From nobody Thu May  1 08:23:54 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2061A0902 for <netmod@ietfa.amsl.com>; Thu,  1 May 2014 08:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVJDh3BlqgCt for <netmod@ietfa.amsl.com>; Thu,  1 May 2014 08:23:48 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD921A6F85 for <netmod@ietf.org>; Thu,  1 May 2014 08:23:48 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id cm18so2014412qab.39 for <netmod@ietf.org>; Thu, 01 May 2014 08:23:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g3yB97et4+sZbGl/42NMlCMRFNlLb5Ozjnc4qii9eqc=; b=ajhFQavEkFUa8C5U6IwKyLo8qQiwFZHOQQfhHDxUbRDrkfgY/7O90bwGqc0hQ7WZN9 x2p40XZDOgCMsEOzGCRSMSJ4GjEkqfOY5szeRNCJVyp/BnYx/zoXZN+DqO3gyfXXXBBw h353va9wynQd135VsDBgZ9AI+8LkhSa0rtMRb76H+r8cVE0BpIgJOmFMcQBiqbp0gpPI 90ZB7PT92jIGX2R6ZWAaVnJAF1Q0tMy69K9qSK0CA9R5Vs5gy8GtfyCZkxdZJfx66wlJ jDI0lB3sF4MLTVckEc3WPjPt9Kmn/oTwv8t+nCBKRBJh3JaOSt71/6ARDV4RH1xlNRJt yvdQ==
X-Gm-Message-State: ALoCoQlcG+zBSwAUD3BM/jiOxKauOgqubun0GlBRmOc8tRDHYxbf67udZbtSfG1n4aZ4YvsLMsoB
MIME-Version: 1.0
X-Received: by 10.140.26.243 with SMTP id 106mr13383543qgv.91.1398957826269; Thu, 01 May 2014 08:23:46 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 08:23:46 -0700 (PDT)
In-Reply-To: <CF872BB7.6BF1B%kwatsen@juniper.net>
References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> <CF859937.6B5B6%kwatsen@juniper.net> <20140430194951.GC31986@elstar.local> <CF872BB7.6BF1B%kwatsen@juniper.net>
Date: Thu, 1 May 2014 08:23:46 -0700
Message-ID: <CABCOCHS9tRjwB=HkUZ4qC4acfnyTCg0tse_P_tT2OoQcDaqKQA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Kent Watsen <kwatsen@juniper.net>
Content-Type: multipart/alternative; boundary=001a11c00c984b207604f8584045
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5Cbp-kmaQa-vYKEGrf33BbOcPro
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 15:23:51 -0000

--001a11c00c984b207604f8584045
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 30, 2014 at 9:18 PM, Kent Watsen <kwatsen@juniper.net> wrote:

>
>
>
> Hi Juergen,
>
>
> > Kent,
> >
> > the process is somewhat like this
> > <snip/>
>
> I can=B9t help the timing on this.  The reason this is coming up now is
> because the NETCONF WG wanted to unify the TLS and SSH config, which mean=
t
> that suddenly the TLS config showed up in a the
> draft-ietf-netconf-server-model, which is supposed to be about configurin=
g
> the server (not user auth).  Maybe the issue can be traced to 5539bis-00
> (Sep 2012), as that is where the TLS-auth config was very first
> introduced.  Perhaps it should=B9ve been put into the
> draft-ietf-netmod-system-mgmt at that time, but the issue was less visibl=
e
> then since it kind of makes sense that the config would be in the 5539bis=
.
>  In fact, Tom said as much here:
> http://www.ietf.org/mail-archive/web/netconf/current/msg08841.html.
>
>
>
> >Of course, since there is another IETF last call, you can raise an
> >issue during this second IETF last call if you believe the document is
> >not ready.
>
> And that we should do if we agree that it=B9s the best course of action.
>
>
>
> ><history deleted>
> >So keep this in mind when you think about the issue. Are we having an
> >issue that renders the current version unusable or is this just one of
> >the many additions one can imagine but which may as well go into a
> >future revision or augmentation of the data model? In the later case,
> >I prefer to not pull this document out of the IESG back into the WG.
>
> The problem is that if it doesn=B9t go into draft-ietf-netmod-system-mgmt=
,
> then the alternative solutions (see bottom) may compound the problem.  No=
w
> is the time for us to at least look at it and agree what makes sense.  I=
=B9m
> all for us doing the right thing, whatever it might be, but we haven=B9t
> even discussed what that is yet.
>
>
>
> >PS: I personally do not believe that the user authentation objects in
> >    the sytem draft need configuration of certifications and trust
> >    anchors.
>
> Great, the discussion begins, so here goes.
>
> The netmod-system-management defines config for User Authentication and
> says that it does so for SSH because that is NETCONF=B9s mandatory to
> implement transport.  Meanwhile we have netconf-server-model, which is
> suppose to be just about configuring the NETCONF server, and yet it has
> user-auth config for TLS (not SSH) in it.  This inconsistency is the issu=
e.
>
>
> So, what are our options?
>
> 1. Go forward with current inconsistency
>
> 2. Only modify draft-ietf-netconf-server-model, but move TLS user-auth ou=
t
>    of ietf-server-model into a separate model that augments ietf-system
>
> 3. Similar to #2, but move the ietf-system augmentation back to 5539bis
>
> 4. Similar to #2, but move the TLS-auth directly (no augmentation) into
>    the ietf-system model defined in draft-ietf-netmod-system-mgmt
>
> 5. Move all user-auth config from draft-ietf-netmod-system-mgmt into
>    draft-ietf-netconf-server-model
>
> 6. Move all user-auth config from both draft-ietf-netmod-system-mgmt
>    and draft-ietf-netconf-server-model into yet another draft (for
>    instance, draft-ietf-netmod-user-auth?)
>
> 7. Anything else?
>
>
I think (2) is OK.

Thanks for explaining why we need service-level conformance specification
for YANG. YANG modules are just building blocks.  The real high-level API
may be defined in 1 sub-tree, but it will be spread across 10 YANG modules.

We have to be able to deliver YANG modules in RFCs in an unimpeded fashion.
There will always be new stuff the pipeline.  YANG needs to be robust enoug=
h
to deal with this reality.

Given the existing YANG conformance limitations, you need to carve up
the new functionality (either w/separate modules of w/ YANG features).
We have to use augment a lot more. We have to maintain data organization
without rewriting or republishing modules constantly.




> Thanks,
> Kent
>
>
>
Andy

--001a11c00c984b207604f8584045
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Apr 30, 2014 at 9:18 PM, Kent Watsen <span dir=3D"ltr">&lt;=
<a href=3D"mailto:kwatsen@juniper.net" target=3D"_blank">kwatsen@juniper.ne=
t</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
<br>
<br>
Hi Juergen,<br>
<br>
<br>
&gt; Kent,<br>
&gt;<br>
&gt; the process is somewhat like this<br>
&gt; &lt;snip/&gt;<br>
<br>
I can=B9t help the timing on this. =A0The reason this is coming up now is<b=
r>
because the NETCONF WG wanted to unify the TLS and SSH config, which meant<=
br>
that suddenly the TLS config showed up in a the<br>
draft-ietf-netconf-server-model, which is supposed to be about configuring<=
br>
the server (not user auth). =A0Maybe the issue can be traced to 5539bis-00<=
br>
(Sep 2012), as that is where the TLS-auth config was very first<br>
introduced. =A0Perhaps it should=B9ve been put into the<br>
draft-ietf-netmod-system-mgmt at that time, but the issue was less visible<=
br>
then since it kind of makes sense that the config would be in the 5539bis.<=
br>
=A0In fact, Tom said as much here:<br>
<a href=3D"http://www.ietf.org/mail-archive/web/netconf/current/msg08841.ht=
ml" target=3D"_blank">http://www.ietf.org/mail-archive/web/netconf/current/=
msg08841.html</a>.<br>
<br>
<br>
<br>
&gt;Of course, since there is another IETF last call, you can raise an<br>
&gt;issue during this second IETF last call if you believe the document is<=
br>
&gt;not ready.<br>
<br>
And that we should do if we agree that it=B9s the best course of action.<br=
>
<br>
<br>
<br>
&gt;&lt;history deleted&gt;<br>
&gt;So keep this in mind when you think about the issue. Are we having an<b=
r>
&gt;issue that renders the current version unusable or is this just one of<=
br>
&gt;the many additions one can imagine but which may as well go into a<br>
&gt;future revision or augmentation of the data model? In the later case,<b=
r>
&gt;I prefer to not pull this document out of the IESG back into the WG.<br=
>
<br>
The problem is that if it doesn=B9t go into draft-ietf-netmod-system-mgmt,<=
br>
then the alternative solutions (see bottom) may compound the problem. =A0No=
w<br>
is the time for us to at least look at it and agree what makes sense. =A0I=
=B9m<br>
all for us doing the right thing, whatever it might be, but we haven=B9t<br=
>
even discussed what that is yet.<br>
<br>
<br>
<br>
&gt;PS: I personally do not believe that the user authentation objects in<b=
r>
&gt; =A0 =A0the sytem draft need configuration of certifications and trust<=
br>
&gt; =A0 =A0anchors.<br>
<br>
Great, the discussion begins, so here goes.<br>
<br>
The netmod-system-management defines config for User Authentication and<br>
says that it does so for SSH because that is NETCONF=B9s mandatory to<br>
implement transport. =A0Meanwhile we have netconf-server-model, which is<br=
>
suppose to be just about configuring the NETCONF server, and yet it has<br>
user-auth config for TLS (not SSH) in it. =A0This inconsistency is the issu=
e.<br>
<br>
<br>
So, what are our options?<br>
<br>
1. Go forward with current inconsistency<br>
<br>
2. Only modify draft-ietf-netconf-server-model, but move TLS user-auth out<=
br>
=A0 =A0of ietf-server-model into a separate model that augments ietf-system=
<br>
<br>
3. Similar to #2, but move the ietf-system augmentation back to 5539bis<br>
<br>
4. Similar to #2, but move the TLS-auth directly (no augmentation) into<br>
=A0 =A0the ietf-system model defined in draft-ietf-netmod-system-mgmt<br>
<br>
5. Move all user-auth config from draft-ietf-netmod-system-mgmt into<br>
=A0 =A0draft-ietf-netconf-server-model<br>
<br>
6. Move all user-auth config from both draft-ietf-netmod-system-mgmt<br>
=A0 =A0and draft-ietf-netconf-server-model into yet another draft (for<br>
=A0 =A0instance, draft-ietf-netmod-user-auth?)<br>
<br>
7. Anything else?<br>
<br></blockquote><div><br></div><div>I think (2) is OK.</div><div><br></div=
><div>Thanks for explaining why we need service-level conformance specifica=
tion</div><div>for YANG. YANG modules are just building blocks. =A0The real=
 high-level API</div>
<div>may be defined in 1 sub-tree, but it will be spread across 10 YANG mod=
ules.</div><div><br></div><div>We have to be able to deliver YANG modules i=
n RFCs in an unimpeded fashion.</div><div>There will always be new stuff th=
e pipeline. =A0YANG needs to be robust enough</div>
<div>to deal with this reality.</div><div><br></div><div>Given the existing=
 YANG conformance limitations, you need to carve up</div><div>the new funct=
ionality (either w/separate modules of w/ YANG features).</div><div>We have=
 to use augment a lot more. We have to maintain data organization</div>
<div>without rewriting or republishing modules constantly.</div><div><br></=
div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Kent<br>
<br>
<br></blockquote><div><br></div><div>Andy</div><div>=A0</div></div></div></=
div>

--001a11c00c984b207604f8584045--


From nobody Fri May  2 01:36:02 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45AC1A0371 for <netmod@ietfa.amsl.com>; Fri,  2 May 2014 01:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCVDwo0xWo8h for <netmod@ietfa.amsl.com>; Fri,  2 May 2014 01:36:00 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 39C201A030E for <netmod@ietf.org>; Fri,  2 May 2014 01:35:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A520054054E; Fri,  2 May 2014 10:35:55 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbxeT64urh2P; Fri,  2 May 2014 10:35:51 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 77C66540187; Fri,  2 May 2014 10:35:49 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>, andy@yumaworks.com
In-Reply-To: <20140430.120437.323948755.mbj@tail-f.com>
References: <m2bnvjclax.fsf@nic.cz> <20140430.100000.412611390.mbj@tail-f.com> <CABCOCHRg_6=0qTafZcf7mGwKU_83KBM_hrN9O=SoGg4YhbGygw@mail.gmail.com> <20140430.120437.323948755.mbj@tail-f.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 02 May 2014 10:35:49 +0200
Message-ID: <m2mwf0inmi.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RMghzIWqVl0SdOhJNSOkg9Vwb1E
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 issue: data-specific attributes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 08:36:02 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

> Andy Bierman <andy@yumaworks.com> wrote:
>> On Wed, Apr 30, 2014 at 1:00 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>> 
>> > Ladislav Lhotka <lhotka@nic.cz> wrote:
>> > > >> Practically speaking, I can see the need for global attributes but
>> > not for
>> > > >> local ones. What are the use cases that cannot be modelled in YANG
>> > now,
>> > > >> e.g. via changing a leaf to a container?
>> > > >>
>> > > >>
>> > > > The global attribute is not that useful.
>> > > > Associating specific metadata with specific data nodes is more useful.
>> > >
>> > > Metadata associated with specific nodes can be modelled as standard YANG
>> > data
>> > > nodes, perhaps using a grouping.
>> >
>> > But this it what we want to avoid...
>> >
>> > > My serious concern is that people will start using attributes as normal
>> > data
>> > > nodes in YANG
>> >
>> > +1
>> >
>> >
>> I did not mention that these attributes are read-only, so it would be
>> impossible
>> to replace config leafs with attributes.  This abuse you are concerned about
>> is not possible.
>
> This seems like an arbitrary limitation.  The "inactive" attribute is
> an example of a read/write (global) attribute.  Why would data-node
> specific attributes be read only?
>
> For both global and local attributes, it must be possible to define
> their read/write properties.

Yes, what's probably more important than how the (meta)data are represented and serialised is to discuss semantics, i.e. how the protocols are supposed to deal with the attributes compared to normal data nodes.

Lada

>
>
>
> /martin

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri May  2 02:26:26 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C690D1A0A62 for <netmod@ietfa.amsl.com>; Fri,  2 May 2014 02:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXNnkoGwPuZl for <netmod@ietfa.amsl.com>; Fri,  2 May 2014 02:26:24 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F12BE1A030E for <netmod@ietf.org>; Fri,  2 May 2014 02:26:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A5F4254054E; Fri,  2 May 2014 11:26:20 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-EN4SEN0lzF; Fri,  2 May 2014 11:26:12 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E1FAF5400EF; Fri,  2 May 2014 11:26:10 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>, feng.chong33@zte.com.cn
In-Reply-To: <20140430.080334.89777294.mbj@tail-f.com>
References: <OFADE35010.09DFFB02-ON48257CCA.00040A19-48257CCA.000692D6@zte.com.cn> <20140430.080334.89777294.mbj@tail-f.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 02 May 2014 11:26:09 +0200
Message-ID: <m2eh0cilam.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3QBrMnWyMO6KtNr7XBAiInu4wc8
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG1.1 issue:add 'dataset' and 'datastore' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 09:26:25 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

> Hi,
>
> I added this as an alternative solution to Y42; Y42-02.


+1

I think it should be considered, too, some extensibility might be useful. The set of (configuration) datastores is extensible in theory but currently there is no way for specifying the semantics of new datastores. In fact, even the semantics of "running" is open-ended.

Lada

>
>
> /martin
>
>
>
> feng.chong33@zte.com.cn wrote:
>> Hi all,
>>       I suggest add 'dataset' and 'datastore' statements to identify which 
>> dataset a data node belongs to.
>>       YANG use config statement to identify whether the node belongsto 
>> configuration dataset, but it is not extensible.
>>  
>>       For example, I2RS want to define its own dataset, but YANG have no 
>> syntax to identify which node belongs to I2RS dataset,
>>       unless I2RS extend its own yang keyword.
>> 
>>       I think we should provide a standard way to de this.
>>  
>>       'dataset' statement can be used to define a user-specific dataset. 
>> and a new statement 'belongs' can be used to identify which dataset 
>>        the data node belongs to, as substatement of data 
>> nodes(container,list,leaf,leaf-list,anyxml,etc).
>>  
>>       'datastore' statement can be used to define a data store based on 
>> one dataset.
>>  
>>       dataset statement's substatements are listed below:
>>  
>> substatement
>> cardinality
>> description
>> 0..1
>> reference
>> 0..1
>> 
>>      datastore statement's substatements are listed below:
>>  
>> substatement
>> cardinality
>> base
>> 1
>> description
>> 0..1
>> reference
>> 0..1
>> 
>>      The 'base' statement has a argument,its value is a defined dataset, 
>> to indicate which dataset this datastore is based.
>> 
>>      For example:
>>      dataset config {
>>         description "the configuration dataset";
>>      }
>> 
>>      datastore running {
>>         base config;
>>         description "running configuration data store";
>>      }
>>  
>>      dataset i2rs {
>>          description "i2rs data set";
>>      }
>>  
>>      datastore i2rs {
>>          base i2rs;
>>      }
>> 
>>      container foo {
>>         belongs config;
>>        list foo-list {
>>             belongs i2rs;
>>             key name;
>>             leaf name {...}
>>             leaf other {...}
>>        }
>>      }
>> 
>> /frank
>> --------------------------------------------------------
>> ZTE Information Security Notice: The information contained in this mail (and
>> any attachment transmitted herewith) is privileged and confidential and is
>> intended for the exclusive use of the addressee(s).  If you are not an intended
>> recipient, any disclosure, reproduction, distribution or other dissemination or
>> use of the information contained is strictly prohibited.  If you have received
>> this mail in error, please delete it and notify us immediately.
>> --------------------------------------------------------
>> ZTE Information Security Notice: The information contained in this mail (and
>> any attachment transmitted herewith) is privileged and confidential and is
>> intended for the exclusive use of the addressee(s).  If you are not an intended
>> recipient, any disclosure, reproduction, distribution or other dissemination or
>> use of the information contained is strictly prohibited.  If you have received
>> this mail in error, please delete it and notify us immediately.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri May  2 05:39:36 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2546F1A6FA7 for <netmod@ietfa.amsl.com>; Fri,  2 May 2014 05:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbS0ni4sXKvM for <netmod@ietfa.amsl.com>; Fri,  2 May 2014 05:39:31 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id BB00D1A6F74 for <netmod@ietf.org>; Fri,  2 May 2014 05:39:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ECDB9751; Fri,  2 May 2014 14:39:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UlM2x7Wg82pO; Fri,  2 May 2014 14:39:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri,  2 May 2014 14:39:28 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E73820017; Fri,  2 May 2014 14:39: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 53DuzP_YZTIu; Fri,  2 May 2014 14:39:26 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B79020013; Fri,  2 May 2014 14:39:26 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 625F42CC81B3; Fri,  2 May 2014 14:39:25 +0200 (CEST)
Date: Fri, 2 May 2014 14:39:25 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.net>
Message-ID: <20140502123925.GC36168@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> <CF859937.6B5B6%kwatsen@juniper.net> <20140430194951.GC31986@elstar.local> <CF872BB7.6BF1B%kwatsen@juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CF872BB7.6BF1B%kwatsen@juniper.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/M79pyTiK9IQmfslWvHwULjYFA4A
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 12:39:34 -0000

On Thu, May 01, 2014 at 04:18:33AM +0000, Kent Watsen wrote:
> 
> 
> The problem is that if it doesnıt go into draft-ietf-netmod-system-mgmt,
> then the alternative solutions (see bottom) may compound the problem.  Now
> is the time for us to at least look at it and agree what makes sense.  Iım
> all for us doing the right thing, whatever it might be, but we havenıt
> even discussed what that is yet.
> 

Since there are no concrete edits people agree on at this point in
time, I do not plan to move draft-ietf-netmod-system-mgmt back form
the IESG into the WG to work on it a couple of more weeks and then to
restart the whole procedure.

> The netmod-system-management defines config for User Authentication and
> says that it does so for SSH because that is NETCONFıs mandatory to
> implement transport.  Meanwhile we have netconf-server-model, which is
> suppose to be just about configuring the NETCONF server, and yet it has
> user-auth config for TLS (not SSH) in it.  This inconsistency is the issue.

I do not think this is a fair summary. Both, SSH and TLS call home
need parameters configured on the NC server side but also on the NC
client side, (e.g. the SSH user and its credentials to call home).
Where will this stuff go?

Sure, we can move the cert-maps and psk-maps to some other module, I
am not sure though it really helps solving a concrete problem. These
are at the end objects to implement on the NC server, whether they are
defined as part of draft-ietf-netmod-system-mgmt, netconf-server-model
or some other module. And the maps are rather NETCONF over TLS
specific.  The SSH authentication objects may also be used outside
NETCONF, e.g. to configure plain old access to the system's CLI.
 
> So, what are our options?
> 
> 1. Go forward with current inconsistency
> 
> 2. Only modify draft-ietf-netconf-server-model, but move TLS user-auth out
>    of ietf-server-model into a separate model that augments ietf-system
> 
> 3. Similar to #2, but move the ietf-system augmentation back to 5539bis
> 
> 4. Similar to #2, but move the TLS-auth directly (no augmentation) into
>    the ietf-system model defined in draft-ietf-netmod-system-mgmt
> 
> 5. Move all user-auth config from draft-ietf-netmod-system-mgmt into
>    draft-ietf-netconf-server-model
> 
> 6. Move all user-auth config from both draft-ietf-netmod-system-mgmt
>    and draft-ietf-netconf-server-model into yet another draft (for
>    instance, draft-ietf-netmod-user-auth?)
> 
> 7. Anything else?

As NETMOD WG co-chair, I want to publish draft-ietf-netmod-system-mgmt.
Building "perfect" modules means we will never finish. Once again,
modules can be revised and augmented if needed.

/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 nobody Sat May  3 09:42:41 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8E1A0102 for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 09:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnWqzkv_9bY4 for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 09:42:38 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 20B201A0104 for <netmod@ietf.org>; Sat,  3 May 2014 09:42:37 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id x13so6062225qcv.7 for <netmod@ietf.org>; Sat, 03 May 2014 09:42:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RV5bvawb16JRHz+icKgvw/eXCky455MeKurflBf/lEI=; b=invptRoOdYZ+7fEJTNPoTo1kpOCAtX354qZyfkgFEB2WuLZ+YOKnSGIHy5u7yYJzJv RW3Gg9NQITsbyo+b94ynzySgURpf0Dce2Zn9AahZG/2K+RNgYVDJxF4/2Vo/TMJOhRUR xAPeYcmd9ylOszvKvQ7/5GQE37J8VYBxqEUwLITvJhXhZPUV9g0tYr8jcwRusm+2EQWs z0rKrjpB0KO96NHDkq28f/htTR25Ka3mRoWDPFh9xXw2VZsKa9rj4pRxZrD6FCRg9F9I L3rKvqOZXVRgYypSaRvi+MxfeM97wL+D5pQy4Hs5s3IsyMlKxIawF+Ra71S7gNAgHW+D SiOQ==
X-Gm-Message-State: ALoCoQkJpDX17gGRFqbPsbP6UY5R/JDJCagxuF+oSC3blMZHb2fdh0ySnalty7OmuOIGH4lFasAE
MIME-Version: 1.0
X-Received: by 10.224.36.129 with SMTP id t1mr28599046qad.88.1399135355174; Sat, 03 May 2014 09:42:35 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Sat, 3 May 2014 09:42:35 -0700 (PDT)
Date: Sat, 3 May 2014 09:42:35 -0700
Message-ID: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=089e0158a9e4d696e004f88195d1
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Oj2wE6pDFok5KB_qcIyNSzXvbNk
Subject: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 16:42:40 -0000

--089e0158a9e4d696e004f88195d1
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Problem:

The use of a leaf in the data model (such as the
/interfaces/interface/enabled
leaf in the ietf-interfaces module) does not account for YANG validation
rules
for many statements that can reference the disabled subtree from outside
of that subtree:

    - must
    - when
    - unique
    - min-elements
    - max-elements
    - leafref (valid instances)
    - choices (disabled case is still the active case, so no other can be
used)

The behavior for all of these statements needs to be clarified
when disabled nodes are involved.

The 'enabled' leaf is like SMIv2 RowStatus TC, except that
it is ad-hoc and used randomly. SMIv2 does not have any
validation statements that can be affected by a 'notInService' row,
so RowStatus is not broken in SNMP.

Solution:

YANG 1.1 must define a "metadata plane" that applies to
configuration datastores.  Global attributes that are specific
to configuration datastores (e.g. with-defaults) will be included
in the standard metadata library. It is expected that protocols
using YANG will define operations for reading and writing
global attributes.

YANG 1.1 must define an "enabled" global attribute that must
be supported in all YANG 1.1 tools. The YANG validation rules
must be adjusted to properly account for disabled subtrees.

Side issue: should 'enabled' leafs be removed when converting
a YANG 1.0 module to YANG 1.1?


Andy

--089e0158a9e4d696e004f88195d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Problem:</div><div><br></div><div>T=
he use of a leaf in the data model (such as the /interfaces/interface/enabl=
ed</div><div>leaf in the ietf-interfaces module) does not account for YANG =
validation rules</div>
<div>for many statements that can reference the disabled subtree from outsi=
de</div><div>of that subtree:</div><div><br></div><div>=A0 =A0 - must</div>=
<div>=A0 =A0 - when</div><div>=A0 =A0 - unique</div><div>=A0 =A0 - min-elem=
ents</div><div>
=A0 =A0 - max-elements</div><div>=A0 =A0 - leafref (valid instances)</div><=
div>=A0 =A0 - choices (disabled case is still the active case, so no other =
can be used)</div><div><br></div><div>The behavior for all of these stateme=
nts needs to be clarified</div>
<div>when disabled nodes are involved.</div><div><br></div><div>The &#39;en=
abled&#39; leaf is like SMIv2 RowStatus TC, except that</div><div>it is ad-=
hoc and used randomly. SMIv2 does not have any</div><div>validation stateme=
nts that can be affected by a &#39;notInService&#39; row,</div>
<div>so RowStatus is not broken in SNMP.</div><div><br></div><div>Solution:=
</div><div><br></div><div>YANG 1.1 must define a &quot;metadata plane&quot;=
 that applies to</div><div>configuration datastores. =A0Global attributes t=
hat are specific</div>
<div>to configuration datastores (e.g. with-defaults) will be included</div=
><div>in the standard metadata library. It is expected that protocols</div>=
<div>using YANG will define operations for reading and writing</div><div>
global attributes.</div><div><br></div><div>YANG 1.1 must define an &quot;e=
nabled&quot; global attribute that must</div><div>be supported in all YANG =
1.1 tools. The YANG validation rules</div><div>must be adjusted to properly=
 account for disabled subtrees.</div>
<div><br></div><div>Side issue: should &#39;enabled&#39; leafs be removed w=
hen converting</div><div>a YANG 1.0 module to YANG 1.1?</div><div><br></div=
><div><br></div><div>Andy</div><div><br></div></div>

--089e0158a9e4d696e004f88195d1--


From nobody Sat May  3 11:50:53 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870741A00F4 for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 11:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H75ADBNdIDOs for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 11:50:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3A1A00F0 for <netmod@ietf.org>; Sat,  3 May 2014 11:50:50 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C7D9F13FA79; Sat,  3 May 2014 20:50:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399143046; bh=30UVzCfYF9xlc+CuMmgU5Bllajrsgel9r+qKF7uGwfg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Fgaa5mAhITIVh15vq0r+pRmQ6rSwfaW2SZidVhVYOmiMig8FYMmF4+rfuowb+wfwB mvnkMetq+/3FERNwsZhd/GUpE7FvodW2GKARkQ81SbPJl64kGP+09+K6ju4lHf492d hYwGCMishNDNPXGcMBdigHitMKQCHgx247HJ72DY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com>
Date: Sat, 3 May 2014 20:50:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kym8RWhnnmU4DkUSDmwJv4S8kIQ
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 18:50:51 -0000

On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:

> Hi,
>=20
> Problem:
>=20
> The use of a leaf in the data model (such as the =
/interfaces/interface/enabled
> leaf in the ietf-interfaces module) does not account for YANG =
validation rules
> for many statements that can reference the disabled subtree from =
outside
> of that subtree:
>=20
>     - must
>     - when
>     - unique
>     - min-elements
>     - max-elements
>     - leafref (valid instances)
>     - choices (disabled case is still the active case, so no other can =
be used)

In my view, an =93enabled false=94 leaf *operationally* disables a =
particular instance or function. For all other purposes related to =
datastore validation, the value of the enabled leaf doesn=92t matter. In =
other words, =93enabled false=94 is not the same as commenting out the =
corresponding instance in the configuration.

Lada

>=20
> The behavior for all of these statements needs to be clarified
> when disabled nodes are involved.
>=20
> The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> it is ad-hoc and used randomly. SMIv2 does not have any
> validation statements that can be affected by a 'notInService' row,
> so RowStatus is not broken in SNMP.
>=20
> Solution:
>=20
> YANG 1.1 must define a "metadata plane" that applies to
> configuration datastores.  Global attributes that are specific
> to configuration datastores (e.g. with-defaults) will be included
> in the standard metadata library. It is expected that protocols
> using YANG will define operations for reading and writing
> global attributes.
>=20
> YANG 1.1 must define an "enabled" global attribute that must
> be supported in all YANG 1.1 tools. The YANG validation rules
> must be adjusted to properly account for disabled subtrees.
>=20
> Side issue: should 'enabled' leafs be removed when converting
> a YANG 1.0 module to YANG 1.1?
>=20
>=20
> Andy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sat May  3 12:31:09 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97D41A010D for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 12:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t8wmfSKKT-l for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 12:31:04 -0700 (PDT)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id B15C21A0103 for <netmod@ietf.org>; Sat,  3 May 2014 12:31:04 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id l6so1396822qcy.37 for <netmod@ietf.org>; Sat, 03 May 2014 12:31:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SGsiQ9wihwhlnSm/ej1JylLmjREbdWR1+I3XlESdmF0=; b=dA1dWYqlKB9kVZGiPLiTNGuUnW7UEjnzvp0zPvy5PV85J6LhHy6UCco7EmIpd2KrM1 HFKJAon1vTkjypMDwTPVRTL2hOdhYDXBMtBVUmhFY2r8uoVMb63tKFEhxDhNiqwE73a2 OYrRdhvtFsQ9YIQMhtY+8jhlbceFhSHwe6IKQ5QvdRTLQkX2DurApGA8Z77jieUD44EI 5fIGE4Z2V4GOygo/YvEgmJctugQPeHfKRLV7BL0e3uECuNnN7Wfg4A0ZT6Y1udwd7m+G XFlhJ97Mk7WCgjOp10SwBYkd8cLONUlVj57tnVTAPlU/nPndjxOmozccgqwwy2REdCzT rCpA==
X-Gm-Message-State: ALoCoQlz6K5JMlwNfdy565u46fOLF7US/1LohuIS0q6Yl0dDWlopTFe6xJoCbHZ7sK8G5Dl1y3G4
MIME-Version: 1.0
X-Received: by 10.140.26.243 with SMTP id 106mr29680488qgv.91.1399145461809; Sat, 03 May 2014 12:31:01 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Sat, 3 May 2014 12:31:01 -0700 (PDT)
In-Reply-To: <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz>
Date: Sat, 3 May 2014 12:31:01 -0700
Message-ID: <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c00c983d9f1404f883f0df
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rupEnLwMhQSJXlm5Er95TSWxrFs
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 19:31:07 -0000

--001a11c00c983d9f1404f883f0df
Content-Type: text/plain; charset=ISO-8859-1

On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
>
> > Hi,
> >
> > Problem:
> >
> > The use of a leaf in the data model (such as the
> /interfaces/interface/enabled
> > leaf in the ietf-interfaces module) does not account for YANG validation
> rules
> > for many statements that can reference the disabled subtree from outside
> > of that subtree:
> >
> >     - must
> >     - when
> >     - unique
> >     - min-elements
> >     - max-elements
> >     - leafref (valid instances)
> >     - choices (disabled case is still the active case, so no other can
> be used)
>
> In my view, an "enabled false" leaf *operationally* disables a particular
> instance or function. For all other purposes related to datastore
> validation, the value of the enabled leaf doesn't matter. In other words,
> "enabled false" is not the same as commenting out the corresponding
> instance in the configuration.
>
>
OK -- they may be different, but the enabled leaf is ad-hoc,
and YANG designers must know about this leaf.  Adding or removing
this leaf could break other YANG statements.

E,g,


   leaf active-foo-interface {
       type  if:interface-ref;
       mandatory true;
   }


By YANG validation rules, the  leafref test for interface name
will include all disabled interfaces.

Doesn't every object that uses the interface-ref typedef need
to have a must-stmt making sure the enabled leaf is set,
if they want to activate a service on only enabled interfaces?

(Is this the must-stmt to use?)

   leaf active-foo-interface {
       type  if:interface-ref;
       must "/if:interfaces/if:interface[if:name=current()]/enabled";
       mandatory true;
   }

Don't all must/when/leafref validation statements that want only
active interfaces need to be written this way?

I agree this notion of "operationally disabled" is not the
same as commenting out.  I don't think N/Y properly supports
either one.



Lada
>

Andy


>
> >
> > The behavior for all of these statements needs to be clarified
> > when disabled nodes are involved.
> >
> > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > it is ad-hoc and used randomly. SMIv2 does not have any
> > validation statements that can be affected by a 'notInService' row,
> > so RowStatus is not broken in SNMP.
> >
> > Solution:
> >
> > YANG 1.1 must define a "metadata plane" that applies to
> > configuration datastores.  Global attributes that are specific
> > to configuration datastores (e.g. with-defaults) will be included
> > in the standard metadata library. It is expected that protocols
> > using YANG will define operations for reading and writing
> > global attributes.
> >
> > YANG 1.1 must define an "enabled" global attribute that must
> > be supported in all YANG 1.1 tools. The YANG validation rules
> > must be adjusted to properly account for disabled subtrees.
> >
> > Side issue: should 'enabled' leafs be removed when converting
> > a YANG 1.0 module to YANG 1.1?
> >
> >
> > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c00c983d9f1404f883f0df
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <span dir=3D"ltr">=
&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><br>
On 03 May 2014, at 18:42, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; Problem:<br>
&gt;<br>
&gt; The use of a leaf in the data model (such as the /interfaces/interface=
/enabled<br>
&gt; leaf in the ietf-interfaces module) does not account for YANG validati=
on rules<br>
&gt; for many statements that can reference the disabled subtree from outsi=
de<br>
&gt; of that subtree:<br>
&gt;<br>
&gt; &nbsp; &nbsp; - must<br>
&gt; &nbsp; &nbsp; - when<br>
&gt; &nbsp; &nbsp; - unique<br>
&gt; &nbsp; &nbsp; - min-elements<br>
&gt; &nbsp; &nbsp; - max-elements<br>
&gt; &nbsp; &nbsp; - leafref (valid instances)<br>
&gt; &nbsp; &nbsp; - choices (disabled case is still the active case, so no=
 other can be used)<br>
<br>
In my view, an &ldquo;enabled false&rdquo; leaf *operationally* disables a =
particular instance or function. For all other purposes related to datastor=
e validation, the value of the enabled leaf doesn&rsquo;t matter. In other =
words, &ldquo;enabled false&rdquo; is not the same as commenting out the co=
rresponding instance in the configuration.<br>

<br></blockquote><div><br></div><div>OK -- they may be different, but the e=
nabled leaf is ad-hoc,</div><div>and YANG designers must know about this le=
af. &nbsp;Adding or removing</div><div>this leaf could break other YANG sta=
tements.</div>
<div><br></div><div>E,g,</div><div><br></div><div><br></div><div>&nbsp; &nb=
sp;leaf active-foo-interface {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;type &n=
bsp;if:interface-ref;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<=
/div><div>&nbsp; &nbsp;}</div><div><br></div><div><br></div><div>
By YANG validation rules, the &nbsp;leafref test for interface name</div><d=
iv>will include all disabled interfaces.</div><div><br></div><div>Doesn&#39=
;t every object that uses the interface-ref typedef need</div><div>to have =
a must-stmt making sure the enabled leaf is set,</div>
<div>if they want to activate a service on only enabled interfaces?</div><d=
iv><br></div><div>(Is this the must-stmt to use?)</div><div><br></div><div>=
<div>&nbsp; &nbsp;leaf active-foo-interface {</div><div>&nbsp; &nbsp; &nbsp=
; &nbsp;type &nbsp;if:interface-ref;</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if:interfaces/if:interface[if:n=
ame=3Dcurrent()]/enabled&quot;;<br></div><div>&nbsp; &nbsp; &nbsp; &nbsp;ma=
ndatory true;</div><div>&nbsp; &nbsp;}</div></div><div><br></div><div>Don&#=
39;t all must/when/leafref validation statements that want only</div>
<div>active interfaces need to be written this way?</div><div><br></div><di=
v>I agree this notion of &quot;operationally disabled&quot; is not the</div=
><div>same as commenting out. &nbsp;I don&#39;t think N/Y properly supports=
</div>
<div>either one.<br></div><div><br></div><div><br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">

Lada<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">

<br>
&gt;<br>
&gt; The behavior for all of these statements needs to be clarified<br>
&gt; when disabled nodes are involved.<br>
&gt;<br>
&gt; The &#39;enabled&#39; leaf is like SMIv2 RowStatus TC, except that<br>
&gt; it is ad-hoc and used randomly. SMIv2 does not have any<br>
&gt; validation statements that can be affected by a &#39;notInService&#39;=
 row,<br>
&gt; so RowStatus is not broken in SNMP.<br>
&gt;<br>
&gt; Solution:<br>
&gt;<br>
&gt; YANG 1.1 must define a &quot;metadata plane&quot; that applies to<br>
&gt; configuration datastores. &nbsp;Global attributes that are specific<br=
>
&gt; to configuration datastores (e.g. with-defaults) will be included<br>
&gt; in the standard metadata library. It is expected that protocols<br>
&gt; using YANG will define operations for reading and writing<br>
&gt; global attributes.<br>
&gt;<br>
&gt; YANG 1.1 must define an &quot;enabled&quot; global attribute that must=
<br>
&gt; be supported in all YANG 1.1 tools. The YANG validation rules<br>
&gt; must be adjusted to properly account for disabled subtrees.<br>
&gt;<br>
&gt; Side issue: should &#39;enabled&#39; leafs be removed when converting<=
br>
&gt; a YANG 1.0 module to YANG 1.1?<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; netmod mailing list<br>
&gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c00c983d9f1404f883f0df--


From nobody Sat May  3 22:59:18 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0011A0010 for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 22:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.5
X-Spam-Level: 
X-Spam-Status: No, score=-99.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeugaqwTlby3 for <netmod@ietfa.amsl.com>; Sat,  3 May 2014 22:59:12 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7E1A000E for <netmod@ietf.org>; Sat,  3 May 2014 22:59:11 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id B7B2219234A6 for <netmod@ietf.org>; Sun,  4 May 2014 13:58:54 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 7F791716F6D; Sun,  4 May 2014 13:58:53 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s445wuIV072438; Sun, 4 May 2014 13:58:56 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <CABCOCHQM9NpcaA13nN2TUx-KmTk2CH2ZLAmMJtDqvujGhoJRiw@mail.gmail.com>
References: <OFADE35010.09DFFB02-ON48257CCA.00040A19-48257CCA.000692D6@zte.com.cn>	<20140430060001.GA29852@elstar.local> <CABCOCHQM9NpcaA13nN2TUx-KmTk2CH2ZLAmMJtDqvujGhoJRiw@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
MIME-Version: 1.0
X-KeepSent: D097ADA8:12F46D00-48257CCE:001F06CF; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OFD097ADA8.12F46D00-ON48257CCE.001F06CF-48257CCE.0020DDB4@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Sun, 4 May 2014 13:58:57 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-04 13:58:58, Serialize complete at 2014-05-04 13:58:58
Content-Type: multipart/alternative; boundary="=_alternative 0020DDB248257CCE_="
X-MAIL: mse01.zte.com.cn s445wuIV072438
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ildyEUbClrm7Oq7aaFECjKFikYM
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG1.1 issue:add 'dataset' and 'datastore' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 05:59:16 -0000

This is a multipart message in MIME format.

--=_alternative 0020DDB248257CCE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDQt
MzAgMjI6MTY6NDA6DQoNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAy
MDE0LTA0LTMwIDIyOjE2DQo+IA0KPiDK1bz+yMsNCj4gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiwgDQo+IGZlbmcuY2hvbmcz
M0B6dGUuY29tLmNuLCAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPiwgDQo+IA0K
PiCzrcvNDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW25ldG1vZF0gWUFORzEuMSBpc3N1ZTphZGQg
J2RhdGFzZXQnIGFuZCAnZGF0YXN0b3JlJyBzdGF0ZW1lbnRzDQo+IA0KPiANCg0KPiBPbiBUdWUs
IEFwciAyOSwgMjAxNCBhdCAxMTowMCBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDwNCj4gai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gSSB0aGluayB0aGUg
ZXhhbXBsZXMgc2hvdyBhIG1pc2NvbmNlcHRpb24gYWJvdXQgaG93IFlBTkcgd29ya3MgYW5kIGEN
Cj4gbGlrZWx5IHR5cGljYWwgbWlzdXNlIG9mIGEgbWVjaGFuaXNtIHRvIGRlZmluZSAnZGF0YXNl
dCdzIGFuZA0KPiAnZGF0YXN0b3JlcycuIEkgdGhpbmsgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRv
IGRlc2lnbmF0ZSBzYXkgYSBsZWFmDQo+IGRlZmluaXRpb24gYXMgYmVsb25naW5nIHRvIHRoZSBy
dW5uaW5nIGRhdGFzdG9yZSBpbnN0ZWFkIG9mIG1hcmtpbmcgaXQNCj4gYXMgYSBjb25maWcgb2Jq
ZWN0Lg0KDQo+IA0KPiBJIGRvIG5vdCB3YW50IFlBTkcgbW9kdWxlcyBkZWZpbmluZyBkYXRhc3Rv
cmVzLg0KPiBUaGlzIGNsYXNzaWZpY2F0aW9uIG5lZWRzIHRvIGJlIGhhcmQtd2lyZWQgYmVjYXVz
ZSB0aGUgdmFsaWRhdGlvbiBydWxlcw0KPiBhcmUgc3BlY2lmaWMgdG8gdGhlIGRhdGFzdG9yZS4g
SG93IGRvZXMgYSBjbGllbnQga25vdyB0aGUgdmFsaWRhdGlvbg0KPiBydWxlcyBmb3IgdGhlICJh
Y21lOnNwZWNpYWwtZGF0YXN0b3JlIj8NCg0KSSB0aGluayBpZiBhIGNsaWVudCBkb24ndCBrbm93
IGEgdXNlci1kZWZpbmVkIGRhdGFzdG9ycywgaXQgd2lsbCBpZ25vcmUgDQp0aGUgZGF0YSBub2Rl
IHRhZ2dlZCB3aXRoIGRhdGFzZXQgYmFzZWQgYnkgdGhpcyBkYXRhc3RvcmUuDQoNCkZvciBleGFt
cGxlLCAnZWRpdC1jb25maWcnIG9wZXJhdGlvbidzIHRhcmdldCBpcyBydW5uaW5nL2NhbmRpZGF0
ZSwNCmlmIGEgZGF0YSBub2RlIHRhZ2dlZCB3aXRoICJhY21lOnNwZWNpYWwtZGF0YXN0b3JlIiwg
dGhpcyBkYXRhIG5vZGUgd2lsbCANCmJlIGlnbm9yZWQgYnkgJ2VkaXQtY29uZmlnJy4NCidlZGl0
LWNvbmZpZycgb3BlcmF0aW9uIGNhbiBvbmx5IGVkaXQgdGhlIGRhdGEgbm9kZSB0YWdnZWQgd2l0
aCAnY29uZmlnJyANCmRhdGFzZXQuDQogDQo+IA0KPiBTbyBmYXIsIHdlIGRpc3Rpbmd1aXNoIGNv
bmZpZ3VyYXRpb24gb2JqZWN0cyBmcm9tIG9wZXJhdGlvbmFsIHN0YXRlDQo+IG9iamVjdHMuIFdo
YXQgd2UgYXJlIG1pc3Npbmcgc2VlbXMgdG8gYmUgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4NCj4g
cmVhZC1vbmx5IG9wZXJhdGlvbmFsIHN0YXRlIG9iamVjdHMgYW5kIG9wZXJhdGlvbmFsIHN0YXRl
IG9iamVjdHMgdGhhdA0KPiBjYW4gYmUgd3JpdHRlbi4gSSBtYXkgYmUgdmVyeSB3cm9uZyB0byBh
bGxvdyBkYXRhIG1vZGVsIHdyaXRlcnMgdG8NCj4gY29tZSB1cCB3aXRoIGFyYml0cmFyeSBzdWNo
IGRpc3RpbmN0aW9ucy4NCg0KPiANCj4gKzENCj4gDQo+IFdlIGhhdmUgcnBjICsgZGF0YSBub2Rl
cyArIG5vdGlmaWNhdGlvbnMuDQo+IFRoZSAnZGF0YSBub2RlcycgcGllY2UgY29uc2lzdHMgb2Yg
YSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZQ0KPiBwbHVzIHNvbWUgY29uZmlnPWZhbHNlIHN0dWZm
IHRoYXQgaXMgbm90IGluIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuDQo+IFlBTkcgZG9lcyBu
b3QgZGVmaW5lIGl0IGFueSBmdXJ0aGVyIHRoYW4gdGhhdC4NCj4gDQo+IFdlIG5lZWQgdG8gZGl2
aWRlIHRoZSBjb25maWc9ZmFsc2UgYmxvYiBpbnRvIGF0IGxlYXN0IDIgcGllY2VzOg0KPiAgIDEp
IGVkaXRhYmxlIG9wZXJhdGlvbmFsIHN0YXRlDQo+ICAgMikgbm9uLWVkaXRhYmxlIG9wZXJhdGlv
bmFsIHN0YXRlIGFuZCBzdGF0aXN0aWNzDQo+IA0KPiBZQU5HIGRvZXMgbm90IHRhZyBkYXRhIGFz
ICdORVRDT05GJyBvciAnSTJSUycgYnV0DQo+IHJhdGhlciBqdXN0IGlkZW50aWZpZXMgdGhlIGRh
dGEgcHJvcGVydGllcy4gIFRoZSBwcm90b2NvbCB1c2VkIHRvDQo+IGVkaXQgZGF0YSBpcyBvdXRz
aWRlIHRoZSBzY29wZSBvZiBZQU5HIChpZiBpdCBpcyBkZXNpZ25lZCBjb3JyZWN0bHkpLg0KPiAN
Cg0KSSB0aGluayAgZGF0YSBub2RlcyBkZWZpbmVkIGJ5IFlBTkcgaXMgbm90IHNpbXBseSAgZGl2
aWRlZCAgaW50byBjb25maWcgDQphbmQgbm90IGNvbmZpZy4NCldlIGhhdmUgbm8gd2F5IHRvIGRl
ZmluZSBhbGwgbWV0aG9kcyBob3cgdGhlIGRhdGEgbm9kZXMgaXMgZGl2aWRlZC4NCg0KU28sIHdl
IHNob3VsZCBwcm92aWRlIGEgd2F5ICBmb3IgdXNlciB0byBkZWZpbmUgdGhlIGRvbWFpbiB3aGF0
IGRhdGEgbm9kZXMgDQpiZWxvbmdzIHRvLg0KDQpGb3IgZXhhbXBsZSwgTkVUQ09ORiBjYW4gZGVm
aW5lIGNvbmZpZyBkYXRhc2V0IGFuZCBzdGF0ZSBkYXRhc2V0LA0KSTJSUyBjYW4gZGVmaW5lIGky
cnMtZWRpdGFibGUgZGF0YXNldCBhbmQgaTJycy1yZWFkb25seSBkYXRhc2V0Lg0KDQo+IEluIG90
aGVyIHdvcmRzLCBhIHByb3Bvc2FsIHRvIGludHJvZHVjZSBhIG1lY2hhbmlzbSB0byBpZGVudGlm
eQ0KPiB3cml0YWJsZSBvcGVyYXRpb25hbCBzdGF0ZSBpcyBvbmUgdGhpbmcgKGlmIGl0IGNvbWVz
IGFsb25nIHdpdGggYQ0KPiBjbGVhciB1bmRlcnN0YW5kaW5nIHdoYXQgdGhlIGltcGFjdCBvZiB0
aGlzIGlzIG9uIHRoZSB3aG9sZQ0KPiBORVRDT05GL1lBTkcgaW5mcmFzdHJ1Y3R1cmUpLiBCdXQg
YSBwcm9wb3NhbCB0byB0byBhbGxvdyBhbiBvcGVuIGVuZGVkDQo+IHNldCBvZiBvYmplY3QgY2xh
c3NlcyBhbmQgZGF0YXN0b3JlcyBzZWVtcyBub3QgdmVyeSB1c2VmdWwuDQo+IA0KPiAvanMgKHNw
ZWFraW5nIGFzIHRlY2huaWNhbCBjb250cmlidXRvcikNCg0KPiANCj4gQW5keQ0KPiAgDQo+IE9u
IFdlZCwgQXByIDMwLCAyMDE0IGF0IDA5OjExOjI1QU0gKzA4MDAsIGZlbmcuY2hvbmczM0B6dGUu
Y29tLmNuIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPiAgICAgICBJIHN1Z2dlc3QgYWRkICdkYXRh
c2V0JyBhbmQgJ2RhdGFzdG9yZScgc3RhdGVtZW50cyB0byBpZGVudGlmeSANCndoaWNoDQo+ID4g
ZGF0YXNldCBhIGRhdGEgbm9kZSBiZWxvbmdzIHRvLg0KPiA+ICAgICAgIFlBTkcgdXNlIGNvbmZp
ZyBzdGF0ZW1lbnQgdG8gaWRlbnRpZnkgd2hldGhlciB0aGUgbm9kZSBiZWxvbmdzdG8NCj4gPiBj
b25maWd1cmF0aW9uIGRhdGFzZXQsIGJ1dCBpdCBpcyBub3QgZXh0ZW5zaWJsZS4NCj4gPg0KPiA+
ICAgICAgIEZvciBleGFtcGxlLCBJMlJTIHdhbnQgdG8gZGVmaW5lIGl0cyBvd24gZGF0YXNldCwg
YnV0IFlBTkcgaGF2ZSANCm5vDQo+ID4gc3ludGF4IHRvIGlkZW50aWZ5IHdoaWNoIG5vZGUgYmVs
b25ncyB0byBJMlJTIGRhdGFzZXQsDQo+ID4gICAgICAgdW5sZXNzIEkyUlMgZXh0ZW5kIGl0cyBv
d24geWFuZyBrZXl3b3JkLg0KPiA+DQo+ID4gICAgICAgSSB0aGluayB3ZSBzaG91bGQgcHJvdmlk
ZSBhIHN0YW5kYXJkIHdheSB0byBkZSB0aGlzLg0KPiA+DQo+ID4gICAgICAgJ2RhdGFzZXQnIHN0
YXRlbWVudCBjYW4gYmUgdXNlZCB0byBkZWZpbmUgYSB1c2VyLXNwZWNpZmljIA0KZGF0YXNldC4N
Cj4gPiBhbmQgYSBuZXcgc3RhdGVtZW50ICdiZWxvbmdzJyBjYW4gYmUgdXNlZCB0byBpZGVudGlm
eSB3aGljaCBkYXRhc2V0DQo+ID4gICAgICAgIHRoZSBkYXRhIG5vZGUgYmVsb25ncyB0bywgYXMg
c3Vic3RhdGVtZW50IG9mIGRhdGENCj4gPiBub2Rlcyhjb250YWluZXIsbGlzdCxsZWFmLGxlYWYt
bGlzdCxhbnl4bWwsZXRjKS4NCj4gPg0KPiA+ICAgICAgICdkYXRhc3RvcmUnIHN0YXRlbWVudCBj
YW4gYmUgdXNlZCB0byBkZWZpbmUgYSBkYXRhIHN0b3JlIGJhc2VkIA0Kb24NCj4gPiBvbmUgZGF0
YXNldC4NCj4gPg0KPiA+ICAgICAgIGRhdGFzZXQgc3RhdGVtZW50J3Mgc3Vic3RhdGVtZW50cyBh
cmUgbGlzdGVkIGJlbG93Og0KPiA+DQo+ID4gc3Vic3RhdGVtZW50DQo+ID4gY2FyZGluYWxpdHkN
Cj4gPiBkZXNjcmlwdGlvbg0KPiA+IDAuLjENCj4gPiByZWZlcmVuY2UNCj4gPiAwLi4xDQo+ID4N
Cj4gPiAgICAgIGRhdGFzdG9yZSBzdGF0ZW1lbnQncyBzdWJzdGF0ZW1lbnRzIGFyZSBsaXN0ZWQg
YmVsb3c6DQo+ID4NCj4gPiBzdWJzdGF0ZW1lbnQNCj4gPiBjYXJkaW5hbGl0eQ0KPiA+IGJhc2UN
Cj4gPiAxDQo+ID4gZGVzY3JpcHRpb24NCj4gPiAwLi4xDQo+ID4gcmVmZXJlbmNlDQo+ID4gMC4u
MQ0KPiA+DQo+ID4gICAgICBUaGUgJ2Jhc2UnIHN0YXRlbWVudCBoYXMgYSBhcmd1bWVudCxpdHMg
dmFsdWUgaXMgYSBkZWZpbmVkIA0KZGF0YXNldCwNCj4gPiB0byBpbmRpY2F0ZSB3aGljaCBkYXRh
c2V0IHRoaXMgZGF0YXN0b3JlIGlzIGJhc2VkLg0KPiA+DQo+ID4gICAgICBGb3IgZXhhbXBsZToN
Cj4gPiAgICAgIGRhdGFzZXQgY29uZmlnIHsNCj4gPiAgICAgICAgIGRlc2NyaXB0aW9uICJ0aGUg
Y29uZmlndXJhdGlvbiBkYXRhc2V0IjsNCj4gPiAgICAgIH0NCj4gPg0KPiA+ICAgICAgZGF0YXN0
b3JlIHJ1bm5pbmcgew0KPiA+ICAgICAgICAgYmFzZSBjb25maWc7DQo+ID4gICAgICAgICBkZXNj
cmlwdGlvbiAicnVubmluZyBjb25maWd1cmF0aW9uIGRhdGEgc3RvcmUiOw0KPiA+ICAgICAgfQ0K
PiA+DQo+ID4gICAgICBkYXRhc2V0IGkycnMgew0KPiA+ICAgICAgICAgIGRlc2NyaXB0aW9uICJp
MnJzIGRhdGEgc2V0IjsNCj4gPiAgICAgIH0NCj4gPg0KPiA+ICAgICAgZGF0YXN0b3JlIGkycnMg
ew0KPiA+ICAgICAgICAgIGJhc2UgaTJyczsNCj4gPiAgICAgIH0NCj4gPg0KPiA+ICAgICAgY29u
dGFpbmVyIGZvbyB7DQo+ID4gICAgICAgICBiZWxvbmdzIGNvbmZpZzsNCj4gPiAgICAgICAgbGlz
dCBmb28tbGlzdCB7DQo+ID4gICAgICAgICAgICAgYmVsb25ncyBpMnJzOw0KPiA+ICAgICAgICAg
ICAgIGtleSBuYW1lOw0KPiA+ICAgICAgICAgICAgIGxlYWYgbmFtZSB7Li4ufQ0KPiA+ICAgICAg
ICAgICAgIGxlYWYgb3RoZXIgey4uLn0NCj4gPiAgICAgICAgfQ0KPiA+ICAgICAgfQ0KPiA+DQo+
ID4gL2ZyYW5rDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50
IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFs
IGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0K
PiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9z
dXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv
biBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv
aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFpURSBJ
bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g
dGhpcw0KPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlz
IHByaXZpbGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUg
ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChzKS4gIElmIHlvdSBhcmUgbm90IGFu
IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiByZXByb2R1Y3Rpb24sIGRp
c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgDQo+IGluZm9y
bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5
IHVzIGltbWVkaWF0ZWx5Lg0KPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0
Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K
PiANCj4gDQo+IC0tDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu
aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg
Q2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIw
MCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiANCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl
OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2ht
ZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwg
YW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMp
LiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg
cmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ug
b2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFu
ZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj
ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNo
bWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFs
IGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShz
KS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUs
IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNl
IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm
IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBh
bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K

--=_alternative 0020DDB248257CCE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQ
tNPaIDIwMTQtMDQtMzANCjIyOjE2OjQwOjxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZs
dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyAyMDE0LTA0LTMwIDIyOjE2PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7LA0KPGJyPg0KJmd0OyBmZW5nLmNob25nMzNAenRl
LmNvbS5jbiwgJnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRtb2RAaWV0Zi5vcmcm
Z3Q7LA0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg
s63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7INb3
zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTog
W25ldG1vZF0gWUFORzEuMSBpc3N1ZTphZGQgJ2RhdGFzZXQnIGFuZCAnZGF0YXN0b3JlJyBzdGF0
ZW1lbnRzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg
PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIFR1ZSwgQXBy
IDI5LCAyMDE0IGF0IDExOjAwIFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCiZsdDs8YnI+DQom
Z3Q7IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsgd3JvdGU6PC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEkgdGhpbmsgdGhlIGV4YW1wbGVzIHNo
b3cgYSBtaXNjb25jZXB0aW9uIGFib3V0DQpob3cgWUFORyB3b3JrcyBhbmQgYTxicj4NCiZndDsg
bGlrZWx5IHR5cGljYWwgbWlzdXNlIG9mIGEgbWVjaGFuaXNtIHRvIGRlZmluZSAnZGF0YXNldCdz
IGFuZDxicj4NCiZndDsgJ2RhdGFzdG9yZXMnLiBJIHRoaW5rIGl0IHdvdWxkIGJlIGEgbWlzdGFr
ZSB0byBkZXNpZ25hdGUgc2F5IGEgbGVhZjxicj4NCiZndDsgZGVmaW5pdGlvbiBhcyBiZWxvbmdp
bmcgdG8gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlIGluc3RlYWQgb2YgbWFya2luZw0KaXQ8YnI+DQom
Z3Q7IGFzIGEgY29uZmlnIG9iamVjdC48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBJIGRvIG5vdCB3YW50IFlBTkcgbW9kdWxlcyBkZWZpbmlu
ZyBkYXRhc3RvcmVzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGlz
IGNsYXNzaWZpY2F0aW9uIG5lZWRzIHRvIGJlIGhhcmQtd2lyZWQgYmVjYXVzZQ0KdGhlIHZhbGlk
YXRpb24gcnVsZXM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgYXJlIHNw
ZWNpZmljIHRvIHRoZSBkYXRhc3RvcmUuIEhvdyBkb2VzIGEgY2xpZW50DQprbm93IHRoZSB2YWxp
ZGF0aW9uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHJ1bGVzIGZvciB0
aGUgJnF1b3Q7YWNtZTpzcGVjaWFsLWRhdGFzdG9yZSZxdW90Oz88L2ZvbnQ+PC90dD4NCjxicj4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgdGhpbmsgaWYgYSBjbGllbnQgZG9uJ3Qga25vdyBhIHVz
ZXItZGVmaW5lZCBkYXRhc3RvcnMsDQppdCB3aWxsIGlnbm9yZSA8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPnRoZSBkYXRhIG5vZGUgdGFnZ2VkIHdpdGggZGF0YXNldCBiYXNlZCBi
eSB0aGlzIGRhdGFzdG9yZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PkZvciBleGFtcGxlLCAnZWRpdC1jb25maWcnIG9wZXJhdGlvbidzIHRhcmdldCBpcyBydW5uaW5n
L2NhbmRpZGF0ZSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmlmIGEgZGF0YSBu
b2RlIHRhZ2dlZCB3aXRoICZxdW90O2FjbWU6c3BlY2lhbC1kYXRhc3RvcmUmcXVvdDssDQp0aGlz
IGRhdGEgbm9kZSB3aWxsIGJlIGlnbm9yZWQgYnkgJ2VkaXQtY29uZmlnJy48L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPidlZGl0LWNvbmZpZycgb3BlcmF0aW9uIGNhbiBvbmx5IGVk
aXQgdGhlIGRhdGEgbm9kZQ0KdGFnZ2VkIHdpdGggJ2NvbmZpZycgZGF0YXNldC48L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFNvIGZhciwgd2UgZGlzdGluZ3Vpc2ggY29uZmlndXJh
dGlvbiBvYmplY3RzIGZyb20gb3BlcmF0aW9uYWwgc3RhdGU8YnI+DQomZ3Q7IG9iamVjdHMuIFdo
YXQgd2UgYXJlIG1pc3Npbmcgc2VlbXMgdG8gYmUgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW48YnI+
DQomZ3Q7IHJlYWQtb25seSBvcGVyYXRpb25hbCBzdGF0ZSBvYmplY3RzIGFuZCBvcGVyYXRpb25h
bCBzdGF0ZSBvYmplY3RzDQp0aGF0PGJyPg0KJmd0OyBjYW4gYmUgd3JpdHRlbi4gSSBtYXkgYmUg
dmVyeSB3cm9uZyB0byBhbGxvdyBkYXRhIG1vZGVsIHdyaXRlcnMgdG88YnI+DQomZ3Q7IGNvbWUg
dXAgd2l0aCBhcmJpdHJhcnkgc3VjaCBkaXN0aW5jdGlvbnMuPGJyPg0KPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgKzE8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBXZSBoYXZlIHJwYyArIGRhdGEgbm9kZXMg
KyBub3RpZmljYXRpb25zLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBU
aGUgJ2RhdGEgbm9kZXMnIHBpZWNlIGNvbnNpc3RzIG9mIGEgY29uZmlndXJhdGlvbg0KZGF0YXN0
b3JlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHBsdXMgc29tZSBjb25m
aWc9ZmFsc2Ugc3R1ZmYgdGhhdCBpcyBub3QgaW4gYQ0KY29uZmlndXJhdGlvbiBkYXRhc3RvcmUu
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFlBTkcgZG9lcyBub3QgZGVm
aW5lIGl0IGFueSBmdXJ0aGVyIHRoYW4gdGhhdC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBXZSBuZWVkIHRvIGRpdmlkZSB0aGUgY29uZmlnPWZhbHNl
IGJsb2IgaW50byBhdCBsZWFzdCAyIHBpZWNlczo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgJm5ic3A7IDEpIGVkaXRhYmxlIG9wZXJhdGlvbmFsIHN0YXRlPC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAyKSBub24tZWRpdGFibGUgb3Bl
cmF0aW9uYWwgc3RhdGUgYW5kDQpzdGF0aXN0aWNzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgWUFORyBkb2VzIG5vdCB0YWcgZGF0YSBhcyAnTkVUQ09O
Ricgb3IgJ0kyUlMnIGJ1dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBy
YXRoZXIganVzdCBpZGVudGlmaWVzIHRoZSBkYXRhIHByb3BlcnRpZXMuICZuYnNwO1RoZQ0KcHJv
dG9jb2wgdXNlZCB0bzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBlZGl0
IGRhdGEgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgWUFORyAoaWYgaXQNCmlzIGRlc2lnbmVkIGNv
cnJlY3RseSkuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDwvZm9udD48
L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSB0aGluayAmbmJzcDtkYXRhIG5vZGVz
IGRlZmluZWQgYnkgWUFORyBpcyBub3Qgc2ltcGx5DQombmJzcDtkaXZpZGVkICZuYnNwO2ludG8g
Y29uZmlnIGFuZCBub3QgY29uZmlnLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
V2UgaGF2ZSBubyB3YXkgdG8gZGVmaW5lIGFsbCBtZXRob2RzIGhvdyB0aGUgZGF0YQ0Kbm9kZXMg
aXMgZGl2aWRlZC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlNvLCB3
ZSBzaG91bGQgcHJvdmlkZSBhIHdheSAmbmJzcDtmb3IgdXNlciB0byBkZWZpbmUNCnRoZSBkb21h
aW4gd2hhdCBkYXRhIG5vZGVzIGJlbG9uZ3MgdG8uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj5Gb3IgZXhhbXBsZSwgTkVUQ09ORiBjYW4gZGVmaW5lIGNvbmZpZyBkYXRh
c2V0IGFuZA0Kc3RhdGUgZGF0YXNldCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PkkyUlMgY2FuIGRlZmluZSBpMnJzLWVkaXRhYmxlIGRhdGFzZXQgYW5kIGkycnMtcmVhZG9ubHkN
CmRhdGFzZXQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IElu
IG90aGVyIHdvcmRzLCBhIHByb3Bvc2FsIHRvIGludHJvZHVjZSBhIG1lY2hhbmlzbSB0byBpZGVu
dGlmeTxicj4NCiZndDsgd3JpdGFibGUgb3BlcmF0aW9uYWwgc3RhdGUgaXMgb25lIHRoaW5nIChp
ZiBpdCBjb21lcyBhbG9uZyB3aXRoIGE8YnI+DQomZ3Q7IGNsZWFyIHVuZGVyc3RhbmRpbmcgd2hh
dCB0aGUgaW1wYWN0IG9mIHRoaXMgaXMgb24gdGhlIHdob2xlPGJyPg0KJmd0OyBORVRDT05GL1lB
TkcgaW5mcmFzdHJ1Y3R1cmUpLiBCdXQgYSBwcm9wb3NhbCB0byB0byBhbGxvdyBhbiBvcGVuIGVu
ZGVkPGJyPg0KJmd0OyBzZXQgb2Ygb2JqZWN0IGNsYXNzZXMgYW5kIGRhdGFzdG9yZXMgc2VlbXMg
bm90IHZlcnkgdXNlZnVsLjxicj4NCiZndDsgPGJyPg0KJmd0OyAvanMgKHNwZWFraW5nIGFzIHRl
Y2huaWNhbCBjb250cmlidXRvcik8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgPGJyPg0KJmd0OyBBbmR5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBPbiBX
ZWQsIEFwciAzMCwgMjAxNCBhdCAwOToxMToyNUFNICswODAwLCBmZW5nLmNob25nMzNAenRlLmNv
bS5jbg0Kd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgSSBzdWdnZXN0IGFkZCAnZGF0YXNldCcgYW5kICdkYXRhc3RvcmUnDQpz
dGF0ZW1lbnRzIHRvIGlkZW50aWZ5IHdoaWNoPGJyPg0KJmd0OyAmZ3Q7IGRhdGFzZXQgYSBkYXRh
IG5vZGUgYmVsb25ncyB0by48YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWUFO
RyB1c2UgY29uZmlnIHN0YXRlbWVudCB0byBpZGVudGlmeSB3aGV0aGVyDQp0aGUgbm9kZSBiZWxv
bmdzdG88YnI+DQomZ3Q7ICZndDsgY29uZmlndXJhdGlvbiBkYXRhc2V0LCBidXQgaXQgaXMgbm90
IGV4dGVuc2libGUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IEZvciBleGFtcGxlLCBJMlJTIHdhbnQgdG8gZGVmaW5lIGl0cyBvd24NCmRhdGFzZXQs
IGJ1dCBZQU5HIGhhdmUgbm88YnI+DQomZ3Q7ICZndDsgc3ludGF4IHRvIGlkZW50aWZ5IHdoaWNo
IG5vZGUgYmVsb25ncyB0byBJMlJTIGRhdGFzZXQsPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IHVubGVzcyBJMlJTIGV4dGVuZCBpdHMgb3duIHlhbmcga2V5d29yZC48YnI+DQom
Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSB0aGluayB3ZSBz
aG91bGQgcHJvdmlkZSBhIHN0YW5kYXJkIHdheQ0KdG8gZGUgdGhpcy48YnI+DQomZ3Q7ICZndDs8
YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJ2RhdGFzZXQnIHN0YXRlbWVudCBj
YW4gYmUgdXNlZCB0byBkZWZpbmUNCmEgdXNlci1zcGVjaWZpYyBkYXRhc2V0Ljxicj4NCiZndDsg
Jmd0OyBhbmQgYSBuZXcgc3RhdGVtZW50ICdiZWxvbmdzJyBjYW4gYmUgdXNlZCB0byBpZGVudGlm
eSB3aGljaCBkYXRhc2V0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O3RoZSBkYXRhIG5vZGUgYmVsb25ncyB0bywgYXMgc3Vic3RhdGVtZW50DQpvZiBkYXRhPGJyPg0K
Jmd0OyAmZ3Q7IG5vZGVzKGNvbnRhaW5lcixsaXN0LGxlYWYsbGVhZi1saXN0LGFueXhtbCxldGMp
Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAnZGF0
YXN0b3JlJyBzdGF0ZW1lbnQgY2FuIGJlIHVzZWQgdG8gZGVmaW5lDQphIGRhdGEgc3RvcmUgYmFz
ZWQgb248YnI+DQomZ3Q7ICZndDsgb25lIGRhdGFzZXQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRhdGFzZXQgc3RhdGVtZW50J3Mgc3Vic3RhdGVt
ZW50cyBhcmUgbGlzdGVkDQpiZWxvdzo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgc3Vi
c3RhdGVtZW50PGJyPg0KJmd0OyAmZ3Q7IGNhcmRpbmFsaXR5PGJyPg0KJmd0OyAmZ3Q7IGRlc2Ny
aXB0aW9uPGJyPg0KJmd0OyAmZ3Q7IDAuLjE8YnI+DQomZ3Q7ICZndDsgcmVmZXJlbmNlPGJyPg0K
Jmd0OyAmZ3Q7IDAuLjE8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtkYXRhc3RvcmUgc3RhdGVtZW50J3Mgc3Vic3RhdGVtZW50cyBhcmUgbGlzdGVkDQpi
ZWxvdzo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgc3Vic3RhdGVtZW50PGJyPg0KJmd0
OyAmZ3Q7IGNhcmRpbmFsaXR5PGJyPg0KJmd0OyAmZ3Q7IGJhc2U8YnI+DQomZ3Q7ICZndDsgMTxi
cj4NCiZndDsgJmd0OyBkZXNjcmlwdGlvbjxicj4NCiZndDsgJmd0OyAwLi4xPGJyPg0KJmd0OyAm
Z3Q7IHJlZmVyZW5jZTxicj4NCiZndDsgJmd0OyAwLi4xPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlICdiYXNlJyBzdGF0ZW1lbnQgaGFzIGEgYXJn
dW1lbnQsaXRzIHZhbHVlDQppcyBhIGRlZmluZWQgZGF0YXNldCw8YnI+DQomZ3Q7ICZndDsgdG8g
aW5kaWNhdGUgd2hpY2ggZGF0YXNldCB0aGlzIGRhdGFzdG9yZSBpcyBiYXNlZC48YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGb3IgZXhhbXBsZTo8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhc2V0IGNvbmZpZyB7PGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDt0aGUg
Y29uZmlndXJhdGlvbg0KZGF0YXNldCZxdW90Ozs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDt9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ZGF0YXN0b3JlIHJ1bm5pbmcgezxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgYmFzZSBjb25maWc7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtydW5uaW5nIGNvbmZpZ3VyYXRpb24NCmRhdGEgc3Rv
cmUmcXVvdDs7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RhdGFzZXQgaTJycyB7PGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlv
biAmcXVvdDtpMnJzIGRhdGENCnNldCZxdW90Ozs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDt9PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ZGF0YXN0b3JlIGkycnMgezxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7YmFzZSBpMnJzOzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
O308YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250
YWluZXIgZm9vIHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJl
bG9uZ3MgY29uZmlnOzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDts
aXN0IGZvby1saXN0IHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgYmVsb25ncyBpMnJzOzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBrZXkgbmFtZTs8YnI+DQomZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGVhZiBuYW1lIHsuLi59PGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxl
YWYgb3RoZXIgey4uLn08YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
fTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDs8YnI+
DQomZ3Q7ICZndDsgL2ZyYW5rPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IFpURSBJbmZv
cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4NCnRo
aXM8YnI+DQomZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0
aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu
ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAocyku
ICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1
cmUsIDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2Vt
aW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlz
IHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkDQo8YnI+DQom
Z3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGlt
bWVkaWF0ZWx5Ljxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24g
U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzPGJyPg0K
Jmd0OyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHBy
aXZpbGVnZWQgYW5kIDxicj4NCiZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3Ig
dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAmbmJzcDtJ
ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCA8YnI+
DQomZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24g
b3IgdXNlIG9mIHRoZSA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3Rs
eSBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0OyB0aGlz
IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs
eS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJy
Pg0KJmd0OyAmZ3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD48
YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPjx0dD48
Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8
L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyAtLTxicj4NCiZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFjb2JzIFVuaXZlcnNpdHkNCkJyZW1lbiBnR21iSDxicj4N
CiZndDsgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IENhbXB1cyBSaW5nIDEsDQoyODc1OSBCcmVtZW4sIEdlcm1hbnk8YnI+DQomZ3Q7IEZheDogJm5i
c3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8L2Zv
bnQ+PC90dD48YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyI+PHR0Pjxm
b250IHNpemU9Mj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvZm9udD48L3R0Pjwv
YT48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldG1vZCBtYWls
aW5nIGxpc3Q8YnI+DQomZ3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+
PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZD48dHQ+
PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k
PC9mb250PjwvdHQ+PC9hPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu
Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0
aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp
dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2
ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl
Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90
aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg
c3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBl
cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2Zv
bnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y
bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz
IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmls
ZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1
c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw
aWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVy
IGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3Ry
aWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+
PC9wcmU+PGJyPg0K

--=_alternative 0020DDB248257CCE_=--


From nobody Sun May  4 00:41:19 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259AC1A0160 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 00:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ0jQGUbnjgq for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 00:40:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 040B01A015F for <netmod@ietf.org>; Sun,  4 May 2014 00:40:45 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1F28813F8CF; Sun,  4 May 2014 09:40:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399189240; bh=z5jT6f5YTDwP3BcSML6/fx3nEhbCMeXDR678L5TQPnk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nl3YrSJTPc5HcGj2VsmuBQCqCDMUqGJ5/naRqyQFVmjkz0HcKtp+9C4tt5oEjBj+p onYaD7yQ1wSoLEFMf2XxRV6Jz+PXFtepzFQWi0zx87WKZJekTVRisiGC87d61/ws8+ ++ZeaiZExzlDJp/f4yd3IEr38zP2mtCDiCuG0+x4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com>
Date: Sun, 4 May 2014 09:40:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz> <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BbAu5N6b1kBZTkH1wjjLk7Or2Es
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 07:40:48 -0000

On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>=20
> On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> > Hi,
> >
> > Problem:
> >
> > The use of a leaf in the data model (such as the =
/interfaces/interface/enabled
> > leaf in the ietf-interfaces module) does not account for YANG =
validation rules
> > for many statements that can reference the disabled subtree from =
outside
> > of that subtree:
> >
> >     - must
> >     - when
> >     - unique
> >     - min-elements
> >     - max-elements
> >     - leafref (valid instances)
> >     - choices (disabled case is still the active case, so no other =
can be used)
>=20
> In my view, an =93enabled false=94 leaf *operationally* disables a =
particular instance or function. For all other purposes related to =
datastore validation, the value of the enabled leaf doesn=92t matter. In =
other words, =93enabled false=94 is not the same as commenting out the =
corresponding instance in the configuration.
>=20
>=20
> OK -- they may be different, but the enabled leaf is ad-hoc,
> and YANG designers must know about this leaf.  Adding or removing
> this leaf could break other YANG statements.
>=20
> E,g,
>=20
>=20
>    leaf active-foo-interface {
>        type  if:interface-ref;
>        mandatory true;
>    }
>=20
>=20
> By YANG validation rules, the  leafref test for interface name
> will include all disabled interfaces.

Yes.

>=20
> Doesn't every object that uses the interface-ref typedef need
> to have a must-stmt making sure the enabled leaf is set,
> if they want to activate a service on only enabled interfaces?
>=20
> (Is this the must-stmt to use?)
>=20
>    leaf active-foo-interface {
>        type  if:interface-ref;
>        must "/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled";
>        mandatory true;
>    }
>=20
> Don't all must/when/leafref validation statements that want only
> active interfaces need to be written this way?

I don=92t think so. An operator may want to pre-configure an interface =
in the disabled state, set up all references to it etc., so that =
everything will be up and running after setting the single =93enabled=94 =
leaf to true.

Lada

>=20
> I agree this notion of "operationally disabled" is not the
> same as commenting out.  I don't think N/Y properly supports
> either one.
>=20
>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> >
> > The behavior for all of these statements needs to be clarified
> > when disabled nodes are involved.
> >
> > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > it is ad-hoc and used randomly. SMIv2 does not have any
> > validation statements that can be affected by a 'notInService' row,
> > so RowStatus is not broken in SNMP.
> >
> > Solution:
> >
> > YANG 1.1 must define a "metadata plane" that applies to
> > configuration datastores.  Global attributes that are specific
> > to configuration datastores (e.g. with-defaults) will be included
> > in the standard metadata library. It is expected that protocols
> > using YANG will define operations for reading and writing
> > global attributes.
> >
> > YANG 1.1 must define an "enabled" global attribute that must
> > be supported in all YANG 1.1 tools. The YANG validation rules
> > must be adjusted to properly account for disabled subtrees.
> >
> > Side issue: should 'enabled' leafs be removed when converting
> > a YANG 1.0 module to YANG 1.1?
> >
> >
> > Andy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sun May  4 01:33:37 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A981A0045 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 01:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj0kvEwiRKqD for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 01:33:11 -0700 (PDT)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEF21A0025 for <netmod@ietf.org>; Sun,  4 May 2014 01:33:10 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id i50so5064907qgf.17 for <netmod@ietf.org>; Sun, 04 May 2014 01:33:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x2FVoq2vNs4jxmJ0/WMuQUu5peZzbI0cfQJWYjGaw2Y=; b=HPIaqx00VP3JVYyfKg6WPG0XtgBKHip7snrg86ZQqVYr/OqlELdxX9Z5bzqL6yXPc2 3O0X1d7QZjqqyfzmdbDbwnpJLSAtzCjRu/gDMolYXu09ObarWmjJO4oMkihIjP/7nS4T y9fENWZbrcR5Owe+GB0KAjinOtWUBcLE/fgqoU3nRJ3dTfyvNX+LRelbduew/PQtbpWt vgLr6rfyn+ro9lJJj07DIzNfW8D84OMQCqLX3Hinpf5Oi/UVTOE9Yi4BpqUMHSjKVDK7 kal7aUtMOCwstg9ePWpDqafRfl+3rPiG4qbkN+pQ7nU0ubNCyYd1FqM8obcTvYXMLulC a0zw==
X-Gm-Message-State: ALoCoQkHcVArJtbMciKENRqihjsXu3d7YRSbZirTmHinP8TLXlY/C9ok01TlTZQ+DqgdCUohToFz
MIME-Version: 1.0
X-Received: by 10.229.17.69 with SMTP id r5mr35091981qca.7.1399192387825; Sun, 04 May 2014 01:33:07 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Sun, 4 May 2014 01:33:07 -0700 (PDT)
In-Reply-To: <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz> <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com> <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz>
Date: Sun, 4 May 2014 01:33:07 -0700
Message-ID: <CABCOCHQR_QvmV7QJbVoG+=F_xroU=XcAn3xDwOjfZ-jcR89WFg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a1133c9383fc82004f88eddda
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DtCwFhXfOQC_WwnJZr8FwdIsEMI
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 08:33:14 -0000

--001a1133c9383fc82004f88eddda
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > > Hi,
> > >
> > > Problem:
> > >
> > > The use of a leaf in the data model (such as the
> /interfaces/interface/enabled
> > > leaf in the ietf-interfaces module) does not account for YANG
> validation rules
> > > for many statements that can reference the disabled subtree from
> outside
> > > of that subtree:
> > >
> > >     - must
> > >     - when
> > >     - unique
> > >     - min-elements
> > >     - max-elements
> > >     - leafref (valid instances)
> > >     - choices (disabled case is still the active case, so no other can
> be used)
> >
> > In my view, an "enabled false" leaf *operationally* disables a
> particular instance or function. For all other purposes related to
> datastore validation, the value of the enabled leaf doesn't matter. In
> other words, "enabled false" is not the same as commenting out the
> corresponding instance in the configuration.
> >
> >
> > OK -- they may be different, but the enabled leaf is ad-hoc,
> > and YANG designers must know about this leaf.  Adding or removing
> > this leaf could break other YANG statements.
> >
> > E,g,
> >
> >
> >    leaf active-foo-interface {
> >        type  if:interface-ref;
> >        mandatory true;
> >    }
> >
> >
> > By YANG validation rules, the  leafref test for interface name
> > will include all disabled interfaces.
>
> Yes.
>
> >
> > Doesn't every object that uses the interface-ref typedef need
> > to have a must-stmt making sure the enabled leaf is set,
> > if they want to activate a service on only enabled interfaces?
> >
> > (Is this the must-stmt to use?)
> >
> >    leaf active-foo-interface {
> >        type  if:interface-ref;
> >        must "/if:interfaces/if:interface[if:name=current()]/enabled";
> >        mandatory true;
> >    }
> >
> > Don't all must/when/leafref validation statements that want only
> > active interfaces need to be written this way?
>
> I don't think so. An operator may want to pre-configure an interface in
> the disabled state, set up all references to it etc., so that everything
> will be up and running after setting the single "enabled" leaf to true.
>

I said "this is what has to be written to identity active interfaces"
and you respond "maybe they want to select disabled interfaces".
The complex must/when statements will be required to select
active interfaces.  In my example, the active-foo-interface MUST
be active. The foo service does not work when it is configured to
use a disabled interface.  I suspect very few services function correctly
using disabled interfaces.


> Lada
>


Andy


>
> >
> > I agree this notion of "operationally disabled" is not the
> > same as commenting out.  I don't think N/Y properly supports
> > either one.
> >
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > > The behavior for all of these statements needs to be clarified
> > > when disabled nodes are involved.
> > >
> > > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > > it is ad-hoc and used randomly. SMIv2 does not have any
> > > validation statements that can be affected by a 'notInService' row,
> > > so RowStatus is not broken in SNMP.
> > >
> > > Solution:
> > >
> > > YANG 1.1 must define a "metadata plane" that applies to
> > > configuration datastores.  Global attributes that are specific
> > > to configuration datastores (e.g. with-defaults) will be included
> > > in the standard metadata library. It is expected that protocols
> > > using YANG will define operations for reading and writing
> > > global attributes.
> > >
> > > YANG 1.1 must define an "enabled" global attribute that must
> > > be supported in all YANG 1.1 tools. The YANG validation rules
> > > must be adjusted to properly account for disabled subtrees.
> > >
> > > Side issue: should 'enabled' leafs be removed when converting
> > > a YANG 1.0 module to YANG 1.1?
> > >
> > >
> > > Andy
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a1133c9383fc82004f88eddda
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <span dir=3D"ltr">=
&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 03 May 2014, at 21:31, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka &lt;<a href=3D"mailto=
:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 03 May 2014, at 18:42, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; Problem:<br>
&gt; &gt;<br>
&gt; &gt; The use of a leaf in the data model (such as the /interfaces/inte=
rface/enabled<br>
&gt; &gt; leaf in the ietf-interfaces module) does not account for YANG val=
idation rules<br>
&gt; &gt; for many statements that can reference the disabled subtree from =
outside<br>
&gt; &gt; of that subtree:<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp; - must<br>
&gt; &gt; &nbsp; &nbsp; - when<br>
&gt; &gt; &nbsp; &nbsp; - unique<br>
&gt; &gt; &nbsp; &nbsp; - min-elements<br>
&gt; &gt; &nbsp; &nbsp; - max-elements<br>
&gt; &gt; &nbsp; &nbsp; - leafref (valid instances)<br>
&gt; &gt; &nbsp; &nbsp; - choices (disabled case is still the active case, =
so no other can be used)<br>
&gt;<br>
&gt; In my view, an &ldquo;enabled false&rdquo; leaf *operationally* disabl=
es a particular instance or function. For all other purposes related to dat=
astore validation, the value of the enabled leaf doesn&rsquo;t matter. In o=
ther words, &ldquo;enabled false&rdquo; is not the same as commenting out t=
he corresponding instance in the configuration.<br>

&gt;<br>
&gt;<br>
&gt; OK -- they may be different, but the enabled leaf is ad-hoc,<br>
&gt; and YANG designers must know about this leaf. &nbsp;Adding or removing=
<br>
&gt; this leaf could break other YANG statements.<br>
&gt;<br>
&gt; E,g,<br>
&gt;<br>
&gt;<br>
&gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:interface-ref;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &nbsp; &nbsp;}<br>
&gt;<br>
&gt;<br>
&gt; By YANG validation rules, the &nbsp;leafref test for interface name<br=
>
&gt; will include all disabled interfaces.<br>
<br>
Yes.<br>
<br>
&gt;<br>
&gt; Doesn&#39;t every object that uses the interface-ref typedef need<br>
&gt; to have a must-stmt making sure the enabled leaf is set,<br>
&gt; if they want to activate a service on only enabled interfaces?<br>
&gt;<br>
&gt; (Is this the must-stmt to use?)<br>
&gt;<br>
&gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:interface-ref;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if:interfaces/if:interface[if:n=
ame=3Dcurrent()]/enabled&quot;;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &nbsp; &nbsp;}<br>
&gt;<br>
&gt; Don&#39;t all must/when/leafref validation statements that want only<b=
r>
&gt; active interfaces need to be written this way?<br>
<br>
I don&rsquo;t think so. An operator may want to pre-configure an interface =
in the disabled state, set up all references to it etc., so that everything=
 will be up and running after setting the single &ldquo;enabled&rdquo; leaf=
 to true.<br>
</blockquote><div><br></div><div>I said &quot;this is what has to be writte=
n to identity active interfaces&quot;</div><div>and you respond &quot;maybe=
 they want to select disabled interfaces&quot;.</div><div>The complex must/=
when statements will be required to select</div>
<div>active interfaces. &nbsp;In my example, the active-foo-interface MUST<=
/div><div>be active. The foo service does not work when it is configured to=
</div><div>use a disabled interface. &nbsp;I suspect very few services func=
tion correctly</div>
<div>using disabled interfaces.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
Lada<br></blockquote><div><br></div><div><br></div><div>Andy</div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;<br>
&gt; I agree this notion of &quot;operationally disabled&quot; is not the<b=
r>
&gt; same as commenting out. &nbsp;I don&#39;t think N/Y properly supports<=
br>
&gt; either one.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; The behavior for all of these statements needs to be clarified<br=
>
&gt; &gt; when disabled nodes are involved.<br>
&gt; &gt;<br>
&gt; &gt; The &#39;enabled&#39; leaf is like SMIv2 RowStatus TC, except tha=
t<br>
&gt; &gt; it is ad-hoc and used randomly. SMIv2 does not have any<br>
&gt; &gt; validation statements that can be affected by a &#39;notInService=
&#39; row,<br>
&gt; &gt; so RowStatus is not broken in SNMP.<br>
&gt; &gt;<br>
&gt; &gt; Solution:<br>
&gt; &gt;<br>
&gt; &gt; YANG 1.1 must define a &quot;metadata plane&quot; that applies to=
<br>
&gt; &gt; configuration datastores. &nbsp;Global attributes that are specif=
ic<br>
&gt; &gt; to configuration datastores (e.g. with-defaults) will be included=
<br>
&gt; &gt; in the standard metadata library. It is expected that protocols<b=
r>
&gt; &gt; using YANG will define operations for reading and writing<br>
&gt; &gt; global attributes.<br>
&gt; &gt;<br>
&gt; &gt; YANG 1.1 must define an &quot;enabled&quot; global attribute that=
 must<br>
&gt; &gt; be supported in all YANG 1.1 tools. The YANG validation rules<br>
&gt; &gt; must be adjusted to properly account for disabled subtrees.<br>
&gt; &gt;<br>
&gt; &gt; Side issue: should &#39;enabled&#39; leafs be removed when conver=
ting<br>
&gt; &gt; a YANG 1.0 module to YANG 1.1?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; netmod mailing list<br>
&gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a1133c9383fc82004f88eddda--


From nobody Sun May  4 02:45:14 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9D1A004D for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 02:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn569An-wAED for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 02:45:11 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D457E1A004C for <netmod@ietf.org>; Sun,  4 May 2014 02:45:10 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6ADBE13F8CF; Sun,  4 May 2014 11:45:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399196707; bh=mhhTLJOBS/rudtdCwFnvJsCnjkR1GiqJfA8yuwSEDpY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rUj327/TzdNiEduSY6IU/TuoYgMamt15eeNh/y1YpwdWXRy5geKmnj5fil+oNmLsT ARs0gJdlmem+/eE3FFjhusQF3fyek2AMQgGU/H9v37xiNCycwFo7Qdq8giXFgRieYE vOPSTALLSqYeOchPqqDoL+6lzWwk5qxsqwMn5Qdk=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHQR_QvmV7QJbVoG+=F_xroU=XcAn3xDwOjfZ-jcR89WFg@mail.gmail.com>
Date: Sun, 4 May 2014 11:45:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz> <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com> <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz> <CABCOCHQR_QvmV7QJbVoG+=F_xroU=XcAn3xDwOjfZ-jcR89WFg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Afy0raMczFeVLFXxUxWpb1rzoBA
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 09:45:13 -0000

On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>=20
> On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> >
> > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > > Hi,
> > >
> > > Problem:
> > >
> > > The use of a leaf in the data model (such as the =
/interfaces/interface/enabled
> > > leaf in the ietf-interfaces module) does not account for YANG =
validation rules
> > > for many statements that can reference the disabled subtree from =
outside
> > > of that subtree:
> > >
> > >     - must
> > >     - when
> > >     - unique
> > >     - min-elements
> > >     - max-elements
> > >     - leafref (valid instances)
> > >     - choices (disabled case is still the active case, so no other =
can be used)
> >
> > In my view, an =93enabled false=94 leaf *operationally* disables a =
particular instance or function. For all other purposes related to =
datastore validation, the value of the enabled leaf doesn=92t matter. In =
other words, =93enabled false=94 is not the same as commenting out the =
corresponding instance in the configuration.
> >
> >
> > OK -- they may be different, but the enabled leaf is ad-hoc,
> > and YANG designers must know about this leaf.  Adding or removing
> > this leaf could break other YANG statements.
> >
> > E,g,
> >
> >
> >    leaf active-foo-interface {
> >        type  if:interface-ref;
> >        mandatory true;
> >    }
> >
> >
> > By YANG validation rules, the  leafref test for interface name
> > will include all disabled interfaces.
>=20
> Yes.
>=20
> >
> > Doesn't every object that uses the interface-ref typedef need
> > to have a must-stmt making sure the enabled leaf is set,
> > if they want to activate a service on only enabled interfaces?
> >
> > (Is this the must-stmt to use?)
> >
> >    leaf active-foo-interface {
> >        type  if:interface-ref;
> >        must =
"/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled";
> >        mandatory true;
> >    }
> >
> > Don't all must/when/leafref validation statements that want only
> > active interfaces need to be written this way?
>=20
> I don=92t think so. An operator may want to pre-configure an interface =
in the disabled state, set up all references to it etc., so that =
everything will be up and running after setting the single =93enabled=94 =
leaf to true.
>=20
> I said "this is what has to be written to identity active interfaces"
> and you respond "maybe they want to select disabled interfaces=94.

It=92s up to the server to interpret the entire configuration, so if a =
service is enabled in configuration but it depends on an interface that =
is currently disabled, the server might keep that service operationally =
disabled as well.

Section 6 in the routing draft deals with exactly these interactions.

If this situation has to be avoided for some reason, then yes, a =93must=94=
 statement can be used to enforce, e.g., that a leafref only refers to =
an enabled interface. I don=92t see it as a problem though.

I think it is OK that the =93enabled=94 leafs are ad hoc because their =
semantics may be specific, too.

That said, I am not against introducing the =93inactive=94 attribute =
but, as I understand it, its meaning will be different.

> The complex must/when statements will be required to select
> active interfaces.  In my example, the active-foo-interface MUST
> be active. The foo service does not work when it is configured to
> use a disabled interface.  I suspect very few services function =
correctly
> using disabled interfaces.

My point is that even if a service looks like being enabled in =
configuration, it may not be the case because some dependencies are not =
met - and this can be anticipated, as in the routing data model.

Lada=20

>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
>=20
> >
> > I agree this notion of "operationally disabled" is not the
> > same as commenting out.  I don't think N/Y properly supports
> > either one.
> >
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > > The behavior for all of these statements needs to be clarified
> > > when disabled nodes are involved.
> > >
> > > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > > it is ad-hoc and used randomly. SMIv2 does not have any
> > > validation statements that can be affected by a 'notInService' =
row,
> > > so RowStatus is not broken in SNMP.
> > >
> > > Solution:
> > >
> > > YANG 1.1 must define a "metadata plane" that applies to
> > > configuration datastores.  Global attributes that are specific
> > > to configuration datastores (e.g. with-defaults) will be included
> > > in the standard metadata library. It is expected that protocols
> > > using YANG will define operations for reading and writing
> > > global attributes.
> > >
> > > YANG 1.1 must define an "enabled" global attribute that must
> > > be supported in all YANG 1.1 tools. The YANG validation rules
> > > must be adjusted to properly account for disabled subtrees.
> > >
> > > Side issue: should 'enabled' leafs be removed when converting
> > > a YANG 1.0 module to YANG 1.1?
> > >
> > >
> > > Andy
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sun May  4 07:11:41 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0A1A0099 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 07:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6di2Hl4w37iu for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 07:11:35 -0700 (PDT)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by ietfa.amsl.com (Postfix) with ESMTP id 349391A0096 for <netmod@ietf.org>; Sun,  4 May 2014 07:11:35 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id i50so5351037qgf.3 for <netmod@ietf.org>; Sun, 04 May 2014 07:11:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NaTJJ34VYhCt4VC0pK/RDgdtQDT/DC+wjpIJKOG1f8Y=; b=NvcVsI27SaxcaV2egIP1kbAYSk8fZQCgOA0C9j3WLktfxW2p5b5uGa/Va1OrufeEdo opqth8cTnZed21WUiG78/qM/bzZa5kUKrv72NyRqB5AK3qzmBhP6DikaEfy2XKnWPxol OAYgduOdS0tVSU1vVS9I1N+sL0kcrpQt6hhRuYoj7FeUcCyLwQAgZLCgN9bYJjk5W4uR kiPWWm2S4l18SAyI02yMAZN1F8cgbYXiYO7+I0urtKe5GGmg5GI37cW5JpZQOwnsrUsO g9Y7LZJU3iFjXGz7I0t5BvVPm9V1+ueMzHeS5+VlVjmwryEg4mmAoevko1OuQYUrdwne V8xQ==
X-Gm-Message-State: ALoCoQne33JSXEtDFNe1XStBp/bIhO8Svodcn49TPuz7IB8UxtXs53V/tDctbMnZD4xMRrG7ff1P
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr9944343qgo.25.1399212691954; Sun, 04 May 2014 07:11:31 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Sun, 4 May 2014 07:11:31 -0700 (PDT)
In-Reply-To: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz> <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com> <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz> <CABCOCHQR_QvmV7QJbVoG+=F_xroU=XcAn3xDwOjfZ-jcR89WFg@mail.gmail.com> <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz>
Date: Sun, 4 May 2014 07:11:31 -0700
Message-ID: <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c173347833fe04f8939723
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iLmFxAnMgkUH7LMPegObzM_txHw
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 14:11:39 -0000

--001a11c173347833fe04f8939723
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > >
> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Problem:
> > > >
> > > > The use of a leaf in the data model (such as the
> /interfaces/interface/enabled
> > > > leaf in the ietf-interfaces module) does not account for YANG
> validation rules
> > > > for many statements that can reference the disabled subtree from
> outside
> > > > of that subtree:
> > > >
> > > >     - must
> > > >     - when
> > > >     - unique
> > > >     - min-elements
> > > >     - max-elements
> > > >     - leafref (valid instances)
> > > >     - choices (disabled case is still the active case, so no other
> can be used)
> > >
> > > In my view, an "enabled false" leaf *operationally* disables a
> particular instance or function. For all other purposes related to
> datastore validation, the value of the enabled leaf doesn't matter. In
> other words, "enabled false" is not the same as commenting out the
> corresponding instance in the configuration.
> > >
> > >
> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > and YANG designers must know about this leaf.  Adding or removing
> > > this leaf could break other YANG statements.
> > >
> > > E,g,
> > >
> > >
> > >    leaf active-foo-interface {
> > >        type  if:interface-ref;
> > >        mandatory true;
> > >    }
> > >
> > >
> > > By YANG validation rules, the  leafref test for interface name
> > > will include all disabled interfaces.
> >
> > Yes.
> >
> > >
> > > Doesn't every object that uses the interface-ref typedef need
> > > to have a must-stmt making sure the enabled leaf is set,
> > > if they want to activate a service on only enabled interfaces?
> > >
> > > (Is this the must-stmt to use?)
> > >
> > >    leaf active-foo-interface {
> > >        type  if:interface-ref;
> > >        must "/if:interfaces/if:interface[if:name=current()]/enabled";
> > >        mandatory true;
> > >    }
> > >
> > > Don't all must/when/leafref validation statements that want only
> > > active interfaces need to be written this way?
> >
> > I don't think so. An operator may want to pre-configure an interface in
> the disabled state, set up all references to it etc., so that everything
> will be up and running after setting the single "enabled" leaf to true.
> >
> > I said "this is what has to be written to identity active interfaces"
> > and you respond "maybe they want to select disabled interfaces".
>
> It's up to the server to interpret the entire configuration, so if a
> service is enabled in configuration but it depends on an interface that is
> currently disabled, the server might keep that service operationally
> disabled as well.
>
>
Not if the YANG validation rules say differently.
My point is that the YANG designer must write all validation rules to
account for disabled configuration, or the model is wrong.


Section 6 in the routing draft deals with exactly these interactions.
>
> If this situation has to be avoided for some reason, then yes, a "must"
> statement can be used to enforce, e.g., that a leafref only refers to an
> enabled interface. I don't see it as a problem though.
>
> I think it is OK that the "enabled" leafs are ad hoc because their
> semantics may be specific, too.
>
>
So some enabled leafs will be default true, some default false,
some mandatory with no default.  Some will have special corner-cases
that cause partial operation.  Some will have extra enabled leafs that
change the meaning of the original enabled leaf.

Sounds great if you are trying to create a fragile, ad-hoc, hand-coded
system.
Not so great if you are trying to use YANG to bring consistency and
automation
into the system.


That said, I am not against introducing the "inactive" attribute but, as I
> understand it, its meaning will be different.
>
> > The complex must/when statements will be required to select
> > active interfaces.  In my example, the active-foo-interface MUST
> > be active. The foo service does not work when it is configured to
> > use a disabled interface.  I suspect very few services function correctly
> > using disabled interfaces.
>
> My point is that even if a service looks like being enabled in
> configuration, it may not be the case because some dependencies are not met
> - and this can be anticipated, as in the routing data model.
>
>
The system will have to be designed to account for all these ad-hoc on/off
switches.
IMO hindsight will show that a completely free-form solution path was not a
good idea.


Lada
>

Andy


>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > I agree this notion of "operationally disabled" is not the
> > > same as commenting out.  I don't think N/Y properly supports
> > > either one.
> > >
> > >
> > >
> > > Lada
> > >
> > > Andy
> > >
> > >
> > > >
> > > > The behavior for all of these statements needs to be clarified
> > > > when disabled nodes are involved.
> > > >
> > > > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > > > it is ad-hoc and used randomly. SMIv2 does not have any
> > > > validation statements that can be affected by a 'notInService' row,
> > > > so RowStatus is not broken in SNMP.
> > > >
> > > > Solution:
> > > >
> > > > YANG 1.1 must define a "metadata plane" that applies to
> > > > configuration datastores.  Global attributes that are specific
> > > > to configuration datastores (e.g. with-defaults) will be included
> > > > in the standard metadata library. It is expected that protocols
> > > > using YANG will define operations for reading and writing
> > > > global attributes.
> > > >
> > > > YANG 1.1 must define an "enabled" global attribute that must
> > > > be supported in all YANG 1.1 tools. The YANG validation rules
> > > > must be adjusted to properly account for disabled subtrees.
> > > >
> > > > Side issue: should 'enabled' leafs be removed when converting
> > > > a YANG 1.0 module to YANG 1.1?
> > > >
> > > >
> > > > Andy
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c173347833fe04f8939723
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 04 May 2014, at 10:33, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka &lt;<a href=3D"mailto=
:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 03 May 2014, at 21:31, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka &lt;<a href=3D"m=
ailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On 03 May 2014, at 18:42, Andy Bierman &lt;<a href=3D"mailto:andy=
@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Problem:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The use of a leaf in the data model (such as the /interfaces=
/interface/enabled<br>
&gt; &gt; &gt; leaf in the ietf-interfaces module) does not account for YAN=
G validation rules<br>
&gt; &gt; &gt; for many statements that can reference the disabled subtree =
from outside<br>
&gt; &gt; &gt; of that subtree:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; - must<br>
&gt; &gt; &gt; &nbsp; &nbsp; - when<br>
&gt; &gt; &gt; &nbsp; &nbsp; - unique<br>
&gt; &gt; &gt; &nbsp; &nbsp; - min-elements<br>
&gt; &gt; &gt; &nbsp; &nbsp; - max-elements<br>
&gt; &gt; &gt; &nbsp; &nbsp; - leafref (valid instances)<br>
&gt; &gt; &gt; &nbsp; &nbsp; - choices (disabled case is still the active c=
ase, so no other can be used)<br>
&gt; &gt;<br>
&gt; &gt; In my view, an &ldquo;enabled false&rdquo; leaf *operationally* d=
isables a particular instance or function. For all other purposes related t=
o datastore validation, the value of the enabled leaf doesn&rsquo;t matter.=
 In other words, &ldquo;enabled false&rdquo; is not the same as commenting =
out the corresponding instance in the configuration.<br>

&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; OK -- they may be different, but the enabled leaf is ad-hoc,<br>
&gt; &gt; and YANG designers must know about this leaf. &nbsp;Adding or rem=
oving<br>
&gt; &gt; this leaf could break other YANG statements.<br>
&gt; &gt;<br>
&gt; &gt; E,g,<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:interface-ref;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; By YANG validation rules, the &nbsp;leafref test for interface na=
me<br>
&gt; &gt; will include all disabled interfaces.<br>
&gt;<br>
&gt; Yes.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Doesn&#39;t every object that uses the interface-ref typedef need=
<br>
&gt; &gt; to have a must-stmt making sure the enabled leaf is set,<br>
&gt; &gt; if they want to activate a service on only enabled interfaces?<br=
>
&gt; &gt;<br>
&gt; &gt; (Is this the must-stmt to use?)<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:interface-ref;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if:interfaces/if:interface=
[if:name=3Dcurrent()]/enabled&quot;;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt;<br>
&gt; &gt; Don&#39;t all must/when/leafref validation statements that want o=
nly<br>
&gt; &gt; active interfaces need to be written this way?<br>
&gt;<br>
&gt; I don&rsquo;t think so. An operator may want to pre-configure an inter=
face in the disabled state, set up all references to it etc., so that every=
thing will be up and running after setting the single &ldquo;enabled&rdquo;=
 leaf to true.<br>

&gt;<br>
&gt; I said &quot;this is what has to be written to identity active interfa=
ces&quot;<br>
&gt; and you respond &quot;maybe they want to select disabled interfaces&rd=
quo;.<br>
<br>
It&rsquo;s up to the server to interpret the entire configuration, so if a =
service is enabled in configuration but it depends on an interface that is =
currently disabled, the server might keep that service operationally disabl=
ed as well.<br>

<br></blockquote><div><br></div><div>Not if the YANG validation rules say d=
ifferently.</div><div>My point is that the YANG designer must write all val=
idation rules to</div><div>account for disabled configuration, or the model=
 is wrong.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Section 6 in the routing draft deals with exactly these interactions.<br>
<br>
If this situation has to be avoided for some reason, then yes, a &ldquo;mus=
t&rdquo; statement can be used to enforce, e.g., that a leafref only refers=
 to an enabled interface. I don&rsquo;t see it as a problem though.<br>
<br>
I think it is OK that the &ldquo;enabled&rdquo; leafs are ad hoc because th=
eir semantics may be specific, too.<br>
<br></blockquote><div><br></div><div>So some enabled leafs will be default =
true, some default false,</div><div>some mandatory with no default. &nbsp;S=
ome will have special corner-cases</div><div>that cause partial operation. =
&nbsp;Some will have extra enabled leafs that</div>
<div>change the meaning of the original enabled leaf.</div><div><br></div><=
div>Sounds great if you are trying to create a fragile, ad-hoc, hand-coded =
system.</div><div>Not so great if you are trying to use YANG to bring consi=
stency and automation</div>
<div>into the system.</div><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
That said, I am not against introducing the &ldquo;inactive&rdquo; attribut=
e but, as I understand it, its meaning will be different.<br>
<br>
&gt; The complex must/when statements will be required to select<br>
&gt; active interfaces. &nbsp;In my example, the active-foo-interface MUST<=
br>
&gt; be active. The foo service does not work when it is configured to<br>
&gt; use a disabled interface. &nbsp;I suspect very few services function c=
orrectly<br>
&gt; using disabled interfaces.<br>
<br>
My point is that even if a service looks like being enabled in configuratio=
n, it may not be the case because some dependencies are not met - and this =
can be anticipated, as in the routing data model.<br>
<br></blockquote><div><br></div><div>The system will have to be designed to=
 account for all these ad-hoc on/off switches.</div><div>IMO hindsight will=
 show that a completely free-form solution path was not a good idea.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lada<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; I agree this notion of &quot;operationally disabled&quot; is not =
the<br>
&gt; &gt; same as commenting out. &nbsp;I don&#39;t think N/Y properly supp=
orts<br>
&gt; &gt; either one.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Lada<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The behavior for all of these statements needs to be clarifi=
ed<br>
&gt; &gt; &gt; when disabled nodes are involved.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The &#39;enabled&#39; leaf is like SMIv2 RowStatus TC, excep=
t that<br>
&gt; &gt; &gt; it is ad-hoc and used randomly. SMIv2 does not have any<br>
&gt; &gt; &gt; validation statements that can be affected by a &#39;notInSe=
rvice&#39; row,<br>
&gt; &gt; &gt; so RowStatus is not broken in SNMP.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Solution:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; YANG 1.1 must define a &quot;metadata plane&quot; that appli=
es to<br>
&gt; &gt; &gt; configuration datastores. &nbsp;Global attributes that are s=
pecific<br>
&gt; &gt; &gt; to configuration datastores (e.g. with-defaults) will be inc=
luded<br>
&gt; &gt; &gt; in the standard metadata library. It is expected that protoc=
ols<br>
&gt; &gt; &gt; using YANG will define operations for reading and writing<br=
>
&gt; &gt; &gt; global attributes.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; YANG 1.1 must define an &quot;enabled&quot; global attribute=
 that must<br>
&gt; &gt; &gt; be supported in all YANG 1.1 tools. The YANG validation rule=
s<br>
&gt; &gt; &gt; must be adjusted to properly account for disabled subtrees.<=
br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Side issue: should &#39;enabled&#39; leafs be removed when c=
onverting<br>
&gt; &gt; &gt; a YANG 1.0 module to YANG 1.1?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Andy<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; netmod mailing list<br>
&gt; &gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; &gt; PGP Key ID: E74E8C0C<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c173347833fe04f8939723--


From nobody Sun May  4 10:17:04 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03371A00D5 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 10:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7HCG6g5Ricb for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 10:17:00 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id D9B621A0179 for <netmod@ietf.org>; Sun,  4 May 2014 10:16:59 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id a108so222379qge.22 for <netmod@ietf.org>; Sun, 04 May 2014 10:16:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AU5P9tN+OARDRIHE2/ySf8EHcqy62p9F4LI5U9UKhfA=; b=iUXuJ5Wp/o0DDwoxG9LEB6LAvoXHJSO1daz9b/5Exv6a6BRQ+frANg+5JDTlwu/38d +QbkT2FgUO4FXGNVNcCpTzy9pAWVIvSs2aCbNrQoeYRrK4G0zSu5jb0CKS4jCJxxz0av GkBO70V6jVn54WF5cqcgfdB6y5GJ6cKzVhuwf4LbpgUlqZ1GKLv407w2PeWMz+nADQ+u ZynMNkL4gpRbQU8SdOIVKilQMDpJ9lSUSChHgHMQZBTP0BnGKVv14uRjOobq8V11uslc GrXYamXcUoe6nBcdePTL/lZA93zpoNW1+FaErOSL2JZG+Ra5SApg4sjbfwCLxTYEFFKu 94tA==
X-Gm-Message-State: ALoCoQnRv5/GyU4XjGtDup57R3yKDUDh0JbFIeyfpJaj3A7B5VmIHRz7zJ0bql++sPYaa1qMcvr5
MIME-Version: 1.0
X-Received: by 10.140.27.212 with SMTP id 78mr35872847qgx.18.1399223816640; Sun, 04 May 2014 10:16:56 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Sun, 4 May 2014 10:16:56 -0700 (PDT)
In-Reply-To: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz> <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com> <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz> <CABCOCHQR_QvmV7QJbVoG+=F_xroU=XcAn3xDwOjfZ-jcR89WFg@mail.gmail.com> <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz>
Date: Sun, 4 May 2014 10:16:56 -0700
Message-ID: <CABCOCHRve4=mcxoADFzwDiWo-3S35pvFSqjKE65ArPbMcn0LnQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c14d668d6fa204f8962e8c
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/S_fQs0A3WG1yAKVybieWLFJgRpQ
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 17:17:03 -0000

--001a11c14d668d6fa204f8962e8c
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > >
> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > Problem:
> > > >
> > > > The use of a leaf in the data model (such as the
> /interfaces/interface/enabled
> > > > leaf in the ietf-interfaces module) does not account for YANG
> validation rules
> > > > for many statements that can reference the disabled subtree from
> outside
> > > > of that subtree:
> > > >
> > > >     - must
> > > >     - when
> > > >     - unique
> > > >     - min-elements
> > > >     - max-elements
> > > >     - leafref (valid instances)
> > > >     - choices (disabled case is still the active case, so no other
> can be used)
> > >
> > > In my view, an "enabled false" leaf *operationally* disables a
> particular instance or function. For all other purposes related to
> datastore validation, the value of the enabled leaf doesn't matter. In
> other words, "enabled false" is not the same as commenting out the
> corresponding instance in the configuration.
> > >
> > >
> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > and YANG designers must know about this leaf.  Adding or removing
> > > this leaf could break other YANG statements.
> > >
> > > E,g,
> > >
> > >
> > >    leaf active-foo-interface {
> > >        type  if:interface-ref;
> > >        mandatory true;
> > >    }
> > >
> > >
> > > By YANG validation rules, the  leafref test for interface name
> > > will include all disabled interfaces.
> >
> > Yes.
> >
> > >
> > > Doesn't every object that uses the interface-ref typedef need
> > > to have a must-stmt making sure the enabled leaf is set,
> > > if they want to activate a service on only enabled interfaces?
> > >
> > > (Is this the must-stmt to use?)
> > >
> > >    leaf active-foo-interface {
> > >        type  if:interface-ref;
> > >        must "/if:interfaces/if:interface[if:name=current()]/enabled";
> > >        mandatory true;
> > >    }
> > >
> > > Don't all must/when/leafref validation statements that want only
> > > active interfaces need to be written this way?
> >
> > I don't think so. An operator may want to pre-configure an interface in
> the disabled state, set up all references to it etc., so that everything
> will be up and running after setting the single "enabled" leaf to true.
> >
> > I said "this is what has to be written to identity active interfaces"
> > and you respond "maybe they want to select disabled interfaces".
>
> It's up to the server to interpret the entire configuration, so if a
> service is enabled in configuration but it depends on an interface that is
> currently disabled, the server might keep that service operationally
> disabled as well.
>
> Section 6 in the routing draft deals with exactly these interactions.
>
> If this situation has to be avoided for some reason, then yes, a "must"
> statement can be used to enforce, e.g., that a leafref only refers to an
> enabled interface. I don't see it as a problem though.
>
> I think it is OK that the "enabled" leafs are ad hoc because their
> semantics may be specific, too.
>
>

This is the part I really don't like.
These mechanisms should not be ad-hoc and different for every module.
There should be a standard way to operationally enable/disable config
and a standard way to comment/uncomment config.

IMO, we are making a big mistake by not standardizing a solution like the
xpath1.0
typedef in ietf-yang-types.yang.  If there was a reusable type for this
leaf, then tools
could use that to identify the design pattern and handle the enable/disable
edits
within the validation engine and the system instrumentation.

Sometimes following the CLI too closely leads to bad API decisions


Andy



> That said, I am not against introducing the "inactive" attribute but, as I
> understand it, its meaning will be different.
>
> > The complex must/when statements will be required to select
> > active interfaces.  In my example, the active-foo-interface MUST
> > be active. The foo service does not work when it is configured to
> > use a disabled interface.  I suspect very few services function correctly
> > using disabled interfaces.
>
> My point is that even if a service looks like being enabled in
> configuration, it may not be the case because some dependencies are not met
> - and this can be anticipated, as in the routing data model.
>
> Lada
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > I agree this notion of "operationally disabled" is not the
> > > same as commenting out.  I don't think N/Y properly supports
> > > either one.
> > >
> > >
> > >
> > > Lada
> > >
> > > Andy
> > >
> > >
> > > >
> > > > The behavior for all of these statements needs to be clarified
> > > > when disabled nodes are involved.
> > > >
> > > > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > > > it is ad-hoc and used randomly. SMIv2 does not have any
> > > > validation statements that can be affected by a 'notInService' row,
> > > > so RowStatus is not broken in SNMP.
> > > >
> > > > Solution:
> > > >
> > > > YANG 1.1 must define a "metadata plane" that applies to
> > > > configuration datastores.  Global attributes that are specific
> > > > to configuration datastores (e.g. with-defaults) will be included
> > > > in the standard metadata library. It is expected that protocols
> > > > using YANG will define operations for reading and writing
> > > > global attributes.
> > > >
> > > > YANG 1.1 must define an "enabled" global attribute that must
> > > > be supported in all YANG 1.1 tools. The YANG validation rules
> > > > must be adjusted to properly account for disabled subtrees.
> > > >
> > > > Side issue: should 'enabled' leafs be removed when converting
> > > > a YANG 1.0 module to YANG 1.1?
> > > >
> > > >
> > > > Andy
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c14d668d6fa204f8962e8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 04 May 2014, at 10:33, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka &lt;<a href=3D"mailto=
:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 03 May 2014, at 21:31, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka &lt;<a href=3D"m=
ailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On 03 May 2014, at 18:42, Andy Bierman &lt;<a href=3D"mailto:andy=
@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Problem:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The use of a leaf in the data model (such as the /interfaces=
/interface/enabled<br>
&gt; &gt; &gt; leaf in the ietf-interfaces module) does not account for YAN=
G validation rules<br>
&gt; &gt; &gt; for many statements that can reference the disabled subtree =
from outside<br>
&gt; &gt; &gt; of that subtree:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; - must<br>
&gt; &gt; &gt; &nbsp; &nbsp; - when<br>
&gt; &gt; &gt; &nbsp; &nbsp; - unique<br>
&gt; &gt; &gt; &nbsp; &nbsp; - min-elements<br>
&gt; &gt; &gt; &nbsp; &nbsp; - max-elements<br>
&gt; &gt; &gt; &nbsp; &nbsp; - leafref (valid instances)<br>
&gt; &gt; &gt; &nbsp; &nbsp; - choices (disabled case is still the active c=
ase, so no other can be used)<br>
&gt; &gt;<br>
&gt; &gt; In my view, an &ldquo;enabled false&rdquo; leaf *operationally* d=
isables a particular instance or function. For all other purposes related t=
o datastore validation, the value of the enabled leaf doesn&rsquo;t matter.=
 In other words, &ldquo;enabled false&rdquo; is not the same as commenting =
out the corresponding instance in the configuration.<br>

&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; OK -- they may be different, but the enabled leaf is ad-hoc,<br>
&gt; &gt; and YANG designers must know about this leaf. &nbsp;Adding or rem=
oving<br>
&gt; &gt; this leaf could break other YANG statements.<br>
&gt; &gt;<br>
&gt; &gt; E,g,<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:interface-ref;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; By YANG validation rules, the &nbsp;leafref test for interface na=
me<br>
&gt; &gt; will include all disabled interfaces.<br>
&gt;<br>
&gt; Yes.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Doesn&#39;t every object that uses the interface-ref typedef need=
<br>
&gt; &gt; to have a must-stmt making sure the enabled leaf is set,<br>
&gt; &gt; if they want to activate a service on only enabled interfaces?<br=
>
&gt; &gt;<br>
&gt; &gt; (Is this the must-stmt to use?)<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:interface-ref;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if:interfaces/if:interface=
[if:name=3Dcurrent()]/enabled&quot;;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt;<br>
&gt; &gt; Don&#39;t all must/when/leafref validation statements that want o=
nly<br>
&gt; &gt; active interfaces need to be written this way?<br>
&gt;<br>
&gt; I don&rsquo;t think so. An operator may want to pre-configure an inter=
face in the disabled state, set up all references to it etc., so that every=
thing will be up and running after setting the single &ldquo;enabled&rdquo;=
 leaf to true.<br>

&gt;<br>
&gt; I said &quot;this is what has to be written to identity active interfa=
ces&quot;<br>
&gt; and you respond &quot;maybe they want to select disabled interfaces&rd=
quo;.<br>
<br>
It&rsquo;s up to the server to interpret the entire configuration, so if a =
service is enabled in configuration but it depends on an interface that is =
currently disabled, the server might keep that service operationally disabl=
ed as well.<br>

<br>
Section 6 in the routing draft deals with exactly these interactions.<br>
<br>
If this situation has to be avoided for some reason, then yes, a &ldquo;mus=
t&rdquo; statement can be used to enforce, e.g., that a leafref only refers=
 to an enabled interface. I don&rsquo;t see it as a problem though.<br>
<br>
I think it is OK that the &ldquo;enabled&rdquo; leafs are ad hoc because th=
eir semantics may be specific, too.<br>
<br></blockquote><div><br></div><div><br></div><div>This is the part I real=
ly don&#39;t like.</div><div>These mechanisms should not be ad-hoc and diff=
erent for every module.</div><div>There should be a standard way to operati=
onally enable/disable config</div>
<div>and a standard way to comment/uncomment config.</div><div><br></div><d=
iv>IMO, we are making a big mistake by not standardizing a solution like th=
e xpath1.0</div><div>typedef in ietf-yang-types.yang. &nbsp;If there was a =
reusable type for this leaf, then tools</div>
<div>could use that to identify the design pattern and handle the enable/di=
sable edits</div><div>within the validation engine and the system instrumen=
tation.</div><div><br></div><div>Sometimes following the CLI too closely le=
ads to bad API decisions</div>
<div><br></div><div><br></div><div>Andy</div><div><br></div><div>&nbsp;</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
That said, I am not against introducing the &ldquo;inactive&rdquo; attribut=
e but, as I understand it, its meaning will be different.<br>
<br>
&gt; The complex must/when statements will be required to select<br>
&gt; active interfaces. &nbsp;In my example, the active-foo-interface MUST<=
br>
&gt; be active. The foo service does not work when it is configured to<br>
&gt; use a disabled interface. &nbsp;I suspect very few services function c=
orrectly<br>
&gt; using disabled interfaces.<br>
<br>
My point is that even if a service looks like being enabled in configuratio=
n, it may not be the case because some dependencies are not met - and this =
can be anticipated, as in the routing data model.<br>
<br>
Lada<br>
<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; I agree this notion of &quot;operationally disabled&quot; is not =
the<br>
&gt; &gt; same as commenting out. &nbsp;I don&#39;t think N/Y properly supp=
orts<br>
&gt; &gt; either one.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Lada<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The behavior for all of these statements needs to be clarifi=
ed<br>
&gt; &gt; &gt; when disabled nodes are involved.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The &#39;enabled&#39; leaf is like SMIv2 RowStatus TC, excep=
t that<br>
&gt; &gt; &gt; it is ad-hoc and used randomly. SMIv2 does not have any<br>
&gt; &gt; &gt; validation statements that can be affected by a &#39;notInSe=
rvice&#39; row,<br>
&gt; &gt; &gt; so RowStatus is not broken in SNMP.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Solution:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; YANG 1.1 must define a &quot;metadata plane&quot; that appli=
es to<br>
&gt; &gt; &gt; configuration datastores. &nbsp;Global attributes that are s=
pecific<br>
&gt; &gt; &gt; to configuration datastores (e.g. with-defaults) will be inc=
luded<br>
&gt; &gt; &gt; in the standard metadata library. It is expected that protoc=
ols<br>
&gt; &gt; &gt; using YANG will define operations for reading and writing<br=
>
&gt; &gt; &gt; global attributes.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; YANG 1.1 must define an &quot;enabled&quot; global attribute=
 that must<br>
&gt; &gt; &gt; be supported in all YANG 1.1 tools. The YANG validation rule=
s<br>
&gt; &gt; &gt; must be adjusted to properly account for disabled subtrees.<=
br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Side issue: should &#39;enabled&#39; leafs be removed when c=
onverting<br>
&gt; &gt; &gt; a YANG 1.0 module to YANG 1.1?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Andy<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; netmod mailing list<br>
&gt; &gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; &gt; PGP Key ID: E74E8C0C<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c14d668d6fa204f8962e8c--


From nobody Sun May  4 22:57:30 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C61A0257 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 22:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3cbYJDqFmo2 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 22:57:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D99A01A0254 for <netmod@ietf.org>; Sun,  4 May 2014 22:57:26 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A71D3941BC; Mon,  5 May 2014 07:57:21 +0200 (CEST)
Date: Mon, 05 May 2014 07:57:20 +0200 (CEST)
Message-Id: <20140505.075720.274914921.mbj@tail-f.com>
To: nisse@lysator.liu.se
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <nnha5ar39t.fsf@bacon.lysator.liu.se>
References: <nnlhunqplp.fsf@bacon.lysator.liu.se> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <nnha5ar39t.fsf@bacon.lysator.liu.se>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dUKm45k19eVmgL6USYq6_itVIlA
Cc: ietf-ssh@NetBSD.org, netmod@ietf.org, jhutz@cmu.edu
Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 05:57:29 -0000

nisse@lysator.liu.se (Niels M=F6ller) wrote:
> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> =

> > On Wed, 2014-04-30 at 08:49 +0200, Niels M=F6ller wrote:
> >> >     However, if we also keep the leaf algorithm, we need to spec=
ify
> >> >     what happens if the leaf algorithm has a value that is diffe=
rent
> >> >     from the value embedded in the key blob.
> >> =

> >> Right, eliminating this redundancy makes things simpler.
> >
> > It would, except you can't eliminate it.
> =

> Hmm. I think you're right. So then then the "algorithm" leaf would be=

> the name being used in algorithm negotiation and the like, and the "k=
ey"
> leaf would be the key blob. The key blob typically starts with a stri=
ng
> containing the algorithm identifier, but nothing but the ssh
> implementation is expected to care about that detail.

Ok.  But even if I don't know/care about the details; if I want to
configure a key, I need to know that the format my keygen program uses
is compatible with the format the server expects.


> So then the right choice is 1),
> =

> : 1)  Clarify that the leaf "key-data" contains:
> : =

> :          string    certificate or public key format identifier
> :          byte[n]   key/certificate data
> : =

> :     This allows for simple copy-and-paste from normal open ssh and
> :     rfc4716 files.

But Jeffrey Hutzelman wrote:

   But yes, I believe RFC4716 is broken, because it relies on the
   encoding described above, rather than being consistent with the
   requirement "The key type MUST always be explicitly known."

So if we introduce the clarification (1) above, aren't we doing the
same mistake as RFC 4716?

I am a bit confused by the terminology.  What is the difference
between "key", "key data", and "key blob"?



/martin


From nobody Sun May  4 23:57:35 2014
Return-Path: <nisse@lysator.liu.se>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB111A0262 for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 23:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.122
X-Spam-Level: 
X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-MO_NpbUEtQ for <netmod@ietfa.amsl.com>; Sun,  4 May 2014 23:57:31 -0700 (PDT)
Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D41A0019 for <netmod@ietf.org>; Sun,  4 May 2014 23:57:31 -0700 (PDT)
Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s456vLM1027931; Mon, 5 May 2014 08:57:21 +0200 (MEST)
Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s456vHVK027925; Mon, 5 May 2014 08:57:17 +0200 (MEST)
X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f
From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
To: Martin Bjorklund <mbj@tail-f.com>
References: <nnlhunqplp.fsf@bacon.lysator.liu.se> <1398875570.20380.20.camel@destiny.pc.cs.cmu.edu> <nnha5ar39t.fsf@bacon.lysator.liu.se> <20140505.075720.274914921.mbj@tail-f.com>
Date: Mon, 05 May 2014 08:57:17 +0200
In-Reply-To: <20140505.075720.274914921.mbj@tail-f.com> (Martin Bjorklund's message of "Mon, 05 May 2014 07:57:20 +0200 (CEST)")
Message-ID: <nneh08pvaq.fsf@bacon.lysator.liu.se>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IUkL6ICTQv4E_RNaC2mwJ--ywfo
Cc: ietf-ssh@NetBSD.org, netmod@ietf.org, jhutz@cmu.edu
Subject: Re: [netmod] SSH keys - draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 06:57:33 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

> nisse@lysator.liu.se (Niels Möller) wrote:

>> So then the right choice is 1),
>> 
>> : 1)  Clarify that the leaf "key-data" contains:
>> : 
>> :          string    certificate or public key format identifier
>> :          byte[n]   key/certificate data
>> : 
>> :     This allows for simple copy-and-paste from normal open ssh and
>> :     rfc4716 files.
>
> But Jeffrey Hutzelman wrote:
>
>    But yes, I believe RFC4716 is broken, because it relies on the
>    encoding described above, rather than being consistent with the
>    requirement "The key type MUST always be explicitly known."

It would have made some sense for the RFC 4716 public key format to
include some other header for the algorithm, but I'm not sure it's
"broken". I think one reasonable interpretation of "The key type MUST
always be explicitly known." is that it's inappropriate to define
mechanisms *within* the ssh protocol which accept a key of arbitrary
type, without any algorithm negotiation or advertisement, so that the
receiver has to take the key apart and then do some dispatch on the
embedded algorithm type.

But that doens't necessarily rule out passing around arbitrary keys
*outside* of the ssh wire protocol, without specifying key type
explicitly.

> I am a bit confused by the terminology.  What is the difference
> between "key", "key data", and "key blob"?

Sorry about that. I think the data for the "key-data" leaf should be as
you specify it above. E.g., for an RSA key, the ssh transport encoding
of

      string    "ssh-rsa"
      mpint     e
      mpint     n

The one thing that seems clear to me is that you shouldn't strip that
algorithm field from your "key-data" leaf.

> So if we introduce the clarification (1) above, aren't we doing the
> same mistake as RFC 4716?

If you also include the string "ssh-rsa" in the "algorithm" leaf, you
*do* have that extra information, missing from RFC 4716. So if it's a
mistake, it's a different mistake.

A small practical problem is that if you want to do simple
copy-and-paste from rfc4716 files, you also need a tool to extract the
algorithm identifier, so you can set the "algorithm" leaf correctly. And
I see nothing wrong in doing that; it is properly specified in both RFC
4716 and RFC4253 how to do that, and any tools handing RFC4716 files at
all can be expected to have some knowledge of ssh specifics.

I have to admit I'm also a bit confused at this point... it's getting
less and less clear to me if it really is the right thing to include
algorithm info separately. My gut reaction was no, and then Jeffrey
convinced me it's necessary, and now I just don't know.

Pro: Having the algorithm separately simplifies some use cases. Say, you
want to compare the information in your files to the configuration of an
ssh implementation to see if available keys are supported.

Cons: You could get subtle failure modes if you do the above, and the
data is inconsistent. Say some program ignores your algorithm leaf
(e.g., you export the key data in RFC 4716 format), and some doesn't
(e.g., the algorithm leaf makes it through to the ssh configuration, and
then the key is invalid, and results in an error locally or remotely).

Probably no *big* problems either way.

In case you use this data to keep track of authorized user or host keys,
I think it's prudent to make sure than any key-data leaf not matching
the corresponding "algorithm" leafs is treated as an invalid key. And,
e.g., refuse to export it in RFC 4716 format.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.


From nobody Mon May  5 00:08:35 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8AA1A0275 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPmQA2XEA6kZ for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:08:30 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4A86E1A026A for <netmod@ietf.org>; Mon,  5 May 2014 00:08:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8A88E540647; Mon,  5 May 2014 09:08:25 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUB38I6bqBnr; Mon,  5 May 2014 09:08:20 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 09938540331; Mon,  5 May 2014 09:08:19 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>
In-Reply-To: <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com> <F17C1196-D388-4370-B9F1-0B6870A06C9A@nic.cz> <CABCOCHQS8q3FXN7SwWgU9nrxLWA7gdA=Hj+vEnctFi1hv8f5LA@mail.gmail.com> <9429DA92-078C-4F7D-9795-AF7D43B79142@nic.cz> <CABCOCHQR_QvmV7QJbVoG+=F_xroU=XcAn3xDwOjfZ-jcR89WFg@mail.gmail.com> <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 05 May 2014 09:08:19 +0200
Message-ID: <m28uqgd7oc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nksFEyGPckyCRQ-eZp6y2v5INXc
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 07:08:34 -0000

Andy Bierman <andy@yumaworks.com> writes:

> On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>>
>> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
>>
>> >
>> >
>> >
>> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> >
>> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> > >
>> > >
>> > >
>> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz>
>> wrote:
>> > >
>> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > Problem:
>> > > >
>> > > > The use of a leaf in the data model (such as the
>> /interfaces/interface/enabled
>> > > > leaf in the ietf-interfaces module) does not account for YANG
>> validation rules
>> > > > for many statements that can reference the disabled subtree from
>> outside
>> > > > of that subtree:
>> > > >
>> > > >     - must
>> > > >     - when
>> > > >     - unique
>> > > >     - min-elements
>> > > >     - max-elements
>> > > >     - leafref (valid instances)
>> > > >     - choices (disabled case is still the active case, so no other
>> can be used)
>> > >
>> > > In my view, an "enabled false" leaf *operationally* disables a
>> particular instance or function. For all other purposes related to
>> datastore validation, the value of the enabled leaf doesn't matter. In
>> other words, "enabled false" is not the same as commenting out the
>> corresponding instance in the configuration.
>> > >
>> > >
>> > > OK -- they may be different, but the enabled leaf is ad-hoc,
>> > > and YANG designers must know about this leaf.  Adding or removing
>> > > this leaf could break other YANG statements.
>> > >
>> > > E,g,
>> > >
>> > >
>> > >    leaf active-foo-interface {
>> > >        type  if:interface-ref;
>> > >        mandatory true;
>> > >    }
>> > >
>> > >
>> > > By YANG validation rules, the  leafref test for interface name
>> > > will include all disabled interfaces.
>> >
>> > Yes.
>> >
>> > >
>> > > Doesn't every object that uses the interface-ref typedef need
>> > > to have a must-stmt making sure the enabled leaf is set,
>> > > if they want to activate a service on only enabled interfaces?
>> > >
>> > > (Is this the must-stmt to use?)
>> > >
>> > >    leaf active-foo-interface {
>> > >        type  if:interface-ref;
>> > >        must "/if:interfaces/if:interface[if:name=current()]/enabled";
>> > >        mandatory true;
>> > >    }
>> > >
>> > > Don't all must/when/leafref validation statements that want only
>> > > active interfaces need to be written this way?
>> >
>> > I don't think so. An operator may want to pre-configure an interface in
>> the disabled state, set up all references to it etc., so that everything
>> will be up and running after setting the single "enabled" leaf to true.
>> >
>> > I said "this is what has to be written to identity active interfaces"
>> > and you respond "maybe they want to select disabled interfaces".
>>
>> It's up to the server to interpret the entire configuration, so if a
>> service is enabled in configuration but it depends on an interface that is
>> currently disabled, the server might keep that service operationally
>> disabled as well.
>>
>>
> Not if the YANG validation rules say differently.
> My point is that the YANG designer must write all validation rules to
> account for disabled configuration, or the model is wrong.

I don't agree. It would be extremely impractical to render a configuration invalid just by disabling an interface.

I suspect we (again) run into the confusion of configuration and state. The rules you are talking about are in fact important for operational state - service X cannot be enabled unless interface Y is enabled as well. In configuration they are IMO unnecessary, in fact annoying - the server should be able to figure out what to do.

>
>
> Section 6 in the routing draft deals with exactly these interactions.
>>
>> If this situation has to be avoided for some reason, then yes, a "must"
>> statement can be used to enforce, e.g., that a leafref only refers to an
>> enabled interface. I don't see it as a problem though.
>>
>> I think it is OK that the "enabled" leafs are ad hoc because their
>> semantics may be specific, too.
>>
>>
> So some enabled leafs will be default true, some default false,
> some mandatory with no default.  Some will have special corner-cases
> that cause partial operation.  Some will have extra enabled leafs that
> change the meaning of the original enabled leaf.
>

Sure, if it makes sense for a particular case and implementation policy. For example, an implementation might want to have ssh server enabled by default but XMPP server disabled by default.

> Sounds great if you are trying to create a fragile, ad-hoc, hand-coded
> system.
> Not so great if you are trying to use YANG to bring consistency and
> automation
> into the system.

I don't believe there is a one-size-fits-all solution for all these "enabled" switches. In some cases, their effect is combined with parent presence containers.

If there is a prototypical pattern for using such "enabled" leafs, it can be explained in 6087bis, and perhaps supported with some groupings. But this doesn't mean there can't be an "enabled" leaf with different semantics.

Why is that fragile, if the semantics are properly described in the data model?

>
>
> That said, I am not against introducing the "inactive" attribute but, as I
>> understand it, its meaning will be different.
>>
>> > The complex must/when statements will be required to select
>> > active interfaces.  In my example, the active-foo-interface MUST
>> > be active. The foo service does not work when it is configured to
>> > use a disabled interface.  I suspect very few services function correctly
>> > using disabled interfaces.
>>
>> My point is that even if a service looks like being enabled in
>> configuration, it may not be the case because some dependencies are not met
>> - and this can be anticipated, as in the routing data model.
>>
>>
> The system will have to be designed to account for all these ad-hoc on/off
> switches.
> IMO hindsight will show that a completely free-form solution path was not a
> good idea.

Free form? I think a data modeller is supposed to do the right thing, and IMO it is not the same in all cases.

Lada

>
>
> Lada
>>
>
> Andy
>
>
>>
>> >
>> >
>> > Lada
>> >
>> >
>> > Andy
>> >
>> >
>> > >
>> > > I agree this notion of "operationally disabled" is not the
>> > > same as commenting out.  I don't think N/Y properly supports
>> > > either one.
>> > >
>> > >
>> > >
>> > > Lada
>> > >
>> > > Andy
>> > >
>> > >
>> > > >
>> > > > The behavior for all of these statements needs to be clarified
>> > > > when disabled nodes are involved.
>> > > >
>> > > > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
>> > > > it is ad-hoc and used randomly. SMIv2 does not have any
>> > > > validation statements that can be affected by a 'notInService' row,
>> > > > so RowStatus is not broken in SNMP.
>> > > >
>> > > > Solution:
>> > > >
>> > > > YANG 1.1 must define a "metadata plane" that applies to
>> > > > configuration datastores.  Global attributes that are specific
>> > > > to configuration datastores (e.g. with-defaults) will be included
>> > > > in the standard metadata library. It is expected that protocols
>> > > > using YANG will define operations for reading and writing
>> > > > global attributes.
>> > > >
>> > > > YANG 1.1 must define an "enabled" global attribute that must
>> > > > be supported in all YANG 1.1 tools. The YANG validation rules
>> > > > must be adjusted to properly account for disabled subtrees.
>> > > >
>> > > > Side issue: should 'enabled' leafs be removed when converting
>> > > > a YANG 1.0 module to YANG 1.1?
>> > > >
>> > > >
>> > > > Andy
>> > > >
>> > > > _______________________________________________
>> > > > netmod mailing list
>> > > > netmod@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/netmod
>> > >
>> > > --
>> > > Ladislav Lhotka, CZ.NIC Labs
>> > > PGP Key ID: E74E8C0C
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon May  5 00:26:40 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FDA1A0019 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41IM_TkfVsLP for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:26:37 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA21A0276 for <netmod@ietf.org>; Mon,  5 May 2014 00:26:36 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 9FF073B41E5; Mon,  5 May 2014 09:26:32 +0200 (CEST)
Date: Mon, 05 May 2014 09:26:32 +0200 (CEST)
Message-Id: <20140505.092632.235496358.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <m28uqgd7oc.fsf@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qOzRfRYSJFBg3vMyjyjvDR3X5vU
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 07:26:38 -0000

Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.com> writes:
> 
> > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >>
> >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
> >>
> >> >
> >> >
> >> >
> >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> >
> >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
> >> >
> >> > >
> >> > >
> >> > >
> >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz>
> >> wrote:
> >> > >
> >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > Problem:
> >> > > >
> >> > > > The use of a leaf in the data model (such as the
> >> /interfaces/interface/enabled
> >> > > > leaf in the ietf-interfaces module) does not account for YANG
> >> validation rules
> >> > > > for many statements that can reference the disabled subtree from
> >> outside
> >> > > > of that subtree:
> >> > > >
> >> > > >     - must
> >> > > >     - when
> >> > > >     - unique
> >> > > >     - min-elements
> >> > > >     - max-elements
> >> > > >     - leafref (valid instances)
> >> > > >     - choices (disabled case is still the active case, so no other
> >> can be used)
> >> > >
> >> > > In my view, an "enabled false" leaf *operationally* disables a
> >> particular instance or function. For all other purposes related to
> >> datastore validation, the value of the enabled leaf doesn't matter. In
> >> other words, "enabled false" is not the same as commenting out the
> >> corresponding instance in the configuration.
> >> > >
> >> > >
> >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> >> > > and YANG designers must know about this leaf.  Adding or removing
> >> > > this leaf could break other YANG statements.
> >> > >
> >> > > E,g,
> >> > >
> >> > >
> >> > >    leaf active-foo-interface {
> >> > >        type  if:interface-ref;
> >> > >        mandatory true;
> >> > >    }
> >> > >
> >> > >
> >> > > By YANG validation rules, the  leafref test for interface name
> >> > > will include all disabled interfaces.
> >> >
> >> > Yes.
> >> >
> >> > >
> >> > > Doesn't every object that uses the interface-ref typedef need
> >> > > to have a must-stmt making sure the enabled leaf is set,
> >> > > if they want to activate a service on only enabled interfaces?
> >> > >
> >> > > (Is this the must-stmt to use?)
> >> > >
> >> > >    leaf active-foo-interface {
> >> > >        type  if:interface-ref;
> >> > >        must "/if:interfaces/if:interface[if:name=current()]/enabled";
> >> > >        mandatory true;
> >> > >    }
> >> > >
> >> > > Don't all must/when/leafref validation statements that want only
> >> > > active interfaces need to be written this way?
> >> >
> >> > I don't think so. An operator may want to pre-configure an interface in
> >> the disabled state, set up all references to it etc., so that everything
> >> will be up and running after setting the single "enabled" leaf to true.
> >> >
> >> > I said "this is what has to be written to identity active interfaces"
> >> > and you respond "maybe they want to select disabled interfaces".
> >>
> >> It's up to the server to interpret the entire configuration, so if a
> >> service is enabled in configuration but it depends on an interface that is
> >> currently disabled, the server might keep that service operationally
> >> disabled as well.
> >>
> >>
> > Not if the YANG validation rules say differently.
> > My point is that the YANG designer must write all validation rules to
> > account for disabled configuration, or the model is wrong.
> 
> I don't agree. It would be extremely impractical to render a configuration
> invalid just by disabling an interface.

I think you are both right - the 'inactive' feature is very useful
(and it works just as if the node is deleted), but it doesn't
necessarilty replace an "enabled" leaf in all cases.  As you noted,
they behave differently.


/martin


From nobody Mon May  5 00:26:56 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952FE1A0019 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8ZBhAt7-Nc1 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:26:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7B51A0276 for <netmod@ietf.org>; Mon,  5 May 2014 00:26:53 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 712A73B41E5; Mon,  5 May 2014 09:26:49 +0200 (CEST)
Date: Mon, 05 May 2014 09:26:48 +0200 (CEST)
Message-Id: <20140505.092648.122530744.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com>
References: <CABCOCHR_Kf2a9mD_rZ-mkw5NGob9Rp_pdSaQ0k40ER2aN56LLA@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i3ZDwHBm658vq7Nia1qaq_Mxfao
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 07:26:54 -0000

Hi,

Added as Y48.


/martin



Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> Problem:
> 
> The use of a leaf in the data model (such as the
> /interfaces/interface/enabled
> leaf in the ietf-interfaces module) does not account for YANG validation
> rules
> for many statements that can reference the disabled subtree from outside
> of that subtree:
> 
>     - must
>     - when
>     - unique
>     - min-elements
>     - max-elements
>     - leafref (valid instances)
>     - choices (disabled case is still the active case, so no other can be
> used)
> 
> The behavior for all of these statements needs to be clarified
> when disabled nodes are involved.
> 
> The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> it is ad-hoc and used randomly. SMIv2 does not have any
> validation statements that can be affected by a 'notInService' row,
> so RowStatus is not broken in SNMP.
> 
> Solution:
> 
> YANG 1.1 must define a "metadata plane" that applies to
> configuration datastores.  Global attributes that are specific
> to configuration datastores (e.g. with-defaults) will be included
> in the standard metadata library. It is expected that protocols
> using YANG will define operations for reading and writing
> global attributes.
> 
> YANG 1.1 must define an "enabled" global attribute that must
> be supported in all YANG 1.1 tools. The YANG validation rules
> must be adjusted to properly account for disabled subtrees.
> 
> Side issue: should 'enabled' leafs be removed when converting
> a YANG 1.0 module to YANG 1.1?
> 
> 
> Andy


From nobody Mon May  5 00:35:05 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049FA1A0270 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbB2R-82pkk1 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 00:35:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6060B1A0019 for <netmod@ietf.org>; Mon,  5 May 2014 00:35:02 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 78AFC13F9D0; Mon,  5 May 2014 09:34:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399275298; bh=KmiFiK5QENmyUtSvtWrLV2jJXbMZBk7//wYvRB/KcQE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GtQkvJvnSSM+wvMVV3v/OWUoUr3YXOih/0LxWYCQjebM+sP+kNxWT7mJFFiuOd26H h7okocjaXI/9mUXXlnTEcMPdNRWLuR5Uct5+ETj80hMUOc53zDZN9Z7YlvxEqoJp23 KATq/xtUFJ53XbWz+Gr93XfVpzsRI3yiDJ3xpRjw=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140505.092632.235496358.mbj@tail-f.com>
Date: Mon, 5 May 2014 09:34:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B01E5AB-EE3F-44B2-AB66-15255429E255@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gajLsmTY9IfN6Mfm-PyXpWmXObk
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 07:35:04 -0000

On 05 May 2014, at 09:26, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
>> Andy Bierman <andy@yumaworks.com> writes:
>>=20
>>> On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>>>=20
>>>>=20
>>>> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>>>>>=20
>>>>> On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz>
>>>> wrote:
>>>>>>=20
>>>>>> On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> =
wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Problem:
>>>>>>>=20
>>>>>>> The use of a leaf in the data model (such as the
>>>> /interfaces/interface/enabled
>>>>>>> leaf in the ietf-interfaces module) does not account for YANG
>>>> validation rules
>>>>>>> for many statements that can reference the disabled subtree from
>>>> outside
>>>>>>> of that subtree:
>>>>>>>=20
>>>>>>>    - must
>>>>>>>    - when
>>>>>>>    - unique
>>>>>>>    - min-elements
>>>>>>>    - max-elements
>>>>>>>    - leafref (valid instances)
>>>>>>>    - choices (disabled case is still the active case, so no =
other
>>>> can be used)
>>>>>>=20
>>>>>> In my view, an "enabled false" leaf *operationally* disables a
>>>> particular instance or function. For all other purposes related to
>>>> datastore validation, the value of the enabled leaf doesn't matter. =
In
>>>> other words, "enabled false" is not the same as commenting out the
>>>> corresponding instance in the configuration.
>>>>>>=20
>>>>>>=20
>>>>>> OK -- they may be different, but the enabled leaf is ad-hoc,
>>>>>> and YANG designers must know about this leaf.  Adding or removing
>>>>>> this leaf could break other YANG statements.
>>>>>>=20
>>>>>> E,g,
>>>>>>=20
>>>>>>=20
>>>>>>   leaf active-foo-interface {
>>>>>>       type  if:interface-ref;
>>>>>>       mandatory true;
>>>>>>   }
>>>>>>=20
>>>>>>=20
>>>>>> By YANG validation rules, the  leafref test for interface name
>>>>>> will include all disabled interfaces.
>>>>>=20
>>>>> Yes.
>>>>>=20
>>>>>>=20
>>>>>> Doesn't every object that uses the interface-ref typedef need
>>>>>> to have a must-stmt making sure the enabled leaf is set,
>>>>>> if they want to activate a service on only enabled interfaces?
>>>>>>=20
>>>>>> (Is this the must-stmt to use?)
>>>>>>=20
>>>>>>   leaf active-foo-interface {
>>>>>>       type  if:interface-ref;
>>>>>>       must =
"/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled";
>>>>>>       mandatory true;
>>>>>>   }
>>>>>>=20
>>>>>> Don't all must/when/leafref validation statements that want only
>>>>>> active interfaces need to be written this way?
>>>>>=20
>>>>> I don't think so. An operator may want to pre-configure an =
interface in
>>>> the disabled state, set up all references to it etc., so that =
everything
>>>> will be up and running after setting the single "enabled" leaf to =
true.
>>>>>=20
>>>>> I said "this is what has to be written to identity active =
interfaces"
>>>>> and you respond "maybe they want to select disabled interfaces".
>>>>=20
>>>> It's up to the server to interpret the entire configuration, so if =
a
>>>> service is enabled in configuration but it depends on an interface =
that is
>>>> currently disabled, the server might keep that service =
operationally
>>>> disabled as well.
>>>>=20
>>>>=20
>>> Not if the YANG validation rules say differently.
>>> My point is that the YANG designer must write all validation rules =
to
>>> account for disabled configuration, or the model is wrong.
>>=20
>> I don't agree. It would be extremely impractical to render a =
configuration
>> invalid just by disabling an interface.
>=20
> I think you are both right - the 'inactive' feature is very useful
> (and it works just as if the node is deleted), but it doesn't
> necessarilty replace an "enabled" leaf in all cases.  As you noted,
> they behave differently.

Yes, that=92s what I wrote in my earlier email. But then, any use of =
=91inactive=92 may of course violate constraints of the data model - =
exactly as node deletion can. So I don=92t see the point of this issue - =
what needs to be clarified?

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May  5 01:48:11 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B11C1A0159 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 01:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgdEirX7Tc3Y for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 01:48:08 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBDE1A0157 for <netmod@ietf.org>; Mon,  5 May 2014 01:48:08 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id f51so6645011qge.12 for <netmod@ietf.org>; Mon, 05 May 2014 01:48:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0BCIU2gYdQAh+RwcnMRrZlftY1EZirnq7aMSR+vXjk0=; b=mLQMAxmBffzRTuSQCYcsDQ5quQGPsCJmbZL6yedUd2EhJbN6swV2h+j9ztIq5hjjLU rhEiSxlheiZm5rUMfsw0Ymlmcl4OsBAXaCjZkDVofQ9rUt0lq7nB7SnsXLAU+TaHaik2 PyD/dgGpXkhAJFkayq394amOtu9Qb7+HZRoMYzAjfJN5tFovjBmhPFLxhJF3tDVLdHVZ JC/Lqn7oA0KH/jFhPKjWWjTqSLbdP49BsBdLEYrWw1lEL68Vf0twvXiixvcwPaBgNaEq 3JUpqlBRpWjStoE4Wi2YZNC2Qv749y053Uk6rqm0smMTwbrFi9WRhgz1H5g70lxyAN2K DqZg==
X-Gm-Message-State: ALoCoQkV3Iq+hABR8vObYSdJ/BrnBfNzdcN65rcBys7wWO8DxA5hKd68APou/F0iRKMuhMRKRFuY
MIME-Version: 1.0
X-Received: by 10.224.138.3 with SMTP id y3mr42533914qat.78.1399279685094; Mon, 05 May 2014 01:48:05 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Mon, 5 May 2014 01:48:04 -0700 (PDT)
In-Reply-To: <20140505.092632.235496358.mbj@tail-f.com>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com>
Date: Mon, 5 May 2014 01:48:04 -0700
Message-ID: <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary=047d7b672b44927f8004f8a330bf
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Hj4VNSmMK-Q9zqSTvo3VWtO5SS4
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 08:48:10 -0000

--047d7b672b44927f8004f8a330bf
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > >>
> > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
> > >>
> > >> >
> > >> >
> > >> >
> > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > >> >
> > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
> > >> >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz>
> > >> wrote:
> > >> > >
> > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
> wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > Problem:
> > >> > > >
> > >> > > > The use of a leaf in the data model (such as the
> > >> /interfaces/interface/enabled
> > >> > > > leaf in the ietf-interfaces module) does not account for YANG
> > >> validation rules
> > >> > > > for many statements that can reference the disabled subtree from
> > >> outside
> > >> > > > of that subtree:
> > >> > > >
> > >> > > >     - must
> > >> > > >     - when
> > >> > > >     - unique
> > >> > > >     - min-elements
> > >> > > >     - max-elements
> > >> > > >     - leafref (valid instances)
> > >> > > >     - choices (disabled case is still the active case, so no
> other
> > >> can be used)
> > >> > >
> > >> > > In my view, an "enabled false" leaf *operationally* disables a
> > >> particular instance or function. For all other purposes related to
> > >> datastore validation, the value of the enabled leaf doesn't matter. In
> > >> other words, "enabled false" is not the same as commenting out the
> > >> corresponding instance in the configuration.
> > >> > >
> > >> > >
> > >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > >> > > and YANG designers must know about this leaf.  Adding or removing
> > >> > > this leaf could break other YANG statements.
> > >> > >
> > >> > > E,g,
> > >> > >
> > >> > >
> > >> > >    leaf active-foo-interface {
> > >> > >        type  if:interface-ref;
> > >> > >        mandatory true;
> > >> > >    }
> > >> > >
> > >> > >
> > >> > > By YANG validation rules, the  leafref test for interface name
> > >> > > will include all disabled interfaces.
> > >> >
> > >> > Yes.
> > >> >
> > >> > >
> > >> > > Doesn't every object that uses the interface-ref typedef need
> > >> > > to have a must-stmt making sure the enabled leaf is set,
> > >> > > if they want to activate a service on only enabled interfaces?
> > >> > >
> > >> > > (Is this the must-stmt to use?)
> > >> > >
> > >> > >    leaf active-foo-interface {
> > >> > >        type  if:interface-ref;
> > >> > >        must
> "/if:interfaces/if:interface[if:name=current()]/enabled";
> > >> > >        mandatory true;
> > >> > >    }
> > >> > >
> > >> > > Don't all must/when/leafref validation statements that want only
> > >> > > active interfaces need to be written this way?
> > >> >
> > >> > I don't think so. An operator may want to pre-configure an
> interface in
> > >> the disabled state, set up all references to it etc., so that
> everything
> > >> will be up and running after setting the single "enabled" leaf to
> true.
> > >> >
> > >> > I said "this is what has to be written to identity active
> interfaces"
> > >> > and you respond "maybe they want to select disabled interfaces".
> > >>
> > >> It's up to the server to interpret the entire configuration, so if a
> > >> service is enabled in configuration but it depends on an interface
> that is
> > >> currently disabled, the server might keep that service operationally
> > >> disabled as well.
> > >>
> > >>
> > > Not if the YANG validation rules say differently.
> > > My point is that the YANG designer must write all validation rules to
> > > account for disabled configuration, or the model is wrong.
> >
> > I don't agree. It would be extremely impractical to render a
> configuration
> > invalid just by disabling an interface.
>
>
The important point is that the designer better know every single
YANG object and write the validation rules correctly.
Inconvenient or not, if some component needs to use
only active interfaces, then ignoring the 'active' leaf will be broken.

The system can be hand-coded at great expense to deal with any
poorly designed ad-hoc mechanism.  It is just engineering decisions
that determine whether we develop an efficient programmatic API
or we develop CLI with angle brackets.




> I think you are both right - the 'inactive' feature is very useful
> (and it works just as if the node is deleted), but it doesn't
> necessarilty replace an "enabled" leaf in all cases.  As you noted,
> they behave differently.
>
>
>
Andy



> /martin
>

--047d7b672b44927f8004f8a330bf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ladislav Lhotka &lt;<a href=3D"mailto:lhotka=
@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; writes:<br>
&gt;<br>
&gt; &gt; On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka &lt;<a href=3D"ma=
ilto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On 04 May 2014, at 10:33, Andy Bierman &lt;<a href=3D"mailto:=
andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka &lt;<a =
href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; On 03 May 2014, at 21:31, Andy Bierman &lt;<a href=3D"ma=
ilto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka &l=
t;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt; &gt;&gt; wrote:<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; On 03 May 2014, at 18:42, Andy Bierman &lt;<a href=
=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; &gt; Problem:<br>
&gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; &gt; The use of a leaf in the data model (such as t=
he<br>
&gt; &gt;&gt; /interfaces/interface/enabled<br>
&gt; &gt;&gt; &gt; &gt; &gt; leaf in the ietf-interfaces module) does not a=
ccount for YANG<br>
&gt; &gt;&gt; validation rules<br>
&gt; &gt;&gt; &gt; &gt; &gt; for many statements that can reference the dis=
abled subtree from<br>
&gt; &gt;&gt; outside<br>
&gt; &gt;&gt; &gt; &gt; &gt; of that subtree:<br>
&gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - must<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - when<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - unique<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - min-elements<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - max-elements<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - leafref (valid instances)<br>
&gt; &gt;&gt; &gt; &gt; &gt; =A0 =A0 - choices (disabled case is still the =
active case, so no other<br>
&gt; &gt;&gt; can be used)<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; In my view, an &quot;enabled false&quot; leaf *oper=
ationally* disables a<br>
&gt; &gt;&gt; particular instance or function. For all other purposes relat=
ed to<br>
&gt; &gt;&gt; datastore validation, the value of the enabled leaf doesn&#39=
;t matter. In<br>
&gt; &gt;&gt; other words, &quot;enabled false&quot; is not the same as com=
menting out the<br>
&gt; &gt;&gt; corresponding instance in the configuration.<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; OK -- they may be different, but the enabled leaf i=
s ad-hoc,<br>
&gt; &gt;&gt; &gt; &gt; and YANG designers must know about this leaf. =A0Ad=
ding or removing<br>
&gt; &gt;&gt; &gt; &gt; this leaf could break other YANG statements.<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; E,g,<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0leaf active-foo-interface {<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0 =A0 =A0type =A0if:interface-ref;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0 =A0 =A0mandatory true;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0}<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; By YANG validation rules, the =A0leafref test for i=
nterface name<br>
&gt; &gt;&gt; &gt; &gt; will include all disabled interfaces.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Yes.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; Doesn&#39;t every object that uses the interface-re=
f typedef need<br>
&gt; &gt;&gt; &gt; &gt; to have a must-stmt making sure the enabled leaf is=
 set,<br>
&gt; &gt;&gt; &gt; &gt; if they want to activate a service on only enabled =
interfaces?<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; (Is this the must-stmt to use?)<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0leaf active-foo-interface {<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0 =A0 =A0type =A0if:interface-ref;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0 =A0 =A0must &quot;/if:interfaces/if:interfa=
ce[if:name=3Dcurrent()]/enabled&quot;;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0 =A0 =A0mandatory true;<br>
&gt; &gt;&gt; &gt; &gt; =A0 =A0}<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; Don&#39;t all must/when/leafref validation statemen=
ts that want only<br>
&gt; &gt;&gt; &gt; &gt; active interfaces need to be written this way?<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; I don&#39;t think so. An operator may want to pre-config=
ure an interface in<br>
&gt; &gt;&gt; the disabled state, set up all references to it etc., so that=
 everything<br>
&gt; &gt;&gt; will be up and running after setting the single &quot;enabled=
&quot; leaf to true.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; I said &quot;this is what has to be written to identity =
active interfaces&quot;<br>
&gt; &gt;&gt; &gt; and you respond &quot;maybe they want to select disabled=
 interfaces&quot;.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It&#39;s up to the server to interpret the entire configurati=
on, so if a<br>
&gt; &gt;&gt; service is enabled in configuration but it depends on an inte=
rface that is<br>
&gt; &gt;&gt; currently disabled, the server might keep that service operat=
ionally<br>
&gt; &gt;&gt; disabled as well.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt; Not if the YANG validation rules say differently.<br>
&gt; &gt; My point is that the YANG designer must write all validation rule=
s to<br>
&gt; &gt; account for disabled configuration, or the model is wrong.<br>
&gt;<br>
&gt; I don&#39;t agree. It would be extremely impractical to render a confi=
guration<br>
&gt; invalid just by disabling an interface.<br>
<br></blockquote><div><br></div><div>The important point is that the design=
er better know every single</div><div>YANG object and write the validation =
rules correctly.</div><div>Inconvenient or not, if some component needs to =
use</div>
<div>only active interfaces, then ignoring the &#39;active&#39; leaf will b=
e broken.</div><div><br></div><div>The system can be hand-coded at great ex=
pense to deal with any</div><div>poorly designed ad-hoc mechanism. =A0It is=
 just engineering decisions</div>
<div>that determine whether we develop an efficient programmatic API</div><=
div>or we develop CLI with angle brackets.</div><div><br></div><div><br></d=
iv><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">

I think you are both right - the &#39;inactive&#39; feature is very useful<=
br>
(and it works just as if the node is deleted), but it doesn&#39;t<br>
necessarilty replace an &quot;enabled&quot; leaf in all cases. =A0As you no=
ted,<br>
they behave differently.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br></font></span></blockquote><div><br></div><div>Andy</div><div><br></div=
><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font =
color=3D"#888888">
/martin<br>
</font></span></blockquote></div><br></div></div>

--047d7b672b44927f8004f8a330bf--


From nobody Mon May  5 02:36:47 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFBE1A0173 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 02:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6-NQK4fJlbw for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 02:36:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6268A1A00DF for <netmod@ietf.org>; Mon,  5 May 2014 02:36:43 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3946413F9D0; Mon,  5 May 2014 11:36:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399282599; bh=Tgg5YG+3bmkC4bkHhBHWdh1uRfj19X0KddEvPjkOivE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X+CHwRueWTDAHKdnV0UIiMYFBBwGHnDchMISoVu3GbyvkK1Lw8WCepaWADebCgTXh 1Z4KQL2McEYnAHnLdS1cXbTPTjo17fTTEea8X3m+yUyUD4pwX5q9+fiM4rUTpP6DjC P8w8mzcdKIvbll9PvQz4n+aCeSQUUOInccv579Mg=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com>
Date: Mon, 5 May 2014 11:36:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0953E12-3AB2-44CC-9A63-7070540CC534@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com> <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/C5xsWAcfaDWwbyO-mclizfUHIVk
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 09:36:45 -0000

On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> > >
> > >>
> > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> =
wrote:
> > >>
> > >> >
> > >> >
> > >> >
> > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka =
<lhotka@nic.cz> wrote:
> > >> >
> > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> =
wrote:
> > >> >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka =
<lhotka@nic.cz>
> > >> wrote:
> > >> > >
> > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> =
wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > Problem:
> > >> > > >
> > >> > > > The use of a leaf in the data model (such as the
> > >> /interfaces/interface/enabled
> > >> > > > leaf in the ietf-interfaces module) does not account for =
YANG
> > >> validation rules
> > >> > > > for many statements that can reference the disabled subtree =
from
> > >> outside
> > >> > > > of that subtree:
> > >> > > >
> > >> > > >     - must
> > >> > > >     - when
> > >> > > >     - unique
> > >> > > >     - min-elements
> > >> > > >     - max-elements
> > >> > > >     - leafref (valid instances)
> > >> > > >     - choices (disabled case is still the active case, so =
no other
> > >> can be used)
> > >> > >
> > >> > > In my view, an "enabled false" leaf *operationally* disables =
a
> > >> particular instance or function. For all other purposes related =
to
> > >> datastore validation, the value of the enabled leaf doesn't =
matter. In
> > >> other words, "enabled false" is not the same as commenting out =
the
> > >> corresponding instance in the configuration.
> > >> > >
> > >> > >
> > >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > >> > > and YANG designers must know about this leaf.  Adding or =
removing
> > >> > > this leaf could break other YANG statements.
> > >> > >
> > >> > > E,g,
> > >> > >
> > >> > >
> > >> > >    leaf active-foo-interface {
> > >> > >        type  if:interface-ref;
> > >> > >        mandatory true;
> > >> > >    }
> > >> > >
> > >> > >
> > >> > > By YANG validation rules, the  leafref test for interface =
name
> > >> > > will include all disabled interfaces.
> > >> >
> > >> > Yes.
> > >> >
> > >> > >
> > >> > > Doesn't every object that uses the interface-ref typedef need
> > >> > > to have a must-stmt making sure the enabled leaf is set,
> > >> > > if they want to activate a service on only enabled =
interfaces?
> > >> > >
> > >> > > (Is this the must-stmt to use?)
> > >> > >
> > >> > >    leaf active-foo-interface {
> > >> > >        type  if:interface-ref;
> > >> > >        must =
"/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled";
> > >> > >        mandatory true;
> > >> > >    }
> > >> > >
> > >> > > Don't all must/when/leafref validation statements that want =
only
> > >> > > active interfaces need to be written this way?
> > >> >
> > >> > I don't think so. An operator may want to pre-configure an =
interface in
> > >> the disabled state, set up all references to it etc., so that =
everything
> > >> will be up and running after setting the single "enabled" leaf to =
true.
> > >> >
> > >> > I said "this is what has to be written to identity active =
interfaces"
> > >> > and you respond "maybe they want to select disabled =
interfaces".
> > >>
> > >> It's up to the server to interpret the entire configuration, so =
if a
> > >> service is enabled in configuration but it depends on an =
interface that is
> > >> currently disabled, the server might keep that service =
operationally
> > >> disabled as well.
> > >>
> > >>
> > > Not if the YANG validation rules say differently.
> > > My point is that the YANG designer must write all validation rules =
to
> > > account for disabled configuration, or the model is wrong.
> >
> > I don't agree. It would be extremely impractical to render a =
configuration
> > invalid just by disabling an interface.
>=20
>=20
> The important point is that the designer better know every single
> YANG object and write the validation rules correctly.
> Inconvenient or not, if some component needs to use
> only active interfaces, then ignoring the 'active' leaf will be =
broken.

It will be broken in terms of operational state, not configuration. Many =
changes in configuration have ripple effects and well-designed server =
should be able to trace dependencies and act accordingly, rather than =
forcing the user to do it manually.

>=20
> The system can be hand-coded at great expense to deal with any
> poorly designed ad-hoc mechanism.  It is just engineering decisions
> that determine whether we develop an efficient programmatic API
> or we develop CLI with angle brackets.

So what would you do with the rules in sec. 6 of the routing module? =
Note that they involve not only =93enabled=94 leafs in the interfaces =
and ip modules, but also =93ip:forwarding=94.

For example, if /if:interfaces/if:interface/if:enabled is set to false =
for an interface, I don=92t want to force the client to go and remove =
that interface from all configured routing instances.

Similarly, disabling a physical interface should automatically lead to =
disabling all logical interfaces created on top of that physical =
interface - without having to disable all of them manually.

Lada=20

>=20
>=20
> =20
> I think you are both right - the 'inactive' feature is very useful
> (and it works just as if the node is deleted), but it doesn't
> necessarilty replace an "enabled" leaf in all cases.  As you noted,
> they behave differently.
>=20
>=20
>=20
> Andy
>=20
> =20
> /martin
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May  5 08:05:37 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C911A0391 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 08:05:33 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HuUiLF_TL59 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 08:05:31 -0700 (PDT)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id DEC441A038E for <netmod@ietf.org>; Mon,  5 May 2014 08:05:30 -0700 (PDT)
Received: by mail-qg0-f47.google.com with SMTP id j107so800504qga.6 for <netmod@ietf.org>; Mon, 05 May 2014 08:05:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FDd9SarKj6fcb0dJlAnHkeIHdAMwBOkF4bRDm5TFaQ0=; b=MIuZqwC1FKCdKVpcTiGQbWJwyl6N4c9IH4mmDTrl79a9tHndNmKvJ5TDld4J11vfQ/ UFgOftgsYnAQt68lHLo+f7jh1Jge8ozhnbWrpf7J39AO5YUkeXrtWwFSmgsE8SzKVuz4 vBEsrTmkTnlznog4tj519PIKWFTZbuEKiN8fp2haGwpGtnAOvwf4RG3bD0rq5iLII4wJ UxedQxQQ0Vaz3XwEKFlUmjK5ilUCTyn+gHwScQMKgmVPn1eH+k4B6jfcnmPnrET8+LhY ZG5MTixwSUHhsXQrN3ebHy7bCwffYtdiEofGyWtgxokSk6qlVI/7qxCfyldOmi5DA/7m zEcQ==
X-Gm-Message-State: ALoCoQlaK97dwaPP7jd2b8LmaEU3NrvopGccrV1w4zdBmGWx3YMjWIPlgb9PjYssjx8Pnvpuroup
MIME-Version: 1.0
X-Received: by 10.229.72.10 with SMTP id k10mr44991448qcj.2.1399302327222; Mon, 05 May 2014 08:05:27 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Mon, 5 May 2014 08:05:27 -0700 (PDT)
In-Reply-To: <E0953E12-3AB2-44CC-9A63-7070540CC534@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com> <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com> <E0953E12-3AB2-44CC-9A63-7070540CC534@nic.cz>
Date: Mon, 5 May 2014 08:05:27 -0700
Message-ID: <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=089e0168131825d7ec04f8a87648
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xrQZfvW7aDlXauLi-OcfwV-IQQU
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 15:05:34 -0000

--089e0168131825d7ec04f8a87648
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Andy Bierman <andy@yumaworks.com> writes:
> > >
> > > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > >
> > > >>
> > > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> wrote:
> > > >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > >> >
> > > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <lhotka@nic.cz
> >
> > > >> wrote:
> > > >> > >
> > > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > >> > >
> > > >> > > > Hi,
> > > >> > > >
> > > >> > > > Problem:
> > > >> > > >
> > > >> > > > The use of a leaf in the data model (such as the
> > > >> /interfaces/interface/enabled
> > > >> > > > leaf in the ietf-interfaces module) does not account for YANG
> > > >> validation rules
> > > >> > > > for many statements that can reference the disabled subtree
> from
> > > >> outside
> > > >> > > > of that subtree:
> > > >> > > >
> > > >> > > >     - must
> > > >> > > >     - when
> > > >> > > >     - unique
> > > >> > > >     - min-elements
> > > >> > > >     - max-elements
> > > >> > > >     - leafref (valid instances)
> > > >> > > >     - choices (disabled case is still the active case, so no
> other
> > > >> can be used)
> > > >> > >
> > > >> > > In my view, an "enabled false" leaf *operationally* disables a
> > > >> particular instance or function. For all other purposes related to
> > > >> datastore validation, the value of the enabled leaf doesn't matter.
> In
> > > >> other words, "enabled false" is not the same as commenting out the
> > > >> corresponding instance in the configuration.
> > > >> > >
> > > >> > >
> > > >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > >> > > and YANG designers must know about this leaf.  Adding or
> removing
> > > >> > > this leaf could break other YANG statements.
> > > >> > >
> > > >> > > E,g,
> > > >> > >
> > > >> > >
> > > >> > >    leaf active-foo-interface {
> > > >> > >        type  if:interface-ref;
> > > >> > >        mandatory true;
> > > >> > >    }
> > > >> > >
> > > >> > >
> > > >> > > By YANG validation rules, the  leafref test for interface name
> > > >> > > will include all disabled interfaces.
> > > >> >
> > > >> > Yes.
> > > >> >
> > > >> > >
> > > >> > > Doesn't every object that uses the interface-ref typedef need
> > > >> > > to have a must-stmt making sure the enabled leaf is set,
> > > >> > > if they want to activate a service on only enabled interfaces?
> > > >> > >
> > > >> > > (Is this the must-stmt to use?)
> > > >> > >
> > > >> > >    leaf active-foo-interface {
> > > >> > >        type  if:interface-ref;
> > > >> > >        must
> "/if:interfaces/if:interface[if:name=current()]/enabled";
> > > >> > >        mandatory true;
> > > >> > >    }
> > > >> > >
> > > >> > > Don't all must/when/leafref validation statements that want only
> > > >> > > active interfaces need to be written this way?
> > > >> >
> > > >> > I don't think so. An operator may want to pre-configure an
> interface in
> > > >> the disabled state, set up all references to it etc., so that
> everything
> > > >> will be up and running after setting the single "enabled" leaf to
> true.
> > > >> >
> > > >> > I said "this is what has to be written to identity active
> interfaces"
> > > >> > and you respond "maybe they want to select disabled interfaces".
> > > >>
> > > >> It's up to the server to interpret the entire configuration, so if a
> > > >> service is enabled in configuration but it depends on an interface
> that is
> > > >> currently disabled, the server might keep that service operationally
> > > >> disabled as well.
> > > >>
> > > >>
> > > > Not if the YANG validation rules say differently.
> > > > My point is that the YANG designer must write all validation rules to
> > > > account for disabled configuration, or the model is wrong.
> > >
> > > I don't agree. It would be extremely impractical to render a
> configuration
> > > invalid just by disabling an interface.
> >
> >
> > The important point is that the designer better know every single
> > YANG object and write the validation rules correctly.
> > Inconvenient or not, if some component needs to use
> > only active interfaces, then ignoring the 'active' leaf will be broken.
>
> It will be broken in terms of operational state, not configuration. Many
> changes in configuration have ripple effects and well-designed server
> should be able to trace dependencies and act accordingly, rather than
> forcing the user to do it manually.
>
>

The server cannot ripple the disable event automatically using an ad-hoc
solution,
but that is just an implementation detail to the IETF, so it's not
important.

The reason RowStatus is a bad idea is that it is not config, but it is
mixed in
with the config, and it is config according to YANG validation rules.
When you set the enabled leaf to false with an <edit-config> operation,
you are configuring the interface to be operationally disabled.

All YANG validation outside the interface has to account for interfaces
that have been configured to be operationally disabled.

When the hardware is operationally broken, setting 'enable' to true
is not going to fix it.  The enabled leaf is just the desired state, like
all the other config=true nodes.

I agree that the desired state and operational state are not the same.
I don't agree that setting enabled-leaf to false is the same as the system
disabling a broken interface.


Andy

>
> > The system can be hand-coded at great expense to deal with any
> > poorly designed ad-hoc mechanism.  It is just engineering decisions
> > that determine whether we develop an efficient programmatic API
> > or we develop CLI with angle brackets.
>
> So what would you do with the rules in sec. 6 of the routing module? Note
> that they involve not only "enabled" leafs in the interfaces and ip
> modules, but also "ip:forwarding".
>
> For example, if /if:interfaces/if:interface/if:enabled is set to false for
> an interface, I don't want to force the client to go and remove that
> interface from all configured routing instances.
>
> Similarly, disabling a physical interface should automatically lead to
> disabling all logical interfaces created on top of that physical interface
> - without having to disable all of them manually.
>
> Lada
>
> >
> >
> >
> > I think you are both right - the 'inactive' feature is very useful
> > (and it works just as if the node is deleted), but it doesn't
> > necessarilty replace an "enabled" leaf in all cases.  As you noted,
> > they behave differently.
> >
> >
> >
> > Andy
> >
> >
> > /martin
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--089e0168131825d7ec04f8a87648
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 05 May 2014, at 10:48, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund &lt;<a href=3D"mailt=
o:mbj@tail-f.com">mbj@tail-f.com</a>&gt; wrote:<br>
&gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>=
&gt; wrote:<br>
&gt; &gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaw=
orks.com</a>&gt; writes:<br>
&gt; &gt;<br>
&gt; &gt; &gt; On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka &lt;<a href=
=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; On 04 May 2014, at 10:33, Andy Bierman &lt;<a href=3D"ma=
ilto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka &l=
t;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; On 03 May 2014, at 21:31, Andy Bierman &lt;<a href=
=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhot=
ka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt; &gt; &gt;&gt; wrote:<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; On 03 May 2014, at 18:42, Andy Bierman &lt;<a =
href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; Problem:<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; The use of a leaf in the data model (such=
 as the<br>
&gt; &gt; &gt;&gt; /interfaces/interface/enabled<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; leaf in the ietf-interfaces module) does =
not account for YANG<br>
&gt; &gt; &gt;&gt; validation rules<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; for many statements that can reference th=
e disabled subtree from<br>
&gt; &gt; &gt;&gt; outside<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; of that subtree:<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - must<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - when<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - unique<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - min-elements<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - max-elements<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - leafref (valid instances)=
<br>
&gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - choices (disabled case is=
 still the active case, so no other<br>
&gt; &gt; &gt;&gt; can be used)<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; In my view, an &quot;enabled false&quot; leaf =
*operationally* disables a<br>
&gt; &gt; &gt;&gt; particular instance or function. For all other purposes =
related to<br>
&gt; &gt; &gt;&gt; datastore validation, the value of the enabled leaf does=
n&#39;t matter. In<br>
&gt; &gt; &gt;&gt; other words, &quot;enabled false&quot; is not the same a=
s commenting out the<br>
&gt; &gt; &gt;&gt; corresponding instance in the configuration.<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; OK -- they may be different, but the enabled l=
eaf is ad-hoc,<br>
&gt; &gt; &gt;&gt; &gt; &gt; and YANG designers must know about this leaf. =
&nbsp;Adding or removing<br>
&gt; &gt; &gt;&gt; &gt; &gt; this leaf could break other YANG statements.<b=
r>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; E,g,<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:inter=
face-ref;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; By YANG validation rules, the &nbsp;leafref te=
st for interface name<br>
&gt; &gt; &gt;&gt; &gt; &gt; will include all disabled interfaces.<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; Yes.<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; Doesn&#39;t every object that uses the interfa=
ce-ref typedef need<br>
&gt; &gt; &gt;&gt; &gt; &gt; to have a must-stmt making sure the enabled le=
af is set,<br>
&gt; &gt; &gt;&gt; &gt; &gt; if they want to activate a service on only ena=
bled interfaces?<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; (Is this the must-stmt to use?)<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:inter=
face-ref;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if:inte=
rfaces/if:interface[if:name=3Dcurrent()]/enabled&quot;;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true;<br>
&gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; &gt; Don&#39;t all must/when/leafref validation sta=
tements that want only<br>
&gt; &gt; &gt;&gt; &gt; &gt; active interfaces need to be written this way?=
<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; I don&#39;t think so. An operator may want to pre-c=
onfigure an interface in<br>
&gt; &gt; &gt;&gt; the disabled state, set up all references to it etc., so=
 that everything<br>
&gt; &gt; &gt;&gt; will be up and running after setting the single &quot;en=
abled&quot; leaf to true.<br>
&gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt;&gt; &gt; I said &quot;this is what has to be written to iden=
tity active interfaces&quot;<br>
&gt; &gt; &gt;&gt; &gt; and you respond &quot;maybe they want to select dis=
abled interfaces&quot;.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt; It&#39;s up to the server to interpret the entire config=
uration, so if a<br>
&gt; &gt; &gt;&gt; service is enabled in configuration but it depends on an=
 interface that is<br>
&gt; &gt; &gt;&gt; currently disabled, the server might keep that service o=
perationally<br>
&gt; &gt; &gt;&gt; disabled as well.<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; Not if the YANG validation rules say differently.<br>
&gt; &gt; &gt; My point is that the YANG designer must write all validation=
 rules to<br>
&gt; &gt; &gt; account for disabled configuration, or the model is wrong.<b=
r>
&gt; &gt;<br>
&gt; &gt; I don&#39;t agree. It would be extremely impractical to render a =
configuration<br>
&gt; &gt; invalid just by disabling an interface.<br>
&gt;<br>
&gt;<br>
&gt; The important point is that the designer better know every single<br>
&gt; YANG object and write the validation rules correctly.<br>
&gt; Inconvenient or not, if some component needs to use<br>
&gt; only active interfaces, then ignoring the &#39;active&#39; leaf will b=
e broken.<br>
<br>
It will be broken in terms of operational state, not configuration. Many ch=
anges in configuration have ripple effects and well-designed server should =
be able to trace dependencies and act accordingly, rather than forcing the =
user to do it manually.<br>

<br></blockquote><div><br></div><div><br></div><div>The server cannot rippl=
e the disable event automatically using an ad-hoc solution,</div><div>but t=
hat is just an implementation detail to the IETF, so it&#39;s not important=
.</div>
<div><br></div><div>The reason RowStatus is a bad idea is that it is not co=
nfig, but it is mixed in</div><div>with the config, and it is config accord=
ing to YANG validation rules.</div><div>When you set the enabled leaf to fa=
lse with an &lt;edit-config&gt; operation,</div>
<div>you are configuring the interface to be operationally disabled.</div><=
div><br></div><div>All YANG validation outside the interface has to account=
 for interfaces</div><div>that have been configured to be operationally dis=
abled.</div>
<div><br></div><div>When the hardware is operationally broken, setting &#39=
;enable&#39; to true</div><div>is not going to fix it. &nbsp;The enabled le=
af is just the desired state, like</div><div>all the other config=3Dtrue no=
des.</div>
<div><br></div><div>I agree that the desired state and operational state ar=
e not the same.<br></div><div>I don&#39;t agree that setting enabled-leaf t=
o false is the same as the system</div><div>disabling a broken interface.</=
div>
<div><br></div><div><br></div><div>Andy</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
&gt;<br>
&gt; The system can be hand-coded at great expense to deal with any<br>
&gt; poorly designed ad-hoc mechanism. &nbsp;It is just engineering decisio=
ns<br>
&gt; that determine whether we develop an efficient programmatic API<br>
&gt; or we develop CLI with angle brackets.<br>
<br>
So what would you do with the rules in sec. 6 of the routing module? Note t=
hat they involve not only &ldquo;enabled&rdquo; leafs in the interfaces and=
 ip modules, but also &ldquo;ip:forwarding&rdquo;.<br>
<br>
For example, if /if:interfaces/if:interface/if:enabled is set to false for =
an interface, I don&rsquo;t want to force the client to go and remove that =
interface from all configured routing instances.<br>
<br>
Similarly, disabling a physical interface should automatically lead to disa=
bling all logical interfaces created on top of that physical interface - wi=
thout having to disable all of them manually.<br>
<br>
Lada<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I think you are both right - the &#39;inactive&#39; feature is very us=
eful<br>
&gt; (and it works just as if the node is deleted), but it doesn&#39;t<br>
&gt; necessarilty replace an &quot;enabled&quot; leaf in all cases. &nbsp;A=
s you noted,<br>
&gt; they behave differently.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; /martin<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--089e0168131825d7ec04f8a87648--


From nobody Mon May  5 09:25:54 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7031A03C8 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 09:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O45ebd1KXjGS for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 09:25:28 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5DB1A00C6 for <netmod@ietf.org>; Mon,  5 May 2014 09:25:28 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5BEB413F9D0; Mon,  5 May 2014 18:25:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399307124; bh=5+NR4GQHMvSFCvv17uTLevwS4FDfPYY1TH/9CsYWfEE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N9zBnV2kd2lf99S8uE3WvULgc7ALY/feurDV31TGuXcqApM/TxgPaDHlWdsECIZqL Edo6RfTzYR2bz6BoN1KK0hPELunXrKnBADH0eyTcHwBWaNnR++6m7DW/wusgcgZL5C VAdL0HLZqfcaDEK73PJIi2aBxai3hKHEFzi2EGuY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com>
Date: Mon, 5 May 2014 18:25:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com> <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com> <E0953E12-3AB2-44CC-9A63-7070540CC534@nic.cz> <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rf9d99xhyqdP3ZBmk2_Ce7bgreY
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 16:25:31 -0000

On 05 May 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>=20
> On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Andy Bierman <andy@yumaworks.com> writes:
> > >
> > > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> > > >
> > > >>
> > > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com> =
wrote:
> > > >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka =
<lhotka@nic.cz> wrote:
> > > >> >
> > > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com> =
wrote:
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka =
<lhotka@nic.cz>
> > > >> wrote:
> > > >> > >
> > > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com> =
wrote:
> > > >> > >
> > > >> > > > Hi,
> > > >> > > >
> > > >> > > > Problem:
> > > >> > > >
> > > >> > > > The use of a leaf in the data model (such as the
> > > >> /interfaces/interface/enabled
> > > >> > > > leaf in the ietf-interfaces module) does not account for =
YANG
> > > >> validation rules
> > > >> > > > for many statements that can reference the disabled =
subtree from
> > > >> outside
> > > >> > > > of that subtree:
> > > >> > > >
> > > >> > > >     - must
> > > >> > > >     - when
> > > >> > > >     - unique
> > > >> > > >     - min-elements
> > > >> > > >     - max-elements
> > > >> > > >     - leafref (valid instances)
> > > >> > > >     - choices (disabled case is still the active case, so =
no other
> > > >> can be used)
> > > >> > >
> > > >> > > In my view, an "enabled false" leaf *operationally* =
disables a
> > > >> particular instance or function. For all other purposes related =
to
> > > >> datastore validation, the value of the enabled leaf doesn't =
matter. In
> > > >> other words, "enabled false" is not the same as commenting out =
the
> > > >> corresponding instance in the configuration.
> > > >> > >
> > > >> > >
> > > >> > > OK -- they may be different, but the enabled leaf is =
ad-hoc,
> > > >> > > and YANG designers must know about this leaf.  Adding or =
removing
> > > >> > > this leaf could break other YANG statements.
> > > >> > >
> > > >> > > E,g,
> > > >> > >
> > > >> > >
> > > >> > >    leaf active-foo-interface {
> > > >> > >        type  if:interface-ref;
> > > >> > >        mandatory true;
> > > >> > >    }
> > > >> > >
> > > >> > >
> > > >> > > By YANG validation rules, the  leafref test for interface =
name
> > > >> > > will include all disabled interfaces.
> > > >> >
> > > >> > Yes.
> > > >> >
> > > >> > >
> > > >> > > Doesn't every object that uses the interface-ref typedef =
need
> > > >> > > to have a must-stmt making sure the enabled leaf is set,
> > > >> > > if they want to activate a service on only enabled =
interfaces?
> > > >> > >
> > > >> > > (Is this the must-stmt to use?)
> > > >> > >
> > > >> > >    leaf active-foo-interface {
> > > >> > >        type  if:interface-ref;
> > > >> > >        must =
"/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled";
> > > >> > >        mandatory true;
> > > >> > >    }
> > > >> > >
> > > >> > > Don't all must/when/leafref validation statements that want =
only
> > > >> > > active interfaces need to be written this way?
> > > >> >
> > > >> > I don't think so. An operator may want to pre-configure an =
interface in
> > > >> the disabled state, set up all references to it etc., so that =
everything
> > > >> will be up and running after setting the single "enabled" leaf =
to true.
> > > >> >
> > > >> > I said "this is what has to be written to identity active =
interfaces"
> > > >> > and you respond "maybe they want to select disabled =
interfaces".
> > > >>
> > > >> It's up to the server to interpret the entire configuration, so =
if a
> > > >> service is enabled in configuration but it depends on an =
interface that is
> > > >> currently disabled, the server might keep that service =
operationally
> > > >> disabled as well.
> > > >>
> > > >>
> > > > Not if the YANG validation rules say differently.
> > > > My point is that the YANG designer must write all validation =
rules to
> > > > account for disabled configuration, or the model is wrong.
> > >
> > > I don't agree. It would be extremely impractical to render a =
configuration
> > > invalid just by disabling an interface.
> >
> >
> > The important point is that the designer better know every single
> > YANG object and write the validation rules correctly.
> > Inconvenient or not, if some component needs to use
> > only active interfaces, then ignoring the 'active' leaf will be =
broken.
>=20
> It will be broken in terms of operational state, not configuration. =
Many changes in configuration have ripple effects and well-designed =
server should be able to trace dependencies and act accordingly, rather =
than forcing the user to do it manually.
>=20
>=20
>=20
> The server cannot ripple the disable event automatically using an =
ad-hoc solution,
> but that is just an implementation detail to the IETF, so it's not =
important.

Of course it can, why not? An implementor of the routing module is =
expected to follow sec. 6 rules. It is just not so that the same =
callback can be used whenever any =93enabled=94 leaf is changed.

>=20
> The reason RowStatus is a bad idea is that it is not config, but it is =
mixed in
> with the config, and it is config according to YANG validation rules.
> When you set the enabled leaf to false with an <edit-config> =
operation,
> you are configuring the interface to be operationally disabled.

Yes.

>=20
> All YANG validation outside the interface has to account for =
interfaces
> that have been configured to be operationally disabled.

This is where we differ, as long as you talk about configuration. The =
ex-vlan module in interfaces draft doesn=92t have any must statement =
requiring that the base-interface be enabled.

>=20
> When the hardware is operationally broken, setting 'enable' to true
> is not going to fix it.  The enabled leaf is just the desired state, =
like
> all the other config=3Dtrue nodes.

Sure.

>=20
> I agree that the desired state and operational state are not the same.
> I don't agree that setting enabled-leaf to false is the same as the =
system
> disabling a broken interface.

Where did I say that?

Lada

>=20
>=20
> Andy
>=20
> >
> > The system can be hand-coded at great expense to deal with any
> > poorly designed ad-hoc mechanism.  It is just engineering decisions
> > that determine whether we develop an efficient programmatic API
> > or we develop CLI with angle brackets.
>=20
> So what would you do with the rules in sec. 6 of the routing module? =
Note that they involve not only =93enabled=94 leafs in the interfaces =
and ip modules, but also =93ip:forwarding=94.
>=20
> For example, if /if:interfaces/if:interface/if:enabled is set to false =
for an interface, I don=92t want to force the client to go and remove =
that interface from all configured routing instances.
>=20
> Similarly, disabling a physical interface should automatically lead to =
disabling all logical interfaces created on top of that physical =
interface - without having to disable all of them manually.
>=20
> Lada
>=20
> >
> >
> >
> > I think you are both right - the 'inactive' feature is very useful
> > (and it works just as if the node is deleted), but it doesn't
> > necessarilty replace an "enabled" leaf in all cases.  As you noted,
> > they behave differently.
> >
> >
> >
> > Andy
> >
> >
> > /martin
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May  5 10:21:25 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7741A01BB for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 10:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level: 
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVsyQ_14vB4i for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 10:21:17 -0700 (PDT)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 999231A02F6 for <netmod@ietf.org>; Mon,  5 May 2014 10:21:17 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id m20so4935976qcx.40 for <netmod@ietf.org>; Mon, 05 May 2014 10:21:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6P2zHB9pFgszMrL4j4PMzDJIQBICJY9rL70KMluGiW4=; b=K32T4sX8i78++2NMUTct8vzVdNvnKPFXFiWe3ANR6FOQUUy3GgSPseKSnc1yr9rpj+ xXsmi/dVvWSH0wc96Ec00u7mt+kGLa7I9Jo5RHtTtHTLQ7Jl95AhT4ECXJ5nG8DCSK5k MHfVW7Rdg5eztKxnILpED/FhXDAyycOiSx2AP9bRmCpKNyktheWxTVISwLt6u3N1JH/6 9l3fUfBHIKazobHwz4nWMSC5Shq7b0d7ti74pIkjXCQm6jXPpHa0GCwjsMQVRNrNIogv 5p0874ov5Kg/fta2gmX46sky8fOl6dzfehyQB6qAuk3+A1077jmDAIUXyYcsRpJTIkrD g3Cw==
X-Gm-Message-State: ALoCoQniOwfalQoU/rS+7eTxj7lB9RziW4CfuogAayW9cvhYqBN231ffY+YbfZTPWZOSd4Xmxfuk
MIME-Version: 1.0
X-Received: by 10.224.138.3 with SMTP id y3mr46858203qat.78.1399310473980; Mon, 05 May 2014 10:21:13 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Mon, 5 May 2014 10:21:13 -0700 (PDT)
In-Reply-To: <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com> <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com> <E0953E12-3AB2-44CC-9A63-7070540CC534@nic.cz> <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com> <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz>
Date: Mon, 5 May 2014 10:21:13 -0700
Message-ID: <CABCOCHQFruGPF40BNJMBzyxBbJ9L0unLaynZ0RxUTaLpg0BM5A@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=047d7b672b44bb84b904f8aa5b0c
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7Lv8szm1ebbUiLiTWiUvl_7FX-Q
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 17:21:22 -0000

--047d7b672b44bb84b904f8aa5b0c
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 05 May 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > Andy Bierman <andy@yumaworks.com> writes:
> > > >
> > > > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > > >
> > > > >>
> > > > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > > >> >
> > > > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <
> lhotka@nic.cz>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > > >> > >
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > Problem:
> > > > >> > > >
> > > > >> > > > The use of a leaf in the data model (such as the
> > > > >> /interfaces/interface/enabled
> > > > >> > > > leaf in the ietf-interfaces module) does not account for
> YANG
> > > > >> validation rules
> > > > >> > > > for many statements that can reference the disabled subtree
> from
> > > > >> outside
> > > > >> > > > of that subtree:
> > > > >> > > >
> > > > >> > > >     - must
> > > > >> > > >     - when
> > > > >> > > >     - unique
> > > > >> > > >     - min-elements
> > > > >> > > >     - max-elements
> > > > >> > > >     - leafref (valid instances)
> > > > >> > > >     - choices (disabled case is still the active case, so
> no other
> > > > >> can be used)
> > > > >> > >
> > > > >> > > In my view, an "enabled false" leaf *operationally* disables a
> > > > >> particular instance or function. For all other purposes related to
> > > > >> datastore validation, the value of the enabled leaf doesn't
> matter. In
> > > > >> other words, "enabled false" is not the same as commenting out the
> > > > >> corresponding instance in the configuration.
> > > > >> > >
> > > > >> > >
> > > > >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > > >> > > and YANG designers must know about this leaf.  Adding or
> removing
> > > > >> > > this leaf could break other YANG statements.
> > > > >> > >
> > > > >> > > E,g,
> > > > >> > >
> > > > >> > >
> > > > >> > >    leaf active-foo-interface {
> > > > >> > >        type  if:interface-ref;
> > > > >> > >        mandatory true;
> > > > >> > >    }
> > > > >> > >
> > > > >> > >
> > > > >> > > By YANG validation rules, the  leafref test for interface name
> > > > >> > > will include all disabled interfaces.
> > > > >> >
> > > > >> > Yes.
> > > > >> >
> > > > >> > >
> > > > >> > > Doesn't every object that uses the interface-ref typedef need
> > > > >> > > to have a must-stmt making sure the enabled leaf is set,
> > > > >> > > if they want to activate a service on only enabled interfaces?
> > > > >> > >
> > > > >> > > (Is this the must-stmt to use?)
> > > > >> > >
> > > > >> > >    leaf active-foo-interface {
> > > > >> > >        type  if:interface-ref;
> > > > >> > >        must
> "/if:interfaces/if:interface[if:name=current()]/enabled";
> > > > >> > >        mandatory true;
> > > > >> > >    }
> > > > >> > >
> > > > >> > > Don't all must/when/leafref validation statements that want
> only
> > > > >> > > active interfaces need to be written this way?
> > > > >> >
> > > > >> > I don't think so. An operator may want to pre-configure an
> interface in
> > > > >> the disabled state, set up all references to it etc., so that
> everything
> > > > >> will be up and running after setting the single "enabled" leaf to
> true.
> > > > >> >
> > > > >> > I said "this is what has to be written to identity active
> interfaces"
> > > > >> > and you respond "maybe they want to select disabled interfaces".
> > > > >>
> > > > >> It's up to the server to interpret the entire configuration, so
> if a
> > > > >> service is enabled in configuration but it depends on an
> interface that is
> > > > >> currently disabled, the server might keep that service
> operationally
> > > > >> disabled as well.
> > > > >>
> > > > >>
> > > > > Not if the YANG validation rules say differently.
> > > > > My point is that the YANG designer must write all validation rules
> to
> > > > > account for disabled configuration, or the model is wrong.
> > > >
> > > > I don't agree. It would be extremely impractical to render a
> configuration
> > > > invalid just by disabling an interface.
> > >
> > >
> > > The important point is that the designer better know every single
> > > YANG object and write the validation rules correctly.
> > > Inconvenient or not, if some component needs to use
> > > only active interfaces, then ignoring the 'active' leaf will be broken.
> >
> > It will be broken in terms of operational state, not configuration. Many
> changes in configuration have ripple effects and well-designed server
> should be able to trace dependencies and act accordingly, rather than
> forcing the user to do it manually.
> >
> >
> >
> > The server cannot ripple the disable event automatically using an ad-hoc
> solution,
> > but that is just an implementation detail to the IETF, so it's not
> important.
>
> Of course it can, why not? An implementor of the routing module is
> expected to follow sec. 6 rules. It is just not so that the same callback
> can be used whenever any "enabled" leaf is changed.
>

I meant "automatically" to be automated, not hand-coded.
The more free-form behavior that is defined in text instead of
some sort of structured statement, the more hand-coding.



> >
> > The reason RowStatus is a bad idea is that it is not config, but it is
> mixed in
> > with the config, and it is config according to YANG validation rules.
> > When you set the enabled leaf to false with an <edit-config> operation,
> > you are configuring the interface to be operationally disabled.
>
> Yes.
>
> >
> > All YANG validation outside the interface has to account for interfaces
> > that have been configured to be operationally disabled.
>
> This is where we differ, as long as you talk about configuration. The
> ex-vlan module in interfaces draft doesn't have any must statement
> requiring that the base-interface be enabled.
>
>
The design still has to account for the enabled leaf.
You decided it doesn't matter for that specific ad-hoc case.

Let's say the site has a SLA that says a certain server needs to
always have at least 1 operationally enabled interface at all times.
In that case, the enabled=false interfaces need to be checked.
The operator is not allowed to configure all interfaces to be disabled.

I guess we don't agree that this is some sort of repeatable design pattern
that does not have to be defined in free-form text.



> >
> > When the hardware is operationally broken, setting 'enable' to true
> > is not going to fix it.  The enabled leaf is just the desired state, like
> > all the other config=true nodes.
>
> Sure.
>
> >
> > I agree that the desired state and operational state are not the same.
> > I don't agree that setting enabled-leaf to false is the same as the
> system
> > disabling a broken interface.
>
> Where did I say that?
>

Lada
>
>

Andy


> >
> >
> > Andy
> >
> > >
> > > The system can be hand-coded at great expense to deal with any
> > > poorly designed ad-hoc mechanism.  It is just engineering decisions
> > > that determine whether we develop an efficient programmatic API
> > > or we develop CLI with angle brackets.
> >
> > So what would you do with the rules in sec. 6 of the routing module?
> Note that they involve not only "enabled" leafs in the interfaces and ip
> modules, but also "ip:forwarding".
> >
> > For example, if /if:interfaces/if:interface/if:enabled is set to false
> for an interface, I don't want to force the client to go and remove that
> interface from all configured routing instances.
> >
> > Similarly, disabling a physical interface should automatically lead to
> disabling all logical interfaces created on top of that physical interface
> - without having to disable all of them manually.
> >
> > Lada
> >
> > >
> > >
> > >
> > > I think you are both right - the 'inactive' feature is very useful
> > > (and it works just as if the node is deleted), but it doesn't
> > > necessarilty replace an "enabled" leaf in all cases.  As you noted,
> > > they behave differently.
> > >
> > >
> > >
> > > Andy
> > >
> > >
> > > /martin
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--047d7b672b44bb84b904f8aa5b0c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 05 May 2014, at 17:05, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka &lt;<a href=3D"mailto:=
lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 05 May 2014, at 10:48, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund &lt;<a href=3D"=
mailto:mbj@tail-f.com">mbj@tail-f.com</a>&gt; wrote:<br>
&gt; &gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.c=
z</a>&gt; wrote:<br>
&gt; &gt; &gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@=
yumaworks.com</a>&gt; writes:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka &lt;<a =
href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; On 04 May 2014, at 10:33, Andy Bierman &lt;<a href=
=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhot=
ka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; On 03 May 2014, at 21:31, Andy Bierman &lt;<a =
href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav=
 Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; On 03 May 2014, at 18:42, Andy Bierman &l=
t;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<b=
r>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; Problem:<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; The use of a leaf in the data model =
(such as the<br>
&gt; &gt; &gt; &gt;&gt; /interfaces/interface/enabled<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; leaf in the ietf-interfaces module) =
does not account for YANG<br>
&gt; &gt; &gt; &gt;&gt; validation rules<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; for many statements that can referen=
ce the disabled subtree from<br>
&gt; &gt; &gt; &gt;&gt; outside<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; of that subtree:<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - must<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - when<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - unique<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - min-elements<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - max-elements<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - leafref (valid insta=
nces)<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - choices (disabled ca=
se is still the active case, so no other<br>
&gt; &gt; &gt; &gt;&gt; can be used)<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; In my view, an &quot;enabled false&quot; =
leaf *operationally* disables a<br>
&gt; &gt; &gt; &gt;&gt; particular instance or function. For all other purp=
oses related to<br>
&gt; &gt; &gt; &gt;&gt; datastore validation, the value of the enabled leaf=
 doesn&#39;t matter. In<br>
&gt; &gt; &gt; &gt;&gt; other words, &quot;enabled false&quot; is not the s=
ame as commenting out the<br>
&gt; &gt; &gt; &gt;&gt; corresponding instance in the configuration.<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; OK -- they may be different, but the enab=
led leaf is ad-hoc,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; and YANG designers must know about this l=
eaf. &nbsp;Adding or removing<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; this leaf could break other YANG statemen=
ts.<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; E,g,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<=
br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:=
interface-ref;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true=
;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; By YANG validation rules, the &nbsp;leafr=
ef test for interface name<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; will include all disabled interfaces.<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; Yes.<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; Doesn&#39;t every object that uses the in=
terface-ref typedef need<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; to have a must-stmt making sure the enabl=
ed leaf is set,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; if they want to activate a service on onl=
y enabled interfaces?<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; (Is this the must-stmt to use?)<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<=
br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:=
interface-ref;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if=
:interfaces/if:interface[if:name=3Dcurrent()]/enabled&quot;;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true=
;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; Don&#39;t all must/when/leafref validatio=
n statements that want only<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; active interfaces need to be written this=
 way?<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; I don&#39;t think so. An operator may want to =
pre-configure an interface in<br>
&gt; &gt; &gt; &gt;&gt; the disabled state, set up all references to it etc=
., so that everything<br>
&gt; &gt; &gt; &gt;&gt; will be up and running after setting the single &qu=
ot;enabled&quot; leaf to true.<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; I said &quot;this is what has to be written to=
 identity active interfaces&quot;<br>
&gt; &gt; &gt; &gt;&gt; &gt; and you respond &quot;maybe they want to selec=
t disabled interfaces&quot;.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; It&#39;s up to the server to interpret the entire c=
onfiguration, so if a<br>
&gt; &gt; &gt; &gt;&gt; service is enabled in configuration but it depends =
on an interface that is<br>
&gt; &gt; &gt; &gt;&gt; currently disabled, the server might keep that serv=
ice operationally<br>
&gt; &gt; &gt; &gt;&gt; disabled as well.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt; Not if the YANG validation rules say differently.<br>
&gt; &gt; &gt; &gt; My point is that the YANG designer must write all valid=
ation rules to<br>
&gt; &gt; &gt; &gt; account for disabled configuration, or the model is wro=
ng.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I don&#39;t agree. It would be extremely impractical to rend=
er a configuration<br>
&gt; &gt; &gt; invalid just by disabling an interface.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; The important point is that the designer better know every single=
<br>
&gt; &gt; YANG object and write the validation rules correctly.<br>
&gt; &gt; Inconvenient or not, if some component needs to use<br>
&gt; &gt; only active interfaces, then ignoring the &#39;active&#39; leaf w=
ill be broken.<br>
&gt;<br>
&gt; It will be broken in terms of operational state, not configuration. Ma=
ny changes in configuration have ripple effects and well-designed server sh=
ould be able to trace dependencies and act accordingly, rather than forcing=
 the user to do it manually.<br>

&gt;<br>
&gt;<br>
&gt;<br>
&gt; The server cannot ripple the disable event automatically using an ad-h=
oc solution,<br>
&gt; but that is just an implementation detail to the IETF, so it&#39;s not=
 important.<br>
<br>
Of course it can, why not? An implementor of the routing module is expected=
 to follow sec. 6 rules. It is just not so that the same callback can be us=
ed whenever any &ldquo;enabled&rdquo; leaf is changed.<br></blockquote><div=
><br></div>
<div>I meant &quot;automatically&quot; to be automated, not hand-coded.</di=
v><div>The more free-form behavior that is defined in text instead of</div>=
<div>some sort of structured statement, the more hand-coding.</div><div>
<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;<br>
&gt; The reason RowStatus is a bad idea is that it is not config, but it is=
 mixed in<br>
&gt; with the config, and it is config according to YANG validation rules.<=
br>
&gt; When you set the enabled leaf to false with an &lt;edit-config&gt; ope=
ration,<br>
&gt; you are configuring the interface to be operationally disabled.<br>
<br>
Yes.<br>
<br>
&gt;<br>
&gt; All YANG validation outside the interface has to account for interface=
s<br>
&gt; that have been configured to be operationally disabled.<br>
<br>
This is where we differ, as long as you talk about configuration. The ex-vl=
an module in interfaces draft doesn&rsquo;t have any must statement requiri=
ng that the base-interface be enabled.<br>
<br></blockquote><div><br></div><div>The design still has to account for th=
e enabled leaf.</div><div>You decided it doesn&#39;t matter for that specif=
ic ad-hoc case.</div><div><br></div><div>Let&#39;s say the site has a SLA t=
hat says a certain server needs to</div>
<div>always have at least 1 operationally enabled interface at all times.</=
div><div>In that case, the enabled=3Dfalse interfaces need to be checked.</=
div><div>The operator is not allowed to configure all interfaces to be disa=
bled.</div>
<div><br></div><div>I guess we don&#39;t agree that this is some sort of re=
peatable design pattern</div><div>that does not have to be defined in free-=
form text.</div><div><br></div><div>&nbsp;<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

&gt;<br>
&gt; When the hardware is operationally broken, setting &#39;enable&#39; to=
 true<br>
&gt; is not going to fix it. &nbsp;The enabled leaf is just the desired sta=
te, like<br>
&gt; all the other config=3Dtrue nodes.<br>
<br>
Sure.<br>
<br>
&gt;<br>
&gt; I agree that the desired state and operational state are not the same.=
<br>
&gt; I don&#39;t agree that setting enabled-leaf to false is the same as th=
e system<br>
&gt; disabling a broken interface.<br>
<br>
Where did I say that?<br></blockquote><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
Lada<br>
<br></blockquote><div><br></div><div><br></div><div>Andy</div><div>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; The system can be hand-coded at great expense to deal with any<br=
>
&gt; &gt; poorly designed ad-hoc mechanism. &nbsp;It is just engineering de=
cisions<br>
&gt; &gt; that determine whether we develop an efficient programmatic API<b=
r>
&gt; &gt; or we develop CLI with angle brackets.<br>
&gt;<br>
&gt; So what would you do with the rules in sec. 6 of the routing module? N=
ote that they involve not only &ldquo;enabled&rdquo; leafs in the interface=
s and ip modules, but also &ldquo;ip:forwarding&rdquo;.<br>
&gt;<br>
&gt; For example, if /if:interfaces/if:interface/if:enabled is set to false=
 for an interface, I don&rsquo;t want to force the client to go and remove =
that interface from all configured routing instances.<br>
&gt;<br>
&gt; Similarly, disabling a physical interface should automatically lead to=
 disabling all logical interfaces created on top of that physical interface=
 - without having to disable all of them manually.<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I think you are both right - the &#39;inactive&#39; feature is ve=
ry useful<br>
&gt; &gt; (and it works just as if the node is deleted), but it doesn&#39;t=
<br>
&gt; &gt; necessarilty replace an &quot;enabled&quot; leaf in all cases. &n=
bsp;As you noted,<br>
&gt; &gt; they behave differently.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; /martin<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--047d7b672b44bb84b904f8aa5b0c--


From nobody Mon May  5 10:55:35 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F9D1A03A5 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 10:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grQO2XhYvrMy for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 10:55:27 -0700 (PDT)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 80F431A038E for <netmod@ietf.org>; Mon,  5 May 2014 10:55:27 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id l6so3427843qcy.9 for <netmod@ietf.org>; Mon, 05 May 2014 10:55:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OG/HpwejJzZV4bV3Mq9Vco8GxlUKH2alQiC7cEpXrjE=; b=XPjBlIl1X80QkK+bnvJWxgx+D7WI71IfEUnjPwLEWZq/+CjE6pd1On92m02EUSNC4u N65JuMXiBmK0FIPTVe262pM+9XZOnO7jtcR0i34uA4DH2KcgYboa1NsmvYN6IahzzfWy RqHz+khuyDqOil5F+WL4FQn1ikNFUWB8Ck+mB8PopUGzJO0Bgt5mgm6TCnpXbTJUC05r eYX41+4on+yY6ljuKFUAs5mnFg7Xt0gxz8zbQpoT3JjWQ2me94STBpfRAvNMwqrxM1CA bewGsv8YRo63/abqKLRfBHHPZBmHJLj0e4L0ULzxc2kvL3xW70OYZPK+D0y1LxBx6w34 ZYEw==
X-Gm-Message-State: ALoCoQlhYbexYd1YQjOG2hGOiHhK1BC/52Zc+bT6R2C32veFpLbS5z7VbW9rMx2ITWWMv5td47OS
MIME-Version: 1.0
X-Received: by 10.224.55.6 with SMTP id s6mr11619354qag.7.1399312523796; Mon, 05 May 2014 10:55:23 -0700 (PDT)
Received: by 10.140.104.14 with HTTP; Mon, 5 May 2014 10:55:23 -0700 (PDT)
In-Reply-To: <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz>
References: <1D1A1E83-05E3-4449-B8F7-BEFFC716C45B@nic.cz> <CABCOCHThWqmO1cUgxSJFVrKn4GC10af4_rFtf8LUL-Z5i=-yMA@mail.gmail.com> <m28uqgd7oc.fsf@nic.cz> <20140505.092632.235496358.mbj@tail-f.com> <CABCOCHSUjLPuLvtK5WpTkZGgTrgDv-p6ZDim=nxpLYRvR85acg@mail.gmail.com> <E0953E12-3AB2-44CC-9A63-7070540CC534@nic.cz> <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com> <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz>
Date: Mon, 5 May 2014 10:55:23 -0700
Message-ID: <CABCOCHR_FqKUaj+HNSRMDgimR760XHXRL9Jy9N_35vjEHrfffA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=089e0153705ee9385e04f8aad5e9
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cUCbPnGjjElbu35kLnw7-F5-U6o
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 17:55:32 -0000

--089e0153705ee9385e04f8aad5e9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Here is what I mean by a typedef solution.
Why did the WG decide this cannot work?

OLD:

         leaf enabled {
           type boolean;
           default "true";
           description
             "This leaf contains the configured, desired state of the
              interface.
              Systems that implement the IF-MIB use the value of this
              leaf in the 'running' datastore to set
              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
              has been initialized, as described in RFC 2863.

              Changes in this leaf in the 'running' datastore are
              reflected in ifAdminStatus, but if ifAdminStatus is
              changed over SNMP, this leaf is not affected.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }

NEW:

         // this is a general typedef, probably in ietf-yang-types

         typedef oper-enabled {
           type boolean;
           description
             "Used to operationally disable some configuration.
              The affected configuration SHOULD be limited to
              the parent node of the leaf using this typedef,
              but it MAY affect other configuration as described
              in the module.";
         }


         leaf enabled {
           type yang:oper-enabled;
           default "true";
           description
             "This leaf contains the configured, desired state of the
              interface.
              Systems that implement the IF-MIB use the value of this
              leaf in the 'running' datastore to set
              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
              has been initialized, as described in RFC 2863.

              Changes in this leaf in the 'running' datastore are
              reflected in ifAdminStatus, but if ifAdminStatus is
              changed over SNMP, this leaf is not affected.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
         }


Andy




On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 05 May 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > Andy Bierman <andy@yumaworks.com> writes:
> > > >
> > > > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > > >
> > > > >>
> > > > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > > >> >
> > > > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <
> lhotka@nic.cz>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
> wrote:
> > > > >> > >
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > Problem:
> > > > >> > > >
> > > > >> > > > The use of a leaf in the data model (such as the
> > > > >> /interfaces/interface/enabled
> > > > >> > > > leaf in the ietf-interfaces module) does not account for
> YANG
> > > > >> validation rules
> > > > >> > > > for many statements that can reference the disabled subtree
> from
> > > > >> outside
> > > > >> > > > of that subtree:
> > > > >> > > >
> > > > >> > > >     - must
> > > > >> > > >     - when
> > > > >> > > >     - unique
> > > > >> > > >     - min-elements
> > > > >> > > >     - max-elements
> > > > >> > > >     - leafref (valid instances)
> > > > >> > > >     - choices (disabled case is still the active case, so
> no other
> > > > >> can be used)
> > > > >> > >
> > > > >> > > In my view, an "enabled false" leaf *operationally* disables a
> > > > >> particular instance or function. For all other purposes related to
> > > > >> datastore validation, the value of the enabled leaf doesn't
> matter. In
> > > > >> other words, "enabled false" is not the same as commenting out the
> > > > >> corresponding instance in the configuration.
> > > > >> > >
> > > > >> > >
> > > > >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > > >> > > and YANG designers must know about this leaf.  Adding or
> removing
> > > > >> > > this leaf could break other YANG statements.
> > > > >> > >
> > > > >> > > E,g,
> > > > >> > >
> > > > >> > >
> > > > >> > >    leaf active-foo-interface {
> > > > >> > >        type  if:interface-ref;
> > > > >> > >        mandatory true;
> > > > >> > >    }
> > > > >> > >
> > > > >> > >
> > > > >> > > By YANG validation rules, the  leafref test for interface name
> > > > >> > > will include all disabled interfaces.
> > > > >> >
> > > > >> > Yes.
> > > > >> >
> > > > >> > >
> > > > >> > > Doesn't every object that uses the interface-ref typedef need
> > > > >> > > to have a must-stmt making sure the enabled leaf is set,
> > > > >> > > if they want to activate a service on only enabled interfaces?
> > > > >> > >
> > > > >> > > (Is this the must-stmt to use?)
> > > > >> > >
> > > > >> > >    leaf active-foo-interface {
> > > > >> > >        type  if:interface-ref;
> > > > >> > >        must
> "/if:interfaces/if:interface[if:name=current()]/enabled";
> > > > >> > >        mandatory true;
> > > > >> > >    }
> > > > >> > >
> > > > >> > > Don't all must/when/leafref validation statements that want
> only
> > > > >> > > active interfaces need to be written this way?
> > > > >> >
> > > > >> > I don't think so. An operator may want to pre-configure an
> interface in
> > > > >> the disabled state, set up all references to it etc., so that
> everything
> > > > >> will be up and running after setting the single "enabled" leaf to
> true.
> > > > >> >
> > > > >> > I said "this is what has to be written to identity active
> interfaces"
> > > > >> > and you respond "maybe they want to select disabled interfaces".
> > > > >>
> > > > >> It's up to the server to interpret the entire configuration, so
> if a
> > > > >> service is enabled in configuration but it depends on an
> interface that is
> > > > >> currently disabled, the server might keep that service
> operationally
> > > > >> disabled as well.
> > > > >>
> > > > >>
> > > > > Not if the YANG validation rules say differently.
> > > > > My point is that the YANG designer must write all validation rules
> to
> > > > > account for disabled configuration, or the model is wrong.
> > > >
> > > > I don't agree. It would be extremely impractical to render a
> configuration
> > > > invalid just by disabling an interface.
> > >
> > >
> > > The important point is that the designer better know every single
> > > YANG object and write the validation rules correctly.
> > > Inconvenient or not, if some component needs to use
> > > only active interfaces, then ignoring the 'active' leaf will be broken.
> >
> > It will be broken in terms of operational state, not configuration. Many
> changes in configuration have ripple effects and well-designed server
> should be able to trace dependencies and act accordingly, rather than
> forcing the user to do it manually.
> >
> >
> >
> > The server cannot ripple the disable event automatically using an ad-hoc
> solution,
> > but that is just an implementation detail to the IETF, so it's not
> important.
>
> Of course it can, why not? An implementor of the routing module is
> expected to follow sec. 6 rules. It is just not so that the same callback
> can be used whenever any "enabled" leaf is changed.
>
> >
> > The reason RowStatus is a bad idea is that it is not config, but it is
> mixed in
> > with the config, and it is config according to YANG validation rules.
> > When you set the enabled leaf to false with an <edit-config> operation,
> > you are configuring the interface to be operationally disabled.
>
> Yes.
>
> >
> > All YANG validation outside the interface has to account for interfaces
> > that have been configured to be operationally disabled.
>
> This is where we differ, as long as you talk about configuration. The
> ex-vlan module in interfaces draft doesn't have any must statement
> requiring that the base-interface be enabled.
>
> >
> > When the hardware is operationally broken, setting 'enable' to true
> > is not going to fix it.  The enabled leaf is just the desired state, like
> > all the other config=true nodes.
>
> Sure.
>
> >
> > I agree that the desired state and operational state are not the same.
> > I don't agree that setting enabled-leaf to false is the same as the
> system
> > disabling a broken interface.
>
> Where did I say that?
>
> Lada
>
> >
> >
> > Andy
> >
> > >
> > > The system can be hand-coded at great expense to deal with any
> > > poorly designed ad-hoc mechanism.  It is just engineering decisions
> > > that determine whether we develop an efficient programmatic API
> > > or we develop CLI with angle brackets.
> >
> > So what would you do with the rules in sec. 6 of the routing module?
> Note that they involve not only "enabled" leafs in the interfaces and ip
> modules, but also "ip:forwarding".
> >
> > For example, if /if:interfaces/if:interface/if:enabled is set to false
> for an interface, I don't want to force the client to go and remove that
> interface from all configured routing instances.
> >
> > Similarly, disabling a physical interface should automatically lead to
> disabling all logical interfaces created on top of that physical interface
> - without having to disable all of them manually.
> >
> > Lada
> >
> > >
> > >
> > >
> > > I think you are both right - the 'inactive' feature is very useful
> > > (and it works just as if the node is deleted), but it doesn't
> > > necessarilty replace an "enabled" leaf in all cases.  As you noted,
> > > they behave differently.
> > >
> > >
> > >
> > > Andy
> > >
> > >
> > > /martin
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--089e0153705ee9385e04f8aad5e9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Here is what I mean by a typedef so=
lution.</div><div>Why did the WG decide this cannot work?</div><div><br></d=
iv><div>OLD:</div><div><pre style=3D"color:rgb(0,0,0);word-wrap:break-word;=
white-space:pre-wrap">
         leaf enabled {
           type boolean;
           default &quot;true&quot;;
           description
             &quot;This leaf contains the configured, desired state of the
              interface.
              Systems that implement the IF-MIB use the value of this
              leaf in the &#39;running&#39; datastore to set
              IF-MIB.ifAdminStatus to &#39;up&#39; or &#39;down&#39; after =
an ifEntry
              has been initialized, as described in RFC 2863.

              Changes in this leaf in the &#39;running&#39; datastore are
              reflected in ifAdminStatus, but if ifAdminStatus is
              changed over SNMP, this leaf is not affected.&quot;;
           reference
             &quot;RFC 2863: The Interfaces Group MIB - ifAdminStatus&quot;=
;
         }</pre><pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-s=
pace:pre-wrap">NEW:</pre><pre style=3D"color:rgb(0,0,0);word-wrap:break-wor=
d;white-space:pre-wrap">         // this is a general typedef, probably in =
ietf-yang-types</pre>
<pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"> =
        typedef oper-enabled {
           type boolean;
           description
             &quot;Used to operationally disable some configuration.
              The affected configuration SHOULD be limited to
              the parent node of the leaf using this typedef,
              but it MAY affect other configuration as described
              in the module.&quot;;
         }</pre><pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-s=
pace:pre-wrap"><br></pre><pre style=3D"color:rgb(0,0,0);word-wrap:break-wor=
d;white-space:pre-wrap"><pre style=3D"word-wrap:break-word;white-space:pre-=
wrap">
         leaf enabled {
           type yang:oper-enabled;
           default &quot;true&quot;;
           description
             &quot;This leaf contains the configured, desired state of the
              interface.
              Systems that implement the IF-MIB use the value of this
              leaf in the &#39;running&#39; datastore to set
              IF-MIB.ifAdminStatus to &#39;up&#39; or &#39;down&#39; after =
an ifEntry
              has been initialized, as described in RFC 2863.

              Changes in this leaf in the &#39;running&#39; datastore are
              reflected in ifAdminStatus, but if ifAdminStatus is
              changed over SNMP, this leaf is not affected.&quot;;
           reference
             &quot;RFC 2863: The Interfaces Group MIB - ifAdminStatus&quot;=
;
         }</pre><pre style=3D"word-wrap:break-word;white-space:pre-wrap"><b=
r></pre><pre style=3D"word-wrap:break-word;white-space:pre-wrap">Andy</pre>=
<pre style=3D"word-wrap:break-word;white-space:pre-wrap"><br></pre></pre></=
div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 May 5, 2014 at 9:25 AM, Ladislav Lhotka <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<br>
On 05 May 2014, at 17:05, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka &lt;<a href=3D"mailto:=
lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 05 May 2014, at 10:48, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund &lt;<a href=3D"=
mailto:mbj@tail-f.com">mbj@tail-f.com</a>&gt; wrote:<br>
&gt; &gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.c=
z</a>&gt; wrote:<br>
&gt; &gt; &gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@=
yumaworks.com</a>&gt; writes:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka &lt;<a =
href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; On 04 May 2014, at 10:33, Andy Bierman &lt;<a href=
=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhot=
ka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; On 03 May 2014, at 21:31, Andy Bierman &lt;<a =
href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; On Sat, May 3, 2014 at 11:50 AM, Ladislav=
 Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt; &gt; &gt; &gt;&gt; wrote:<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; On 03 May 2014, at 18:42, Andy Bierman &l=
t;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<b=
r>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; Problem:<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; The use of a leaf in the data model =
(such as the<br>
&gt; &gt; &gt; &gt;&gt; /interfaces/interface/enabled<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; leaf in the ietf-interfaces module) =
does not account for YANG<br>
&gt; &gt; &gt; &gt;&gt; validation rules<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; for many statements that can referen=
ce the disabled subtree from<br>
&gt; &gt; &gt; &gt;&gt; outside<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; of that subtree:<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - must<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - when<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - unique<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - min-elements<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - max-elements<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - leafref (valid insta=
nces)<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &gt; &nbsp; &nbsp; - choices (disabled ca=
se is still the active case, so no other<br>
&gt; &gt; &gt; &gt;&gt; can be used)<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; In my view, an &quot;enabled false&quot; =
leaf *operationally* disables a<br>
&gt; &gt; &gt; &gt;&gt; particular instance or function. For all other purp=
oses related to<br>
&gt; &gt; &gt; &gt;&gt; datastore validation, the value of the enabled leaf=
 doesn&#39;t matter. In<br>
&gt; &gt; &gt; &gt;&gt; other words, &quot;enabled false&quot; is not the s=
ame as commenting out the<br>
&gt; &gt; &gt; &gt;&gt; corresponding instance in the configuration.<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; OK -- they may be different, but the enab=
led leaf is ad-hoc,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; and YANG designers must know about this l=
eaf. &nbsp;Adding or removing<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; this leaf could break other YANG statemen=
ts.<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; E,g,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<=
br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:=
interface-ref;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true=
;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; By YANG validation rules, the &nbsp;leafr=
ef test for interface name<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; will include all disabled interfaces.<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; Yes.<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; Doesn&#39;t every object that uses the in=
terface-ref typedef need<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; to have a must-stmt making sure the enabl=
ed leaf is set,<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; if they want to activate a service on onl=
y enabled interfaces?<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; (Is this the must-stmt to use?)<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;leaf active-foo-interface {<=
br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;type &nbsp;if:=
interface-ref;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;must &quot;/if=
:interfaces/if:interface[if:name=3Dcurrent()]/enabled&quot;;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;mandatory true=
;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; Don&#39;t all must/when/leafref validatio=
n statements that want only<br>
&gt; &gt; &gt; &gt;&gt; &gt; &gt; active interfaces need to be written this=
 way?<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; I don&#39;t think so. An operator may want to =
pre-configure an interface in<br>
&gt; &gt; &gt; &gt;&gt; the disabled state, set up all references to it etc=
., so that everything<br>
&gt; &gt; &gt; &gt;&gt; will be up and running after setting the single &qu=
ot;enabled&quot; leaf to true.<br>
&gt; &gt; &gt; &gt;&gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; &gt; I said &quot;this is what has to be written to=
 identity active interfaces&quot;<br>
&gt; &gt; &gt; &gt;&gt; &gt; and you respond &quot;maybe they want to selec=
t disabled interfaces&quot;.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; It&#39;s up to the server to interpret the entire c=
onfiguration, so if a<br>
&gt; &gt; &gt; &gt;&gt; service is enabled in configuration but it depends =
on an interface that is<br>
&gt; &gt; &gt; &gt;&gt; currently disabled, the server might keep that serv=
ice operationally<br>
&gt; &gt; &gt; &gt;&gt; disabled as well.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt; Not if the YANG validation rules say differently.<br>
&gt; &gt; &gt; &gt; My point is that the YANG designer must write all valid=
ation rules to<br>
&gt; &gt; &gt; &gt; account for disabled configuration, or the model is wro=
ng.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I don&#39;t agree. It would be extremely impractical to rend=
er a configuration<br>
&gt; &gt; &gt; invalid just by disabling an interface.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; The important point is that the designer better know every single=
<br>
&gt; &gt; YANG object and write the validation rules correctly.<br>
&gt; &gt; Inconvenient or not, if some component needs to use<br>
&gt; &gt; only active interfaces, then ignoring the &#39;active&#39; leaf w=
ill be broken.<br>
&gt;<br>
&gt; It will be broken in terms of operational state, not configuration. Ma=
ny changes in configuration have ripple effects and well-designed server sh=
ould be able to trace dependencies and act accordingly, rather than forcing=
 the user to do it manually.<br>

&gt;<br>
&gt;<br>
&gt;<br>
&gt; The server cannot ripple the disable event automatically using an ad-h=
oc solution,<br>
&gt; but that is just an implementation detail to the IETF, so it&#39;s not=
 important.<br>
<br>
Of course it can, why not? An implementor of the routing module is expected=
 to follow sec. 6 rules. It is just not so that the same callback can be us=
ed whenever any &ldquo;enabled&rdquo; leaf is changed.<br>
<br>
&gt;<br>
&gt; The reason RowStatus is a bad idea is that it is not config, but it is=
 mixed in<br>
&gt; with the config, and it is config according to YANG validation rules.<=
br>
&gt; When you set the enabled leaf to false with an &lt;edit-config&gt; ope=
ration,<br>
&gt; you are configuring the interface to be operationally disabled.<br>
<br>
Yes.<br>
<br>
&gt;<br>
&gt; All YANG validation outside the interface has to account for interface=
s<br>
&gt; that have been configured to be operationally disabled.<br>
<br>
This is where we differ, as long as you talk about configuration. The ex-vl=
an module in interfaces draft doesn&rsquo;t have any must statement requiri=
ng that the base-interface be enabled.<br>
<br>
&gt;<br>
&gt; When the hardware is operationally broken, setting &#39;enable&#39; to=
 true<br>
&gt; is not going to fix it. &nbsp;The enabled leaf is just the desired sta=
te, like<br>
&gt; all the other config=3Dtrue nodes.<br>
<br>
Sure.<br>
<br>
&gt;<br>
&gt; I agree that the desired state and operational state are not the same.=
<br>
&gt; I don&#39;t agree that setting enabled-leaf to false is the same as th=
e system<br>
&gt; disabling a broken interface.<br>
<br>
Where did I say that?<br>
<br>
Lada<br>
<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; The system can be hand-coded at great expense to deal with any<br=
>
&gt; &gt; poorly designed ad-hoc mechanism. &nbsp;It is just engineering de=
cisions<br>
&gt; &gt; that determine whether we develop an efficient programmatic API<b=
r>
&gt; &gt; or we develop CLI with angle brackets.<br>
&gt;<br>
&gt; So what would you do with the rules in sec. 6 of the routing module? N=
ote that they involve not only &ldquo;enabled&rdquo; leafs in the interface=
s and ip modules, but also &ldquo;ip:forwarding&rdquo;.<br>
&gt;<br>
&gt; For example, if /if:interfaces/if:interface/if:enabled is set to false=
 for an interface, I don&rsquo;t want to force the client to go and remove =
that interface from all configured routing instances.<br>
&gt;<br>
&gt; Similarly, disabling a physical interface should automatically lead to=
 disabling all logical interfaces created on top of that physical interface=
 - without having to disable all of them manually.<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I think you are both right - the &#39;inactive&#39; feature is ve=
ry useful<br>
&gt; &gt; (and it works just as if the node is deleted), but it doesn&#39;t=
<br>
&gt; &gt; necessarilty replace an &quot;enabled&quot; leaf in all cases. &n=
bsp;As you noted,<br>
&gt; &gt; they behave differently.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; /martin<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div>

--089e0153705ee9385e04f8aad5e9--


From nobody Mon May  5 12:26:58 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AFD1A0452 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 12:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZxU9yAF7TrC for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 12:26:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 563231A045C for <netmod@ietf.org>; Mon,  5 May 2014 12:26:52 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 57BE8476C16; Mon,  5 May 2014 21:26:47 +0200 (CEST)
Date: Mon, 05 May 2014 21:26:46 +0200 (CEST)
Message-Id: <20140505.212646.11884293.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHR_FqKUaj+HNSRMDgimR760XHXRL9Jy9N_35vjEHrfffA@mail.gmail.com>
References: <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com> <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz> <CABCOCHR_FqKUaj+HNSRMDgimR760XHXRL9Jy9N_35vjEHrfffA@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pkCjHqYFIOcHHp-NvzMwhxJ6IWw
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 May 2014 19:26:56 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> Here is what I mean by a typedef solution.
> Why did the WG decide this cannot work?

I don't think this was ever proposed and considered by the WG.


/martin



> 
> OLD:
> 
>          leaf enabled {
>            type boolean;
>            default "true";
>            description
>              "This leaf contains the configured, desired state of the
>               interface.
>               Systems that implement the IF-MIB use the value of this
>               leaf in the 'running' datastore to set
>               IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
>               has been initialized, as described in RFC 2863.
> 
>               Changes in this leaf in the 'running' datastore are
>               reflected in ifAdminStatus, but if ifAdminStatus is
>               changed over SNMP, this leaf is not affected.";
>            reference
>              "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
>          }
> 
> NEW:
> 
>          // this is a general typedef, probably in ietf-yang-types
> 
>          typedef oper-enabled {
>            type boolean;
>            description
>              "Used to operationally disable some configuration.
>               The affected configuration SHOULD be limited to
>               the parent node of the leaf using this typedef,
>               but it MAY affect other configuration as described
>               in the module.";
>          }
> 
> 
>          leaf enabled {
>            type yang:oper-enabled;
>            default "true";
>            description
>              "This leaf contains the configured, desired state of the
>               interface.
>               Systems that implement the IF-MIB use the value of this
>               leaf in the 'running' datastore to set
>               IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
>               has been initialized, as described in RFC 2863.
> 
>               Changes in this leaf in the 'running' datastore are
>               reflected in ifAdminStatus, but if ifAdminStatus is
>               changed over SNMP, this leaf is not affected.";
>            reference
>              "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
>          }
> 
> 
> Andy
> 
> 
> 
> 
> On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> 
> >
> > On 05 May 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > > > Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > > > Andy Bierman <andy@yumaworks.com> writes:
> > > > >
> > > > > > On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz>
> > wrote:
> > > > > >
> > > > > >>
> > > > > >> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com>
> > wrote:
> > > > > >>
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> > wrote:
> > > > > >> >
> > > > > >> > On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com>
> > wrote:
> > > > > >> >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <
> > lhotka@nic.cz>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
> > wrote:
> > > > > >> > >
> > > > > >> > > > Hi,
> > > > > >> > > >
> > > > > >> > > > Problem:
> > > > > >> > > >
> > > > > >> > > > The use of a leaf in the data model (such as the
> > > > > >> /interfaces/interface/enabled
> > > > > >> > > > leaf in the ietf-interfaces module) does not account for
> > YANG
> > > > > >> validation rules
> > > > > >> > > > for many statements that can reference the disabled subtree
> > from
> > > > > >> outside
> > > > > >> > > > of that subtree:
> > > > > >> > > >
> > > > > >> > > >     - must
> > > > > >> > > >     - when
> > > > > >> > > >     - unique
> > > > > >> > > >     - min-elements
> > > > > >> > > >     - max-elements
> > > > > >> > > >     - leafref (valid instances)
> > > > > >> > > >     - choices (disabled case is still the active case, so
> > no other
> > > > > >> can be used)
> > > > > >> > >
> > > > > >> > > In my view, an "enabled false" leaf *operationally* disables a
> > > > > >> particular instance or function. For all other purposes related to
> > > > > >> datastore validation, the value of the enabled leaf doesn't
> > matter. In
> > > > > >> other words, "enabled false" is not the same as commenting out the
> > > > > >> corresponding instance in the configuration.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > > > >> > > and YANG designers must know about this leaf.  Adding or
> > removing
> > > > > >> > > this leaf could break other YANG statements.
> > > > > >> > >
> > > > > >> > > E,g,
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >    leaf active-foo-interface {
> > > > > >> > >        type  if:interface-ref;
> > > > > >> > >        mandatory true;
> > > > > >> > >    }
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > By YANG validation rules, the  leafref test for interface name
> > > > > >> > > will include all disabled interfaces.
> > > > > >> >
> > > > > >> > Yes.
> > > > > >> >
> > > > > >> > >
> > > > > >> > > Doesn't every object that uses the interface-ref typedef need
> > > > > >> > > to have a must-stmt making sure the enabled leaf is set,
> > > > > >> > > if they want to activate a service on only enabled interfaces?
> > > > > >> > >
> > > > > >> > > (Is this the must-stmt to use?)
> > > > > >> > >
> > > > > >> > >    leaf active-foo-interface {
> > > > > >> > >        type  if:interface-ref;
> > > > > >> > >        must
> > "/if:interfaces/if:interface[if:name=current()]/enabled";
> > > > > >> > >        mandatory true;
> > > > > >> > >    }
> > > > > >> > >
> > > > > >> > > Don't all must/when/leafref validation statements that want
> > only
> > > > > >> > > active interfaces need to be written this way?
> > > > > >> >
> > > > > >> > I don't think so. An operator may want to pre-configure an
> > interface in
> > > > > >> the disabled state, set up all references to it etc., so that
> > everything
> > > > > >> will be up and running after setting the single "enabled" leaf to
> > true.
> > > > > >> >
> > > > > >> > I said "this is what has to be written to identity active
> > interfaces"
> > > > > >> > and you respond "maybe they want to select disabled interfaces".
> > > > > >>
> > > > > >> It's up to the server to interpret the entire configuration, so
> > if a
> > > > > >> service is enabled in configuration but it depends on an
> > interface that is
> > > > > >> currently disabled, the server might keep that service
> > operationally
> > > > > >> disabled as well.
> > > > > >>
> > > > > >>
> > > > > > Not if the YANG validation rules say differently.
> > > > > > My point is that the YANG designer must write all validation rules
> > to
> > > > > > account for disabled configuration, or the model is wrong.
> > > > >
> > > > > I don't agree. It would be extremely impractical to render a
> > configuration
> > > > > invalid just by disabling an interface.
> > > >
> > > >
> > > > The important point is that the designer better know every single
> > > > YANG object and write the validation rules correctly.
> > > > Inconvenient or not, if some component needs to use
> > > > only active interfaces, then ignoring the 'active' leaf will be broken.
> > >
> > > It will be broken in terms of operational state, not configuration. Many
> > changes in configuration have ripple effects and well-designed server
> > should be able to trace dependencies and act accordingly, rather than
> > forcing the user to do it manually.
> > >
> > >
> > >
> > > The server cannot ripple the disable event automatically using an ad-hoc
> > solution,
> > > but that is just an implementation detail to the IETF, so it's not
> > important.
> >
> > Of course it can, why not? An implementor of the routing module is
> > expected to follow sec. 6 rules. It is just not so that the same callback
> > can be used whenever any "enabled" leaf is changed.
> >
> > >
> > > The reason RowStatus is a bad idea is that it is not config, but it is
> > mixed in
> > > with the config, and it is config according to YANG validation rules.
> > > When you set the enabled leaf to false with an <edit-config> operation,
> > > you are configuring the interface to be operationally disabled.
> >
> > Yes.
> >
> > >
> > > All YANG validation outside the interface has to account for interfaces
> > > that have been configured to be operationally disabled.
> >
> > This is where we differ, as long as you talk about configuration. The
> > ex-vlan module in interfaces draft doesn't have any must statement
> > requiring that the base-interface be enabled.
> >
> > >
> > > When the hardware is operationally broken, setting 'enable' to true
> > > is not going to fix it.  The enabled leaf is just the desired state, like
> > > all the other config=true nodes.
> >
> > Sure.
> >
> > >
> > > I agree that the desired state and operational state are not the same.
> > > I don't agree that setting enabled-leaf to false is the same as the
> > system
> > > disabling a broken interface.
> >
> > Where did I say that?
> >
> > Lada
> >
> > >
> > >
> > > Andy
> > >
> > > >
> > > > The system can be hand-coded at great expense to deal with any
> > > > poorly designed ad-hoc mechanism.  It is just engineering decisions
> > > > that determine whether we develop an efficient programmatic API
> > > > or we develop CLI with angle brackets.
> > >
> > > So what would you do with the rules in sec. 6 of the routing module?
> > Note that they involve not only "enabled" leafs in the interfaces and ip
> > modules, but also "ip:forwarding".
> > >
> > > For example, if /if:interfaces/if:interface/if:enabled is set to false
> > for an interface, I don't want to force the client to go and remove that
> > interface from all configured routing instances.
> > >
> > > Similarly, disabling a physical interface should automatically lead to
> > disabling all logical interfaces created on top of that physical interface
> > - without having to disable all of them manually.
> > >
> > > Lada
> > >
> > > >
> > > >
> > > >
> > > > I think you are both right - the 'inactive' feature is very useful
> > > > (and it works just as if the node is deleted), but it doesn't
> > > > necessarilty replace an "enabled" leaf in all cases.  As you noted,
> > > > they behave differently.
> > > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > > /martin
> > > >
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >


From nobody Mon May  5 21:39:26 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1F1A0712 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 21:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level: 
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTQHNoPgp5oM for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 21:39:22 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5761A070E for <netmod@ietf.org>; Mon,  5 May 2014 21:39:21 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8149D141274; Tue,  6 May 2014 06:39:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399351155; bh=vdjkwhf9OQ69H8vm1uBce+GOCouS1ssPnILkOnifR1s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=W3ff1XvVBE9HS/GsH7tir1DT8SYTwimV9xId8a6RiRtq1prxNrhOfjWlsfUHYexaP S+ymWdQzktuPfoRIXp/CKYgYnNjVYX6B4X6yNdeQOuOt6yySkZqGWXnaKkwn34DwP8 Hg3RpeQFClnc0WDGoxk6LEZbjcJ70OPqNej0qbIg=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140505.212646.11884293.mbj@tail-f.com>
Date: Tue, 6 May 2014 06:39:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B593152-FD20-4FDE-9376-1BB950E49230@nic.cz>
References: <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com> <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz> <CABCOCHR_FqKUaj+HNSRMDgimR760XHXRL9Jy9N_35vjEHrfffA@mail.gmail.com> <20140505.212646.11884293.mbj@tail-f.com>
To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pvotu63wwFu87JjS2OcuEoyuQzI
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 04:39:24 -0000

On 05 May 2014, at 21:26, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.com> wrote:
>> Hi,
>>=20
>> Here is what I mean by a typedef solution.
>> Why did the WG decide this cannot work?
>=20
> I don't think this was ever proposed and considered by the WG.

+1

This is doable in good old YANG 1.0.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>> OLD:
>>=20
>>         leaf enabled {
>>           type boolean;
>>           default "true";
>>           description
>>             "This leaf contains the configured, desired state of the
>>              interface.
>>              Systems that implement the IF-MIB use the value of this
>>              leaf in the 'running' datastore to set
>>              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
>>              has been initialized, as described in RFC 2863.
>>=20
>>              Changes in this leaf in the 'running' datastore are
>>              reflected in ifAdminStatus, but if ifAdminStatus is
>>              changed over SNMP, this leaf is not affected.";
>>           reference
>>             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
>>         }
>>=20
>> NEW:
>>=20
>>         // this is a general typedef, probably in ietf-yang-types
>>=20
>>         typedef oper-enabled {
>>           type boolean;
>>           description
>>             "Used to operationally disable some configuration.
>>              The affected configuration SHOULD be limited to
>>              the parent node of the leaf using this typedef,
>>              but it MAY affect other configuration as described
>>              in the module.";
>>         }
>>=20
>>=20
>>         leaf enabled {
>>           type yang:oper-enabled;
>>           default "true";
>>           description
>>             "This leaf contains the configured, desired state of the
>>              interface.
>>              Systems that implement the IF-MIB use the value of this
>>              leaf in the 'running' datastore to set
>>              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
>>              has been initialized, as described in RFC 2863.
>>=20
>>              Changes in this leaf in the 'running' datastore are
>>              reflected in ifAdminStatus, but if ifAdminStatus is
>>              changed over SNMP, this leaf is not affected.";
>>           reference
>>             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
>>         }
>>=20
>>=20
>> Andy
>>=20
>>=20
>>=20
>>=20
>> On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>>=20
>>>=20
>>> On 05 May 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:
>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>>>>=20
>>>> On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com>
>>> wrote:
>>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>>>> Andy Bierman <andy@yumaworks.com> writes:
>>>>>>=20
>>>>>>> On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz>
>>> wrote:
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com>
>>> wrote:
>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka =
<lhotka@nic.cz>
>>> wrote:
>>>>>>>>>=20
>>>>>>>>> On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com>
>>> wrote:
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <
>>> lhotka@nic.cz>
>>>>>>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>> On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
>>> wrote:
>>>>>>>>>>=20
>>>>>>>>>>> Hi,
>>>>>>>>>>>=20
>>>>>>>>>>> Problem:
>>>>>>>>>>>=20
>>>>>>>>>>> The use of a leaf in the data model (such as the
>>>>>>>> /interfaces/interface/enabled
>>>>>>>>>>> leaf in the ietf-interfaces module) does not account for
>>> YANG
>>>>>>>> validation rules
>>>>>>>>>>> for many statements that can reference the disabled subtree
>>> from
>>>>>>>> outside
>>>>>>>>>>> of that subtree:
>>>>>>>>>>>=20
>>>>>>>>>>>    - must
>>>>>>>>>>>    - when
>>>>>>>>>>>    - unique
>>>>>>>>>>>    - min-elements
>>>>>>>>>>>    - max-elements
>>>>>>>>>>>    - leafref (valid instances)
>>>>>>>>>>>    - choices (disabled case is still the active case, so
>>> no other
>>>>>>>> can be used)
>>>>>>>>>>=20
>>>>>>>>>> In my view, an "enabled false" leaf *operationally* disables =
a
>>>>>>>> particular instance or function. For all other purposes related =
to
>>>>>>>> datastore validation, the value of the enabled leaf doesn't
>>> matter. In
>>>>>>>> other words, "enabled false" is not the same as commenting out =
the
>>>>>>>> corresponding instance in the configuration.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> OK -- they may be different, but the enabled leaf is ad-hoc,
>>>>>>>>>> and YANG designers must know about this leaf.  Adding or
>>> removing
>>>>>>>>>> this leaf could break other YANG statements.
>>>>>>>>>>=20
>>>>>>>>>> E,g,
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>   leaf active-foo-interface {
>>>>>>>>>>       type  if:interface-ref;
>>>>>>>>>>       mandatory true;
>>>>>>>>>>   }
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> By YANG validation rules, the  leafref test for interface =
name
>>>>>>>>>> will include all disabled interfaces.
>>>>>>>>>=20
>>>>>>>>> Yes.
>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Doesn't every object that uses the interface-ref typedef need
>>>>>>>>>> to have a must-stmt making sure the enabled leaf is set,
>>>>>>>>>> if they want to activate a service on only enabled =
interfaces?
>>>>>>>>>>=20
>>>>>>>>>> (Is this the must-stmt to use?)
>>>>>>>>>>=20
>>>>>>>>>>   leaf active-foo-interface {
>>>>>>>>>>       type  if:interface-ref;
>>>>>>>>>>       must
>>> "/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled";
>>>>>>>>>>       mandatory true;
>>>>>>>>>>   }
>>>>>>>>>>=20
>>>>>>>>>> Don't all must/when/leafref validation statements that want
>>> only
>>>>>>>>>> active interfaces need to be written this way?
>>>>>>>>>=20
>>>>>>>>> I don't think so. An operator may want to pre-configure an
>>> interface in
>>>>>>>> the disabled state, set up all references to it etc., so that
>>> everything
>>>>>>>> will be up and running after setting the single "enabled" leaf =
to
>>> true.
>>>>>>>>>=20
>>>>>>>>> I said "this is what has to be written to identity active
>>> interfaces"
>>>>>>>>> and you respond "maybe they want to select disabled =
interfaces".
>>>>>>>>=20
>>>>>>>> It's up to the server to interpret the entire configuration, so
>>> if a
>>>>>>>> service is enabled in configuration but it depends on an
>>> interface that is
>>>>>>>> currently disabled, the server might keep that service
>>> operationally
>>>>>>>> disabled as well.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>> Not if the YANG validation rules say differently.
>>>>>>> My point is that the YANG designer must write all validation =
rules
>>> to
>>>>>>> account for disabled configuration, or the model is wrong.
>>>>>>=20
>>>>>> I don't agree. It would be extremely impractical to render a
>>> configuration
>>>>>> invalid just by disabling an interface.
>>>>>=20
>>>>>=20
>>>>> The important point is that the designer better know every single
>>>>> YANG object and write the validation rules correctly.
>>>>> Inconvenient or not, if some component needs to use
>>>>> only active interfaces, then ignoring the 'active' leaf will be =
broken.
>>>>=20
>>>> It will be broken in terms of operational state, not configuration. =
Many
>>> changes in configuration have ripple effects and well-designed =
server
>>> should be able to trace dependencies and act accordingly, rather =
than
>>> forcing the user to do it manually.
>>>>=20
>>>>=20
>>>>=20
>>>> The server cannot ripple the disable event automatically using an =
ad-hoc
>>> solution,
>>>> but that is just an implementation detail to the IETF, so it's not
>>> important.
>>>=20
>>> Of course it can, why not? An implementor of the routing module is
>>> expected to follow sec. 6 rules. It is just not so that the same =
callback
>>> can be used whenever any "enabled" leaf is changed.
>>>=20
>>>>=20
>>>> The reason RowStatus is a bad idea is that it is not config, but it =
is
>>> mixed in
>>>> with the config, and it is config according to YANG validation =
rules.
>>>> When you set the enabled leaf to false with an <edit-config> =
operation,
>>>> you are configuring the interface to be operationally disabled.
>>>=20
>>> Yes.
>>>=20
>>>>=20
>>>> All YANG validation outside the interface has to account for =
interfaces
>>>> that have been configured to be operationally disabled.
>>>=20
>>> This is where we differ, as long as you talk about configuration. =
The
>>> ex-vlan module in interfaces draft doesn't have any must statement
>>> requiring that the base-interface be enabled.
>>>=20
>>>>=20
>>>> When the hardware is operationally broken, setting 'enable' to true
>>>> is not going to fix it.  The enabled leaf is just the desired =
state, like
>>>> all the other config=3Dtrue nodes.
>>>=20
>>> Sure.
>>>=20
>>>>=20
>>>> I agree that the desired state and operational state are not the =
same.
>>>> I don't agree that setting enabled-leaf to false is the same as the
>>> system
>>>> disabling a broken interface.
>>>=20
>>> Where did I say that?
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>>=20
>>>> Andy
>>>>=20
>>>>>=20
>>>>> The system can be hand-coded at great expense to deal with any
>>>>> poorly designed ad-hoc mechanism.  It is just engineering =
decisions
>>>>> that determine whether we develop an efficient programmatic API
>>>>> or we develop CLI with angle brackets.
>>>>=20
>>>> So what would you do with the rules in sec. 6 of the routing =
module?
>>> Note that they involve not only "enabled" leafs in the interfaces =
and ip
>>> modules, but also "ip:forwarding".
>>>>=20
>>>> For example, if /if:interfaces/if:interface/if:enabled is set to =
false
>>> for an interface, I don't want to force the client to go and remove =
that
>>> interface from all configured routing instances.
>>>>=20
>>>> Similarly, disabling a physical interface should automatically lead =
to
>>> disabling all logical interfaces created on top of that physical =
interface
>>> - without having to disable all of them manually.
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I think you are both right - the 'inactive' feature is very useful
>>>>> (and it works just as if the node is deleted), but it doesn't
>>>>> necessarilty replace an "enabled" leaf in all cases.  As you =
noted,
>>>>> they behave differently.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Andy
>>>>>=20
>>>>>=20
>>>>> /martin
>>>>>=20
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May  5 23:28:16 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E071A0727 for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 23:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01DQg0Z0pChY for <netmod@ietfa.amsl.com>; Mon,  5 May 2014 23:28:13 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 910DB1A025A for <netmod@ietf.org>; Mon,  5 May 2014 23:28:12 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 98D56124CC3F for <netmod@ietf.org>; Tue,  6 May 2014 14:27:56 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s466RwqM042527 for <netmod@ietf.org>; Tue, 6 May 2014 14:27:58 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
To: netmod@ietf.org
MIME-Version: 1.0
X-KeepSent: 10ECF393:51E3F760-48257CD0:002226C7; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF10ECF393.51E3F760-ON48257CD0.002226C7-48257CD0.00238601@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 6 May 2014 14:27:59 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-06 14:28:01, Serialize complete at 2014-05-06 14:28:01
Content-Type: multipart/alternative; boundary="=_alternative 002385FA48257CD0_="
X-MAIL: mse02.zte.com.cn s466RwqM042527
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cOFi_JeYu3t6ybJSeQ9xOuSo8a0
Subject: [netmod] question about prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 06:28:15 -0000

This is a multipart message in MIME format.

--=_alternative 002385FA48257CD0_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,
   I hava a question about prefix. when a module defined a prefix of 
module, can it be used to indicate submodoule's definition?

For example,

module a {
    include b;
    prefix a;
    ....
    leaf fooleaf {
         type a:foo;
    }

}

submodule b {
    belongsto a {
       prefix a;
    }

    typedef foo {
        type uint8;
    }
}

is is valid? 

/frank
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 002385FA48257CD0_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Hi all,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;I hava a question about
prefix. when a module defined a prefix of module, can it be used to indicate
submodoule's definition?</font>
<br>
<br><font size=2 face="sans-serif">For example,</font>
<br>
<br><font size=2 face="sans-serif">module a {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; include b;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; prefix a;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; ....</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; leaf fooleaf {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;type
a:foo;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; }</font>
<br>
<br><font size=2 face="sans-serif">}</font>
<br>
<br><font size=2 face="sans-serif">submodule b {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; belongsto a {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;prefix a;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; }</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; typedef foo {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; type uint8;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; }</font>
<br><font size=2 face="sans-serif">}</font>
<br>
<br><font size=2 face="sans-serif">is is valid? </font>
<br>
<br><font size=2 face="sans-serif">/frank</font>

<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre><br>

--=_alternative 002385FA48257CD0_=--


From nobody Tue May  6 00:40:23 2014
Return-Path: <jernej.tuljak@mg-soft.si>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7923D1A0292 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 00:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.051
X-Spam-Level: 
X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVFL5eqYfaIl for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 00:40:19 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB691A0273 for <netmod@ietf.org>; Tue,  6 May 2014 00:40:19 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s467eEth027396; Tue, 6 May 2014 09:40:14 +0200
Message-ID: <536891DB.1040007@mg-soft.com>
Date: Tue, 06 May 2014 09:40:11 +0200
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: feng.chong33@zte.com.cn
References: <OF10ECF393.51E3F760-ON48257CD0.002226C7-48257CD0.00238601@zte.com.cn>
In-Reply-To: <OF10ECF393.51E3F760-ON48257CD0.002226C7-48257CD0.00238601@zte.com.cn>
Content-Type: multipart/alternative; boundary="------------000006010001020900060405"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6TwKwrfM9qdVo0hQi0kXONQ8ceU
Cc: netmod@ietf.org
Subject: Re: [netmod] question about prefix
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 07:40:22 -0000

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

Dne 6.5.2014 8:27, pis(e feng.chong33@zte.com.cn:
> Hi all,
>    I hava a question about prefix. when a module defined a prefix of 
> module, can it be used to indicate submodoule's definition?
>
> For example,
>
> module a {
>     include b;
>     prefix a;
>     ....
>     leaf fooleaf {
>          type a:foo;
>     }
>
> }
>
> submodule b {
>     belongsto a {
>        prefix a;
>     }
>
>     typedef foo {
>         type uint8;
>     }
> }
>
> is is valid?

Definitions inside a submodule belong to the namespace of the including 
module. Therefore "foo" is a local definition from module's "a" 
perspective. So yes, you can refer to it inside module "a" with a fully 
qualified name using the prefix of module "a", much like you can inside 
submodule "b" using the prefix defined in the belongs-to statement. The 
concept is described in RFC6020, Section 5.1.

Jernej

>
> /frank
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------000006010001020900060405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dne 6.5.2014 8:27, pi&#353;e
      <a class="moz-txt-link-abbreviated" href="mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a>:<br>
    </div>
    <blockquote
cite="mid:OF10ECF393.51E3F760-ON48257CD0.002226C7-48257CD0.00238601@zte.com.cn"
      type="cite"><font face="sans-serif" size="2">Hi all,</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp;I hava a question about
        prefix. when a module defined a prefix of module, can it be used
        to indicate
        submodoule's definition?</font>
      <br>
      <br>
      <font face="sans-serif" size="2">For example,</font>
      <br>
      <br>
      <font face="sans-serif" size="2">module a {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; include b;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; prefix a;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; ....</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; leaf fooleaf {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;type
        a:foo;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; }</font>
      <br>
      <br>
      <font face="sans-serif" size="2">}</font>
      <br>
      <br>
      <font face="sans-serif" size="2">submodule b {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; belongsto a {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp;prefix a;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; }</font>
      <br>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; typedef foo {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; type uint8;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; }</font>
      <br>
      <font face="sans-serif" size="2">}</font>
      <br>
      <br>
      <font face="sans-serif" size="2">is is valid? </font>
      <br>
    </blockquote>
    <br>
    Definitions inside a submodule belong to the namespace of the
    including module. Therefore "foo" is a local definition from
    module's "a" perspective. So yes, you can refer to it inside module
    "a" with a fully qualified name using the prefix of module "a", much
    like you can inside submodule "b" using the prefix defined in the
    belongs-to statement. The concept is described in RFC6020, Section
    5.1.<br>
    <br>
    Jernej<br>
    <br>
    <blockquote
cite="mid:OF10ECF393.51E3F760-ON48257CD0.002226C7-48257CD0.00238601@zte.com.cn"
      type="cite">
      <br>
      <font face="sans-serif" size="2">/frank</font>
      <br>
      <pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
netmod mailing list
<a class="moz-txt-link-abbreviated" href="mailto:netmod@ietf.org">netmod@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org/mailman/listinfo/netmod</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------000006010001020900060405--


From nobody Tue May  6 07:46:11 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C21A0354 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 07:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y--4VS7purH1 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 07:46:08 -0700 (PDT)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id C42D91A008D for <netmod@ietf.org>; Tue,  6 May 2014 07:46:08 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id m5so5463751qaj.30 for <netmod@ietf.org>; Tue, 06 May 2014 07:46:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=7V0lDrZ3kSsxjkMJYr595PlUI9kltptuCId4StQ7TYY=; b=gmO4vDzDLhpmy92zh06aAk9oRMrtaJgPe0tIPXGqUC/bjjmQqMycviDVGslZn4b4BF K5bYtJmQG2ch1xKIXXae9ppM22GFOJ6p7mqlKVYLo5GYd62/CFO4/YkREfGXMjZyTWAA ZNqQuqALOZ1IjSHDdRBjKHggwA/llOa+J0fyF7RPR67CCrGclGiNOGp8y3VnV/Zgvh0+ 9sYvuNe67x1W222sVsjBcGFbniqkXNA2qH0e2Ua6DD+2Em3MacTChoNcJwjIcJjPYMy+ wpv8NAlmW9+AgHCk7k9gs9SWL1i4Wzk2r3PYiFzDS+piU2XimnFVPZoo10f07rVajewp Tjmw==
X-Gm-Message-State: ALoCoQm47GTpaSp+9D60KzLP5R5kg1pVa2OC4jT54/lsf78LsClnYL5nRKvueJ3IMin0fcBmUt24
MIME-Version: 1.0
X-Received: by 10.224.55.6 with SMTP id s6mr19896905qag.7.1399387564807; Tue, 06 May 2014 07:46:04 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Tue, 6 May 2014 07:46:04 -0700 (PDT)
Date: Tue, 6 May 2014 07:46:04 -0700
Message-ID: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/mixed; boundary=089e0153705eb4e7c704f8bc4e49
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OYWOyk6uFKvyXLata6EwzQJsDRg
Subject: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 14:46:10 -0000

--089e0153705eb4e7c704f8bc4e49
Content-Type: multipart/alternative; boundary=089e0153705eb4e7c104f8bc4e47

--089e0153705eb4e7c104f8bc4e47
Content-Type: text/plain; charset=ISO-8859-1

Hi,

The question about submodules reminded me of our previous debate
on how nested submodules are treated.  I just did a test with
pyang and yangdump-pro.  They do not produce the same results.

   tinc2     <----  tinc1
                         |
                         + tinc1a
                         |
                         + tinc1b   <-- tinc1c

Problem: Need to clarify behavior when a submodule (tinc1c) is not
included by the main module.

pyang says this is an error and refuses to even compile tinc2.
I cannot find any text where it says this is an error.

andy@andy-swdev:~/modules$ pyang tinc1.yang
tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by
the module tinc1

andy@andy-swdev:~/modules$ pyang tinc2.yang
tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by
the module tinc1

yangdump-pro does report an error for using the tinc3a typedef in an
external module.  However it does not flag an error when that same type
is pulled through within a grouping.  The unexported submodule tinc1c is not
treated as an error.


andy@andy-swdev:~/modules$ yangdump-pro tinc1
*** /home/andy/modules/tinc1.yang
*** 0 Errors, 0 Warnings


andy@andy-swdev:~/modules$ yangdump-pro tinc2
Error: typedef definition for 'tinc1:type3' not found in module tinc1
tinc2.yang:19.12: error(250): definition not found

*** /home/andy/modules/tinc2.yang
*** 1 Errors, 0 Warnings

Solution:  Need to reach WG consensus on proper behavior and update
the appropriate text in YANG 1.1.

   * Is it an error to have an unexported submodule (IMO, no)

   * Is it an error to use an unexported definition (yes; seems to be
consensus
     on this point)

    * Is it an error to use an unexported definition if it is used in a
grouping
      that is exported?  (IMO, no)



Andy

--089e0153705eb4e7c104f8bc4e47
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>The question about submodules remin=
ded me of our previous debate</div><div>on how nested submodules are treate=
d. =A0I just did a test with</div><div>pyang and yangdump-pro. =A0They do n=
ot produce the same results.</div>
<div><br></div><div>=A0 =A0tinc2 =A0 =A0 &lt;---- =A0tinc1</div><div>=A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|</div><div>=A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1a</div><div>=A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0+ tinc1b =A0 &lt;-- tinc1c</div>
<div><br></div><div>Problem: Need to clarify behavior when a submodule (tin=
c1c) is not</div><div>included by the main module.</div><div><br></div><div=
>pyang says this is an error and refuses to even compile tinc2.</div><div>
I cannot find any text where it says this is an error.</div><div><br></div>=
<div><div>andy@andy-swdev:~/modules$ pyang tinc1.yang</div><div>tinc1b.yang=
:4: error: submodule tinc1c is included by tinc1b, but not by the module ti=
nc1</div>
<div><br></div><div>andy@andy-swdev:~/modules$ pyang tinc2.yang</div><div>t=
inc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by the=
 module tinc1</div><div><br></div></div><div>yangdump-pro does report an er=
ror for using the tinc3a typedef in an</div>
<div>external module. =A0However it does not flag an error when that same t=
ype</div><div>is pulled through within a grouping. =A0The unexported submod=
ule tinc1c is not</div><div>treated as an error.</div><div><br></div><div><=
br>
</div><div><div>andy@andy-swdev:~/modules$ yangdump-pro tinc1</div><div>***=
 /home/andy/modules/tinc1.yang</div><div>*** 0 Errors, 0 Warnings</div></di=
v><div><br></div><div><br></div><div><div>andy@andy-swdev:~/modules$ yangdu=
mp-pro tinc2</div>
<div>Error: typedef definition for &#39;tinc1:type3&#39; not found in modul=
e tinc1</div><div>tinc2.yang:19.12: error(250): definition not found</div><=
div><br></div><div>*** /home/andy/modules/tinc2.yang</div><div>*** 1 Errors=
, 0 Warnings</div>
<div><br></div><div>Solution: =A0Need to reach WG consensus on proper behav=
ior and update</div></div><div>the appropriate text in YANG 1.1.</div><div>=
<br></div><div>=A0 =A0* Is it an error to have an unexported submodule (IMO=
, no)</div>
<div><br></div><div>=A0 =A0* Is it an error to use an unexported definition=
 (yes; seems to be consensus</div><div>=A0 =A0 =A0on this point)</div><div>=
<br></div><div>=A0 =A0 * Is it an error to use an unexported definition if =
it is used in a grouping</div>
<div>=A0 =A0 =A0 that is exported? =A0(IMO, no)</div><div><br></div><div><b=
r></div><div><br></div><div>Andy</div><div><br></div></div>

--089e0153705eb4e7c104f8bc4e47--
--089e0153705eb4e7c704f8bc4e49
Content-Type: application/octet-stream; name="tinc1.yang"
Content-Disposition: attachment; filename="tinc1.yang"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_huvb6kub0

bW9kdWxlIHRpbmMxIHsKCiAgICBuYW1lc3BhY2UgImh0dHA6Ly95dW1hd29ya3MuY29tL25zL3Rp
bmMxIjsKICAgIHByZWZpeCAidGluYzEiOwoKICAgIGluY2x1ZGUgdGluYzFhOwogICAgaW5jbHVk
ZSB0aW5jMWI7CgogICAgcmV2aXNpb24gMjAxNC0wNS0wNjsKCiB9Cg==
--089e0153705eb4e7c704f8bc4e49
Content-Type: application/octet-stream; name="tinc1a.yang"
Content-Disposition: attachment; filename="tinc1a.yang"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_huvb6kut1

c3VibW9kdWxlIHRpbmMxYSB7CgogICAgYmVsb25ncy10byB0aW5jMSB7IHByZWZpeCAidGluYzEi
OyB9CgogICAgcmV2aXNpb24gMjAxNC0wNS0wNjsKCiAgICB0eXBlZGVmIHR5cGUxIHsKICAgICAg
dHlwZSBpbnQzMjsKICAgIH0KCiB9Cg==
--089e0153705eb4e7c704f8bc4e49
Content-Type: application/octet-stream; name="tinc1b.yang"
Content-Disposition: attachment; filename="tinc1b.yang"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_huvb6kuz2

c3VibW9kdWxlIHRpbmMxYiB7CgogICAgYmVsb25ncy10byB0aW5jMSB7IHByZWZpeCAidGluYzEi
OyB9CiAgICBpbmNsdWRlIHRpbmMxYzsKCiAgICByZXZpc2lvbiAyMDE0LTA1LTA2OwoKICAgIHR5
cGVkZWYgdHlwZTIgewogICAgICB0eXBlIHVpbnQzMjsKICAgIH0KCiAgICBncm91cGluZyBncnAx
IHsKICAgICAgbGVhZiBncnAtbGVhZiB7CiAgICAgICAgdHlwZSB0aW5jMTp0eXBlMzsKICAgICAg
fQogICAgfQoKIH0K
--089e0153705eb4e7c704f8bc4e49
Content-Type: application/octet-stream; name="tinc1c.yang"
Content-Disposition: attachment; filename="tinc1c.yang"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_huvb6kv43

c3VibW9kdWxlIHRpbmMxYyB7CgogICAgYmVsb25ncy10byB0aW5jMSB7IHByZWZpeCAidGluYzEi
OyB9CgogICAgcmV2aXNpb24gMjAxNC0wNS0wNjsKCiAgICB0eXBlZGVmIHR5cGUzIHsKICAgICAg
dHlwZSBzdHJpbmc7CiAgICB9CgogfQo=
--089e0153705eb4e7c704f8bc4e49
Content-Type: application/octet-stream; name="tinc2.yang"
Content-Disposition: attachment; filename="tinc2.yang"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_huvb6kv94

bW9kdWxlIHRpbmMyIHsKCiAgICBuYW1lc3BhY2UgImh0dHA6Ly95dW1hd29ya3MuY29tL25zL3Rp
bmMyIjsKICAgIHByZWZpeCAidGluYzIiOwoKICAgIGltcG9ydCB0aW5jMSB7IHByZWZpeCB0aW5j
MTsgfQoKICAgIHJldmlzaW9uIDIwMTQtMDUtMDY7CgogICAgbGVhZiB0MSB7CiAgICAgIHR5cGUg
dGluYzE6dHlwZTE7CiAgICB9CgogICAgbGVhZiB0MiB7CiAgICAgIHR5cGUgdGluYzE6dHlwZTI7
CiAgICB9CgogICAgbGVhZiB0MyB7CiAgICAgIHR5cGUgdGluYzE6dHlwZTM7CiAgICB9CgogICAg
dXNlcyB0aW5jMTpncnAxOwoKIH0K
--089e0153705eb4e7c704f8bc4e49--


From nobody Tue May  6 09:34:06 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8781A0252 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 09:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d_uuBnTKaLa for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 09:33:55 -0700 (PDT)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A01A017E for <netmod@ietf.org>; Tue,  6 May 2014 09:33:55 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id e16so7187731qcx.0 for <netmod@ietf.org>; Tue, 06 May 2014 09:33:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tXRUPiAC7uFOS1T7nLdb6VwcI8ObeL2Jord4aJS5Dc4=; b=cmoH0+K/E5TFQCA/JCCiDPpMtpPt6D/soiExhN5alP9IxCBBSmCo+O3r/pDQbnQFu5 yXXXv9B8wcUh8j39B3pKeCprT4paXAfSOIp6q0ztM6Ynyn3RsCijjFAryWFqSaPsthjO OnplqDhtmuk0qm8PuAXO1AEIIw2JPtmVHPMowdZPpazrjgQD7lGWz6n2YjwPpjX1KkdY /ufaAVBeTAMYblLdMXA0MHUHqU81EtigK2HWN7+95if6GyloO5dEw1zeks2Gd5/ADyoV X3IKaiCjoR0uF9a6VdqN89AYFnbkhoimyNfQgQSNzc36wo3RqYpYmG+5FSEqhb8sPGoA SDPA==
X-Gm-Message-State: ALoCoQkH8FBxAcIMD8yfO+i7n3sa1CPa87YD0fXpO3vgPGAEkzZIVdWkLZLKPhHkH+Q0sgvWcEiY
MIME-Version: 1.0
X-Received: by 10.140.18.173 with SMTP id 42mr51710655qgf.94.1399394031351; Tue, 06 May 2014 09:33:51 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Tue, 6 May 2014 09:33:51 -0700 (PDT)
In-Reply-To: <3B593152-FD20-4FDE-9376-1BB950E49230@nic.cz>
References: <CABCOCHQyWY2OXRt=fqx5-nsc+pyyGucryAZpkc9uXLVp2b-oww@mail.gmail.com> <4D5E04C9-7CE6-439A-9B1B-DDB84A4B9B4F@nic.cz> <CABCOCHR_FqKUaj+HNSRMDgimR760XHXRL9Jy9N_35vjEHrfffA@mail.gmail.com> <20140505.212646.11884293.mbj@tail-f.com> <3B593152-FD20-4FDE-9376-1BB950E49230@nic.cz>
Date: Tue, 6 May 2014 09:33:51 -0700
Message-ID: <CABCOCHSzp8YNH_QELUSGwoEmnM5y=b9u=reWEVPZH+4UJ70VWg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11351cb224575904f8bdd0e5
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hvrn6UDa1mBl1YSSSq3RbMKhOng
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 issue: enabled leaf design pattern
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 16:33:59 -0000

--001a11351cb224575904f8bdd0e5
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 5, 2014 at 9:39 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 05 May 2014, at 21:26, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaworks.com> wrote:
> >> Hi,
> >>
> >> Here is what I mean by a typedef solution.
> >> Why did the WG decide this cannot work?
> >
> > I don't think this was ever proposed and considered by the WG.
>
> +1
>
> This is doable in good old YANG 1.0.
>
>
I proposed a grouping earlier but that was too restrictive.
I realized the default does not matter for tagging purposes.
The exact requirements and effects of disabling are model-specific.

The SHOULD means somebody needs a good reason not to make
the leaf affect just the parent subtree. (Before it was a MUST I think.)



> Lada
>
>
Andy


> >
> >
> > /martin
> >
> >
> >
> >>
> >> OLD:
> >>
> >>         leaf enabled {
> >>           type boolean;
> >>           default "true";
> >>           description
> >>             "This leaf contains the configured, desired state of the
> >>              interface.
> >>              Systems that implement the IF-MIB use the value of this
> >>              leaf in the 'running' datastore to set
> >>              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
> >>              has been initialized, as described in RFC 2863.
> >>
> >>              Changes in this leaf in the 'running' datastore are
> >>              reflected in ifAdminStatus, but if ifAdminStatus is
> >>              changed over SNMP, this leaf is not affected.";
> >>           reference
> >>             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
> >>         }
> >>
> >> NEW:
> >>
> >>         // this is a general typedef, probably in ietf-yang-types
> >>
> >>         typedef oper-enabled {
> >>           type boolean;
> >>           description
> >>             "Used to operationally disable some configuration.
> >>              The affected configuration SHOULD be limited to
> >>              the parent node of the leaf using this typedef,
> >>              but it MAY affect other configuration as described
> >>              in the module.";
> >>         }
> >>
> >>
> >>         leaf enabled {
> >>           type yang:oper-enabled;
> >>           default "true";
> >>           description
> >>             "This leaf contains the configured, desired state of the
> >>              interface.
> >>              Systems that implement the IF-MIB use the value of this
> >>              leaf in the 'running' datastore to set
> >>              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
> >>              has been initialized, as described in RFC 2863.
> >>
> >>              Changes in this leaf in the 'running' datastore are
> >>              reflected in ifAdminStatus, but if ifAdminStatus is
> >>              changed over SNMP, this leaf is not affected.";
> >>           reference
> >>             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
> >>         }
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >>
> >> On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>
> >>>
> >>> On 05 May 2014, at 17:05, Andy Bierman <andy@yumaworks.com> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> >>>>
> >>>> On 05 May 2014, at 10:48, Andy Bierman <andy@yumaworks.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund <mbj@tail-f.com>
> >>> wrote:
> >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>>>>> Andy Bierman <andy@yumaworks.com> writes:
> >>>>>>
> >>>>>>> On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <lhotka@nic.cz>
> >>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On 04 May 2014, at 10:33, Andy Bierman <andy@yumaworks.com>
> >>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <lhotka@nic.cz>
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>> On 03 May 2014, at 21:31, Andy Bierman <andy@yumaworks.com>
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <
> >>> lhotka@nic.cz>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 03 May 2014, at 18:42, Andy Bierman <andy@yumaworks.com>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> Problem:
> >>>>>>>>>>>
> >>>>>>>>>>> The use of a leaf in the data model (such as the
> >>>>>>>> /interfaces/interface/enabled
> >>>>>>>>>>> leaf in the ietf-interfaces module) does not account for
> >>> YANG
> >>>>>>>> validation rules
> >>>>>>>>>>> for many statements that can reference the disabled subtree
> >>> from
> >>>>>>>> outside
> >>>>>>>>>>> of that subtree:
> >>>>>>>>>>>
> >>>>>>>>>>>    - must
> >>>>>>>>>>>    - when
> >>>>>>>>>>>    - unique
> >>>>>>>>>>>    - min-elements
> >>>>>>>>>>>    - max-elements
> >>>>>>>>>>>    - leafref (valid instances)
> >>>>>>>>>>>    - choices (disabled case is still the active case, so
> >>> no other
> >>>>>>>> can be used)
> >>>>>>>>>>
> >>>>>>>>>> In my view, an "enabled false" leaf *operationally* disables a
> >>>>>>>> particular instance or function. For all other purposes related to
> >>>>>>>> datastore validation, the value of the enabled leaf doesn't
> >>> matter. In
> >>>>>>>> other words, "enabled false" is not the same as commenting out the
> >>>>>>>> corresponding instance in the configuration.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> OK -- they may be different, but the enabled leaf is ad-hoc,
> >>>>>>>>>> and YANG designers must know about this leaf.  Adding or
> >>> removing
> >>>>>>>>>> this leaf could break other YANG statements.
> >>>>>>>>>>
> >>>>>>>>>> E,g,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>   leaf active-foo-interface {
> >>>>>>>>>>       type  if:interface-ref;
> >>>>>>>>>>       mandatory true;
> >>>>>>>>>>   }
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> By YANG validation rules, the  leafref test for interface name
> >>>>>>>>>> will include all disabled interfaces.
> >>>>>>>>>
> >>>>>>>>> Yes.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Doesn't every object that uses the interface-ref typedef need
> >>>>>>>>>> to have a must-stmt making sure the enabled leaf is set,
> >>>>>>>>>> if they want to activate a service on only enabled interfaces?
> >>>>>>>>>>
> >>>>>>>>>> (Is this the must-stmt to use?)
> >>>>>>>>>>
> >>>>>>>>>>   leaf active-foo-interface {
> >>>>>>>>>>       type  if:interface-ref;
> >>>>>>>>>>       must
> >>> "/if:interfaces/if:interface[if:name=current()]/enabled";
> >>>>>>>>>>       mandatory true;
> >>>>>>>>>>   }
> >>>>>>>>>>
> >>>>>>>>>> Don't all must/when/leafref validation statements that want
> >>> only
> >>>>>>>>>> active interfaces need to be written this way?
> >>>>>>>>>
> >>>>>>>>> I don't think so. An operator may want to pre-configure an
> >>> interface in
> >>>>>>>> the disabled state, set up all references to it etc., so that
> >>> everything
> >>>>>>>> will be up and running after setting the single "enabled" leaf to
> >>> true.
> >>>>>>>>>
> >>>>>>>>> I said "this is what has to be written to identity active
> >>> interfaces"
> >>>>>>>>> and you respond "maybe they want to select disabled interfaces".
> >>>>>>>>
> >>>>>>>> It's up to the server to interpret the entire configuration, so
> >>> if a
> >>>>>>>> service is enabled in configuration but it depends on an
> >>> interface that is
> >>>>>>>> currently disabled, the server might keep that service
> >>> operationally
> >>>>>>>> disabled as well.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Not if the YANG validation rules say differently.
> >>>>>>> My point is that the YANG designer must write all validation rules
> >>> to
> >>>>>>> account for disabled configuration, or the model is wrong.
> >>>>>>
> >>>>>> I don't agree. It would be extremely impractical to render a
> >>> configuration
> >>>>>> invalid just by disabling an interface.
> >>>>>
> >>>>>
> >>>>> The important point is that the designer better know every single
> >>>>> YANG object and write the validation rules correctly.
> >>>>> Inconvenient or not, if some component needs to use
> >>>>> only active interfaces, then ignoring the 'active' leaf will be
> broken.
> >>>>
> >>>> It will be broken in terms of operational state, not configuration.
> Many
> >>> changes in configuration have ripple effects and well-designed server
> >>> should be able to trace dependencies and act accordingly, rather than
> >>> forcing the user to do it manually.
> >>>>
> >>>>
> >>>>
> >>>> The server cannot ripple the disable event automatically using an
> ad-hoc
> >>> solution,
> >>>> but that is just an implementation detail to the IETF, so it's not
> >>> important.
> >>>
> >>> Of course it can, why not? An implementor of the routing module is
> >>> expected to follow sec. 6 rules. It is just not so that the same
> callback
> >>> can be used whenever any "enabled" leaf is changed.
> >>>
> >>>>
> >>>> The reason RowStatus is a bad idea is that it is not config, but it is
> >>> mixed in
> >>>> with the config, and it is config according to YANG validation rules.
> >>>> When you set the enabled leaf to false with an <edit-config>
> operation,
> >>>> you are configuring the interface to be operationally disabled.
> >>>
> >>> Yes.
> >>>
> >>>>
> >>>> All YANG validation outside the interface has to account for
> interfaces
> >>>> that have been configured to be operationally disabled.
> >>>
> >>> This is where we differ, as long as you talk about configuration. The
> >>> ex-vlan module in interfaces draft doesn't have any must statement
> >>> requiring that the base-interface be enabled.
> >>>
> >>>>
> >>>> When the hardware is operationally broken, setting 'enable' to true
> >>>> is not going to fix it.  The enabled leaf is just the desired state,
> like
> >>>> all the other config=true nodes.
> >>>
> >>> Sure.
> >>>
> >>>>
> >>>> I agree that the desired state and operational state are not the same.
> >>>> I don't agree that setting enabled-leaf to false is the same as the
> >>> system
> >>>> disabling a broken interface.
> >>>
> >>> Where did I say that?
> >>>
> >>> Lada
> >>>
> >>>>
> >>>>
> >>>> Andy
> >>>>
> >>>>>
> >>>>> The system can be hand-coded at great expense to deal with any
> >>>>> poorly designed ad-hoc mechanism.  It is just engineering decisions
> >>>>> that determine whether we develop an efficient programmatic API
> >>>>> or we develop CLI with angle brackets.
> >>>>
> >>>> So what would you do with the rules in sec. 6 of the routing module?
> >>> Note that they involve not only "enabled" leafs in the interfaces and
> ip
> >>> modules, but also "ip:forwarding".
> >>>>
> >>>> For example, if /if:interfaces/if:interface/if:enabled is set to false
> >>> for an interface, I don't want to force the client to go and remove
> that
> >>> interface from all configured routing instances.
> >>>>
> >>>> Similarly, disabling a physical interface should automatically lead to
> >>> disabling all logical interfaces created on top of that physical
> interface
> >>> - without having to disable all of them manually.
> >>>>
> >>>> Lada
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> I think you are both right - the 'inactive' feature is very useful
> >>>>> (and it works just as if the node is deleted), but it doesn't
> >>>>> necessarilty replace an "enabled" leaf in all cases.  As you noted,
> >>>>> they behave differently.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Andy
> >>>>>
> >>>>>
> >>>>> /martin
> >>>>>
> >>>>
> >>>> --
> >>>> Ladislav Lhotka, CZ.NIC Labs
> >>>> PGP Key ID: E74E8C0C
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>>
> >>>
> >>>
> >>>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11351cb224575904f8bdd0e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, May 5, 2014 at 9:39 PM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 05 May 2014, at 21:26, Martin Bjorklund &lt;<a href=3D"mailto:mbj@tail-f=
.com">mbj@tail-f.com</a>&gt; wrote:<br>
<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; wrote:<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; Here is what I mean by a typedef solution.<br>
&gt;&gt; Why did the WG decide this cannot work?<br>
&gt;<br>
&gt; I don&#39;t think this was ever proposed and considered by the WG.<br>
<br>
+1<br>
<br>
This is doable in good old YANG 1.0.<br>
<br></blockquote><div><br></div><div>I proposed a grouping earlier but that=
 was too restrictive.</div><div>I realized the default does not matter for =
tagging purposes.</div><div>The exact requirements and effects of disabling=
 are model-specific.</div>
<div><br></div><div>The SHOULD means somebody needs a good reason not to ma=
ke</div><div>the leaf affect just the parent subtree. (Before it was a MUST=
 I think.)</div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

Lada<br>
<br></blockquote><div><br></div><div>Andy</div><div>=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
&gt;<br>
&gt;<br>
&gt; /martin<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; OLD:<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 leaf enabled {<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 type boolean;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 default &quot;true&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 description<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &quot;This leaf contains the configured, d=
esired state of the<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0interface.<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0Systems that implement the IF-MIB use t=
he value of this<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0leaf in the &#39;running&#39; datastore=
 to set<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0IF-MIB.ifAdminStatus to &#39;up&#39; or=
 &#39;down&#39; after an ifEntry<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0has been initialized, as described in R=
FC 2863.<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0Changes in this leaf in the &#39;runnin=
g&#39; datastore are<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0reflected in ifAdminStatus, but if ifAd=
minStatus is<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0changed over SNMP, this leaf is not aff=
ected.&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 reference<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &quot;RFC 2863: The Interfaces Group MIB -=
 ifAdminStatus&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 }<br>
&gt;&gt;<br>
&gt;&gt; NEW:<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 // this is a general typedef, probably in ietf-yan=
g-types<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 typedef oper-enabled {<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 type boolean;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 description<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &quot;Used to operationally disable some c=
onfiguration.<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0The affected configuration SHOULD be li=
mited to<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0the parent node of the leaf using this =
typedef,<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0but it MAY affect other configuration a=
s described<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0in the module.&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 }<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 leaf enabled {<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 type yang:oper-enabled;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 default &quot;true&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 description<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &quot;This leaf contains the configured, d=
esired state of the<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0interface.<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0Systems that implement the IF-MIB use t=
he value of this<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0leaf in the &#39;running&#39; datastore=
 to set<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0IF-MIB.ifAdminStatus to &#39;up&#39; or=
 &#39;down&#39; after an ifEntry<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0has been initialized, as described in R=
FC 2863.<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0Changes in this leaf in the &#39;runnin=
g&#39; datastore are<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0reflected in ifAdminStatus, but if ifAd=
minStatus is<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0changed over SNMP, this leaf is not aff=
ected.&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 reference<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 &quot;RFC 2863: The Interfaces Group MIB -=
 ifAdminStatus&quot;;<br>
&gt;&gt; =A0 =A0 =A0 =A0 }<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Andy<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Mon, May 5, 2014 at 9:25 AM, Ladislav Lhotka &lt;<a href=3D"mai=
lto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 05 May 2014, at 17:05, Andy Bierman &lt;<a href=3D"mailto:a=
ndy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Mon, May 5, 2014 at 2:36 AM, Ladislav Lhotka &lt;<a hre=
f=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On 05 May 2014, at 10:48, Andy Bierman &lt;<a href=3D"mail=
to:andy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Mon, May 5, 2014 at 12:26 AM, Martin Bjorklund &lt;=
<a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">l=
hotka@nic.cz</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.=
com">andy@yumaworks.com</a>&gt; writes:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotk=
a &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On 04 May 2014, at 10:33, Andy Bierman &lt=
;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Sun, May 4, 2014 at 12:40 AM, Ladis=
lav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On 03 May 2014, at 21:31, Andy Bierman=
 &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Sat, May 3, 2014 at 11:50 AM, L=
adislav Lhotka &lt;<br>
&gt;&gt;&gt; <a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On 03 May 2014, at 18:42, Andy Bie=
rman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a>&gt;<b=
r>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Problem:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; The use of a leaf in the data =
model (such as the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; /interfaces/interface/enabled<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; leaf in the ietf-interfaces mo=
dule) does not account for<br>
&gt;&gt;&gt; YANG<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; validation rules<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; for many statements that can r=
eference the disabled subtree<br>
&gt;&gt;&gt; from<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; outside<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; of that subtree:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- must<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- when<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- unique<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- min-elements<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- max-elements<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- leafref (valid instan=
ces)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0- choices (disabled cas=
e is still the active case, so<br>
&gt;&gt;&gt; no other<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; can be used)<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; In my view, an &quot;enabled false=
&quot; leaf *operationally* disables a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; particular instance or function. For all o=
ther purposes related to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; datastore validation, the value of the ena=
bled leaf doesn&#39;t<br>
&gt;&gt;&gt; matter. In<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; other words, &quot;enabled false&quot; is =
not the same as commenting out the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; corresponding instance in the configuratio=
n.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; OK -- they may be different, but t=
he enabled leaf is ad-hoc,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; and YANG designers must know about=
 this leaf. =A0Adding or<br>
&gt;&gt;&gt; removing<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; this leaf could break other YANG s=
tatements.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; E,g,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 leaf active-foo-interface {<br=
>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0 =A0 type =A0if:interface-r=
ef;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0 =A0 mandatory true;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 }<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; By YANG validation rules, the =A0l=
eafref test for interface name<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; will include all disabled interfac=
es.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Yes.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Doesn&#39;t every object that uses=
 the interface-ref typedef need<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to have a must-stmt making sure th=
e enabled leaf is set,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; if they want to activate a service=
 on only enabled interfaces?<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (Is this the must-stmt to use?)<br=
>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 leaf active-foo-interface {<br=
>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0 =A0 type =A0if:interface-r=
ef;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0 =A0 must<br>
&gt;&gt;&gt; &quot;/if:interfaces/if:interface[if:name=3Dcurrent()]/enabled=
&quot;;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 =A0 =A0 mandatory true;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; =A0 }<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Don&#39;t all must/when/leafref va=
lidation statements that want<br>
&gt;&gt;&gt; only<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; active interfaces need to be writt=
en this way?<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I don&#39;t think so. An operator may =
want to pre-configure an<br>
&gt;&gt;&gt; interface in<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the disabled state, set up all references =
to it etc., so that<br>
&gt;&gt;&gt; everything<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; will be up and running after setting the s=
ingle &quot;enabled&quot; leaf to<br>
&gt;&gt;&gt; true.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I said &quot;this is what has to be wr=
itten to identity active<br>
&gt;&gt;&gt; interfaces&quot;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; and you respond &quot;maybe they want =
to select disabled interfaces&quot;.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; It&#39;s up to the server to interpret the=
 entire configuration, so<br>
&gt;&gt;&gt; if a<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; service is enabled in configuration but it=
 depends on an<br>
&gt;&gt;&gt; interface that is<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; currently disabled, the server might keep =
that service<br>
&gt;&gt;&gt; operationally<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; disabled as well.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Not if the YANG validation rules say different=
ly.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; My point is that the YANG designer must write =
all validation rules<br>
&gt;&gt;&gt; to<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; account for disabled configuration, or the mod=
el is wrong.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I don&#39;t agree. It would be extremely impractic=
al to render a<br>
&gt;&gt;&gt; configuration<br>
&gt;&gt;&gt;&gt;&gt;&gt; invalid just by disabling an interface.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; The important point is that the designer better know e=
very single<br>
&gt;&gt;&gt;&gt;&gt; YANG object and write the validation rules correctly.<=
br>
&gt;&gt;&gt;&gt;&gt; Inconvenient or not, if some component needs to use<br=
>
&gt;&gt;&gt;&gt;&gt; only active interfaces, then ignoring the &#39;active&=
#39; leaf will be broken.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; It will be broken in terms of operational state, not confi=
guration. Many<br>
&gt;&gt;&gt; changes in configuration have ripple effects and well-designed=
 server<br>
&gt;&gt;&gt; should be able to trace dependencies and act accordingly, rath=
er than<br>
&gt;&gt;&gt; forcing the user to do it manually.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The server cannot ripple the disable event automatically u=
sing an ad-hoc<br>
&gt;&gt;&gt; solution,<br>
&gt;&gt;&gt;&gt; but that is just an implementation detail to the IETF, so =
it&#39;s not<br>
&gt;&gt;&gt; important.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Of course it can, why not? An implementor of the routing modul=
e is<br>
&gt;&gt;&gt; expected to follow sec. 6 rules. It is just not so that the sa=
me callback<br>
&gt;&gt;&gt; can be used whenever any &quot;enabled&quot; leaf is changed.<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The reason RowStatus is a bad idea is that it is not confi=
g, but it is<br>
&gt;&gt;&gt; mixed in<br>
&gt;&gt;&gt;&gt; with the config, and it is config according to YANG valida=
tion rules.<br>
&gt;&gt;&gt;&gt; When you set the enabled leaf to false with an &lt;edit-co=
nfig&gt; operation,<br>
&gt;&gt;&gt;&gt; you are configuring the interface to be operationally disa=
bled.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; All YANG validation outside the interface has to account f=
or interfaces<br>
&gt;&gt;&gt;&gt; that have been configured to be operationally disabled.<br=
>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; This is where we differ, as long as you talk about configurati=
on. The<br>
&gt;&gt;&gt; ex-vlan module in interfaces draft doesn&#39;t have any must s=
tatement<br>
&gt;&gt;&gt; requiring that the base-interface be enabled.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; When the hardware is operationally broken, setting &#39;en=
able&#39; to true<br>
&gt;&gt;&gt;&gt; is not going to fix it. =A0The enabled leaf is just the de=
sired state, like<br>
&gt;&gt;&gt;&gt; all the other config=3Dtrue nodes.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Sure.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I agree that the desired state and operational state are n=
ot the same.<br>
&gt;&gt;&gt;&gt; I don&#39;t agree that setting enabled-leaf to false is th=
e same as the<br>
&gt;&gt;&gt; system<br>
&gt;&gt;&gt;&gt; disabling a broken interface.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Where did I say that?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Lada<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Andy<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; The system can be hand-coded at great expense to deal =
with any<br>
&gt;&gt;&gt;&gt;&gt; poorly designed ad-hoc mechanism. =A0It is just engine=
ering decisions<br>
&gt;&gt;&gt;&gt;&gt; that determine whether we develop an efficient program=
matic API<br>
&gt;&gt;&gt;&gt;&gt; or we develop CLI with angle brackets.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; So what would you do with the rules in sec. 6 of the routi=
ng module?<br>
&gt;&gt;&gt; Note that they involve not only &quot;enabled&quot; leafs in t=
he interfaces and ip<br>
&gt;&gt;&gt; modules, but also &quot;ip:forwarding&quot;.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; For example, if /if:interfaces/if:interface/if:enabled is =
set to false<br>
&gt;&gt;&gt; for an interface, I don&#39;t want to force the client to go a=
nd remove that<br>
&gt;&gt;&gt; interface from all configured routing instances.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Similarly, disabling a physical interface should automatic=
ally lead to<br>
&gt;&gt;&gt; disabling all logical interfaces created on top of that physic=
al interface<br>
&gt;&gt;&gt; - without having to disable all of them manually.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Lada<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I think you are both right - the &#39;inactive&#39; fe=
ature is very useful<br>
&gt;&gt;&gt;&gt;&gt; (and it works just as if the node is deleted), but it =
doesn&#39;t<br>
&gt;&gt;&gt;&gt;&gt; necessarilty replace an &quot;enabled&quot; leaf in al=
l cases. =A0As you noted,<br>
&gt;&gt;&gt;&gt;&gt; they behave differently.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Andy<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; /martin<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt;&gt;&gt;&gt; PGP Key ID: E74E8C0C<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt;&gt;&gt; PGP Key ID: E74E8C0C<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11351cb224575904f8bdd0e5--


From nobody Tue May  6 14:49:27 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AD51A0527 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 14:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.151
X-Spam-Level: 
X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PdFPZXWRJJm for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 14:49:23 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA651A049C for <netmod@ietf.org>; Tue,  6 May 2014 14:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21098; q=dns/txt; s=iport; t=1399412960; x=1400622560; h=from:to:subject:date:message-id:mime-version; bh=GCs0kZgcItcmo9CjEM9is1JrX4YDFnCutT6ThdzqMtc=; b=SoQYzSWHrpNn9rwQe2fdYNZWw+Jvq6kgretVWXiHc4SGcDr7tRRMCSPC wRHpelaym/WBK7TzSdR2G1+KeGwScgB+osZQ101oihahfjLcMvn/ZLgrH y2hBcWe1osWjz2qYLhj9bPxFQQ2gjtb9tA25m2MujPAUknlObg1JtPa9D A=;
X-Files: extension-validation.yang, extension-validation-self-validating.yang : 3528, 4783
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAGxYaVOtJA2D/2dsb2JhbABagkJET1jEZ4EgFnSCJwEELV4BKiYwJgEEGwYNiCaZdbRFF4kxhHCDYoEVBIlOh1aBOZlVgzSBbyQc
X-IronPort-AV: E=Sophos;i="4.97,998,1389744000";  d="yang'?scan'208,217";a="41528205"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 06 May 2014 21:49:18 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s46LnItB012457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Tue, 6 May 2014 21:49:18 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 6 May 2014 16:49:18 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Yang 1.1 Extension Validation?
Thread-Index: Ac9pdPKbirurxoM3R52BRWZ3rP4xYQ==
Date: Tue, 6 May 2014 21:49:17 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AAD3D7@xmb-aln-x08.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.138]
Content-Type: multipart/mixed; boundary="_005_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3ISaPPqPiQ7JBZUd72OpChkRPBU
Subject: [netmod] Yang 1.1 Extension Validation?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 21:49:26 -0000

--_005_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_
Content-Type: multipart/alternative;
	boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_"

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks,



I've been discussing Yang ideas and pain points with a few teams who have b=
een applying the language in multiple scenarios over the last few years, an=
d based on our usage experiences, we've come up with a few ideas/questions =
which we think are valuable and I haven=B9t seen other people bring up on t=
he alias or in Yang 1.1 discussions.



So I'll post a few threads, and would welcome your thoughts :-) The first i=
s relating to how extensions are specified.



Issue:



Yang has a clean/simple grammar that allows for a simple domain-specific de=
scription. In particular, (almost) all of the ABNF boils down to:

  fixed-keyword variable-argument?;

  fixed-keyword variable-argument? { fixed-child-keyword variable-argument?=
 ...}

where the set of valid keywords to use as "fixed-child-keyword" depend on w=
hat "fixed-keyword" is.



This can be used when defining extensions, allowing a strict grammar to be =
specified in the extension description. This has the following benefits:

- It helps ensure that the usage of extensions is defined clearly and compr=
ehensively.

- It encourages Yang extensions to follow the grammar patterns of the base =
language.

- It allows automated validation of extended grammar.



Note that AFAICS basically all of the base Yang grammar can also be defined=
 in this way. (FWIW the set of rules is derived from Pyang's grammar checki=
ng.)



Solution:



"extension-validation.yang", attached, describes the extra grammar needed t=
o perform this validation.



It's described there in the form of a Yang extension, but IMO it would be b=
etter as a part of the base Yang syntax to use as a recommended way of defi=
ning extensions in Yang 1.1. (And doing so would allow for example the use =
of "description" and "pattern" keywords within the "argument" subblock.)



The "extension-validation-self-validating.yang" module (also attached) illu=
strates the usage of these extensions (-; by applying them to the module it=
self ;-).



Alternative solution:



This could be implemented as an extension rather than as part of the base g=
rammar, as per the attached example (though this has disadvantages as noted=
 above).





Cheers,

Peyman





--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:"Courier New";
	mso-fareast-language:EN-US;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi folks,<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">I've been discussing Yang ideas and pain points w=
ith a few teams who have been applying the language in multiple scenarios o=
ver the last few years, and based on our usage experiences, we've come up w=
ith a few ideas/questions which we
 think are valuable and I haven=B9t seen other people bring up on the alias=
 or in Yang 1.1 discussions.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">So I'll post a few threads, and would welcome you=
r thoughts :-) The first is relating to how extensions are specified.<o:p><=
/o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Issue:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Yang has a clean/simple grammar that allows for a=
 simple domain-specific description. In particular, (almost) all of the ABN=
F boils down to:<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; fixed-keyword variable-argument?;<o:p></o:=
p></p>
<p class=3D"MsoPlainText">&nbsp; fixed-keyword variable-argument? { fixed-c=
hild-keyword variable-argument? ...}<o:p></o:p></p>
<p class=3D"MsoPlainText">where the set of valid keywords to use as &quot;f=
ixed-child-keyword&quot; depend on what &quot;fixed-keyword&quot; is.<o:p><=
/o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This can be used when defining extensions, allowi=
ng a strict grammar to be specified in the extension description. This has =
the following benefits:<o:p></o:p></p>
<p class=3D"MsoPlainText">- It helps ensure that the usage of extensions is=
 defined clearly and comprehensively.<o:p></o:p></p>
<p class=3D"MsoPlainText">- It encourages Yang extensions to follow the gra=
mmar patterns of the base language.<o:p></o:p></p>
<p class=3D"MsoPlainText">- It allows automated validation of extended gram=
mar.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Note that AFAICS basically all of the base Yang g=
rammar can also be defined in this way. (FWIW the set of rules is derived f=
rom Pyang's grammar checking.)<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Solution:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&quot;extension-validation.yang&quot;, attached, =
describes the extra grammar needed to perform this validation.<o:p></o:p></=
p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">It's described there in the form of a Yang extens=
ion, but IMO it would be better as a part of the base Yang syntax to use as=
 a recommended way of defining extensions in Yang 1.1. (And doing so would =
allow for example the use of &quot;description&quot;
 and &quot;pattern&quot; keywords within the &quot;argument&quot; subblock.=
)<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The &quot;extension-validation-self-validating.ya=
ng&quot; module (also attached) illustrates the usage of these extensions (=
-; by applying them to the module itself ;-).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Alternative solution:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This could be implemented as an extension rather =
than as part of the base grammar, as per the attached example (though this =
has disadvantages as noted above).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Cheers,<o:p></o:p></p>
<p class=3D"MsoPlainText">Peyman<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_--

--_005_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_
Content-Type: application/octet-stream; name="extension-validation.yang"
Content-Description: extension-validation.yang
Content-Disposition: attachment; filename="extension-validation.yang";
	size=3528; creation-date="Fri, 02 May 2014 10:40:59 GMT";
	modification-date="Tue, 06 May 2014 21:21:21 GMT"
Content-Transfer-Encoding: base64

DQptb2R1bGUgZXh0ZW5zaW9uLXZhbGlkYXRpb24gew0KICAgIHByZWZpeCBleHQ7DQoNCiAgICBk
ZXNjcmlwdGlvbg0KICAgICAgICAiQWxsb3dzIGV4dGVuc2lvbiBzeW50YXggdG8gYmUgZGVzY3Jp
YmVkIHVzaW5nIGJhc2ljIHZhbGlkYXRpb24NCiAgICAgICAgIHJ1bGVzLCB0byBkZWZpbmUgYSBz
dHJpY3QgZ3JhbW1hciI7DQoNCiAgICAvKg0KICAgICAqIFJ1bGVzIGRlc2NyaWJpbmcgYXJndW1l
bnQgc3ludGF4IGZvciBleHRlbnNpb25zDQogICAgICovDQoNCiAgICBleHRlbnNpb24gcGF0dGVy
biB7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiUmVndWxhciBleHByZXNzaW9u
IHJlc3RyaW5nIHRoZSB2YWx1ZXMgdGhhdCBjYW4gYmUgdXNlZCBhcyBhbg0KICAgICAgICAgICAg
IGFyZ3VtZW50IHRvIHRoZSBwYXJlbnQgZXh0ZW5zaW9uIGtleXdvcmQuDQoNCiAgICAgICAgICAg
ICBEZWZhdWx0OiAnLionIjsNCg0KICAgICAgICBhcmd1bWVudCAicmVnZXgiOw0KICAgIH0NCg0K
ICAgIGV4dGVuc2lvbiBzY2hlbWEtbm9kZSB7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAg
ICAgICAiSW5kaWNhdGVzIHRoYXQgdGhlIGV4dGVuc2lvbidzIGFyZ3VtZW50IHJlZmVycyB0byBh
IG5vZGUgaW4NCiAgICAgICAgICAgICB0aGUgZGF0YSBtb2RlbCBzY2hlbWEsIGFuZCBkZXNjcmli
ZXMgdGhlIHBhdGggZm9ybWF0IHVzZWQuDQogICAgICAgICAgICAgDQogICAgICAgICAgICAgQXJn
dW1lbnQ6DQogICAgICAgICAgICAgICAgICdhYnNvbHV0ZScgZm9yIGFuIGFic29sdXRlIHNjaGVt
YSBub2RlaWQ7DQogICAgICAgICAgICAgICAgICdkZXNjZW5kYW50JyBmb3IgYSBkZXNjZW5kYW50
IHNjaGVtYSBub2RlaWQ7DQogICAgICAgICAgICAgICAgICdhbnknIGZvciBlaXRoZXIgb2YgdGhl
IGFib3ZlLg0KICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgIFRlcm1zIGFib3ZlIHVzZWQg
YXMgZGVmaW5lZCBpbiBSRkMgNjAyMC4iOw0KICAgICAgICANCiAgICAgICAgYXJndW1lbnQgIm5v
ZGVpZC10eXBlIjsNCiAgICB9DQoNCiAgICBleHRlbnNpb24gdGFyZ2V0LW5vZGUtdHlwZSB7DQog
ICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiTGlzdHMgdGhlIHR5cGVzIG9mIGRhdGEg
bm9kZSB0aGF0IHRoZSBzY2hlbWEgbm9kZWlkIHNwZWNpZmllZA0KICAgICAgICAgICAgIGluIHRo
ZSBleHRlbnNpb24ncyBhcmd1bWVudCBjYW4gcmVmZXIgdG8gKHNwYWNlLXNlcGFyYXRlZCkuIjsN
CiAgICAgICAgDQogICAgICAgIGFyZ3VtZW50ICJub2RlLXR5cGUiOw0KICAgIH0NCg0KICAgIGV4
dGVuc2lvbiBkZWZhdWx0IHsNCiAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJEZXNj
cmliZXMgdGhlIGRlZmF1bHQgdmFsdWUgYW4gZXh0ZW5zaW9uJ3MgYXJndW1lbnQgd291bGQgdGFr
ZQ0KICAgICAgICAgICAgIGlmIHRoZSBleHRlbnNpb24gaXMgbm90IHNwZWNpZmllZCI7DQogICAg
ICAgIA0KICAgICAgICBhcmd1bWVudCBzdHJpbmc7DQogICAgfQ0KDQogICAgLyoNCiAgICAgKiBS
dWxlcyBkZXNjcmliaW5nIGhvdyBleHRlbnNpb25zIGNhbiBiZSB1c2VkIGluIHRoZSBkYXRhIG1v
ZGVsIGhpZXJhcmNoeQ0KICAgICAqLw0KDQogICAgZXh0ZW5zaW9uIHN0cmljdC1ncmFtbWFyIHsN
CiAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJEZWZpbmVzIGEgY29udGFpbmVyIGRl
c2NyaWJpbmcgc3RyaWN0IGdyYW1tYXIgcnVsZXMgZm9yIGFuDQogICAgICAgICAgICAgZXh0ZW5z
aW9uIGtleXdvcmQsIHVzaW5nIG9uIHRoZSB2YWxpZC1wYXJlbnQsIHZhbGlkLWNoaWxkDQogICAg
ICAgICAgICAgYW5kIGNhcmRpbmFsaXR5IHN0YXRlbWVudHMuDQogICAgICAgICAgICAgDQogICAg
ICAgICAgICAgTkI6IEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIHZhbGlkLXBhcmVudCBzdGF0
ZW1lbnQgc2hvdWxkDQogICAgICAgICAgICAgYmUgdXNlZCBpbiBwcmVmZXJlbmNlIHRvIHZhbGlk
LWNoaWxkIGluIGNhc2VzIHdoZXJlIHRoZXkNCiAgICAgICAgICAgICB3b3VsZCBvdGhlcndpc2Ug
YmUgZXF1aXZhbGVudC4iOw0KICAgIH0NCg0KICAgIGV4dGVuc2lvbiB2YWxpZC1wYXJlbnQgew0K
ICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgIlVzZWQgd2l0aGluIGFuIGV4dGVuc2lv
biB0byBpbmRpY2F0ZSB0aGUga2V5d29yZHMgKGluIHRoZSBiYXNlDQogICAgICAgICAgICAgWWFu
ZyBncmFtbWFyIG9yIGV4dGVuc2lvbiBrZXl3b3Jkcykgd2hpY2ggZGVmaW5lIGEgc3ViYmxvY2sN
CiAgICAgICAgICAgICB3aXRoaW4gd2hpY2ggdGhlIHBhcmVudCBleHRlbnNpb24gY2FuIGJlIHVz
ZWQuDQogICAgICAgICAgICAgDQogICAgICAgICAgICAgS2V5d29yZHMgYXJlIHNwZWNpZmllZCBh
cyBhIHNwYWNlLXNlcGFyYXRlZCBsaXN0Lg0KICAgICAgICAgICAgIA0KICAgICAgICAgICAgIE5C
OiBUaGlzIGlzIGFkZGl0aXZlIHRvIG90aGVyIHZhbGlkLXBhcmVudCBhbmQgdmFsaWQtY2hpbGQN
CiAgICAgICAgICAgICBzdGF0ZW1lbnRzLCBhbmQgdG8gdGhlIGJhc2UgWWFuZyBncmFtbWFyLiI7
DQoNCiAgICAgICAgYXJndW1lbnQga2V5d29yZC1saXN0Ow0KICAgIH0NCg0KICAgIGV4dGVuc2lv
biB2YWxpZC1jaGlsZCB7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiVXNlZCB3
aXRoaW4gYW4gZXh0ZW5zaW9uIHRvIGluZGljYXRlIHRoZSB2YWxpZCBjaGlsZA0KICAgICAgICAg
ICAgIGtleXdvcmRzIHRoYXQgY2FuIGJlIHNwZWNpZmllZCBpbiBhIHN1YmJsb2NrIHVuZGVyIHRo
ZQ0KICAgICAgICAgICAgIGV4dGVuc2lvbiBzdGF0ZW1lbnQuDQogICAgICAgICAgICAgDQogICAg
ICAgICAgICAgS2V5d29yZHMgYXJlIHNwZWNpZmllZCBhcyBhIHNwYWNlLXNlcGFyYXRlZCBsaXN0
Lg0KDQogICAgICAgICAgICAgTkI6IFRoaXMgaXMgYWRkaXRpdmUgdG8gb3RoZXIgdmFsaWQtcGFy
ZW50IGFuZCB2YWxpZC1jaGlsZA0KICAgICAgICAgICAgIHN0YXRlbWVudHMsIGFuZCB0byB0aGUg
YmFzZSBZYW5nIGdyYW1tYXIuIjsNCg0KICAgICAgICBhcmd1bWVudCBrZXl3b3JkLWxpc3Q7DQog
ICAgfQ0KDQogICAgZXh0ZW5zaW9uIGNhcmRpbmFsaXR5IHsNCiAgICAgICAgZGVzY3JpcHRpb24N
CiAgICAgICAgICAgICJVc2VkIHRvIGluZGljYXRlIGhvdyBtYW55IHRpbWVzIGEgc3RhdGVtZW50
IGNhbiBiZSB1c2VkDQogICAgICAgICAgICAgd2l0aGluIHRoZSBzYW1lIHN1YmJsb2NrDQoNCiAg
ICAgICAgICAgICBBcmd1bWVudDogICAgICAgICAgICANCiAgICAgICAgICAgICAgICAnMC0xJyB0
byBpbmRpY2F0ZSBhbiBvcHRpb25hbCBzdGF0ZW1lbnQgdXNlZCBvbmNlOw0KICAgICAgICAgICAg
ICAgICcxJyBmb3IgYSBtYW5kYXRvcnkgc3RhdGVtZW50Ow0KICAgICAgICAgICAgICAgICdtdWx0
aXBsZScgZm9yIGEgc3RhdGVtZW50IHRoYXQgY2FuIGJlIHVzZWQgbXVsdGlwbGUgdGltZXMuIjsN
Cg0KICAgICAgICBhcmd1bWVudCAiY2FyZGluYWxpdHktdHlwZSI7DQogICAgfQ0KfQ0K

--_005_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_
Content-Type: application/octet-stream;
	name="extension-validation-self-validating.yang"
Content-Description: extension-validation-self-validating.yang
Content-Disposition: attachment;
	filename="extension-validation-self-validating.yang"; size=4783;
	creation-date="Fri, 02 May 2014 11:01:45 GMT";
	modification-date="Tue, 06 May 2014 21:21:16 GMT"
Content-Transfer-Encoding: base64

DQptb2R1bGUgZXh0ZW5zaW9uLXZhbGlkYXRpb24gew0KICAgIHByZWZpeCBleHQ7DQogDQogICAg
ZGVzY3JpcHRpb24NCiAgICAgICAgIkFsbG93cyBleHRlbnNpb24gc3ludGF4IHRvIGJlIGRlc2Ny
aWJlZCB1c2luZyBiYXNpYyB2YWxpZGF0aW9uDQogICAgICAgICBydWxlcywgdG8gZGVmaW5lIGEg
c3RyaWN0IGdyYW1tYXIiOw0KDQogICAgLyoNCiAgICAgKiBSdWxlcyBkZXNjcmliaW5nIGFyZ3Vt
ZW50IHN5bnRheCBmb3IgZXh0ZW5zaW9ucw0KICAgICAqLw0KDQogICAgZXh0ZW5zaW9uIHBhdHRl
cm4gew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgIlJlZ3VsYXIgZXhwcmVzc2lv
biByZXN0cmluZyB0aGUgdmFsdWVzIHRoYXQgY2FuIGJlIHVzZWQgYXMgYW4NCiAgICAgICAgICAg
ICBhcmd1bWVudCB0byB0aGUgcGFyZW50IGV4dGVuc2lvbiBrZXl3b3JkLiI7Cg0KICAgICAgICBh
cmd1bWVudCAicmVnZXgiIHsNCiAgICAgICAgICAgIGV4dDpkZWZhdWx0ICIuKiI7DQogICAgICAg
IH0NCiAgICAgICAgDQogICAgICAgIGV4dDpzdHJpY3QtZ3JhbW1hciB7DQogICAgICAgICAgICBl
eHQ6dmFsaWQtcGFyZW50ICJhcmd1bWVudCI7DQogICAgICAgIH0NCiAgICB9DQoNCiAgICBleHRl
bnNpb24gc2NoZW1hLW5vZGUgew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgIklu
ZGljYXRlcyB0aGF0IHRoZSBleHRlbnNpb24ncyBhcmd1bWVudCByZWZlcnMgdG8gYSBub2RlIGlu
DQogICAgICAgICAgICAgdGhlIGRhdGEgbW9kZWwgc2NoZW1hLCBhbmQgZGVzY3JpYmVzIHRoZSBw
YXRoIGZvcm1hdCB1c2VkLiI7DQogICAgICAgIGFyZ3VtZW50ICJub2RlaWQtdHlwZSIgew0KICAg
ICAgICAgICAgZXh0OnBhdHRlcm4gImFic29sdXRlfGRlc2NlbmRhbnR8YW55IjsNCiAgICAgICAg
fQ0KICAgICAgICBleHQ6c3RyaWN0LWdyYW1tYXIgew0KICAgICAgICAgICAgZXh0OnZhbGlkLXBh
cmVudCAiYXJndW1lbnQiOw0KICAgICAgICB9DQogICAgfQ0KDQogICAgZXh0ZW5zaW9uIHRhcmdl
dC1ub2RlLXR5cGUgew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgIkxpc3RzIHRo
ZSB0eXBlcyBvZiBkYXRhIG5vZGUgdGhhdCB0aGUgc2NoZW1hIG5vZGVpZCBzcGVjaWZpZWQNCiAg
ICAgICAgICAgICBpbiB0aGUgZXh0ZW5zaW9uJ3MgYXJndW1lbnQgY2FuIHJlZmVyIHRvLiI7DQog
ICAgICAgIGFyZ3VtZW50IG5vZGUtdHlwZSB7DQogICAgICAgICAgICBleHQ6cGF0dGVybg0KICAg
ICAgICAgICAgICAgICAgIihjb250YWluZXJ8bGlzdHxsZWFmfGxlYWYtbGlzdHxjaG9pY2V8Y2Fz
ZXxpbnB1dHxvdXRwdXR8bm90aWZpY2F0aW9uKSINCiAgICAgICAgICAgICAgICArICIoIChjb250
YWluZXJ8bGlzdHxsZWFmfGxlYWYtbGlzdHxjaG9pY2V8Y2FzZXxpbnB1dHxvdXRwdXR8bm90aWZp
Y2F0aW9uKSkqIjsNCiAgICAgICAgfQ0KICAgIH0NCg0KICAgIGV4dGVuc2lvbiBkZWZhdWx0IHsN
CiAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJEZXNjcmliZXMgdGhlIGRlZmF1bHQg
dmFsdWUgYW4gZXh0ZW5zaW9uJ3MgYXJndW1lbnQgd291bGQgdGFrZQ0KICAgICAgICAgICAgIGlm
IHRoZSBleHRlbnNpb24gaXMgbm90IHNwZWNpZmllZCI7DQogICAgICAgIGFyZ3VtZW50IHN0cmlu
ZzsNCiAgICAgICAgZXh0OnN0cmljdC1ncmFtbWFyIHsNCiAgICAgICAgICAgIGV4dDp2YWxpZC1w
YXJlbnQgImFyZ3VtZW50IjsNCiAgICAgICAgfQ0KICAgIH0NCg0KICAgIGV4dGVuc2lvbiBkZXNj
cmlwdGlvbiB7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiQWxsb3dzIGEgZGVz
Y3JpcHRpb24gdG8gYmUgcHJvdmlkZWQgZm9yIGFuIGV4dGVuc2lvbidzIGFyZ3VtZW50LiI7DQog
ICAgICAgIGFyZ3VtZW50IHN0cmluZzsNCiAgICAgICAgZXh0OnN0cmljdC1ncmFtbWFyIHsNCiAg
ICAgICAgICAgIGV4dDp2YWxpZC1wYXJlbnQgImFyZ3VtZW50IjsNCiAgICAgICAgfQ0KICAgIH0N
Cg0KICAgIC8qDQogICAgICogUnVsZXMgZGVzY3JpYmluZyBob3cgZXh0ZW5zaW9ucyBjYW4gYmUg
dXNlZCBpbiB0aGUgZGF0YSBtb2RlbCBoaWVyYXJjaHkNCiAgICAgKi8NCg0KICAgIGV4dGVuc2lv
biBzdHJpY3QtZ3JhbW1hciB7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiRGVm
aW5lcyBhIGNvbnRhaW5lciBkZXNjcmliaW5nIHN0cmljdCBncmFtbWFyIHJ1bGVzIGZvciBhbg0K
ICAgICAgICAgICAgIGV4dGVuc2lvbiBrZXl3b3JkLCB1c2luZyBvbiB0aGUgdmFsaWQtcGFyZW50
LCB2YWxpZC1jaGlsZA0KICAgICAgICAgICAgIGFuZCBjYXJkaW5hbGl0eSBzdGF0ZW1lbnRzLg0K
ICAgICAgICAgICAgIA0KICAgICAgICAgICAgIE5COiBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRo
ZSB2YWxpZC1wYXJlbnQgc3RhdGVtZW50IHNob3VsZA0KICAgICAgICAgICAgIGJlIHVzZWQgaW4g
cHJlZmVyZW5jZSB0byB2YWxpZC1jaGlsZCBpbiBjYXNlcyB3aGVyZSB0aGV5DQogICAgICAgICAg
ICAgd291bGQgb3RoZXJ3aXNlIGJlIGVxdWl2YWxlbnQuIjsNCg0KICAgICAgICBleHQ6c3RyaWN0
LWdyYW1tYXIgew0KICAgICAgICAgICAgZXh0OnZhbGlkLXBhcmVudCAiZXh0ZW5zaW9uIjsNCiAg
ICAgICAgfQ0KICAgIH0NCg0KICAgIGV4dGVuc2lvbiB2YWxpZC1wYXJlbnQgew0KICAgICAgICBk
ZXNjcmlwdGlvbg0KICAgICAgICAgICAgIlVzZWQgd2l0aGluIGFuIGV4dGVuc2lvbiB0byBpbmRp
Y2F0ZSB0aGUga2V5d29yZHMgKGluIHRoZSBiYXNlDQogICAgICAgICAgICAgWWFuZyBncmFtbWFy
IG9yIGV4dGVuc2lvbiBrZXl3b3Jkcykgd2hpY2ggZGVmaW5lIGEgc3ViYmxvY2sNCiAgICAgICAg
ICAgICB3aXRoaW4gd2hpY2ggdGhlIHBhcmVudCBleHRlbnNpb24gY2FuIGJlIHVzZWQuDQogICAg
ICAgICAgICAgDQogICAgICAgICAgICAgTkI6IFRoaXMgaXMgYWRkaXRpdmUgdG8gb3RoZXIgdmFs
aWQtcGFyZW50IGFuZCB2YWxpZC1jaGlsZA0KICAgICAgICAgICAgIHN0YXRlbWVudHMsIGFuZCB0
byB0aGUgYmFzZSBZYW5nIGdyYW1tYXIuIjsNCg0KICAgICAgICBhcmd1bWVudCBrZXl3b3JkLWxp
c3Qgew0KICAgICAgICAgICAgZXh0OmRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgIlNwYWNl
LXNlcGFyYXRlZCBsaXN0IG9mIGtleXdvcmRzLg0KICAgICAgICAgICAgICAgICANCiAgICAgICAg
ICAgICAgICAgTWF5IGJlIGEgY29tYmluYXRpb24gb2YgYmFzZSBZYW5nIGtleXdvcmRzIGFuZCBr
ZXl3b3Jkcw0KICAgICAgICAgICAgICAgICBkZWZpbmVkIGJ5IGV4dGVuc2lvbnMgKGluY2x1ZGlu
ZyBwcmVmaXgpLiI7DQoNCiAgICAgICAgICAgIGV4dDpwYXR0ZXJuICIoWy1fYS16QS1aMC05XSs6
KT9bLV9hLXpBLVowLTldKyggKFstX2EtekEtWjAtOV0rOik/Wy1fYS16QS1aMC05XSspKiI7DQog
ICAgICAgICAgICBleHQ6ZGVmYXVsdCAiIjsNCiAgICAgICAgfQ0KICAgICAgICBleHQ6c3RyaWN0
LWdyYW1tYXIgew0KICAgICAgICAgICAgZXh0OnZhbGlkLXBhcmVudCAiZXh0OnN0cmljdC1ncmFt
bWFyIjsNCiAgICAgICAgfQ0KICAgIH0NCg0KICAgIGV4dGVuc2lvbiB2YWxpZC1jaGlsZCB7DQog
ICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiVXNlZCB3aXRoaW4gYW4gZXh0ZW5zaW9u
IHRvIGluZGljYXRlIHRoZSB2YWxpZCBjaGlsZA0KICAgICAgICAgICAgIGtleXdvcmRzIHRoYXQg
Y2FuIGJlIHNwZWNpZmllZCBpbiBhIHN1YmJsb2NrIHVuZGVyIHRoZQ0KICAgICAgICAgICAgIGV4
dGVuc2lvbiBzdGF0ZW1lbnQuCg0KICAgICAgICAgICAgIE5COiBUaGlzIGlzIGFkZGl0aXZlIHRv
IG90aGVyIHZhbGlkLXBhcmVudCBhbmQgdmFsaWQtY2hpbGQNCiAgICAgICAgICAgICBzdGF0ZW1l
bnRzLCBhbmQgdG8gdGhlIGJhc2UgWWFuZyBncmFtbWFyLiI7DQoNCiAgICAgICAgYXJndW1lbnQg
a2V5d29yZC1saXN0IHsNCiAgICAgICAgICAgIGV4dDpkZXNjcmlwdGlvbg0KICAgICAgICAgICAg
ICAgICJTcGFjZS1zZXBhcmF0ZWQgbGlzdCBvZiBrZXl3b3Jkcy4NCiAgICAgICAgICAgICAgICAg
DQogICAgICAgICAgICAgICAgIE1heSBiZSBhIGNvbWJpbmF0aW9uIG9mIGJhc2UgWWFuZyBrZXl3
b3JkcyBhbmQga2V5d29yZHMNCiAgICAgICAgICAgICAgICAgZGVmaW5lZCBieSBleHRlbnNpb25z
IChpbmNsdWRpbmcgcHJlZml4KS4iOw0KDQogICAgICAgICAgICBleHQ6cGF0dGVybiAiKFstX2Et
ekEtWjAtOV0rOik/Wy1fYS16QS1aMC05XSsoIChbLV9hLXpBLVowLTldKzopP1stX2EtekEtWjAt
OV0rKSoiOw0KICAgICAgICAgICAgZXh0OmRlZmF1bHQgIiI7DQogICAgICAgIH0NCiAgICAgICAg
ZXh0OnN0cmljdC1ncmFtbWFyIHsNCiAgICAgICAgICAgIGV4dDp2YWxpZC1wYXJlbnQgImV4dDpz
dHJpY3QtZ3JhbW1hciI7DQogICAgICAgIH0NCiAgICB9DQoNCiAgICBleHRlbnNpb24gY2FyZGlu
YWxpdHkgew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgIlVzZWQgdG8gaW5kaWNh
dGUgaG93IG1hbnkgdGltZXMgYSBzdGF0ZW1lbnQgY2FuIGJlIHVzZWQNCiAgICAgICAgICAgICB3
aXRoaW4gdGhlIHNhbWUgc3ViYmxvY2siOw0KDQogICAgICAgIGFyZ3VtZW50ICJjYXJkaW5hbGl0
eS10eXBlIiB7DQogICAgICAgICAgICBleHQ6cGF0dGVybiAiMC0xfDF8bXVsdGlwbGUiOw0KICAg
ICAgICB9DQogICAgICAgIGV4dDpzdHJpY3QtZ3JhbW1hciB7DQogICAgICAgICAgICBleHQ6dmFs
aWQtcGFyZW50ICJleHQ6c3RyaWN0LWdyYW1tYXIiOw0KICAgICAgICB9DQogICAgfQ0KfQ==

--_005_013A9B371AC6DF4C8AD261897D8F243E10AAD3D7xmbalnx08ciscoc_--


From nobody Tue May  6 14:58:53 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2D11A0469 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 14:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxmpVEdjoigf for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 14:58:49 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 879C61A0357 for <netmod@ietf.org>; Tue,  6 May 2014 14:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16368; q=dns/txt; s=iport; t=1399413526; x=1400623126; h=from:to:subject:date:message-id:mime-version; bh=AGJtlN8Ant/10mHwlS9v5Q5khPQncfbnesJOrPMZcXE=; b=XEZbYVCjipYBL2ltIH1naKLC3JzWDbsApqhD6L/6O2qktmtearTWmakt fs2kg2Za0gLt0sF5st2xLJawfAwvE+mQtl88ICAqxfr00CX0iCjRz5Q+f DVtOCnL26wNRxFtc9quxLGohkL9T4k87YlxzpeZAPli9jlS1h+sYEGFn7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALpaaVOtJV2c/2dsb2JhbABagkJET1jEZ4EgFnSCJwEELV4BKlYmAQQbE4gmmXW0RBeOIYNigRUErDKDNIIv
X-IronPort-AV: E=Sophos;i="4.97,998,1389744000";  d="scan'208,217";a="322923447"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 06 May 2014 21:58:45 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s46LwjtZ015008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Tue, 6 May 2014 21:58:45 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 6 May 2014 16:58:45 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Yang 1.1 support for long-running commands
Thread-Index: Ac9pdk5URJKkkV5oTRGY7VzMjPCT8g==
Date: Tue, 6 May 2014 21:58:45 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AAD433@xmb-aln-x08.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.138]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pAIRejJdLnM5pEWWfMw5DuEhj8c
Subject: [netmod] Yang 1.1 support for long-running commands
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 21:58:52 -0000

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Issue:



Currently, we cannot find a "clean" way to mode a long-running command (e.g=
. "ping", "traceroute") in Yang. This class of command requires the followi=
ng:

-    A request to be made to trigger the command starting (e.g. an RPC).

-    Notifications to be returned (for a period) as partial results become =
available.

-    A request to be made to cancel the operation if required.

-    An indication that the operation has completed and no further results =
are pending.



So in Yang 1.0 this could be modelled as follows:



rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  output {

    leaf operation-id {

      type uint64;

      description "Correlates the request to 'ping-cancel' and 'ping-result=
s'"

  }

}

rpc ping-cancel {

  input {

    leaf operation-id {

      type uint64;

      description "The ID for the operation to cancel, as returned by the p=
ing request";

    }

  }

}

notification ping-results {

  leaf operation-id {

    type uint64;

    mandatory true;

    description "The ID for the request for which results are being returne=
d";

  leaf result {

    type enumeration {

      enum success;

      enum timeout;

      enum unreachable;

    }

  }

  leaf operation-completed {

    type empty;

    description "Indicates that no further results are to be returned";

  }

}



However, it would be preferable to have an abbreviated form for this usage =
pattern, which would also allow for it to be implemented differently depend=
ing on the protocol.



Solution:



This could be done various ways, but one suggestion would be to define a "p=
artial-output" RPC result, such that whenever it is used, the type of opera=
tion is as above.



rpc ping {

  input {

    leaf dest     { type yang:ip-address; mandatory true; }

    leaf timeout  { type uint32; units "ms"; default 1000; }

    leaf interval { type uint32; units "ms"; default 0; }

    leaf count    { type uint32; description "Default: infinite"; }

  }

  partial-output {

    leaf result {

      mandatory true;

      type enumeration {

        enum success;

        enum failed;

        enum unreachable;

      }

    }

  }

}



Depending on the protocol, this could be implicitly expanded to the above Y=
ang 1.0 form (with the "cancel", operation-id and "operation-completed" bei=
ng implicit based on a standard pattern), so all the extraneous parts that =
are common to this pattern are abstracted from the user.



[Note: If an "output" is also specified, that would be expected to be retur=
ned immediately in response to the input, in line with the existing RPC sem=
antics.]



Alternative solution:



It would be possible to implement this as an extension, though that would r=
equire a fifth type of operation to be defined as part of the extension.



--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:"Courier New";
	mso-fareast-language:EN-US;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:601574422;
	mso-list-type:hybrid;
	mso-list-template-ids:-954696894 -1572708188 134807555 134807557 134807553=
 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:23.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Calibri;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:59.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:95.25pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:131.25pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:167.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:203.25pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:239.25pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:275.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:311.25pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText"><b>Issue:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Currently, we cannot find a &quot;clean&quot; way=
 to mode a long-running command (e.g. &quot;ping&quot;, &quot;traceroute&qu=
ot;) in Yang. This class of command requires the following:<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>A request to be made to trigger the command startin=
g (e.g. an RPC).<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Notifications to be returned (for a period) as part=
ial results become available.<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>A request to be made to cancel the operation if req=
uired.<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>An indication that the operation has completed and =
no further results are pending.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">So in Yang 1.0 this could be modelled as follows:=
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">rpc ping {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; input {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf dest &nbsp;&nbsp;&nbsp;&n=
bsp;{ type yang:ip-address; mandatory true; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf timeout&nbsp; { type uint=
32; units &quot;ms&quot;; default 1000; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf interval { type uint32; u=
nits &quot;ms&quot;; default 0; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf count &nbsp;&nbsp;&nbsp;{=
 type uint32; description &quot;Default: infinite&quot;; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; output {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf operation-id {<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type uint64;<o:p><=
/o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; description &quot;=
Correlates the request to 'ping-cancel' and 'ping-results'&quot;<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText">rpc ping-cancel {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; input {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf operation-id {<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type uint64;<o:p><=
/o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; description &quot;=
The ID for the operation to cancel, as returned by the ping request&quot;;<=
o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText">notification ping-results {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf operation-id {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; type uint64;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; mandatory true;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; description &quot;The ID for t=
he request for which results are being returned&quot;;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf result {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; type enumeration {<o:p></o:p><=
/p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum success;<o:p>=
</o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum timeout;<o:p>=
</o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;enum unreachable;<=
o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf operation-completed {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; type empty;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; description &quot;Indicates th=
at no further results are to be returned&quot;;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">However, it would be preferable to have an abbrev=
iated form for this usage pattern, which would also allow for it to be impl=
emented differently depending on the protocol.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Solution:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This could be done various ways, but one suggesti=
on would be to define a &quot;partial-output&quot; RPC result, such that wh=
enever it is used, the type of operation is as above.
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">rpc ping {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; input {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf dest &nbsp;&nbsp;&nbsp;&n=
bsp;{ type yang:ip-address; mandatory true; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf timeout&nbsp; { type uint=
32; units &quot;ms&quot;; default 1000; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf interval { type uint32; u=
nits &quot;ms&quot;; default 0; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf count &nbsp;&nbsp;&nbsp;{=
 type uint32; description &quot;Default: infinite&quot;; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; partial-output {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;leaf result {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mandatory true;<o:=
p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;type enumeration {=
<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;enum s=
uccess;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;enum f=
ailed;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;enum u=
nreachable;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;}<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;}<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Depending on the protocol, this could be implicit=
ly expanded to the above Yang 1.0 form (with the &quot;cancel&quot;, operat=
ion-id and &quot;operation-completed&quot; being implicit based on a standa=
rd pattern), so all the extraneous parts that are common
 to this pattern are abstracted from the user.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">[Note: If an &quot;output&quot; is also specified=
, that would be expected to be returned immediately in response to the inpu=
t, in line with the existing RPC semantics.]<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Alternative solution:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">It would be possible to implement this as an exte=
nsion, though that would require a fifth type of operation to be defined as=
 part of the extension.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAD433xmbalnx08ciscoc_--


From nobody Tue May  6 23:26:28 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679541A024E for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 23:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpFnU25hwfn9 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 23:26:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 923781A03B3 for <netmod@ietf.org>; Tue,  6 May 2014 23:26:26 -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 F02A0477C7F; Wed,  7 May 2014 08:25:56 +0200 (CEST)
Date: Wed, 07 May 2014 08:25:56 +0200 (CEST)
Message-Id: <20140507.082556.1123898727747279235.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/icSX3ogVlt6MDI9qg58RdCmJogA
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 06:26:27 -0000

Hi,

Added as Y49.


/martin


From nobody Tue May  6 23:30:00 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7361A03B3 for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 23:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4w9VGgLc16s for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 23:29:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC61A024E for <netmod@ietf.org>; Tue,  6 May 2014 23:29:58 -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 DBEB9477C7F; Wed,  7 May 2014 08:29:53 +0200 (CEST)
Date: Wed, 07 May 2014 08:29:53 +0200 (CEST)
Message-Id: <20140507.082953.816547373694750532.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/w7K6EfNyGXsChvZrmMDXQKD1ThI
Cc: netmod@ietf.org
Subject: [netmod] Y49: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 06:29:59 -0000

Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> The question about submodules reminded me of our previous debate
> on how nested submodules are treated.  I just did a test with
> pyang and yangdump-pro.  They do not produce the same results.

[...]

> Solution:  Need to reach WG consensus on proper behavior and update
> the appropriate text in YANG 1.1.

I agree that this needs to be clarified.

This might not come as a surprise to you, but I prefer solution
Y49-02; make "unexported" submodules illegal.

IMO allowing "unexported" submodules would be really confusing.  Would
they solve any problem?


/martin


From nobody Tue May  6 23:48:57 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B671A04CD for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 23:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBxZhAy9gchg for <netmod@ietfa.amsl.com>; Tue,  6 May 2014 23:48:54 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2283F1A024E for <netmod@ietf.org>; Tue,  6 May 2014 23:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7436; q=dns/txt; s=iport; t=1399445330; x=1400654930; h=from:to:subject:date:message-id:mime-version; bh=MnWAiaiV2J53yv7oY7V+q1b7NydD/wLj+o9DwOU5Z6E=; b=CRIi8J8sQ6gEtfUNnZX7nyDnmspgZ2KL2pmoB2cH6ExHH2azi3Jzw5hZ X90SeaAX2goWPflJhPVYAFnaqrlEnvb4/caFan9TLg4ktvzP0S9PYzIax Z6jLQVtBVoKx/JXesOh6xb8MtwEY5gUDCyVYIvmeXD9zVfBnMIBRmEImq A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALzWaVOtJA2H/2dsb2JhbABagkJET1jFF4EhFnSCJwEELV4BKlYmAQQbE4gmmiq0RheOIYNigRUErDKDNIIv
X-IronPort-AV: E=Sophos;i="4.97,1001,1389744000";  d="scan'208,217";a="322945740"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 07 May 2014 06:48:50 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s476mnST030299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Wed, 7 May 2014 06:48:49 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 7 May 2014 01:48:49 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: YANG 1.1 Default for Mandatory Statement
Thread-Index: Ac9pv9sfKcqtLG29Qf2+QZQGFDQn7g==
Date: Wed, 7 May 2014 06:48:48 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.209.38]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AAE090xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eoobsB6NBBecMfWU4ngu48B92TY
Subject: [netmod] YANG 1.1 Default for Mandatory Statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 06:48:55 -0000

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAE090xmbalnx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Issue:



There can be containers which contain a set of fields which are all mandato=
ry, and currently each leaf needs to be individually tagged as mandatory. F=
or readability, it would be good to be able to indicate that everything wit=
hin a subtree is mandatory.



This can be useful in two scenarios: Firstly when multiple leaves make up a=
 single logical "block" of data (as close as it gets to a complex type); an=
d secondly when a container (in particular in operational data) has a large=
 number of leaves, all of which are mandatory.



Example:



grouping lacp-system-id-group {

  container lacp-system-id {

    presence;

    leaf id  { type uint16; mandatory true; }

    leaf mac { type yang:mac-address; mandatory true; }

  }

}



Solution:



Enable the "mandatory" keyword under lists, containers, and case statements=
. In this usage, the keyword would apply to all contained leaves.

(This is effectively a parallel of how the "config" statement works as desc=
ribed in RFC 6020.)



container lacp-system-id {

  presence;

  mandatory true;

  leaf id  { type uint16; }

  leaf mac { type yang:mac-address; }

}



Alternative solution:



Add a new "default-mandatory" keyword  that's supported under lists, contai=
ners and case-statements, with values "true" and "false", which sets the de=
fault state of the mandatory keyword for elements contained. (This avoids o=
verloading the keyword, but



container lacp-system-id {

  presence;

  default-mandatory true;

  leaf id  { type uint16; }

  leaf mac { type yang:mac-address; }

}



--_000_013A9B371AC6DF4C8AD261897D8F243E10AAE090xmbalnx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:"Courier New";
	mso-fareast-language:EN-US;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText"><b>Issue:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">There can be containers which contain a set of fi=
elds which are all mandatory, and currently each leaf needs to be individua=
lly tagged as mandatory. For readability, it would be good to be able to in=
dicate that everything within a subtree
 is mandatory.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This can be useful in two scenarios: Firstly when=
 multiple leaves make up a single logical &quot;block&quot; of data (as clo=
se as it gets to a complex type); and secondly when a container (in particu=
lar in operational data) has a large number
 of leaves, all of which are mandatory.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Example:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">grouping lacp-system-id-group {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; container lacp-system-id {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; presence;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf id&nbsp; { type uint16; m=
andatory true; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;leaf mac { type yang:mac-addre=
ss; mandatory true; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Solution:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Enable the &quot;mandatory&quot; keyword under li=
sts, containers, and case statements. In this usage, the keyword would appl=
y to all contained leaves.<o:p></o:p></p>
<p class=3D"MsoPlainText">(This is effectively a parallel of how the &quot;=
config&quot; statement works as described in RFC 6020.)<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">container lacp-system-id {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; presence;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; mandatory true;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf id&nbsp; { type uint16; }<o:p></o:p><=
/p>
<p class=3D"MsoPlainText">&nbsp; leaf mac { type yang:mac-address; }<o:p></=
o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Alternative solution:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Add a new &quot;default-mandatory&quot; keyword&n=
bsp; that's supported under lists, containers and case-statements, with val=
ues &quot;true&quot; and &quot;false&quot;, which sets the default state of=
 the mandatory keyword for elements contained. (This avoids overloading
 the keyword, but <o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">container lacp-system-id {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; presence;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; default-mandatory true;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf id&nbsp; { type uint16; }<o:p></o:p><=
/p>
<p class=3D"MsoPlainText">&nbsp; leaf mac { type yang:mac-address; }<o:p></=
o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAE090xmbalnx08ciscoc_--


From nobody Wed May  7 00:27:10 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982CE1A0676 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku3dfAQUF43d for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:27:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 820C21A065D for <netmod@ietf.org>; Wed,  7 May 2014 00:27:06 -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 73608477C68; Wed,  7 May 2014 09:27:01 +0200 (CEST)
Date: Wed, 07 May 2014 09:27:01 +0200 (CEST)
Message-Id: <20140507.092701.2209126758174311088.mbj@tail-f.com>
To: powladi@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AAD3D7@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAD3D7@xmb-aln-x08.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nRNYABU9KNZgurbz9E1NLmuyRbw
Cc: netmod@ietf.org
Subject: Re: [netmod] Yang 1.1 Extension Validation?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 07:27:08 -0000

Hi,

Added as Y50.


/martin


"Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com> =
wrote:
> Hi folks,
> =

> =

> =

> I've been discussing Yang ideas and pain points with a few teams who =
have been applying the language in multiple scenarios over the last few=
 years, and based on our usage experiences, we've come up with a few id=
eas/questions which we think are valuable and I haven=B9t seen other pe=
ople bring up on the alias or in Yang 1.1 discussions.
> =

> =

> =

> So I'll post a few threads, and would welcome your thoughts :-) The f=
irst is relating to how extensions are specified.
> =

> =

> =

> Issue:
> =

> =

> =

> Yang has a clean/simple grammar that allows for a simple domain-speci=
fic description. In particular, (almost) all of the ABNF boils down to:=

> =

>   fixed-keyword variable-argument?;
> =

>   fixed-keyword variable-argument? { fixed-child-keyword variable-arg=
ument? ...}
> =

> where the set of valid keywords to use as "fixed-child-keyword" depen=
d on what "fixed-keyword" is.
> =

> =

> =

> This can be used when defining extensions, allowing a strict grammar =
to be specified in the extension description. This has the following be=
nefits:
> =

> - It helps ensure that the usage of extensions is defined clearly and=
 comprehensively.
> =

> - It encourages Yang extensions to follow the grammar patterns of the=
 base language.
> =

> - It allows automated validation of extended grammar.
> =

> =

> =

> Note that AFAICS basically all of the base Yang grammar can also be d=
efined in this way. (FWIW the set of rules is derived from Pyang's gram=
mar checking.)
> =

> =

> =

> Solution:
> =

> =

> =

> "extension-validation.yang", attached, describes the extra grammar ne=
eded to perform this validation.
> =

> =

> =

> It's described there in the form of a Yang extension, but IMO it woul=
d be better as a part of the base Yang syntax to use as a recommended w=
ay of defining extensions in Yang 1.1. (And doing so would allow for ex=
ample the use of "description" and "pattern" keywords within the "argum=
ent" subblock.)
> =

> =

> =

> The "extension-validation-self-validating.yang" module (also attached=
) illustrates the usage of these extensions (-; by applying them to the=
 module itself ;-).
> =

> =

> =

> Alternative solution:
> =

> =

> =

> This could be implemented as an extension rather than as part of the =
base grammar, as per the attached example (though this has disadvantage=
s as noted above).
> =

> =

> =

> =

> =

> Cheers,
> =

> Peyman
> =

> =

> =

> =


From nobody Wed May  7 00:27:26 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91751A065D for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKj6MkjftehG for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:27:17 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBA51A0676 for <netmod@ietf.org>; Wed,  7 May 2014 00:27:17 -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 C00833F4013; Wed,  7 May 2014 09:27:12 +0200 (CEST)
Date: Wed, 07 May 2014 09:27:12 +0200 (CEST)
Message-Id: <20140507.092712.828514137814478867.mbj@tail-f.com>
To: powladi@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AAD433@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAD433@xmb-aln-x08.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lJIJ92XMp9BicuaF7q3pC2IQ05M
Cc: netmod@ietf.org
Subject: Re: [netmod] Yang 1.1 support for long-running commands
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 07:27:21 -0000

Hi,

Added as Y51.


/martin


"Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com> wrote:
> Issue:
> 
> 
> 
> Currently, we cannot find a "clean" way to mode a long-running command (e.g. "ping", "traceroute") in Yang. This class of command requires the following:
> 
> -    A request to be made to trigger the command starting (e.g. an RPC).
> 
> -    Notifications to be returned (for a period) as partial results become available.
> 
> -    A request to be made to cancel the operation if required.
> 
> -    An indication that the operation has completed and no further results are pending.
> 
> 
> 
> So in Yang 1.0 this could be modelled as follows:
> 
> 
> 
> rpc ping {
> 
>   input {
> 
>     leaf dest     { type yang:ip-address; mandatory true; }
> 
>     leaf timeout  { type uint32; units "ms"; default 1000; }
> 
>     leaf interval { type uint32; units "ms"; default 0; }
> 
>     leaf count    { type uint32; description "Default: infinite"; }
> 
>   }
> 
>   output {
> 
>     leaf operation-id {
> 
>       type uint64;
> 
>       description "Correlates the request to 'ping-cancel' and 'ping-results'"
> 
>   }
> 
> }
> 
> rpc ping-cancel {
> 
>   input {
> 
>     leaf operation-id {
> 
>       type uint64;
> 
>       description "The ID for the operation to cancel, as returned by the ping request";
> 
>     }
> 
>   }
> 
> }
> 
> notification ping-results {
> 
>   leaf operation-id {
> 
>     type uint64;
> 
>     mandatory true;
> 
>     description "The ID for the request for which results are being returned";
> 
>   leaf result {
> 
>     type enumeration {
> 
>       enum success;
> 
>       enum timeout;
> 
>       enum unreachable;
> 
>     }
> 
>   }
> 
>   leaf operation-completed {
> 
>     type empty;
> 
>     description "Indicates that no further results are to be returned";
> 
>   }
> 
> }
> 
> 
> 
> However, it would be preferable to have an abbreviated form for this usage pattern, which would also allow for it to be implemented differently depending on the protocol.
> 
> 
> 
> Solution:
> 
> 
> 
> This could be done various ways, but one suggestion would be to define a "partial-output" RPC result, such that whenever it is used, the type of operation is as above.
> 
> 
> 
> rpc ping {
> 
>   input {
> 
>     leaf dest     { type yang:ip-address; mandatory true; }
> 
>     leaf timeout  { type uint32; units "ms"; default 1000; }
> 
>     leaf interval { type uint32; units "ms"; default 0; }
> 
>     leaf count    { type uint32; description "Default: infinite"; }
> 
>   }
> 
>   partial-output {
> 
>     leaf result {
> 
>       mandatory true;
> 
>       type enumeration {
> 
>         enum success;
> 
>         enum failed;
> 
>         enum unreachable;
> 
>       }
> 
>     }
> 
>   }
> 
> }
> 
> 
> 
> Depending on the protocol, this could be implicitly expanded to the above Yang 1.0 form (with the "cancel", operation-id and "operation-completed" being implicit based on a standard pattern), so all the extraneous parts that are common to this pattern are abstracted from the user.
> 
> 
> 
> [Note: If an "output" is also specified, that would be expected to be returned immediately in response to the input, in line with the existing RPC semantics.]
> 
> 
> 
> Alternative solution:
> 
> 
> 
> It would be possible to implement this as an extension, though that would require a fifth type of operation to be defined as part of the extension.
> 
> 


From nobody Wed May  7 00:27:39 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5061A067D for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeLR1KuDwuqM for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:27:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF441A065D for <netmod@ietf.org>; Wed,  7 May 2014 00:27:36 -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 09C4D3F4012; Wed,  7 May 2014 09:27:32 +0200 (CEST)
Date: Wed, 07 May 2014 09:27:31 +0200 (CEST)
Message-Id: <20140507.092731.422274944402181413.mbj@tail-f.com>
To: powladi@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7YZ7-RMlarcro5wz-0m69e0S9mA
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 Default for Mandatory Statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 07:27:37 -0000

Hi,

Added as Y52.


/martin



"Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com> wrote:
> Issue:
> 
> 
> 
> There can be containers which contain a set of fields which are all mandatory, and currently each leaf needs to be individually tagged as mandatory. For readability, it would be good to be able to indicate that everything within a subtree is mandatory.
> 
> 
> 
> This can be useful in two scenarios: Firstly when multiple leaves make up a single logical "block" of data (as close as it gets to a complex type); and secondly when a container (in particular in operational data) has a large number of leaves, all of which are mandatory.
> 
> 
> 
> Example:
> 
> 
> 
> grouping lacp-system-id-group {
> 
>   container lacp-system-id {
> 
>     presence;
> 
>     leaf id  { type uint16; mandatory true; }
> 
>     leaf mac { type yang:mac-address; mandatory true; }
> 
>   }
> 
> }
> 
> 
> 
> Solution:
> 
> 
> 
> Enable the "mandatory" keyword under lists, containers, and case statements. In this usage, the keyword would apply to all contained leaves.
> 
> (This is effectively a parallel of how the "config" statement works as described in RFC 6020.)
> 
> 
> 
> container lacp-system-id {
> 
>   presence;
> 
>   mandatory true;
> 
>   leaf id  { type uint16; }
> 
>   leaf mac { type yang:mac-address; }
> 
> }
> 
> 
> 
> Alternative solution:
> 
> 
> 
> Add a new "default-mandatory" keyword  that's supported under lists, containers and case-statements, with values "true" and "false", which sets the default state of the mandatory keyword for elements contained. (This avoids overloading the keyword, but
> 
> 
> 
> container lacp-system-id {
> 
>   presence;
> 
>   default-mandatory true;
> 
>   leaf id  { type uint16; }
> 
>   leaf mac { type yang:mac-address; }
> 
> }
> 
> 


From nobody Wed May  7 00:40:51 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B02C1A067F for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQOO_gm2T4-Y for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 00:40:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D490C1A067D for <netmod@ietf.org>; Wed,  7 May 2014 00:40:44 -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 ABCB33F4012; Wed,  7 May 2014 09:40:39 +0200 (CEST)
Date: Wed, 07 May 2014 09:40:39 +0200 (CEST)
Message-Id: <20140507.094039.1355620338232070983.mbj@tail-f.com>
To: powladi@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/srFdxJFM0KNBTYCz-qhrMO_qje8
Cc: netmod@ietf.org
Subject: [netmod] Y52: Default for Mandatory Statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 07:40:46 -0000

Hi,

> There can be containers which contain a set of fields which are all
> mandatory, and currently each leaf needs to be individually tagged
> as mandatory. For readability, it would be good to be able to
> indicate that everything within a subtree is mandatory.

Readability is always subjective.  Personally, I think it is more
clear to have the explicit mandatory statement in each subnode.

Also, I think is confusing to let the 'mandatory' statement be applied
recursively in some cases (these new cases), but not in others
(existing mandatory in choice).



/martin


From nobody Wed May  7 01:06:57 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76BD1A0668 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 01:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.95
X-Spam-Level: 
X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id magHtDE1htRL for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 01:06:51 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id CF7811A0186 for <netmod@ietf.org>; Wed,  7 May 2014 01:06:50 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 0BED4193AE0F for <netmod@ietf.org>; Wed,  7 May 2014 16:06:31 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 1F085733155 for <netmod@ietf.org>; Wed,  7 May 2014 16:06:30 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4786WWs048822 for <netmod@ietf.org>; Wed, 7 May 2014 16:06:32 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
To: netmod@ietf.org
MIME-Version: 1.0
X-KeepSent: 46394C7C:CE4D2C7A-48257CCE:00255C97; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF46394C7C.CE4D2C7A-ON48257CCE.00255C97-48257CD1.002C8C33@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Wed, 7 May 2014 16:06:33 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-07 16:06:35, Serialize complete at 2014-05-07 16:06:35
Content-Type: multipart/alternative; boundary="=_alternative 002C8C3148257CD1_="
X-MAIL: mse02.zte.com.cn s4786WWs048822
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Hjipxja6NArl6Vf8KVQVnmpjdlM
Subject: [netmod] YANG1.1 issue: remove the advertisement of conformance information in NETCONF hello message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 08:06:55 -0000

This is a multipart message in MIME format.

--=_alternative 002C8C3148257CD1_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,

     In section 5.6.4, RFC6020, advertisement of YANG module conformance 
information MUST be implemented in hello message by NETCONF server.
I think it's out of scope of YANG. YANG only can define what the 
conformance is, but can not define how these conformance are advertised, 
it's 
operation protocol(e.g NETCONF)'s job.
     In fact, advertisement of data modules conformance information in 
hello message have caused a lot of trouble to NETCONF.
1. too big hello message.
2. how to advertise NOT YANG schema's conformance.
3. Data model information is a capability of operation protocol? I think 
it's not.
4. it's conflict with NETCONF's capabilities exchange.
   For example,NETCONF has own YANG module,it defined netconf's 
capablities as features. So, it will be advertised in hello message.
   But these capabilities have been in hello message.
   For example:
   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:netconf:base:1.1
       </capability>
       <capability>
         urn:ietf:params:netconf:capability:writable-running:1.0
       </capability>
       <capability>
         urn:ietf:params:netconf:capability:candidate:1.0
       </capability>
       <capability>
 
urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&features=writable-running,candidate
       </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>
/frank

Solution:
        remove the advertisement of YANG conformance in NETCONF hello 
message. NETCONF can decide how advertise these information by self.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 002C8C3148257CD1_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;In section 5.6.4,
RFC6020, advertisement of YANG module conformance information MUST be implemented
in hello message by NETCONF server.</font>
<br><font size=2 face="sans-serif">I think it's out of scope of YANG. YANG
only can define what the conformance is, but can not define how these conformance
are advertised, it's </font>
<br><font size=2 face="sans-serif">operation protocol(e.g NETCONF)'s job.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;In fact, advertisement
of data modules conformance information in hello message have caused a
lot of trouble to NETCONF.</font>
<br><font size=2 face="sans-serif">1. too big hello message.</font>
<br><font size=2 face="sans-serif">2. how to advertise NOT YANG schema's
conformance.</font>
<br><font size=2 face="sans-serif">3. Data model information is a capability
of operation protocol? I think it's not.</font>
<br><font size=2 face="sans-serif">4. it's conflict with NETCONF's capabilities
exchange.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;For example,NETCONF has
own YANG module,it defined netconf's capablities as features. So, it will
be advertised in hello message.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;But these capabilities
have been in hello message.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;For example:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;&lt;hello xmlns=&quot;urn:ietf:params:xml:ns:netconf:base:1.0&quot;&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;&lt;capabilities&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;urn:ietf:params:netconf:base:1.1</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;/capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;urn:ietf:params:netconf:capability:writable-running:1.0</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;/capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;urn:ietf:params:netconf:capability:candidate:1.0</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;/capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&amp;features=writable-running,candidate</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp;&lt;/capability&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;&lt;/capabilities&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp;&lt;session-id&gt;4&lt;/session-id&gt;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;&lt;/hello&gt;</font>
<br><font size=2 face="sans-serif">/frank</font>
<br>
<br><font size=2 face="sans-serif">Solution:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; remove the
advertisement of YANG conformance in NETCONF hello message. NETCONF can
decide how advertise these information by self.</font>

<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre><br>

<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre><br>

--=_alternative 002C8C3148257CD1_=--


From nobody Wed May  7 01:26:13 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2341A0278 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 01:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRRxM-HONohn for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 01:26:11 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D93B11A067D for <netmod@ietf.org>; Wed,  7 May 2014 01:26:10 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:20:a0e5:28bc:5b9d:2359] (unknown [IPv6:2001:1488:fffe:20:a0e5:28bc:5b9d:2359]) by mail.nic.cz (Postfix) with ESMTPSA id 38BF513F998; Wed,  7 May 2014 10:26:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399451166; bh=lpe7/It8bMIlEDfg0tEYIKJB3d61+REhWeRzx9MCcAY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Sz+YmtLOjncN0YKWnRwiVUeJN+48pYlW9e7j6N1n4scvREKqx1DYRqgKXyXXiKsdX H0aiXhAYb5EeOE1njCrYy5vxZt4pQcSZ9DMAYDLuLQmL4MPxp5mzmuRAlaMc36i7Ac gfIO3kCAhcDOIf988/T5d2Al0hVKx/izBcYPu3u4=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140507.094039.1355620338232070983.mbj@tail-f.com>
Date: Wed, 7 May 2014 10:26:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E83A19C6-7728-41CA-8554-0C810E5EF8FD@nic.cz>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com> <20140507.094039.1355620338232070983.mbj@tail-f.com>
To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LpWxzwhSb9iQYMdwsvy5uq6baK0
Cc: netmod@ietf.org
Subject: Re: [netmod] Y52: Default for Mandatory Statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 08:26:12 -0000

On 07 May 2014, at 09:40, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>=20
>> There can be containers which contain a set of fields which are all
>> mandatory, and currently each leaf needs to be individually tagged
>> as mandatory. For readability, it would be good to be able to
>> indicate that everything within a subtree is mandatory.
>=20
> Readability is always subjective.  Personally, I think it is more
> clear to have the explicit mandatory statement in each subnode.
>=20
> Also, I think is confusing to let the 'mandatory' statement be applied
> recursively in some cases (these new cases), but not in others
> (existing mandatory in choice).

+1

Another complication would be augments that may add new nodes to the =
subtree from outside.

Lada

>=20
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May  7 02:03:08 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8B01A026F for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COSmC15s3evt for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:03:06 -0700 (PDT)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id CCFEB1A0278 for <netmod@ietf.org>; Wed,  7 May 2014 02:03:05 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id s7so681853qap.6 for <netmod@ietf.org>; Wed, 07 May 2014 02:03:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pz6ID12yZ3FeVVhLj8uj651IjEUsNpiUIOZqGQSPtu4=; b=Szmy5mp6KBpI+SOEsXMrNW42cfobs7GGry3t59Xbl6VOHhyXk81LSR7YqVzh1mqmEI jqBBc7vw0IqGqAvIfdUQ6HiHUvw0A9cizWMAUR+3IB2mVtxAeVgxhzx3v3Ubf0B5/mUJ 7FhkAaeQAYy7O159d3Og+BOn6xEqIdWUBQMt7NlTZRpqos1Q5x85TEEKWgvwyIN39E2A 5VnDNAHGH5dFMUZMl+W5mTSzLpFmJT8tZX84x24gRdpN56gZmQ9fi3Ai75p/2/uu5z1m b7tN7o8wK5mlXRLfAl9kY2BHX6QifVsvJs9eS9GnSGNFEimq10nmgk8DAZyiLDI1V9qw iGuQ==
X-Gm-Message-State: ALoCoQn1UYhuSxH2VH3XXG4sxF/yUCnzFbUM6XcNVVJCCd66hMvGRkRkw9l/tAIRuFzcEiuaD5qM
MIME-Version: 1.0
X-Received: by 10.140.92.37 with SMTP id a34mr2595538qge.91.1399453381639; Wed, 07 May 2014 02:03:01 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 02:03:01 -0700 (PDT)
In-Reply-To: <20140507.082953.816547373694750532.mbj@tail-f.com>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <20140507.082953.816547373694750532.mbj@tail-f.com>
Date: Wed, 7 May 2014 02:03:01 -0700
Message-ID: <CABCOCHQsf+PoySWcwc5PWLaMMrgBhq-Nff6BQsJvnB5Uu9v1cg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary=001a1139baf2b156c004f8cba1f1
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iRo-beYCQe9Ql-LfrpN5HJo1DIM
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y49: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 09:03:07 -0000

--001a1139baf2b156c004f8cba1f1
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 6, 2014 at 11:29 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> Andy Bierman <andy@yumaworks.com> wrote:
> > Hi,
> >
> > The question about submodules reminded me of our previous debate
> > on how nested submodules are treated.  I just did a test with
> > pyang and yangdump-pro.  They do not produce the same results.
>
> [...]
>
> > Solution:  Need to reach WG consensus on proper behavior and update
> > the appropriate text in YANG 1.1.
>
> I agree that this needs to be clarified.
>
> This might not come as a surprise to you, but I prefer solution
> Y49-02; make "unexported" submodules illegal.
>
> IMO allowing "unexported" submodules would be really confusing.  Would
> they solve any problem?
>
>
The module may be under development and not all definitions are final yet.
There is not a single line of text in RFC 6020 that says it is an error to
have a nested submodule.  There is not 1 place in the RFC where it
an error to have an unused definition (e.g. nested unused groupings).



> /martin
>

Andy

--001a1139baf2b156c004f8cba1f1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, May 6, 2014 at 11:29 PM, Martin Bjorklund <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<br>
Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</=
a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; The question about submodules reminded me of our previous debate<br>
&gt; on how nested submodules are treated. =A0I just did a test with<br>
&gt; pyang and yangdump-pro. =A0They do not produce the same results.<br>
<br>
[...]<br>
<br>
&gt; Solution: =A0Need to reach WG consensus on proper behavior and update<=
br>
&gt; the appropriate text in YANG 1.1.<br>
<br>
I agree that this needs to be clarified.<br>
<br>
This might not come as a surprise to you, but I prefer solution<br>
Y49-02; make &quot;unexported&quot; submodules illegal.<br>
<br>
IMO allowing &quot;unexported&quot; submodules would be really confusing. =
=A0Would<br>
they solve any problem?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>The module may be under development and not all defi=
nitions are final yet.</div><div>There is not a single line of text in RFC =
6020 that says it is an error to</div>
<div>have a nested submodule. =A0There is not 1 place in the RFC where it</=
div><div>an error to have an unused definition (e.g. nested unused grouping=
s).</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888">
<br>
/martin<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Andy<=
/div><div class=3D"gmail_extra"><br></div></div>

--001a1139baf2b156c004f8cba1f1--


From nobody Wed May  7 02:12:06 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359521A0377 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:12:05 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIddETLFMg1J for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:11:58 -0700 (PDT)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by ietfa.amsl.com (Postfix) with ESMTP id 252BA1A0278 for <netmod@ietf.org>; Wed,  7 May 2014 02:11:58 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id q108so733825qgd.27 for <netmod@ietf.org>; Wed, 07 May 2014 02:11:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EQqTdDlIBNvyGSoGvr8HDhGXcPohm4T1idzIUWFi3rk=; b=P5tHBOuFQJzzK/vratKlc4BMvw3bJUZWvflTK6qNtVCmsiO8+FrSiQ8uVXrc/OvcJF 6waD4vU5wD+UVOC4HkwJKQGoITFcT3NAZbQp3Y163PVNmfLCwTrwgyjzets653N2+H0V eN/A+AEjdSmwDYAf72I7FEgqWwl2in4Ka0VxD1wwoAsHy8pv2F/RMsPblTkl0oUSLSw7 O2SOWO13i3uf8DUv2a4pDrHamA0KPg2KLciaKt8AetdNlInJ5XfY4mnFTn8T1iLmoukv SdUaOK3kGeukL5K6uhU8rDARa5BjKOEQutZlFGcDpT7z7UPFdXaSSVIAXv4pjxi4Qkvn J3rw==
X-Gm-Message-State: ALoCoQk3T34/hTD8hCZLAlHuS5MHrON33d8y21vJivDUd1NE3AjcySrFjiNXF+mB2Qfs4yGWTizM
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr32951252qgo.25.1399453913847; Wed, 07 May 2014 02:11:53 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 02:11:53 -0700 (PDT)
In-Reply-To: <OF46394C7C.CE4D2C7A-ON48257CCE.00255C97-48257CD1.002C8C33@zte.com.cn>
References: <OF46394C7C.CE4D2C7A-ON48257CCE.00255C97-48257CD1.002C8C33@zte.com.cn>
Date: Wed, 7 May 2014 02:11:53 -0700
Message-ID: <CABCOCHQkYf8wwxk6MHwVVZpwsz6_VQrzfm_wTngGP186JvBJeg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: feng.chong33@zte.com.cn
Content-Type: multipart/alternative; boundary=001a11c173346a301b04f8cbc1e4
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j99szK_rNzmoHUqmYHvZNsN3Cu8
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG1.1 issue: remove the advertisement of conformance information in NETCONF hello message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 09:12:05 -0000

--001a11c173346a301b04f8cbc1e4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, May 7, 2014 at 1:06 AM, <feng.chong33@zte.com.cn> wrote:

> Hi all,
>
>      In section 5.6.4, RFC6020, advertisement of YANG module conformance
> information MUST be implemented in hello message by NETCONF server.
> I think it's out of scope of YANG. YANG only can define what the
> conformance is, but can not define how these conformance are advertised,
> it's
> operation protocol(e.g NETCONF)'s job.
>      In fact, advertisement of data modules conformance information in
> hello message have caused a lot of trouble to NETCONF.
> 1. too big hello message.
> 2. how to advertise NOT YANG schema's conformance.
> 3. Data model information is a capability of operation protocol? I think
> it's not.
> 4. it's conflict with NETCONF's capabilities exchange.
>    For example,NETCONF has own YANG module,it defined netconf's
> capablities as features. So, it will be advertised in hello message.
>    But these capabilities have been in hello message.
>    For example:
>    <hello xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>      <capabilities>
>        <capability>
>          urn:ietf:params:netconf:base:1.1
>        </capability>
>        <capability>
>          urn:ietf:params:netconf:capability:writable-running:1.0
>        </capability>
>        <capability>
>          urn:ietf:params:netconf:capability:candidate:1.0
>        </capability>
>        <capability>
>
>  urn:ietf:params:xml:ns:netconf:base:1.0?module=3Dietf-netconf&features=
=3Dwritable-running,candidate
>        </capability>
>      </capabilities>
>      <session-id>4</session-id>
>    </hello>
> /frank
>
> Solution:
>         remove the advertisement of YANG conformance in NETCONF hello
> message. NETCONF can decide how advertise these information by self.
>
>
I do not agree this is a problem.
Standardized module advertisement is important for interoperability.
Claim (1) is relative. Even 1000 modules would be way less than a mega-byte=
.
The largest servers have about 100 - 200 modules, nowhere near 1000.
Claim (2) is irrelevant because only YANG modules are included in YANG
module advertisement.
Non-standard proprietary modules would be advertised some other way.
Claim (3) is just wrong -- NETCONF allows a <capability> to represent
anything.
Claim (4) applies only to the ietf-netconf module.  This is the only YANG
module that
is redundant.


Andy


> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (=
and any attachment transmitted herewith) is privileged and confidential and=
 is intended for the exclusive use of the addressee(s).  If you are not an =
intended recipient, any disclosure, reproduction, distribution or other dis=
semination or use of the information contained is strictly prohibited.  If =
you have received this mail in error, please delete it and notify us immedi=
ately.
>
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (=
and any attachment transmitted herewith) is privileged and confidential and=
 is intended for the exclusive use of the addressee(s).  If you are not an =
intended recipient, any disclosure, reproduction, distribution or other dis=
semination or use of the information contained is strictly prohibited.  If =
you have received this mail in error, please delete it and notify us immedi=
ately.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

--001a11c173346a301b04f8cbc1e4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 1:06 AM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:feng.chong33@zte.com.cn" target=3D"_blank">feng.chong33@zte.com.cn</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><font face=3D"sans-serif">Hi all,</font>
<br>
<br><font face=3D"sans-serif">=A0 =A0 =A0In section 5.6.4,
RFC6020, advertisement of YANG module conformance information MUST be imple=
mented
in hello message by NETCONF server.</font>
<br><font face=3D"sans-serif">I think it&#39;s out of scope of YANG. YANG
only can define what the conformance is, but can not define how these confo=
rmance
are advertised, it&#39;s </font>
<br><font face=3D"sans-serif">operation protocol(e.g NETCONF)&#39;s job.</f=
ont>
<br><font face=3D"sans-serif">=A0 =A0 =A0In fact, advertisement
of data modules conformance information in hello message have caused a
lot of trouble to NETCONF.</font>
<br><font face=3D"sans-serif">1. too big hello message.</font>
<br><font face=3D"sans-serif">2. how to advertise NOT YANG schema&#39;s
conformance.</font>
<br><font face=3D"sans-serif">3. Data model information is a capability
of operation protocol? I think it&#39;s not.</font>
<br><font face=3D"sans-serif">4. it&#39;s conflict with NETCONF&#39;s capab=
ilities
exchange.</font>
<br><font face=3D"sans-serif">=A0 =A0For example,NETCONF has
own YANG module,it defined netconf&#39;s capablities as features. So, it wi=
ll
be advertised in hello message.</font>
<br><font face=3D"sans-serif">=A0 =A0But these capabilities
have been in hello message.</font>
<br><font face=3D"sans-serif">=A0 =A0For example:</font>
<br><font face=3D"sans-serif">=A0 =A0&lt;hello xmlns=3D&quot;urn:ietf:param=
s:xml:ns:netconf:base:1.0&quot;&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0&lt;capabilities&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0 =A0urn:ietf:params:netconf:ba=
se:1.1</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;/capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0 =A0urn:ietf:params:netconf:ca=
pability:writable-running:1.0</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;/capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0 =A0urn:ietf:params:netconf:ca=
pability:candidate:1.0</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;/capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0 =A0urn:ietf:params:xml:ns:net=
conf:base:1.0?module=3Dietf-netconf&amp;features=3Dwritable-running,candida=
te</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0&lt;/capability&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0&lt;/capabilities&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0&lt;session-id&gt;4&lt;/session-id=
&gt;</font>
<br><font face=3D"sans-serif">=A0 =A0&lt;/hello&gt;</font>
<br><font face=3D"sans-serif">/frank</font>
<br>
<br><font face=3D"sans-serif">Solution:</font>
<br><font face=3D"sans-serif">=A0 =A0 =A0 =A0 remove the
advertisement of YANG conformance in NETCONF hello message. NETCONF can
decide how advertise these information by self.</font>

<br><pre><font color=3D"blue"></font></pre></blockquote><div><br></div><div=
>I do not agree this is a problem.</div><div>Standardized module advertisem=
ent is important for interoperability.</div><div>Claim (1) is relative. Eve=
n 1000 modules would be way less than a mega-byte.</div>
<div>The largest servers have about 100 - 200 modules, nowhere near 1000.</=
div><div>Claim (2) is irrelevant because only YANG modules are included in =
YANG module advertisement.</div><div>Non-standard proprietary modules would=
 be advertised some other way.</div>
<div>Claim (3) is just wrong -- NETCONF allows a &lt;capability&gt; to repr=
esent anything.</div><div>Claim (4) applies only to the ietf-netconf module=
. =A0This is the only YANG module that</div><div>is redundant.</div><div>
<br></div><div><br></div><div>Andy</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><pre><font color=3D"blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.

</font></pre><br>

<br><pre><font color=3D"blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.

</font></pre><br>
<br>_______________________________________________<br>
netmod mailing list<br>
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/netmod</a><br>
<br></blockquote></div><br></div></div>

--001a11c173346a301b04f8cbc1e4--


From nobody Wed May  7 02:17:43 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE291A0377 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5H6vl_7VB6Z for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:17:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC61A027E for <netmod@ietf.org>; Wed,  7 May 2014 02:17:40 -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 422333F4012; Wed,  7 May 2014 11:17:35 +0200 (CEST)
Date: Wed, 07 May 2014 11:17:35 +0200 (CEST)
Message-Id: <20140507.111735.2265717469215095648.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHQkYf8wwxk6MHwVVZpwsz6_VQrzfm_wTngGP186JvBJeg@mail.gmail.com>
References: <OF46394C7C.CE4D2C7A-ON48257CCE.00255C97-48257CD1.002C8C33@zte.com.cn> <CABCOCHQkYf8wwxk6MHwVVZpwsz6_VQrzfm_wTngGP186JvBJeg@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dczoWK-KJ58N5alGcvF_rRKUL8g
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG1.1 issue: remove the advertisement of conformance information in NETCONF hello message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 09:17:41 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, May 7, 2014 at 1:06 AM, <feng.chong33@zte.com.cn> wrote:
> 
> > Hi all,
> >
> >      In section 5.6.4, RFC6020, advertisement of YANG module conformance
> > information MUST be implemented in hello message by NETCONF server.
> > I think it's out of scope of YANG. YANG only can define what the
> > conformance is, but can not define how these conformance are advertised,
> > it's
> > operation protocol(e.g NETCONF)'s job.
> >      In fact, advertisement of data modules conformance information in
> > hello message have caused a lot of trouble to NETCONF.
> > 1. too big hello message.
> > 2. how to advertise NOT YANG schema's conformance.
> > 3. Data model information is a capability of operation protocol? I think
> > it's not.
> > 4. it's conflict with NETCONF's capabilities exchange.
> >    For example,NETCONF has own YANG module,it defined netconf's
> > capablities as features. So, it will be advertised in hello message.
> >    But these capabilities have been in hello message.
> >    For example:
> >    <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >      <capabilities>
> >        <capability>
> >          urn:ietf:params:netconf:base:1.1
> >        </capability>
> >        <capability>
> >          urn:ietf:params:netconf:capability:writable-running:1.0
> >        </capability>
> >        <capability>
> >          urn:ietf:params:netconf:capability:candidate:1.0
> >        </capability>
> >        <capability>
> >
> >  urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&features=writable-running,candidate
> >        </capability>
> >      </capabilities>
> >      <session-id>4</session-id>
> >    </hello>
> > /frank
> >
> > Solution:
> >         remove the advertisement of YANG conformance in NETCONF hello
> > message. NETCONF can decide how advertise these information by self.
> >
> >
> I do not agree this is a problem.

+1

> Standardized module advertisement is important for interoperability.
> Claim (1) is relative. Even 1000 modules would be way less than a mega-byte.
> The largest servers have about 100 - 200 modules, nowhere near 1000.
> Claim (2) is irrelevant because only YANG modules are included in YANG
> module advertisement.
> Non-standard proprietary modules would be advertised some other way.
> Claim (3) is just wrong -- NETCONF allows a <capability> to represent
> anything.
> Claim (4) applies only to the ietf-netconf module.  This is the only YANG
> module that
> is redundant.

+1 to all.


I would also add that the mapping from YANG to NETCONF needs to be
defined.  Currently it is defined in RFC 6020.  Maybe it should be
moved to a separate document, but even if it was, the advertisment of
the modules must be defined.


/martin


From nobody Wed May  7 02:33:18 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499841A0431 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96
X-Spam-Level: 
X-Spam-Status: No, score=-96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaSMkekH397a for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 02:33:12 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E0AEA1A03D1 for <netmod@ietf.org>; Wed,  7 May 2014 02:33:11 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id B9D25193B384 for <netmod@ietf.org>; Wed,  7 May 2014 17:32:52 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C903973489E; Wed,  7 May 2014 17:32:50 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s479WmT7086592; Wed, 7 May 2014 17:32:48 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140507.111735.2265717469215095648.mbj@tail-f.com>
References: <OF46394C7C.CE4D2C7A-ON48257CCE.00255C97-48257CD1.002C8C33@zte.com.cn>	<CABCOCHQkYf8wwxk6MHwVVZpwsz6_VQrzfm_wTngGP186JvBJeg@mail.gmail.com> <20140507.111735.2265717469215095648.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
MIME-Version: 1.0
X-KeepSent: CF70D34F:AE4097F4-48257CD1:00337875; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OFCF70D34F.AE4097F4-ON48257CD1.00337875-48257CD1.0034726E@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Wed, 7 May 2014 17:32:50 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-07 17:32:51, Serialize complete at 2014-05-07 17:32:51
Content-Type: multipart/alternative; boundary="=_alternative 0034726E48257CD1_="
X-MAIL: mse02.zte.com.cn s479WmT7086592
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m6HJW2pe0dq6iilmJPYmOvHpd6Q
Cc: netmod@ietf.org
Subject: [netmod] =?gb2312?b?tPC4tDogUmU6ICBZQU5HMS4xIGlzc3VlOiByZW1vdmUg?= =?gb2312?b?dGhlIGFkdmVydGlzZW1lbnQgb2YgY29uZm9ybWFuY2UgaW5mb3JtYXRpb24g?= =?gb2312?b?aW4gTkVUQ09ORiBoZWxsbyBtZXNzYWdl?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 09:33:14 -0000

This is a multipart message in MIME format.

--=_alternative 0034726E48257CD1_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCk1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiDQtNPaIDIwMTQtMDUt
MDcgMTc6MTc6MzU6DQoNCj4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IA0KPiAy
MDE0LTA1LTA3IDE3OjE3DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGFuZHlAeXVtYXdvcmtzLmNvbSwg
DQo+IA0KPiCzrcvNDQo+IA0KPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgbmV0bW9kQGlldGYu
b3JnDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW25ldG1vZF0gWUFORzEuMSBpc3N1ZTogcmVtb3Zl
IHRoZSBhZHZlcnRpc2VtZW50IG9mIGNvbmZvcm1hbmNlIA0KPiBpbmZvcm1hdGlvbiBpbiBORVRD
T05GIGhlbGxvIG1lc3NhZ2UNCj4gDQo+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t
PiB3cm90ZToNCj4gPiBPbiBXZWQsIE1heSA3LCAyMDE0IGF0IDE6MDYgQU0sIDxmZW5nLmNob25n
MzNAenRlLmNvbS5jbj4gd3JvdGU6DQo+ID4gDQo+ID4gPiBIaSBhbGwsDQo+ID4gPg0KPiA+ID4g
ICAgICBJbiBzZWN0aW9uIDUuNi40LCBSRkM2MDIwLCBhZHZlcnRpc2VtZW50IG9mIFlBTkcgbW9k
dWxlIA0KY29uZm9ybWFuY2UNCj4gPiA+IGluZm9ybWF0aW9uIE1VU1QgYmUgaW1wbGVtZW50ZWQg
aW4gaGVsbG8gbWVzc2FnZSBieSBORVRDT05GIHNlcnZlci4NCj4gPiA+IEkgdGhpbmsgaXQncyBv
dXQgb2Ygc2NvcGUgb2YgWUFORy4gWUFORyBvbmx5IGNhbiBkZWZpbmUgd2hhdCB0aGUNCj4gPiA+
IGNvbmZvcm1hbmNlIGlzLCBidXQgY2FuIG5vdCBkZWZpbmUgaG93IHRoZXNlIGNvbmZvcm1hbmNl
IGFyZSANCmFkdmVydGlzZWQsDQo+ID4gPiBpdCdzDQo+ID4gPiBvcGVyYXRpb24gcHJvdG9jb2wo
ZS5nIE5FVENPTkYpJ3Mgam9iLg0KPiA+ID4gICAgICBJbiBmYWN0LCBhZHZlcnRpc2VtZW50IG9m
IGRhdGEgbW9kdWxlcyBjb25mb3JtYW5jZSBpbmZvcm1hdGlvbiANCmluDQo+ID4gPiBoZWxsbyBt
ZXNzYWdlIGhhdmUgY2F1c2VkIGEgbG90IG9mIHRyb3VibGUgdG8gTkVUQ09ORi4NCj4gPiA+IDEu
IHRvbyBiaWcgaGVsbG8gbWVzc2FnZS4NCj4gPiA+IDIuIGhvdyB0byBhZHZlcnRpc2UgTk9UIFlB
Tkcgc2NoZW1hJ3MgY29uZm9ybWFuY2UuDQo+ID4gPiAzLiBEYXRhIG1vZGVsIGluZm9ybWF0aW9u
IGlzIGEgY2FwYWJpbGl0eSBvZiBvcGVyYXRpb24gcHJvdG9jb2w/IEkgDQp0aGluaw0KPiA+ID4g
aXQncyBub3QuDQo+ID4gPiA0LiBpdCdzIGNvbmZsaWN0IHdpdGggTkVUQ09ORidzIGNhcGFiaWxp
dGllcyBleGNoYW5nZS4NCj4gPiA+ICAgIEZvciBleGFtcGxlLE5FVENPTkYgaGFzIG93biBZQU5H
IG1vZHVsZSxpdCBkZWZpbmVkIG5ldGNvbmYncw0KPiA+ID4gY2FwYWJsaXRpZXMgYXMgZmVhdHVy
ZXMuIFNvLCBpdCB3aWxsIGJlIGFkdmVydGlzZWQgaW4gaGVsbG8gbWVzc2FnZS4NCj4gPiA+ICAg
IEJ1dCB0aGVzZSBjYXBhYmlsaXRpZXMgaGF2ZSBiZWVuIGluIGhlbGxvIG1lc3NhZ2UuDQo+ID4g
PiAgICBGb3IgZXhhbXBsZToNCj4gPiA+ICAgIDxoZWxsbyB4bWxucz0idXJuOmlldGY6cGFyYW1z
OnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4gPiA+ICAgICAgPGNhcGFiaWxpdGllcz4NCj4g
PiA+ICAgICAgICA8Y2FwYWJpbGl0eT4NCj4gPiA+ICAgICAgICAgIHVybjppZXRmOnBhcmFtczpu
ZXRjb25mOmJhc2U6MS4xDQo+ID4gPiAgICAgICAgPC9jYXBhYmlsaXR5Pg0KPiA+ID4gICAgICAg
IDxjYXBhYmlsaXR5Pg0KPiA+ID4gICAgICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2Fw
YWJpbGl0eTp3cml0YWJsZS1ydW5uaW5nOjEuMA0KPiA+ID4gICAgICAgIDwvY2FwYWJpbGl0eT4N
Cj4gPiA+ICAgICAgICA8Y2FwYWJpbGl0eT4NCj4gPiA+ICAgICAgICAgIHVybjppZXRmOnBhcmFt
czpuZXRjb25mOmNhcGFiaWxpdHk6Y2FuZGlkYXRlOjEuMA0KPiA+ID4gICAgICAgIDwvY2FwYWJp
bGl0eT4NCj4gPiA+ICAgICAgICA8Y2FwYWJpbGl0eT4NCj4gPiA+DQo+ID4gPiAgdXJuOmlldGY6
cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wP21vZHVsZT1pZXRmLQ0KPiBuZXRjb25mJmZl
YXR1cmVzPXdyaXRhYmxlLXJ1bm5pbmcsY2FuZGlkYXRlDQo+ID4gPiAgICAgICAgPC9jYXBhYmls
aXR5Pg0KPiA+ID4gICAgICA8L2NhcGFiaWxpdGllcz4NCj4gPiA+ICAgICAgPHNlc3Npb24taWQ+
NDwvc2Vzc2lvbi1pZD4NCj4gPiA+ICAgIDwvaGVsbG8+DQo+ID4gPiAvZnJhbmsNCj4gPiA+DQo+
ID4gPiBTb2x1dGlvbjoNCj4gPiA+ICAgICAgICAgcmVtb3ZlIHRoZSBhZHZlcnRpc2VtZW50IG9m
IFlBTkcgY29uZm9ybWFuY2UgaW4gTkVUQ09ORiANCmhlbGxvDQo+ID4gPiBtZXNzYWdlLiBORVRD
T05GIGNhbiBkZWNpZGUgaG93IGFkdmVydGlzZSB0aGVzZSBpbmZvcm1hdGlvbiBieSBzZWxmLg0K
PiA+ID4NCj4gPiA+DQo+ID4gSSBkbyBub3QgYWdyZWUgdGhpcyBpcyBhIHByb2JsZW0uDQo+IA0K
PiArMQ0KPiANCj4gPiBTdGFuZGFyZGl6ZWQgbW9kdWxlIGFkdmVydGlzZW1lbnQgaXMgaW1wb3J0
YW50IGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KPiA+IENsYWltICgxKSBpcyByZWxhdGl2ZS4gRXZl
biAxMDAwIG1vZHVsZXMgd291bGQgYmUgd2F5IGxlc3MgdGhhbiBhIA0KbWVnYS1ieXRlLg0KPiA+
IFRoZSBsYXJnZXN0IHNlcnZlcnMgaGF2ZSBhYm91dCAxMDAgLSAyMDAgbW9kdWxlcywgbm93aGVy
ZSBuZWFyIDEwMDAuDQo+ID4gQ2xhaW0gKDIpIGlzIGlycmVsZXZhbnQgYmVjYXVzZSBvbmx5IFlB
TkcgbW9kdWxlcyBhcmUgaW5jbHVkZWQgaW4gWUFORw0KPiA+IG1vZHVsZSBhZHZlcnRpc2VtZW50
Lg0KPiA+IE5vbi1zdGFuZGFyZCBwcm9wcmlldGFyeSBtb2R1bGVzIHdvdWxkIGJlIGFkdmVydGlz
ZWQgc29tZSBvdGhlciB3YXkuDQo+ID4gQ2xhaW0gKDMpIGlzIGp1c3Qgd3JvbmcgLS0gTkVUQ09O
RiBhbGxvd3MgYSA8Y2FwYWJpbGl0eT4gdG8gcmVwcmVzZW50DQo+ID4gYW55dGhpbmcuDQo+ID4g
Q2xhaW0gKDQpIGFwcGxpZXMgb25seSB0byB0aGUgaWV0Zi1uZXRjb25mIG1vZHVsZS4gIFRoaXMg
aXMgdGhlIG9ubHkgDQpZQU5HDQo+ID4gbW9kdWxlIHRoYXQNCj4gPiBpcyByZWR1bmRhbnQuDQo+
IA0KPiArMSB0byBhbGwuDQo+IA0KPiANCj4gSSB3b3VsZCBhbHNvIGFkZCB0aGF0IHRoZSBtYXBw
aW5nIGZyb20gWUFORyB0byBORVRDT05GIG5lZWRzIHRvIGJlDQo+IGRlZmluZWQuICBDdXJyZW50
bHkgaXQgaXMgZGVmaW5lZCBpbiBSRkMgNjAyMC4gIE1heWJlIGl0IHNob3VsZCBiZQ0KPiBtb3Zl
ZCB0byBhIHNlcGFyYXRlIGRvY3VtZW50LCBidXQgZXZlbiBpZiBpdCB3YXMsIHRoZSBhZHZlcnRp
c21lbnQgb2YNCj4gdGhlIG1vZHVsZXMgbXVzdCBiZSBkZWZpbmVkLg0KPiANCj4gDQo+IC9tYXJ0
aW4NCg0KSSB0aGluayB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBZQU5HIG1vZHVsZXMgaXMgbWFuZGF0
b3J5LiBCdXQgaG93IHRvIA0KYWR2ZXJ0aXNlIFNIT1VMRCBiZSBkZWNpZGVkIGJ5IG9wZXJhdGlv
biBwcm90b2NvbChlLmcgTkVUQ09ORikuDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBhZHZlcnRpc2Vt
ZW50IG11c3QgYmUgaW4gaGVsbG8gbWVzc2FnZSwgaXQgY2FuIGJlIA0Kb2J0YWluZWQgYnkgYSBS
UEMgKHN1Y2ggYXMgZ2V0LXNjaGVtYS1jb25mb3JtYW5jZSkuDQoNCk5FVENPTkYgc2hvdWxkIHBy
b3ZpZGUgYSBzdGFuZGFyZCB3YXkgdG8gYWR2ZXJ0aXNlIGl0cyBzY2hlbWEoaW5jbHVkZSBZQU5H
IA0KYW5kIE5PVCBZQU5HKS4gVGhpcyBpcyBub3QgWUFORydzIGpvYi4NCg0KDQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y
bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz
IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmls
ZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1
c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw
aWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVy
IGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3Ry
aWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv
cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp
cyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp
bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg
dXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp
cGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl
ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0
cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy
b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg==

--=_alternative 0034726E48257CD1_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPk1hcnRpbiBCam9ya2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OyDQ
tNPaIDIwMTQtMDUtMDcNCjE3OjE3OjM1Ojxicj4NCjxicj4NCiZndDsgTWFydGluIEJqb3JrbHVu
ZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyAyMDE0LTA1LTA3IDE3OjE3PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgYW5keUB5dW1hd29ya3MuY29tLCA8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24sIG5l
dG1vZEBpZXRmLm9yZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+
DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K
Jmd0OyBSZTogW25ldG1vZF0gWUFORzEuMSBpc3N1ZTogcmVtb3ZlIHRoZSBhZHZlcnRpc2VtZW50
IG9mIGNvbmZvcm1hbmNlDQo8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGluIE5FVENPTkYgaGVsbG8g
bWVzc2FnZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7
IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7
ICZndDsgT24gV2VkLCBNYXkgNywgMjAxNCBhdCAxOjA2IEFNLCAmbHQ7ZmVuZy5jaG9uZzMzQHp0
ZS5jb20uY24mZ3Q7DQp3cm90ZTo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
SGkgYWxsLDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDtJbiBzZWN0aW9uIDUuNi40LCBSRkM2MDIwLCBhZHZlcnRpc2VtZW50DQpvZiBZ
QU5HIG1vZHVsZSBjb25mb3JtYW5jZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGluZm9ybWF0aW9uIE1V
U1QgYmUgaW1wbGVtZW50ZWQgaW4gaGVsbG8gbWVzc2FnZSBieSBORVRDT05GDQpzZXJ2ZXIuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgSSB0aGluayBpdCdzIG91dCBvZiBzY29wZSBvZiBZQU5HLiBZQU5H
IG9ubHkgY2FuIGRlZmluZQ0Kd2hhdCB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBjb25mb3JtYW5j
ZSBpcywgYnV0IGNhbiBub3QgZGVmaW5lIGhvdyB0aGVzZSBjb25mb3JtYW5jZQ0KYXJlIGFkdmVy
dGlzZWQsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaXQnczxicj4NCiZndDsgJmd0OyAmZ3Q7IG9wZXJh
dGlvbiBwcm90b2NvbChlLmcgTkVUQ09ORikncyBqb2IuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtJbiBmYWN0LCBhZHZlcnRpc2VtZW50IG9mIGRhdGEgbW9kdWxlcw0K
Y29uZm9ybWFuY2UgaW5mb3JtYXRpb24gaW48YnI+DQomZ3Q7ICZndDsgJmd0OyBoZWxsbyBtZXNz
YWdlIGhhdmUgY2F1c2VkIGEgbG90IG9mIHRyb3VibGUgdG8gTkVUQ09ORi48YnI+DQomZ3Q7ICZn
dDsgJmd0OyAxLiB0b28gYmlnIGhlbGxvIG1lc3NhZ2UuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgMi4g
aG93IHRvIGFkdmVydGlzZSBOT1QgWUFORyBzY2hlbWEncyBjb25mb3JtYW5jZS48YnI+DQomZ3Q7
ICZndDsgJmd0OyAzLiBEYXRhIG1vZGVsIGluZm9ybWF0aW9uIGlzIGEgY2FwYWJpbGl0eSBvZiBv
cGVyYXRpb24gcHJvdG9jb2w/DQpJIHRoaW5rPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaXQncyBub3Qu
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgNC4gaXQncyBjb25mbGljdCB3aXRoIE5FVENPTkYncyBjYXBh
YmlsaXRpZXMgZXhjaGFuZ2UuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0ZvciBl
eGFtcGxlLE5FVENPTkYgaGFzIG93biBZQU5HIG1vZHVsZSxpdA0KZGVmaW5lZCBuZXRjb25mJ3M8
YnI+DQomZ3Q7ICZndDsgJmd0OyBjYXBhYmxpdGllcyBhcyBmZWF0dXJlcy4gU28sIGl0IHdpbGwg
YmUgYWR2ZXJ0aXNlZCBpbiBoZWxsbw0KbWVzc2FnZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7QnV0IHRoZXNlIGNhcGFiaWxpdGllcyBoYXZlIGJlZW4gaW4gaGVsbG8gbWVzc2Fn
ZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGU6PGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyZsdDtoZWxsbyB4bWxucz0mcXVvdDt1cm46aWV0Zjpw
YXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y2FwYWJpbGl0aWVzJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtjYXBhYmlsaXR5Jmd0Ozxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1cm46aWV0
ZjpwYXJhbXM6bmV0Y29uZjpiYXNlOjEuMTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyZsdDsvY2FwYWJpbGl0eSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y2FwYWJpbGl0eSZndDs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXJuOmlldGY6cGFyYW1z
Om5ldGNvbmY6Y2FwYWJpbGl0eTp3cml0YWJsZS1ydW5uaW5nOjEuMDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvY2FwYWJpbGl0eSZndDs8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y2FwYWJpbGl0eSZn
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpjYW5kaWRhdGU6MS4wPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9jYXBhYmlsaXR5Jmd0
Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtjYXBh
YmlsaXR5Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7
dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wP21vZHVsZT1pZXRmLTxicj4N
CiZndDsgbmV0Y29uZiZhbXA7ZmVhdHVyZXM9d3JpdGFibGUtcnVubmluZyxjYW5kaWRhdGU8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2NhcGFiaWxp
dHkmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2NhcGFi
aWxpdGllcyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtz
ZXNzaW9uLWlkJmd0OzQmbHQ7L3Nlc3Npb24taWQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyZsdDsvaGVsbG8mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgL2ZyYW5rPGJyPg0K
Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBTb2x1dGlvbjo8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVtb3ZlIHRoZSBhZHZlcnRpc2Vt
ZW50IG9mDQpZQU5HIGNvbmZvcm1hbmNlIGluIE5FVENPTkYgaGVsbG88YnI+DQomZ3Q7ICZndDsg
Jmd0OyBtZXNzYWdlLiBORVRDT05GIGNhbiBkZWNpZGUgaG93IGFkdmVydGlzZSB0aGVzZSBpbmZv
cm1hdGlvbg0KYnkgc2VsZi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7IEkgZG8gbm90IGFncmVlIHRoaXMgaXMgYSBwcm9ibGVtLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyArMTxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFN0YW5kYXJkaXplZCBt
b2R1bGUgYWR2ZXJ0aXNlbWVudCBpcyBpbXBvcnRhbnQgZm9yIGludGVyb3BlcmFiaWxpdHkuPGJy
Pg0KJmd0OyAmZ3Q7IENsYWltICgxKSBpcyByZWxhdGl2ZS4gRXZlbiAxMDAwIG1vZHVsZXMgd291
bGQgYmUgd2F5IGxlc3MgdGhhbg0KYSBtZWdhLWJ5dGUuPGJyPg0KJmd0OyAmZ3Q7IFRoZSBsYXJn
ZXN0IHNlcnZlcnMgaGF2ZSBhYm91dCAxMDAgLSAyMDAgbW9kdWxlcywgbm93aGVyZSBuZWFyDQox
MDAwLjxicj4NCiZndDsgJmd0OyBDbGFpbSAoMikgaXMgaXJyZWxldmFudCBiZWNhdXNlIG9ubHkg
WUFORyBtb2R1bGVzIGFyZSBpbmNsdWRlZA0KaW4gWUFORzxicj4NCiZndDsgJmd0OyBtb2R1bGUg
YWR2ZXJ0aXNlbWVudC48YnI+DQomZ3Q7ICZndDsgTm9uLXN0YW5kYXJkIHByb3ByaWV0YXJ5IG1v
ZHVsZXMgd291bGQgYmUgYWR2ZXJ0aXNlZCBzb21lIG90aGVyDQp3YXkuPGJyPg0KJmd0OyAmZ3Q7
IENsYWltICgzKSBpcyBqdXN0IHdyb25nIC0tIE5FVENPTkYgYWxsb3dzIGEgJmx0O2NhcGFiaWxp
dHkmZ3Q7DQp0byByZXByZXNlbnQ8YnI+DQomZ3Q7ICZndDsgYW55dGhpbmcuPGJyPg0KJmd0OyAm
Z3Q7IENsYWltICg0KSBhcHBsaWVzIG9ubHkgdG8gdGhlIGlldGYtbmV0Y29uZiBtb2R1bGUuICZu
YnNwO1RoaXMNCmlzIHRoZSBvbmx5IFlBTkc8YnI+DQomZ3Q7ICZndDsgbW9kdWxlIHRoYXQ8YnI+
DQomZ3Q7ICZndDsgaXMgcmVkdW5kYW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyArMSB0byBhbGwu
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB3b3VsZCBhbHNvIGFkZCB0aGF0IHRo
ZSBtYXBwaW5nIGZyb20gWUFORyB0byBORVRDT05GIG5lZWRzIHRvIGJlPGJyPg0KJmd0OyBkZWZp
bmVkLiAmbmJzcDtDdXJyZW50bHkgaXQgaXMgZGVmaW5lZCBpbiBSRkMgNjAyMC4gJm5ic3A7TWF5
YmUgaXQNCnNob3VsZCBiZTxicj4NCiZndDsgbW92ZWQgdG8gYSBzZXBhcmF0ZSBkb2N1bWVudCwg
YnV0IGV2ZW4gaWYgaXQgd2FzLCB0aGUgYWR2ZXJ0aXNtZW50DQpvZjxicj4NCiZndDsgdGhlIG1v
ZHVsZXMgbXVzdCBiZSBkZWZpbmVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9t
YXJ0aW48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgdGhpbmsgdGhl
IGFkdmVydGlzZW1lbnQgb2YgWUFORyBtb2R1bGVzIGlzIG1hbmRhdG9yeS4NCkJ1dCBob3cgdG8g
YWR2ZXJ0aXNlIFNIT1VMRCBiZSBkZWNpZGVkIGJ5IG9wZXJhdGlvbiBwcm90b2NvbChlLmcgTkVU
Q09ORikuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGRvbid0IHRo
aW5rIHRoaXMgYWR2ZXJ0aXNlbWVudCBtdXN0IGJlIGluIGhlbGxvDQptZXNzYWdlLCBpdCBjYW4g
YmUgb2J0YWluZWQgYnkgYSBSUEMgKHN1Y2ggYXMgZ2V0LXNjaGVtYS1jb25mb3JtYW5jZSkuPC9m
b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5ORVRDT05GIHNob3VsZCBwcm92
aWRlIGEgc3RhbmRhcmQgd2F5IHRvIGFkdmVydGlzZQ0KaXRzIHNjaGVtYShpbmNsdWRlIFlBTkcg
YW5kIE5PVCBZQU5HKS4gVGhpcyBpcyBub3QgWUFORydzIGpvYi48L2ZvbnQ+PC90dD4NCjxicj4N
Cjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT
ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh
bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k
IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo
ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu
eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p
bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxi
cj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1
cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQg
YW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNv
bmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBh
ZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk
aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0
aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hp
Yml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBk
ZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4N
Cg==

--=_alternative 0034726E48257CD1_=--


From nobody Wed May  7 03:10:38 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EC11A064E for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 03:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcAfFxZJrY6x for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 03:10:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2111A06B2 for <netmod@ietf.org>; Wed,  7 May 2014 03:10:35 -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 1286A3F4012; Wed,  7 May 2014 12:10:30 +0200 (CEST)
Date: Wed, 07 May 2014 12:10:29 +0200 (CEST)
Message-Id: <20140507.121029.683551387839890053.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHQsf+PoySWcwc5PWLaMMrgBhq-Nff6BQsJvnB5Uu9v1cg@mail.gmail.com>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <20140507.082953.816547373694750532.mbj@tail-f.com> <CABCOCHQsf+PoySWcwc5PWLaMMrgBhq-Nff6BQsJvnB5Uu9v1cg@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XoKbI0hnAnf04sRN8SQFvQ6ilVY
Cc: netmod@ietf.org
Subject: Re: [netmod] Y49: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 10:10:37 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, May 6, 2014 at 11:29 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > Hi,
> >
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > Hi,
> > >
> > > The question about submodules reminded me of our previous debate
> > > on how nested submodules are treated.  I just did a test with
> > > pyang and yangdump-pro.  They do not produce the same results.
> >
> > [...]
> >
> > > Solution:  Need to reach WG consensus on proper behavior and update
> > > the appropriate text in YANG 1.1.
> >
> > I agree that this needs to be clarified.
> >
> > This might not come as a surprise to you, but I prefer solution
> > Y49-02; make "unexported" submodules illegal.
> >
> > IMO allowing "unexported" submodules would be really confusing.  Would
> > they solve any problem?
> >
> >
> The module may be under development and not all definitions are final yet.

I think this needs to be handled by the toolchain (if at all).  The
rules we define for YANG modules applies to valid modules.  How you
got there doesn't matter.

> There is not a single line of text in RFC 6020 that says it is an error to
> have a nested submodule.

I already agreed that we need to clarify this.  (But nested submodules
in general are allowed by 6020).


/martin


From nobody Wed May  7 05:57:35 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589581A02B3 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 05:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.852
X-Spam-Level: 
X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le2C0myTSbpo for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 05:57:31 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7061A02A5 for <netmod@ietf.org>; Wed,  7 May 2014 05:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2378; q=dns/txt; s=iport; t=1399467447; x=1400677047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hNh5cs6bzsDHKlDfKZDUA937IfjeGZ0s9vY7G7FOqCw=; b=DRhFZoe4yKXtrrhdd3wz8gZxIiifHIqVzESaBOXG31nE1sMqFItSBgfZ 52s9+rRY/8fmlrB4mCuadCd23YLmNcicZjAe8/lRs9jw1n6SEJCww+mzm qh4Wh8M/3NeZO6RPTuCg5HOLU9TiBzlDnjNHhhhVbzehtsqr5153XkapV w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAEYsalOtJV2b/2dsb2JhbABagwZPWL1chmtRAYEaFnSCJQEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQBDQUIE4geCA3PORMEjiExBwaDJIEVBIlOomSDNIIv
X-IronPort-AV: E=Sophos;i="4.97,1003,1389744000"; d="scan'208";a="323042288"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 07 May 2014 12:57:27 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s47CvRjr029640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 12:57:27 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 7 May 2014 07:57:26 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>, =?iso-8859-1?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
Thread-Topic: [netmod] Y52: Default for Mandatory Statement
Thread-Index: AQH+hJr1IFJHE69gzGt1ULOBDVQTkAERKc0fAW1Lt72awuqpIA==
Date: Wed, 7 May 2014 12:57:25 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AAE869@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAE090@xmb-aln-x08.cisco.com> <20140507.094039.1355620338232070983.mbj@tail-f.com> <E83A19C6-7728-41CA-8554-0C810E5EF8FD@nic.cz>
In-Reply-To: <E83A19C6-7728-41CA-8554-0C810E5EF8FD@nic.cz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.168]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tIanwEPFMTh12A4QSX4OeaPGUGs
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y52: Default for Mandatory Statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 12:57:33 -0000

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: 07 May 2014 09:26
> To: Martin Bj=F6rklund
> Cc: powladi@cisco.com; netmod@ietf.org
> Subject: Re: [netmod] Y52: Default for Mandatory Statement
>=20
>=20
> On 07 May 2014, at 09:40, Martin Bjorklund <mbj@tail-f.com> wrote:
>=20
> > Hi,
> >
> >> There can be containers which contain a set of fields which are all
> >> mandatory, and currently each leaf needs to be individually tagged
> >> as mandatory. For readability, it would be good to be able to
> >> indicate that everything within a subtree is mandatory.
> >
> > Readability is always subjective.  Personally, I think it is more
> > clear to have the explicit mandatory statement in each subnode.

Sure, perhaps readability was the wrong word. To put it another way:
What's being suggested is that in some cases, "it is expected that
elements in this container are mandatory" might be  "this leaf is
mandatory". (And it would make the model less verbose.) Though I expect
it's still subjective ;-)

In particular, is it fair to say that the usage of the "config" statement
on non-presence containers has equivalent behavior/use cases? (i.e. The
alternative would be that instead of putting the "config" statement on a
non-presence container it should be specified for each subnode.)

> > Also, I think is confusing to let the 'mandatory' statement be applied
> > recursively in some cases (these new cases), but not in others
> > (existing mandatory in choice).

Fair point; so the alternative suggestion of using "mandatory-default"
instead to set the default sense for subnodes would be clearer.

> +1
>=20
> Another complication would be augments that may add new nodes to the subt=
ree
> from outside.

Sure; I would expect augmenting within a subtree that defaults to true
would not be a mainline use case, but it does need considering. If we use
"mandataory-default" to set the default sense for the mandatory keyword
(i.e the "alternative solution"), does that help?

Cheers,
Peyman

> Lada
>=20
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20


From nobody Wed May  7 07:52:06 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F841A0324 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 07:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6hkWlYUQpLX for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 07:52:03 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6AD1A02E7 for <netmod@ietf.org>; Wed,  7 May 2014 07:52:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DE370540838; Wed,  7 May 2014 16:51:57 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOXtTVn5d3hb; Wed,  7 May 2014 16:51:50 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 67A78540222; Wed,  7 May 2014 16:51:49 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "netmod\@ietf.org" <netmod@ietf.org>
In-Reply-To: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Wed, 07 May 2014 16:51:48 +0200
Message-ID: <m2ha51d4l7.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jj_sL8amc2vlLbSkj2QNPwObQvQ
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 14:52:05 -0000

Hi,

IMO, it would suffice to include all submodules in the main module and have the belongs-to statements in submodules. Definitions from every submodule would be available in the main module as well as in any other submodule.

I think that including a submodule from another submodule is pretty much useless because the main module and all submodules share the same namespace in any case.

Lada
  
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> The question about submodules reminded me of our previous debate
> on how nested submodules are treated.  I just did a test with
> pyang and yangdump-pro.  They do not produce the same results.
>
>    tinc2     <----  tinc1
>                          |
>                          + tinc1a
>                          |
>                          + tinc1b   <-- tinc1c
>
> Problem: Need to clarify behavior when a submodule (tinc1c) is not
> included by the main module.
>
> pyang says this is an error and refuses to even compile tinc2.
> I cannot find any text where it says this is an error.
>
> andy@andy-swdev:~/modules$ pyang tinc1.yang
> tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by
> the module tinc1
>
> andy@andy-swdev:~/modules$ pyang tinc2.yang
> tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by
> the module tinc1
>
> yangdump-pro does report an error for using the tinc3a typedef in an
> external module.  However it does not flag an error when that same type
> is pulled through within a grouping.  The unexported submodule tinc1c is not
> treated as an error.
>
>
> andy@andy-swdev:~/modules$ yangdump-pro tinc1
> *** /home/andy/modules/tinc1.yang
> *** 0 Errors, 0 Warnings
>
>
> andy@andy-swdev:~/modules$ yangdump-pro tinc2
> Error: typedef definition for 'tinc1:type3' not found in module tinc1
> tinc2.yang:19.12: error(250): definition not found
>
> *** /home/andy/modules/tinc2.yang
> *** 1 Errors, 0 Warnings
>
> Solution:  Need to reach WG consensus on proper behavior and update
> the appropriate text in YANG 1.1.
>
>    * Is it an error to have an unexported submodule (IMO, no)
>
>    * Is it an error to use an unexported definition (yes; seems to be
> consensus
>      on this point)
>
>     * Is it an error to use an unexported definition if it is used in a
> grouping
>       that is exported?  (IMO, no)
>
>
>
> Andy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed May  7 08:25:29 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0A1A0395 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 08:25:26 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLCRZAAZtigW for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 08:25:24 -0700 (PDT)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19A521A0372 for <netmod@ietf.org>; Wed,  7 May 2014 08:25:23 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id i50so1273077qgf.3 for <netmod@ietf.org>; Wed, 07 May 2014 08:25:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ssaEQhvxqL5k9vRtB5KvRac4JoqsLnpqarp3EZyDMlw=; b=JPfDnqn7aBIkg5QpAbOmwYoESH5A7tt6BarsEMINjOjoU61TiUGPEt4IPfWzYXxSr4 jIyMxqpX2WjMrwtwZ/q7Qqn591Ru7MCHxHIfh4FSdBDSeg7WWSbu1o6nmHDs8TPUFYKe 7AqZY8nDRda/F04yj5ZSebWa7QmkXUKKMh/i/Ft7MBZzEF2jeYLl1eK8UnM8bqVY+cMB oZOShMpvZ9P6pm/aD7EdnU7kuspnSgZIqd42b+B3DJXTYXcvxl+gPx6s7vWHvb2oxb0z YHN7N5BKINCpHPlYcgzf+fC81n1ofCk5gDIFjWoY7ogKcL4N3dbbanL7fzi51Xl+58g+ M8cw==
X-Gm-Message-State: ALoCoQk+P+mXfDP9oHq9kWMwfjhA+pPYVQRlusL0mlrWFr9QbT+dqgj39w2xvmLfQa4YzyJF6jth
MIME-Version: 1.0
X-Received: by 10.229.72.10 with SMTP id k10mr64611529qcj.2.1399476319641; Wed, 07 May 2014 08:25:19 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 08:25:19 -0700 (PDT)
In-Reply-To: <m2ha51d4l7.fsf@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz>
Date: Wed, 7 May 2014 08:25:19 -0700
Message-ID: <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=089e01681318e7796d04f8d0f8e3
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZwHqS9zpaWz8UPxa3Ue7sPM1fME
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 15:25:26 -0000

--089e01681318e7796d04f8d0f8e3
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Hi,
>
> IMO, it would suffice to include all submodules in the main module and
> have the belongs-to statements in submodules. Definitions from every
> submodule would be available in the main module as well as in any other
> submodule.
>
> I think that including a submodule from another submodule is pretty much
> useless because the main module and all submodules share the same namespace
> in any case.
>
>
I think I like this idea (!)

It has always been my opinion that there is only 1 namespace within a
module.
Submodules provide organization, not namespace partitioning.  Include
statements
within submodules enforce partitioned namespace and lead to strange export
behavior.

But it is not backward-compatible to say include-stmt within a submodule is
not allowed.

We were here before.  You and Martin concluded that "include tinc1c" MUST
be present
in the main module and I said the module namespace is flat so 'type3' was
exported to tinc2
even if it was not included in the main module.

The fundamental issue is whether a module namespace is a hierarchy of
submodule namespaces
of whether the module namespace is flat and all submodules contribute to it.


Lada
>

Andy


>
> Andy Bierman <andy@yumaworks.com> writes:
>
> > Hi,
> >
> > The question about submodules reminded me of our previous debate
> > on how nested submodules are treated.  I just did a test with
> > pyang and yangdump-pro.  They do not produce the same results.
> >
> >    tinc2     <----  tinc1
> >                          |
> >                          + tinc1a
> >                          |
> >                          + tinc1b   <-- tinc1c
> >
> > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > included by the main module.
> >
> > pyang says this is an error and refuses to even compile tinc2.
> > I cannot find any text where it says this is an error.
> >
> > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by
> > the module tinc1
> >
> > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not by
> > the module tinc1
> >
> > yangdump-pro does report an error for using the tinc3a typedef in an
> > external module.  However it does not flag an error when that same type
> > is pulled through within a grouping.  The unexported submodule tinc1c is
> not
> > treated as an error.
> >
> >
> > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > *** /home/andy/modules/tinc1.yang
> > *** 0 Errors, 0 Warnings
> >
> >
> > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > Error: typedef definition for 'tinc1:type3' not found in module tinc1
> > tinc2.yang:19.12: error(250): definition not found
> >
> > *** /home/andy/modules/tinc2.yang
> > *** 1 Errors, 0 Warnings
> >
> > Solution:  Need to reach WG consensus on proper behavior and update
> > the appropriate text in YANG 1.1.
> >
> >    * Is it an error to have an unexported submodule (IMO, no)
> >
> >    * Is it an error to use an unexported definition (yes; seems to be
> > consensus
> >      on this point)
> >
> >     * Is it an error to use an unexported definition if it is used in a
> > grouping
> >       that is exported?  (IMO, no)
> >
> >
> >
> > Andy
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--089e01681318e7796d04f8d0f8e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<br>
IMO, it would suffice to include all submodules in the main module and have=
 the belongs-to statements in submodules. Definitions from every submodule =
would be available in the main module as well as in any other submodule.<br=
>

<br>
I think that including a submodule from another submodule is pretty much us=
eless because the main module and all submodules share the same namespace i=
n any case.<br>
<br></blockquote><div><br></div><div>I think I like this idea (!)</div><div=
><br></div><div>It has always been my opinion that there is only 1 namespac=
e within a module.</div><div>Submodules provide organization, not namespace=
 partitioning. =A0Include statements</div>
<div>within submodules enforce partitioned namespace and lead to strange ex=
port behavior.</div><div><br></div><div>But it is not backward-compatible t=
o say include-stmt within a submodule is not allowed.</div><div><br></div>
<div>We were here before. =A0You and Martin concluded that &quot;include ti=
nc1c&quot; MUST be present</div><div>in the main module and I said the modu=
le namespace is flat so &#39;type3&#39; was exported to tinc2</div><div>eve=
n if it was not included in the main module.</div>
<div><br></div><div>The fundamental issue is whether a module namespace is =
a hierarchy of submodule namespaces</div><div>of whether the module namespa=
ce is flat and all submodules contribute to it.</div><div><br></div><div>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
Lada<br></blockquote><div><br></div><div>Andy</div><div>=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<br>
Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</=
a>&gt; writes:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; The question about submodules reminded me of our previous debate<br>
&gt; on how nested submodules are treated. =A0I just did a test with<br>
&gt; pyang and yangdump-pro. =A0They do not produce the same results.<br>
&gt;<br>
&gt; =A0 =A0tinc2 =A0 =A0 &lt;---- =A0tinc1<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1a<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1b =A0 &lt;--=
 tinc1c<br>
&gt;<br>
&gt; Problem: Need to clarify behavior when a submodule (tinc1c) is not<br>
&gt; included by the main module.<br>
&gt;<br>
&gt; pyang says this is an error and refuses to even compile tinc2.<br>
&gt; I cannot find any text where it says this is an error.<br>
&gt;<br>
&gt; andy@andy-swdev:~/modules$ pyang tinc1.yang<br>
&gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not =
by<br>
&gt; the module tinc1<br>
&gt;<br>
&gt; andy@andy-swdev:~/modules$ pyang tinc2.yang<br>
&gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not =
by<br>
&gt; the module tinc1<br>
&gt;<br>
&gt; yangdump-pro does report an error for using the tinc3a typedef in an<b=
r>
&gt; external module. =A0However it does not flag an error when that same t=
ype<br>
&gt; is pulled through within a grouping. =A0The unexported submodule tinc1=
c is not<br>
&gt; treated as an error.<br>
&gt;<br>
&gt;<br>
&gt; andy@andy-swdev:~/modules$ yangdump-pro tinc1<br>
&gt; *** /home/andy/modules/tinc1.yang<br>
&gt; *** 0 Errors, 0 Warnings<br>
&gt;<br>
&gt;<br>
&gt; andy@andy-swdev:~/modules$ yangdump-pro tinc2<br>
&gt; Error: typedef definition for &#39;tinc1:type3&#39; not found in modul=
e tinc1<br>
&gt; tinc2.yang:19.12: error(250): definition not found<br>
&gt;<br>
&gt; *** /home/andy/modules/tinc2.yang<br>
&gt; *** 1 Errors, 0 Warnings<br>
&gt;<br>
&gt; Solution: =A0Need to reach WG consensus on proper behavior and update<=
br>
&gt; the appropriate text in YANG 1.1.<br>
&gt;<br>
&gt; =A0 =A0* Is it an error to have an unexported submodule (IMO, no)<br>
&gt;<br>
&gt; =A0 =A0* Is it an error to use an unexported definition (yes; seems to=
 be<br>
&gt; consensus<br>
&gt; =A0 =A0 =A0on this point)<br>
&gt;<br>
&gt; =A0 =A0 * Is it an error to use an unexported definition if it is used=
 in a<br>
&gt; grouping<br>
&gt; =A0 =A0 =A0 that is exported? =A0(IMO, no)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt; _______________________________________________<br>
&gt; netmod mailing list<br>
&gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
</font></span></blockquote></div><br></div></div>

--089e01681318e7796d04f8d0f8e3--


From nobody Wed May  7 08:31:11 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16561A0368 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 08:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJBbnCPJlDh7 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 08:31:05 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F19C31A0387 for <netmod@ietf.org>; Wed,  7 May 2014 08:31:04 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8541713F976; Wed,  7 May 2014 17:30:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399476659; bh=mZZypApj/PKHFWmxZwAhj9brHdF7Cl1+EoMlwUMg9O8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Wr8XUUQQ5KsJ0FtyrDZA1aRazxOLYRBgBIRd8YX+cCDXhWH69dQR0GqFUjzsY/rhe fX0u8rXp1FZ93kuAzJ0Dbz3I+GFunuNRt391OHUnWfLLK+z59pW61a3izgUWjyUhi3 Ll/M1p8E6otVgUkF+9Qdnv+rE5ktvJhjL57a0Ews=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com>
Date: Wed, 7 May 2014 17:30:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/c3kstqjvElpD6lvz48R6vNMtOXw
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 15:31:07 -0000

On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi,
>=20
> IMO, it would suffice to include all submodules in the main module and =
have the belongs-to statements in submodules. Definitions from every =
submodule would be available in the main module as well as in any other =
submodule.
>=20
> I think that including a submodule from another submodule is pretty =
much useless because the main module and all submodules share the same =
namespace in any case.
>=20
>=20
> I think I like this idea (!)
>=20
> It has always been my opinion that there is only 1 namespace within a =
module.
> Submodules provide organization, not namespace partitioning.  Include =
statements
> within submodules enforce partitioned namespace and lead to strange =
export behavior.
>=20
> But it is not backward-compatible to say include-stmt within a =
submodule is not allowed.

It may remain allowed but not required for making definitions from other =
submodules (and the main module) available. I think this is a compatible =
change.

>=20
> We were here before.  You and Martin concluded that "include tinc1c" =
MUST be present
> in the main module and I said the module namespace is flat so 'type3' =
was exported to tinc2
> even if it was not included in the main module.

In my view, this is an additional complexity that buys you nothing.

Lada

>=20
> The fundamental issue is whether a module namespace is a hierarchy of =
submodule namespaces
> of whether the module namespace is flat and all submodules contribute =
to it.
>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> Andy Bierman <andy@yumaworks.com> writes:
>=20
> > Hi,
> >
> > The question about submodules reminded me of our previous debate
> > on how nested submodules are treated.  I just did a test with
> > pyang and yangdump-pro.  They do not produce the same results.
> >
> >    tinc2     <----  tinc1
> >                          |
> >                          + tinc1a
> >                          |
> >                          + tinc1b   <-- tinc1c
> >
> > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > included by the main module.
> >
> > pyang says this is an error and refuses to even compile tinc2.
> > I cannot find any text where it says this is an error.
> >
> > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but =
not by
> > the module tinc1
> >
> > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but =
not by
> > the module tinc1
> >
> > yangdump-pro does report an error for using the tinc3a typedef in an
> > external module.  However it does not flag an error when that same =
type
> > is pulled through within a grouping.  The unexported submodule =
tinc1c is not
> > treated as an error.
> >
> >
> > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > *** /home/andy/modules/tinc1.yang
> > *** 0 Errors, 0 Warnings
> >
> >
> > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > Error: typedef definition for 'tinc1:type3' not found in module =
tinc1
> > tinc2.yang:19.12: error(250): definition not found
> >
> > *** /home/andy/modules/tinc2.yang
> > *** 1 Errors, 0 Warnings
> >
> > Solution:  Need to reach WG consensus on proper behavior and update
> > the appropriate text in YANG 1.1.
> >
> >    * Is it an error to have an unexported submodule (IMO, no)
> >
> >    * Is it an error to use an unexported definition (yes; seems to =
be
> > consensus
> >      on this point)
> >
> >     * Is it an error to use an unexported definition if it is used =
in a
> > grouping
> >       that is exported?  (IMO, no)
> >
> >
> >
> > Andy
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May  7 08:53:32 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941421A079B for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 08:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djM-subdHCJy for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 08:53:29 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id CDBFC1A0392 for <netmod@ietf.org>; Wed,  7 May 2014 08:53:28 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id r5so1333798qcx.35 for <netmod@ietf.org>; Wed, 07 May 2014 08:53:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=penA964iBg7KYKZCYBeIaR8N1NwLGeYQYJe5A+bimRc=; b=XK5st1FYGKxsHAdKdGXFprdrUvkCKMr5j7rrk3wd2axDBEMTKUa49/oJifgxK/AxaM BKyZF8caU2dtiZ7y5eEj7cKPhs68cqFyHjRcKXPQnxCyrCUoMIUMmy3yjmk6OFZImAV1 84KiF+wWx3I+Kz+lwp7bsvWIoQnl9QUR3W+QIBC0QJQRnmbJb3cDWTrnWh4El6kT9Vyi grtYFZyeIVhvx2n+12Y0QTxHeBW10EFeDM253zzt9NDiRjTZ3XsSap7OFZnqkTyr7+KB hfkPu+umzCS45qW8jSsL7Ld9SHEHN6DQkUr8mpbSU+IglYXADOPIvgMQi3Ym1HOd+jBL c/zw==
X-Gm-Message-State: ALoCoQlETactOFiP6A0imJrKfa36KRmgyRfmz5OjG6CeP8Otyvx0/LB6y3QAIxnRi3OrsADAyU09
MIME-Version: 1.0
X-Received: by 10.224.138.3 with SMTP id y3mr66478933qat.78.1399478004439; Wed, 07 May 2014 08:53:24 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 08:53:24 -0700 (PDT)
In-Reply-To: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com> <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz>
Date: Wed, 7 May 2014 08:53:24 -0700
Message-ID: <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=047d7b672b4453811804f8d15d44
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sWoL2Q3EIXKvAM6rIq22hG5xxvo
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 15:53:30 -0000

--047d7b672b4453811804f8d15d44
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> >
> > IMO, it would suffice to include all submodules in the main module and
> have the belongs-to statements in submodules. Definitions from every
> submodule would be available in the main module as well as in any other
> submodule.
> >
> > I think that including a submodule from another submodule is pretty much
> useless because the main module and all submodules share the same namespace
> in any case.
> >
> >
> > I think I like this idea (!)
> >
> > It has always been my opinion that there is only 1 namespace within a
> module.
> > Submodules provide organization, not namespace partitioning.  Include
> statements
> > within submodules enforce partitioned namespace and lead to strange
> export behavior.
> >
> > But it is not backward-compatible to say include-stmt within a submodule
> is not allowed.
>
> It may remain allowed but not required for making definitions from other
> submodules (and the main module) available. I think this is a compatible
> change.
>
> >
> > We were here before.  You and Martin concluded that "include tinc1c"
> MUST be present
> > in the main module and I said the module namespace is flat so 'type3'
> was exported to tinc2
> > even if it was not included in the main module.
>
> In my view, this is an additional complexity that buys you nothing.
>
>
Does this mean we agree?  IMO the "belongs-to foo" statement is enough.
That says "my definitions are for namespace 'foo', and I can access all
definitions in namespace 'foo'.

That way we cannot have 2 definitions of the same thing in different
submodules,
or 1 in the main module and 1 in a submodule.

Why can't a submodule access definitions in the main module?
What problem does that solve?

IMO it is a lot simpler not to have any concept of submodule namespaces.


Lada
>

Andy


>
> >
> > The fundamental issue is whether a module namespace is a hierarchy of
> submodule namespaces
> > of whether the module namespace is flat and all submodules contribute to
> it.
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > Hi,
> > >
> > > The question about submodules reminded me of our previous debate
> > > on how nested submodules are treated.  I just did a test with
> > > pyang and yangdump-pro.  They do not produce the same results.
> > >
> > >    tinc2     <----  tinc1
> > >                          |
> > >                          + tinc1a
> > >                          |
> > >                          + tinc1b   <-- tinc1c
> > >
> > > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > > included by the main module.
> > >
> > > pyang says this is an error and refuses to even compile tinc2.
> > > I cannot find any text where it says this is an error.
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not
> by
> > > the module tinc1
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not
> by
> > > the module tinc1
> > >
> > > yangdump-pro does report an error for using the tinc3a typedef in an
> > > external module.  However it does not flag an error when that same type
> > > is pulled through within a grouping.  The unexported submodule tinc1c
> is not
> > > treated as an error.
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > > *** /home/andy/modules/tinc1.yang
> > > *** 0 Errors, 0 Warnings
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > > Error: typedef definition for 'tinc1:type3' not found in module tinc1
> > > tinc2.yang:19.12: error(250): definition not found
> > >
> > > *** /home/andy/modules/tinc2.yang
> > > *** 1 Errors, 0 Warnings
> > >
> > > Solution:  Need to reach WG consensus on proper behavior and update
> > > the appropriate text in YANG 1.1.
> > >
> > >    * Is it an error to have an unexported submodule (IMO, no)
> > >
> > >    * Is it an error to use an unexported definition (yes; seems to be
> > > consensus
> > >      on this point)
> > >
> > >     * Is it an error to use an unexported definition if it is used in a
> > > grouping
> > >       that is exported?  (IMO, no)
> > >
> > >
> > >
> > > Andy
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--047d7b672b4453811804f8d15d44
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 07 May 2014, at 17:25, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka &lt;<a href=3D"mailto:=
lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; IMO, it would suffice to include all submodules in the main module and=
 have the belongs-to statements in submodules. Definitions from every submo=
dule would be available in the main module as well as in any other submodul=
e.<br>

&gt;<br>
&gt; I think that including a submodule from another submodule is pretty mu=
ch useless because the main module and all submodules share the same namesp=
ace in any case.<br>
&gt;<br>
&gt;<br>
&gt; I think I like this idea (!)<br>
&gt;<br>
&gt; It has always been my opinion that there is only 1 namespace within a =
module.<br>
&gt; Submodules provide organization, not namespace partitioning. =A0Includ=
e statements<br>
&gt; within submodules enforce partitioned namespace and lead to strange ex=
port behavior.<br>
&gt;<br>
&gt; But it is not backward-compatible to say include-stmt within a submodu=
le is not allowed.<br>
<br>
It may remain allowed but not required for making definitions from other su=
bmodules (and the main module) available. I think this is a compatible chan=
ge.<br>
<br>
&gt;<br>
&gt; We were here before. =A0You and Martin concluded that &quot;include ti=
nc1c&quot; MUST be present<br>
&gt; in the main module and I said the module namespace is flat so &#39;typ=
e3&#39; was exported to tinc2<br>
&gt; even if it was not included in the main module.<br>
<br>
In my view, this is an additional complexity that buys you nothing.<br>
<br></blockquote><div><br></div><div>Does this mean we agree? =A0IMO the &q=
uot;belongs-to foo&quot; statement is enough.</div><div>That says &quot;my =
definitions are for namespace &#39;foo&#39;, and I can access all</div><div=
>
definitions in namespace &#39;foo&#39;.</div><div><br></div><div>That way w=
e cannot have 2 definitions of the same thing in different submodules,</div=
><div>or 1 in the main module and 1 in a submodule.</div><div><br></div>
<div>Why can&#39;t a submodule access definitions in the main module?</div>=
<div>What problem does that solve?</div><div><br></div><div>IMO it is a lot=
 simpler not to have any concept of submodule namespaces.</div><div><br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lada<br></blockquote><div><br></div><div>Andy</div><div>=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<br>
&gt;<br>
&gt; The fundamental issue is whether a module namespace is a hierarchy of =
submodule namespaces<br>
&gt; of whether the module namespace is flat and all submodules contribute =
to it.<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; writes:<br>
&gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; The question about submodules reminded me of our previous debate<=
br>
&gt; &gt; on how nested submodules are treated. =A0I just did a test with<b=
r>
&gt; &gt; pyang and yangdump-pro. =A0They do not produce the same results.<=
br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0tinc2 =A0 =A0 &lt;---- =A0tinc1<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1a<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1b =A0 &=
lt;-- tinc1c<br>
&gt; &gt;<br>
&gt; &gt; Problem: Need to clarify behavior when a submodule (tinc1c) is no=
t<br>
&gt; &gt; included by the main module.<br>
&gt; &gt;<br>
&gt; &gt; pyang says this is an error and refuses to even compile tinc2.<br=
>
&gt; &gt; I cannot find any text where it says this is an error.<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ pyang tinc1.yang<br>
&gt; &gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but=
 not by<br>
&gt; &gt; the module tinc1<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ pyang tinc2.yang<br>
&gt; &gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but=
 not by<br>
&gt; &gt; the module tinc1<br>
&gt; &gt;<br>
&gt; &gt; yangdump-pro does report an error for using the tinc3a typedef in=
 an<br>
&gt; &gt; external module. =A0However it does not flag an error when that s=
ame type<br>
&gt; &gt; is pulled through within a grouping. =A0The unexported submodule =
tinc1c is not<br>
&gt; &gt; treated as an error.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ yangdump-pro tinc1<br>
&gt; &gt; *** /home/andy/modules/tinc1.yang<br>
&gt; &gt; *** 0 Errors, 0 Warnings<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ yangdump-pro tinc2<br>
&gt; &gt; Error: typedef definition for &#39;tinc1:type3&#39; not found in =
module tinc1<br>
&gt; &gt; tinc2.yang:19.12: error(250): definition not found<br>
&gt; &gt;<br>
&gt; &gt; *** /home/andy/modules/tinc2.yang<br>
&gt; &gt; *** 1 Errors, 0 Warnings<br>
&gt; &gt;<br>
&gt; &gt; Solution: =A0Need to reach WG consensus on proper behavior and up=
date<br>
&gt; &gt; the appropriate text in YANG 1.1.<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0* Is it an error to have an unexported submodule (IMO, no)=
<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0* Is it an error to use an unexported definition (yes; see=
ms to be<br>
&gt; &gt; consensus<br>
&gt; &gt; =A0 =A0 =A0on this point)<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0 * Is it an error to use an unexported definition if it is=
 used in a<br>
&gt; &gt; grouping<br>
&gt; &gt; =A0 =A0 =A0 that is exported? =A0(IMO, no)<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; netmod mailing list<br>
&gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--047d7b672b4453811804f8d15d44--


From nobody Wed May  7 09:00:59 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB481A0353 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzC9TcG0X5MA for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:00:55 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE8E1A0321 for <netmod@ietf.org>; Wed,  7 May 2014 09:00:55 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8862813F86F; Wed,  7 May 2014 18:00:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399478450; bh=koitqEbcOTFpNn+3xe3lz9XQ37CT5zd/H5KTwalPZMk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TEFcTsjUooIovdLwzzrEv77s3zv3PotGSRIOc3yPKYwTVl5qlU8Gfoo3+0LqOIpDR kLPw5vhS6UTVHMax7SYLWZMFEUMpUsNgxNLGrrMaqrSqjqKpaIc04QhPHkjvOvZUTl If10bTuyQaqPUrz91BCaQiZdl+V7IMIlnZ55FVTE=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com>
Date: Wed, 7 May 2014 18:00:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com> <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ruDKJTsxg_6K_1y_RANV7fl7pkk
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:00:57 -0000

On 07 May 2014, at 17:53, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>=20
> On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> > Hi,
> >
> > IMO, it would suffice to include all submodules in the main module =
and have the belongs-to statements in submodules. Definitions from every =
submodule would be available in the main module as well as in any other =
submodule.
> >
> > I think that including a submodule from another submodule is pretty =
much useless because the main module and all submodules share the same =
namespace in any case.
> >
> >
> > I think I like this idea (!)
> >
> > It has always been my opinion that there is only 1 namespace within =
a module.
> > Submodules provide organization, not namespace partitioning.  =
Include statements
> > within submodules enforce partitioned namespace and lead to strange =
export behavior.
> >
> > But it is not backward-compatible to say include-stmt within a =
submodule is not allowed.
>=20
> It may remain allowed but not required for making definitions from =
other submodules (and the main module) available. I think this is a =
compatible change.
>=20
> >
> > We were here before.  You and Martin concluded that "include tinc1c" =
MUST be present
> > in the main module and I said the module namespace is flat so =
'type3' was exported to tinc2
> > even if it was not included in the main module.
>=20
> In my view, this is an additional complexity that buys you nothing.
>=20
>=20
> Does this mean we agree?

I guess so. :-)

> IMO the "belongs-to foo" statement is enough.
> That says "my definitions are for namespace 'foo', and I can access =
all
> definitions in namespace 'foo=92.

All submodules have to be included in the main module so that an =
importing module is aware of them.

>=20
> That way we cannot have 2 definitions of the same thing in different =
submodules,
> or 1 in the main module and 1 in a submodule.

This is not possible anyway (IMO).

>=20
> Why can't a submodule access definitions in the main module?
> What problem does that solve?

None, I think.
=20
>=20
> IMO it is a lot simpler not to have any concept of submodule =
namespaces.

+1

Whenever namespace separation is needed, modules should be used.

Lada

>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> >
> > The fundamental issue is whether a module namespace is a hierarchy =
of submodule namespaces
> > of whether the module namespace is flat and all submodules =
contribute to it.
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > Hi,
> > >
> > > The question about submodules reminded me of our previous debate
> > > on how nested submodules are treated.  I just did a test with
> > > pyang and yangdump-pro.  They do not produce the same results.
> > >
> > >    tinc2     <----  tinc1
> > >                          |
> > >                          + tinc1a
> > >                          |
> > >                          + tinc1b   <-- tinc1c
> > >
> > > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > > included by the main module.
> > >
> > > pyang says this is an error and refuses to even compile tinc2.
> > > I cannot find any text where it says this is an error.
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but =
not by
> > > the module tinc1
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but =
not by
> > > the module tinc1
> > >
> > > yangdump-pro does report an error for using the tinc3a typedef in =
an
> > > external module.  However it does not flag an error when that same =
type
> > > is pulled through within a grouping.  The unexported submodule =
tinc1c is not
> > > treated as an error.
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > > *** /home/andy/modules/tinc1.yang
> > > *** 0 Errors, 0 Warnings
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > > Error: typedef definition for 'tinc1:type3' not found in module =
tinc1
> > > tinc2.yang:19.12: error(250): definition not found
> > >
> > > *** /home/andy/modules/tinc2.yang
> > > *** 1 Errors, 0 Warnings
> > >
> > > Solution:  Need to reach WG consensus on proper behavior and =
update
> > > the appropriate text in YANG 1.1.
> > >
> > >    * Is it an error to have an unexported submodule (IMO, no)
> > >
> > >    * Is it an error to use an unexported definition (yes; seems to =
be
> > > consensus
> > >      on this point)
> > >
> > >     * Is it an error to use an unexported definition if it is used =
in a
> > > grouping
> > >       that is exported?  (IMO, no)
> > >
> > >
> > >
> > > Andy
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May  7 09:09:44 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9731A0825 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiMJ5JEt3-LR for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:09:40 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id E29F21A0823 for <netmod@ietf.org>; Wed,  7 May 2014 09:09:39 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id i17so1301691qcy.8 for <netmod@ietf.org>; Wed, 07 May 2014 09:09:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R8F6XAv0EBFH+Csu9F/Zb5I+7YinKxYXW2Ce/Y3bRds=; b=Y/7SjD6Ok1xIfolcOb0omjRPWbMpOcq9KAArF8Vf8nSWIyAXLwxk+Un1wM7DCcgLlB hjVAjRYGC18rTQVLEFsTI/ovoQim2iZpGbBTqMgaWuZFxa9JYUpXp3466gNZruIPTo+f 70TMKXy1z8dI0IrALiSZZeLuoITDzmfymCwkH+tXxxWA7gI5o/ll7ng9P/uitlHpO1li iqQYf8PHapzo4ZOGHLSL9g2DFq5HnpSt2A8WsCFFg8cTgJF+Ixt7o0xDqTTYG0dCW1us rV6MNzMuq20+7IaYMyxbSvuyy7qB1x3PEjU0hRVjTTuItRVGZdvhcVb8+Z6xhncWqD9S 9fAQ==
X-Gm-Message-State: ALoCoQnJyt0Z+Vnst/GjFcMHA0mI/dM9C7d7kyacTj6pRGACAmAZ/8mRpTW/UOXntKu1o/IfnaBa
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr36211201qgo.25.1399478975481; Wed, 07 May 2014 09:09:35 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 09:09:35 -0700 (PDT)
In-Reply-To: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com> <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz>
Date: Wed, 7 May 2014 09:09:35 -0700
Message-ID: <CABCOCHRVD=F_gSEGeRmYLZ1ahXfkUpJxxih+qmERiTKSeTj2Ug@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c17334345e7f04f8d19789
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XVp4KoSfxwfbRE1Z2qMIMOqcJnA
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:09:42 -0000

--001a11c17334345e7f04f8d19789
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> >
> > IMO, it would suffice to include all submodules in the main module and
> have the belongs-to statements in submodules. Definitions from every
> submodule would be available in the main module as well as in any other
> submodule.
> >
> > I think that including a submodule from another submodule is pretty much
> useless because the main module and all submodules share the same namespace
> in any case.
> >
> >
> > I think I like this idea (!)
> >
> > It has always been my opinion that there is only 1 namespace within a
> module.
> > Submodules provide organization, not namespace partitioning.  Include
> statements
> > within submodules enforce partitioned namespace and lead to strange
> export behavior.
> >
> > But it is not backward-compatible to say include-stmt within a submodule
> is not allowed.
>
> It may remain allowed but not required for making definitions from other
> submodules (and the main module) available. I think this is a compatible
> change.
>

OK.

I still do not agree that all include-stmts need to be in the main module.
IMO it is much more intuitive that they work like C #include (nested
#includes are pulled into the main module).

The value of nested submodules is the ability to sub-divide a sub-component.
The implementation of a submodule should not impact importers (same as in
C).
I think this is also allowed by the change rules in sec 10:


  release-1:

       foo <--- foo-inc

  release-2:

       foo <-- foo-inc   <--- foo-inc-a, foo-inc-b

In C, the foo source file does not need to be touched when
foo-inc is modified.  IMO YANG should work the same way.


Andy



> >
> > We were here before.  You and Martin concluded that "include tinc1c"
> MUST be present
> > in the main module and I said the module namespace is flat so 'type3'
> was exported to tinc2
> > even if it was not included in the main module.
>
> In my view, this is an additional complexity that buys you nothing.
>
> Lada
>
> >
> > The fundamental issue is whether a module namespace is a hierarchy of
> submodule namespaces
> > of whether the module namespace is flat and all submodules contribute to
> it.
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > Hi,
> > >
> > > The question about submodules reminded me of our previous debate
> > > on how nested submodules are treated.  I just did a test with
> > > pyang and yangdump-pro.  They do not produce the same results.
> > >
> > >    tinc2     <----  tinc1
> > >                          |
> > >                          + tinc1a
> > >                          |
> > >                          + tinc1b   <-- tinc1c
> > >
> > > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > > included by the main module.
> > >
> > > pyang says this is an error and refuses to even compile tinc2.
> > > I cannot find any text where it says this is an error.
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not
> by
> > > the module tinc1
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but not
> by
> > > the module tinc1
> > >
> > > yangdump-pro does report an error for using the tinc3a typedef in an
> > > external module.  However it does not flag an error when that same type
> > > is pulled through within a grouping.  The unexported submodule tinc1c
> is not
> > > treated as an error.
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > > *** /home/andy/modules/tinc1.yang
> > > *** 0 Errors, 0 Warnings
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > > Error: typedef definition for 'tinc1:type3' not found in module tinc1
> > > tinc2.yang:19.12: error(250): definition not found
> > >
> > > *** /home/andy/modules/tinc2.yang
> > > *** 1 Errors, 0 Warnings
> > >
> > > Solution:  Need to reach WG consensus on proper behavior and update
> > > the appropriate text in YANG 1.1.
> > >
> > >    * Is it an error to have an unexported submodule (IMO, no)
> > >
> > >    * Is it an error to use an unexported definition (yes; seems to be
> > > consensus
> > >      on this point)
> > >
> > >     * Is it an error to use an unexported definition if it is used in a
> > > grouping
> > >       that is exported?  (IMO, no)
> > >
> > >
> > >
> > > Andy
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c17334345e7f04f8d19789
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 07 May 2014, at 17:25, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka &lt;<a href=3D"mailto:=
lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; IMO, it would suffice to include all submodules in the main module and=
 have the belongs-to statements in submodules. Definitions from every submo=
dule would be available in the main module as well as in any other submodul=
e.<br>

&gt;<br>
&gt; I think that including a submodule from another submodule is pretty mu=
ch useless because the main module and all submodules share the same namesp=
ace in any case.<br>
&gt;<br>
&gt;<br>
&gt; I think I like this idea (!)<br>
&gt;<br>
&gt; It has always been my opinion that there is only 1 namespace within a =
module.<br>
&gt; Submodules provide organization, not namespace partitioning. =A0Includ=
e statements<br>
&gt; within submodules enforce partitioned namespace and lead to strange ex=
port behavior.<br>
&gt;<br>
&gt; But it is not backward-compatible to say include-stmt within a submodu=
le is not allowed.<br>
<br>
It may remain allowed but not required for making definitions from other su=
bmodules (and the main module) available. I think this is a compatible chan=
ge.<br></blockquote><div><br></div><div>OK.</div><div><br></div><div>I stil=
l do not agree that all include-stmts need to be in the main module.</div>
<div>IMO it is much more intuitive that they work like C #include (nested</=
div><div>#includes are pulled into the main module).</div><div><br></div><d=
iv>The value of nested submodules is the ability to sub-divide a sub-compon=
ent.</div>
<div>The implementation of a submodule should not impact importers (same as=
 in C).</div><div>I think this is also allowed by the change rules in sec 1=
0:<br></div><div><br></div><div><br></div><div>=A0 release-1:</div><div><br=
>
</div><div>=A0 =A0 =A0 =A0foo &lt;--- foo-inc</div><div><br></div><div>=A0 =
release-2:</div><div><br></div><div>=A0 =A0 =A0 =A0foo &lt;-- foo-inc =A0 &=
lt;--- foo-inc-a, foo-inc-b</div><div><br></div><div>In C, the foo source f=
ile does not need to be touched when</div>
<div>foo-inc is modified. =A0IMO YANG should work the same way.</div><div><=
br></div><div><br></div><div>Andy</div><div><br></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">

<br>
&gt;<br>
&gt; We were here before. =A0You and Martin concluded that &quot;include ti=
nc1c&quot; MUST be present<br>
&gt; in the main module and I said the module namespace is flat so &#39;typ=
e3&#39; was exported to tinc2<br>
&gt; even if it was not included in the main module.<br>
<br>
In my view, this is an additional complexity that buys you nothing.<br>
<br>
Lada<br>
<br>
&gt;<br>
&gt; The fundamental issue is whether a module namespace is a hierarchy of =
submodule namespaces<br>
&gt; of whether the module namespace is flat and all submodules contribute =
to it.<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; writes:<br>
&gt;<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; The question about submodules reminded me of our previous debate<=
br>
&gt; &gt; on how nested submodules are treated. =A0I just did a test with<b=
r>
&gt; &gt; pyang and yangdump-pro. =A0They do not produce the same results.<=
br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0tinc2 =A0 =A0 &lt;---- =A0tinc1<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1a<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<br>
&gt; &gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+ tinc1b =A0 &=
lt;-- tinc1c<br>
&gt; &gt;<br>
&gt; &gt; Problem: Need to clarify behavior when a submodule (tinc1c) is no=
t<br>
&gt; &gt; included by the main module.<br>
&gt; &gt;<br>
&gt; &gt; pyang says this is an error and refuses to even compile tinc2.<br=
>
&gt; &gt; I cannot find any text where it says this is an error.<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ pyang tinc1.yang<br>
&gt; &gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but=
 not by<br>
&gt; &gt; the module tinc1<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ pyang tinc2.yang<br>
&gt; &gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but=
 not by<br>
&gt; &gt; the module tinc1<br>
&gt; &gt;<br>
&gt; &gt; yangdump-pro does report an error for using the tinc3a typedef in=
 an<br>
&gt; &gt; external module. =A0However it does not flag an error when that s=
ame type<br>
&gt; &gt; is pulled through within a grouping. =A0The unexported submodule =
tinc1c is not<br>
&gt; &gt; treated as an error.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ yangdump-pro tinc1<br>
&gt; &gt; *** /home/andy/modules/tinc1.yang<br>
&gt; &gt; *** 0 Errors, 0 Warnings<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; andy@andy-swdev:~/modules$ yangdump-pro tinc2<br>
&gt; &gt; Error: typedef definition for &#39;tinc1:type3&#39; not found in =
module tinc1<br>
&gt; &gt; tinc2.yang:19.12: error(250): definition not found<br>
&gt; &gt;<br>
&gt; &gt; *** /home/andy/modules/tinc2.yang<br>
&gt; &gt; *** 1 Errors, 0 Warnings<br>
&gt; &gt;<br>
&gt; &gt; Solution: =A0Need to reach WG consensus on proper behavior and up=
date<br>
&gt; &gt; the appropriate text in YANG 1.1.<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0* Is it an error to have an unexported submodule (IMO, no)=
<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0* Is it an error to use an unexported definition (yes; see=
ms to be<br>
&gt; &gt; consensus<br>
&gt; &gt; =A0 =A0 =A0on this point)<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0 * Is it an error to use an unexported definition if it is=
 used in a<br>
&gt; &gt; grouping<br>
&gt; &gt; =A0 =A0 =A0 that is exported? =A0(IMO, no)<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; netmod mailing list<br>
&gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c17334345e7f04f8d19789--


From nobody Wed May  7 09:11:36 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B511A07A6 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY5WW6x9SdPf for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:11:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0651A0377 for <netmod@ietf.org>; Wed,  7 May 2014 09:11:28 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 1DC4B574001; Wed,  7 May 2014 18:11:23 +0200 (CEST)
Date: Wed, 07 May 2014 18:11:21 +0200 (CEST)
Message-Id: <20140507.181121.223853730.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz>
References: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com> <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KPHZChKBjf6iH1L7iS1B7G1zJNs
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:11:34 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDA3IE1heSAy
MDE0LCBhdCAxNzo1MywgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K
PiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBPbiBXZWQsIE1heSA3LCAyMDE0IGF0IDg6MzAgQU0s
IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4gDQo+ID4gT24gMDcg
TWF5IDIwMTQsIGF0IDE3OjI1LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3Jv
dGU6DQo+ID4gDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiBXZWQsIE1heSA3LCAyMDE0
IGF0IDc6NTEgQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4g
PiBIaSwNCj4gPiA+DQo+ID4gPiBJTU8sIGl0IHdvdWxkIHN1ZmZpY2UgdG8gaW5jbHVkZSBhbGwg
c3VibW9kdWxlcyBpbiB0aGUgbWFpbiBtb2R1bGUgYW5kIGhhdmUNCj4gPiA+IHRoZSBiZWxvbmdz
LXRvIHN0YXRlbWVudHMgaW4gc3VibW9kdWxlcy4gRGVmaW5pdGlvbnMgZnJvbSBldmVyeSBzdWJt
b2R1bGUNCj4gPiA+IHdvdWxkIGJlIGF2YWlsYWJsZSBpbiB0aGUgbWFpbiBtb2R1bGUgYXMgd2Vs
bCBhcyBpbiBhbnkgb3RoZXIgc3VibW9kdWxlLg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgdGhhdCBp
bmNsdWRpbmcgYSBzdWJtb2R1bGUgZnJvbSBhbm90aGVyIHN1Ym1vZHVsZSBpcyBwcmV0dHkgbXVj
aA0KPiA+ID4gdXNlbGVzcyBiZWNhdXNlIHRoZSBtYWluIG1vZHVsZSBhbmQgYWxsIHN1Ym1vZHVs
ZXMgc2hhcmUgdGhlIHNhbWUgbmFtZXNwYWNlDQo+ID4gPiBpbiBhbnkgY2FzZS4NCj4gPiA+DQo+
ID4gPg0KPiA+ID4gSSB0aGluayBJIGxpa2UgdGhpcyBpZGVhICghKQ0KPiA+ID4NCj4gPiA+IEl0
IGhhcyBhbHdheXMgYmVlbiBteSBvcGluaW9uIHRoYXQgdGhlcmUgaXMgb25seSAxIG5hbWVzcGFj
ZSB3aXRoaW4gYQ0KPiA+ID4gbW9kdWxlLg0KPiA+ID4gU3VibW9kdWxlcyBwcm92aWRlIG9yZ2Fu
aXphdGlvbiwgbm90IG5hbWVzcGFjZSBwYXJ0aXRpb25pbmcuICBJbmNsdWRlDQo+ID4gPiBzdGF0
ZW1lbnRzDQo+ID4gPiB3aXRoaW4gc3VibW9kdWxlcyBlbmZvcmNlIHBhcnRpdGlvbmVkIG5hbWVz
cGFjZSBhbmQgbGVhZCB0byBzdHJhbmdlIGV4cG9ydA0KPiA+ID4gYmVoYXZpb3IuDQo+ID4gPg0K
PiA+ID4gQnV0IGl0IGlzIG5vdCBiYWNrd2FyZC1jb21wYXRpYmxlIHRvIHNheSBpbmNsdWRlLXN0
bXQgd2l0aGluIGEgc3VibW9kdWxlIGlzDQo+ID4gPiBub3QgYWxsb3dlZC4NCj4gPiANCj4gPiBJ
dCBtYXkgcmVtYWluIGFsbG93ZWQgYnV0IG5vdCByZXF1aXJlZCBmb3IgbWFraW5nIGRlZmluaXRp
b25zIGZyb20gb3RoZXINCj4gPiBzdWJtb2R1bGVzIChhbmQgdGhlIG1haW4gbW9kdWxlKSBhdmFp
bGFibGUuIEkgdGhpbmsgdGhpcyBpcyBhIGNvbXBhdGlibGUNCj4gPiBjaGFuZ2UuDQo+ID4gDQo+
ID4gPg0KPiA+ID4gV2Ugd2VyZSBoZXJlIGJlZm9yZS4gIFlvdSBhbmQgTWFydGluIGNvbmNsdWRl
ZCB0aGF0ICJpbmNsdWRlIHRpbmMxYyIgTVVTVA0KPiA+ID4gYmUgcHJlc2VudA0KPiA+ID4gaW4g
dGhlIG1haW4gbW9kdWxlIGFuZCBJIHNhaWQgdGhlIG1vZHVsZSBuYW1lc3BhY2UgaXMgZmxhdCBz
byAndHlwZTMnIHdhcw0KPiA+ID4gZXhwb3J0ZWQgdG8gdGluYzINCj4gPiA+IGV2ZW4gaWYgaXQg
d2FzIG5vdCBpbmNsdWRlZCBpbiB0aGUgbWFpbiBtb2R1bGUuDQo+ID4gDQo+ID4gSW4gbXkgdmll
dywgdGhpcyBpcyBhbiBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdGhhdCBidXlzIHlvdSBub3RoaW5n
Lg0KPiA+IA0KPiA+IA0KPiA+IERvZXMgdGhpcyBtZWFuIHdlIGFncmVlPw0KPiANCj4gSSBndWVz
cyBzby4gOi0pDQo+IA0KPiA+IElNTyB0aGUgImJlbG9uZ3MtdG8gZm9vIiBzdGF0ZW1lbnQgaXMg
ZW5vdWdoLg0KPiA+IFRoYXQgc2F5cyAibXkgZGVmaW5pdGlvbnMgYXJlIGZvciBuYW1lc3BhY2Ug
J2ZvbycsIGFuZCBJIGNhbiBhY2Nlc3MgYWxsDQo+ID4gZGVmaW5pdGlvbnMgaW4gbmFtZXNwYWNl
ICdmb2/igJkuDQo+IA0KPiBBbGwgc3VibW9kdWxlcyBoYXZlIHRvIGJlIGluY2x1ZGVkIGluIHRo
ZSBtYWluIG1vZHVsZSBzbyB0aGF0IGFuIGltcG9ydGluZw0KPiBtb2R1bGUgaXMgYXdhcmUgb2Yg
dGhlbS4NCj4gDQo+ID4gDQo+ID4gVGhhdCB3YXkgd2UgY2Fubm90IGhhdmUgMiBkZWZpbml0aW9u
cyBvZiB0aGUgc2FtZSB0aGluZyBpbiBkaWZmZXJlbnQNCj4gPiBzdWJtb2R1bGVzLA0KPiA+IG9y
IDEgaW4gdGhlIG1haW4gbW9kdWxlIGFuZCAxIGluIGEgc3VibW9kdWxlLg0KPiANCj4gVGhpcyBp
cyBub3QgcG9zc2libGUgYW55d2F5IChJTU8pLg0KPiANCj4gPiANCj4gPiBXaHkgY2FuJ3QgYSBz
dWJtb2R1bGUgYWNjZXNzIGRlZmluaXRpb25zIGluIHRoZSBtYWluIG1vZHVsZT8NCj4gPiBXaGF0
IHByb2JsZW0gZG9lcyB0aGF0IHNvbHZlPw0KPiANCj4gTm9uZSwgSSB0aGluay4NCj4gIA0KPiA+
IA0KPiA+IElNTyBpdCBpcyBhIGxvdCBzaW1wbGVyIG5vdCB0byBoYXZlIGFueSBjb25jZXB0IG9m
IHN1Ym1vZHVsZSBuYW1lc3BhY2VzLg0KPiANCj4gKzENCj4gDQo+IFdoZW5ldmVyIG5hbWVzcGFj
ZSBzZXBhcmF0aW9uIGlzIG5lZWRlZCwgbW9kdWxlcyBzaG91bGQgYmUgdXNlZC4NCg0KSSBhbSBj
b25mdXNlZC4gICBUaGVyZSBhcmUgbm8gYWRkaXRpb25hbCBuYW1lc3BhY2VzIHRvZGF5IC0ganVz
dCBvbmUsDQppbnRyb2R1Y2VkIGJ5IHRoZSBtb2R1bGUuICBXaGF0IGRpZCB5b3UgYWdyZWUgb24/
DQoNCg0KL21hcnRpbg0K


From nobody Wed May  7 09:16:59 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457181A082B for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8qcmiAmU-Gt for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:16:52 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3541A083E for <netmod@ietf.org>; Wed,  7 May 2014 09:16:46 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0422813F889; Wed,  7 May 2014 18:16:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399479401; bh=JAmg/+y4sntJy4UqVaVxWaEwWV0tutCQ8NwNeoNVXvU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wa77tBA74vfpYIDQ9KL3G/mBhz+7nxw3xLDr6Dgn+z89uXXPnh1jw8qkghKaia61s B0vRhrGRdVj03k+N1GkdSEs8TC2XWhIFG989rMYT9hUv9JQyf6kO5GmwwXtvn3NxK2 TtvmFYyIMbXJWykx8AdOfT7gzM95n14wcI33sLEE=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140507.181121.223853730.mbj@tail-f.com>
Date: Wed, 7 May 2014 18:16:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF662CB1-C5C1-4B8B-9F73-C74DDC717310@nic.cz>
References: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com> <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz> <20140507.181121.223853730.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JShA-7wznv57v2ZAlQwTu6rY4mw
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:16:54 -0000

On 07 May 2014, at 18:11, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>=20
>> On 07 May 2014, at 17:53, Andy Bierman <andy@yumaworks.com> wrote:
>>=20
>>>=20
>>>=20
>>>=20
>>> On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>>>=20
>>> On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>>>> Hi,
>>>>=20
>>>> IMO, it would suffice to include all submodules in the main module =
and have
>>>> the belongs-to statements in submodules. Definitions from every =
submodule
>>>> would be available in the main module as well as in any other =
submodule.
>>>>=20
>>>> I think that including a submodule from another submodule is pretty =
much
>>>> useless because the main module and all submodules share the same =
namespace
>>>> in any case.
>>>>=20
>>>>=20
>>>> I think I like this idea (!)
>>>>=20
>>>> It has always been my opinion that there is only 1 namespace within =
a
>>>> module.
>>>> Submodules provide organization, not namespace partitioning.  =
Include
>>>> statements
>>>> within submodules enforce partitioned namespace and lead to strange =
export
>>>> behavior.
>>>>=20
>>>> But it is not backward-compatible to say include-stmt within a =
submodule is
>>>> not allowed.
>>>=20
>>> It may remain allowed but not required for making definitions from =
other
>>> submodules (and the main module) available. I think this is a =
compatible
>>> change.
>>>=20
>>>>=20
>>>> We were here before.  You and Martin concluded that "include =
tinc1c" MUST
>>>> be present
>>>> in the main module and I said the module namespace is flat so =
'type3' was
>>>> exported to tinc2
>>>> even if it was not included in the main module.
>>>=20
>>> In my view, this is an additional complexity that buys you nothing.
>>>=20
>>>=20
>>> Does this mean we agree?
>>=20
>> I guess so. :-)
>>=20
>>> IMO the "belongs-to foo" statement is enough.
>>> That says "my definitions are for namespace 'foo', and I can access =
all
>>> definitions in namespace 'foo=92.
>>=20
>> All submodules have to be included in the main module so that an =
importing
>> module is aware of them.
>>=20
>>>=20
>>> That way we cannot have 2 definitions of the same thing in different
>>> submodules,
>>> or 1 in the main module and 1 in a submodule.
>>=20
>> This is not possible anyway (IMO).
>>=20
>>>=20
>>> Why can't a submodule access definitions in the main module?
>>> What problem does that solve?
>>=20
>> None, I think.
>>=20
>>>=20
>>> IMO it is a lot simpler not to have any concept of submodule =
namespaces.
>>=20
>> +1
>>=20
>> Whenever namespace separation is needed, modules should be used.
>=20
> I am confused.   There are no additional namespaces today - just one,
> introduced by the module.  What did you agree on?

That =91include=92 statements in a submodule are useless. Because of the =
shared namespace, different submodules cannot define nodes, identities, =
groupings and typedefs with colliding names, no matter whether they use =
include or not.

Lada  =20

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May  7 09:20:15 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AF81A02EA for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1_gtiR1RTvN for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:20:13 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C71A02BE for <netmod@ietf.org>; Wed,  7 May 2014 09:20:12 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3775213F889; Wed,  7 May 2014 18:20:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399479608; bh=Q/HOiOYmESRuRSI1FTUQjdBhFwpa161ttGsBW8lAdw8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=o6V/E5S2WGuMCcCYQ0zgr0QrP4MiMkCFC/Wa/UpB8l1An5mfWzu64wZXd8eWXX1SS jos07kAr3rIe9EbZAxR0PKtuvRnDiuWo8H1/PY/a5h68Dv6g3S+oLQdPuTdxAecNQZ HbGiWUZpEGcCSuW75S+zIZgh/IOcQ+uwvCNQVbhU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHRVD=F_gSEGeRmYLZ1ahXfkUpJxxih+qmERiTKSeTj2Ug@mail.gmail.com>
Date: Wed, 7 May 2014 18:20:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <95506137-4968-48F6-9F63-90F592BE8EF3@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com> <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHRVD=F_gSEGeRmYLZ1ahXfkUpJxxih+qmERiTKSeTj2Ug@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EeY7va8gCEVxZrLYmMs4IrTuAj8
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:20:14 -0000

On 07 May 2014, at 18:09, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>=20
> On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> > Hi,
> >
> > IMO, it would suffice to include all submodules in the main module =
and have the belongs-to statements in submodules. Definitions from every =
submodule would be available in the main module as well as in any other =
submodule.
> >
> > I think that including a submodule from another submodule is pretty =
much useless because the main module and all submodules share the same =
namespace in any case.
> >
> >
> > I think I like this idea (!)
> >
> > It has always been my opinion that there is only 1 namespace within =
a module.
> > Submodules provide organization, not namespace partitioning.  =
Include statements
> > within submodules enforce partitioned namespace and lead to strange =
export behavior.
> >
> > But it is not backward-compatible to say include-stmt within a =
submodule is not allowed.
>=20
> It may remain allowed but not required for making definitions from =
other submodules (and the main module) available. I think this is a =
compatible change.
>=20
> OK.
>=20
> I still do not agree that all include-stmts need to be in the main =
module.
> IMO it is much more intuitive that they work like C #include (nested
> #includes are pulled into the main module).

With no includes in the main module, how do you know which submodules =
are part of the data model? Searching the universe for all submodules =
that belong-to the main module doesn=92t seem very effective.

Lada

>=20
> The value of nested submodules is the ability to sub-divide a =
sub-component.
> The implementation of a submodule should not impact importers (same as =
in C).
> I think this is also allowed by the change rules in sec 10:
>=20
>=20
>   release-1:
>=20
>        foo <--- foo-inc
>=20
>   release-2:
>=20
>        foo <-- foo-inc   <--- foo-inc-a, foo-inc-b
>=20
> In C, the foo source file does not need to be touched when
> foo-inc is modified.  IMO YANG should work the same way.
>=20
>=20
> Andy
>=20
>=20
>=20
> >
> > We were here before.  You and Martin concluded that "include tinc1c" =
MUST be present
> > in the main module and I said the module namespace is flat so =
'type3' was exported to tinc2
> > even if it was not included in the main module.
>=20
> In my view, this is an additional complexity that buys you nothing.
>=20
> Lada
>=20
> >
> > The fundamental issue is whether a module namespace is a hierarchy =
of submodule namespaces
> > of whether the module namespace is flat and all submodules =
contribute to it.
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > Hi,
> > >
> > > The question about submodules reminded me of our previous debate
> > > on how nested submodules are treated.  I just did a test with
> > > pyang and yangdump-pro.  They do not produce the same results.
> > >
> > >    tinc2     <----  tinc1
> > >                          |
> > >                          + tinc1a
> > >                          |
> > >                          + tinc1b   <-- tinc1c
> > >
> > > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > > included by the main module.
> > >
> > > pyang says this is an error and refuses to even compile tinc2.
> > > I cannot find any text where it says this is an error.
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but =
not by
> > > the module tinc1
> > >
> > > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but =
not by
> > > the module tinc1
> > >
> > > yangdump-pro does report an error for using the tinc3a typedef in =
an
> > > external module.  However it does not flag an error when that same =
type
> > > is pulled through within a grouping.  The unexported submodule =
tinc1c is not
> > > treated as an error.
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > > *** /home/andy/modules/tinc1.yang
> > > *** 0 Errors, 0 Warnings
> > >
> > >
> > > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > > Error: typedef definition for 'tinc1:type3' not found in module =
tinc1
> > > tinc2.yang:19.12: error(250): definition not found
> > >
> > > *** /home/andy/modules/tinc2.yang
> > > *** 1 Errors, 0 Warnings
> > >
> > > Solution:  Need to reach WG consensus on proper behavior and =
update
> > > the appropriate text in YANG 1.1.
> > >
> > >    * Is it an error to have an unexported submodule (IMO, no)
> > >
> > >    * Is it an error to use an unexported definition (yes; seems to =
be
> > > consensus
> > >      on this point)
> > >
> > >     * Is it an error to use an unexported definition if it is used =
in a
> > > grouping
> > >       that is exported?  (IMO, no)
> > >
> > >
> > >
> > > Andy
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May  7 09:26:21 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5201B1A0815 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A81tYRowCHOr for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:26:17 -0700 (PDT)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCD1A07EE for <netmod@ietf.org>; Wed,  7 May 2014 09:26:16 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id q108so1301929qgd.41 for <netmod@ietf.org>; Wed, 07 May 2014 09:26:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+MxHBh11lThSZXVNjJs5xgAeJpk3NgKxNTHCihTfK1Q=; b=i5K6TCXpBJqO2F8bXHLzaB6Sfp8zDti9iUkJsbyqdbo75sXJ7DXtWpDfS+UiL0F3vX exosNo2jhiAaUp5zEecOdE6CfKd3tYEzKTHEvLMx4AInH0BWJtcvrgBcxxEQ1utF28kj RFlOwA5MxSnqV6XrAFXAHleGpLjFN7e9rEpk0rGoZR09VB338avAorZAYm6XcUG5w2BR ZL5Fu5vl23PzDHu6wFn/RY9CtX+MwMptbZJ2flXLBQz7dZ7Tbp+6ES0eQAXQSnzw0b1l ew5DkD+gaC/MnLWA342uPfl8S4UwcFRz5WwsRoZoRl42qw9tI4w5gAapaFCvCU7d/jPz qMUQ==
X-Gm-Message-State: ALoCoQkSJgd//VxNr9Lhar8Wez8RYX3HOHCH3ATfFvmCdDSHJzob6PWm/uNEAxpLlUqEQuqKeCoS
MIME-Version: 1.0
X-Received: by 10.140.18.173 with SMTP id 42mr60866494qgf.94.1399479972608; Wed, 07 May 2014 09:26:12 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 09:26:12 -0700 (PDT)
In-Reply-To: <20140507.181121.223853730.mbj@tail-f.com>
References: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com> <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz> <20140507.181121.223853730.mbj@tail-f.com>
Date: Wed, 7 May 2014 09:26:12 -0700
Message-ID: <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary=001a11351cb2a3b4b104f8d1d2ad
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kBHagTT3rdo5fz2QTbgPt_VRCek
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:26:19 -0000

--001a11351cb2a3b4b104f8d1d2ad
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 07 May 2014, at 17:53, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > > On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> > > > Hi,
> > > >
> > > > IMO, it would suffice to include all submodules in the main module
> and have
> > > > the belongs-to statements in submodules. Definitions from every
> submodule
> > > > would be available in the main module as well as in any other
> submodule.
> > > >
> > > > I think that including a submodule from another submodule is pretty
> much
> > > > useless because the main module and all submodules share the same
> namespace
> > > > in any case.
> > > >
> > > >
> > > > I think I like this idea (!)
> > > >
> > > > It has always been my opinion that there is only 1 namespace within a
> > > > module.
> > > > Submodules provide organization, not namespace partitioning.  Include
> > > > statements
> > > > within submodules enforce partitioned namespace and lead to strange
> export
> > > > behavior.
> > > >
> > > > But it is not backward-compatible to say include-stmt within a
> submodule is
> > > > not allowed.
> > >
> > > It may remain allowed but not required for making definitions from
> other
> > > submodules (and the main module) available. I think this is a
> compatible
> > > change.
> > >
> > > >
> > > > We were here before.  You and Martin concluded that "include tinc1c"
> MUST
> > > > be present
> > > > in the main module and I said the module namespace is flat so
> 'type3' was
> > > > exported to tinc2
> > > > even if it was not included in the main module.
> > >
> > > In my view, this is an additional complexity that buys you nothing.
> > >
> > >
> > > Does this mean we agree?
> >
> > I guess so. :-)
> >
> > > IMO the "belongs-to foo" statement is enough.
> > > That says "my definitions are for namespace 'foo', and I can access all
> > > definitions in namespace 'foo'.
> >
> > All submodules have to be included in the main module so that an
> importing
> > module is aware of them.
> >
> > >
> > > That way we cannot have 2 definitions of the same thing in different
> > > submodules,
> > > or 1 in the main module and 1 in a submodule.
> >
> > This is not possible anyway (IMO).
> >
> > >
> > > Why can't a submodule access definitions in the main module?
> > > What problem does that solve?
> >
> > None, I think.
> >
> > >
> > > IMO it is a lot simpler not to have any concept of submodule
> namespaces.
> >
> > +1
> >
> > Whenever namespace separation is needed, modules should be used.
>
> I am confused.   There are no additional namespaces today - just one,
> introduced by the module.  What did you agree on?
>
>
There are 2 issues -- we agree on 1

 1) how to indicate that submodule contents are exported from the main
module
     to external modules?

    a) include must be in main module
    b) include must be in main module or submodule

 2) what definitions are visible within a submodule?

    a) only self and includes
    b) main module, self, and includes

IMO, belongs-to-stmt is enough to declare submodule contents as part of the
main module.
The parser needs to be able to find all submodule, and it can by following
the include-stmts.
An include-stmt does not need to be in the main module for a parser to find
it.




> /martin
>

Andy

--001a11351cb2a3b4b104f8d1d2ad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ladislav Lhotka &lt;<a href=3D"mailto:lhotka=
@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 07 May 2014, at 17:53, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka &lt;<a href=3D"ma=
ilto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On 07 May 2014, at 17:25, Andy Bierman &lt;<a href=3D"mailto:andy=
@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka &lt;<a href=
=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; IMO, it would suffice to include all submodules in the main =
module and have<br>
&gt; &gt; &gt; the belongs-to statements in submodules. Definitions from ev=
ery submodule<br>
&gt; &gt; &gt; would be available in the main module as well as in any othe=
r submodule.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I think that including a submodule from another submodule is=
 pretty much<br>
&gt; &gt; &gt; useless because the main module and all submodules share the=
 same namespace<br>
&gt; &gt; &gt; in any case.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I think I like this idea (!)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; It has always been my opinion that there is only 1 namespace=
 within a<br>
&gt; &gt; &gt; module.<br>
&gt; &gt; &gt; Submodules provide organization, not namespace partitioning.=
 &nbsp;Include<br>
&gt; &gt; &gt; statements<br>
&gt; &gt; &gt; within submodules enforce partitioned namespace and lead to =
strange export<br>
&gt; &gt; &gt; behavior.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; But it is not backward-compatible to say include-stmt within=
 a submodule is<br>
&gt; &gt; &gt; not allowed.<br>
&gt; &gt;<br>
&gt; &gt; It may remain allowed but not required for making definitions fro=
m other<br>
&gt; &gt; submodules (and the main module) available. I think this is a com=
patible<br>
&gt; &gt; change.<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We were here before. &nbsp;You and Martin concluded that &qu=
ot;include tinc1c&quot; MUST<br>
&gt; &gt; &gt; be present<br>
&gt; &gt; &gt; in the main module and I said the module namespace is flat s=
o &#39;type3&#39; was<br>
&gt; &gt; &gt; exported to tinc2<br>
&gt; &gt; &gt; even if it was not included in the main module.<br>
&gt; &gt;<br>
&gt; &gt; In my view, this is an additional complexity that buys you nothin=
g.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Does this mean we agree?<br>
&gt;<br>
&gt; I guess so. :-)<br>
&gt;<br>
&gt; &gt; IMO the &quot;belongs-to foo&quot; statement is enough.<br>
&gt; &gt; That says &quot;my definitions are for namespace &#39;foo&#39;, a=
nd I can access all<br>
&gt; &gt; definitions in namespace &#39;foo&rsquo;.<br>
&gt;<br>
&gt; All submodules have to be included in the main module so that an impor=
ting<br>
&gt; module is aware of them.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; That way we cannot have 2 definitions of the same thing in differ=
ent<br>
&gt; &gt; submodules,<br>
&gt; &gt; or 1 in the main module and 1 in a submodule.<br>
&gt;<br>
&gt; This is not possible anyway (IMO).<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Why can&#39;t a submodule access definitions in the main module?<=
br>
&gt; &gt; What problem does that solve?<br>
&gt;<br>
&gt; None, I think.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; IMO it is a lot simpler not to have any concept of submodule name=
spaces.<br>
&gt;<br>
&gt; +1<br>
&gt;<br>
&gt; Whenever namespace separation is needed, modules should be used.<br>
<br>
I am confused. &nbsp; There are no additional namespaces today - just one,<=
br>
introduced by the module. &nbsp;What did you agree on?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>There are 2 issues -- we agree on 1</div><div><br></=
div><div>&nbsp;1) how to indicate that submodule contents are exported from=
 the main module</div>
<div>&nbsp; &nbsp; &nbsp;to external modules?</div><div><br></div><div>&nbs=
p; &nbsp; a) include must be in main module</div><div>&nbsp; &nbsp; b) incl=
ude must be in main module or submodule</div><div><br></div><div>&nbsp;2) w=
hat definitions are visible within a submodule?</div>
<div><br></div><div>&nbsp; &nbsp; a) only self and includes</div><div>&nbsp=
; &nbsp; b) main module, self, and includes</div><div><br></div><div>IMO, b=
elongs-to-stmt is enough to declare submodule contents as part of the main =
module.</div><div>
The parser needs to be able to find all submodule, and it can by following =
the include-stmts.</div><div>An include-stmt does not need to be in the mai=
n module for a parser to find it.</div><div><br></div><div><br></div><div>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font color=
=3D"#888888">
<br>
/martin<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Andy<=
/div><div class=3D"gmail_extra"><br></div></div>

--001a11351cb2a3b4b104f8d1d2ad--


From nobody Wed May  7 09:31:14 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359081A0396 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:31:10 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSqxB13lxZIU for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:31:07 -0700 (PDT)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by ietfa.amsl.com (Postfix) with ESMTP id EA8EE1A035C for <netmod@ietf.org>; Wed,  7 May 2014 09:31:06 -0700 (PDT)
Received: by mail-qg0-f52.google.com with SMTP id a108so1375665qge.11 for <netmod@ietf.org>; Wed, 07 May 2014 09:31:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xE0r00eKG/kD8CHmpdTDluzjMdqQcNywAW3DoWBxqtI=; b=E9Yy/WEmTnDNU2JxqV9bQwPjPcf4gTx/p63XWxrhmOtha6lPfBqSbbkK8KBTd0h9/Z d0IJY0g34NO2BL9ov6up91CcAwFSOsuPROk5JTK6rtTFK4+PWzrYraR/ZHgxNWfUcGuL aCVYWWZIZty4U9y7rZWJPfrC4VDhlN0dtyKNtNPHmuS+V1TzoOjJTD1vqg1lqkZM8Iru yb1+6OhqPZuXE6jlJpS010I58C3YTPBImL+yrBjkaHBt9lCnoo0iUVMKazatKIWO6cl4 A6hLfoy2qWodMuCPTptsWjwy2gTB9Y24wmvXoLWB9d+tu3pndeCgzW/1mMB8guTp1tfi a+UQ==
X-Gm-Message-State: ALoCoQkfyhfZq4OL/TlqaVeNYtPkxmq8mV2o1pPI/yTXT9OeGJxyOdSGlVeZV6sR46yCUDPLuWmI
MIME-Version: 1.0
X-Received: by 10.224.64.132 with SMTP id e4mr67338150qai.16.1399480262590; Wed, 07 May 2014 09:31:02 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 09:31:02 -0700 (PDT)
In-Reply-To: <95506137-4968-48F6-9F63-90F592BE8EF3@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com> <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHRVD=F_gSEGeRmYLZ1ahXfkUpJxxih+qmERiTKSeTj2Ug@mail.gmail.com> <95506137-4968-48F6-9F63-90F592BE8EF3@nic.cz>
Date: Wed, 7 May 2014 09:31:02 -0700
Message-ID: <CABCOCHTah2x8NWt=8-UL7m3Q6SKs0D1G4_32_+g+h_-25mECnw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c20e7aec183904f8d1e35d
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FT9oDdEGaq29tNV-T-BzPfxXc-Q
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:31:10 -0000

--001a11c20e7aec183904f8d1e35d
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 7, 2014 at 9:20 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 07 May 2014, at 18:09, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Hi,
> > >
> > > IMO, it would suffice to include all submodules in the main module and
> have the belongs-to statements in submodules. Definitions from every
> submodule would be available in the main module as well as in any other
> submodule.
> > >
> > > I think that including a submodule from another submodule is pretty
> much useless because the main module and all submodules share the same
> namespace in any case.
> > >
> > >
> > > I think I like this idea (!)
> > >
> > > It has always been my opinion that there is only 1 namespace within a
> module.
> > > Submodules provide organization, not namespace partitioning.  Include
> statements
> > > within submodules enforce partitioned namespace and lead to strange
> export behavior.
> > >
> > > But it is not backward-compatible to say include-stmt within a
> submodule is not allowed.
> >
> > It may remain allowed but not required for making definitions from other
> submodules (and the main module) available. I think this is a compatible
> change.
> >
> > OK.
> >
> > I still do not agree that all include-stmts need to be in the main
> module.
> > IMO it is much more intuitive that they work like C #include (nested
> > #includes are pulled into the main module).
>
> With no includes in the main module, how do you know which submodules are
> part of the data model? Searching the universe for all submodules that
> belong-to the main module doesn't seem very effective.
>
>

I did not say that.  Of course the module only contains submodules that are
explicitly included.  But a parser is required to follow the include chain.
The parser must process an include-stmt in a submodule (and detect loops).
Of course only the 'found' submodules are parsed.  (It is up to the designer
to make sure the include-chain is complete and no intentional orphan
submodules
exist in the universe ;-)


Lada
>
>
Andy


> >
> > The value of nested submodules is the ability to sub-divide a
> sub-component.
> > The implementation of a submodule should not impact importers (same as
> in C).
> > I think this is also allowed by the change rules in sec 10:
> >
> >
> >   release-1:
> >
> >        foo <--- foo-inc
> >
> >   release-2:
> >
> >        foo <-- foo-inc   <--- foo-inc-a, foo-inc-b
> >
> > In C, the foo source file does not need to be touched when
> > foo-inc is modified.  IMO YANG should work the same way.
> >
> >
> > Andy
> >
> >
> >
> > >
> > > We were here before.  You and Martin concluded that "include tinc1c"
> MUST be present
> > > in the main module and I said the module namespace is flat so 'type3'
> was exported to tinc2
> > > even if it was not included in the main module.
> >
> > In my view, this is an additional complexity that buys you nothing.
> >
> > Lada
> >
> > >
> > > The fundamental issue is whether a module namespace is a hierarchy of
> submodule namespaces
> > > of whether the module namespace is flat and all submodules contribute
> to it.
> > >
> > >
> > > Lada
> > >
> > > Andy
> > >
> > >
> > > Andy Bierman <andy@yumaworks.com> writes:
> > >
> > > > Hi,
> > > >
> > > > The question about submodules reminded me of our previous debate
> > > > on how nested submodules are treated.  I just did a test with
> > > > pyang and yangdump-pro.  They do not produce the same results.
> > > >
> > > >    tinc2     <----  tinc1
> > > >                          |
> > > >                          + tinc1a
> > > >                          |
> > > >                          + tinc1b   <-- tinc1c
> > > >
> > > > Problem: Need to clarify behavior when a submodule (tinc1c) is not
> > > > included by the main module.
> > > >
> > > > pyang says this is an error and refuses to even compile tinc2.
> > > > I cannot find any text where it says this is an error.
> > > >
> > > > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but
> not by
> > > > the module tinc1
> > > >
> > > > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, but
> not by
> > > > the module tinc1
> > > >
> > > > yangdump-pro does report an error for using the tinc3a typedef in an
> > > > external module.  However it does not flag an error when that same
> type
> > > > is pulled through within a grouping.  The unexported submodule
> tinc1c is not
> > > > treated as an error.
> > > >
> > > >
> > > > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > > > *** /home/andy/modules/tinc1.yang
> > > > *** 0 Errors, 0 Warnings
> > > >
> > > >
> > > > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > > > Error: typedef definition for 'tinc1:type3' not found in module tinc1
> > > > tinc2.yang:19.12: error(250): definition not found
> > > >
> > > > *** /home/andy/modules/tinc2.yang
> > > > *** 1 Errors, 0 Warnings
> > > >
> > > > Solution:  Need to reach WG consensus on proper behavior and update
> > > > the appropriate text in YANG 1.1.
> > > >
> > > >    * Is it an error to have an unexported submodule (IMO, no)
> > > >
> > > >    * Is it an error to use an unexported definition (yes; seems to be
> > > > consensus
> > > >      on this point)
> > > >
> > > >     * Is it an error to use an unexported definition if it is used
> in a
> > > > grouping
> > > >       that is exported?  (IMO, no)
> > > >
> > > >
> > > >
> > > > Andy
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c20e7aec183904f8d1e35d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 9:20 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 07 May 2014, at 18:09, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka &lt;<a href=3D"mailto:=
lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 07 May 2014, at 17:25, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka &lt;<a href=3D"ma=
ilto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; IMO, it would suffice to include all submodules in the main modul=
e and have the belongs-to statements in submodules. Definitions from every =
submodule would be available in the main module as well as in any other sub=
module.<br>

&gt; &gt;<br>
&gt; &gt; I think that including a submodule from another submodule is pret=
ty much useless because the main module and all submodules share the same n=
amespace in any case.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I think I like this idea (!)<br>
&gt; &gt;<br>
&gt; &gt; It has always been my opinion that there is only 1 namespace with=
in a module.<br>
&gt; &gt; Submodules provide organization, not namespace partitioning. &nbs=
p;Include statements<br>
&gt; &gt; within submodules enforce partitioned namespace and lead to stran=
ge export behavior.<br>
&gt; &gt;<br>
&gt; &gt; But it is not backward-compatible to say include-stmt within a su=
bmodule is not allowed.<br>
&gt;<br>
&gt; It may remain allowed but not required for making definitions from oth=
er submodules (and the main module) available. I think this is a compatible=
 change.<br>
&gt;<br>
&gt; OK.<br>
&gt;<br>
&gt; I still do not agree that all include-stmts need to be in the main mod=
ule.<br>
&gt; IMO it is much more intuitive that they work like C #include (nested<b=
r>
&gt; #includes are pulled into the main module).<br>
<br>
With no includes in the main module, how do you know which submodules are p=
art of the data model? Searching the universe for all submodules that belon=
g-to the main module doesn&rsquo;t seem very effective.<br>
<br></blockquote><div><br></div><div><br></div><div>I did not say that. &nb=
sp;Of course the module only contains submodules that are</div><div>explici=
tly included. &nbsp;But a parser is required to follow the include chain.</=
div><div>
The parser must process an include-stmt in a submodule (and detect loops).<=
/div><div>Of course only the &#39;found&#39; submodules are parsed. &nbsp;(=
It is up to the designer</div><div>to make sure the include-chain is comple=
te and no intentional orphan submodules</div>
<div>exist in the universe ;-)</div><div><br></div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
Lada<br>
<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
&gt;<br>
&gt; The value of nested submodules is the ability to sub-divide a sub-comp=
onent.<br>
&gt; The implementation of a submodule should not impact importers (same as=
 in C).<br>
&gt; I think this is also allowed by the change rules in sec 10:<br>
&gt;<br>
&gt;<br>
&gt; &nbsp; release-1:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;foo &lt;--- foo-inc<br>
&gt;<br>
&gt; &nbsp; release-2:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp;foo &lt;-- foo-inc &nbsp; &lt;--- foo-inc-a=
, foo-inc-b<br>
&gt;<br>
&gt; In C, the foo source file does not need to be touched when<br>
&gt; foo-inc is modified. &nbsp;IMO YANG should work the same way.<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; We were here before. &nbsp;You and Martin concluded that &quot;in=
clude tinc1c&quot; MUST be present<br>
&gt; &gt; in the main module and I said the module namespace is flat so &#3=
9;type3&#39; was exported to tinc2<br>
&gt; &gt; even if it was not included in the main module.<br>
&gt;<br>
&gt; In my view, this is an additional complexity that buys you nothing.<br=
>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; The fundamental issue is whether a module namespace is a hierarch=
y of submodule namespaces<br>
&gt; &gt; of whether the module namespace is flat and all submodules contri=
bute to it.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Lada<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaw=
orks.com</a>&gt; writes:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The question about submodules reminded me of our previous de=
bate<br>
&gt; &gt; &gt; on how nested submodules are treated. &nbsp;I just did a tes=
t with<br>
&gt; &gt; &gt; pyang and yangdump-pro. &nbsp;They do not produce the same r=
esults.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp;tinc2 &nbsp; &nbsp; &lt;---- &nbsp;tinc1<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp;+ tinc1a<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp;+ tinc1b &nbsp; &lt;-- tinc1c<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Problem: Need to clarify behavior when a submodule (tinc1c) =
is not<br>
&gt; &gt; &gt; included by the main module.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; pyang says this is an error and refuses to even compile tinc=
2.<br>
&gt; &gt; &gt; I cannot find any text where it says this is an error.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; andy@andy-swdev:~/modules$ pyang tinc1.yang<br>
&gt; &gt; &gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b=
, but not by<br>
&gt; &gt; &gt; the module tinc1<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; andy@andy-swdev:~/modules$ pyang tinc2.yang<br>
&gt; &gt; &gt; tinc1b.yang:4: error: submodule tinc1c is included by tinc1b=
, but not by<br>
&gt; &gt; &gt; the module tinc1<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; yangdump-pro does report an error for using the tinc3a typed=
ef in an<br>
&gt; &gt; &gt; external module. &nbsp;However it does not flag an error whe=
n that same type<br>
&gt; &gt; &gt; is pulled through within a grouping. &nbsp;The unexported su=
bmodule tinc1c is not<br>
&gt; &gt; &gt; treated as an error.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; andy@andy-swdev:~/modules$ yangdump-pro tinc1<br>
&gt; &gt; &gt; *** /home/andy/modules/tinc1.yang<br>
&gt; &gt; &gt; *** 0 Errors, 0 Warnings<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; andy@andy-swdev:~/modules$ yangdump-pro tinc2<br>
&gt; &gt; &gt; Error: typedef definition for &#39;tinc1:type3&#39; not foun=
d in module tinc1<br>
&gt; &gt; &gt; tinc2.yang:19.12: error(250): definition not found<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; *** /home/andy/modules/tinc2.yang<br>
&gt; &gt; &gt; *** 1 Errors, 0 Warnings<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Solution: &nbsp;Need to reach WG consensus on proper behavio=
r and update<br>
&gt; &gt; &gt; the appropriate text in YANG 1.1.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp;* Is it an error to have an unexported submodul=
e (IMO, no)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp;* Is it an error to use an unexported definitio=
n (yes; seems to be<br>
&gt; &gt; &gt; consensus<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;on this point)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; * Is it an error to use an unexported definiti=
on if it is used in a<br>
&gt; &gt; &gt; grouping<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; that is exported? &nbsp;(IMO, no)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Andy<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; netmod mailing list<br>
&gt; &gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; &gt; PGP Key ID: E74E8C0C<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c20e7aec183904f8d1e35d--


From nobody Wed May  7 09:44:24 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EDA1A07B9 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_41=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejKK8rp1QrX7 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:44:19 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA21A03BD for <netmod@ietf.org>; Wed,  7 May 2014 09:44:19 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 86B9413F686; Wed,  7 May 2014 18:44:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399481054; bh=mlVq+1dscbgbQQnH8sjB+0+SMDCs/ZF7hD2B04MVIL8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yHQrn6G9EpFzM4Dq7cGTSZpf3MtZCexd9EsmcKKEYkC3NITVL29kwr1spfHQS2KYV N44vRcJdRto227FvkHOEwhUzHVlEdGYt7fcuQWQtkvDiwQVI9FH1qjW0hKd0l8nZHE hN4IcpSKgtzc32iNrFV1wbc16oYqRT0aUBCbiw0Y=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHTah2x8NWt=8-UL7m3Q6SKs0D1G4_32_+g+h_-25mECnw@mail.gmail.com>
Date: Wed, 7 May 2014 18:44:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <77B380E2-8272-4015-A2E8-7B952769D824@nic.cz>
References: <CABCOCHSKFDARxNg7AQdXXjWqWb7rZ2P+2DXqbAv3uHK1eM50fA@mail.gmail.com> <m2ha51d4l7.fsf@nic.cz> <CABCOCHTAU00o=gGKOLgN4PyxCGcEyNuSivthzv_ZY1cw+C7LAg@mail.gmail.com> <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHRVD=F_gSEGeRmYLZ1ahXfkUpJxxih+qmERiTKSeTj2Ug@mail.gmail.com> <95506137-4968-48F6-9F63-90F592BE8EF3@nic.cz> <CABCOCHTah2x8NWt=8-UL7m3Q6SKs0D1G4_32_+g+h_-25mECnw@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a0UJ2kbIzV3VsLzbG6CdZO3Zy2I
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:44:21 -0000

On 07 May 2014, at 18:31, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Wed, May 7, 2014 at 9:20 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>=20
> On 07 May 2014, at 18:09, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> >
> > On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> > > Hi,
> > >
> > > IMO, it would suffice to include all submodules in the main module =
and have the belongs-to statements in submodules. Definitions from every =
submodule would be available in the main module as well as in any other =
submodule.
> > >
> > > I think that including a submodule from another submodule is =
pretty much useless because the main module and all submodules share the =
same namespace in any case.
> > >
> > >
> > > I think I like this idea (!)
> > >
> > > It has always been my opinion that there is only 1 namespace =
within a module.
> > > Submodules provide organization, not namespace partitioning.  =
Include statements
> > > within submodules enforce partitioned namespace and lead to =
strange export behavior.
> > >
> > > But it is not backward-compatible to say include-stmt within a =
submodule is not allowed.
> >
> > It may remain allowed but not required for making definitions from =
other submodules (and the main module) available. I think this is a =
compatible change.
> >
> > OK.
> >
> > I still do not agree that all include-stmts need to be in the main =
module.
> > IMO it is much more intuitive that they work like C #include (nested
> > #includes are pulled into the main module).
>=20
> With no includes in the main module, how do you know which submodules =
are part of the data model? Searching the universe for all submodules =
that belong-to the main module doesn=92t seem very effective.
>=20
>=20
>=20
> I did not say that.  Of course the module only contains submodules =
that are
> explicitly included.  But a parser is required to follow the include =
chain.
> The parser must process an include-stmt in a submodule (and detect =
loops).
> Of course only the 'found' submodules are parsed.  (It is up to the =
designer
> to make sure the include-chain is complete and no intentional orphan =
submodules
> exist in the universe ;-)

I am not sure what you actually propose. Could you summarise it? Which =
statements would be used and where?

FWIW, my proposal is to make the submodule logic extremely simple: only =
a single level of submodules and references in both directions via =
=91include=92 in the main module and =91belongs-to=92 in the submodule. =
Essentially, an =91include foo;=92 in the main module means the same as =
pasting the submodule contents in that place.

Subdividing a submodule is still possible, only the main module will =
have two includes instead of one.

Lada=20

>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
> >
> > The value of nested submodules is the ability to sub-divide a =
sub-component.
> > The implementation of a submodule should not impact importers (same =
as in C).
> > I think this is also allowed by the change rules in sec 10:
> >
> >
> >   release-1:
> >
> >        foo <--- foo-inc
> >
> >   release-2:
> >
> >        foo <-- foo-inc   <--- foo-inc-a, foo-inc-b
> >
> > In C, the foo source file does not need to be touched when
> > foo-inc is modified.  IMO YANG should work the same way.
> >
> >
> > Andy
> >
> >
> >
> > >
> > > We were here before.  You and Martin concluded that "include =
tinc1c" MUST be present
> > > in the main module and I said the module namespace is flat so =
'type3' was exported to tinc2
> > > even if it was not included in the main module.
> >
> > In my view, this is an additional complexity that buys you nothing.
> >
> > Lada
> >
> > >
> > > The fundamental issue is whether a module namespace is a hierarchy =
of submodule namespaces
> > > of whether the module namespace is flat and all submodules =
contribute to it.
> > >
> > >
> > > Lada
> > >
> > > Andy
> > >
> > >
> > > Andy Bierman <andy@yumaworks.com> writes:
> > >
> > > > Hi,
> > > >
> > > > The question about submodules reminded me of our previous debate
> > > > on how nested submodules are treated.  I just did a test with
> > > > pyang and yangdump-pro.  They do not produce the same results.
> > > >
> > > >    tinc2     <----  tinc1
> > > >                          |
> > > >                          + tinc1a
> > > >                          |
> > > >                          + tinc1b   <-- tinc1c
> > > >
> > > > Problem: Need to clarify behavior when a submodule (tinc1c) is =
not
> > > > included by the main module.
> > > >
> > > > pyang says this is an error and refuses to even compile tinc2.
> > > > I cannot find any text where it says this is an error.
> > > >
> > > > andy@andy-swdev:~/modules$ pyang tinc1.yang
> > > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, =
but not by
> > > > the module tinc1
> > > >
> > > > andy@andy-swdev:~/modules$ pyang tinc2.yang
> > > > tinc1b.yang:4: error: submodule tinc1c is included by tinc1b, =
but not by
> > > > the module tinc1
> > > >
> > > > yangdump-pro does report an error for using the tinc3a typedef =
in an
> > > > external module.  However it does not flag an error when that =
same type
> > > > is pulled through within a grouping.  The unexported submodule =
tinc1c is not
> > > > treated as an error.
> > > >
> > > >
> > > > andy@andy-swdev:~/modules$ yangdump-pro tinc1
> > > > *** /home/andy/modules/tinc1.yang
> > > > *** 0 Errors, 0 Warnings
> > > >
> > > >
> > > > andy@andy-swdev:~/modules$ yangdump-pro tinc2
> > > > Error: typedef definition for 'tinc1:type3' not found in module =
tinc1
> > > > tinc2.yang:19.12: error(250): definition not found
> > > >
> > > > *** /home/andy/modules/tinc2.yang
> > > > *** 1 Errors, 0 Warnings
> > > >
> > > > Solution:  Need to reach WG consensus on proper behavior and =
update
> > > > the appropriate text in YANG 1.1.
> > > >
> > > >    * Is it an error to have an unexported submodule (IMO, no)
> > > >
> > > >    * Is it an error to use an unexported definition (yes; seems =
to be
> > > > consensus
> > > >      on this point)
> > > >
> > > >     * Is it an error to use an unexported definition if it is =
used in a
> > > > grouping
> > > >       that is exported?  (IMO, no)
> > > >
> > > >
> > > >
> > > > Andy
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May  7 09:46:56 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7E1A07B9 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iBtUsRhKZlD for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 09:46:51 -0700 (PDT)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id D1AC11A0385 for <netmod@ietf.org>; Wed,  7 May 2014 09:46:50 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id j5so1377394qga.0 for <netmod@ietf.org>; Wed, 07 May 2014 09:46:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wqiXzYoIrhgA6n4cYp9jRNqYGA6vRPSJnUGcS4e8Nm8=; b=dbdrKaOPxJSac2gTPI8RxFzd/nKawCRqei2bt45z+8tV7HIvCrf/96uUgDn0onTQnx NvMI83nHeCZD3VwMWrF+/EOSTrzmTy/3fiWYqBkKdozKc+tOMs+GpWKc1BW5TplDiPaZ S2cz2WVxCBP2xmZT+ItxASb7R+/fAsHL8/Czr6Kd2ZvHeZnTjqHLnzGu9nJACLZAkI2B xTqp7h1ccrWxSPm8au1Cz9b+RN3c6QXexa4wVTRuHhjxHI8Bf2lAhOotbKF87Db4ArJp WPRdMjEkehT2332y6j8NQduIxOYa78MG42f4vbCoZiW+hA75a/arSTwtjSF5ke4UzmX/ BkXQ==
X-Gm-Message-State: ALoCoQlYflENmj37RbxH+t90GXfuvqiAPrRh9HMdeHlTN6UHvpGF3hK+KkQilLmWxxm5MFAw7fDm
MIME-Version: 1.0
X-Received: by 10.140.92.37 with SMTP id a34mr6236023qge.91.1399481206379; Wed, 07 May 2014 09:46:46 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 09:46:46 -0700 (PDT)
In-Reply-To: <BF662CB1-C5C1-4B8B-9F73-C74DDC717310@nic.cz>
References: <1FC108F8-FA4A-42AB-A0BC-44F2AF178DF6@nic.cz> <CABCOCHTNQyUjw7GTpnjF+S_j4xAND2o-23MEfEKY9y5bn1mX_Q@mail.gmail.com> <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz> <20140507.181121.223853730.mbj@tail-f.com> <BF662CB1-C5C1-4B8B-9F73-C74DDC717310@nic.cz>
Date: Wed, 7 May 2014 09:46:46 -0700
Message-ID: <CABCOCHQDUG1u1yF=+NTYdC7M=TxRO=1M5DzAhqJXOf_f+54JuA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a1139baf22d2d5304f8d21cef
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/p2TD58c3nchS7oJNZCn8vWjuyO4
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 16:46:53 -0000

--001a1139baf22d2d5304f8d21cef
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 7, 2014 at 9:16 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 07 May 2014, at 18:11, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>
> >> On 07 May 2014, at 17:53, Andy Bierman <andy@yumaworks.com> wrote:
> >>
> >>>
> >>>
> >>>
> >>> On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>>
> >>> On 07 May 2014, at 17:25, Andy Bierman <andy@yumaworks.com> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz>
> wrote:
> >>>> Hi,
> >>>>
> >>>> IMO, it would suffice to include all submodules in the main module
> and have
> >>>> the belongs-to statements in submodules. Definitions from every
> submodule
> >>>> would be available in the main module as well as in any other
> submodule.
> >>>>
> >>>> I think that including a submodule from another submodule is pretty
> much
> >>>> useless because the main module and all submodules share the same
> namespace
> >>>> in any case.
> >>>>
> >>>>
> >>>> I think I like this idea (!)
> >>>>
> >>>> It has always been my opinion that there is only 1 namespace within a
> >>>> module.
> >>>> Submodules provide organization, not namespace partitioning.  Include
> >>>> statements
> >>>> within submodules enforce partitioned namespace and lead to strange
> export
> >>>> behavior.
> >>>>
> >>>> But it is not backward-compatible to say include-stmt within a
> submodule is
> >>>> not allowed.
> >>>
> >>> It may remain allowed but not required for making definitions from
> other
> >>> submodules (and the main module) available. I think this is a
> compatible
> >>> change.
> >>>
> >>>>
> >>>> We were here before.  You and Martin concluded that "include tinc1c"
> MUST
> >>>> be present
> >>>> in the main module and I said the module namespace is flat so 'type3'
> was
> >>>> exported to tinc2
> >>>> even if it was not included in the main module.
> >>>
> >>> In my view, this is an additional complexity that buys you nothing.
> >>>
> >>>
> >>> Does this mean we agree?
> >>
> >> I guess so. :-)
> >>
> >>> IMO the "belongs-to foo" statement is enough.
> >>> That says "my definitions are for namespace 'foo', and I can access all
> >>> definitions in namespace 'foo'.
> >>
> >> All submodules have to be included in the main module so that an
> importing
> >> module is aware of them.
> >>
> >>>
> >>> That way we cannot have 2 definitions of the same thing in different
> >>> submodules,
> >>> or 1 in the main module and 1 in a submodule.
> >>
> >> This is not possible anyway (IMO).
> >>
> >>>
> >>> Why can't a submodule access definitions in the main module?
> >>> What problem does that solve?
> >>
> >> None, I think.
> >>
> >>>
> >>> IMO it is a lot simpler not to have any concept of submodule
> namespaces.
> >>
> >> +1
> >>
> >> Whenever namespace separation is needed, modules should be used.
> >
> > I am confused.   There are no additional namespaces today - just one,
> > introduced by the module.  What did you agree on?
>
> That 'include' statements in a submodule are useless. Because of the
> shared namespace, different submodules cannot define nodes, identities,
> groupings and typedefs with colliding names, no matter whether they use
> include or not.
>
>
They are not useless, they are misused.
They are needed to find all the files that are part of the module namespace.
They can be nested and still serve this purpose.

I agree that include-stmt just gets in the way and makes YANG much less
useful
with current submodule restrictions.

   belongs-to foo { prefix foo; }

It is absolutely clear anywhere foo:some-def is used what is intended,
so there is no need to list all the accessed submodules.

Use of include-stmt to find files is mandatory, but use within a submodule
to access the module namespace should not be required.

A flat namespace would mean that including different versions of the same
submodule within the module namespace would be an error.  It is currently
possible with nested include-stmts (include by revision is just as awful
as import by revision).





Lada
>
>
> >
> > /martin
>
>
Andy

--001a1139baf22d2d5304f8d21cef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 7, 2014 at 9:16 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 07 May 2014, at 18:11, Martin Bjorklund &lt;<a href=3D"mailto:mbj@tail-f=
.com">mbj@tail-f.com</a>&gt; wrote:<br>
<br>
&gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>=
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 07 May 2014, at 17:53, Andy Bierman &lt;<a href=3D"mailto:andy@=
yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Wed, May 7, 2014 at 8:30 AM, Ladislav Lhotka &lt;<a href=3D=
"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 07 May 2014, at 17:25, Andy Bierman &lt;<a href=3D"mailto:a=
ndy@yumaworks.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Wed, May 7, 2014 at 7:51 AM, Ladislav Lhotka &lt;<a hre=
f=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; IMO, it would suffice to include all submodules in the mai=
n module and have<br>
&gt;&gt;&gt;&gt; the belongs-to statements in submodules. Definitions from =
every submodule<br>
&gt;&gt;&gt;&gt; would be available in the main module as well as in any ot=
her submodule.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I think that including a submodule from another submodule =
is pretty much<br>
&gt;&gt;&gt;&gt; useless because the main module and all submodules share t=
he same namespace<br>
&gt;&gt;&gt;&gt; in any case.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I think I like this idea (!)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; It has always been my opinion that there is only 1 namespa=
ce within a<br>
&gt;&gt;&gt;&gt; module.<br>
&gt;&gt;&gt;&gt; Submodules provide organization, not namespace partitionin=
g. &nbsp;Include<br>
&gt;&gt;&gt;&gt; statements<br>
&gt;&gt;&gt;&gt; within submodules enforce partitioned namespace and lead t=
o strange export<br>
&gt;&gt;&gt;&gt; behavior.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; But it is not backward-compatible to say include-stmt with=
in a submodule is<br>
&gt;&gt;&gt;&gt; not allowed.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It may remain allowed but not required for making definitions =
from other<br>
&gt;&gt;&gt; submodules (and the main module) available. I think this is a =
compatible<br>
&gt;&gt;&gt; change.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; We were here before. &nbsp;You and Martin concluded that &=
quot;include tinc1c&quot; MUST<br>
&gt;&gt;&gt;&gt; be present<br>
&gt;&gt;&gt;&gt; in the main module and I said the module namespace is flat=
 so &#39;type3&#39; was<br>
&gt;&gt;&gt;&gt; exported to tinc2<br>
&gt;&gt;&gt;&gt; even if it was not included in the main module.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In my view, this is an additional complexity that buys you not=
hing.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Does this mean we agree?<br>
&gt;&gt;<br>
&gt;&gt; I guess so. :-)<br>
&gt;&gt;<br>
&gt;&gt;&gt; IMO the &quot;belongs-to foo&quot; statement is enough.<br>
&gt;&gt;&gt; That says &quot;my definitions are for namespace &#39;foo&#39;=
, and I can access all<br>
&gt;&gt;&gt; definitions in namespace &#39;foo&rsquo;.<br>
&gt;&gt;<br>
&gt;&gt; All submodules have to be included in the main module so that an i=
mporting<br>
&gt;&gt; module is aware of them.<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; That way we cannot have 2 definitions of the same thing in dif=
ferent<br>
&gt;&gt;&gt; submodules,<br>
&gt;&gt;&gt; or 1 in the main module and 1 in a submodule.<br>
&gt;&gt;<br>
&gt;&gt; This is not possible anyway (IMO).<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Why can&#39;t a submodule access definitions in the main modul=
e?<br>
&gt;&gt;&gt; What problem does that solve?<br>
&gt;&gt;<br>
&gt;&gt; None, I think.<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; IMO it is a lot simpler not to have any concept of submodule n=
amespaces.<br>
&gt;&gt;<br>
&gt;&gt; +1<br>
&gt;&gt;<br>
&gt;&gt; Whenever namespace separation is needed, modules should be used.<b=
r>
&gt;<br>
&gt; I am confused. &nbsp; There are no additional namespaces today - just =
one,<br>
&gt; introduced by the module. &nbsp;What did you agree on?<br>
<br>
That &lsquo;include&rsquo; statements in a submodule are useless. Because o=
f the shared namespace, different submodules cannot define nodes, identitie=
s, groupings and typedefs with colliding names, no matter whether they use =
include or not.<br>

<br></blockquote><div><br></div><div>They are not useless, they are misused=
.</div><div>They are needed to find all the files that are part of the modu=
le namespace.</div><div>They can be nested and still serve this purpose.</d=
iv>
<div><br></div><div>I agree that include-stmt just gets in the way and make=
s YANG much less useful</div><div>with current submodule restrictions.</div=
><div><br></div><div>&nbsp; &nbsp;belongs-to foo { prefix foo; }</div><div>=
<br></div>
<div>It is absolutely clear anywhere foo:some-def is used what is intended,=
</div><div>so there is no need to list all the accessed submodules.</div><d=
iv><br></div><div>Use of include-stmt to find files is mandatory, but use w=
ithin a submodule</div>
<div>to access the module namespace should not be required.</div><div><br><=
/div><div>A flat namespace would mean that including different versions of =
the same</div><div>submodule within the module namespace would be an error.=
 &nbsp;It is currently</div>
<div>possible with nested include-stmts (include by revision is just as awf=
ul</div><div>as import by revision).</div><div><br></div><div><br></div><di=
v><br></div><div><br></div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Lada&nbsp;<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;<br>
&gt;<br>
&gt; /martin<br>
<br></blockquote><div><br></div><div>Andy</div><div><br></div></div></div><=
/div>

--001a1139baf22d2d5304f8d21cef--


From nobody Wed May  7 13:16:36 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778571A0398 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 13:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.151
X-Spam-Level: 
X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHYUz7Kz3fO4 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 13:16:26 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id A39901A02BD for <netmod@ietf.org>; Wed,  7 May 2014 13:16:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19078; q=dns/txt; s=iport; t=1399493781; x=1400703381; h=from:to:subject:date:message-id:mime-version; bh=DnMd3FFljsnX02YwzhIUJ0EzIXw55mo9VRfaEbbyifI=; b=LqenCv4uEsRKREXXvLx8ErKS23BmgKrIEtXB6g9J+Jp3thFuU0HBo5yZ ot4qcUU7mh0nw/WfBUaQpx36Xdcuymcn3ba7HStlFM+p9RaO6cUMYaS/B 33lLMkZ57C4LgjsJqPyO6XlkZxueoLYL+e2CV9H+rylYO563tz8vI/NU2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYFAJyTalOtJA2H/2dsb2JhbABagkJET1i8IYh+AYEdFnSCJwEELUUZASpWJgEEGxOIJg2bOrRUF44hg2KBFQSsMoM0bQEBgUA
X-IronPort-AV: E=Sophos;i="4.97,1006,1389744000";  d="scan'208,217";a="41874154"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP; 07 May 2014 20:16:20 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s47KGKZg020334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Wed, 7 May 2014 20:16:20 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 7 May 2014 15:16:20 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: YANG 1.1 Key Flexibility
Thread-Index: Ac9qLz6zmZUfl/5JQ8q4qF/+Vawjfg==
Date: Wed, 7 May 2014 20:16:19 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.222.228]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AAF484xmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/POh_i4JAFivZTliHYB3kSa_OzEk
Subject: [netmod] YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 20:16:29 -0000

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAF484xmbalnx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This is related to the restrictions on how keys can be specified for lists =
in YANG 1.0. I've listed two examples we've run up against where we hit lim=
itations, and the extensions that could be made to support these use cases =
(which have some overlap).



Issue 1:



The elements of a subcontainer cannot be used as part of a key. In particul=
ar, take the case where a container with two elements is used as a data ele=
ment in some cases, but needs to be used as a key in others.



grouping lacp-system-id-group {

  container lacp-system-id {

    leaf id  { type uint16; mandatory true; }

    leaf mac { type yang:mac-address; mandatory true; }

  }

}



This can be done in Yang 1.0 is to re-define the contents of the grouping d=
irectly in the list (or to use a grouping-within-the grouping).



list mc-lag-rgs {

  key "system-id system-mac";

 leaf id  { type uint16; mandatory true; }

  leaf mac { type yang:mac-address; mandatory true; }



  [...]

}



Issue 2:



A list entry may have a key which is a union; i.e. it is indexed by a singl=
e value which is one of multiple types. However, a YANG union is not always=
 sufficient to model a choice between a set of types.



Take the following case for example:



choice maintenance-domain-identifier {

  leaf host { type inet:host; }

  leaf id   { type hex-string; }

  leaf name { type string; }

}



These strings can be overlapping, so this cannot be represented as a union.



There doesn't seem to be a way to use this as a key in Yang 1.0, without lo=
sing some typing information or inventing explicit invalid values (although=
 Y09 could help with this to some extent -- see below).



Solution A:



Support keys within subcontainers. This brings the "key" statement in line =
with the "unique" statement, but doesn't necessarily mean there's any need =
to change the properties that are required of keys (e.g. they could still b=
e mandatory within the list; though if Y09 is accepted this would be more f=
lexible -- see Solution C).



This solve the example in "Issue 1", which becomes:



list mc-lag-rgs {

  key "lacp-system-id/id lacp-system-id/mac";

  uses lacp-system-id-group;



  [...]

}



Solution B:



Support non-leaf nodes (in particular container/choice) as keys. The comple=
xity of the key type could be restricted (e.g. requiring that all leaves (o=
r all leaves in all case statements) are mandatory, and that there there is=
 only one level of hierarchy below the node selected as a key), or it could=
 simply be taken as shorthand for Solution A for all the leaves (potentiall=
y in conjunction with Y09 to allow non-mandatory leaves).



Supporting the container as a key would solve issue 1, and supporting the c=
hoice as a key would solve issue 2.



Relationship with Y09:



Y09<http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-9> tra=
cks support for non-mandatory keys -- this has particular uses in combinati=
on with Solution A above, as it allows more flexibility in the leaves that =
can be used as part of the key.



For example, Issue 2 can be modelled as follows using just Y09 if the leave=
s are made entries directly in the list:



list maintenance-domains {

  key "host id name";

  leaf host { type inet:host;  mandatory false; }

  leaf id   { type hex-string; mandatory false; }

  leaf name { type string;     mandatory false; }



  // Rule to ensure exactly one of the above is specified

  must "count(host) + count(id) + count(name) =3D 1";

}



However, in conjunction with solution A, instead this could be modelled as =
follows (which allows the choice statement to be re-used):



list maintenance-domains {

  key "maintenance-domain-identifier/host/host "

    + "maintenance-domain-identifier/id/id "

    + "maintenance-domain-identifier/string/string";

  choice maintenance-domain-identifier {

    mandatory true;

    leaf host { type inet:host; }

    leaf id   { type hex-string; }

    leaf name { type string; }

  }

}



Further notes on Y09:



-    Is there a reason that even a single key has to be mandatory, rather t=
han considering its absence to be an extension of its value space?

-    Presumably keys should be mandatory by default for compatibility with =
YANG 1.0? (i.e. using "mandatory false;" to override.)

-    The restriction on having an "empty" leaf as part of a key should pres=
umably also be lifted if Y09 is accepted?



--_000_013A9B371AC6DF4C8AD261897D8F243E10AAF484xmbalnx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:"Courier New";
	mso-fareast-language:EN-US;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1839538602;
	mso-list-type:hybrid;
	mso-list-template-ids:-545503744 -1729887452 134807555 134807557 134807553=
 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:3;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:23.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Calibri;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:59.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:95.25pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:131.25pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:167.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:203.25pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:239.25pt;
	text-indent:-18.0pt;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:275.25pt;
	text-indent:-18.0pt;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:311.25pt;
	text-indent:-18.0pt;
	font-family:Wingdings;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">This is related to the restrictions on how keys c=
an be specified for lists in YANG 1.0. I've listed two examples we've run u=
p against where we hit limitations, and the extensions that could be made t=
o support these use cases (which have
 some overlap).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Issue 1:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The elements of a subcontainer cannot be used as =
part of a key. In particular, take the case where a container with two elem=
ents is used as a data element in some cases, but needs to be used as a key=
 in others.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">grouping lacp-system-id-group {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; container lacp-system-id {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf id&nbsp; { type uint16; m=
andatory true; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; leaf mac { type yang:mac-addre=
ss; mandatory true; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This can be done in Yang 1.0 is to re-define the =
contents of the grouping directly in the list (or to use a grouping-within-=
the grouping).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">list mc-lag-rgs {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; key &quot;system-id system-mac&quot;;<o:p>=
</o:p></p>
<p class=3D"MsoPlainText">&nbsp;leaf id&nbsp; { type uint16; mandatory true=
; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf mac { type yang:mac-address; mandator=
y true; }<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp; [&#8230;]<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Issue 2:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">A list entry may have a key which is a union; i.e=
. it is indexed by a single value which is one of multiple types. However, =
a YANG union is not always sufficient to model a choice between a set of ty=
pes.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Take the following case for example:<o:p></o:p></=
p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">choice maintenance-domain-identifier {<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">&nbsp; leaf host { type inet:host; }<o:p></o:p></=
p>
<p class=3D"MsoPlainText">&nbsp; leaf id &nbsp;&nbsp;{ type hex-string; }<o=
:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf name { type string; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">These strings can be overlapping, so this cannot =
be represented as a union.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">There doesn't seem to be a way to use this as a k=
ey in Yang 1.0, without losing some typing information or inventing explici=
t invalid values (although Y09 could help with this to some extent -- see b=
elow).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Solution A:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Support keys within subcontainers. This brings th=
e &quot;key&quot; statement in line with the &quot;unique&quot; statement, =
but doesn't necessarily mean there's any need to change the properties that=
 are required of keys (e.g. they could still be mandatory
 within the list; though if Y09 is accepted this would be more flexible -- =
see Solution C).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">This solve the example in &quot;Issue 1&quot;, wh=
ich becomes:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">list mc-lag-rgs {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; key &quot;lacp-system-id/id lacp-system-id=
/mac&quot;;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; uses lacp-system-id-group;<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp; [&#8230;]<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Solution B:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Support non-leaf nodes (in particular container/c=
hoice) as keys. The complexity of the key type could be restricted (e.g. re=
quiring that all leaves (or all leaves in all case statements) are mandator=
y, and that there there is only one
 level of hierarchy below the node selected as a key), or it could simply b=
e taken as shorthand for Solution A for all the leaves (potentially in conj=
unction with Y09 to allow non-mandatory leaves).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Supporting the container as a key would solve iss=
ue 1, and supporting the choice as a key would solve issue 2.<o:p></o:p></p=
>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Relationship with Y09:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><a href=3D"http://svn.tools.ietf.org/svn/wg/netmo=
d/yang-1.1/issues.html#sec-9">Y09</a> tracks support for non-mandatory keys=
 -- this has particular uses in combination with Solution A above, as it al=
lows more flexibility in the leaves
 that can be used as part of the key.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">For example, Issue 2 can be modelled as follows u=
sing just Y09 if the leaves are made entries directly in the list:<o:p></o:=
p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">list maintenance-domains {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; key &quot;host id name&quot;;<o:p></o:p></=
p>
<p class=3D"MsoPlainText">&nbsp; leaf host { type inet:host;&nbsp; mandator=
y false; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf id &nbsp;&nbsp;{ type hex-string; man=
datory false; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; leaf name { type string; &nbsp;&nbsp;&nbsp=
;&nbsp;mandatory false; }<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">&nbsp; // Rule to ensure exactly one of the above=
 is specified<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; must &quot;count(host) &#43; count(id) &#4=
3; count(name) =3D 1&quot;;<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">However, in conjunction with solution A, instead =
this could be modelled as follows (which allows the choice statement to be =
re-used):<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">list maintenance-domains {<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; key &quot;maintenance-domain-identifier/ho=
st/host &quot;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; &#43; &quot;maintenance-domain=
-identifier/id/id &quot;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; &#43; &quot;maintenance-domain=
-identifier/string/string&quot;;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; choice maintenance-domain-identifier {<o:p=
></o:p></p>
<p class=3D"MsoPlainText">&nbsp;&nbsp;&nbsp; mandatory true;<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;leaf host { type inet:host; }<=
o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;leaf id &nbsp;&nbsp;{ type hex=
-string; }<o:p></o:p></p>
<p class=3D"MsoPlainText">&nbsp; &nbsp;&nbsp;leaf name { type string; }<o:p=
></o:p></p>
<p class=3D"MsoPlainText">&nbsp; }<o:p></o:p></p>
<p class=3D"MsoPlainText">}<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><b>Further notes on Y09:<o:p></o:p></b></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Is there a reason that even a single key has to be =
mandatory, rather than considering its absence to be an extension of its va=
lue space?<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Presumably keys should be mandatory by default for =
compatibility with YANG 1.0? (i.e. using &quot;mandatory false;&quot; to ov=
erride.)<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:23.25pt;text-indent:-18.0pt;=
mso-list:l0 level1 lfo1">
<![if !supportLists]><span style=3D"mso-list:Ignore">-<span style=3D"font:7=
.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;
</span></span><![endif]>The restriction on having an &quot;empty&quot; leaf=
 as part of a key should presumably also be lifted if Y09 is accepted?<o:p>=
</o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AAF484xmbalnx08ciscoc_--


From nobody Wed May  7 13:21:30 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6BA1A0207 for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 13:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzMGIULnAptt for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 13:21:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 490B81A01AE for <netmod@ietf.org>; Wed,  7 May 2014 13:21:27 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id B3740477C65; Wed,  7 May 2014 22:21:21 +0200 (CEST)
Date: Wed, 07 May 2014 22:21:20 +0200 (CEST)
Message-Id: <20140507.222120.122843926.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com>
References: <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz> <20140507.181121.223853730.mbj@tail-f.com> <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KSRtsxGyufQTiciJOXuN-hv-9GA
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 May 2014 20:21:28 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > I am confused.   There are no additional namespaces today - just one,
> > introduced by the module.  What did you agree on?
> >
> >
> There are 2 issues -- we agree on 1
> 
>  1) how to indicate that submodule contents are exported from the main
> module
>      to external modules?
> 
>     a) include must be in main module
>     b) include must be in main module or submodule
> 
>  2) what definitions are visible within a submodule?
> 
>     a) only self and includes
>     b) main module, self, and includes

Thank you, this is a clear summary of the alternatives.

I think we were all over the map when we discussed this during the
initial design of YANG.  We looked at all these alternatives, and
ended up with what we have today.  I'll go back and look in the
archives to see how much of the discussions are captured.

One design rule we had was that we wanted it to be possible to compile
/ check each submodule on its own (only follow explicit
import/include), w/o having to bring in the complete module.  With
option 2b, this is no longer possible.

Re. issue 1, it seems to me no real problem is solved by going from 1a
to 1b.

Re. issue 2, solution 2b actually solves a real problem - today you
have to place common definitions in a separate submodule; they cannot
go into the main module.  Since circular includes are not possible,
references within a module (across submodules) have to be done
carefully, and might impose a non-intuitive submodule design.

So I think we need to think more about this, but solution 2b seems
attractive to me.


/martin


From nobody Wed May  7 17:36:53 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C50F1A044D for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 17:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU2b8j_xZLur for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 17:36:30 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 351E31A0426 for <netmod@ietf.org>; Wed,  7 May 2014 17:36:30 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id x13so2039919qcv.16 for <netmod@ietf.org>; Wed, 07 May 2014 17:36:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I00wgB/PzlGdg/JAZ+SjrfddciPDafYXPeCEU0JmRgA=; b=mGqDgPFLdhXfseRPwqBls9QScQ4HMRBe9xy46YwGmJMw87M8zaid4kJ/ZDN4yudW09 XM2x72AkiIjP/tMSnpO2OGKHMH+5jnZAfBwvozybEq4id/5aDEslBBv2onkG5L7/LfyJ wBJqIVsd3ZD8UgVWuqFhQhLzxPTFi4OaeORprwpAD1wB23H2GESRd6QrA4UeLrZQzgof HfHnGw2oEMRJTeTq2inHRd/ZRajYoGTrY9GORTtLHgjgLUQm7N793d0Yzx3yOAPvbh/D o3sCYMgpZOjRJkhr3pMfKh+vJQs6L2U8m2yEsi1p0mMnTOTKSdYPrkzkscLHUXhv65hn GfMA==
X-Gm-Message-State: ALoCoQkbaSKe9s8BoKvsRkvCdkkvyced99X9zBoG/bMOozLhmkC9aEhLKbLMoJGRYvxmOKfrH+ns
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr357751qgo.25.1399509385732; Wed, 07 May 2014 17:36:25 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 17:36:25 -0700 (PDT)
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com>
Date: Wed, 7 May 2014 17:36:25 -0700
Message-ID: <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c17334cbf95504f8d8ab20
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IlJjCqexOPzuMdPgS_ndDrlrRn0
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 00:36:33 -0000

--001a11c17334cbf95504f8d8ab20
Content-Type: text/plain; charset=ISO-8859-1

Hi,

These topics were debated at length during the development of RFC 6020.
It was determined that (a) not only should keys be simple leafs that are
children of the list, but (b) the key leafs must be encoded on the wire
before any other child nodes, in order to improve server performance.

Nested leafs, containers full of whatever as keys, and variable numbers
of keys via choice-stmt would make YANG too complicated to be implemented
efficiently in servers.  N/Y is already very heavy-weight to implement.
This would make it much worse.


Andy



On Wed, May 7, 2014 at 1:16 PM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <powladi@cisco.com> wrote:

>  This is related to the restrictions on how keys can be specified for
> lists in YANG 1.0. I've listed two examples we've run up against where we
> hit limitations, and the extensions that could be made to support these use
> cases (which have some overlap).
>
>
>
> *Issue 1:*
>
>
>
> The elements of a subcontainer cannot be used as part of a key. In
> particular, take the case where a container with two elements is used as a
> data element in some cases, but needs to be used as a key in others.
>
>
>
> grouping lacp-system-id-group {
>
>   container lacp-system-id {
>
>     leaf id  { type uint16; mandatory true; }
>
>     leaf mac { type yang:mac-address; mandatory true; }
>
>   }
>
> }
>
>
>
> This can be done in Yang 1.0 is to re-define the contents of the grouping
> directly in the list (or to use a grouping-within-the grouping).
>
>
>
> list mc-lag-rgs {
>
>   key "system-id system-mac";
>
>  leaf id  { type uint16; mandatory true; }
>
>   leaf mac { type yang:mac-address; mandatory true; }
>
>
>
>   [...]
>
> }
>
>
>
> *Issue 2:*
>
>
>
> A list entry may have a key which is a union; i.e. it is indexed by a
> single value which is one of multiple types. However, a YANG union is not
> always sufficient to model a choice between a set of types.
>
>
>
> Take the following case for example:
>
>
>
> choice maintenance-domain-identifier {
>
>   leaf host { type inet:host; }
>
>   leaf id   { type hex-string; }
>
>   leaf name { type string; }
>
> }
>
>
>
> These strings can be overlapping, so this cannot be represented as a union.
>
>
>
> There doesn't seem to be a way to use this as a key in Yang 1.0, without
> losing some typing information or inventing explicit invalid values
> (although Y09 could help with this to some extent -- see below).
>
>
>
> *Solution A:*
>
>
>
> Support keys within subcontainers. This brings the "key" statement in line
> with the "unique" statement, but doesn't necessarily mean there's any need
> to change the properties that are required of keys (e.g. they could still
> be mandatory within the list; though if Y09 is accepted this would be more
> flexible -- see Solution C).
>
>
>
> This solve the example in "Issue 1", which becomes:
>
>
>
> list mc-lag-rgs {
>
>   key "lacp-system-id/id lacp-system-id/mac";
>
>   uses lacp-system-id-group;
>
>
>
>   [...]
>
> }
>
>
>
> *Solution B:*
>
>
>
> Support non-leaf nodes (in particular container/choice) as keys. The
> complexity of the key type could be restricted (e.g. requiring that all
> leaves (or all leaves in all case statements) are mandatory, and that there
> there is only one level of hierarchy below the node selected as a key), or
> it could simply be taken as shorthand for Solution A for all the leaves
> (potentially in conjunction with Y09 to allow non-mandatory leaves).
>
>
>
> Supporting the container as a key would solve issue 1, and supporting the
> choice as a key would solve issue 2.
>
>
>
> *Relationship with Y09:*
>
>
>
> Y09 <http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-9>tracks support for non-mandatory keys -- this has particular uses in
> combination with Solution A above, as it allows more flexibility in the
> leaves that can be used as part of the key.
>
>
>
> For example, Issue 2 can be modelled as follows using just Y09 if the
> leaves are made entries directly in the list:
>
>
>
> list maintenance-domains {
>
>   key "host id name";
>
>   leaf host { type inet:host;  mandatory false; }
>
>   leaf id   { type hex-string; mandatory false; }
>
>   leaf name { type string;     mandatory false; }
>
>
>
>   // Rule to ensure exactly one of the above is specified
>
>   must "count(host) + count(id) + count(name) = 1";
>
> }
>
>
>
> However, in conjunction with solution A, instead this could be modelled as
> follows (which allows the choice statement to be re-used):
>
>
>
> list maintenance-domains {
>
>   key "maintenance-domain-identifier/host/host "
>
>     + "maintenance-domain-identifier/id/id "
>
>     + "maintenance-domain-identifier/string/string";
>
>   choice maintenance-domain-identifier {
>
>     mandatory true;
>
>     leaf host { type inet:host; }
>
>     leaf id   { type hex-string; }
>
>     leaf name { type string; }
>
>   }
>
> }
>
>
>
> *Further notes on Y09:*
>
>
>
> -    Is there a reason that even a single key has to be mandatory, rather
> than considering its absence to be an extension of its value space?
>
> -    Presumably keys should be mandatory by default for compatibility
> with YANG 1.0? (i.e. using "mandatory false;" to override.)
>
> -    The restriction on having an "empty" leaf as part of a key should
> presumably also be lifted if Y09 is accepted?
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

--001a11c17334cbf95504f8d8ab20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br>These topics were debated at length during the=
 development of RFC 6020.</div><div>It was determined that (a) not only sho=
uld keys be simple leafs that are</div><div>children of the list, but (b) t=
he key leafs must be encoded on the wire</div>
<div>before any other child nodes, in order to improve server performance.<=
/div><div><br></div><div>Nested leafs, containers full of whatever as keys,=
 and variable numbers</div><div>of keys via choice-stmt would make YANG too=
 complicated to be implemented</div>
<div>efficiently in servers. &nbsp;N/Y is already very heavy-weight to impl=
ement.</div><div>This would make it much worse.</div><div><br></div><div><b=
r></div><div>Andy</div><div><br></div></div><div class=3D"gmail_extra"><br>=
<br>
<div class=3D"gmail_quote">On Wed, May 7, 2014 at 1:16 PM, Peyman Owladi -X=
 (powladi - Ensoft Ltd at Cisco) <span dir=3D"ltr">&lt;<a href=3D"mailto:po=
wladi@cisco.com" target=3D"_blank">powladi@cisco.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">






<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div>
<p>This is related to the restrictions on how keys can be specified for lis=
ts in YANG 1.0. I&#39;ve listed two examples we&#39;ve run up against where=
 we hit limitations, and the extensions that could be made to support these=
 use cases (which have
 some overlap).<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p><b>Issue 1:<u></u><u></u></b></p>
<p><u></u>&nbsp;<u></u></p>
<p>The elements of a subcontainer cannot be used as part of a key. In parti=
cular, take the case where a container with two elements is used as a data =
element in some cases, but needs to be used as a key in others.<u></u><u></=
u></p>

<p><u></u>&nbsp;<u></u></p>
<p>grouping lacp-system-id-group {<u></u><u></u></p>
<p>&nbsp; container lacp-system-id {<u></u><u></u></p>
<p>&nbsp;&nbsp;&nbsp; leaf id&nbsp; { type uint16; mandatory true; }<u></u>=
<u></u></p>
<p>&nbsp;&nbsp;&nbsp; leaf mac { type yang:mac-address; mandatory true; }<u=
></u><u></u></p>
<p>&nbsp; }<u></u><u></u></p>
<p>}<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>This can be done in Yang 1.0 is to re-define the contents of the groupin=
g directly in the list (or to use a grouping-within-the grouping).<u></u><u=
></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>list mc-lag-rgs {<u></u><u></u></p>
<p>&nbsp; key &quot;system-id system-mac&quot;;<u></u><u></u></p>
<p>&nbsp;leaf id&nbsp; { type uint16; mandatory true; }<u></u><u></u></p>
<p>&nbsp; leaf mac { type yang:mac-address; mandatory true; }<u></u><u></u>=
</p>
<p><u></u>&nbsp;<u></u></p>
<p>&nbsp; [&hellip;]<u></u><u></u></p>
<p>}<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p><b>Issue 2:<u></u><u></u></b></p>
<p><u></u>&nbsp;<u></u></p>
<p>A list entry may have a key which is a union; i.e. it is indexed by a si=
ngle value which is one of multiple types. However, a YANG union is not alw=
ays sufficient to model a choice between a set of types.<u></u><u></u></p>

<p><u></u>&nbsp;<u></u></p>
<p>Take the following case for example:<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>choice maintenance-domain-identifier {<u></u><u></u></p>
<p>&nbsp; leaf host { type inet:host; }<u></u><u></u></p>
<p>&nbsp; leaf id &nbsp;&nbsp;{ type hex-string; }<u></u><u></u></p>
<p>&nbsp; leaf name { type string; }<u></u><u></u></p>
<p>}<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>These strings can be overlapping, so this cannot be represented as a uni=
on.<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>There doesn&#39;t seem to be a way to use this as a key in Yang 1.0, wit=
hout losing some typing information or inventing explicit invalid values (a=
lthough Y09 could help with this to some extent -- see below).<u></u><u></u=
></p>

<p><u></u>&nbsp;<u></u></p>
<p><b>Solution A:<u></u><u></u></b></p>
<p><u></u>&nbsp;<u></u></p>
<p>Support keys within subcontainers. This brings the &quot;key&quot; state=
ment in line with the &quot;unique&quot; statement, but doesn&#39;t necessa=
rily mean there&#39;s any need to change the properties that are required o=
f keys (e.g. they could still be mandatory
 within the list; though if Y09 is accepted this would be more flexible -- =
see Solution C).<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>This solve the example in &quot;Issue 1&quot;, which becomes:<u></u><u><=
/u></p>
<p><u></u>&nbsp;<u></u></p>
<p>list mc-lag-rgs {<u></u><u></u></p>
<p>&nbsp; key &quot;lacp-system-id/id lacp-system-id/mac&quot;;<u></u><u></=
u></p>
<p>&nbsp; uses lacp-system-id-group;<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>&nbsp; [&hellip;]<u></u><u></u></p>
<p>}<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p><b>Solution B:<u></u><u></u></b></p>
<p><u></u>&nbsp;<u></u></p>
<p>Support non-leaf nodes (in particular container/choice) as keys. The com=
plexity of the key type could be restricted (e.g. requiring that all leaves=
 (or all leaves in all case statements) are mandatory, and that there there=
 is only one
 level of hierarchy below the node selected as a key), or it could simply b=
e taken as shorthand for Solution A for all the leaves (potentially in conj=
unction with Y09 to allow non-mandatory leaves).<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>Supporting the container as a key would solve issue 1, and supporting th=
e choice as a key would solve issue 2.<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p><b>Relationship with Y09:<u></u><u></u></b></p>
<p><u></u>&nbsp;<u></u></p>
<p><a href=3D"http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#=
sec-9" target=3D"_blank">Y09</a> tracks support for non-mandatory keys -- t=
his has particular uses in combination with Solution A above, as it allows =
more flexibility in the leaves
 that can be used as part of the key.<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>For example, Issue 2 can be modelled as follows using just Y09 if the le=
aves are made entries directly in the list:<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>list maintenance-domains {<u></u><u></u></p>
<p>&nbsp; key &quot;host id name&quot;;<u></u><u></u></p>
<p>&nbsp; leaf host { type inet:host;&nbsp; mandatory false; }<u></u><u></u=
></p>
<p>&nbsp; leaf id &nbsp;&nbsp;{ type hex-string; mandatory false; }<u></u><=
u></u></p>
<p>&nbsp; leaf name { type string; &nbsp;&nbsp;&nbsp;&nbsp;mandatory false;=
 }<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>&nbsp; // Rule to ensure exactly one of the above is specified<u></u><u>=
</u></p>
<p>&nbsp; must &quot;count(host) + count(id) + count(name) =3D 1&quot;;<u><=
/u><u></u></p>
<p>}<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p>However, in conjunction with solution A, instead this could be modelled =
as follows (which allows the choice statement to be re-used):<u></u><u></u>=
</p>
<p><u></u>&nbsp;<u></u></p>
<p>list maintenance-domains {<u></u><u></u></p>
<p>&nbsp; key &quot;maintenance-domain-identifier/host/host &quot;<u></u><u=
></u></p>
<p>&nbsp;&nbsp;&nbsp; + &quot;maintenance-domain-identifier/id/id &quot;<u>=
</u><u></u></p>
<p>&nbsp;&nbsp;&nbsp; + &quot;maintenance-domain-identifier/string/string&q=
uot;;<u></u><u></u></p>
<p>&nbsp; choice maintenance-domain-identifier {<u></u><u></u></p>
<p>&nbsp;&nbsp;&nbsp; mandatory true;<u></u><u></u></p>
<p>&nbsp; &nbsp;&nbsp;leaf host { type inet:host; }<u></u><u></u></p>
<p>&nbsp; &nbsp;&nbsp;leaf id &nbsp;&nbsp;{ type hex-string; }<u></u><u></u=
></p>
<p>&nbsp; &nbsp;&nbsp;leaf name { type string; }<u></u><u></u></p>
<p>&nbsp; }<u></u><u></u></p>
<p>}<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<p><b>Further notes on Y09:<u></u><u></u></b></p>
<p><u></u>&nbsp;<u></u></p>
<p style=3D"margin-left:23.25pt">
<u></u><span>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;=
&nbsp;&nbsp;
</span></span><u></u>Is there a reason that even a single key has to be man=
datory, rather than considering its absence to be an extension of its value=
 space?<u></u><u></u></p>
<p style=3D"margin-left:23.25pt">
<u></u><span>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;=
&nbsp;&nbsp;
</span></span><u></u>Presumably keys should be mandatory by default for com=
patibility with YANG 1.0? (i.e. using &quot;mandatory false;&quot; to overr=
ide.)<u></u><u></u></p>
<p style=3D"margin-left:23.25pt">
<u></u><span>-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;=
&nbsp;&nbsp;
</span></span><u></u>The restriction on having an &quot;empty&quot; leaf as=
 part of a key should presumably also be lifted if Y09 is accepted?<u></u><=
u></u></p>
<p><u></u>&nbsp;<u></u></p>
</div>
</div>

<br>_______________________________________________<br>
netmod mailing list<br>
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/netmod</a><br>
<br></blockquote></div><br></div>

--001a11c17334cbf95504f8d8ab20--


From nobody Wed May  7 22:54:43 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125911A023C for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 22:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMT7Nph3UY7F for <netmod@ietfa.amsl.com>; Wed,  7 May 2014 22:54:38 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 07A001A0236 for <netmod@ietf.org>; Wed,  7 May 2014 22:54:37 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3BFEF13F976; Thu,  8 May 2014 07:54:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1399528471; bh=rt9Yye1Yk53H8R28Vo51IQGhzazXS3F+INgoLLJiwtU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=utbZSL2bYDrwOXReNK+ZGrnH3+79eEsAslHmLHp5uLrg6T5tHjRTG9c/S2/GVL9ig pPVjrZva0fV/dHXrtimsqmHWW9WH3MCZfQUYDEwV3DtYgOfUBEuGtisFJ2/3R6kiXS +13UOM0W3yIdoa9AiFSk4nLuShu2Hq1B3NUu9LVc=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140507.222120.122843926.mbj@tail-f.com>
Date: Thu, 8 May 2014 07:54:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A543A9BC-9F1A-4154-8CBB-B0A52EC9C3EB@nic.cz>
References: <F340FFBF-EC29-493B-A592-36CB884D493E@nic.cz> <20140507.181121.223853730.mbj@tail-f.com> <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com> <20140507.222120.122843926.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KMkfrwv8dYfbrR7cLACLbASHido
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 05:54:40 -0000

On 07 May 2014, at 22:21, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.com> wrote:
>> On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:
>>> I am confused.   There are no additional namespaces today - just =
one,
>>> introduced by the module.  What did you agree on?
>>>=20
>>>=20
>> There are 2 issues -- we agree on 1
>>=20
>> 1) how to indicate that submodule contents are exported from the main
>> module
>>     to external modules?
>>=20
>>    a) include must be in main module
>>    b) include must be in main module or submodule
>>=20
>> 2) what definitions are visible within a submodule?
>>=20
>>    a) only self and includes
>>    b) main module, self, and includes
>=20
> Thank you, this is a clear summary of the alternatives.
>=20
> I think we were all over the map when we discussed this during the
> initial design of YANG.  We looked at all these alternatives, and
> ended up with what we have today.  I'll go back and look in the
> archives to see how much of the discussions are captured.

I wasn=92t there. :-)

>=20
> One design rule we had was that we wanted it to be possible to compile
> / check each submodule on its own (only follow explicit
> import/include), w/o having to bring in the complete module.  With
> option 2b, this is no longer possible.

I don=92t think this is important - the top-level definitions from the =
main module and all submodules are easy to look up. On the other hand, =
submodules cannot use conflicting names even if they don=92t include =
each other, so it doesn=92t help submodule writers in this respect.=20

>=20
> Re. issue 1, it seems to me no real problem is solved by going from 1a
> to 1b.

I agree. It would be different if a submodule tree could be grafted to a =
non-root node, but it is not the case.

>=20
> Re. issue 2, solution 2b actually solves a real problem - today you
> have to place common definitions in a separate submodule; they cannot
> go into the main module.  Since circular includes are not possible,
> references within a module (across submodules) have to be done
> carefully, and might impose a non-intuitive submodule design.

Right, this is a serious contender for the most peculiar rule in YANG.=20=


>=20
> So I think we need to think more about this, but solution 2b seems
> attractive to me.

With 1a, the following is a logical option:

2c) main module and all submodules included from it.

Lada

>=20
>=20
> /martin
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May  8 00:54:37 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EB91A04E8 for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 00:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q01jSdgVACJh for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 00:54:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1361A04A7 for <netmod@ietf.org>; Thu,  8 May 2014 00:54:32 -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 25A203F4012; Thu,  8 May 2014 09:54:27 +0200 (CEST)
Date: Thu, 08 May 2014 09:54:26 +0200 (CEST)
Message-Id: <20140508.095426.686508493610810924.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <A543A9BC-9F1A-4154-8CBB-B0A52EC9C3EB@nic.cz>
References: <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com> <20140507.222120.122843926.mbj@tail-f.com> <A543A9BC-9F1A-4154-8CBB-B0A52EC9C3EB@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dkvWS3rcU6WRFmfkUQu16yqtAO8
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 07:54:35 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDA3IE1heSAy
MDE0LCBhdCAyMjoyMSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K
PiANCj4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4+IE9u
IFdlZCwgTWF5IDcsIDIwMTQgYXQgOToxMSBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt
Zi5jb20+DQo+ID4+IHdyb3RlOg0KPiA+Pj4gSSBhbSBjb25mdXNlZC4gICBUaGVyZSBhcmUgbm8g
YWRkaXRpb25hbCBuYW1lc3BhY2VzIHRvZGF5IC0ganVzdCBvbmUsDQo+ID4+PiBpbnRyb2R1Y2Vk
IGJ5IHRoZSBtb2R1bGUuICBXaGF0IGRpZCB5b3UgYWdyZWUgb24/DQo+ID4+PiANCj4gPj4+IA0K
PiA+PiBUaGVyZSBhcmUgMiBpc3N1ZXMgLS0gd2UgYWdyZWUgb24gMQ0KPiA+PiANCj4gPj4gMSkg
aG93IHRvIGluZGljYXRlIHRoYXQgc3VibW9kdWxlIGNvbnRlbnRzIGFyZSBleHBvcnRlZCBmcm9t
IHRoZSBtYWluDQo+ID4+IG1vZHVsZQ0KPiA+PiAgICAgdG8gZXh0ZXJuYWwgbW9kdWxlcz8NCj4g
Pj4gDQo+ID4+ICAgIGEpIGluY2x1ZGUgbXVzdCBiZSBpbiBtYWluIG1vZHVsZQ0KPiA+PiAgICBi
KSBpbmNsdWRlIG11c3QgYmUgaW4gbWFpbiBtb2R1bGUgb3Igc3VibW9kdWxlDQo+ID4+IA0KPiA+
PiAyKSB3aGF0IGRlZmluaXRpb25zIGFyZSB2aXNpYmxlIHdpdGhpbiBhIHN1Ym1vZHVsZT8NCj4g
Pj4gDQo+ID4+ICAgIGEpIG9ubHkgc2VsZiBhbmQgaW5jbHVkZXMNCj4gPj4gICAgYikgbWFpbiBt
b2R1bGUsIHNlbGYsIGFuZCBpbmNsdWRlcw0KPiA+IA0KPiA+IFRoYW5rIHlvdSwgdGhpcyBpcyBh
IGNsZWFyIHN1bW1hcnkgb2YgdGhlIGFsdGVybmF0aXZlcy4NCj4gPiANCj4gPiBJIHRoaW5rIHdl
IHdlcmUgYWxsIG92ZXIgdGhlIG1hcCB3aGVuIHdlIGRpc2N1c3NlZCB0aGlzIGR1cmluZyB0aGUN
Cj4gPiBpbml0aWFsIGRlc2lnbiBvZiBZQU5HLiAgV2UgbG9va2VkIGF0IGFsbCB0aGVzZSBhbHRl
cm5hdGl2ZXMsIGFuZA0KPiA+IGVuZGVkIHVwIHdpdGggd2hhdCB3ZSBoYXZlIHRvZGF5LiAgSSds
bCBnbyBiYWNrIGFuZCBsb29rIGluIHRoZQ0KPiA+IGFyY2hpdmVzIHRvIHNlZSBob3cgbXVjaCBv
ZiB0aGUgZGlzY3Vzc2lvbnMgYXJlIGNhcHR1cmVkLg0KPiANCj4gSSB3YXNu4oCZdCB0aGVyZS4g
Oi0pDQo+IA0KPiA+IA0KPiA+IE9uZSBkZXNpZ24gcnVsZSB3ZSBoYWQgd2FzIHRoYXQgd2Ugd2Fu
dGVkIGl0IHRvIGJlIHBvc3NpYmxlIHRvIGNvbXBpbGUNCj4gPiAvIGNoZWNrIGVhY2ggc3VibW9k
dWxlIG9uIGl0cyBvd24gKG9ubHkgZm9sbG93IGV4cGxpY2l0DQo+ID4gaW1wb3J0L2luY2x1ZGUp
LCB3L28gaGF2aW5nIHRvIGJyaW5nIGluIHRoZSBjb21wbGV0ZSBtb2R1bGUuICBXaXRoDQo+ID4g
b3B0aW9uIDJiLCB0aGlzIGlzIG5vIGxvbmdlciBwb3NzaWJsZS4NCj4gDQo+IEkgZG9u4oCZdCB0
aGluayB0aGlzIGlzIGltcG9ydGFudCAtIHRoZSB0b3AtbGV2ZWwgZGVmaW5pdGlvbnMgZnJvbSB0
aGUNCj4gbWFpbiBtb2R1bGUgYW5kIGFsbCBzdWJtb2R1bGVzIGFyZSBlYXN5IHRvIGxvb2sgdXAu
IE9uIHRoZSBvdGhlciBoYW5kLA0KPiBzdWJtb2R1bGVzIGNhbm5vdCB1c2UgY29uZmxpY3Rpbmcg
bmFtZXMgZXZlbiBpZiB0aGV5IGRvbuKAmXQgaW5jbHVkZQ0KPiBlYWNoIG90aGVyLCBzbyBpdCBk
b2VzbuKAmXQgaGVscCBzdWJtb2R1bGUgd3JpdGVycyBpbiB0aGlzIHJlc3BlY3QuDQo+IA0KPiA+
IA0KPiA+IFJlLiBpc3N1ZSAxLCBpdCBzZWVtcyB0byBtZSBubyByZWFsIHByb2JsZW0gaXMgc29s
dmVkIGJ5IGdvaW5nIGZyb20gMWENCj4gPiB0byAxYi4NCj4gDQo+IEkgYWdyZWUuIEl0IHdvdWxk
IGJlIGRpZmZlcmVudCBpZiBhIHN1Ym1vZHVsZSB0cmVlIGNvdWxkIGJlIGdyYWZ0ZWQgdG8NCj4g
YSBub24tcm9vdCBub2RlLCBidXQgaXQgaXMgbm90IHRoZSBjYXNlLg0KPiANCj4gPiANCj4gPiBS
ZS4gaXNzdWUgMiwgc29sdXRpb24gMmIgYWN0dWFsbHkgc29sdmVzIGEgcmVhbCBwcm9ibGVtIC0g
dG9kYXkgeW91DQo+ID4gaGF2ZSB0byBwbGFjZSBjb21tb24gZGVmaW5pdGlvbnMgaW4gYSBzZXBh
cmF0ZSBzdWJtb2R1bGU7IHRoZXkgY2Fubm90DQo+ID4gZ28gaW50byB0aGUgbWFpbiBtb2R1bGUu
ICBTaW5jZSBjaXJjdWxhciBpbmNsdWRlcyBhcmUgbm90IHBvc3NpYmxlLA0KPiA+IHJlZmVyZW5j
ZXMgd2l0aGluIGEgbW9kdWxlIChhY3Jvc3Mgc3VibW9kdWxlcykgaGF2ZSB0byBiZSBkb25lDQo+
ID4gY2FyZWZ1bGx5LCBhbmQgbWlnaHQgaW1wb3NlIGEgbm9uLWludHVpdGl2ZSBzdWJtb2R1bGUg
ZGVzaWduLg0KPiANCj4gUmlnaHQsIHRoaXMgaXMgYSBzZXJpb3VzIGNvbnRlbmRlciBmb3IgdGhl
IG1vc3QgcGVjdWxpYXIgcnVsZSBpbiBZQU5HLg0KPiANCj4gPiANCj4gPiBTbyBJIHRoaW5rIHdl
IG5lZWQgdG8gdGhpbmsgbW9yZSBhYm91dCB0aGlzLCBidXQgc29sdXRpb24gMmIgc2VlbXMNCj4g
PiBhdHRyYWN0aXZlIHRvIG1lLg0KPiANCj4gV2l0aCAxYSwgdGhlIGZvbGxvd2luZyBpcyBhIGxv
Z2ljYWwgb3B0aW9uOg0KPiANCj4gMmMpIG1haW4gbW9kdWxlIGFuZCBhbGwgc3VibW9kdWxlcyBp
bmNsdWRlZCBmcm9tIGl0Lg0KDQpZZXMsIHRoYXQncyBob3cgSSBpbnRlcnByZXRlZCAyYiEgIEVz
c2VudGlhbGx5IGVhY2ggc3VibW9kdWxlIGhhcw0KYWNjZXNzIHRvIGFsbCBkZWZpbml0aW9ucyBp
biBhbGwgb3RoZXIgc3VibW9kdWxlcy4NCg0KDQovbWFydGluDQo=


From nobody Thu May  8 03:00:43 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62161A0547 for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 03:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsFCP3QPgO-R for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 03:00:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 51D551A0546 for <netmod@ietf.org>; Thu,  8 May 2014 03:00:38 -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 08BFA3941FA; Thu,  8 May 2014 12:00:32 +0200 (CEST)
Date: Thu, 08 May 2014 12:00:31 +0200 (CEST)
Message-Id: <20140508.120031.421415901709698364.mbj@tail-f.com>
To: powladi@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uSwqGNK7iRykypmePFHEQTEUahU
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 10:00:40 -0000

Hi,

Added as Y53.


/martin


"Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com> wrote:
> This is related to the restrictions on how keys can be specified for
> lists in YANG 1.0. I've listed two examples we've run up against where
> we hit limitations, and the extensions that could be made to support
> these use cases (which have some overlap).
> 
> 
> 
> Issue 1:
> 
> 
> 
> The elements of a subcontainer cannot be used as part of a key. In
> particular, take the case where a container with two elements is used
> as a data element in some cases, but needs to be used as a key in
> others.
> 
> 
> 
> grouping lacp-system-id-group {
> 
>   container lacp-system-id {
> 
>     leaf id  { type uint16; mandatory true; }
> 
>     leaf mac { type yang:mac-address; mandatory true; }
> 
>   }
> 
> }
> 
> 
> 
> This can be done in Yang 1.0 is to re-define the contents of the
> grouping directly in the list (or to use a grouping-within-the
> grouping).
> 
> 
> 
> list mc-lag-rgs {
> 
>   key "system-id system-mac";
> 
>  leaf id  { type uint16; mandatory true; }
> 
>   leaf mac { type yang:mac-address; mandatory true; }
> 
> 
> 
>   [...]
> 
> }
> 
> 
> 
> Issue 2:
> 
> 
> 
> A list entry may have a key which is a union; i.e. it is indexed by a
> single value which is one of multiple types. However, a YANG union is
> not always sufficient to model a choice between a set of types.
> 
> 
> 
> Take the following case for example:
> 
> 
> 
> choice maintenance-domain-identifier {
> 
>   leaf host { type inet:host; }
> 
>   leaf id   { type hex-string; }
> 
>   leaf name { type string; }
> 
> }
> 
> 
> 
> These strings can be overlapping, so this cannot be represented as a
> union.
> 
> 
> 
> There doesn't seem to be a way to use this as a key in Yang 1.0,
> without losing some typing information or inventing explicit invalid
> values (although Y09 could help with this to some extent -- see
> below).
> 
> 
> 
> Solution A:
> 
> 
> 
> Support keys within subcontainers. This brings the "key" statement in
> line with the "unique" statement, but doesn't necessarily mean there's
> any need to change the properties that are required of keys (e.g. they
> could still be mandatory within the list; though if Y09 is accepted
> this would be more flexible -- see Solution C).
> 
> 
> 
> This solve the example in "Issue 1", which becomes:
> 
> 
> 
> list mc-lag-rgs {
> 
>   key "lacp-system-id/id lacp-system-id/mac";
> 
>   uses lacp-system-id-group;
> 
> 
> 
>   [...]
> 
> }
> 
> 
> 
> Solution B:
> 
> 
> 
> Support non-leaf nodes (in particular container/choice) as keys. The
> complexity of the key type could be restricted (e.g. requiring that
> all leaves (or all leaves in all case statements) are mandatory, and
> that there there is only one level of hierarchy below the node
> selected as a key), or it could simply be taken as shorthand for
> Solution A for all the leaves (potentially in conjunction with Y09 to
> allow non-mandatory leaves).
> 
> 
> 
> Supporting the container as a key would solve issue 1, and supporting
> the choice as a key would solve issue 2.
> 
> 
> 
> Relationship with Y09:
> 
> 
> 
> Y09<http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-9>
> tracks support for non-mandatory keys -- this has particular uses in
> combination with Solution A above, as it allows more flexibility in
> the leaves that can be used as part of the key.
> 
> 
> 
> For example, Issue 2 can be modelled as follows using just Y09 if the
> leaves are made entries directly in the list:
> 
> 
> 
> list maintenance-domains {
> 
>   key "host id name";
> 
>   leaf host { type inet:host;  mandatory false; }
> 
>   leaf id   { type hex-string; mandatory false; }
> 
>   leaf name { type string;     mandatory false; }
> 
> 
> 
>   // Rule to ensure exactly one of the above is specified
> 
>   must "count(host) + count(id) + count(name) = 1";
> 
> }
> 
> 
> 
> However, in conjunction with solution A, instead this could be
> modelled as follows (which allows the choice statement to be re-used):
> 
> 
> 
> list maintenance-domains {
> 
>   key "maintenance-domain-identifier/host/host "
> 
>     + "maintenance-domain-identifier/id/id "
> 
>     + "maintenance-domain-identifier/string/string";
> 
>   choice maintenance-domain-identifier {
> 
>     mandatory true;
> 
>     leaf host { type inet:host; }
> 
>     leaf id   { type hex-string; }
> 
>     leaf name { type string; }
> 
>   }
> 
> }
> 
> 
> 
> Further notes on Y09:
> 
> 
> 
> -    Is there a reason that even a single key has to be mandatory, rather
> -    than considering its absence to be an extension of its value space?
> 
> -    Presumably keys should be mandatory by default for compatibility with
> -    YANG 1.0? (i.e. using "mandatory false;" to override.)
> 
> -    The restriction on having an "empty" leaf as part of a key should
> -    presumably also be lifted if Y09 is accepted?
> 
> 


From nobody Thu May  8 03:01:52 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09C61A05CB for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 03:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fFVotAsOgXa for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 03:01:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 659D71A0552 for <netmod@ietf.org>; Thu,  8 May 2014 03:01:48 -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 2F2293941F6; Thu,  8 May 2014 12:01:43 +0200 (CEST)
Date: Thu, 08 May 2014 12:01:43 +0200 (CEST)
Message-Id: <20140508.120143.1962717862150015233.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/renOq-YmhOtVVEadj9Ti1kNI6eM
Cc: netmod@ietf.org
Subject: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 10:01:49 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> These topics were debated at length during the development of RFC 6020.
> It was determined that (a) not only should keys be simple leafs that are
> children of the list, but (b) the key leafs must be encoded on the wire
> before any other child nodes, in order to improve server performance.
> 
> Nested leafs, containers full of whatever as keys, and variable numbers
> of keys via choice-stmt would make YANG too complicated to be implemented
> efficiently in servers.  N/Y is already very heavy-weight to implement.
> This would make it much worse.

I fully agree.


/martin


From nobody Thu May  8 06:49:46 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EBB1A065A for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 06:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level: 
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rtJ_kJTLmFi for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 06:49:40 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6F1A0654 for <netmod@ietf.org>; Thu,  8 May 2014 06:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2540; q=dns/txt; s=iport; t=1399556975; x=1400766575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GBMWq5NscEbFbQTPEImc5I2Nu9ekIPnJ+gmGTJkUkC4=; b=SPFPnXecVY7+ADlb25fbDR/sWhg+qeXJle2CP+V7iP13mdrr/fu5rsFY eWROJgtj6+1imeYIF9pLE0k4JJqfHk5+wFN7NxTf3q0daW11ktfpo8sfD KylvgxDfzPk/C0pZ6pzkPblf9PNzY770Ld+yGPPRpXe0tw7dqQ79kmYvG w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFADCKa1OtJV2Z/2dsb2JhbABZgwaBJ8VfAYERFnSCJQEBAQQ6PwwEAgEIDgMEAQEBChQJBzIUCQgCBAENBQgTiCbQDxeJMYRQAQEeMQcGgySBFQEDlUGWcoM2gXY5
X-IronPort-AV: E=Sophos;i="4.97,1010,1389744000"; d="scan'208";a="42116458"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 08 May 2014 13:49:35 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s48DnZsB030724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 13:49:35 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 8 May 2014 08:49:34 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "andy@yumaworks.com" <andy@yumaworks.com>
Thread-Topic: Y53: YANG 1.1 Key Flexibility
Thread-Index: AQDqlaWLAxII9M2UdJcD6jdSAOWzIAGT5jcmAY5vUDyc5xqW8A==
Date: Thu, 8 May 2014 13:49:34 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com> <20140508.120143.1962717862150015233.mbj@tail-f.com>
In-Reply-To: <20140508.120143.1962717862150015233.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.168]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZGgv25i-yRrZJ8n5-7pe9V73IAY
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 13:49:44 -0000

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 08 May 2014 11:02
> To: andy@yumaworks.com
> Cc: powladi@cisco.com; netmod@ietf.org
> Subject: Y53: YANG 1.1 Key Flexibility
>=20
> Andy Bierman <andy@yumaworks.com> wrote:
> > Hi,
> >
> > These topics were debated at length during the development of RFC 6020.
> > It was determined that (a) not only should keys be simple leafs that ar=
e
> > children of the list, but (b) the key leafs must be encoded on the wire
> > before any other child nodes, in order to improve server performance.
> >
> > Nested leafs, containers full of whatever as keys, and variable numbers
> > of keys via choice-stmt would make YANG too complicated to be implement=
ed
> > efficiently in servers.  N/Y is already very heavy-weight to implement.
> > This would make it much worse.
>=20
> I fully agree.

Fair enough; thanks for the explanation.

It would still be useful to get some thoughts on what the solution should b=
e for issue 2 in the original mail (copied here for reference):
=3D=3D=3D=3D=3D=3D
A list entry may have a key which is a union; i.e. it is indexed by a singl=
e value which is one of multiple types. However, a YANG union is not always=
 sufficient to model a choice between a set of types.

Take the following case for example:

choice maintenance-domain-identifier {
  leaf host { type inet:host; }
  leaf id   { type hex-string; }
  leaf name { type string; }
}

These strings can be overlapping, so this cannot be represented as a union.
=3D=3D=3D=3D=3D=3D

Do you have thoughts on how this should be modelled (and if extensions are =
needed)?

In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a "must" statement =
(and I'm not sure whether this is even compatible with the "CLI" comment in=
 Y09-01):
=3D=3D=3D=3D=3D=3D
list maintenance-domains {
  key "host id name";
  leaf host { type inet:host;  mandatory false; }
  leaf id   { type hex-string; mandatory false; }
  leaf name { type string;     mandatory false; }

  // Rule to ensure exactly one of the above is specified
  must "count(host) + count(id) + count(name) =3D 1";
}
=3D=3D=3D=3D=3D=3D

Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)

Thanks,
Peyman


From nobody Thu May  8 07:04:57 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149DD1A069B for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 07:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbH7qfFuhjrj for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 07:04:48 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 353481A0697 for <netmod@ietf.org>; Thu,  8 May 2014 07:04:48 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id ih12so2549805qab.40 for <netmod@ietf.org>; Thu, 08 May 2014 07:04:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HHvp80niDJPLaBykjPuLjxqJ1smpqyR2oPhP2X+4Vq8=; b=HzQSgR0y4TsOjDBvHRQq8mi4HA19yuOx/TAPjsn/U4XQWPUwuKS2Vt9QMILL3szl1G OkCHCBxWxvAcUdQ0w2R9RdhFnkhn5rvse6FR4u5w8GzXuu4tQ0dcNoZg8v6jlfmfjC65 g5PtIYLjSfPrJEMk7wx/Zd7MKYJ5dYvpesgzUs0gkAxR9HS5BHGOM2MRrR6RLbmdw76Y FJpznl68smAh8yxZf7EKLyB2W4qe1Oyazc6yAPQFpMlIfBTA5igXT9BxhNhutIGlYv6g ybJXUyaI4aO1JCUjjMVzbs1svoiVkuOsXCbftDg1iEvcJff5DjECG7EthNZ+fyYUGoNs aL/Q==
X-Gm-Message-State: ALoCoQlj7Ej9Qn6s2QH21hAtG6EvalGgT2wqq8HD4IbWF6YrVTTz1lh7vG77wQAYUO3oOE+KLXOF
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr4894109qgy.34.1399557883503; Thu, 08 May 2014 07:04:43 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 8 May 2014 07:04:43 -0700 (PDT)
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com> <20140508.120143.1962717862150015233.mbj@tail-f.com> <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com>
Date: Thu, 8 May 2014 07:04:43 -0700
Message-ID: <CABCOCHQNysSSgV51MApPCVcc4GWQLHS3w=3+SgiQYzWv80NdKw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c126ba7d421a04f8e3f680
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_6YUTeloucKLgSIBbZmVV0bft-o
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 14:04:53 -0000

--001a11c126ba7d421a04f8e3f680
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 8, 2014 at 6:49 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <powladi@cisco.com> wrote:

> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > Sent: 08 May 2014 11:02
> > To: andy@yumaworks.com
> > Cc: powladi@cisco.com; netmod@ietf.org
> > Subject: Y53: YANG 1.1 Key Flexibility
> >
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > Hi,
> > >
> > > These topics were debated at length during the development of RFC 6020.
> > > It was determined that (a) not only should keys be simple leafs that
> are
> > > children of the list, but (b) the key leafs must be encoded on the wire
> > > before any other child nodes, in order to improve server performance.
> > >
> > > Nested leafs, containers full of whatever as keys, and variable numbers
> > > of keys via choice-stmt would make YANG too complicated to be
> implemented
> > > efficiently in servers.  N/Y is already very heavy-weight to implement.
> > > This would make it much worse.
> >
> > I fully agree.
>
> Fair enough; thanks for the explanation.
>
> It would still be useful to get some thoughts on what the solution should
> be for issue 2 in the original mail (copied here for reference):
> ======
> A list entry may have a key which is a union; i.e. it is indexed by a
> single value which is one of multiple types. However, a YANG union is not
> always sufficient to model a choice between a set of types.
>
> Take the following case for example:
>
> choice maintenance-domain-identifier {
>   leaf host { type inet:host; }
>   leaf id   { type hex-string; }
>   leaf name { type string; }
> }
>
>


typedef maintenance-domain-identifier {
  type union {
    type inet:host;
    type hex-string;
    type string;
  }
}


This is legal YANG.
Figuring out which type-stmt matched is an implementation detail.


Andy






> These strings can be overlapping, so this cannot be represented as a union.
> ======
>
> Do you have thoughts on how this should be modelled (and if extensions are
> needed)?
>
> In particular, it seems there is a solution using Y09-01, though to do
> this we effectively have to reinvent the choice/union using a "must"
> statement (and I'm not sure whether this is even compatible with the "CLI"
> comment in Y09-01):
> ======
> list maintenance-domains {
>   key "host id name";
>   leaf host { type inet:host;  mandatory false; }
>   leaf id   { type hex-string; mandatory false; }
>   leaf name { type string;     mandatory false; }
>
>   // Rule to ensure exactly one of the above is specified
>   must "count(host) + count(id) + count(name) = 1";
> }
> ======
>
> Is that the best approach, or is there a better answer? (For example,
> introducing a union type with a discriminator would perhaps work as it
> would allow the above to be modelled as a union and therefore used as a
> key.)
>
> Thanks,
> Peyman
>
>

--001a11c126ba7d421a04f8e3f680
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, May 8, 2014 at 6:49 AM, Peyman Owladi -X (powladi - Ensoft =
Ltd at Cisco) <span dir=3D"ltr">&lt;<a href=3D"mailto:powladi@cisco.com" ta=
rget=3D"_blank">powladi@cisco.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">&gt; -----Original Message-----<br>
&gt; From: Martin Bjorklund [mailto:<a href=3D"mailto:mbj@tail-f.com">mbj@t=
ail-f.com</a>]<br>
&gt; Sent: 08 May 2014 11:02<br>
&gt; To: <a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a><br>
&gt; Cc: <a href=3D"mailto:powladi@cisco.com">powladi@cisco.com</a>; <a hre=
f=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; Subject: Y53: YANG 1.1 Key Flexibility<br>
&gt;<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; These topics were debated at length during the development of RFC=
 6020.<br>
&gt; &gt; It was determined that (a) not only should keys be simple leafs t=
hat are<br>
&gt; &gt; children of the list, but (b) the key leafs must be encoded on th=
e wire<br>
&gt; &gt; before any other child nodes, in order to improve server performa=
nce.<br>
&gt; &gt;<br>
&gt; &gt; Nested leafs, containers full of whatever as keys, and variable n=
umbers<br>
&gt; &gt; of keys via choice-stmt would make YANG too complicated to be imp=
lemented<br>
&gt; &gt; efficiently in servers. =A0N/Y is already very heavy-weight to im=
plement.<br>
&gt; &gt; This would make it much worse.<br>
&gt;<br>
&gt; I fully agree.<br>
<br>
Fair enough; thanks for the explanation.<br>
<br>
It would still be useful to get some thoughts on what the solution should b=
e for issue 2 in the original mail (copied here for reference):<br>
=3D=3D=3D=3D=3D=3D<br>
A list entry may have a key which is a union; i.e. it is indexed by a singl=
e value which is one of multiple types. However, a YANG union is not always=
 sufficient to model a choice between a set of types.<br>
<br>
Take the following case for example:<br>
<br>
choice maintenance-domain-identifier {<br>
=A0 leaf host { type inet:host; }<br>
=A0 leaf id =A0 { type hex-string; }<br>
=A0 leaf name { type string; }<br>
}<br>
<br></blockquote><div><br></div><div><br></div><div><br></div>typedef maint=
enance-domain-identifier {</div><div class=3D"gmail_quote">=A0 type union {=
<br>=A0 =A0 type inet:host;=A0<br>=A0 =A0 type hex-string;=A0<br>=A0 =A0 ty=
pe string;=A0<br>
=A0 }</div><div class=3D"gmail_quote">}</div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">This=
 is legal YANG.</div><div class=3D"gmail_quote">Figuring out which type-stm=
t matched is an implementation detail.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">Andy</div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote"><div><br></div><div><br></div><div><br></div><div>=
=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I&#39;m not sure whether this is even compatible with the &q=
uot;CLI&quot; comment in Y09-01):<br>

=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
=A0 key &quot;host id name&quot;;<br>
=A0 leaf host { type inet:host; =A0mandatory false; }<br>
=A0 leaf id =A0 { type hex-string; mandatory false; }<br>
=A0 leaf name { type string; =A0 =A0 mandatory false; }<br>
<br>
=A0 // Rule to ensure exactly one of the above is specified<br>
=A0 must &quot;count(host) + count(id) + count(name) =3D 1&quot;;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>

<br>
Thanks,<br>
Peyman<br>
<br>
</blockquote></div><br></div></div>

--001a11c126ba7d421a04f8e3f680--


From nobody Thu May  8 08:12:42 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8746A1A005E for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 08:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.551
X-Spam-Level: 
X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M44SPOyvxsb1 for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 08:12:35 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 017761A0057 for <netmod@ietf.org>; Thu,  8 May 2014 08:12:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15651; q=dns/txt; s=iport; t=1399561950; x=1400771550; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vq0e45uJX6XojVD2vYQV9uaIdXyJ530R8R7USFfv/fs=; b=d8y3L8nIbS2s/RcfrfkWb+23RKEfyS7EhROye61iWeIZ8qz/EozMEA4m +X9KYz8i/UQgGuBx1KjYcUpmhIpuy25gYPpWUsTlwpWq9WB+UxhTV4G4c +DTmji6VB8AJBOQmOwOA4TTvmZw48TxIXVoQZuS2gwlSm5hx/apJaloQW Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFACWea1OtJV2Y/2dsb2JhbABZgkJET1jFYQGBExZ0giUBAQEELUwMBAIBCBEEAQEBCh0HMhQJCAIEDgUIE4gm0CUXiTGEUAEBHjEGAQaDJIEVBIV2j0uWcoM2gW8HFwYc
X-IronPort-AV: E=Sophos;i="4.97,1010,1389744000";  d="scan'208,217";a="42137412"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 08 May 2014 15:12:29 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s48FCTvo016812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 15:12:29 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 8 May 2014 10:12:29 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: Y53: YANG 1.1 Key Flexibility
Thread-Index: AQDqlaWLAxII9M2UdJcD6jdSAOWzIAGT5jcmAY5vUDwCXvmZxQFYRSpqnMmnZpA=
Date: Thu, 8 May 2014 15:12:29 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AB0C2D@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com> <20140508.120143.1962717862150015233.mbj@tail-f.com> <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com> <CABCOCHQNysSSgV51MApPCVcc4GWQLHS3w=3+SgiQYzWv80NdKw@mail.gmail.com>
In-Reply-To: <CABCOCHQNysSSgV51MApPCVcc4GWQLHS3w=3+SgiQYzWv80NdKw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.168]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AB0C2Dxmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/llCYkPtswR09BmFNrq3JkmmMOV4
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 15:12:39 -0000

--_000_013A9B371AC6DF4C8AD261897D8F243E10AB0C2Dxmbalnx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: 08 May 2014 15:05
To: Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)
Cc: Martin Bjorklund; netmod@ietf.org
Subject: Re: Y53: YANG 1.1 Key Flexibility



On Thu, May 8, 2014 at 6:49 AM, Peyman Owladi -X (powladi - Ensoft Ltd at C=
isco) <powladi@cisco.com<mailto:powladi@cisco.com>> wrote:
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com<mailto:mbj@tail-f.com>]
> Sent: 08 May 2014 11:02
> To: andy@yumaworks.com<mailto:andy@yumaworks.com>
> Cc: powladi@cisco.com<mailto:powladi@cisco.com>; netmod@ietf.org<mailto:n=
etmod@ietf.org>
> Subject: Y53: YANG 1.1 Key Flexibility
>
> Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:
> > Hi,
> >
> > These topics were debated at length during the development of RFC 6020.
> > It was determined that (a) not only should keys be simple leafs that ar=
e
> > children of the list, but (b) the key leafs must be encoded on the wire
> > before any other child nodes, in order to improve server performance.
> >
> > Nested leafs, containers full of whatever as keys, and variable numbers
> > of keys via choice-stmt would make YANG too complicated to be implement=
ed
> > efficiently in servers.  N/Y is already very heavy-weight to implement.
> > This would make it much worse.
>
> I fully agree.

Fair enough; thanks for the explanation.

It would still be useful to get some thoughts on what the solution should b=
e for issue 2 in the original mail (copied here for reference):
=3D=3D=3D=3D=3D=3D
A list entry may have a key which is a union; i.e. it is indexed by a singl=
e value which is one of multiple types. However, a YANG union is not always=
 sufficient to model a choice between a set of types.

Take the following case for example:

choice maintenance-domain-identifier {
  leaf host { type inet:host; }
  leaf id   { type hex-string; }
  leaf name { type string; }
}



typedef maintenance-domain-identifier {
  type union {
    type inet:host;
    type hex-string;
    type string;
  }
}


This is legal YANG.
Figuring out which type-stmt matched is an implementation detail.


Andy


To check we're on the same page, my understanding is that in that union, if=
 a specifier matches the domain-name pattern, it would always resolve to th=
e inet:host type (based on RFC 6020 9.2: "When a string representing a unio=
n data type is validated, the string is validated against each member type,=
 in the order they are specified in the "type" statement, until a match is =
found.") -- though I could be misunderstanding what "validated" means here.


In any case, this question arises because there can be overlap in the value=
 space of the different elements; so as well as the value itself, we need t=
he information on which of the options is being represented to interpret th=
e data correctly.

Based on that, it looks like the data needs to be represented as a choice o=
r as independent leaves rather than a union, right?



Thanks,

Peyman

These strings can be overlapping, so this cannot be represented as a union.
=3D=3D=3D=3D=3D=3D

Do you have thoughts on how this should be modelled (and if extensions are =
needed)?

In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a "must" statement =
(and I'm not sure whether this is even compatible with the "CLI" comment in=
 Y09-01):
=3D=3D=3D=3D=3D=3D
list maintenance-domains {
  key "host id name";
  leaf host { type inet:host;  mandatory false; }
  leaf id   { type hex-string; mandatory false; }
  leaf name { type string;     mandatory false; }

  // Rule to ensure exactly one of the above is specified
  must "count(host) + count(id) + count(name) =3D 1";
}
=3D=3D=3D=3D=3D=3D

Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)

Thanks,
Peyman


--_000_013A9B371AC6DF4C8AD261897D8F243E10AB0C2Dxmbalnx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";
	mso-fareast-language:EN-GB;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=
:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=
D"><o:p>&nbsp;</o:p></span></a></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><b><span lang=3D"EN-US"=
 style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&=
quot;">From:</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Andy Bierman [mailto:and=
y@yumaworks.com]
<br>
<b>Sent:</b> 08 May 2014 15:05<br>
<b>To:</b> Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)<br>
<b>Cc:</b> Martin Bjorklund; netmod@ietf.org<br>
<b>Subject:</b> Re: Y53: YANG 1.1 Key Flexibility<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar=
gin-bottom:12.0pt;margin-left:36.0pt">
<o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">On Thu, May 8, 2014 at =
6:49 AM, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) &lt;<a href=3D"ma=
ilto:powladi@cisco.com" target=3D"_blank">powladi@cisco.com</a>&gt; wrote:<=
o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar=
gin-bottom:12.0pt;margin-left:36.0pt">
&gt; -----Original Message-----<br>
&gt; From: Martin Bjorklund [mailto:<a href=3D"mailto:mbj@tail-f.com">mbj@t=
ail-f.com</a>]<br>
&gt; Sent: 08 May 2014 11:02<br>
&gt; To: <a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com</a><br>
&gt; Cc: <a href=3D"mailto:powladi@cisco.com">powladi@cisco.com</a>; <a hre=
f=3D"mailto:netmod@ietf.org">
netmod@ietf.org</a><br>
&gt; Subject: Y53: YANG 1.1 Key Flexibility<br>
&gt;<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; These topics were debated at length during the development of RFC=
 6020.<br>
&gt; &gt; It was determined that (a) not only should keys be simple leafs t=
hat are<br>
&gt; &gt; children of the list, but (b) the key leafs must be encoded on th=
e wire<br>
&gt; &gt; before any other child nodes, in order to improve server performa=
nce.<br>
&gt; &gt;<br>
&gt; &gt; Nested leafs, containers full of whatever as keys, and variable n=
umbers<br>
&gt; &gt; of keys via choice-stmt would make YANG too complicated to be imp=
lemented<br>
&gt; &gt; efficiently in servers. &nbsp;N/Y is already very heavy-weight to=
 implement.<br>
&gt; &gt; This would make it much worse.<br>
&gt;<br>
&gt; I fully agree.<br>
<br>
Fair enough; thanks for the explanation.<br>
<br>
It would still be useful to get some thoughts on what the solution should b=
e for issue 2 in the original mail (copied here for reference):<br>
=3D=3D=3D=3D=3D=3D<br>
A list entry may have a key which is a union; i.e. it is indexed by a singl=
e value which is one of multiple types. However, a YANG union is not always=
 sufficient to model a choice between a set of types.<br>
<br>
Take the following case for example:<br>
<br>
choice maintenance-domain-identifier {<br>
&nbsp; leaf host { type inet:host; }<br>
&nbsp; leaf id &nbsp; { type hex-string; }<br>
&nbsp; leaf name { type string; }<br>
}<o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">typedef maintenance-dom=
ain-identifier {<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; type union {<br>
&nbsp; &nbsp; type inet:host;&nbsp;<br>
&nbsp; &nbsp; type hex-string;&nbsp;<br>
&nbsp; &nbsp; type string;&nbsp;<br>
&nbsp; }<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">}<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">This is legal YANG.<o:p=
></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Figuring out which type=
-stmt matched is an implementation detail.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Andy<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
F497D"><o:p>&nbsp;</o:p></span></p>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">To check=
 we're on the same page, my understanding is that in that union, if a speci=
fier matches the domain-name pattern, it would always resolve to the inet:h=
ost type (based on RFC 6020 9.2: &quot;</span><span style=3D"color:black">W=
hen a string representing a union data type is validated, the string is val=
idated against each member type, in the order they are specified in the &qu=
ot;type&quot; statement, until a match is found.</span><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1=
F497D">&quot;) -- though I could be misunderstanding what &quot;validated&q=
uot; means here.<o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nb=
sp;</o:p></span></pre>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In any case, this questio=
n arises because there can be overlap in the value space of the different e=
lements; so as well as the value itself, we need the information
 on which of the options is being represented to interpret the data correct=
ly.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Based on that, it looks l=
ike the data needs to be represented as a choice or as independent leaves r=
ather than a union, right?<o:p></o:p></span></p>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nb=
sp;</o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<=
o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:11.0pt;fon=
t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peyman<o=
:p></o:p></span></pre>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar=
gin-bottom:12.0pt;margin-left:36.0pt">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I'm not sure whether this is even compatible with the &quot;=
CLI&quot; comment in Y09-01):<br>
=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
&nbsp; key &quot;host id name&quot;;<br>
&nbsp; leaf host { type inet:host; &nbsp;mandatory false; }<br>
&nbsp; leaf id &nbsp; { type hex-string; mandatory false; }<br>
&nbsp; leaf name { type string; &nbsp; &nbsp; mandatory false; }<br>
<br>
&nbsp; // Rule to ensure exactly one of the above is specified<br>
&nbsp; must &quot;count(host) &#43; count(id) &#43; count(name) =3D 1&quot;=
;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>
<br>
Thanks,<br>
Peyman<o:p></o:p></p>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AB0C2Dxmbalnx08ciscoc_--


From nobody Thu May  8 08:33:31 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F5A1A006A for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 08:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoIVUwDPOwZc for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 08:33:26 -0700 (PDT)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id A76E61A004E for <netmod@ietf.org>; Thu,  8 May 2014 08:33:26 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id x13so3102498qcv.30 for <netmod@ietf.org>; Thu, 08 May 2014 08:33:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dQIRPmZbjg/99sCouTGCJv0FAk8WucF5C+dwIXQWRMw=; b=QhZY/KzR64T+QwnDQ9r/SRZFy5Vhl70u1wxuaIfrqB3c2fvAwcslbTQO55xpS2HwHe gmMjU/RUQVX823hXWHw83sxTIDOnV2lis916MtxEc7Ufa20lsCJoUzvv8PbGJURc/BDw rbt56jkfWskCSeSdb0axf/ZODjXwvXfcBbGpl4HTkZbCfmmU28SukWTpFUWfshhxKQRy Ecl3pcm1owl83gDn5V+MLfri4pY3hPUMUphHE4tdaIq9xMRY7SvA7TaVlqW6kkXsEEkf hyIdZAtKw4NLg1yg8VNxBjAQKZaWzRwZ+hfsZXIGiXIhxNXDAXUcU71+rK9o9b4cSXNB 6CYw==
X-Gm-Message-State: ALoCoQma1PsAnbgJgcBBdnsaIl9VmAnWDgHL7wf0vTaMFTPJBrU5rvCRe4UFNEWv6o5xSzOOFG53
MIME-Version: 1.0
X-Received: by 10.224.55.6 with SMTP id s6mr5890871qag.7.1399563201959; Thu, 08 May 2014 08:33:21 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 8 May 2014 08:33:21 -0700 (PDT)
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AB0C2D@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com> <20140508.120143.1962717862150015233.mbj@tail-f.com> <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com> <CABCOCHQNysSSgV51MApPCVcc4GWQLHS3w=3+SgiQYzWv80NdKw@mail.gmail.com> <013A9B371AC6DF4C8AD261897D8F243E10AB0C2D@xmb-aln-x08.cisco.com>
Date: Thu, 8 May 2014 08:33:21 -0700
Message-ID: <CABCOCHQUWHL9jnSQR9wGW_YHJ=Ok_-b-wTQXcm8UVJT30x=38g@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
Content-Type: multipart/alternative; boundary=089e0153705e7e9c8f04f8e533e2
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1DxXXO5HIWuDwrAEFmDDWnWJEik
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 May 2014 15:33:28 -0000

--089e0153705e7e9c8f04f8e533e2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, May 8, 2014 at 8:12 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <powladi@cisco.com> wrote:

>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* 08 May 2014 15:05
> *To:* Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)
> *Cc:* Martin Bjorklund; netmod@ietf.org
> *Subject:* Re: Y53: YANG 1.1 Key Flexibility
>
>
>
>
>
>
>
> On Thu, May 8, 2014 at 6:49 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
> Cisco) <powladi@cisco.com> wrote:
>
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > Sent: 08 May 2014 11:02
> > To: andy@yumaworks.com
> > Cc: powladi@cisco.com; netmod@ietf.org
> > Subject: Y53: YANG 1.1 Key Flexibility
> >
> > Andy Bierman <andy@yumaworks.com> wrote:
> > > Hi,
> > >
> > > These topics were debated at length during the development of RFC 602=
0.
> > > It was determined that (a) not only should keys be simple leafs that
> are
> > > children of the list, but (b) the key leafs must be encoded on the wi=
re
> > > before any other child nodes, in order to improve server performance.
> > >
> > > Nested leafs, containers full of whatever as keys, and variable numbe=
rs
> > > of keys via choice-stmt would make YANG too complicated to be
> implemented
> > > efficiently in servers.  N/Y is already very heavy-weight to implemen=
t.
> > > This would make it much worse.
> >
> > I fully agree.
>
> Fair enough; thanks for the explanation.
>
> It would still be useful to get some thoughts on what the solution should
> be for issue 2 in the original mail (copied here for reference):
> =3D=3D=3D=3D=3D=3D
> A list entry may have a key which is a union; i.e. it is indexed by a
> single value which is one of multiple types. However, a YANG union is not
> always sufficient to model a choice between a set of types.
>
> Take the following case for example:
>
> choice maintenance-domain-identifier {
>   leaf host { type inet:host; }
>   leaf id   { type hex-string; }
>   leaf name { type string; }
> }
>
>
>
>
>
>
>
> typedef maintenance-domain-identifier {
>
>   type union {
>     type inet:host;
>     type hex-string;
>     type string;
>   }
>
> }
>
>
>
>
>
> This is legal YANG.
>
> Figuring out which type-stmt matched is an implementation detail.
>
>
>
>
>
> Andy
>
>
>
> To check we're on the same page, my understanding is that in that union, =
if a specifier matches the domain-name pattern, it would always resolve to =
the inet:host type (based on RFC 6020 9.2: "When a string representing a un=
ion data type is validated, the string is validated against each member typ=
e, in the order they are specified in the "type" statement, until a match i=
s found.") -- though I could be misunderstanding what "validated" means her=
e.
>
>
>
> In any case, this question arises because there can be overlap in the
> value space of the different elements; so as well as the value itself, we
> need the information on which of the options is being represented to
> interpret the data correctly.
>


A union type is like a logical-OR expression.
The YANG validation tool goes through each 'type' in order and checks
if the supplied value is valid for that type.  If so, then the leaf is
valid.
If the parser gets to end of the list and none of the types have validated
for the supplied value, then the leaf is rejected with an invalid-value
error-tag.

So you want to place the most selective patterns first, and the catch-all
'string' last.
It is an implementation detail how the union type is represented within the
server.

   leaf maintenance-domain {
       type maintenance-domain-identifier;
   }


>
> Based on that, it looks like the data needs to be represented as a choice
> or as independent leaves rather than a union, right?
>
>
>
>
No


>  Thanks,
>
> Peyman
>
>
Andy



>
>
>  These strings can be overlapping, so this cannot be represented as a
> union.
> =3D=3D=3D=3D=3D=3D
>
> Do you have thoughts on how this should be modelled (and if extensions ar=
e
> needed)?
>
> In particular, it seems there is a solution using Y09-01, though to do
> this we effectively have to reinvent the choice/union using a "must"
> statement (and I'm not sure whether this is even compatible with the "CLI=
"
> comment in Y09-01):
> =3D=3D=3D=3D=3D=3D
> list maintenance-domains {
>   key "host id name";
>   leaf host { type inet:host;  mandatory false; }
>   leaf id   { type hex-string; mandatory false; }
>   leaf name { type string;     mandatory false; }
>
>   // Rule to ensure exactly one of the above is specified
>   must "count(host) + count(id) + count(name) =3D 1";
> }
> =3D=3D=3D=3D=3D=3D
>
> Is that the best approach, or is there a better answer? (For example,
> introducing a union type with a discriminator would perhaps work as it
> would allow the above to be modelled as a union and therefore used as a
> key.)
>
> Thanks,
> Peyman
>
>
>

--089e0153705e7e9c8f04f8e533e2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, May 8, 2014 at 8:12 AM, Peyman Owladi -X (powladi - Ensoft =
Ltd at Cisco) <span dir=3D"ltr">&lt;<a href=3D"mailto:powladi@cisco.com" ta=
rget=3D"_blank">powladi@cisco.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><a name=3D"145dc6496d41d461__MailEndCompose"><span s=
tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=
uot;;color:#1f497d"><u></u>=A0<u></u></span></a></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><b><span lang=3D"EN-US"=
 style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&=
quot;">From:</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Andy Bierman [mailto:<a =
href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaworks.com</a>=
]
<br>
<b>Sent:</b> 08 May 2014 15:05<br>
<b>To:</b> Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)<br>
<b>Cc:</b> Martin Bjorklund; <a href=3D"mailto:netmod@ietf.org" target=3D"_=
blank">netmod@ietf.org</a><br>
<b>Subject:</b> Re: Y53: YANG 1.1 Key Flexibility<u></u><u></u></span></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi=
n-left:36.0pt">
<u></u>=A0<u></u></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">On Thu, May 8, 2014 at =
6:49 AM, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) &lt;<a href=3D"ma=
ilto:powladi@cisco.com" target=3D"_blank">powladi@cisco.com</a>&gt; wrote:<=
u></u><u></u></p>

<p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi=
n-left:36.0pt">
&gt; -----Original Message-----<br>
&gt; From: Martin Bjorklund [mailto:<a href=3D"mailto:mbj@tail-f.com" targe=
t=3D"_blank">mbj@tail-f.com</a>]<br>
&gt; Sent: 08 May 2014 11:02<br>
&gt; To: <a href=3D"mailto:andy@yumaworks.com" target=3D"_blank">andy@yumaw=
orks.com</a><br>
&gt; Cc: <a href=3D"mailto:powladi@cisco.com" target=3D"_blank">powladi@cis=
co.com</a>; <a href=3D"mailto:netmod@ietf.org" target=3D"_blank">
netmod@ietf.org</a><br>
&gt; Subject: Y53: YANG 1.1 Key Flexibility<br>
&gt;<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com" target=3D"_blan=
k">andy@yumaworks.com</a>&gt; wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt;<br>
&gt; &gt; These topics were debated at length during the development of RFC=
 6020.<br>
&gt; &gt; It was determined that (a) not only should keys be simple leafs t=
hat are<br>
&gt; &gt; children of the list, but (b) the key leafs must be encoded on th=
e wire<br>
&gt; &gt; before any other child nodes, in order to improve server performa=
nce.<br>
&gt; &gt;<br>
&gt; &gt; Nested leafs, containers full of whatever as keys, and variable n=
umbers<br>
&gt; &gt; of keys via choice-stmt would make YANG too complicated to be imp=
lemented<br>
&gt; &gt; efficiently in servers. =A0N/Y is already very heavy-weight to im=
plement.<br>
&gt; &gt; This would make it much worse.<br>
&gt;<br>
&gt; I fully agree.<br>
<br>
Fair enough; thanks for the explanation.<br>
<br>
It would still be useful to get some thoughts on what the solution should b=
e for issue 2 in the original mail (copied here for reference):<br>
=3D=3D=3D=3D=3D=3D<br>
A list entry may have a key which is a union; i.e. it is indexed by a singl=
e value which is one of multiple types. However, a YANG union is not always=
 sufficient to model a choice between a set of types.<br>
<br>
Take the following case for example:<br>
<br>
choice maintenance-domain-identifier {<br>
=A0 leaf host { type inet:host; }<br>
=A0 leaf id =A0 { type hex-string; }<br>
=A0 leaf name { type string; }<br>
}<u></u><u></u></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">typedef maintenance-dom=
ain-identifier {<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">=A0 type union {<br>
=A0 =A0 type inet:host;=A0<br>
=A0 =A0 type hex-string;=A0<br>
=A0 =A0 type string;=A0<br>
=A0 }<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">}<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">This is legal YANG.<u><=
/u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Figuring out which type=
-stmt matched is an implementation detail.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Andy<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
f497d"><u></u>=A0<u></u></span></p>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d">To check we&#39;re on the same page, my und=
erstanding is that in that union, if a specifier matches the domain-name pa=
ttern, it would always resolve to the inet:host type (based on RFC 6020 9.2=
: &quot;</span><span style=3D"color:black">When a string representing a uni=
on data type is validated, the string is validated against each member type=
, in the order they are specified in the &quot;type&quot; statement, until =
a match is found.</span><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1f497d">&quot;) -- though I coul=
d be misunderstanding what &quot;validated&quot; means here.<u></u><u></u><=
/span></pre>

<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span></pre>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">In any case, this questio=
n arises because there can be overlap in the value space of the different e=
lements; so as well as the value itself, we need the information
 on which of the options is being represented to interpret the data correct=
ly.</span></p></div></div></div></div></div></blockquote><div><br></div><di=
v><br></div><div>A union type is like a logical-OR expression.</div><div>
The YANG validation tool goes through each &#39;type&#39; in order and chec=
ks</div><div>if the supplied value is valid for that type. =A0If so, then t=
he leaf is valid.</div><div>If the parser gets to end of the list and none =
of the types have validated</div>
<div>for the supplied value, then the leaf is rejected with an invalid-valu=
e error-tag.</div><div><br></div><div>So you want to place the most selecti=
ve patterns first, and the catch-all &#39;string&#39; last.</div><div>It is=
 an implementation detail how the union type is represented within the serv=
er.</div>
<div><br></div><div>=A0 =A0leaf maintenance-domain {</div><div>=A0 =A0 =A0 =
=A0type maintenance-domain-identifier;</div><div>=A0 =A0}</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"><div><div><div><div><p c=
lass=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibr=
i&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Based on that, it looks l=
ike the data needs to be represented as a choice or as independent leaves r=
ather than a union, right?<u></u><u></u></span></p>

<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d"><u></u>=A0</span></pre></div></div></div></=
div></div></blockquote><div><br></div><div>No</div><div>=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"><div><div><div><div><pre=
><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans=
-serif&quot;;color:#1f497d"><u></u></span></pre>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d">Thanks,<u></u><u></u></span></pre>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d">Peyman<u></u><u></u></span></pre>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"></p></div></div></div><=
/div></div></div></blockquote><div><br></div><div>Andy</div><div><br></div>=
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"><div><div><div><div><div=
><p class=3D"MsoNormal" style=3D"margin-left:36.0pt">=A0<u></u><u></u></p>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class=3D"MsoNormal" style=3D"margin-right:0cm;margin-bottom:12.0pt;margi=
n-left:36.0pt">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I&#39;m not sure whether this is even compatible with the &q=
uot;CLI&quot; comment in Y09-01):<br>

=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
=A0 key &quot;host id name&quot;;<br>
=A0 leaf host { type inet:host; =A0mandatory false; }<br>
=A0 leaf id =A0 { type hex-string; mandatory false; }<br>
=A0 leaf name { type string; =A0 =A0 mandatory false; }<br>
<br>
=A0 // Rule to ensure exactly one of the above is specified<br>
=A0 must &quot;count(host) + count(id) + count(name) =3D 1&quot;;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>

<br>
Thanks,<br>
Peyman<u></u><u></u></p>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>=A0<u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div><br></div></div>

--089e0153705e7e9c8f04f8e533e2--


From nobody Thu May  8 19:50:12 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD131A0143 for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 19:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz6vEcefkp0q for <netmod@ietfa.amsl.com>; Thu,  8 May 2014 19:50:07 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45E1A0139 for <netmod@ietf.org>; Thu,  8 May 2014 19:50:07 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id e16so3833055qcx.41 for <netmod@ietf.org>; Thu, 08 May 2014 19:50:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RJQUJF+Vr+kQBZeTHtPNLqyiyKjcWXoEOz5/L8NHkJs=; b=CuJ9Fjpqmvy7MW4kGBfEZeInOQ1TQHJtoTxgpQhH856Yx1HnknEPx9PAkRMToeXD7e c8nLzPXZRQQqfp/67WVG/Rjvj0VEPgqlXKUKNR8cl43CMO7vhLinlaaAAbNR7jZJDxuc H/QdqcQvPaM18ehnKOkW78sL1qvOOtIsHJCV/YQyXZQ4VC1yd83Hm3UuWauPCBLJcs56 RIPJT2piEDJ2PeZXwj3UvBxvrNDB5FN+Iw9pvTCnHb/lFxJgKUAlJDvjTA0QQwXJzaAM xo2UE6Sy9H8UPrxTu4ABaAIvhOk+FcWppN5/ncFsvoOqqOfom7gNaManhWwr5iTB3kvA A4nA==
X-Gm-Message-State: ALoCoQkzOd9/1JYnWX7kLnv2wZair3NovAqgIbFQ4aPgf4J+Gdmoh90/xY0S9h/GecRGhYcleZuj
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr9970826qgo.25.1399603802502; Thu, 08 May 2014 19:50:02 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 8 May 2014 19:50:02 -0700 (PDT)
In-Reply-To: <20140508.095426.686508493610810924.mbj@tail-f.com>
References: <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com> <20140507.222120.122843926.mbj@tail-f.com> <A543A9BC-9F1A-4154-8CBB-B0A52EC9C3EB@nic.cz> <20140508.095426.686508493610810924.mbj@tail-f.com>
Date: Thu, 8 May 2014 19:50:02 -0700
Message-ID: <CABCOCHSocNhJob91_4UsNBvDC5rp7=QDGNNtNFeVGqkkGkrCaA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary=001a11c17334798c9b04f8eea77c
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/outSrHHnGNAbimYGUEeMdoxb0-U
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 02:50:10 -0000

--001a11c17334798c9b04f8eea77c
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 8, 2014 at 12:54 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 07 May 2014, at 22:21, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > > Andy Bierman <andy@yumaworks.com> wrote:
> > >> On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <mbj@tail-f.com>
> > >> wrote:
> > >>> I am confused.   There are no additional namespaces today - just one,
> > >>> introduced by the module.  What did you agree on?
> > >>>
> > >>>
> > >> There are 2 issues -- we agree on 1
> > >>
> > >> 1) how to indicate that submodule contents are exported from the main
> > >> module
> > >>     to external modules?
> > >>
> > >>    a) include must be in main module
> > >>    b) include must be in main module or submodule
> > >>
> > >> 2) what definitions are visible within a submodule?
> > >>
> > >>    a) only self and includes
> > >>    b) main module, self, and includes
> > >
> > > Thank you, this is a clear summary of the alternatives.
> > >
> > > I think we were all over the map when we discussed this during the
> > > initial design of YANG.  We looked at all these alternatives, and
> > > ended up with what we have today.  I'll go back and look in the
> > > archives to see how much of the discussions are captured.
> >
> > I wasn't there. :-)
> >
> > >
> > > One design rule we had was that we wanted it to be possible to compile
> > > / check each submodule on its own (only follow explicit
> > > import/include), w/o having to bring in the complete module.  With
> > > option 2b, this is no longer possible.
> >
> > I don't think this is important - the top-level definitions from the
> > main module and all submodules are easy to look up. On the other hand,
> > submodules cannot use conflicting names even if they don't include
> > each other, so it doesn't help submodule writers in this respect.
> >
> > >
> > > Re. issue 1, it seems to me no real problem is solved by going from 1a
> > > to 1b.
> >
> > I agree. It would be different if a submodule tree could be grafted to
> > a non-root node, but it is not the case.
> >
> > >
> > > Re. issue 2, solution 2b actually solves a real problem - today you
> > > have to place common definitions in a separate submodule; they cannot
> > > go into the main module.  Since circular includes are not possible,
> > > references within a module (across submodules) have to be done
> > > carefully, and might impose a non-intuitive submodule design.
> >
> > Right, this is a serious contender for the most peculiar rule in YANG.
> >
> > >
> > > So I think we need to think more about this, but solution 2b seems
> > > attractive to me.
> >
> > With 1a, the following is a logical option:
> >
> > 2c) main module and all submodules included from it.
>
> Yes, that's how I interpreted 2b!  Essentially each submodule has
> access to all definitions in all other submodules.
>
>
This is what I wanted from the start.
That is why I do not agree that the include-stmts need to be in the main
module.

module A {
   prefix a;
   include B;
   container foo;
 }
 submodule B {
    belongs-to A { prefix a; }
    include C;
 }
 submodule C {
    belongs-to A { prefix a; }
    leaf top { type string; }
    augment /a:foo {
       leaf should-be-ok { type string; }
     }
 }

IMO, the include-stmts just say "go find this file and add all the
definitions to the module namespace". Therefore, leaf 'top'
is visible in the main module and also to external modules.
This is the detail we do not agree on.  Forcing the include-stmt
to also appear in the main module seems like a CLR.

It is not really OK to declare that submodules can use definitions
without include-stmts, unless we don't care about the self-compiling
sub-modules. (IMO a real low priority). If so, then it is also
OK to allow submodules to access the main module definitions.


> /martin
>

Andy

--001a11c17334798c9b04f8eea77c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, May 8, 2014 at 12:54 AM, Martin Bjorklund <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ladislav Lhotka &lt;<a href=3D"mailto:lhotka=
@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 07 May 2014, at 22:21, Martin Bjorklund &lt;<a href=3D"mailto:mbj@t=
ail-f.com">mbj@tail-f.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaw=
orks.com</a>&gt; wrote:<br>
&gt; &gt;&gt; On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund &lt;<a href=
=3D"mailto:mbj@tail-f.com">mbj@tail-f.com</a>&gt;<br>
&gt; &gt;&gt; wrote:<br>
&gt; &gt;&gt;&gt; I am confused. &nbsp; There are no additional namespaces =
today - just one,<br>
&gt; &gt;&gt;&gt; introduced by the module. &nbsp;What did you agree on?<br=
>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt; There are 2 issues -- we agree on 1<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 1) how to indicate that submodule contents are exported from =
the main<br>
&gt; &gt;&gt; module<br>
&gt; &gt;&gt; &nbsp; &nbsp; to external modules?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &nbsp; &nbsp;a) include must be in main module<br>
&gt; &gt;&gt; &nbsp; &nbsp;b) include must be in main module or submodule<b=
r>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 2) what definitions are visible within a submodule?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &nbsp; &nbsp;a) only self and includes<br>
&gt; &gt;&gt; &nbsp; &nbsp;b) main module, self, and includes<br>
&gt; &gt;<br>
&gt; &gt; Thank you, this is a clear summary of the alternatives.<br>
&gt; &gt;<br>
&gt; &gt; I think we were all over the map when we discussed this during th=
e<br>
&gt; &gt; initial design of YANG. &nbsp;We looked at all these alternatives=
, and<br>
&gt; &gt; ended up with what we have today. &nbsp;I&#39;ll go back and look=
 in the<br>
&gt; &gt; archives to see how much of the discussions are captured.<br>
&gt;<br>
&gt; I wasn&rsquo;t there. :-)<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; One design rule we had was that we wanted it to be possible to co=
mpile<br>
&gt; &gt; / check each submodule on its own (only follow explicit<br>
&gt; &gt; import/include), w/o having to bring in the complete module. &nbs=
p;With<br>
&gt; &gt; option 2b, this is no longer possible.<br>
&gt;<br>
&gt; I don&rsquo;t think this is important - the top-level definitions from=
 the<br>
&gt; main module and all submodules are easy to look up. On the other hand,=
<br>
&gt; submodules cannot use conflicting names even if they don&rsquo;t inclu=
de<br>
&gt; each other, so it doesn&rsquo;t help submodule writers in this respect=
.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Re. issue 1, it seems to me no real problem is solved by going fr=
om 1a<br>
&gt; &gt; to 1b.<br>
&gt;<br>
&gt; I agree. It would be different if a submodule tree could be grafted to=
<br>
&gt; a non-root node, but it is not the case.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Re. issue 2, solution 2b actually solves a real problem - today y=
ou<br>
&gt; &gt; have to place common definitions in a separate submodule; they ca=
nnot<br>
&gt; &gt; go into the main module. &nbsp;Since circular includes are not po=
ssible,<br>
&gt; &gt; references within a module (across submodules) have to be done<br=
>
&gt; &gt; carefully, and might impose a non-intuitive submodule design.<br>
&gt;<br>
&gt; Right, this is a serious contender for the most peculiar rule in YANG.=
<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; So I think we need to think more about this, but solution 2b seem=
s<br>
&gt; &gt; attractive to me.<br>
&gt;<br>
&gt; With 1a, the following is a logical option:<br>
&gt;<br>
&gt; 2c) main module and all submodules included from it.<br>
<br>
Yes, that&#39;s how I interpreted 2b! &nbsp;Essentially each submodule has<=
br>
access to all definitions in all other submodules.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>This is what I wanted from the start.</div><div>That=
 is why I do not agree that the include-stmts need to be in the main module=
.</div>
<div><br></div><div>module A {</div><div>&nbsp; &nbsp;prefix a;</div><div>&=
nbsp; &nbsp;include B;</div><div>&nbsp; &nbsp;container foo;</div><div>&nbs=
p;}</div><div>&nbsp;submodule B {</div><div>&nbsp; &nbsp; belongs-to A { pr=
efix a; }</div><div>&nbsp; &nbsp; include C;</div><div>&nbsp;}</div>
<div>&nbsp;submodule C {</div><div>&nbsp; &nbsp; belongs-to A { prefix a; }=
</div><div>&nbsp; &nbsp; leaf top { type string; }</div><div>&nbsp; &nbsp; =
augment /a:foo {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;leaf should-be-ok { t=
ype string; }</div><div>&nbsp; &nbsp; &nbsp;}</div><div>&nbsp;}</div><div>
<br></div><div>IMO, the include-stmts just say &quot;go find this file and =
add all the</div><div>definitions to the module namespace&quot;. Therefore,=
 leaf &#39;top&#39;</div><div>is visible in the main module and also to ext=
ernal modules.</div>
<div>This is the detail we do not agree on. &nbsp;Forcing the include-stmt<=
/div><div>to also appear in the main module seems like a CLR.</div><div><br=
></div><div>It is not really OK to declare that submodules can use definiti=
ons</div>
<div>without include-stmts, unless we don&#39;t care about the self-compili=
ng</div><div>sub-modules. (IMO a real low priority). If so, then it is also=
</div><div>OK to allow submodules to access the main module definitions.</d=
iv>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font =
color=3D"#888888">
<br>
/martin<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Andy<=
/div><div class=3D"gmail_extra"><br></div></div>

--001a11c17334798c9b04f8eea77c--


From nobody Thu May  8 23:49:48 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71C1A01F4; Thu,  8 May 2014 23:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP_c3USTSg0h; Thu,  8 May 2014 23:49:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C84211A01EE; Thu,  8 May 2014 23:49:44 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 99FEA384004; Fri,  9 May 2014 08:49:38 +0200 (CEST)
Date: Fri, 09 May 2014 08:49:38 +0200 (CEST)
Message-Id: <20140509.084938.274205247.mbj@tail-f.com>
To: ietf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20140429141003.22969.2351.idtracker@ietfa.amsl.com>
References: <20140429141003.22969.2351.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sERXCkKev4Ti1akAdocrtBuimpo
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-system-mgmt-15.txt> (A YANG Data Model for System Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 06:49:46 -0000

Hi,

The IESG <iesg-secretary@ietf.org> wrote:
> 
> The IESG has received a request from the NETCONF Data Modeling Language
> WG (netmod) to consider the following document:
> - 'A YANG Data Model for System Management'
>   <draft-ietf-netmod-system-mgmt-15.txt> as 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 2014-05-13. 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 data model in in this draft has this structure (objects unrelated
to SSH keys removed)

           +--rw user* [name]
               +--rw name        string
               +--rw ssh-key* [name]
                  +--rw name         string
                  +--rw algorithm    string
                  +--rw key-data     binary

The intention is that the separation of the key with two leafs,
"algorithm" and "key-data" makes it easy to cut-and-paste from keys
generated with ssh-keygen etc.  (The encoding of type binary in YANG
is base64, which happen to match the key format.  So the operator can
set the "algorithm" and paste the base64 encoded blob into "key-data".)

During implementation of ssh key handling, we realized that the
description of the objects related to SSH keys probably need some
clarifications. 

Specifically, the list "ssh-key" and the leaf "key-data" are unclear.
After consulting with people at ietf-ssh@NetBSD.org, I propose the
following changes:

OLD:

         list ssh-key {
           key name;
           description
             "A list of public SSH keys for this user.";
           reference
             "RFC 4253: The Secure Shell (SSH) Transport Layer
                        Protocol";

NEW:

        list authorized-key {
           key name;
           description
             "A list of public SSH keys for this user.  These keys
              are allowed for SSH authentication, as described in
              RFC 4253.";
           reference
             "RFC 4253: The Secure Shell (SSH) Transport Layer
                        Protocol";

OLD:

           leaf key-data {
             type binary;
             mandatory true;
             description
               "The binary key data for this ssh key.";
           }

NEW:

          leaf key-data {
             type binary;
             mandatory true;
             description
               "The binary public key data for this ssh key, as
                specified by RFC 4253, Section 6.6, i.e.,:

                  string    certificate or public key format
                            identifier
                  byte[n]   key/certificate data
                ";
             reference
               "RFC 4253: The Secure Shell (SSH) Transport Layer
                          Protocol";
           }



/martin


From nobody Fri May  9 02:54:49 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A051A023D for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 02:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej9jSr1mbP3q for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 02:54:45 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7161A023C for <netmod@ietf.org>; Fri,  9 May 2014 02:54:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5A2F85405BE; Fri,  9 May 2014 11:54:39 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNsQ-uXMbaRR; Fri,  9 May 2014 11:54:35 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6D47754000E; Fri,  9 May 2014 11:54:34 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHSocNhJob91_4UsNBvDC5rp7=QDGNNtNFeVGqkkGkrCaA@mail.gmail.com>
References: <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com> <20140507.222120.122843926.mbj@tail-f.com> <A543A9BC-9F1A-4154-8CBB-B0A52EC9C3EB@nic.cz> <20140508.095426.686508493610810924.mbj@tail-f.com> <CABCOCHSocNhJob91_4UsNBvDC5rp7=QDGNNtNFeVGqkkGkrCaA@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 09 May 2014 11:54:33 +0200
Message-ID: <m2y4ybnup2.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6D8_h82JnsCvP0kfOaoeiB8BxVw
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 09:54:48 -0000

Andy Bierman <andy@yumaworks.com> writes:

> On Thu, May 8, 2014 at 12:54 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Ladislav Lhotka <lhotka@nic.cz> wrote:
>> >
>> > On 07 May 2014, at 22:21, Martin Bjorklund <mbj@tail-f.com> wrote:
>> >
>> > > Andy Bierman <andy@yumaworks.com> wrote:
>> > >> On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <mbj@tail-f.com>
>> > >> wrote:
>> > >>> I am confused.   There are no additional namespaces today - just one,
>> > >>> introduced by the module.  What did you agree on?
>> > >>>
>> > >>>
>> > >> There are 2 issues -- we agree on 1
>> > >>
>> > >> 1) how to indicate that submodule contents are exported from the main
>> > >> module
>> > >>     to external modules?
>> > >>
>> > >>    a) include must be in main module
>> > >>    b) include must be in main module or submodule
>> > >>
>> > >> 2) what definitions are visible within a submodule?
>> > >>
>> > >>    a) only self and includes
>> > >>    b) main module, self, and includes
>> > >
>> > > Thank you, this is a clear summary of the alternatives.
>> > >
>> > > I think we were all over the map when we discussed this during the
>> > > initial design of YANG.  We looked at all these alternatives, and
>> > > ended up with what we have today.  I'll go back and look in the
>> > > archives to see how much of the discussions are captured.
>> >
>> > I wasn't there. :-)
>> >
>> > >
>> > > One design rule we had was that we wanted it to be possible to compile
>> > > / check each submodule on its own (only follow explicit
>> > > import/include), w/o having to bring in the complete module.  With
>> > > option 2b, this is no longer possible.
>> >
>> > I don't think this is important - the top-level definitions from the
>> > main module and all submodules are easy to look up. On the other hand,
>> > submodules cannot use conflicting names even if they don't include
>> > each other, so it doesn't help submodule writers in this respect.
>> >
>> > >
>> > > Re. issue 1, it seems to me no real problem is solved by going from 1a
>> > > to 1b.
>> >
>> > I agree. It would be different if a submodule tree could be grafted to
>> > a non-root node, but it is not the case.
>> >
>> > >
>> > > Re. issue 2, solution 2b actually solves a real problem - today you
>> > > have to place common definitions in a separate submodule; they cannot
>> > > go into the main module.  Since circular includes are not possible,
>> > > references within a module (across submodules) have to be done
>> > > carefully, and might impose a non-intuitive submodule design.
>> >
>> > Right, this is a serious contender for the most peculiar rule in YANG.
>> >
>> > >
>> > > So I think we need to think more about this, but solution 2b seems
>> > > attractive to me.
>> >
>> > With 1a, the following is a logical option:
>> >
>> > 2c) main module and all submodules included from it.
>>
>> Yes, that's how I interpreted 2b!  Essentially each submodule has
>> access to all definitions in all other submodules.
>>
>>
> This is what I wanted from the start.
> That is why I do not agree that the include-stmts need to be in the main
> module.
>
> module A {
>    prefix a;
>    include B;
>    container foo;
>  }
>  submodule B {
>     belongs-to A { prefix a; }
>     include C;
>  }
>  submodule C {
>     belongs-to A { prefix a; }
>     leaf top { type string; }
>     augment /a:foo {
>        leaf should-be-ok { type string; }
>      }
>  }
>
> IMO, the include-stmts just say "go find this file and add all the
> definitions to the module namespace". Therefore, leaf 'top'
> is visible in the main module and also to external modules.
> This is the detail we do not agree on.  Forcing the include-stmt
> to also appear in the main module seems like a CLR.

The include statement would appear *only* in the main module. I think it is better because the main module is advertized but submodules aren't, so it's safer to get all submodules in one step and from an authoritative source. With includes in submodules it is IMO much more likely that the server and client will unintentionally work with different data models.  

>
> It is not really OK to declare that submodules can use definitions
> without include-stmts, unless we don't care about the self-compiling
> sub-modules. (IMO a real low priority). If so, then it is also
> OK to allow submodules to access the main module definitions.

Since submodules aren't really isolated, I think the self-compilation is largely a red herring. A submodule defining a name that's in conflict with the main module will be sucessfully compiled even though it is broken.  

Lada

>
>
>> /martin
>>
>
> Andy

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri May  9 06:12:22 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAB41A02AD for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 06:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5JX6F4KoUVk for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 06:12:10 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7481A02AC for <netmod@ietf.org>; Fri,  9 May 2014 06:12:10 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so4440205qgf.35 for <netmod@ietf.org>; Fri, 09 May 2014 06:12:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HKPCTXQqTRYZW/yKN4UptHIrGroiXuGrFTSOgN4+gXI=; b=JVr2P7LTi2bRMDbQhGsmShgU83TUDM5hFF7cpuqSkvkqcR+I/zW+kKkks0NX0p1RiF VbvhpGl/DeGWEastDEsKcAt8aKKQMAyiuMStx5Xe13D3qIKVuVyb7x/+UOSBJ5T+sc2T ahl0aHFr+GrBry4hht+hgx5TcJlAzCLB66IupvMjJoRMDRgk7o0vsJuIYM+A2f/zr0+Z tUjZCjyS+XmWIia0TPmMMxouVRvQ7P1+rTmzksj945memtEjJJMzM2a4ENzPiSvECcKa 5TkgdK8u+tzz7OYkh3K9CiDJruJGU9ZnTo4sZzymraKpK+/q+bepPbbLlB1cNN0+XSBt Qv4g==
X-Gm-Message-State: ALoCoQnN57tiuJCzKC7k3fslvVqFQcHsCfRlc9uepzK18Mo0opW8EunhkcF/rcdzhZ9HUqbozsUJ
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr13427707qgy.34.1399641117601; Fri, 09 May 2014 06:11:57 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 9 May 2014 06:11:57 -0700 (PDT)
In-Reply-To: <m2y4ybnup2.fsf@nic.cz>
References: <CABCOCHRN85zz1JT_5HauSrwZzCFoH3Hz2Z07j5Yh+mDGC5xeoA@mail.gmail.com> <20140507.222120.122843926.mbj@tail-f.com> <A543A9BC-9F1A-4154-8CBB-B0A52EC9C3EB@nic.cz> <20140508.095426.686508493610810924.mbj@tail-f.com> <CABCOCHSocNhJob91_4UsNBvDC5rp7=QDGNNtNFeVGqkkGkrCaA@mail.gmail.com> <m2y4ybnup2.fsf@nic.cz>
Date: Fri, 9 May 2014 06:11:57 -0700
Message-ID: <CABCOCHSfpk=bDY-tkQi5zM=tXQnJMd5-sLztmWQu21EPjcYeig@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c126baa0d14d04f8f757ca
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/taF6UjSGZWh3Ygkeq0ixjHLdyDc
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG 1.1: clarify nested submodule behavior
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 13:12:17 -0000

--001a11c126baa0d14d04f8f757ca
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 9, 2014 at 2:54 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Andy Bierman <andy@yumaworks.com> writes:
>
> > On Thu, May 8, 2014 at 12:54 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> >
> >> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> >
> >> > On 07 May 2014, at 22:21, Martin Bjorklund <mbj@tail-f.com> wrote:
> >> >
> >> > > Andy Bierman <andy@yumaworks.com> wrote:
> >> > >> On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund <mbj@tail-f.com>
> >> > >> wrote:
> >> > >>> I am confused.   There are no additional namespaces today - just
> one,
> >> > >>> introduced by the module.  What did you agree on?
> >> > >>>
> >> > >>>
> >> > >> There are 2 issues -- we agree on 1
> >> > >>
> >> > >> 1) how to indicate that submodule contents are exported from the
> main
> >> > >> module
> >> > >>     to external modules?
> >> > >>
> >> > >>    a) include must be in main module
> >> > >>    b) include must be in main module or submodule
> >> > >>
> >> > >> 2) what definitions are visible within a submodule?
> >> > >>
> >> > >>    a) only self and includes
> >> > >>    b) main module, self, and includes
> >> > >
> >> > > Thank you, this is a clear summary of the alternatives.
> >> > >
> >> > > I think we were all over the map when we discussed this during the
> >> > > initial design of YANG.  We looked at all these alternatives, and
> >> > > ended up with what we have today.  I'll go back and look in the
> >> > > archives to see how much of the discussions are captured.
> >> >
> >> > I wasn't there. :-)
> >> >
> >> > >
> >> > > One design rule we had was that we wanted it to be possible to
> compile
> >> > > / check each submodule on its own (only follow explicit
> >> > > import/include), w/o having to bring in the complete module.  With
> >> > > option 2b, this is no longer possible.
> >> >
> >> > I don't think this is important - the top-level definitions from the
> >> > main module and all submodules are easy to look up. On the other hand,
> >> > submodules cannot use conflicting names even if they don't include
> >> > each other, so it doesn't help submodule writers in this respect.
> >> >
> >> > >
> >> > > Re. issue 1, it seems to me no real problem is solved by going from
> 1a
> >> > > to 1b.
> >> >
> >> > I agree. It would be different if a submodule tree could be grafted to
> >> > a non-root node, but it is not the case.
> >> >
> >> > >
> >> > > Re. issue 2, solution 2b actually solves a real problem - today you
> >> > > have to place common definitions in a separate submodule; they
> cannot
> >> > > go into the main module.  Since circular includes are not possible,
> >> > > references within a module (across submodules) have to be done
> >> > > carefully, and might impose a non-intuitive submodule design.
> >> >
> >> > Right, this is a serious contender for the most peculiar rule in YANG.
> >> >
> >> > >
> >> > > So I think we need to think more about this, but solution 2b seems
> >> > > attractive to me.
> >> >
> >> > With 1a, the following is a logical option:
> >> >
> >> > 2c) main module and all submodules included from it.
> >>
> >> Yes, that's how I interpreted 2b!  Essentially each submodule has
> >> access to all definitions in all other submodules.
> >>
> >>
> > This is what I wanted from the start.
> > That is why I do not agree that the include-stmts need to be in the main
> > module.
> >
> > module A {
> >    prefix a;
> >    include B;
> >    container foo;
> >  }
> >  submodule B {
> >     belongs-to A { prefix a; }
> >     include C;
> >  }
> >  submodule C {
> >     belongs-to A { prefix a; }
> >     leaf top { type string; }
> >     augment /a:foo {
> >        leaf should-be-ok { type string; }
> >      }
> >  }
> >
> > IMO, the include-stmts just say "go find this file and add all the
> > definitions to the module namespace". Therefore, leaf 'top'
> > is visible in the main module and also to external modules.
> > This is the detail we do not agree on.  Forcing the include-stmt
> > to also appear in the main module seems like a CLR.
>
> The include statement would appear *only* in the main module. I think it
> is better because the main module is advertized but submodules aren't, so
> it's safer to get all submodules in one step and from an authoritative
> source. With includes in submodules it is IMO much more likely that the
> server and client will unintentionally work with different data models.
>
>
This is a CLR needed because you implemented it that way in pyang.
It does not follow the principle of self-compiling modules.
It doesn't matter where the include-stmt is wrt/ finding YANG files.


> >
> > It is not really OK to declare that submodules can use definitions
> > without include-stmts, unless we don't care about the self-compiling
> > sub-modules. (IMO a real low priority). If so, then it is also
> > OK to allow submodules to access the main module definitions.
>
> Since submodules aren't really isolated, I think the self-compilation is
> largely a red herring. A submodule defining a name that's in conflict with
> the main module will be sucessfully compiled even though it is broken.
>
>
I agree compiling submodules is not a very useful feature since they can
never be used
that way in a server.


> Lada
>
> >
> >
> >> /martin
> >>
> >
> > Andy
>
>
Andy


> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--001a11c126baa0d14d04f8f757ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 9, 2014 at 2:54 AM, Ladislav Lhotka <span dir=3D"ltr">&=
lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; writes:<br>
<br>
&gt; On Thu, May 8, 2014 at 12:54 AM, Martin Bjorklund &lt;<a href=3D"mailt=
o:mbj@tail-f.com">mbj@tail-f.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz=
</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On 07 May 2014, at 22:21, Martin Bjorklund &lt;<a href=3D"mai=
lto:mbj@tail-f.com">mbj@tail-f.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">a=
ndy@yumaworks.com</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt;&gt; On Wed, May 7, 2014 at 9:11 AM, Martin Bjorklund &lt=
;<a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com</a>&gt;<br>
&gt;&gt; &gt; &gt;&gt; wrote:<br>
&gt;&gt; &gt; &gt;&gt;&gt; I am confused. =A0 There are no additional names=
paces today - just one,<br>
&gt;&gt; &gt; &gt;&gt;&gt; introduced by the module. =A0What did you agree =
on?<br>
&gt;&gt; &gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; There are 2 issues -- we agree on 1<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; 1) how to indicate that submodule contents are expor=
ted from the main<br>
&gt;&gt; &gt; &gt;&gt; module<br>
&gt;&gt; &gt; &gt;&gt; =A0 =A0 to external modules?<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; =A0 =A0a) include must be in main module<br>
&gt;&gt; &gt; &gt;&gt; =A0 =A0b) include must be in main module or submodul=
e<br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; 2) what definitions are visible within a submodule?<=
br>
&gt;&gt; &gt; &gt;&gt;<br>
&gt;&gt; &gt; &gt;&gt; =A0 =A0a) only self and includes<br>
&gt;&gt; &gt; &gt;&gt; =A0 =A0b) main module, self, and includes<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Thank you, this is a clear summary of the alternatives.<=
br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; I think we were all over the map when we discussed this =
during the<br>
&gt;&gt; &gt; &gt; initial design of YANG. =A0We looked at all these altern=
atives, and<br>
&gt;&gt; &gt; &gt; ended up with what we have today. =A0I&#39;ll go back an=
d look in the<br>
&gt;&gt; &gt; &gt; archives to see how much of the discussions are captured=
.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I wasn&#39;t there. :-)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; One design rule we had was that we wanted it to be possi=
ble to compile<br>
&gt;&gt; &gt; &gt; / check each submodule on its own (only follow explicit<=
br>
&gt;&gt; &gt; &gt; import/include), w/o having to bring in the complete mod=
ule. =A0With<br>
&gt;&gt; &gt; &gt; option 2b, this is no longer possible.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I don&#39;t think this is important - the top-level definitio=
ns from the<br>
&gt;&gt; &gt; main module and all submodules are easy to look up. On the ot=
her hand,<br>
&gt;&gt; &gt; submodules cannot use conflicting names even if they don&#39;=
t include<br>
&gt;&gt; &gt; each other, so it doesn&#39;t help submodule writers in this =
respect.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Re. issue 1, it seems to me no real problem is solved by=
 going from 1a<br>
&gt;&gt; &gt; &gt; to 1b.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I agree. It would be different if a submodule tree could be g=
rafted to<br>
&gt;&gt; &gt; a non-root node, but it is not the case.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; Re. issue 2, solution 2b actually solves a real problem =
- today you<br>
&gt;&gt; &gt; &gt; have to place common definitions in a separate submodule=
; they cannot<br>
&gt;&gt; &gt; &gt; go into the main module. =A0Since circular includes are =
not possible,<br>
&gt;&gt; &gt; &gt; references within a module (across submodules) have to b=
e done<br>
&gt;&gt; &gt; &gt; carefully, and might impose a non-intuitive submodule de=
sign.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Right, this is a serious contender for the most peculiar rule=
 in YANG.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt;<br>
&gt;&gt; &gt; &gt; So I think we need to think more about this, but solutio=
n 2b seems<br>
&gt;&gt; &gt; &gt; attractive to me.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; With 1a, the following is a logical option:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 2c) main module and all submodules included from it.<br>
&gt;&gt;<br>
&gt;&gt; Yes, that&#39;s how I interpreted 2b! =A0Essentially each submodul=
e has<br>
&gt;&gt; access to all definitions in all other submodules.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; This is what I wanted from the start.<br>
&gt; That is why I do not agree that the include-stmts need to be in the ma=
in<br>
&gt; module.<br>
&gt;<br>
&gt; module A {<br>
&gt; =A0 =A0prefix a;<br>
&gt; =A0 =A0include B;<br>
&gt; =A0 =A0container foo;<br>
&gt; =A0}<br>
&gt; =A0submodule B {<br>
&gt; =A0 =A0 belongs-to A { prefix a; }<br>
&gt; =A0 =A0 include C;<br>
&gt; =A0}<br>
&gt; =A0submodule C {<br>
&gt; =A0 =A0 belongs-to A { prefix a; }<br>
&gt; =A0 =A0 leaf top { type string; }<br>
&gt; =A0 =A0 augment /a:foo {<br>
&gt; =A0 =A0 =A0 =A0leaf should-be-ok { type string; }<br>
&gt; =A0 =A0 =A0}<br>
&gt; =A0}<br>
&gt;<br>
&gt; IMO, the include-stmts just say &quot;go find this file and add all th=
e<br>
&gt; definitions to the module namespace&quot;. Therefore, leaf &#39;top&#3=
9;<br>
&gt; is visible in the main module and also to external modules.<br>
&gt; This is the detail we do not agree on. =A0Forcing the include-stmt<br>
&gt; to also appear in the main module seems like a CLR.<br>
<br>
The include statement would appear *only* in the main module. I think it is=
 better because the main module is advertized but submodules aren&#39;t, so=
 it&#39;s safer to get all submodules in one step and from an authoritative=
 source. With includes in submodules it is IMO much more likely that the se=
rver and client will unintentionally work with different data models.<br>

<br></blockquote><div><br></div><div>This is a CLR needed because you imple=
mented it that way in pyang.</div><div>It does not follow the principle of =
self-compiling modules.</div><div>It doesn&#39;t matter where the include-s=
tmt is wrt/ finding YANG files.</div>
<div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;<br>
&gt; It is not really OK to declare that submodules can use definitions<br>
&gt; without include-stmts, unless we don&#39;t care about the self-compili=
ng<br>
&gt; sub-modules. (IMO a real low priority). If so, then it is also<br>
&gt; OK to allow submodules to access the main module definitions.<br>
<br>
Since submodules aren&#39;t really isolated, I think the self-compilation i=
s largely a red herring. A submodule defining a name that&#39;s in conflict=
 with the main module will be sucessfully compiled even though it is broken=
.<br>

<br></blockquote><div><br></div><div>I agree compiling submodules is not a =
very useful feature since they can never be used</div><div>that way in a se=
rver.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Lada<br>
<br>
&gt;<br>
&gt;<br>
&gt;&gt; /martin<br>
&gt;&gt;<br>
&gt;<br>
&gt; Andy<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>Andy</div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span class=3D"HOEnZb"><font color=3D"#888888">
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
</font></span></blockquote></div><br></div></div>

--001a11c126baa0d14d04f8f757ca--


From nobody Fri May  9 07:01:06 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B66E1A02A0 for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.551
X-Spam-Level: 
X-Spam-Status: No, score=-14.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK7vjdVSAx0O for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:01:00 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 73BC91A00BE for <netmod@ietf.org>; Fri,  9 May 2014 07:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18984; q=dns/txt; s=iport; t=1399644056; x=1400853656; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tixoPRCIM5zm8BRu31Suax26l9NWTpYAUCsxAltGXaM=; b=iEt+gNrm8yoihNrGkFt63wx4bvYgX1ynvgaarDMYQoP3X3yv2P1b1/hL 0zIzpX3jQhAqQkwsiG2YwTlNsbKYPy3sV5pbUM6a8qMnWcJhmBYcstqam p2fs1yLZeA3YqZTB4D3i5ICSagU11zgxDGkNBwmnP+rKYNoi5iiOjSReQ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFADHebFOtJA2M/2dsb2JhbABZgkJET1jFSAGBFxZ0giYBAQQtTBACASokMiUCBA4NE4gmDdEmEwSJMYRwLQQHgyuBFQSJVIt7lnqDNm0BgQEkHA
X-IronPort-AV: E=Sophos;i="4.97,1018,1389744000";  d="scan'208,217";a="323651779"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 09 May 2014 14:00:55 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s49E0soR021983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 14:00:54 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 9 May 2014 09:00:54 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: "andy@yumaworks.com" <andy@yumaworks.com>
Thread-Topic: Union Clarification (was: RE: Y53: YANG 1.1 Key Flexibility)
Thread-Index: AQKrtJW8YYu88c7bnOaFVgLua7M/v5l/tIhg
Date: Fri, 9 May 2014 14:00:53 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AB2E2E@xmb-aln-x08.cisco.com>
References: <1a5601cf6b8e$86c94860$945bd920$@cisco.com>
In-Reply-To: <1a5601cf6b8e$86c94860$945bd920$@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.168]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E2Exmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kA3DbCKcj9fnj57dB5VHAcReuL0
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] Union Clarification (was: RE: Y53: YANG 1.1 Key Flexibility)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 14:01:05 -0000

--_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E2Exmbalnx08ciscoc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[Changing the subject to separate the clarifications on unions from the ori=
ginal problem we're trying to solve...]



[...snip...]



To check we're on the same page, my understanding is that in that union, if=
 a specifier matches the domain-name pattern, it would always resolve to th=
e inet:host type (based on RFC 6020 9.2: "When a string representing a unio=
n data type is validated, the string is validated against each member type,=
 in the order they are specified in the "type" statement, until a match is =
found.") -- though I could be misunderstanding what "validated" means here.
In any case, this question arises because there can be overlap in the value=
 space of the different elements; so as well as the value itself, we need t=
he information on which of the options is being represented to interpret th=
e data correctly.
A union type is like a logical-OR expression.
The YANG validation tool goes through each 'type' in order and checks
if the supplied value is valid for that type.  If so, then the leaf is vali=
d.
If the parser gets to end of the list and none of the types have validated
for the supplied value, then the leaf is rejected with an invalid-value err=
or-tag.

OK, thanks for the clarification.

So you want to place the most selective patterns first, and the catch-all '=
string' last.

So I still feel I'm missing something here. If it's just a logical-OR expre=
ssion, why would it matter whether the most selective patterns are placed f=
irst? (And by extension, why is there any mention of ordering at all?]

[If anything, it sounds like if the most selective pattern is a subset of a=
nother pattern, it's not serving any purpose beyond possibly documentation;=
 and specifying them the other way round would presumably make the validati=
on more efficient.]

It is an implementation detail how the union type is represented within the=
 server.

   leaf maintenance-domain {
       type maintenance-domain-identifier;
   }

Right, so if I understand correctly, you are saying that the set of types l=
isted in the union is for no other purpose than to determine whether a leaf=
 is valid; and the implementation can choose to interpret the value however=
 it wishes.

If so, it would be useful to make this explicit; in particular when Yang is=
 mapped to a binary data representation, this subtlety makes a difference t=
o the behavior. (e.g. It looks like it is interpreted as inferring a specif=
ic type in the Yang JSON draft<https://tools.ietf.org/html/draft-lhotka-yan=
g-json-01#section-3.3.10>.)

Thanks,
Peyman
Based on that, it looks like the data needs to be represented as a choice o=
r as independent leaves rather than a union, right?
No



Thanks,

Peyman

Andy



These strings can be overlapping, so this cannot be represented as a union.
=3D=3D=3D=3D=3D=3D

Do you have thoughts on how this should be modelled (and if extensions are =
needed)?

In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a "must" statement =
(and I'm not sure whether this is even compatible with the "CLI" comment in=
 Y09-01):
=3D=3D=3D=3D=3D=3D
list maintenance-domains {
  key "host id name";
  leaf host { type inet:host;  mandatory false; }
  leaf id   { type hex-string; mandatory false; }
  leaf name { type string;     mandatory false; }

  // Rule to ensure exactly one of the above is specified
  must "count(host) + count(id) + count(name) =3D 1";
}
=3D=3D=3D=3D=3D=3D

Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)

Thanks,
Peyman



--_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E2Exmbalnx08ciscoc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	mso-fareast-language:EN-GB;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:EN-GB;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1F497D">[Changing the subject to s</span><span styl=
e=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot=
;;color:#1F497D">eparat</span><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">e</span><span styl=
e=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot=
;;color:#1F497D"> the clarifications on unions from the original problem we=
're trying to solve&#8230;</span><span style=3D"font-size:11.0pt;font-famil=
y:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">]</span><span s=
tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=
uot;;color:#1F497D"><o:p></o:p></span></pre>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pre>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1F497D">[&#8230;snip&#8230;]<o:p></o:p></span></pre=
>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o=
:p></span></pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">To check we're=
 on the same page, my understanding is that in that union, if a specifier m=
atches the domain-name pattern, it would always resolve to the inet:host ty=
pe (based on RFC 6020 9.2: &quot;</span><span style=3D"color:black">When a =
string representing a union data type is validated, the string is validated=
 against each member type, in the order they are specified in the &quot;typ=
e&quot; statement, until a match is found.</span><span style=3D"font-size:1=
1.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"=
>&quot;) -- though I could be misunderstanding what &quot;validated&quot; m=
eans here.&nbsp;</span><o:p></o:p></pre>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">In any case, this question arises because there =
can be overlap in the value space of the different elements; so as well as =
the value itself, we need the information on which of
 the options is being represented to interpret the data correctly.</span><o=
:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">A union type is like a =
logical-OR expression.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">The YANG validation too=
l goes through each 'type' in order and checks<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">if the supplied value i=
s valid for that type. &nbsp;If so, then the leaf is valid.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">If the parser gets to e=
nd of the list and none of the types have validated<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">for the supplied value,=
 then the leaf is rejected with an invalid-value error-tag.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">OK, thanks for the clarif=
ication.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">So you want to place th=
e most selective patterns first, and the catch-all 'string' last.<o:p></o:p=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So I still feel I'm missi=
ng something here. If it's just a logical-OR expression, why would it matte=
r whether the most selective patterns are placed first?</span><span style=
=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:#1F497D">
 (And by extension, why is there any mention of ordering at all?]<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">[</span><span style=3D"fo=
nt-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color=
:#1F497D">If anything, it sounds like if the most selective pattern is a su=
bset
 of another pattern, it's not serving any purpose beyond possibly documenta=
tion; and specifying them the other way round would
</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1F497D">presumably
</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1F497D">make the validation more efficient.</span=
><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans=
-serif&quot;;color:#1F497D">]</span><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">It is an implementation=
 detail how the union type is represented within the server.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;leaf maint=
enance-domain {<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp; &nbsp; &n=
bsp;type maintenance-domain-identifier;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;}<o:p></o:=
p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Right, so if I understand=
 correctly, you are saying that the set of types listed in the union is for=
 no other purpose than to determine whether a leaf is valid;
 and the implementation can choose to interpret the value however it wishes=
.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">If so, it would be useful=
 to make this explicit; in particular when Yang is mapped to a binary data =
representation, this subtlety makes a difference to the
 behavior. (e.g. It looks like it is interpreted as inferring a specific ty=
pe <a href=3D"https://tools.ietf.org/html/draft-lhotka-yang-json-01#section=
-3.3.10">
in the Yang JSON draft</a>.)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peyman<o:p></o:p></span><=
/p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">Based on that, it looks like the data needs to b=
e represented as a choice or as independent leaves rather than a union, rig=
ht?</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">No<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,</span>=
<o:p></o:p></pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peyman</span><=
o:p></o:p></pre>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Andy<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:72.0pt">
&nbsp;<o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=
t;margin-left:72.0pt">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I'm not sure whether this is even compatible with the &quot;=
CLI&quot; comment in Y09-01):<br>
=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
&nbsp; key &quot;host id name&quot;;<br>
&nbsp; leaf host { type inet:host; &nbsp;mandatory false; }<br>
&nbsp; leaf id &nbsp; { type hex-string; mandatory false; }<br>
&nbsp; leaf name { type string; &nbsp; &nbsp; mandatory false; }<br>
<br>
&nbsp; // Rule to ensure exactly one of the above is specified<br>
&nbsp; must &quot;count(host) &#43; count(id) &#43; count(name) =3D 1&quot;=
;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>
<br>
Thanks,<br>
Peyman<o:p></o:p></p>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:72.0pt">
&nbsp;<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E2Exmbalnx08ciscoc_--


From nobody Fri May  9 07:01:59 2014
Return-Path: <powladi@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D79C1A00BE for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5fE88RYPoF3 for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:01:49 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D10651A0077 for <netmod@ietf.org>; Fri,  9 May 2014 07:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18390; q=dns/txt; s=iport; t=1399644104; x=1400853704; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ClSOpPWRmxC2jBUJsiuLideKr0q9CX5W+5xWy28TpE0=; b=fOv3QAT1mAH0BswiWiXncqsGxMB7VmW6THUxhVdFXCxZjU5VJQ+joUCZ HVQ+vPQlyvbXSD4acg7UpAe9EkZ1TsH4GwZvQbM7iUU11V4pi3UDDYIGu eZyIlK0uIVr+jGqGl13poNcH1oT7o4/jZdl8FFB3vFRX4Kqoan/aN30+9 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAJfebFOtJV2b/2dsb2JhbABZgkJET1jFSAGBFxZ0giYBAQQtTBACAQgiCxkyJQIEDg0TiCbRMReJMYRwMQcJAYMhgRUEhXiPV4U0kUaDNoFvJBw
X-IronPort-AV: E=Sophos;i="4.97,1018,1389744000";  d="scan'208,217";a="320621554"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 09 May 2014 14:01:42 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s49E1gAI002287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 14:01:42 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 9 May 2014 09:01:42 -0500
From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
Thread-Topic: Y53: YANG 1.1 Key Flexibility
Thread-Index: AQDqlaWLAxII9M2UdJcD6jdSAOWzIAGT5jcmAY5vUDwCXvmZxQFYRSpqAWNLotUDJpbtpZym1gNw
Date: Fri, 9 May 2014 14:01:41 +0000
Message-ID: <013A9B371AC6DF4C8AD261897D8F243E10AB2E3F@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com> <20140508.120143.1962717862150015233.mbj@tail-f.com> <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com> <CABCOCHQNysSSgV51MApPCVcc4GWQLHS3w=3+SgiQYzWv80NdKw@mail.gmail.com> <013A9B371AC6DF4C8AD261897D8F243E10AB0C2D@xmb-aln-x08.cisco.com> <CABCOCHQUWHL9jnSQR9wGW_YHJ=Ok_-b-wTQXcm8UVJT30x=38g@mail.gmail.com>
In-Reply-To: <CABCOCHQUWHL9jnSQR9wGW_YHJ=Ok_-b-wTQXcm8UVJT30x=38g@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.63.23.168]
Content-Type: multipart/alternative; boundary="_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E3Fxmbalnx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zF-IOaE6vJYWVysOze8ZMbPi4Tc
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 14:01:52 -0000

--_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E3Fxmbalnx08ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[...snip...]

A union type is like a logical-OR expression.
The YANG validation tool goes through each 'type' in order and checks
if the supplied value is valid for that type.  If so, then the leaf is vali=
d.
If the parser gets to end of the list and none of the types have validated
for the supplied value, then the leaf is rejected with an invalid-value err=
or-tag.

So you want to place the most selective patterns first, and the catch-all '=
string' last.
It is an implementation detail how the union type is represented within the=
 server.

   leaf maintenance-domain {
       type maintenance-domain-identifier;
   }

Even taking into account those clarifications, a union is still not suffici=
ent for this scenario.  In particular, it's possible for "example.com" to b=
e either a domain name or a string, and it represents a distinct identifier=
 in each case. i.e.  It's possible to have two different domains, one ident=
ified by string "example.com" and one identified by domain name "example.co=
m".

So the "choice/case" construct (or the Y09-based construct below) allows us=
 to distinguish between these two cases, whereas the "union" construct does=
 not.

If I've understood your comments about the type inference correctly (i.e. t=
hat there is no defined pattern for it), then there is of course an alterna=
tive here to have a separate enumeration that indicates the type being spec=
ified (though in that case I'm not sure there's a whole lot of value in the=
 union any more):

  leaf identifier-type {
    type enumeration {
      enum host;
      enum id;
      enum name;
    }
  }
  leaf identifier { type string; mandatory false; }

But if that's an expected usage pattern, then perhaps having an explicit "d=
iscriminated union" type would have value, by allowing the enumeration valu=
es and corresponding types to be linked programmatically? (Again, this woul=
d be particularly add value when defining mappings from Yang to binary repr=
esentations.)

  leaf identifier {
    type discriminated-union {
      option host { type inet:host; }
      option id   { type hex-string; }
      option name { type string; }
    }
  }

Cheers,
Peyman

Based on that, it looks like the data needs to be represented as a choice o=
r as independent leaves rather than a union, right?



No


Thanks,

Peyman

Andy



These strings can be overlapping, so this cannot be represented as a union.
=3D=3D=3D=3D=3D=3D

Do you have thoughts on how this should be modelled (and if extensions are =
needed)?

In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a "must" statement =
(and I'm not sure whether this is even compatible with the "CLI" comment in=
 Y09-01):
=3D=3D=3D=3D=3D=3D
list maintenance-domains {
  key "host id name";
  leaf host { type inet:host;  mandatory false; }
  leaf id   { type hex-string; mandatory false; }
  leaf name { type string;     mandatory false; }

  // Rule to ensure exactly one of the above is specified
  must "count(host) + count(id) + count(name) =3D 1";
}
=3D=3D=3D=3D=3D=3D

Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)

Thanks,
Peyman



--_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E3Fxmbalnx08ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	mso-fareast-language:EN-GB;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:EN-GB;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=
:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497=
D">[&#8230;snip&#8230;]<o:p></o:p></span></a></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">A union type is like a =
logical-OR expression.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">The YANG validation too=
l goes through each 'type' in order and checks<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">if the supplied value i=
s valid for that type. &nbsp;If so, then the leaf is valid.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">If the parser gets to e=
nd of the list and none of the types have validated<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">for the supplied value,=
 then the leaf is rejected with an invalid-value error-tag.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">So you want to place th=
e most selective patterns first, and the catch-all 'string' last.<o:p></o:p=
></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">It is an implementation=
 detail how the union type is represented within the server.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;leaf maint=
enance-domain {<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp; &nbsp; &n=
bsp;type maintenance-domain-identifier;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;}<o:p></o:=
p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Even taking into account =
those clarifications, a union is still not sufficient for this scenario. &n=
bsp;In particular, it's possible for &quot;example.com&quot; to be either
 a domain name or a string, and it represents a distinct identifier in each=
 case. i.e. &nbsp;It's possible to have two different domains, one identifi=
ed by string &quot;example.com&quot; and one identified by domain name &quo=
t;example.com&quot;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So the &quot;choice/case&=
quot; construct (or the Y09-based construct below) allows us to distinguish=
 between these two cases, whereas the &quot;union&quot; construct does not.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">If I've understood your c=
omments about the type inference correctly (i.e. that there is no defined p=
attern for it), then there is of course an alternative here
 to have a separate enumeration that indicates the type being specified (th=
ough in that case I'm not sure there's a whole lot of value in the union an=
y more):<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; leaf identifier-type {<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; type enumeration {<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum host;<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum id;<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum name;<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; leaf identifier { type string; mandatory false; }<b=
r>
<br>
</span><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot=
;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1F497D">But if that's an expected usage pattern, t=
hen perhaps having an explicit &quot;discriminated union&quot; type would h=
ave value, by allowing the enumeration values and corresponding types
 to be linked programmatically? (Again, this would be particularly add valu=
e when defining mappings from Yang to binary representations.)<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; leaf identifier {<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; type discriminated-union {<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; option host { type inet:hos=
t; }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; option id&nbsp;&nbsp; { typ=
e hex-string; }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; option name { type string; =
}<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peyman<o:p></o:p></span><=
/p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">&nbsp;</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1F497D">Based on that, it looks like the data needs to b=
e represented as a choice or as independent leaves rather than a union, rig=
ht?</span><o:p></o:p></p>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><=
o:p></o:p></pre>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">No<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,</span>=
<o:p></o:p></pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peyman</span><=
o:p></o:p></pre>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Andy<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:72.0pt">
&nbsp;<o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=
t;margin-left:72.0pt">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I'm not sure whether this is even compatible with the &quot;=
CLI&quot; comment in Y09-01):<br>
=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
&nbsp; key &quot;host id name&quot;;<br>
&nbsp; leaf host { type inet:host; &nbsp;mandatory false; }<br>
&nbsp; leaf id &nbsp; { type hex-string; mandatory false; }<br>
&nbsp; leaf name { type string; &nbsp; &nbsp; mandatory false; }<br>
<br>
&nbsp; // Rule to ensure exactly one of the above is specified<br>
&nbsp; must &quot;count(host) &#43; count(id) &#43; count(name) =3D 1&quot;=
;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>
<br>
Thanks,<br>
Peyman<o:p></o:p></p>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:72.0pt">
&nbsp;<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_013A9B371AC6DF4C8AD261897D8F243E10AB2E3Fxmbalnx08ciscoc_--


From nobody Fri May  9 07:17:35 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A031A02AC for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIdfwJxQqIye for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:17:30 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by ietfa.amsl.com (Postfix) with ESMTP id A70D31A00BE for <netmod@ietf.org>; Fri,  9 May 2014 07:17:30 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id a108so4461629qge.22 for <netmod@ietf.org>; Fri, 09 May 2014 07:17:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YasHCNeuOqz/IMB2rR2yWzBN10dqj52w1f7JAsWBlz4=; b=cV3xL14CD5UaShoXJnuCA5gMSjylRJI1Bfl/N9zPOp+aVxwpHp3N4d6oYKyn3a2WwG spFg9IukFtV7CTTTr2xbHWIUabY8tXlC272vhmB7ETrJ6dPcT7O0iLMOOro2AjAlik2l es+s2V8DDRxxnrxJ5HIM5F4O06gcM1+k0cVG2T6X65vcOy89vOd+APZz1/87MozUCJYi A8mPGRiXEd4uZyVEOLWCm7uVeCPsaa7bH/vZQsaMU5gGknnIdlAZViAs9jcfWLh5gddX lAu+SNqZw8qWO7c9iks5TfqeYClvZzfkfpol7IQz0g/Kmsy4eRl/3LYpDma60d7HWQuL 7UWw==
X-Gm-Message-State: ALoCoQmitIafEnnuvaMFfvARsNzrmV5zD4jux4Y39x+QA80hb6/YMHS1rMWqX9YMwSMDp5FzV+Jh
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr14009317qgo.25.1399645045583; Fri, 09 May 2014 07:17:25 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 9 May 2014 07:17:25 -0700 (PDT)
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AB2E3F@xmb-aln-x08.cisco.com>
References: <013A9B371AC6DF4C8AD261897D8F243E10AAF484@xmb-aln-x08.cisco.com> <CABCOCHTFuhpzvOMMhPtRKX28jT3NaNN77wQ-+2mcwuYFOfB0sw@mail.gmail.com> <20140508.120143.1962717862150015233.mbj@tail-f.com> <013A9B371AC6DF4C8AD261897D8F243E10AB09FE@xmb-aln-x08.cisco.com> <CABCOCHQNysSSgV51MApPCVcc4GWQLHS3w=3+SgiQYzWv80NdKw@mail.gmail.com> <013A9B371AC6DF4C8AD261897D8F243E10AB0C2D@xmb-aln-x08.cisco.com> <CABCOCHQUWHL9jnSQR9wGW_YHJ=Ok_-b-wTQXcm8UVJT30x=38g@mail.gmail.com> <013A9B371AC6DF4C8AD261897D8F243E10AB2E3F@xmb-aln-x08.cisco.com>
Date: Fri, 9 May 2014 07:17:25 -0700
Message-ID: <CABCOCHQDy=nZ8jzYmvojvDWuxGP6T1KsePxmtm6pSP21PN1PQQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c17334c10a5804f8f84171
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fY-DPsMI6eGMsWZQY6mYAecgnRQ
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y53: YANG 1.1 Key Flexibility
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 14:17:33 -0000

--001a11c17334c10a5804f8f84171
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 9, 2014 at 7:01 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <powladi@cisco.com> wrote:

>  [...snip...]
>
>
>
> A union type is like a logical-OR expression.
>
> The YANG validation tool goes through each 'type' in order and checks
>
> if the supplied value is valid for that type.  If so, then the leaf is
> valid.
>
> If the parser gets to end of the list and none of the types have validated
>
> for the supplied value, then the leaf is rejected with an invalid-value
> error-tag.
>
>
>
> So you want to place the most selective patterns first, and the catch-all
> 'string' last.
>
> It is an implementation detail how the union type is represented within
> the server.
>
>
>
>    leaf maintenance-domain {
>
>        type maintenance-domain-identifier;
>
>    }
>
>
>
> Even taking into account those clarifications, a union is still not
> sufficient for this scenario.  In particular, it's possible for "
> example.com" to be either a domain name or a string, and it represents a
> distinct identifier in each case. i.e.  It's possible to have two different
> domains, one identified by string "example.com" and one identified by
> domain name "example.com".
>
>
>
> So the "choice/case" construct (or the Y09-based construct below) allows
> us to distinguish between these two cases, whereas the "union" construct
> does not.
>
>
>
> If I've understood your comments about the type inference correctly (i.e.
> that there is no defined pattern for it), then there is of course an
> alternative here to have a separate enumeration that indicates the type
> being specified (though in that case I'm not sure there's a whole lot of
> value in the union any more):
>
>
>
>   leaf identifier-type {
>
>     type enumeration {
>
>       enum host;
>
>       enum id;
>
>       enum name;
>
>     }
>
>   }
>
>   leaf identifier { type string; mandatory false; }
>
>  But if that's an expected usage pattern, then perhaps having an explicit
> "discriminated union" type would have value, by allowing the enumeration
> values and corresponding types to be linked programmatically? (Again, this
> would be particularly add value when defining mappings from Yang to binary
> representations.)
>
>
>
>   leaf identifier {
>
>     type discriminated-union {
>
>       option host { type inet:host; }
>
>       option id   { type hex-string; }
>
>       option name { type string; }
>
>     }
>
>   }
>
>
>

This does not work because the leaf local-name is "identifier".
That is not a virtual node that can be changed to  "host", "id", or "name"
in an instance document,

You can always add the discriminator leaf (e.g. identifier-type) to the
data model.
That is how YANG solves this problem now.

 Cheers,
>
> Peyman
>


Andy


>
>
> Based on that, it looks like the data needs to be represented as a choice
> or as independent leaves rather than a union, right?
>
>
>
>
>
> No
>
>
>
>    Thanks,
>
> Peyman
>
>
>
> Andy
>
>
>
>
>
>
>
>  These strings can be overlapping, so this cannot be represented as a
> union.
> ======
>
> Do you have thoughts on how this should be modelled (and if extensions are
> needed)?
>
> In particular, it seems there is a solution using Y09-01, though to do
> this we effectively have to reinvent the choice/union using a "must"
> statement (and I'm not sure whether this is even compatible with the "CLI"
> comment in Y09-01):
> ======
> list maintenance-domains {
>   key "host id name";
>   leaf host { type inet:host;  mandatory false; }
>   leaf id   { type hex-string; mandatory false; }
>   leaf name { type string;     mandatory false; }
>
>   // Rule to ensure exactly one of the above is specified
>   must "count(host) + count(id) + count(name) = 1";
> }
> ======
>
> Is that the best approach, or is there a better answer? (For example,
> introducing a union type with a discriminator would perhaps work as it
> would allow the above to be modelled as a union and therefore used as a
> key.)
>
> Thanks,
> Peyman
>
>
>
>
>

--001a11c17334c10a5804f8f84171
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 9, 2014 at 7:01 AM, Peyman Owladi -X (powladi - Ensoft =
Ltd at Cisco) <span dir=3D"ltr">&lt;<a href=3D"mailto:powladi@cisco.com" ta=
rget=3D"_blank">powladi@cisco.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><a name=3D"145e14a233df9471__MailEndCompose"><span s=
tyle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&q=
uot;;color:#1f497d">[&hellip;snip&hellip;]<u></u><u></u></span></a></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">A union type is like a =
logical-OR expression.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">The YANG validation too=
l goes through each &#39;type&#39; in order and checks<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">if the supplied value i=
s valid for that type. &nbsp;If so, then the leaf is valid.<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">If the parser gets to e=
nd of the list and none of the types have validated<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">for the supplied value,=
 then the leaf is rejected with an invalid-value error-tag.<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">So you want to place th=
e most selective patterns first, and the catch-all &#39;string&#39; last.<u=
></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">It is an implementation=
 detail how the union type is represented within the server.<u></u><u></u><=
/p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;leaf maint=
enance-domain {<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp; &nbsp; &n=
bsp;type maintenance-domain-identifier;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;}<u></u><u=
></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
f497d"><u></u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Even taking into account =
those clarifications, a union is still not sufficient for this scenario. &n=
bsp;In particular, it&#39;s possible for &quot;<a href=3D"http://example.co=
m" target=3D"_blank">example.com</a>&quot; to be either
 a domain name or a string, and it represents a distinct identifier in each=
 case. i.e. &nbsp;It&#39;s possible to have two different domains, one iden=
tified by string &quot;<a href=3D"http://example.com" target=3D"_blank">exa=
mple.com</a>&quot; and one identified by domain name &quot;<a href=3D"http:=
//example.com" target=3D"_blank">example.com</a>&quot;.<u></u><u></u></span=
></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">So the &quot;choice/case&=
quot; construct (or the Y09-based construct below) allows us to distinguish=
 between these two cases, whereas the &quot;union&quot; construct does not.=
<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">If I&#39;ve understood yo=
ur comments about the type inference correctly (i.e. that there is no defin=
ed pattern for it), then there is of course an alternative here
 to have a separate enumeration that indicates the type being specified (th=
ough in that case I&#39;m not sure there&#39;s a whole lot of value in the =
union any more):<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; leaf identifier-type {<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; type enumeration {<u></u><u></u></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum host;<u></u><u></u></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum id;<u></u><u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enum name;<u></u><u></u></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; leaf identifier { type string; mandatory false; }<b=
r>
<br>
</span><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot=
;;color:#1f497d"><u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:&quot;Calibri&quot;,&quot=
;sans-serif&quot;;color:#1f497d">But if that&#39;s an expected usage patter=
n, then perhaps having an explicit &quot;discriminated union&quot; type wou=
ld have value, by allowing the enumeration values and corresponding types
 to be linked programmatically? (Again, this would be particularly add valu=
e when defining mappings from Yang to binary representations.)<u></u><u></u=
></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; leaf identifier {<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; type discriminated-union {<u></u><u></u=
></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; option host { type inet:hos=
t; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; option id&nbsp;&nbsp; { typ=
e hex-string; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; option name { type string; =
}<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp;&nbsp;&nbsp; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Co=
urier New&quot;">&nbsp; }<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;</span></p><=
/div></div></div></div></div></div></blockquote><div><br></div><div>This do=
es not work because the leaf local-name is &quot;identifier&quot;.</div>
<div>That is not a virtual node that can be changed to &nbsp;&quot;host&quo=
t;, &quot;id&quot;, or &quot;name&quot;</div><div>in an instance document,&=
nbsp;</div><div><br></div><div>You can always add the discriminator leaf (e=
.g. identifier-type) to the data model.</div>
<div>That is how YANG solves this problem now.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"><=
div><div>
<div><div><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Cheers,<u></u><u></u></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Peyman</span></p></div></=
div></div></div></div></div></blockquote><div><br></div><div><br></div><div=
>
Andy</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-G=
B" link=3D"blue" vlink=3D"purple"><div><div><div><div><div><p class=3D"MsoN=
ormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p>

</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1f497d">&nbsp;</span><u></u><u></u></p>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1f497d">Based on that, it looks like the data needs to b=
e represented as a choice or as independent leaves rather than a union, rig=
ht?</span><u></u><u></u></p>

<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">&nbsp;</span><=
u></u><u></u></pre>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">No<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<u></u><u></u></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks,</span>=
<u></u><u></u></pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Peyman</span><=
u></u><u></u></pre>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Andy<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<u></u><u></u></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">
&nbsp;<u></u><u></u></p>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt;margin-left:72.0pt">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I&#39;m not sure whether this is even compatible with the &q=
uot;CLI&quot; comment in Y09-01):<br>

=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
&nbsp; key &quot;host id name&quot;;<br>
&nbsp; leaf host { type inet:host; &nbsp;mandatory false; }<br>
&nbsp; leaf id &nbsp; { type hex-string; mandatory false; }<br>
&nbsp; leaf name { type string; &nbsp; &nbsp; mandatory false; }<br>
<br>
&nbsp; // Rule to ensure exactly one of the above is specified<br>
&nbsp; must &quot;count(host) + count(id) + count(name) =3D 1&quot;;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>

<br>
Thanks,<br>
Peyman<u></u><u></u></p>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">
&nbsp;<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
</div>
</div>
</div>

</blockquote></div><br></div></div>

--001a11c17334c10a5804f8f84171--


From nobody Fri May  9 07:25:33 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A41A02C1 for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:25:30 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-wWBn7pYpPg for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 07:25:27 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) by ietfa.amsl.com (Postfix) with ESMTP id 696401A02D8 for <netmod@ietf.org>; Fri,  9 May 2014 07:25:22 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id f51so4468892qge.40 for <netmod@ietf.org>; Fri, 09 May 2014 07:25:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GCD1qMy+aJ3X+ozVcp+cHRpiTwB432BChnvaFgRKi1c=; b=IfM5ASlYBgXV+QLqLYmjbMppJg674be5L545mh64QJWRlWPl8JDMqeJPhfcYAVaxsf 2Vz3DtJzD8LI7jKLrWakR79RyjP2uREBc0sBXxwFzkD1bNTUOwrK20STKRDWK3rUyAp4 eg+Oiif3+8GKES98JLz4qGoP/O25egrYMyfpjWGPrCvGG577f/a3uXX6mKOdJtrqGpIe tVWp9PmEvkg3eyxerzpGpqSpxshufDNHR12tYpDvMdZ9RQOEb9T6/9F22Xdlf/l2ROLx fqX8c+OG21LD7kQ1Yw+BWYJ365D4snK9JkGkCgW/L8ZbzwtfIa4e1qvHHe+0IRDmCmnP NOrw==
X-Gm-Message-State: ALoCoQlKdDJLyltppSE/aHUCAxyZnhTHtaEGTPLz90e82I95677Kq1UjuCgOawr1r8klSEmxMxnt
MIME-Version: 1.0
X-Received: by 10.140.27.245 with SMTP id 108mr14137180qgx.18.1399645517326; Fri, 09 May 2014 07:25:17 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 9 May 2014 07:25:17 -0700 (PDT)
In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E10AB2E2E@xmb-aln-x08.cisco.com>
References: <1a5601cf6b8e$86c94860$945bd920$@cisco.com> <013A9B371AC6DF4C8AD261897D8F243E10AB2E2E@xmb-aln-x08.cisco.com>
Date: Fri, 9 May 2014 07:25:17 -0700
Message-ID: <CABCOCHSh6UemZRZRtHjACLhwdCO4oVeM9m4_SyK+hPFMz-qzxw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <powladi@cisco.com>
Content-Type: multipart/alternative; boundary=001a11c15260df85a304f8f85d63
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CUrb0Zt0hAT1KpQvhBnpykwkViA
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Union Clarification (was: RE: Y53: YANG 1.1 Key Flexibility)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 14:25:30 -0000

--001a11c15260df85a304f8f85d63
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, May 9, 2014 at 7:00 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <powladi@cisco.com> wrote:

>  [Changing the subject to separate the clarifications on unions from the =
original problem we're trying to solve...]
>
>
>
> [...snip...]
>
>
>
> To check we're on the same page, my understanding is that in that union, =
if a specifier matches the domain-name pattern, it would always resolve to =
the inet:host type (based on RFC 6020 9.2: "When a string representing a un=
ion data type is validated, the string is validated against each member typ=
e, in the order they are specified in the "type" statement, until a match i=
s found.") -- though I could be misunderstanding what "validated" means her=
e.
>
>  In any case, this question arises because there can be overlap in the
> value space of the different elements; so as well as the value itself, we
> need the information on which of the options is being represented to
> interpret the data correctly.
>
> A union type is like a logical-OR expression.
>
> The YANG validation tool goes through each 'type' in order and checks
>
> if the supplied value is valid for that type.  If so, then the leaf is
> valid.
>
> If the parser gets to end of the list and none of the types have validate=
d
>
> for the supplied value, then the leaf is rejected with an invalid-value
> error-tag.
>
>
>
> OK, thanks for the clarification.
>
>
>
> So you want to place the most selective patterns first, and the catch-all
> 'string' last.
>
>
>
> So I still feel I'm missing something here. If it's just a logical-OR
> expression, why would it matter whether the most selective patterns are
> placed first? (And by extension, why is there any mention of ordering at
> all?]
>
>
>


The server implementation can take advantage of the classification.
Having a standard processing order helps for that purpose, but you are
right that it doesn't matter for validation.

The base type string matches everything so no type-stmt following it would
ever get tested.  If the implementation is using the union to convert to th=
e
proper internal binary representation, putting 'string' first would be a
bad idea.


Andy

 [If anything, it sounds like if the most selective pattern is a subset of
> another pattern, it's not serving any purpose beyond possibly
> documentation; and specifying them the other way round would presumably m=
ake
> the validation more efficient.]
>
>
>
> It is an implementation detail how the union type is represented within
> the server.
>
>
>
>    leaf maintenance-domain {
>
>        type maintenance-domain-identifier;
>
>    }
>
>
>
> Right, so if I understand correctly, you are saying that the set of types
> listed in the union is for no other purpose than to determine whether a
> leaf is valid; and the implementation can choose to interpret the value
> however it wishes.
>
>
>
> If so, it would be useful to make this explicit; in particular when Yang
> is mapped to a binary data representation, this subtlety makes a differen=
ce
> to the behavior. (e.g. It looks like it is interpreted as inferring a
> specific type in the Yang JSON draft<https://tools.ietf.org/html/draft-lh=
otka-yang-json-01#section-3.3.10>
> .)
>
>
>
> Thanks,
>
> Peyman
>
>    Based on that, it looks like the data needs to be represented as a
> choice or as independent leaves rather than a union, right?
>
>  No
>
>
>
>
>
>    Thanks,
>
> Peyman
>
>
>
> Andy
>
>
>
>
>
>
>
>  These strings can be overlapping, so this cannot be represented as a
> union.
> =3D=3D=3D=3D=3D=3D
>
> Do you have thoughts on how this should be modelled (and if extensions ar=
e
> needed)?
>
> In particular, it seems there is a solution using Y09-01, though to do
> this we effectively have to reinvent the choice/union using a "must"
> statement (and I'm not sure whether this is even compatible with the "CLI=
"
> comment in Y09-01):
> =3D=3D=3D=3D=3D=3D
> list maintenance-domains {
>   key "host id name";
>   leaf host { type inet:host;  mandatory false; }
>   leaf id   { type hex-string; mandatory false; }
>   leaf name { type string;     mandatory false; }
>
>   // Rule to ensure exactly one of the above is specified
>   must "count(host) + count(id) + count(name) =3D 1";
> }
> =3D=3D=3D=3D=3D=3D
>
> Is that the best approach, or is there a better answer? (For example,
> introducing a union type with a discriminator would perhaps work as it
> would allow the above to be modelled as a union and therefore used as a
> key.)
>
> Thanks,
> Peyman
>
>
>
>
>

--001a11c15260df85a304f8f85d63
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 9, 2014 at 7:00 AM, Peyman Owladi -X (powladi - Ensoft =
Ltd at Cisco) <span dir=3D"ltr">&lt;<a href=3D"mailto:powladi@cisco.com" ta=
rget=3D"_blank">powladi@cisco.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d">[Changing the subject to s</span><span styl=
e=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot=
;;color:#1f497d">eparat</span><span style=3D"font-size:11.0pt;font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">e</span><span styl=
e=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot=
;;color:#1f497d"> the clarifications on unions from the original problem we=
&#39;re trying to solve&hellip;</span><span style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">]</span><s=
pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-se=
rif&quot;;color:#1f497d"><u></u><u></u></span></pre>

<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></span></pre>
<pre><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d">[&hellip;snip&hellip;]<u></u><u></u></span>=
</pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<=
u></u></span></pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">To check we&#3=
9;re on the same page, my understanding is that in that union, if a specifi=
er matches the domain-name pattern, it would always resolve to the inet:hos=
t type (based on RFC 6020 9.2: &quot;</span><span style=3D"color:black">Whe=
n a string representing a union data type is validated, the string is valid=
ated against each member type, in the order they are specified in the &quot=
;type&quot; statement, until a match is found.</span><span style=3D"font-si=
ze:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f4=
97d">&quot;) -- though I could be misunderstanding what &quot;validated&quo=
t; means here.&nbsp;</span><u></u><u></u></pre>

<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1f497d">In any case, this question arises because there =
can be overlap in the value space of the different elements; so as well as =
the value itself, we need the information on which of
 the options is being represented to interpret the data correctly.</span><u=
></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">A union type is like a =
logical-OR expression.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">The YANG validation too=
l goes through each &#39;type&#39; in order and checks<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">if the supplied value i=
s valid for that type. &nbsp;If so, then the leaf is valid.<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">If the parser gets to e=
nd of the list and none of the types have validated<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">for the supplied value,=
 then the leaf is rejected with an invalid-value error-tag.<u></u><u></u></=
p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
f497d"><u></u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">OK, thanks for the clarif=
ication.
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">So you want to place th=
e most selective patterns first, and the catch-all &#39;string&#39; last.<u=
></u><u></u></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">So I still feel I&#39;m m=
issing something here. If it&#39;s just a logical-OR expression, why would =
it matter whether the most selective patterns are placed first?</span><span=
 style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=
&quot;;color:#1f497d">
 (And by extension, why is there any mention of ordering at all?]<u></u><u>=
</u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;</span></p><=
/div></div></div></blockquote><div><br></div><div><br></div><div>The server=
 implementation can take advantage of the classification.</div>
<div>Having a standard processing order helps for that purpose, but you are=
</div><div>right that it doesn&#39;t matter for validation.</div><div><br><=
/div><div>The base type string matches everything so no type-stmt following=
 it would<br>
</div><div>ever get tested. &nbsp;If the implementation is using the union =
to convert to the</div><div>proper internal binary representation, putting =
&#39;string&#39; first would be a bad idea.</div><div><br></div><div><br></=
div>
<div>Andy</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"E=
N-GB" link=3D"blue" vlink=3D"purple"><div><div><p class=3D"MsoNormal"><span=
 style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif=
&quot;;color:#1f497d"><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">[</span><span style=3D"fo=
nt-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color=
:#1f497d">If anything, it sounds like if the most selective pattern is a su=
bset
 of another pattern, it&#39;s not serving any purpose beyond possibly docum=
entation; and specifying them the other way round would
</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1f497d">presumably
</span><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quo=
t;sans-serif&quot;;color:#1f497d">make the validation more efficient.</span=
><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans=
-serif&quot;;color:#1f497d">]</span><span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></=
u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">It is an implementation=
 detail how the union type is represented within the server.<u></u><u></u><=
/p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;leaf maint=
enance-domain {<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp; &nbsp; &n=
bsp;type maintenance-domain-identifier;<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp; &nbsp;}<u></u><u=
></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"color:#1=
f497d"><u></u>&nbsp;<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Right, so if I understand=
 correctly, you are saying that the set of types listed in the union is for=
 no other purpose than to determine whether a leaf is valid;
 and the implementation can choose to interpret the value however it wishes=
.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">If so, it would be useful=
 to make this explicit; in particular when Yang is mapped to a binary data =
representation, this subtlety makes a difference to the
 behavior. (e.g. It looks like it is interpreted as inferring a specific ty=
pe <a href=3D"https://tools.ietf.org/html/draft-lhotka-yang-json-01#section=
-3.3.10" target=3D"_blank">
in the Yang JSON draft</a>.)<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks,<u></u><u></u></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Peyman<u></u><u></u></spa=
n></p>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">
<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1f497d">Based on that, it looks like the data needs to b=
e represented as a choice or as independent leaves rather than a union, rig=
ht?</span><u></u><u></u></p>

</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">No<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<u></u><u></u></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>&nbsp;<u></u></spa=
n></p>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks,</span>=
<u></u><u></u></pre>
<pre style=3D"margin-left:36.0pt"><span style=3D"font-size:11.0pt;font-fami=
ly:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Peyman</span><=
u></u><u></u></pre>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">Andy<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt">&nbsp;<u></u><u></u></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">
&nbsp;<u></u><u></u></p>
</div>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-=
bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt;margin-left:72.0pt">
These strings can be overlapping, so this cannot be represented as a union.=
<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Do you have thoughts on how this should be modelled (and if extensions are =
needed)?<br>
<br>
In particular, it seems there is a solution using Y09-01, though to do this=
 we effectively have to reinvent the choice/union using a &quot;must&quot; =
statement (and I&#39;m not sure whether this is even compatible with the &q=
uot;CLI&quot; comment in Y09-01):<br>

=3D=3D=3D=3D=3D=3D<br>
list maintenance-domains {<br>
&nbsp; key &quot;host id name&quot;;<br>
&nbsp; leaf host { type inet:host; &nbsp;mandatory false; }<br>
&nbsp; leaf id &nbsp; { type hex-string; mandatory false; }<br>
&nbsp; leaf name { type string; &nbsp; &nbsp; mandatory false; }<br>
<br>
&nbsp; // Rule to ensure exactly one of the above is specified<br>
&nbsp; must &quot;count(host) + count(id) + count(name) =3D 1&quot;;<br>
}<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
Is that the best approach, or is there a better answer? (For example, intro=
ducing a union type with a discriminator would perhaps work as it would all=
ow the above to be modelled as a union and therefore used as a key.)<br>

<br>
Thanks,<br>
Peyman<u></u><u></u></p>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin-left:72.0pt">
&nbsp;<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><u></u>&nbsp;<u></u></p=
>
</div>
</div>

</blockquote></div><br></div></div>

--001a11c15260df85a304f8f85d63--


From nobody Fri May  9 15:57:40 2014
Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1166C1A0023 for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 15:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmNO5xoOAbS3 for <netmod@ietfa.amsl.com>; Fri,  9 May 2014 15:57:35 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB6A1A000F for <netmod@ietf.org>; Fri,  9 May 2014 15:57:35 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 22:57:26 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) with mapi id 15.00.0939.000; Fri, 9 May 2014 22:57:26 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt
Thread-Index: AQHPY3s4jQ4Ilm00G0yRQcHkptQdJ5spG4CAgAF4PICAAEsRgIACYVaAgAtp7QA=
Date: Fri, 9 May 2014 22:57:25 +0000
Message-ID: <CF9004B6.6E8ED%kwatsen@juniper.net>
References: <20140429071743.11894.21006.idtracker@ietfa.amsl.com> <CF859937.6B5B6%kwatsen@juniper.net> <20140430194951.GC31986@elstar.local> <CF872BB7.6BF1B%kwatsen@juniper.net> <20140502123925.GC36168@elstar.jacobs.jacobs-university.de>
In-Reply-To: <20140502123925.GC36168@elstar.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [66.129.241.14]
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(189002)(199002)(51444003)(164054003)(83322001)(77982001)(21056001)(76482001)(4396001)(20776003)(64706001)(80022001)(66066001)(36756003)(74502001)(74662001)(31966008)(79102001)(46102001)(83072002)(85852003)(76176999)(54356999)(81342001)(101416001)(83506001)(92726001)(81542001)(92566001)(87936001)(99396002)(99286001)(86362001)(50986999)(2656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AA2419761F15A94FA98302D9E950C97D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uf99gnTi6BPPr7n2rsFZ1NJfLlY
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2014 22:57:38 -0000

Hi Juergen,



>>The netmod-system-management defines config for User Authentication and
>> says that it does so for SSH because that is NETCONF's mandatory to
>> implement transport.  Meanwhile we have netconf-server-model, which is
>> suppose to be just about configuring the NETCONF server, and yet it has
>> user-auth config for TLS (not SSH) in it.  This inconsistency is the
>>issue.
>
>I do not think this is a fair summary. Both, SSH and TLS call home
>need parameters configured on the NC server side but also on the NC
>client side, (e.g. the SSH user and its credentials to call home).
>Where will this stuff go?


Are you asking where NC client information is configured? - as in which
yang model it can go into?

We don't define yang models for NC clients, so what do you mean?


FWIW, on the client side, there are two call-home preconditions:

1. The client needs a trust anchor to verify the device with.  This could
be, for instance, a vendor's well-known CA certificate that the NMS
installed a priori.  Or it could be that the NMS has the device's TLS
server-cert or SSH host-key.   Either way, how the NMS obtains this
information is unspecified in both the 5539bis and reverse-ssh drafts.

2. The client needs to know what user credentials to use when logging into
a device.  As always, the device must be configured with a local user
account.  How the NMS knows the account information configured on the
device is also unspecified in both the 5539bis and reverse-ssh drafts.




>>So, what are our options?
>>=20
>> 1. Go forward with current inconsistency
>>=20
>> 2. Only modify draft-ietf-netconf-server-model, but move TLS user-auth
>>out
>>    of ietf-server-model into a separate model that augments ietf-system
>>=20
>> 3. Similar to #2, but move the ietf-system augmentation back to 5539bis
>>=20
>> 4. Similar to #2, but move the TLS-auth directly (no augmentation) into
>>    the ietf-system model defined in draft-ietf-netmod-system-mgmt
>>=20
>> 5. Move all user-auth config from draft-ietf-netmod-system-mgmt into
>>    draft-ietf-netconf-server-model
>>=20
>> 6. Move all user-auth config from both draft-ietf-netmod-system-mgmt
>>    and draft-ietf-netconf-server-model into yet another draft (for
>>    instance, draft-ietf-netmod-user-auth?)
>>=20
>> 7. Anything else?
>
>As NETMOD WG co-chair, I want to publish draft-ietf-netmod-system-mgmt.
>Building "perfect" modules means we will never finish. Once again,
>modules can be revised and augmented if needed.


So I take it you're ok with options 1, 2, or 3.   Andy said 2 was OK and
no one else responded.   I think that 2 is better than 1 and tied with 3.
So it looks like 2 has the lead, as weak as it is.


Thanks,
Kent




From nobody Mon May 12 17:58:30 2014
Return-Path: <TurnerS@ieca.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1241A07D9 for <netmod@ietfa.amsl.com>; Mon, 12 May 2014 17:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27dr_sHIRzpa for <netmod@ietfa.amsl.com>; Mon, 12 May 2014 17:58:22 -0700 (PDT)
Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.50.11]) by ietfa.amsl.com (Postfix) with ESMTP id AF7771A07D4 for <netmod@ietf.org>; Mon, 12 May 2014 17:58:22 -0700 (PDT)
Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 5EDD158859CDC; Mon, 12 May 2014 19:58:16 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 41A8258859C3A for <netmod@ietf.org>; Mon, 12 May 2014 19:58:16 -0500 (CDT)
Received: from [96.231.225.192] (port=51304 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from <TurnerS@ieca.com>) id 1Wk12t-0005yD-L9; Mon, 12 May 2014 19:58:15 -0500
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Sean Turner <TurnerS@ieca.com>
In-Reply-To: <20140429141003.22969.2351.idtracker@ietfa.amsl.com>
Date: Mon, 12 May 2014 20:58:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F5A1112-C07D-48A5-89AA-9D172B182C20@ieca.com>
References: <20140429141003.22969.2351.idtracker@ietfa.amsl.com>
To: netmod@ietf.org, IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.1874)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 96.231.225.192
X-Exim-ID: 1Wk12t-0005yD-L9
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:51304
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 6
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LqOA_Oqn8Jmvcw5EIRxN_h962Fg
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-system-mgmt-15.txt> (A YANG Data Model for System Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 00:58:24 -0000

Hi,

I wonder if the user authentication model should include something like =
a validity periods for passwords/keys?  When Tatu came and presented to =
SAAG @ IETF 85 =
(http://www.ietf.org/proceedings/85/slides/slides-85-saag-2.pdf) he =
noted that one issue with SSH was keys never expiring (also see =
http://tools.ietf.org/id/draft-ylonen-sshkeybcp-01.txt); would adding a =
date that could be monitored help in this regard?

Additionally, RFC 6187 adds support for certificate for SSH =
authentication shouldn=92t this draft include provisions to support this =
authentication mechanism?

spt

On Apr 29, 2014, at 10:10, The IESG <iesg-secretary@ietf.org> wrote:

>=20
> The IESG has received a request from the NETCONF Data Modeling =
Language
> WG (netmod) to consider the following document:
> - 'A YANG Data Model for System Management'
>  <draft-ietf-netmod-system-mgmt-15.txt> as Proposed Standard
>=20
> 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 2014-05-13. 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.
>=20
> Abstract
>=20
>=20
>   This document defines a YANG data model for the configuration and
>   identification of some common system properties within a device
>   containing a NETCONF server.  This includes data node definitions =
for
>   system identification, time-of-day management, user management, DNS
>   resolver configuration, and some protocol operations for system
>   management.
>=20
>=20
>=20
>=20
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/
>=20
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ballot/
>=20
>=20
> No IPR declarations have been submitted directly on this I-D.
>=20
> Note that RFC 1321 and RFC 6151 are normative references to
> Informational documents.=20
>=20


From nobody Mon May 12 23:24:33 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC19C1A0843; Mon, 12 May 2014 23:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_gHGHk9JWj2; Mon, 12 May 2014 23:24:27 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB21A03F7; Mon, 12 May 2014 23:24:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 78EC3F60; Tue, 13 May 2014 08:24:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MAGTKHlblayR; Tue, 13 May 2014 08:24:19 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 May 2014 08:24:19 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC33020017; Tue, 13 May 2014 08:24:19 +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 los6UIr4lHXi; Tue, 13 May 2014 08:24:18 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E191120013; Tue, 13 May 2014 08:24:17 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id A64542CCF950; Tue, 13 May 2014 08:24:17 +0200 (CEST)
Date: Tue, 13 May 2014 08:24:17 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Sean Turner <TurnerS@ieca.com>
Message-ID: <20140513062417.GB86057@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Sean Turner <TurnerS@ieca.com>, netmod@ietf.org, IESG <iesg@ietf.org>
References: <20140429141003.22969.2351.idtracker@ietfa.amsl.com> <6F5A1112-C07D-48A5-89AA-9D172B182C20@ieca.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6F5A1112-C07D-48A5-89AA-9D172B182C20@ieca.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/x7ZOcqylO0RAXyNpK2R4o0aeCAM
Cc: IESG <iesg@ietf.org>, netmod@ietf.org
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-system-mgmt-15.txt> (A YANG Data Model for System Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 06:24:29 -0000

Sean,

we can keep adding and finish never.

/js

On Mon, May 12, 2014 at 08:58:13PM -0400, Sean Turner wrote:
> Hi,
> 
> I wonder if the user authentication model should include something like a validity periods for passwords/keys?  When Tatu came and presented to SAAG @ IETF 85 (http://www.ietf.org/proceedings/85/slides/slides-85-saag-2.pdf) he noted that one issue with SSH was keys never expiring (also see http://tools.ietf.org/id/draft-ylonen-sshkeybcp-01.txt); would adding a date that could be monitored help in this regard?
> 
> Additionally, RFC 6187 adds support for certificate for SSH authentication shouldn’t this draft include provisions to support this authentication mechanism?
> 
> spt
> 
> On Apr 29, 2014, at 10:10, The IESG <iesg-secretary@ietf.org> wrote:
> 
> > 
> > The IESG has received a request from the NETCONF Data Modeling Language
> > WG (netmod) to consider the following document:
> > - 'A YANG Data Model for System Management'
> >  <draft-ietf-netmod-system-mgmt-15.txt> as 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 2014-05-13. 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.
> > 
> > Abstract
> > 
> > 
> >   This document defines a YANG data model for the configuration and
> >   identification of some common system properties within a device
> >   containing a NETCONF server.  This includes data node definitions for
> >   system identification, time-of-day management, user management, DNS
> >   resolver configuration, and some protocol operations for system
> >   management.
> > 
> > 
> > 
> > 
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/
> > 
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ballot/
> > 
> > 
> > No IPR declarations have been submitted directly on this I-D.
> > 
> > Note that RFC 1321 and RFC 6151 are normative references to
> > Informational documents. 
> > 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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 nobody Tue May 13 09:15:05 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031B81A0102 for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 09:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.578
X-Spam-Level: 
X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Euw8dfNcQ_IW for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 09:15:01 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id D045F1A00DD for <netmod@ietf.org>; Tue, 13 May 2014 09:15:00 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id i8so697299qcq.18 for <netmod@ietf.org>; Tue, 13 May 2014 09:14:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Dhv0JH3iHsufKjYeS0YI25pPC3OiAuJhK28ffMGlWkY=; b=lVhX15PU06TusmhD6gQGpmDOhc5IC10QbhUR4npr+VQiQOqNyh9hWMCN22ffDL3Crw yn/noGuqE7dHiWC+ESk7cNnHLzQaf1PC0aeEaouwybHgbtkDmKE3hEvz0oHmlAtnqIMf bEP6UdpMQ5s/A6D0+svILlXAsQnUgMNEHJtpWdzSRDPIlu8s3Jeax4xdSooxJ85VoJS3 0ADcU74X4H7JoZfrSO9kT0cobM7nTlt0IqlUaSA5khc4Ye8Czco9ZtI7LaN3AavRHI0x Ln7omes94nJcoRlrV1Uy9KeFWnJaYKcGPLAY1dyv/W0c9uxpHp0jtMLtIXT5mgV7EeE8 p1Hg==
X-Gm-Message-State: ALoCoQlbMqsnE23uh/AcoMRhX64+t74ckOPNvjJAd0RdfhmANycdlyg8ghYaIfgKMz43CIUzbgrL
MIME-Version: 1.0
X-Received: by 10.224.138.3 with SMTP id y3mr49498744qat.78.1399997694236; Tue, 13 May 2014 09:14:54 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Tue, 13 May 2014 09:14:54 -0700 (PDT)
Date: Tue, 13 May 2014 09:14:54 -0700
Message-ID: <CABCOCHS4N3n081Sz4Ow-FkkAsLfSdOpzyhTd3zFWsgPpVF_jnw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b672b44406cac04f94a5d1a
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i9p_ebWMTyMQ4S950q4HL5kKEaw
Subject: [netmod] first pass at YANG 1.1 issue list classification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 16:15:03 -0000

--047d7b672b44406cac04f94a5d1a
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I think it might help to classify the issues.
I made a rough pass at the randomly ordered list.
It would be useful to rank how much work/impact
each issue would be to address. (I did not attempt that.)
It would be useful to immediately reject any proposal
that would prevent a YANG 1.0 module from being
valid in YANG 1.1. (I did not check that.)

(N=new, F=fix; also a judgement call)


Conformance
---------------
N Y01: allow boolean if-feature
N Y03: allow if-feature in refine
N Y11: allow if-feature on enums
F Y15: identity advertisement problem
N Y16: module advertisement optimization
N Y27: allow mandatory nodes in an updated module
N Y45: better conformance mechanism

XPath
------
N Y04: accessible tree in xpath in notifs and rpc
F Y05: unprefixed path in top-level typedef
F Y18: fix "when" expression context node problem
N Y20: new set of built-in XPath functions
N Y21: statement to define new XPath functions in a module

Syntax
------
N Y02: allow must in input, output, and notification
F Y06: escaped characters in double quoted strings
F Y08: make leaf-list of type empty illegal
N Y10: allow restrictions on enumerations
N Y12: initialized-by system
N Y13: allow multiple inheritance for identities
F Y14: clarify the string value for identities when used in must/when
N Y22: support constraints on unions
N Y23: support negative patterns as string restrictions
N Y24: YIN -> YANG translation breaks text formatting
N Y25: make enum numbering purely informative and optional
N Y26: allow mandatory nodes in augment
N Y28: support default values in leaf-lists
N Y29: allow choice as a short-hand case
N Y30: allow leafref in union
N Y31: allow require-instance in leafref
N Y32: allow boolean combinations of pattern
N Y33: add 'attribute' statement
F Y34: remove/deprecate/replace the 'anyxml' statement
N Y35: allow empty in union
N Y38: add 'mandatory' to NP-container
F Y39: define the terms system/user-controlled instances
N Y40: add floating point base types
F Y41: clarification of "must" in NP-container
N Y43: add exception statement
N Y44: add a mechanism to parameterize error-message
N Y46: data-specific meta-data
F Y47: bit name too restrictive
F Y49: clarify nested submodule behavior
N Y50: additional extension grammar validation
N Y52: add a shorthand statement for 'mandatory'

Lists
------
F Y07: do not allow when or if-feature on keys
N Y09: introduce optional keys
N Y17: support "augment" of unique
N Y19: we need a better unique
N Y53: allow deep keys

Notifications
-------------
N Y36: associate a notification with a data node
N Y37: allow notifications to be derived from other notifications

Protocol
--------
N Y42: a better model for configuration versus state data is needed
F Y48: enabled leaf design pattern
N Y51: support for long running commands

--047d7b672b44406cac04f94a5d1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I think it might help to classify t=
he issues.</div><div>I made a rough pass at the randomly ordered list.</div=
><div>It would be useful to rank how much work/impact</div><div>each issue =
would be to address. (I did not attempt that.)</div>
<div>It would be useful to immediately reject any proposal</div><div>that w=
ould prevent a YANG 1.0 module from being</div><div>valid in YANG 1.1. (I d=
id not check that.)</div><div><br></div><div>(N=3Dnew, F=3Dfix; also a judg=
ement call)</div>
<div><br></div><div><div><br></div><div>Conformance</div><div>-------------=
--</div><div>N Y01: allow boolean if-feature</div><div>N Y03: allow if-feat=
ure in refine</div><div>N Y11: allow if-feature on enums</div><div>F Y15: i=
dentity advertisement problem</div>
<div>N Y16: module advertisement optimization</div><div>N Y27: allow mandat=
ory nodes in an updated module</div><div>N Y45: better conformance mechanis=
m</div><div><br></div><div>XPath</div><div>------</div><div>N Y04: accessib=
le tree in xpath in notifs and rpc</div>
<div>F Y05: unprefixed path in top-level typedef</div><div>F Y18: fix &quot=
;when&quot; expression context node problem</div><div>N Y20: new set of bui=
lt-in XPath functions</div><div>N Y21: statement to define new XPath functi=
ons in a module</div>
<div><br></div><div>Syntax</div><div>------</div><div>N Y02: allow must in =
input, output, and notification</div><div>F Y06: escaped characters in doub=
le quoted strings</div><div>F Y08: make leaf-list of type empty illegal</di=
v>
<div>N Y10: allow restrictions on enumerations</div><div>N Y12: initialized=
-by system</div><div>N Y13: allow multiple inheritance for identities</div>=
<div>F Y14: clarify the string value for identities when used in must/when<=
/div>
<div>N Y22: support constraints on unions</div><div>N Y23: support negative=
 patterns as string restrictions</div><div>N Y24: YIN -&gt; YANG translatio=
n breaks text formatting</div><div>N Y25: make enum numbering purely inform=
ative and optional</div>
<div>N Y26: allow mandatory nodes in augment</div><div>N Y28: support defau=
lt values in leaf-lists</div><div>N Y29: allow choice as a short-hand case<=
/div><div>N Y30: allow leafref in union</div><div>N Y31: allow require-inst=
ance in leafref</div>
<div>N Y32: allow boolean combinations of pattern</div><div>N Y33: add &#39=
;attribute&#39; statement</div><div>F Y34: remove/deprecate/replace the &#3=
9;anyxml&#39; statement</div><div>N Y35: allow empty in union</div><div>
N Y38: add &#39;mandatory&#39; to NP-container</div><div>F Y39: define the =
terms system/user-controlled instances</div><div>N Y40: add floating point =
base types</div><div>F Y41: clarification of &quot;must&quot; in NP-contain=
er</div>
<div>N Y43: add exception statement</div><div>N Y44: add a mechanism to par=
ameterize error-message</div><div>N Y46: data-specific meta-data</div><div>=
F Y47: bit name too restrictive</div><div>F Y49: clarify nested submodule b=
ehavior</div>
<div>N Y50: additional extension grammar validation</div><div>N Y52: add a =
shorthand statement for &#39;mandatory&#39;</div><div><br></div><div>Lists<=
/div><div>------</div><div>F Y07: do not allow when or if-feature on keys</=
div>
<div>N Y09: introduce optional keys</div><div>N Y17: support &quot;augment&=
quot; of unique</div><div>N Y19: we need a better unique</div><div>N Y53: a=
llow deep keys</div><div><br></div><div>Notifications</div><div>-----------=
--</div>
<div>N Y36: associate a notification with a data node</div><div>N Y37: allo=
w notifications to be derived from other notifications</div><div><br></div>=
<div>Protocol</div><div>--------</div><div>N Y42: a better model for config=
uration versus state data is needed</div>
<div>F Y48: enabled leaf design pattern</div><div>N Y51: support for long r=
unning commands</div></div><div><br></div><div><br></div><div><br></div></d=
iv>

--047d7b672b44406cac04f94a5d1a--


From nobody Tue May 13 14:56:13 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E771A020A; Tue, 13 May 2014 14:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p270CC6oFQn0; Tue, 13 May 2014 14:53:28 -0700 (PDT)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 69D0F1A01FE; Tue, 13 May 2014 14:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=253; q=dns/txt; s=iport; t=1400018002; x=1401227602; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=4oFmIAYRIg+3qO32X87MhJnNn1TPBnWrl817FF9q3BE=; b=iQZzadP4TxMMJE3HouRBhMvMuh1UzwDdueVtqdKRCx5774R6gBgE/dPS e2ZH1JBL1nxPFD3ZWGxRJ46xrlCOeHDNV94DiNnS9N5XsNcG/kagI7a2v tH7yxCc1k3jK7E/6ppDn0gh1f5PQadaREfPJy8wUWMvgObBO52kPhE39m M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvgKAFuTclNIo8UY/2dsb2JhbABZAQ6DRo1PuH4CBQGBPnMBgh1HQD0WGAMCAQIBNhgDAQYIAQEFhW2CSw2cS6oqF5FZgTwEihGPP4ZohTmGb4J7AlkdMA
X-IronPort-AV: E=Sophos;i="4.97,1046,1389744000"; d="scan'208";a="40720526"
Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 13 May 2014 21:53:19 +0000
Received: from [10.154.208.84] ([10.154.208.84]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4DLrHnH023191; Tue, 13 May 2014 21:53:18 GMT
Message-ID: <5372944D.5010509@cisco.com>
Date: Tue, 13 May 2014 14:53:17 -0700
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: undisclosed-recipients:;
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y_RUV0-6bkP6DVxBzOMv6uoYegE
X-Mailman-Approved-At: Tue, 13 May 2014 14:56:11 -0700
Subject: [netmod] YANG Advice and Editing Session at the next IETF meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 21:53:30 -0000

[Sorry for the potential cross-posting]

http://www.ietf.org/meeting/90/tutorials/yang-session.html
Let me stress that this should be an interactive session, and not a 
tutorial.
So come with your (plan to create) YANG modules.

Regards, Benoit


From nobody Tue May 13 18:41:48 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB11A0181 for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 18:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.25
X-Spam-Level: 
X-Spam-Status: No, score=-99.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyu5bgLXB9PU for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 18:41:43 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B21A0173 for <netmod@ietf.org>; Tue, 13 May 2014 18:41:42 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 4544F125BBFD for <netmod@ietf.org>; Wed, 14 May 2014 09:41:26 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4E1dknO032686 for <netmod@ietf.org>; Wed, 14 May 2014 09:39:46 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
To: netmod@ietf.org
MIME-Version: 1.0
X-KeepSent: 45A839A3:22EAA9F8-48257CD8:00069DC9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF45A839A3.22EAA9F8-ON48257CD8.00069DC9-48257CD8.000922DB@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Wed, 14 May 2014 09:39:47 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-14 09:39:47, Serialize complete at 2014-05-14 09:39:47
Content-Type: multipart/alternative; boundary="=_alternative 000922DB48257CD8_="
X-MAIL: mse02.zte.com.cn s4E1dknO032686
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NFfhnH_9TKyGnspo4D_VGmIIaAU
Cc: ye.xu1@zte.com.cn
Subject: [netmod] some questions about leaf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 01:41:46 -0000

This is a multipart message in MIME format.

--=_alternative 000922DB48257CD8_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,
   I have some questions about usage of leaf.
   1. Non-mandatory leaf must have default value? or non-mandatory leaf 
with config true must have default value?
      for example:
      If a list contains a optional leaf node, if this leaf node has no 
default value, 
      when a list instance is created ,what this leaf'value will be?

   2. can leaf node support create operation?
      If a leaf node must have default value, obviously create operation 
can not be supported.

   3. How to resolve the problem that a leaf node can not be defined a 
static default value, but it has a uncertain default value when it is 
created?
      For example:
      list foo {
           key name;
      leaf name {...}
      leaf type {
           type enumeration {
                enum foo1 {...}
                enum foo2 {...}
           }
      }
      leaf value {...}

      }

      If list 'foo' is created, if leaf named 'type''s value is foo1, the 
default value of leaf named 'value' is 10,
      if leaf named 'type''s value is foo2, the default value of leaf 
named  'value' is 20.

      Solution:
      1. Add when statement as default's substatement.
      2. Leaf supports multi default statement.
 
      For example:
      leaf value {
           default 10 {
              when "type == foo1";
           }
           default 20 {
              when "type == foo2";
           }
           type int32;
      } 

      Martin, can this issue can be added to YANG1.1 issues? 
/frank
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 000922DB48257CD8_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Hi all,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;I have some questions about
usage of leaf.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;1. Non-mandatory leaf must
have default value? or non-mandatory leaf with config true must have default
value?</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; for example:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; If a list contains
a optional leaf node, if this leaf node has no default value, </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; when a list instance
is created ,what this leaf'value will be?</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;2. can leaf node support
create operation?</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; If a leaf node
must have default value, obviously create operation can not be supported.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp;3. How to resolve the problem
that a leaf node can not be defined a static default value, but it has
a uncertain default value when it is created?</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; For example:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; list foo {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;key
name;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; leaf name {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; leaf type {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;type
enumeration {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; enum foo1 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; enum foo2 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; }</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; leaf value {...}</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; }</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; If list 'foo' is
created, if leaf named 'type''s value is foo1, the default value of leaf
named 'value' is 10,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; if leaf named 'type''s
value is foo2, the default value of leaf named &nbsp;'value' is 20.</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; Solution:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; 1. Add when statement
as default's substatement.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; 2. Leaf supports
multi default statement.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; For example:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; leaf value {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;default
10 {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; when &quot;type == foo1&quot;;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;default
20 {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; when &quot;type == foo2&quot;;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;type
int32;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; } </font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; Martin, can this
issue can be added to YANG1.1 issues? &nbsp; &nbsp;</font>
<br><font size=2 face="sans-serif">/frank</font>

<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre><br>

--=_alternative 000922DB48257CD8_=--


From nobody Tue May 13 23:39:26 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E111A0258 for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 23:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bis420M3cKB for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 23:39:22 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 57D5C1A025B for <netmod@ietf.org>; Tue, 13 May 2014 23:39:21 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B605B13F8B3; Wed, 14 May 2014 08:39:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400049553; bh=cEtbDSBKquwagTbpjeE0uwgJWoc+ZmbLSawMyv61kGw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bB/MtZX9Hklps72CuZY9ws0ZjrrRXYL8gaEAVXRWOm3dJuMc/5tk/ml9K9RYqIVao dowAZ2MxbUIi93kFyIO1EXvo4LKetD4naW+ce/i3eioNbo2XF7RmJ7Bv10pBdKNYOG 2c51qwZV9LDz1Zg6O43w+M/IiWitYnTVXMiYjqZ4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <OF45A839A3.22EAA9F8-ON48257CD8.00069DC9-48257CD8.000922DB@zte.com.cn>
Date: Wed, 14 May 2014 08:39:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B49F128A-889B-42BA-A16B-B064EA546027@nic.cz>
References: <OF45A839A3.22EAA9F8-ON48257CD8.00069DC9-48257CD8.000922DB@zte.com.cn>
To: feng.chong33@zte.com.cn
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aBMEkVr1Kkruze47SOVm7CcWEmg
Cc: ye.xu1@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] some questions about leaf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 06:39:24 -0000

On 14 May 2014, at 03:39, feng.chong33@zte.com.cn wrote:

> Hi all,=20
>    I have some questions about usage of leaf.=20
>    1. Non-mandatory leaf must have default value? or non-mandatory =
leaf with config true must have default value?

No to both questions.

> =20
>       for example:=20
>       If a list contains a optional leaf node, if this leaf node has =
no default value,=20
>       when a list instance is created ,what this leaf'value will be?

It depends:

- either the value doesn=92t exist (e.g. if you don=92t define an alias =
to a user name, there is none),
- or the server chooses some value for *operational* use.


> =20
>=20
>    2. can leaf node support create operation?=20
>       If a leaf node must have default value, obviously create =
operation can not be supported.=20
>=20
>    3. How to resolve the problem that a leaf node can not be defined a =
static default value, but it has a uncertain default value when it is =
created?=20
>       For example:=20
>       list foo {=20
>            key name;=20
>       leaf name {...}=20
>       leaf type {=20
>            type enumeration {=20
>                 enum foo1 {...}=20
>                 enum foo2 {...}=20
>            }=20
>       }=20
>       leaf value {...}=20
>=20
>       }=20
>=20
>       If list 'foo' is created, if leaf named 'type''s value is foo1, =
the default value of leaf named 'value' is 10,=20
>       if leaf named 'type''s value is foo2, the default value of leaf =
named  'value' is 20.

The solution is to specify this in a description.

> =20
>=20
>       Solution:=20
>       1. Add when statement as default's substatement.=20
>       2. Leaf supports multi default statement.=20
>      =20
>       For example:=20
>       leaf value {=20
>            default 10 {=20
>               when "type =3D=3D foo1";=20
>            }=20
>            default 20 {=20
>               when "type =3D=3D foo2";=20
>            }=20
>            type int32;=20
>       }=20

I am against doing this. Such a use of =91when=92 would suffer from the =
same problem as in Y18 (missing context node), and it could also lead to =
race conditions, for example if defaults of two leafs depend on each =
other.

Moreover, there are other ways how dynamic defaults may be derived. For =
example, if default-lifetime is not configured for IPv6 router =
advertisements, the value of 3*max-rtr-adv-interval should be used =
(operationally).

>=20
>       Martin, can this issue can be added to YANG1.1 issues?

Note that the issue list was closed on May 7.

Lada

>    =20
> /frank=20
>=20
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this =
mail (and any attachment transmitted herewith) is privileged and =
confidential and is intended for the exclusive use of the addressee(s).  =
If you are not an intended recipient, any disclosure, reproduction, =
distribution or other dissemination or use of the information contained =
is strictly prohibited.  If you have received this mail in error, please =
delete it and notify us immediately.
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue May 13 23:59:42 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75C31A0264 for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 23:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.5
X-Spam-Level: 
X-Spam-Status: No, score=-99.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Pfuswn20RQq for <netmod@ietfa.amsl.com>; Tue, 13 May 2014 23:59:24 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 89F4A1A025C for <netmod@ietf.org>; Tue, 13 May 2014 23:59:23 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id CBB0D12C9905; Wed, 14 May 2014 14:59:04 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4E6x6WH065709; Wed, 14 May 2014 14:59:06 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <B49F128A-889B-42BA-A16B-B064EA546027@nic.cz>
References: <OF45A839A3.22EAA9F8-ON48257CD8.00069DC9-48257CD8.000922DB@zte.com.cn> <B49F128A-889B-42BA-A16B-B064EA546027@nic.cz>
To: Ladislav Lhotka <lhotka@nic.cz>
MIME-Version: 1.0
X-KeepSent: 5DE22AE9:100BC6C2-48257CD8:00254834; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF5DE22AE9.100BC6C2-ON48257CD8.00254834-48257CD8.00265F96@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Wed, 14 May 2014 14:59:08 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-14 14:59:08, Serialize complete at 2014-05-14 14:59:08
Content-Type: multipart/alternative; boundary="=_alternative 00265F9648257CD8_="
X-MAIL: mse02.zte.com.cn s4E6x6WH065709
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aGf3oZqAo3ArakFw247oCHCSmGQ
Cc: ye.xu1@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] some questions about leaf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 06:59:33 -0000

This is a multipart message in MIME format.

--=_alternative 00265F9648257CD8_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCkxhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4g0LTT2iAyMDE0LTA1LTE0
IDE0OjM5OjEzOg0KDQo+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gDQo+IDIwMTQt
MDUtMTQgMTQ6MzkNCj4gDQo+IMrVvP7Iyw0KPiANCj4gZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24s
IA0KPiANCj4gs63LzQ0KPiANCj4gbmV0bW9kQGlldGYub3JnLCB5ZS54dTFAenRlLmNvbS5jbg0K
PiANCj4g1vfM4g0KPiANCj4gUmU6IFtuZXRtb2RdIHNvbWUgcXVlc3Rpb25zIGFib3V0IGxlYWYN
Cj4gDQo+IA0KPiBPbiAxNCBNYXkgMjAxNCwgYXQgMDM6MzksIGZlbmcuY2hvbmczM0B6dGUuY29t
LmNuIHdyb3RlOg0KPiANCj4gPiBIaSBhbGwsIA0KPiA+ICAgIEkgaGF2ZSBzb21lIHF1ZXN0aW9u
cyBhYm91dCB1c2FnZSBvZiBsZWFmLiANCj4gPiAgICAxLiBOb24tbWFuZGF0b3J5IGxlYWYgbXVz
dCBoYXZlIGRlZmF1bHQgdmFsdWU/IG9yIG5vbi1tYW5kYXRvcnkNCj4gbGVhZiB3aXRoIGNvbmZp
ZyB0cnVlIG11c3QgaGF2ZSBkZWZhdWx0IHZhbHVlPw0KPiANCj4gTm8gdG8gYm90aCBxdWVzdGlv
bnMuDQo+IA0KPiA+IA0KPiA+ICAgICAgIGZvciBleGFtcGxlOiANCj4gPiAgICAgICBJZiBhIGxp
c3QgY29udGFpbnMgYSBvcHRpb25hbCBsZWFmIG5vZGUsIGlmIHRoaXMgbGVhZiBub2RlIA0KPiBo
YXMgbm8gZGVmYXVsdCB2YWx1ZSwgDQo+ID4gICAgICAgd2hlbiBhIGxpc3QgaW5zdGFuY2UgaXMg
Y3JlYXRlZCAsd2hhdCB0aGlzIGxlYWYndmFsdWUgd2lsbCBiZT8NCj4gDQo+IEl0IGRlcGVuZHM6
DQo+IA0KPiAtIGVpdGhlciB0aGUgdmFsdWUgZG9lc26hr3QgZXhpc3QgKGUuZy4gaWYgeW91IGRv
bqGvdCBkZWZpbmUgYW4gYWxpYXMgDQo+IHRvIGEgdXNlciBuYW1lLCB0aGVyZSBpcyBub25lKSwN
Cj4gLSBvciB0aGUgc2VydmVyIGNob29zZXMgc29tZSB2YWx1ZSBmb3IgKm9wZXJhdGlvbmFsKiB1
c2UuDQo+IA0KPiANCj4gPiANCj4gPiANCj4gPiAgICAyLiBjYW4gbGVhZiBub2RlIHN1cHBvcnQg
Y3JlYXRlIG9wZXJhdGlvbj8gDQo+ID4gICAgICAgSWYgYSBsZWFmIG5vZGUgbXVzdCBoYXZlIGRl
ZmF1bHQgdmFsdWUsIG9idmlvdXNseSBjcmVhdGUgDQo+IG9wZXJhdGlvbiBjYW4gbm90IGJlIHN1
cHBvcnRlZC4gDQo+ID4gDQo+ID4gICAgMy4gSG93IHRvIHJlc29sdmUgdGhlIHByb2JsZW0gdGhh
dCBhIGxlYWYgbm9kZSBjYW4gbm90IGJlIA0KPiBkZWZpbmVkIGEgc3RhdGljIGRlZmF1bHQgdmFs
dWUsIGJ1dCBpdCBoYXMgYSB1bmNlcnRhaW4gZGVmYXVsdCB2YWx1ZQ0KPiB3aGVuIGl0IGlzIGNy
ZWF0ZWQ/IA0KPiA+ICAgICAgIEZvciBleGFtcGxlOiANCj4gPiAgICAgICBsaXN0IGZvbyB7IA0K
PiA+ICAgICAgICAgICAga2V5IG5hbWU7IA0KPiA+ICAgICAgIGxlYWYgbmFtZSB7Li4ufSANCj4g
PiAgICAgICBsZWFmIHR5cGUgeyANCj4gPiAgICAgICAgICAgIHR5cGUgZW51bWVyYXRpb24geyAN
Cj4gPiAgICAgICAgICAgICAgICAgZW51bSBmb28xIHsuLi59IA0KPiA+ICAgICAgICAgICAgICAg
ICBlbnVtIGZvbzIgey4uLn0gDQo+ID4gICAgICAgICAgICB9IA0KPiA+ICAgICAgIH0gDQo+ID4g
ICAgICAgbGVhZiB2YWx1ZSB7Li4ufSANCj4gPiANCj4gPiAgICAgICB9IA0KPiA+IA0KPiA+ICAg
ICAgIElmIGxpc3QgJ2ZvbycgaXMgY3JlYXRlZCwgaWYgbGVhZiBuYW1lZCAndHlwZScncyB2YWx1
ZSBpcyANCj4gZm9vMSwgdGhlIGRlZmF1bHQgdmFsdWUgb2YgbGVhZiBuYW1lZCAndmFsdWUnIGlz
IDEwLCANCj4gPiAgICAgICBpZiBsZWFmIG5hbWVkICd0eXBlJydzIHZhbHVlIGlzIGZvbzIsIHRo
ZSBkZWZhdWx0IHZhbHVlIG9mIA0KPiBsZWFmIG5hbWVkICAndmFsdWUnIGlzIDIwLg0KPiANCj4g
VGhlIHNvbHV0aW9uIGlzIHRvIHNwZWNpZnkgdGhpcyBpbiBhIGRlc2NyaXB0aW9uLg0KPiANCj4g
PiANCj4gPiANCj4gPiAgICAgICBTb2x1dGlvbjogDQo+ID4gICAgICAgMS4gQWRkIHdoZW4gc3Rh
dGVtZW50IGFzIGRlZmF1bHQncyBzdWJzdGF0ZW1lbnQuIA0KPiA+ICAgICAgIDIuIExlYWYgc3Vw
cG9ydHMgbXVsdGkgZGVmYXVsdCBzdGF0ZW1lbnQuIA0KPiA+IA0KPiA+ICAgICAgIEZvciBleGFt
cGxlOiANCj4gPiAgICAgICBsZWFmIHZhbHVlIHsgDQo+ID4gICAgICAgICAgICBkZWZhdWx0IDEw
IHsgDQo+ID4gICAgICAgICAgICAgICB3aGVuICJ0eXBlID09IGZvbzEiOyANCj4gPiAgICAgICAg
ICAgIH0gDQo+ID4gICAgICAgICAgICBkZWZhdWx0IDIwIHsgDQo+ID4gICAgICAgICAgICAgICB3
aGVuICJ0eXBlID09IGZvbzIiOyANCj4gPiAgICAgICAgICAgIH0gDQo+ID4gICAgICAgICAgICB0
eXBlIGludDMyOyANCj4gPiAgICAgICB9IA0KPiANCj4gSSBhbSBhZ2FpbnN0IGRvaW5nIHRoaXMu
IFN1Y2ggYSB1c2Ugb2Ygoa53aGVuoa8gd291bGQgc3VmZmVyIGZyb20gdGhlIA0KPiBzYW1lIHBy
b2JsZW0gYXMgaW4gWTE4IChtaXNzaW5nIGNvbnRleHQgbm9kZSksIGFuZCBpdCBjb3VsZCBhbHNv
IA0KPiBsZWFkIHRvIHJhY2UgY29uZGl0aW9ucywgZm9yIGV4YW1wbGUgaWYgZGVmYXVsdHMgb2Yg
dHdvIGxlYWZzIGRlcGVuZA0KPiBvbiBlYWNoIG90aGVyLg0KPiANCg0KSSBkbyBrbm93IGl0LCBi
dXQgZHluYW1pYyBkZWZhdWx0cyBuZWVkcyB0byBiZSBkZWZpbmVkIGluIG15IHByYWN0aWNlLg0K
TmV0d29yayBtYW5hZ2VyIHdhbnRzIHRvIGtub3cgaXQuIEkgdGhpbmsgYSB2YWxpZCBtb2RlbCBo
YXZlIG5vIHByb2JsZW0gDQp5b3UgbWVudGlvbmVkLg0KSXQgb25seSBhZGRzIHNvbWUgZGlmZmlj
dWx0eSB0byBZQU5HIHBhcnNlci4gDQoNCj4gTW9yZW92ZXIsIHRoZXJlIGFyZSBvdGhlciB3YXlz
IGhvdyBkeW5hbWljIGRlZmF1bHRzIG1heSBiZSBkZXJpdmVkLiANCj4gRm9yIGV4YW1wbGUsIGlm
IGRlZmF1bHQtbGlmZXRpbWUgaXMgbm90IGNvbmZpZ3VyZWQgZm9yIElQdjYgcm91dGVyIA0KPiBh
ZHZlcnRpc2VtZW50cywgdGhlIHZhbHVlIG9mIDMqbWF4LXJ0ci1hZHYtaW50ZXJ2YWwgc2hvdWxk
IGJlIHVzZWQgDQo+IChvcGVyYXRpb25hbGx5KS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIGl0LiBD
YW4gWUFORyBleHByZXNzIHRoaXMgdXNpbmcgZXhpc3Qgc3ludGF4Pw0KPiANCj4gPiANCj4gPiAg
ICAgICBNYXJ0aW4sIGNhbiB0aGlzIGlzc3VlIGNhbiBiZSBhZGRlZCB0byBZQU5HMS4xIGlzc3Vl
cz8NCj4gDQo+IE5vdGUgdGhhdCB0aGUgaXNzdWUgbGlzdCB3YXMgY2xvc2VkIG9uIE1heSA3Lg0K
PiANCj4gTGFkYQ0KPiANCj4gPiANCj4gPiAvZnJhbmsgDQo+ID4gDQo+ID4gLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5m
b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo
aXMNCj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBw
cml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4
Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBp
bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0
cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1h
dGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2Vp
dmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1
cyBpbW1lZGlhdGVseS4NCj4gPiANCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4g
PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZA0KPiANCj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQ
R1AgS2V5IElEOiBFNzRFOEMwQw0KPiANCj4gDQo+IA0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT
ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh
bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k
IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo
ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu
eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p
bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy
b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg==

--=_alternative 00265F9648257CD8_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPkxhZGlzbGF2IExob3RrYSAmbHQ7bGhvdGthQG5pYy5jeiZndDsg0LTT
2iAyMDE0LTA1LTE0DQoxNDozOToxMzo8YnI+DQo8YnI+DQomZ3Q7IExhZGlzbGF2IExob3RrYSAm
bHQ7bGhvdGthQG5pYy5jeiZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDIwMTQtMDUtMTQgMTQ6Mzk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyDK1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgPC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IG5ldG1vZEBpZXRmLm9yZywgeWUueHUxQHp0
ZS5jb20uY248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0
OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg
UmU6IFtuZXRtb2RdIHNvbWUgcXVlc3Rpb25zIGFib3V0IGxlYWY8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDE0IE1heSAyMDE0
LCBhdCAwMzozOSwgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyA8YnI+
DQomZ3Q7ICZndDsgSGkgYWxsLCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0kgaGF2ZSBz
b21lIHF1ZXN0aW9ucyBhYm91dCB1c2FnZSBvZiBsZWFmLiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOzEuIE5vbi1tYW5kYXRvcnkgbGVhZiBtdXN0IGhhdmUgZGVmYXVsdCB2YWx1ZT8gb3IN
Cm5vbi1tYW5kYXRvcnk8YnI+DQomZ3Q7IGxlYWYgd2l0aCBjb25maWcgdHJ1ZSBtdXN0IGhhdmUg
ZGVmYXVsdCB2YWx1ZT88YnI+DQomZ3Q7IDxicj4NCiZndDsgTm8gdG8gYm90aCBxdWVzdGlvbnMu
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IGZvciBleGFtcGxlOiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgSWYgYSBsaXN0IGNvbnRhaW5zIGEgb3B0aW9uYWwgbGVhZiBub2RlLA0KaWYgdGhpcyBs
ZWFmIG5vZGUgPGJyPg0KJmd0OyBoYXMgbm8gZGVmYXVsdCB2YWx1ZSwgPGJyPg0KJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdoZW4gYSBsaXN0IGluc3RhbmNlIGlzIGNyZWF0ZWQgLHdo
YXQgdGhpcw0KbGVhZid2YWx1ZSB3aWxsIGJlPzxicj4NCiZndDsgPGJyPg0KJmd0OyBJdCBkZXBl
bmRzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAtIGVpdGhlciB0aGUgdmFsdWUgZG9lc26hr3QgZXhp
c3QgKGUuZy4gaWYgeW91IGRvbqGvdCBkZWZpbmUgYW4NCmFsaWFzIDxicj4NCiZndDsgdG8gYSB1
c2VyIG5hbWUsIHRoZXJlIGlzIG5vbmUpLDxicj4NCiZndDsgLSBvciB0aGUgc2VydmVyIGNob29z
ZXMgc29tZSB2YWx1ZSBmb3IgKm9wZXJhdGlvbmFsKiB1c2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDsyLiBjYW4gbGVhZiBub2RlIHN1cHBvcnQgY3JlYXRlIG9wZXJhdGlvbj8gPGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIGEgbGVhZiBub2RlIG11c3QgaGF2
ZSBkZWZhdWx0IHZhbHVlLA0Kb2J2aW91c2x5IGNyZWF0ZSA8YnI+DQomZ3Q7IG9wZXJhdGlvbiBj
YW4gbm90IGJlIHN1cHBvcnRlZC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7My4gSG93IHRvIHJlc29sdmUgdGhlIHByb2JsZW0gdGhhdCBhIGxlYWYgbm9kZSBj
YW4NCm5vdCBiZSA8YnI+DQomZ3Q7IGRlZmluZWQgYSBzdGF0aWMgZGVmYXVsdCB2YWx1ZSwgYnV0
IGl0IGhhcyBhIHVuY2VydGFpbiBkZWZhdWx0IHZhbHVlPGJyPg0KJmd0OyB3aGVuIGl0IGlzIGNy
ZWF0ZWQ/IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhhbXBsZTog
PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxpc3QgZm9vIHsgPGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2V5IG5hbWU7
IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmIG5hbWUgey4uLn0gPGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYgdHlwZSB7IDxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgZW51bWVy
YXRpb24geyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtDQpmb28xIHsuLi59IDxicj4NCiZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVu
dW0NCmZvbzIgey4uLn0gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7fSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfSA8
YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGVhZiB2YWx1ZSB7Li4ufSA8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0gPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiBsaXN0ICdm
b28nIGlzIGNyZWF0ZWQsIGlmIGxlYWYgbmFtZWQNCid0eXBlJydzIHZhbHVlIGlzIDxicj4NCiZn
dDsgZm9vMSwgdGhlIGRlZmF1bHQgdmFsdWUgb2YgbGVhZiBuYW1lZCAndmFsdWUnIGlzIDEwLCA8
YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaWYgbGVhZiBuYW1lZCAndHlwZScn
cyB2YWx1ZSBpcyBmb28yLCB0aGUNCmRlZmF1bHQgdmFsdWUgb2YgPGJyPg0KJmd0OyBsZWFmIG5h
bWVkICZuYnNwOyd2YWx1ZScgaXMgMjAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBzb2x1dGlv
biBpcyB0byBzcGVjaWZ5IHRoaXMgaW4gYSBkZXNjcmlwdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IFNvbHV0aW9uOiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
MS4gQWRkIHdoZW4gc3RhdGVtZW50IGFzIGRlZmF1bHQncyBzdWJzdGF0ZW1lbnQuDQo8YnI+DQom
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMi4gTGVhZiBzdXBwb3J0cyBtdWx0aSBkZWZh
dWx0IHN0YXRlbWVudC4NCjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGU6IDxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmIHZhbHVlIHsgPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVmYXVsdCAxMCB7IDxicj4N
CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgd2hlbiAmcXVvdDt0eXBlDQo9PSBmb28xJnF1b3Q7OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9IDxicj4NCiZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RlZmF1bHQgMjAgeyA8YnI+DQom
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IHdoZW4gJnF1b3Q7dHlwZQ0KPT0gZm9vMiZxdW90OzsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGludDMyOyA8YnI+DQomZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBhbSBh
Z2FpbnN0IGRvaW5nIHRoaXMuIFN1Y2ggYSB1c2Ugb2Ygoa53aGVuoa8gd291bGQgc3VmZmVyIGZy
b20NCnRoZSA8YnI+DQomZ3Q7IHNhbWUgcHJvYmxlbSBhcyBpbiBZMTggKG1pc3NpbmcgY29udGV4
dCBub2RlKSwgYW5kIGl0IGNvdWxkIGFsc28gPGJyPg0KJmd0OyBsZWFkIHRvIHJhY2UgY29uZGl0
aW9ucywgZm9yIGV4YW1wbGUgaWYgZGVmYXVsdHMgb2YgdHdvIGxlYWZzIGRlcGVuZDxicj4NCiZn
dDsgb24gZWFjaCBvdGhlci48YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+SSBkbyBrbm93IGl0LCBidXQgZHluYW1pYyBkZWZhdWx0cyBuZWVkcyB0byBi
ZSBkZWZpbmVkDQppbiBteSBwcmFjdGljZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPk5ldHdvcmsgbWFuYWdlciB3YW50cyB0byBrbm93IGl0LiBJIHRoaW5rIGEgdmFsaWQNCm1v
ZGVsIGhhdmUgbm8gcHJvYmxlbSB5b3UgbWVudGlvbmVkLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+SXQgb25seSBhZGRzIHNvbWUgZGlmZmljdWx0eSB0byBZQU5HIHBhcnNlci4g
PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE1vcmVvdmVyLCB0
aGVyZSBhcmUgb3RoZXIgd2F5cyBob3cgZHluYW1pYyBkZWZhdWx0cw0KbWF5IGJlIGRlcml2ZWQu
IDxicj4NCiZndDsgRm9yIGV4YW1wbGUsIGlmIGRlZmF1bHQtbGlmZXRpbWUgaXMgbm90IGNvbmZp
Z3VyZWQgZm9yIElQdjYgcm91dGVyDQo8YnI+DQomZ3Q7IGFkdmVydGlzZW1lbnRzLCB0aGUgdmFs
dWUgb2YgMyptYXgtcnRyLWFkdi1pbnRlcnZhbCBzaG91bGQgYmUgdXNlZA0KPGJyPg0KJmd0OyAo
b3BlcmF0aW9uYWxseSkuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5J
IGRvbid0IHVuZGVyc3RhbmQgaXQuIENhbiBZQU5HIGV4cHJlc3MgdGhpcyB1c2luZw0KZXhpc3Qg
c3ludGF4Pzxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBNYXJ0aW4sIGNhbiB0aGlzIGlzc3VlIGNhbiBiZSBhZGRlZCB0byBZQU5H
MS4xDQppc3N1ZXM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vdGUgdGhhdCB0aGUgaXNzdWUgbGlz
dCB3YXMgY2xvc2VkIG9uIE1heSA3Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBMYWRhPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgL2ZyYW5rIDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0
aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpczxi
cj4NCiZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp
cyBwcml2aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg
Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5i
c3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg
PGJyPg0KJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0
aW9uIG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3Ry
aWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsg
dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRp
YXRlbHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KJmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgbmV0
bW9kQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0Pjxmb250IHNpemU9Mj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvZm9udD48L3R0PjwvYT48
dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTGFkaXNs
YXYgTGhvdGthLCBDWi5OSUMgTGFiczxicj4NCiZndDsgUEdQIEtleSBJRDogRTc0RThDMEM8YnI+
DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0
Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy
aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBh
bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29u
ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFk
ZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRp
c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRp
b24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl
bGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K

--=_alternative 00265F9648257CD8_=--


From nobody Wed May 14 00:14:15 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0A1A0271 for <netmod@ietfa.amsl.com>; Wed, 14 May 2014 00:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.748
X-Spam-Level: *
X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_45=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ddQ_njah2x for <netmod@ietfa.amsl.com>; Wed, 14 May 2014 00:14:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F14BA1A0040 for <netmod@ietf.org>; Wed, 14 May 2014 00:14:09 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E954813F8B3; Wed, 14 May 2014 09:14:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400051642; bh=cCrf56juMkGzyWIqN8++eVZuevXbEvxckdA0fy+Mn5s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YwFdC7oqRpSU/rpeWc4UMCHegs4aRo84N2bWWxUUzKw0T89QLv6Os+yTdAf6zAKN9 oY607vtrpg6u/S5USFsk/qTeRWoUI31HaVxsBKquk9r2Imv1kjmn+X1rnPgNi8Mo87 sK85cbnjDiVdpSw7ip6cvxxUKYuAiAm8x45ypoLs=
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <OF5DE22AE9.100BC6C2-ON48257CD8.00254834-48257CD8.00265F96@zte.com.cn>
Date: Wed, 14 May 2014 09:14:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C47D83F8-ECF4-420A-9CED-7A17D36869BF@nic.cz>
References: <OF45A839A3.22EAA9F8-ON48257CD8.00069DC9-48257CD8.000922DB@zte.com.cn> <B49F128A-889B-42BA-A16B-B064EA546027@nic.cz> <OF5DE22AE9.100BC6C2-ON48257CD8.00254834-48257CD8.00265F96@zte.com.cn>
To: feng.chong33@zte.com.cn
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oC1KMn1DhyqUqwi8OjMdYTZ5Zao
Cc: ye.xu1@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] some questions about leaf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 07:14:12 -0000

On 14 May 2014, at 08:59, feng.chong33@zte.com.cn wrote:

> /frank=20
>=20
> Ladislav Lhotka <lhotka@nic.cz> =D0=B4=D3=DA 2014-05-14 14:39:13:
>=20
> > Ladislav Lhotka <lhotka@nic.cz>=20
> > 2014-05-14 14:39=20
> >=20
> > =CA=D5=BC=FE=C8=CB=20
> >=20
> > feng.chong33@zte.com.cn,=20
> >=20
> > =B3=AD=CB=CD=20
> >=20
> > netmod@ietf.org, ye.xu1@zte.com.cn=20
> >=20
> > =D6=F7=CC=E2=20
> >=20
> > Re: [netmod] some questions about leaf=20
> >=20
> >=20
> > On 14 May 2014, at 03:39, feng.chong33@zte.com.cn wrote:
> >=20
> > > Hi all,=20
> > >    I have some questions about usage of leaf.=20
> > >    1. Non-mandatory leaf must have default value? or non-mandatory
> > leaf with config true must have default value?
> >=20
> > No to both questions.
> >=20
> > > =20
> > >       for example:=20
> > >       If a list contains a optional leaf node, if this leaf node=20=

> > has no default value,=20
> > >       when a list instance is created ,what this leaf'value will =
be?
> >=20
> > It depends:
> >=20
> > - either the value doesn=A1=AFt exist (e.g. if you don=A1=AFt define =
an alias=20
> > to a user name, there is none),
> > - or the server chooses some value for *operational* use.
> >=20
> >=20
> > > =20
> > >=20
> > >    2. can leaf node support create operation?=20
> > >       If a leaf node must have default value, obviously create=20
> > operation can not be supported.=20
> > >=20
> > >    3. How to resolve the problem that a leaf node can not be=20
> > defined a static default value, but it has a uncertain default value
> > when it is created?=20
> > >       For example:=20
> > >       list foo {=20
> > >            key name;=20
> > >       leaf name {...}=20
> > >       leaf type {=20
> > >            type enumeration {=20
> > >                 enum foo1 {...}=20
> > >                 enum foo2 {...}=20
> > >            }=20
> > >       }=20
> > >       leaf value {...}=20
> > >=20
> > >       }=20
> > >=20
> > >       If list 'foo' is created, if leaf named 'type''s value is=20
> > foo1, the default value of leaf named 'value' is 10,=20
> > >       if leaf named 'type''s value is foo2, the default value of=20=

> > leaf named  'value' is 20.
> >=20
> > The solution is to specify this in a description.
> >=20
> > > =20
> > >=20
> > >       Solution:=20
> > >       1. Add when statement as default's substatement.=20
> > >       2. Leaf supports multi default statement.=20
> > >      =20
> > >       For example:=20
> > >       leaf value {=20
> > >            default 10 {=20
> > >               when "type =3D=3D foo1";=20
> > >            }=20
> > >            default 20 {=20
> > >               when "type =3D=3D foo2";=20
> > >            }=20
> > >            type int32;=20
> > >       }=20
> >=20
> > I am against doing this. Such a use of =A1=AEwhen=A1=AF would suffer =
from the=20
> > same problem as in Y18 (missing context node), and it could also=20
> > lead to race conditions, for example if defaults of two leafs depend
> > on each other.
> >=20
>=20
> I do know it, but dynamic defaults needs to be defined in my practice.=20=

> Network manager wants to know it. I think a valid model have no =
problem you mentioned.=20
> It only adds some difficulty to YANG parser.=20
>=20
> > Moreover, there are other ways how dynamic defaults may be derived.=20=

> > For example, if default-lifetime is not configured for IPv6 router=20=

> > advertisements, the value of 3*max-rtr-adv-interval should be used=20=

> > (operationally).=20
>=20
> I don't understand it. Can YANG express this using exist syntax?

No, as you can see in the module ietf-ipv6-unicast-routing, this is =
stated in that leaf=A1=AFs description. See also the description of =
'min-rtr-adv-interval=A1=AF where the procedure for choosing the default =
is even more complicated.

It is not only here that descriptions are used for specifying semantics =
of server operation, and it is intentional.

Lada=20

> >=20
> > >=20
> > >       Martin, can this issue can be added to YANG1.1 issues?
> >=20
> > Note that the issue list was closed on May 7.
> >=20
> > Lada
> >=20
> > >    =20
> > > /frank=20
> > >=20
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and=20
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure,=20
> > reproduction, distribution or other dissemination or use of the=20
> > information contained is strictly prohibited.  If you have received=20=

> > this mail in error, please delete it and notify us immediately.
> > >=20
> > >=20
> > >=20
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >=20
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >=20
> >=20
> >=20
> >=20
>=20
>=20
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this =
mail (and any attachment transmitted herewith) is privileged and =
confidential and is intended for the exclusive use of the addressee(s).  =
If you are not an intended recipient, any disclosure, reproduction, =
distribution or other dissemination or use of the information contained =
is strictly prohibited.  If you have received this mail in error, please =
delete it and notify us immediately.
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May 14 06:45:58 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0D1A00C9; Wed, 14 May 2014 06:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8jz_SxyPf_S; Wed, 14 May 2014 06:45:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1901E1A00A7; Wed, 14 May 2014 06:45:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140514134553.32093.56951.idtracker@ietfa.amsl.com>
Date: Wed, 14 May 2014 06:45:53 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/udFkgE_Qwy_fBJZpoTf_BPrJGbA
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-16.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 13:45:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : A YANG Data Model for System Management
        Authors         : Andy Bierman
                          Martin Bjorklund
	Filename        : draft-ietf-netmod-system-mgmt-16.txt
	Pages           : 41
	Date            : 2014-05-14

Abstract:
   This document defines a YANG data model for the configuration and
   identification of some common system properties within a device
   containing a NETCONF server.  This includes data node definitions for
   system identification, time-of-day management, user management, DNS
   resolver configuration, and some protocol operations for system
   management.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Wed May 14 07:30:35 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3D21A0298 for <netmod@ietfa.amsl.com>; Wed, 14 May 2014 07:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.072
X-Spam-Level: *
X-Spam-Status: No, score=1.072 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKr7-QInbyxL for <netmod@ietfa.amsl.com>; Wed, 14 May 2014 07:30:25 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4573C1A029F for <netmod@ietf.org>; Wed, 14 May 2014 07:30:20 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id r5so2898032qcx.7 for <netmod@ietf.org>; Wed, 14 May 2014 07:30:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l3tZR0OMl1Rv+uwj4li+Jr4/P0iPiB94ilA6VkCKxcY=; b=QRV4XBWEtnIeyS3yuatGApC36l4xoHTRH494AUIz5iBT+vMCSrwjErBr4U2GeRsl7r lZ2F8f/m3k+efMl6nLlEC5lRq3dQVI1zIHXiJyhBaBSOZxM4EqbhSEYuLkAUYkakpZ/S gHp4/w5oTZTOE0eFjhXRczrxhYwcRwiqq/hxcO/eIRnwAIxxQZfqZIpKktdSBbgu/7iJ E5lugzqimpGpykdPfoLLkfKPzCkZK6BzOGCz6M1azSmWg+N+AoOzE4PCyYyuTSm/e4IX C0APtEHg0vpw1QZIONuRKl4ffnW6ILgqH/JupjKBw/AazVLmTriCcN6NSJAR8rfnNlaH E81A==
X-Gm-Message-State: ALoCoQmzLPn01m1Yjj7yZ+xwkBd2LJua5j44O45y2Oy3P/vpmpNJuK6MKgZAInkaebKY8b6/6lnk
MIME-Version: 1.0
X-Received: by 10.140.27.245 with SMTP id 108mr6247769qgx.18.1400077813324; Wed, 14 May 2014 07:30:13 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 14 May 2014 07:30:13 -0700 (PDT)
In-Reply-To: <C47D83F8-ECF4-420A-9CED-7A17D36869BF@nic.cz>
References: <OF45A839A3.22EAA9F8-ON48257CD8.00069DC9-48257CD8.000922DB@zte.com.cn> <B49F128A-889B-42BA-A16B-B064EA546027@nic.cz> <OF5DE22AE9.100BC6C2-ON48257CD8.00254834-48257CD8.00265F96@zte.com.cn> <C47D83F8-ECF4-420A-9CED-7A17D36869BF@nic.cz>
Date: Wed, 14 May 2014 07:30:13 -0700
Message-ID: <CABCOCHSgLiA4rPxbTwtfWrmSJCuhh3VX42Ve=V_BnVJ1QsrFUw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c15260b8b25604f95d04ea
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QVzFw6ydOxix1A8h41qtwb3i-xU
Cc: ye.xu1@zte.com.cn, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] some questions about leaf
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 14:30:33 -0000

--001a11c15260b8b25604f95d04ea
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2014 at 12:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 14 May 2014, at 08:59, feng.chong33@zte.com.cn wrote:
>
> > /frank
> >
> > Ladislav Lhotka <lhotka@nic.cz> =D0=B4=D3=DA 2014-05-14 14:39:13:
> >
> > > Ladislav Lhotka <lhotka@nic.cz>
> > > 2014-05-14 14:39
> > >
> > > =CA=D5=BC=FE=C8=CB
> > >
> > > feng.chong33@zte.com.cn,
> > >
> > > =B3=AD=CB=CD
> > >
> > > netmod@ietf.org, ye.xu1@zte.com.cn
> > >
> > > =D6=F7=CC=E2
> > >
> > > Re: [netmod] some questions about leaf
> > >
> > >
> > > On 14 May 2014, at 03:39, feng.chong33@zte.com.cn wrote:
> > >
> > > > Hi all,
> > > >    I have some questions about usage of leaf.
> > > >    1. Non-mandatory leaf must have default value? or non-mandatory
> > > leaf with config true must have default value?
> > >
> > > No to both questions.
> > >
> > > >
> > > >       for example:
> > > >       If a list contains a optional leaf node, if this leaf node
> > > has no default value,
> > > >       when a list instance is created ,what this leaf'value will be=
?
> > >
> > > It depends:
> > >
> > > - either the value doesn=A1=AFt exist (e.g. if you don=A1=AFt define =
an alias
> > > to a user name, there is none),
> > > - or the server chooses some value for *operational* use.
> > >
> > >
> > > >
> > > >
> > > >    2. can leaf node support create operation?
> > > >       If a leaf node must have default value, obviously create
> > > operation can not be supported.
> > > >
> > > >    3. How to resolve the problem that a leaf node can not be
> > > defined a static default value, but it has a uncertain default value
> > > when it is created?
> > > >       For example:
> > > >       list foo {
> > > >            key name;
> > > >       leaf name {...}
> > > >       leaf type {
> > > >            type enumeration {
> > > >                 enum foo1 {...}
> > > >                 enum foo2 {...}
> > > >            }
> > > >       }
> > > >       leaf value {...}
> > > >
> > > >       }
> > > >
> > > >       If list 'foo' is created, if leaf named 'type''s value is
> > > foo1, the default value of leaf named 'value' is 10,
> > > >       if leaf named 'type''s value is foo2, the default value of
> > > leaf named  'value' is 20.
> > >
> > > The solution is to specify this in a description.
> > >
> > > >
> > > >
> > > >       Solution:
> > > >       1. Add when statement as default's substatement.
> > > >       2. Leaf supports multi default statement.
> > > >
> > > >       For example:
> > > >       leaf value {
> > > >            default 10 {
> > > >               when "type =3D=3D foo1";
> > > >            }
> > > >            default 20 {
> > > >               when "type =3D=3D foo2";
> > > >            }
> > > >            type int32;
> > > >       }
> > >
> > > I am against doing this. Such a use of =A1=AEwhen=A1=AF would suffer =
from the
> > > same problem as in Y18 (missing context node), and it could also
> > > lead to race conditions, for example if defaults of two leafs depend
> > > on each other.
> > >
> >
> > I do know it, but dynamic defaults needs to be defined in my practice.
> > Network manager wants to know it. I think a valid model have no problem
> you mentioned.
> > It only adds some difficulty to YANG parser.
>


There is a difference between a default value that is
dynamically selected by the server, and a dynamic default
that keeps changing, based on evaluation of arbitrary when-stmts.
Perhaps the intent here is to evaluate the when-stmts only once?

What happens if when-stmts overlap and multiple true conditions exist?
What happens if the when-stmts from different leafs affect
each other, preventing both leafs from setting a stable default?

The description-stmt is good enough for complex defaults.
If the NMS developer cares enough they can read the YANG module.
The point of defaults are to allow the server to pick reasonable
initial values so the client can ignore those nodes.


>
> > > Moreover, there are other ways how dynamic defaults may be derived.
> > > For example, if default-lifetime is not configured for IPv6 router
> > > advertisements, the value of 3*max-rtr-adv-interval should be used
> > > (operationally).
> >
> > I don't understand it. Can YANG express this using exist syntax?
>
> No, as you can see in the module ietf-ipv6-unicast-routing, this is state=
d
> in that leaf=A1=AFs description. See also the description of
> 'min-rtr-adv-interval=A1=AF where the procedure for choosing the default =
is even
> more complicated.
>
> It is not only here that descriptions are used for specifying semantics o=
f
> server operation, and it is intentional.
>
> Lada
>


Andy


>
> > >
> > > >
> > > >       Martin, can this issue can be added to YANG1.1 issues?
> > >
> > > Note that the issue list was closed on May 7.
> > >
> > > Lada
> > >
> > > >
> > > > /frank
> > > >
> > > > --------------------------------------------------------
> > > > ZTE Information Security Notice: The information contained in this
> > > mail (and any attachment transmitted herewith) is privileged and
> > > confidential and is intended for the exclusive use of the addressee
> > > (s).  If you are not an intended recipient, any disclosure,
> > > reproduction, distribution or other dissemination or use of the
> > > information contained is strictly prohibited.  If you have received
> > > this mail in error, please delete it and notify us immediately.
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> >
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential
> and is intended for the exclusive use of the addressee(s).  If you are no=
t
> an intended recipient, any disclosure, reproduction, distribution or othe=
r
> dissemination or use of the information contained is strictly prohibited.
>  If you have received this mail in error, please delete it and notify us
> immediately.
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a11c15260b8b25604f95d04ea
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, May 14, 2014 at 12:14 AM, Ladislav Lhotka <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 14 May 2014, at 08:59, <a href=3D"mailto:feng.chong33@zte.com.cn">feng.c=
hong33@zte.com.cn</a> wrote:<br>
<br>
&gt; /frank<br>
&gt;<br>
&gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.cz</a>=
&gt; =D0=B4=D3=DA 2014-05-14 14:39:13:<br>
&gt;<br>
&gt; &gt; Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lhotka@nic.c=
z</a>&gt;<br>
&gt; &gt; 2014-05-14 14:39<br>
&gt; &gt;<br>
&gt; &gt; =CA=D5=BC=FE=C8=CB<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.c=
n</a>,<br>
&gt; &gt;<br>
&gt; &gt; =B3=AD=CB=CD<br>
&gt; &gt;<br>
&gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a>, <a href=
=3D"mailto:ye.xu1@zte.com.cn">ye.xu1@zte.com.cn</a><br>
&gt; &gt;<br>
&gt; &gt; =D6=F7=CC=E2<br>
&gt; &gt;<br>
&gt; &gt; Re: [netmod] some questions about leaf<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On 14 May 2014, at 03:39, <a href=3D"mailto:feng.chong33@zte.com.=
cn">feng.chong33@zte.com.cn</a> wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt; &nbsp; &nbsp;I have some questions about usage of leaf.<br>
&gt; &gt; &gt; &nbsp; &nbsp;1. Non-mandatory leaf must have default value? =
or non-mandatory<br>
&gt; &gt; leaf with config true must have default value?<br>
&gt; &gt;<br>
&gt; &gt; No to both questions.<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; for example:<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; If a list contains a optional leaf node=
, if this leaf node<br>
&gt; &gt; has no default value,<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; when a list instance is created ,what t=
his leaf&#39;value will be?<br>
&gt; &gt;<br>
&gt; &gt; It depends:<br>
&gt; &gt;<br>
&gt; &gt; - either the value doesn&rsquo;t exist (e.g. if you don&rsquo;t d=
efine an alias<br>
&gt; &gt; to a user name, there is none),<br>
&gt; &gt; - or the server chooses some value for *operational* use.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp;2. can leaf node support create operation?<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; If a leaf node must have default value,=
 obviously create<br>
&gt; &gt; operation can not be supported.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp;3. How to resolve the problem that a leaf node =
can not be<br>
&gt; &gt; defined a static default value, but it has a uncertain default va=
lue<br>
&gt; &gt; when it is created?<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; For example:<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; list foo {<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;key name;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; leaf name {...}<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; leaf type {<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;type enumeration {<=
br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; enum=
 foo1 {...}<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; enum=
 foo2 {...}<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; }<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; leaf value {...}<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; }<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; If list &#39;foo&#39; is created, if le=
af named &#39;type&#39;&#39;s value is<br>
&gt; &gt; foo1, the default value of leaf named &#39;value&#39; is 10,<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; if leaf named &#39;type&#39;&#39;s valu=
e is foo2, the default value of<br>
&gt; &gt; leaf named &nbsp;&#39;value&#39; is 20.<br>
&gt; &gt;<br>
&gt; &gt; The solution is to specify this in a description.<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; Solution:<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; 1. Add when statement as default&#39;s =
substatement.<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; 2. Leaf supports multi default statemen=
t.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; For example:<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; leaf value {<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;default 10 {<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; when &quot;=
type =3D=3D foo1&quot;;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;default 20 {<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; when &quot;=
type =3D=3D foo2&quot;;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;type int32;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; }<br>
&gt; &gt;<br>
&gt; &gt; I am against doing this. Such a use of &lsquo;when&rsquo; would s=
uffer from the<br>
&gt; &gt; same problem as in Y18 (missing context node), and it could also<=
br>
&gt; &gt; lead to race conditions, for example if defaults of two leafs dep=
end<br>
&gt; &gt; on each other.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I do know it, but dynamic defaults needs to be defined in my practice.=
<br>
&gt; Network manager wants to know it. I think a valid model have no proble=
m you mentioned.<br>
&gt; It only adds some difficulty to YANG parser.<br></blockquote><div><br>=
</div><div><br></div><div>There is a difference between a default value tha=
t is</div><div>dynamically selected by the server, and a dynamic default</d=
iv>
<div>that keeps changing, based on evaluation of arbitrary when-stmts.</div=
><div>Perhaps the intent here is to evaluate the when-stmts only once?</div=
><div><br></div><div>What happens if when-stmts overlap and multiple true c=
onditions exist?</div>
<div>What happens if the when-stmts from different leafs affect</div><div>e=
ach other, preventing both leafs from setting a stable default?</div><div><=
br></div><div>The description-stmt is good enough for complex defaults.</di=
v>
<div>If the NMS developer cares enough they can read the YANG module.</div>=
<div>The point of defaults are to allow the server to pick reasonable</div>=
<div>initial values so the client can ignore those nodes.</div><div><br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;<br>
&gt; &gt; Moreover, there are other ways how dynamic defaults may be derive=
d.<br>
&gt; &gt; For example, if default-lifetime is not configured for IPv6 route=
r<br>
&gt; &gt; advertisements, the value of 3*max-rtr-adv-interval should be use=
d<br>
&gt; &gt; (operationally).<br>
&gt;<br>
&gt; I don&#39;t understand it. Can YANG express this using exist syntax?<b=
r>
<br>
No, as you can see in the module ietf-ipv6-unicast-routing, this is stated =
in that leaf&rsquo;s description. See also the description of &#39;min-rtr-=
adv-interval&rsquo; where the procedure for choosing the default is even mo=
re complicated.<br>

<br>
It is not only here that descriptions are used for specifying semantics of =
server operation, and it is intentional.<br>
<br>
Lada<br></blockquote><div><br></div><div><br></div><div>Andy</div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; Martin, can this issue can be added to =
YANG1.1 issues?<br>
&gt; &gt;<br>
&gt; &gt; Note that the issue list was closed on May 7.<br>
&gt; &gt;<br>
&gt; &gt; Lada<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; /frank<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --------------------------------------------------------<br>
&gt; &gt; &gt; ZTE Information Security Notice: The information contained i=
n this<br>
&gt; &gt; mail (and any attachment transmitted herewith) is privileged and<=
br>
&gt; &gt; confidential and is intended for the exclusive use of the address=
ee<br>
&gt; &gt; (s). &nbsp;If you are not an intended recipient, any disclosure,<=
br>
&gt; &gt; reproduction, distribution or other dissemination or use of the<b=
r>
&gt; &gt; information contained is strictly prohibited. &nbsp;If you have r=
eceived<br>
&gt; &gt; this mail in error, please delete it and notify us immediately.<b=
r>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; netmod mailing list<br>
&gt; &gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; &gt; PGP Key ID: E74E8C0C<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt; --------------------------------------------------------<br>
&gt; ZTE Information Security Notice: The information contained in this mai=
l (and any attachment transmitted herewith) is privileged and confidential =
and is intended for the exclusive use of the addressee(s). &nbsp;If you are=
 not an intended recipient, any disclosure, reproduction, distribution or o=
ther dissemination or use of the information contained is strictly prohibit=
ed. &nbsp;If you have received this mail in error, please delete it and not=
ify us immediately.<br>

&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
netmod mailing list<br>
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/netmod</a><br>
</blockquote></div><br></div></div>

--001a11c15260b8b25604f95d04ea--


From nobody Wed May 14 14:31:06 2014
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFC91A01F0; Wed, 14 May 2014 14:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level: 
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ2u-uYWDmqD; Wed, 14 May 2014 14:30:55 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B523C1A02D7; Wed, 14 May 2014 14:30:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D1A3118000E; Wed, 14 May 2014 14:29:49 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20140514212949.D1A3118000E@rfc-editor.org>
Date: Wed, 14 May 2014 14:29:49 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bHEf7SOKv6t_ovmosXI0c1A4bJc
Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] RFC 7223 on A YANG Data Model for Interface Management
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 21:31:00 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7223

        Title:      A YANG Data Model for Interface Management 
        Author:     M. Bjorklund
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2014
        Mailbox:    mbj@tail-f.com
        Pages:      39
        Characters: 70537
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netmod-interfaces-cfg-16.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7223.txt

This document defines a YANG data model for the management of network
interfaces.  It is expected that interface-type-specific data models
augment the generic interfaces data model defined in this document.
The data model includes configuration data and state data (status
information and counters for the collection of statistics).

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed May 14 14:31:24 2014
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F871A02EF; Wed, 14 May 2014 14:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.853
X-Spam-Level: 
X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ6ofZcJk_Ao; Wed, 14 May 2014 14:31:11 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5071A02D8; Wed, 14 May 2014 14:31:09 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id AC4461801C1; Wed, 14 May 2014 14:30:04 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20140514213005.AC4461801C1@rfc-editor.org>
Date: Wed, 14 May 2014 14:30:04 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ELXZJHahSUxsJijWQM00CtM-4to
Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] RFC 7224 on IANA Interface Type YANG Module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 May 2014 21:31:15 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7224

        Title:      IANA Interface Type YANG Module 
        Author:     M. Bjorklund
        Status:     Standards Track
        Stream:     IETF
        Date:       May 2014
        Mailbox:    mbj@tail-f.com
        Pages:      37
        Characters: 51377
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netmod-iana-if-type-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7224.txt

This document defines the initial version of the iana-if-type YANG
module.

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Thu May 15 13:34:03 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A661A02F3 for <netmod@ietfa.amsl.com>; Thu, 15 May 2014 13:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level: 
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMe1y9-iTxon for <netmod@ietfa.amsl.com>; Thu, 15 May 2014 13:34:00 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB491A0158 for <netmod@ietf.org>; Thu, 15 May 2014 13:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=190; q=dns/txt; s=iport; t=1400186032; x=1401395632; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=CDThp52j4o6di4ZBuyCLBk7ohkyT1arXzlmgfuv7xf4=; b=GI4oELXe9hHpou23ScernMFgxFfxSew7iIsvZx+ep+gncDrfR/5LKOF3 BWUOA6/d5LXTPq7JZxTXuLvEqHvkzSxUuXxbHOd+wU7/VfQjJfsVvhq3F GcRnGbvi+g2I4iJ8DT5xGmU1ha2X7ta8FZSrWq+0iXfnLH+MBt5FA3B/p 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAE8kdVOtJV2Q/2dsb2JhbABZgwaOIbgbgR0WdIJkQD0WGAMCAQIBSw0IAQGIPZ1AtAYXi0CHVQEDihGPQIZpjCuDVh0
X-IronPort-AV: E=Sophos;i="4.97,1061,1389744000"; d="scan'208";a="44218234"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 15 May 2014 20:33:43 +0000
Received: from [10.154.205.23] ([10.154.205.23]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4FKXhhp031447 for <netmod@ietf.org>; Thu, 15 May 2014 20:33:43 GMT
Message-ID: <537524A7.5050606@cisco.com>
Date: Thu, 15 May 2014 13:33:43 -0700
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: NETMOD Working Group <netmod@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LSsrmhkQNf1oJ08a00xzocnmwRA
Subject: [netmod] RFC 7223  and RFC 7224
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 May 2014 20:34:01 -0000

Congrats to all people involved with those 2 RFCs.

Now that we have some more experience in producing YANG modules, the 
subsequent ones must be produced way faster.

Regards, Benoit


From nobody Fri May 16 01:07:14 2014
Return-Path: <jonathan@hansfords.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12101A01B3 for <netmod@ietfa.amsl.com>; Fri, 16 May 2014 01:07:05 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY16iA5AKj1e for <netmod@ietfa.amsl.com>; Fri, 16 May 2014 01:07:03 -0700 (PDT)
Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5B1A01C6 for <netmod@ietf.org>; Fri, 16 May 2014 01:06:40 -0700 (PDT)
Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id 2Y6Y1o0071SbfYc01Y6Yos; Fri, 16 May 2014 09:06:32 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=NYlo1gz4 c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=AsJUcncBzMYizbaB0C6/RA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=H_mcGaXuBgkA:10 a=0B8HqoTn75oA:10 a=EUbft__QjbsA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=48vgC7mUAAAA:8 a=gbqPyTJVlY7hRQSPEsQA:9 a=QEXdDO2ut3YA:10 a=HgiqoaA2JdkA:10 a=rKrVYePj7rwA:10 a=lZB815dzVvQA:10 a=2Bau_6ZBQ__3W7J56ZsA:9 a=_W_S_7VecoQA:10
X-AUTH: hansfords+us:2500
Received: from host-92-19-235-91.static.as13285.net ([92.19.235.91]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 16 May 2014 09:06:32 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_6a5984c4554ccdc3601731d5288d3489"
Date: Fri, 16 May 2014 09:06:32 +0100
From: Jonathan Hansford <Jonathan@hansfords.net>
To: Benoit Claise <bclaise@cisco.com>
In-Reply-To: <5372944D.5010509@cisco.com>
References: <5372944D.5010509@cisco.com>
Message-ID: <6794186211ba862d0012e8da82b25d66@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [92.19.235.91]
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VHQEcJ1vD8qq1uRgATzw5DhvgW8
Cc: Netmod <netmod@ietf.org>
Subject: Re: [netmod] YANG Advice and Editing Session at the next IETF meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 May 2014 08:07:06 -0000

--=_6a5984c4554ccdc3601731d5288d3489
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=UTF-8

 

Benoit, 

Would it be worth capturing the sorts of issues that are
identified together with guidance on how to address them? As someone who
to date has only played at YANG module construction it would be useful
to have more guidance on the DOs, DON'Ts and general good practice.


Jonathan 

On 2014-05-13 22:53, Benoit Claise wrote: 

> [Sorry for
the potential cross-posting]
> 
>
http://www.ietf.org/meeting/90/tutorials/yang-session.html
> Let me
stress that this should be an interactive session, and not a 
>
tutorial.
> So come with your (plan to create) YANG modules.
> 
>
Regards, Benoit
> 
> _______________________________________________
>
netmod mailing list
> netmod@ietf.org
>
https://www.ietf.org/mailman/listinfo/netmod
 
--=_6a5984c4554ccdc3601731d5288d3489
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body>
<p>Benoit,</p>
<p>Would it be worth capturing the sorts of issues that are identified toge=
ther with guidance on how to address them? As someone who to date has only =
played at YANG module construction it would be useful to have more guidance=
 on the DOs, DON'Ts and general good practice.</p>
<p>Jonathan</p>
<p>On 2014-05-13 22:53, Benoit Claise wrote:</p>
<blockquote type=3D"cite" style=3D"padding-left:5px; border-left:#1010ff 2p=
x solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignore=
d --><!-- meta ignored -->
<pre>[Sorry for the potential cross-posting]

<a href=3D"http://www.ietf.org/meeting/90/tutorials/yang-session.html">http=
://www.ietf.org/meeting/90/tutorials/yang-session.html</a>
Let me stress that this should be an interactive session, and not a=20
tutorial.
So come with your (plan to create) YANG modules.

Regards, Benoit

_______________________________________________
netmod mailing list
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf=
=2Eorg/mailman/listinfo/netmod</a>
</pre>
</blockquote>
</body></html>

--=_6a5984c4554ccdc3601731d5288d3489--


From nobody Fri May 16 01:07:26 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437E81A01B3 for <netmod@ietfa.amsl.com>; Fri, 16 May 2014 01:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYIhb81_ogLJ for <netmod@ietfa.amsl.com>; Fri, 16 May 2014 01:07:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9AA1A01C9 for <netmod@ietf.org>; Fri, 16 May 2014 01:06:41 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0FC1E13F630; Fri, 16 May 2014 10:06:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400227591; bh=RrZOjymdu/VD30LNfx5a6kwFIZNeHBklfgw584E7VuQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XApOK712K1YfBJQwFZLWZ4T8+KRMdbGabmJsEjRsZPdxCqmdguHvdH3LXr8QJ0mh1 2r274Yh2yaKPSDtLsLJaqpijGiDGy97wAnMRpC3/wfLJQPrT3JBzNE32ZQR0rQ4xqk 2nDWn2d5uhXjv89B7ra8SsC4DjGTgSgbQuy4itwE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <537524A7.5050606@cisco.com>
Date: Fri, 16 May 2014 10:06:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F87E6444-1B9B-48B8-9AFA-DF9AF13AD77E@nic.cz>
References: <537524A7.5050606@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IuQ6vTMfUVqdsejzLQTg9knQbrg
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] RFC 7223  and RFC 7224
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 May 2014 08:07:12 -0000

On 15 May 2014, at 22:33, Benoit Claise <bclaise@cisco.com> wrote:

> Congrats to all people involved with those 2 RFCs.
>=20
> Now that we have some more experience in producing YANG modules, the =
subsequent ones must be produced way faster.

Hopefully they will. What will be the next steps with the other pending =
documents?

Thanks, Lada

>=20
> Regards, Benoit
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May 19 07:18:06 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7891A038A; Mon, 19 May 2014 07:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-RDWnsK56FW; Mon, 19 May 2014 07:18:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D32161A035A; Mon, 19 May 2014 07:18:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140519141801.1703.68879.idtracker@ietfa.amsl.com>
Date: Mon, 19 May 2014 07:18:01 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3h4PwBwx0qSF9MGF38drvoulZ-4
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 14:18:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : A YANG Data Model for SNMP Configuration
        Authors         : Martin Bjorklund
                          Juergen Schoenwaelder
	Filename        : draft-ietf-netmod-snmp-cfg-05.txt
	Pages           : 86
	Date            : 2014-05-19

Abstract:
   This document defines a collection of YANG definitions for
   configuring SNMP engines.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Mon May 19 08:49:09 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493D21A01A6 for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 08:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzhAeOJ9HwDC for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 08:49:04 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A79E1A016E for <netmod@ietf.org>; Mon, 19 May 2014 08:49:02 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6F7C1633; Mon, 19 May 2014 17:49:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8iFpw7aGaaoB; Mon, 19 May 2014 17:49:00 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 May 2014 17:49:00 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFAAE20017; Mon, 19 May 2014 17:49:00 +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 F9rMsrvMtmXu; Mon, 19 May 2014 17:49:00 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7BAAB20013; Mon, 19 May 2014 17:48:59 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id CADE52CE96BA; Mon, 19 May 2014 17:48:58 +0200 (CEST)
Date: Mon, 19 May 2014 17:48:58 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140519154858.GA80033@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Benoit Claise <bclaise@cisco.com>, NETMOD Working Group <netmod@ietf.org>
References: <537524A7.5050606@cisco.com> <F87E6444-1B9B-48B8-9AFA-DF9AF13AD77E@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F87E6444-1B9B-48B8-9AFA-DF9AF13AD77E@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nVME742xjGJOFs2XhZcVTLXAQU8
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] RFC 7223  and RFC 7224
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 15:49:07 -0000

On Fri, May 16, 2014 at 10:06:30AM +0200, Ladislav Lhotka wrote:
> 
> On 15 May 2014, at 22:33, Benoit Claise <bclaise@cisco.com> wrote:
> 
> > Congrats to all people involved with those 2 RFCs.
> > 
> > Now that we have some more experience in producing YANG modules, the subsequent ones must be produced way faster.
> 
> Hopefully they will. What will be the next steps with the other pending documents?
> 

Here is a summary of where I think we are regarding the 'old'
documents (from our previous charter):

- draft-ietf-netmod-ip-cfg: RFC Editor Queue

- draft-ietf-netmod-system-mgmt: Waiting for AD Go Ahead

  I think the last version (-16) clears all IESG discusses (and there
  were quite a few I would say); hopefully this I-D moves relatively
  soon into the RFC Editor Queue.

- draft-ietf-netmod-snmp-cfg: AD Evaluation

  Martin just posted a new revision that clears all edits the editors
  had pending (essentially making the transport endpoint construction
  extensible with transport specific parameters). Once Benoit is done
  with his review, the document should go to IETF last call and then
  through the IESG process.

- draft-ietf-netmod-routing-cfg: Waiting for WG Chair Go-Ahead 

  This document has been waiting for me (way too long - I have to
  apologize) for producing the writeup that is needed to request
  publication from the IESG. I have done my homework now and I found a
  couple of mostly editorial nits that I think should be fixed before
  we send this document to the IESG. I will send a separate message
  and ask Lada to address the nits. Once done, I send this over to the
  IESG.

/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 nobody Mon May 19 09:20:39 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B371A039F for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 09:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCvvSnFt5V2b for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 09:20:28 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8EA1A01D5 for <netmod@ietf.org>; Mon, 19 May 2014 09:20:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 79A34F66; Mon, 19 May 2014 18:20:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YVUrvmea2H23; Mon, 19 May 2014 18:20:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 May 2014 18:20:26 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7273220013; Mon, 19 May 2014 18:20: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 5-e2vppLU-qx; Mon, 19 May 2014 18:20:25 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD9C320017; Mon, 19 May 2014 18:20:24 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id D0ABB2CE97A6; Mon, 19 May 2014 18:20:23 +0200 (CEST)
Date: Mon, 19 May 2014 18:20:23 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BNbRfww9cwyTNnj6BS3aCWuObuA
Cc: netmod@ietf.org
Subject: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 16:20:37 -0000

Lada,

while producing the writeup, I re-read the I-D and found a couple of
nits that I propose to fix before we send the document forward.  Most
of them are rather trivial but I think it is best we fix them now so
that we do not have to track them.

/js

a) The three modules do not compile cleanly with pyang 1.3 using the
   --ietf option because of missing description statements:

   ietf-routing: container next-hop-list is missing a description
                substatement

  ietf-ipv4-unicast-routing: container next-hop-list is missing a
                             description substatement

  ietf-ipv6-unicast-routing: container next-hop-list is missing a
                             description substatement

b) OLD

      (read-write) and "ro" means state data (read-only).

   NEW

      (read-write), and "ro" means state data (read-only).

   The RFC editor prefers a comma before and.

c) Page 21 second bullet lists some paths and the text talks about
   state data. I think the paths are incorrect and should point into
   the /rt:routing-state subtree.

d) In all three modules, replace David Kessens with Tom Nadeau as
   co-chair.

e) In all three modules, change the copyright year to 2014.

f) The leaf cur-hop-limit in the state tree has a default statement
   and also this sentence:

              The default SHOULD be set to the value specified in IANA
              Assigned Numbers that was in effect at the time of
              implementation.

   First, a default in the state tree is not really that useful.  This
   text seems to imply that there should be no default at all since
   the value can change. I think this SHOULD text should also be moved
   to the corresponding object in the configuration subtree.

g) The leaf default-lifetime in the state tree has this text:

              If this parameter is not configured, a value of 3 *
              max-rtr-adv-interval SHOULD be used.

   This text seems more appropriate for the corresponding
   configuration leaf and should perhaps be moved there.

h) There is this text in the description of ipv6-router-advertisements
   in the configuration subtree:

            See the corresponding parameters under /rt:routing-state for
            detailed descriptions and references.

   Perhaps it is easier to move the few sentence that are specific for
   the configuration objects right into the configuration object's
   description clauses (and then to remove this sentence)?

i) Please replace [YANG-IF] with [RFC7223] and update the references.

j) I did compile the example-rip module. Of course, it is and example
   and not intended to be complete. But perhaps it makes sense to add
   the missing description clauses just to make sure people always see
   descriptions clauses in RFCs (and perhaps add a comment that the
   statements for module meta information has been left out for
   brevity).

k) Have you validated the example instance document in appendix D
   against the YANG modules?

l) In the security considerations, add a sentence at the end of the
   first paragraph that points to the access control model. See
   Section 7 in RFC 7223 as an example. You also need to add an
   informative reference to RFC 6536 which this sentence refers to.

m) In the security considerations, I suggest to place a color ':'
   after the path:

   OLD

   /routing/routing-instance/interfaces/interface  This list assigns a
      network layer interface to a routing instance and may also specify
      interface parameters related to routing.

   /routing/routing-instance/routing-protocols/routing-protocol  This
      list specifies the routing protocols configured on a device.

   /routing/route-filters/route-filter  This list specifies the
      configured route filters which represent administrative policies
      for redistributing and modifying routing information.

   /routing/ribs/rib  This list specifies the RIBs configured for the
      device.

   NEW

   /routing/routing-instance/interfaces/interface:  This list assigns a
      network layer interface to a routing instance and may also specify
      interface parameters related to routing.

   /routing/routing-instance/routing-protocols/routing-protocol:  This
      list specifies the routing protocols configured on a device.

   /routing/route-filters/route-filter:  This list specifies the
      configured route filters which represent administrative policies
      for redistributing and modifying routing information.

   /routing/ribs/rib:  This list specifies the RIBs configured for the
      device.

/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 nobody Mon May 19 12:11:48 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A081A022A for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 12:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjldCBCpc4oa for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 12:11:40 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5061A03C8 for <netmod@ietf.org>; Mon, 19 May 2014 12:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2098; q=dns/txt; s=iport; t=1400526685; x=1401736285; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=PIfyQ6wIx8940SGUL44J6bEMDj2JzrTspGP3KKaVqaE=; b=gk31+zEb0wnrY7oXJ1tcTO3BUbUUBpMB8FUY9ATuuCTomxet/Yl5k1rq KyYjEcEhRELxISXKCM1FKX8HYaaA84hlZZbly0BNn1wZCvvU/gpfnFWFF nrF9cn5m9W6EkzUCIIWsbUc71M4tOUM45HL+41SGovyoFJ0rg9x+Co+Op Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmoFAAdXelOtJV2Z/2dsb2JhbABZgwZRxGEBgRkWdIIlAQEBBDhRCxgJJQ8CRgYBDAYCAQGIPQ3SNheLQoMVhEAEihWPRYE9hS2MMINXHQ
X-IronPort-AV: E=Sophos;i="4.98,868,1392163200"; d="scan'208";a="45226407"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 19 May 2014 19:11:25 +0000
Received: from [10.21.116.235] (sjc-vpn2-1259.cisco.com [10.21.116.235]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4JJBOOQ029532; Mon, 19 May 2014 19:11:24 GMT
Message-ID: <537A575C.602@cisco.com>
Date: Mon, 19 May 2014 12:11:24 -0700
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@nic.cz>, NETMOD Working Group <netmod@ietf.org>
References: <537524A7.5050606@cisco.com> <F87E6444-1B9B-48B8-9AFA-DF9AF13AD77E@nic.cz> <20140519154858.GA80033@elstar.jacobs.jacobs-university.de>
In-Reply-To: <20140519154858.GA80033@elstar.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/knB9GXg5MFWJjX7b0XSKHjfBTxI
Subject: Re: [netmod] RFC 7223  and RFC 7224
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 19:11:44 -0000

On 19/05/2014 08:48, Juergen Schoenwaelder wrote:
> On Fri, May 16, 2014 at 10:06:30AM +0200, Ladislav Lhotka wrote:
>> On 15 May 2014, at 22:33, Benoit Claise <bclaise@cisco.com> wrote:
>>
>>> Congrats to all people involved with those 2 RFCs.
>>>
>>> Now that we have some more experience in producing YANG modules, the subsequent ones must be produced way faster.
>> Hopefully they will. What will be the next steps with the other pending documents?
>>
> Here is a summary of where I think we are regarding the 'old'
> documents (from our previous charter):
>
> - draft-ietf-netmod-ip-cfg: RFC Editor Queue
Correct.
>
> - draft-ietf-netmod-system-mgmt: Waiting for AD Go Ahead
>
>    I think the last version (-16) clears all IESG discusses (and there
>    were quite a few I would say); hopefully this I-D moves relatively
>    soon into the RFC Editor Queue.
After the second IETF LC, this document returned on the 2014-05-29 IESG 
Telechat
I don't foresee much problem, as the DISCUSSES have been taken care of.
See http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ballot/


>
> - draft-ietf-netmod-snmp-cfg: AD Evaluation
>
>    Martin just posted a new revision that clears all edits the editors
>    had pending (essentially making the transport endpoint construction
>    extensible with transport specific parameters). Once Benoit is done
>    with his review, the document should go to IETF last call and then
>    through the IESG process.
Yes, I need to review the new posted version.

Regards, Benoit
>
> - draft-ietf-netmod-routing-cfg: Waiting for WG Chair Go-Ahead
>
>    This document has been waiting for me (way too long - I have to
>    apologize) for producing the writeup that is needed to request
>    publication from the IESG. I have done my homework now and I found a
>    couple of mostly editorial nits that I think should be fixed before
>    we send this document to the IESG. I will send a separate message
>    and ask Lada to address the nits. Once done, I send this over to the
>    IESG.
>
> /js
>


From nobody Mon May 19 13:18:12 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CB41A0129 for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 13:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCA1izQ33uRV for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 13:18:04 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E601A0176 for <netmod@ietf.org>; Mon, 19 May 2014 13:18:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA2ADFDA for <netmod@ietf.org>; Mon, 19 May 2014 22:18:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 30kgmTMoRABN for <netmod@ietf.org>; Mon, 19 May 2014 22:18:02 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Mon, 19 May 2014 22:18:02 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27E6C20017 for <netmod@ietf.org>; Mon, 19 May 2014 22:18:02 +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 ydyo3k2De49h; Mon, 19 May 2014 22:18:01 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D90120013; Mon, 19 May 2014 22:18:01 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 7420F2CE9D67; Mon, 19 May 2014 22:18:00 +0200 (CEST)
Date: Mon, 19 May 2014 22:18:00 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20140519201800.GB81067@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yHeCxFUUon6zDu4BFbg1nqykOrM
Subject: [netmod] yang 1.1 status and next steps
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 20:18:09 -0000

Hi,

the WG has collected a number of issued to consider for YANG 1.1. The
result can be found here:

      http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

The deadline for submitting issues was 2014-05-07. It seems one issue
got submitted past the deadline and one issue that came up during the
discussions was not included in the issues list. We plan to include
these two issues but otherwise the issue list is closed now.

Currently, all issues are marked as NEW. The WG now has to decide
which issues are in scope of the YANG 1.1 effort (moving them to OPEN)
and which ones are not in scope (moving them to DEAD). To kickoff this
selection process, the WG chairs, with the help of some core
contributors (namely Martin, Andy, Lada), have produced a strawman
proposal that we will distribute in subsequent messages. The goal is
to determine on which issues the WG supports the strawman proposal.
Note that some issues were left undecided because we could not come up
with a strawman (either because there are simply different opinions or
there is a lack of understanding of the issue).

Once we have selected the OPEN issues, we will have to iterate over
them with the goal to find agreement on solutions that address the
issue. In order to do that, we plan to hold weekly conference calls on
Wednesdays 16:00-18:00 CEST, starting from June 4th. Benoit is
supporting us by providing WebEx for these virtual meetings. We will
send out further details about the calls in a subsequent message.

/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 nobody Mon May 19 15:54:17 2014
Return-Path: <bclaise@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BAA1A0413 for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 15:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqcIKCf7kq67 for <netmod@ietfa.amsl.com>; Mon, 19 May 2014 15:54:15 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9681A03E0 for <netmod@ietf.org>; Mon, 19 May 2014 15:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3189; q=dns/txt; s=iport; t=1400540055; x=1401749655; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=SrTHTBTj+zj9ML/t+qQzSzhsyb94TFsR1vJ9SJlxUEA=; b=OQRhvu1f1mka+i/rsqGm2qFha6Vl8npWgG9prWs1iBKSpIAM1020u5Fc EGMzrLZV4911XxGXDD2zDC3IkO3lymtxK5/7FyIhxCKTPetdZj/VJj88O 6wX6w7221qIlEKzwS7Mme8vT2WJNKn7Jb3hFZ/SN7AbZRb8nlFo+CRVkd Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoAFABiLelOtJA2D/2dsb2JhbABZAYMFUYNBuWQBhmlRAYEYFnSCJQEBAQQBAQEgCkEKARALBBQJFggDAgIJAwIBAgEVHxEGDQEFAgEBBYg4Da1tpGQXjk8HgnWBSwSKFY9FgT2FLYwwg1cdMA
X-IronPort-AV: E=Sophos; i="4.98,870,1392163200"; d="scan'208,217"; a="45277231"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 19 May 2014 22:54:15 +0000
Received: from [10.21.112.160] (sjc-vpn2-160.cisco.com [10.21.112.160]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4JMsE92015208; Mon, 19 May 2014 22:54:14 GMT
Message-ID: <537A8B96.5090406@cisco.com>
Date: Mon, 19 May 2014 15:54:14 -0700
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Jonathan Hansford <Jonathan@hansfords.net>
References: <5372944D.5010509@cisco.com> <6794186211ba862d0012e8da82b25d66@imap.plus.net>
In-Reply-To: <6794186211ba862d0012e8da82b25d66@imap.plus.net>
Content-Type: multipart/alternative; boundary="------------070007090907040005020302"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4pa0v1tkM2Us7s3iCASUAtfVskY
Cc: Netmod <netmod@ietf.org>
Subject: Re: [netmod] YANG Advice and Editing Session at the next IETF meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 22:54:17 -0000

This is a multi-part message in MIME format.
--------------070007090907040005020302
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jonathan,

A lot is already captured in http://datatracker.ietf.org/doc/rfc6087/

Regards, B.
>
> Benoit,
>
> Would it be worth capturing the sorts of issues that are identified 
> together with guidance on how to address them? As someone who to date 
> has only played at YANG module construction it would be useful to have 
> more guidance on the DOs, DON'Ts and general good practice.
>
> Jonathan
>
> On 2014-05-13 22:53, Benoit Claise wrote:
>
>> [Sorry for the potential cross-posting]
>>
>> http://www.ietf.org/meeting/90/tutorials/yang-session.html
>> Let me stress that this should be an interactive session, and not a
>> tutorial.
>> So come with your (plan to create) YANG modules.
>>
>> Regards, Benoit
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org  <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod


--------------070007090907040005020302
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Jonathan,<br>
      <br>
      A lot is already captured in
      <a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/doc/rfc6087/">http://datatracker.ietf.org/doc/rfc6087/</a><br>
      <br>
      Regards, B.<br>
    </div>
    <blockquote
      cite="mid:6794186211ba862d0012e8da82b25d66@imap.plus.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Benoit,</p>
      <p>Would it be worth capturing the sorts of issues that are
        identified together with guidance on how to address them? As
        someone who to date has only played at YANG module construction
        it would be useful to have more guidance on the DOs, DON'Ts and
        general good practice.</p>
      <p>Jonathan</p>
      <p>On 2014-05-13 22:53, Benoit Claise wrote:</p>
      <blockquote type="cite" style="padding-left:5px;
        border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
        <pre>[Sorry for the potential cross-posting]

<a moz-do-not-send="true" href="http://www.ietf.org/meeting/90/tutorials/yang-session.html">http://www.ietf.org/meeting/90/tutorials/yang-session.html</a>
Let me stress that this should be an interactive session, and not a 
tutorial.
So come with your (plan to create) YANG modules.

Regards, Benoit

_______________________________________________
netmod mailing list
<a moz-do-not-send="true" href="mailto:netmod@ietf.org">netmod@ietf.org</a>
<a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org/mailman/listinfo/netmod</a>
</pre>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>

--------------070007090907040005020302--


From nobody Mon May 19 17:58:12 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D9E1A045B; Mon, 19 May 2014 17:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.6
X-Spam-Level: 
X-Spam-Status: No, score=-96.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvG3daHpgyHW; Mon, 19 May 2014 17:58:06 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1B1A045A; Mon, 19 May 2014 17:58:06 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 1ED6612A785E; Tue, 20 May 2014 08:57:58 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 8715D6FF345; Tue, 20 May 2014 08:57:57 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s4K0vsg0043352; Tue, 20 May 2014 08:57:54 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140519201800.GB81067@elstar.jacobs.jacobs-university.de>
References: <20140519201800.GB81067@elstar.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
MIME-Version: 1.0
X-KeepSent: 14458D6E:4E76B7E5-48257CDE:0005239C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 08:57:54 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 08:57:55, Serialize complete at 2014-05-20 08:57:55
Content-Type: multipart/alternative; boundary="=_alternative 00054D4848257CDE_="
X-MAIL: mse01.zte.com.cn s4K0vsg0043352
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/spBdMuYyBbEMoUGeHH_PceMbMAc
Cc: netmod <netmod-bounces@ietf.org>, netmod@ietf.org
Subject: [netmod] =?gb2312?b?tPC4tDogIHlhbmcgMS4xIHN0YXR1cyBhbmQgbmV4dCBz?= =?gb2312?b?dGVwcw==?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 00:58:10 -0000

This is a multipart message in MIME format.

--=_alternative 00054D4848257CDE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzA5
Nzg4Lmh0bWwNCg0KV2h5IHRoaXMgaXNzdWUgaXMgbm90IGluY2x1ZGVkIGluIGlzc3VlIGxpc3Q/
DQovZnJhbmsNCg0KIm5ldG1vZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTQt
MDUtMjAgMDQ6MTg6MDA6DQoNCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IA0KPiC3orz+yMs6ICAibmV0bW9kIiA8bmV0bW9kLWJv
dW5jZXNAaWV0Zi5vcmc+DQo+IA0KPiAyMDE0LTA1LTIwIDA0OjE4DQo+IA0KPiDH67TwuLQguPgN
Cj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp
dHkuZGU+DQo+IA0KPiDK1bz+yMsNCj4gDQo+IG5ldG1vZEBpZXRmLm9yZywgDQo+IA0KPiCzrcvN
DQo+IA0KPiDW98ziDQo+IA0KPiBbbmV0bW9kXSB5YW5nIDEuMSBzdGF0dXMgYW5kIG5leHQgc3Rl
cHMNCj4gDQo+IEhpLA0KPiANCj4gdGhlIFdHIGhhcyBjb2xsZWN0ZWQgYSBudW1iZXIgb2YgaXNz
dWVkIHRvIGNvbnNpZGVyIGZvciBZQU5HIDEuMS4gVGhlDQo+IHJlc3VsdCBjYW4gYmUgZm91bmQg
aGVyZToNCj4gDQo+ICAgICAgIGh0dHA6Ly9zdm4udG9vbHMuaWV0Zi5vcmcvc3ZuL3dnL25ldG1v
ZC95YW5nLTEuMS8NCj4gDQo+IFRoZSBkZWFkbGluZSBmb3Igc3VibWl0dGluZyBpc3N1ZXMgd2Fz
IDIwMTQtMDUtMDcuIEl0IHNlZW1zIG9uZSBpc3N1ZQ0KPiBnb3Qgc3VibWl0dGVkIHBhc3QgdGhl
IGRlYWRsaW5lIGFuZCBvbmUgaXNzdWUgdGhhdCBjYW1lIHVwIGR1cmluZyB0aGUNCj4gZGlzY3Vz
c2lvbnMgd2FzIG5vdCBpbmNsdWRlZCBpbiB0aGUgaXNzdWVzIGxpc3QuIFdlIHBsYW4gdG8gaW5j
bHVkZQ0KPiB0aGVzZSB0d28gaXNzdWVzIGJ1dCBvdGhlcndpc2UgdGhlIGlzc3VlIGxpc3QgaXMg
Y2xvc2VkIG5vdy4NCj4gDQo+IEN1cnJlbnRseSwgYWxsIGlzc3VlcyBhcmUgbWFya2VkIGFzIE5F
Vy4gVGhlIFdHIG5vdyBoYXMgdG8gZGVjaWRlDQo+IHdoaWNoIGlzc3VlcyBhcmUgaW4gc2NvcGUg
b2YgdGhlIFlBTkcgMS4xIGVmZm9ydCAobW92aW5nIHRoZW0gdG8gT1BFTikNCj4gYW5kIHdoaWNo
IG9uZXMgYXJlIG5vdCBpbiBzY29wZSAobW92aW5nIHRoZW0gdG8gREVBRCkuIFRvIGtpY2tvZmYg
dGhpcw0KPiBzZWxlY3Rpb24gcHJvY2VzcywgdGhlIFdHIGNoYWlycywgd2l0aCB0aGUgaGVscCBv
ZiBzb21lIGNvcmUNCj4gY29udHJpYnV0b3JzIChuYW1lbHkgTWFydGluLCBBbmR5LCBMYWRhKSwg
aGF2ZSBwcm9kdWNlZCBhIHN0cmF3bWFuDQo+IHByb3Bvc2FsIHRoYXQgd2Ugd2lsbCBkaXN0cmli
dXRlIGluIHN1YnNlcXVlbnQgbWVzc2FnZXMuIFRoZSBnb2FsIGlzDQo+IHRvIGRldGVybWluZSBv
biB3aGljaCBpc3N1ZXMgdGhlIFdHIHN1cHBvcnRzIHRoZSBzdHJhd21hbiBwcm9wb3NhbC4NCj4g
Tm90ZSB0aGF0IHNvbWUgaXNzdWVzIHdlcmUgbGVmdCB1bmRlY2lkZWQgYmVjYXVzZSB3ZSBjb3Vs
ZCBub3QgY29tZSB1cA0KPiB3aXRoIGEgc3RyYXdtYW4gKGVpdGhlciBiZWNhdXNlIHRoZXJlIGFy
ZSBzaW1wbHkgZGlmZmVyZW50IG9waW5pb25zIG9yDQo+IHRoZXJlIGlzIGEgbGFjayBvZiB1bmRl
cnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSkuDQo+IA0KPiBPbmNlIHdlIGhhdmUgc2VsZWN0ZWQgdGhl
IE9QRU4gaXNzdWVzLCB3ZSB3aWxsIGhhdmUgdG8gaXRlcmF0ZSBvdmVyDQo+IHRoZW0gd2l0aCB0
aGUgZ29hbCB0byBmaW5kIGFncmVlbWVudCBvbiBzb2x1dGlvbnMgdGhhdCBhZGRyZXNzIHRoZQ0K
PiBpc3N1ZS4gSW4gb3JkZXIgdG8gZG8gdGhhdCwgd2UgcGxhbiB0byBob2xkIHdlZWtseSBjb25m
ZXJlbmNlIGNhbGxzIG9uDQo+IFdlZG5lc2RheXMgMTY6MDAtMTg6MDAgQ0VTVCwgc3RhcnRpbmcg
ZnJvbSBKdW5lIDR0aC4gQmVub2l0IGlzDQo+IHN1cHBvcnRpbmcgdXMgYnkgcHJvdmlkaW5nIFdl
YkV4IGZvciB0aGVzZSB2aXJ0dWFsIG1lZXRpbmdzLiBXZSB3aWxsDQo+IHNlbmQgb3V0IGZ1cnRo
ZXIgZGV0YWlscyBhYm91dCB0aGUgY2FsbHMgaW4gYSBzdWJzZXF1ZW50IG1lc3NhZ2UuDQo+IA0K
PiAvanMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9l
bndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9u
ZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwg
R2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3Lmph
Y29icy11bml2ZXJzaXR5LmRlLz4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYu
b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa
VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp
cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj
bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k
ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g
b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls
IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg
aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4
Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu
ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u
IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu
ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp
bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K

--=_alternative 00054D4848257CDE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJy
ZW50L21zZzA5Nzg4Lmh0bWwiPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8v
d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMDk3ODguaHRt
bDwvZm9udD48L2E+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldo
eSB0aGlzIGlzc3VlIGlzIG5vdCBpbmNsdWRlZCBpbiBpc3N1ZQ0KbGlzdD88L2ZvbnQ+DQo8YnI+
PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmcmZ3Q7DQrQtNPaIDIwMTQtMDUtMjAgMDQ6MTg6MDA6PGJyPg0KPGJyPg0KJmd0OyBKdWVy
Z2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k
ZSZndDsNCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyC3orz+yMs6ICZu
YnNwOyZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJy
Pg0KJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNS0y
MCAwNDoxODwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7
IMfrtPC4tCC4+Dxicj4NCiZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndh
ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgbmV0bW9kQGlldGYub3JnLCA8L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFtuZXRtb2RdIHlhbmcgMS4xIHN0YXR1cyBh
bmQgbmV4dCBzdGVwczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+
DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyB0aGUgV0cgaGFzIGNvbGxlY3RlZCBhIG51
bWJlciBvZiBpc3N1ZWQgdG8gY29uc2lkZXIgZm9yIFlBTkcgMS4xLg0KVGhlPGJyPg0KJmd0OyBy
ZXN1bHQgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly9zdm4udG9vbHMuaWV0Zi5vcmcv
c3ZuL3dnL25ldG1vZC95YW5nLTEuMS8iPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3N2bi50b29s
cy5pZXRmLm9yZy9zdm4vd2cvbmV0bW9kL3lhbmctMS4xLzwvZm9udD48L3R0PjwvYT48dHQ+PGZv
bnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZGVhZGxpbmUgZm9yIHN1Ym1pdHRp
bmcgaXNzdWVzIHdhcyAyMDE0LTA1LTA3LiBJdCBzZWVtcyBvbmUgaXNzdWU8YnI+DQomZ3Q7IGdv
dCBzdWJtaXR0ZWQgcGFzdCB0aGUgZGVhZGxpbmUgYW5kIG9uZSBpc3N1ZSB0aGF0IGNhbWUgdXAg
ZHVyaW5nDQp0aGU8YnI+DQomZ3Q7IGRpc2N1c3Npb25zIHdhcyBub3QgaW5jbHVkZWQgaW4gdGhl
IGlzc3VlcyBsaXN0LiBXZSBwbGFuIHRvIGluY2x1ZGU8YnI+DQomZ3Q7IHRoZXNlIHR3byBpc3N1
ZXMgYnV0IG90aGVyd2lzZSB0aGUgaXNzdWUgbGlzdCBpcyBjbG9zZWQgbm93Ljxicj4NCiZndDsg
PGJyPg0KJmd0OyBDdXJyZW50bHksIGFsbCBpc3N1ZXMgYXJlIG1hcmtlZCBhcyBORVcuIFRoZSBX
RyBub3cgaGFzIHRvIGRlY2lkZTxicj4NCiZndDsgd2hpY2ggaXNzdWVzIGFyZSBpbiBzY29wZSBv
ZiB0aGUgWUFORyAxLjEgZWZmb3J0IChtb3ZpbmcgdGhlbSB0byBPUEVOKTxicj4NCiZndDsgYW5k
IHdoaWNoIG9uZXMgYXJlIG5vdCBpbiBzY29wZSAobW92aW5nIHRoZW0gdG8gREVBRCkuIFRvIGtp
Y2tvZmYNCnRoaXM8YnI+DQomZ3Q7IHNlbGVjdGlvbiBwcm9jZXNzLCB0aGUgV0cgY2hhaXJzLCB3
aXRoIHRoZSBoZWxwIG9mIHNvbWUgY29yZTxicj4NCiZndDsgY29udHJpYnV0b3JzIChuYW1lbHkg
TWFydGluLCBBbmR5LCBMYWRhKSwgaGF2ZSBwcm9kdWNlZCBhIHN0cmF3bWFuPGJyPg0KJmd0OyBw
cm9wb3NhbCB0aGF0IHdlIHdpbGwgZGlzdHJpYnV0ZSBpbiBzdWJzZXF1ZW50IG1lc3NhZ2VzLiBU
aGUgZ29hbA0KaXM8YnI+DQomZ3Q7IHRvIGRldGVybWluZSBvbiB3aGljaCBpc3N1ZXMgdGhlIFdH
IHN1cHBvcnRzIHRoZSBzdHJhd21hbiBwcm9wb3NhbC48YnI+DQomZ3Q7IE5vdGUgdGhhdCBzb21l
IGlzc3VlcyB3ZXJlIGxlZnQgdW5kZWNpZGVkIGJlY2F1c2Ugd2UgY291bGQgbm90IGNvbWUNCnVw
PGJyPg0KJmd0OyB3aXRoIGEgc3RyYXdtYW4gKGVpdGhlciBiZWNhdXNlIHRoZXJlIGFyZSBzaW1w
bHkgZGlmZmVyZW50IG9waW5pb25zDQpvcjxicj4NCiZndDsgdGhlcmUgaXMgYSBsYWNrIG9mIHVu
ZGVyc3RhbmRpbmcgb2YgdGhlIGlzc3VlKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgT25jZSB3ZSBo
YXZlIHNlbGVjdGVkIHRoZSBPUEVOIGlzc3Vlcywgd2Ugd2lsbCBoYXZlIHRvIGl0ZXJhdGUgb3Zl
cjxicj4NCiZndDsgdGhlbSB3aXRoIHRoZSBnb2FsIHRvIGZpbmQgYWdyZWVtZW50IG9uIHNvbHV0
aW9ucyB0aGF0IGFkZHJlc3MgdGhlPGJyPg0KJmd0OyBpc3N1ZS4gSW4gb3JkZXIgdG8gZG8gdGhh
dCwgd2UgcGxhbiB0byBob2xkIHdlZWtseSBjb25mZXJlbmNlIGNhbGxzDQpvbjxicj4NCiZndDsg
V2VkbmVzZGF5cyAxNjowMC0xODowMCBDRVNULCBzdGFydGluZyBmcm9tIEp1bmUgNHRoLiBCZW5v
aXQgaXM8YnI+DQomZ3Q7IHN1cHBvcnRpbmcgdXMgYnkgcHJvdmlkaW5nIFdlYkV4IGZvciB0aGVz
ZSB2aXJ0dWFsIG1lZXRpbmdzLiBXZSB3aWxsPGJyPg0KJmd0OyBzZW5kIG91dCBmdXJ0aGVyIGRl
dGFpbHMgYWJvdXQgdGhlIGNhbGxzIGluIGEgc3Vic2VxdWVudCBtZXNzYWdlLjxicj4NCiZndDsg
PGJyPg0KJmd0OyAvanM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0
OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyBQaG9uZTogKzQ5IDQy
MSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwNCjI4
NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsgRmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEw
MyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9Imh0
dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93
d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+
Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsg
bmV0bW9kQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2ZvbnQ+PC90dD48L2E+PHR0
Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9
ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv
biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg
aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg
Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v
dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp
c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp
b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl
ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l
ZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJs
dWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj
b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy
ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y
IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh
biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry
aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g
Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0
aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh
dGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg==

--=_alternative 00054D4848257CDE_=--


From nobody Tue May 20 00:05:34 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392731A0313 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2F8uCNKX9VK for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:05:29 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD3C1A0268 for <netmod@ietf.org>; Tue, 20 May 2014 00:05:29 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id D528E7DE9 for <netmod@ietf.org>; Tue, 20 May 2014 15:05:14 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 65AAD724F36 for <netmod@ietf.org>; Tue, 20 May 2014 15:05:13 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s4K75Hu8094837 for <netmod@ietf.org>; Tue, 20 May 2014 15:05:17 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
To: netmod@ietf.org
MIME-Version: 1.0
X-KeepSent: C4C9BABF:6EB619B9-48257CDE:0025678D; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 15:05:18 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 15:05:19, Serialize complete at 2014-05-20 15:05:19
Content-Type: multipart/alternative; boundary="=_alternative 0026F02348257CDE_="
X-MAIL: mse01.zte.com.cn s4K75Hu8094837
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/c7yAvuH4l4Nv_6S7VXoZ57s_w7E
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn
Subject: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 07:05:32 -0000

This is a multipart message in MIME format.

--=_alternative 0026F02348257CDE_=
Content-Type: text/plain; charset="US-ASCII"

Hi all,
      I'm confused with rpc's xpath expression.
      For example:
      module a {
            prefix a;
           rpc foo {
               input {
                  leaf foo1 {...}
               }
               output {
                  leaf foo1 {...}
               }
           }
      }

    The xpath of the leaf name foo1 in foo's input is 
"a:foo/a:input/a:foo1"? or is "a:foo/a:foo1"?
    If it's latter, how to express the xpath of the leaf foo1 in foo's 
output?

    Another question, how to distinguish the xpath of datadef and the 
xpath of rpc?
    For example:
    module a {
        prefix a;
        container foo {
              container input {
                  leaf foo1 {...}
              }
        }
 
         rpc foo {
               input {
                  leaf foo1 {...}
               }
               output {
                  leaf foo1 {...}
               }
           }
    }

    The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in container or 
the leaf foo1 in rpc foo's input?
 
/frank
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0026F02348257CDE_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Hi all,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; I'm confused with
rpc's xpath expression.</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; For example:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; module a {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; prefix a;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rpc
foo {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;input {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;output {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; }</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; The xpath of the leaf
name foo1 in foo's input is &quot;a:foo/a:input/a:foo1&quot;? or is &quot;a:foo/a:foo1&quot;?</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; If it's latter, how to
express the xpath of the leaf foo1 in foo's output?</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; Another question, how
to distinguish the xpath of datadef and the xpath of rpc?</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; For example:</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; module a {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; prefix a;</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; container
foo {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; container input {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; }</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; }</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rpc
foo {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;input {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;output {</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; }</font>
<br>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; The xpath &quot;a:foo/a:input/a:foo1&quot;
points the leaf foo1 in container or the leaf foo1 in rpc foo's input?</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; </font>
<br><font size=2 face="sans-serif">/frank</font>

<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre><br>

<br><pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre><br>

--=_alternative 0026F02348257CDE_=--


From nobody Tue May 20 00:14:18 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECE51A029E for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGv-jL3sdnOB for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:14:13 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479611A0035 for <netmod@ietf.org>; Tue, 20 May 2014 00:14:13 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C8705719; Tue, 20 May 2014 09:14:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yfGnTuf6aUmr; Tue, 20 May 2014 09:14:11 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 May 2014 09:14:11 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F072A20017; Tue, 20 May 2014 09:14: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 YnxM9hwIpRMu; Tue, 20 May 2014 09:14:09 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1492020013; Tue, 20 May 2014 09:14:09 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3616D2CEAADD; Tue, 20 May 2014 09:14:07 +0200 (CEST)
Date: Tue, 20 May 2014 09:14:07 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: feng.chong33@zte.com.cn
Message-ID: <20140520071405.GA82265@elstar.local>
Mail-Followup-To: feng.chong33@zte.com.cn, netmod@ietf.org, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LGEBlBUzqlU7GGle3V0kMYgqeHc
Cc: dai.xianxian@zte.com.cn, cheng.zhu1@zte.com.cn, du.baowei23@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 07:14:15 -0000

See section 7.5.3 of RFC 6020:

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.  The XPath root node has the
      elements representing the RPC output parameters as children.

See also section 7.13.4 of RFC 6020 for the encoding of RPCs.

/js

On Tue, May 20, 2014 at 03:05:18PM +0800, feng.chong33@zte.com.cn wrote:
> Hi all,
>       I'm confused with rpc's xpath expression.
>       For example:
>       module a {
>             prefix a;
>            rpc foo {
>                input {
>                   leaf foo1 {...}
>                }
>                output {
>                   leaf foo1 {...}
>                }
>            }
>       }
> 
>     The xpath of the leaf name foo1 in foo's input is 
> "a:foo/a:input/a:foo1"? or is "a:foo/a:foo1"?
>     If it's latter, how to express the xpath of the leaf foo1 in foo's 
> output?
> 
>     Another question, how to distinguish the xpath of datadef and the 
> xpath of rpc?
>     For example:
>     module a {
>         prefix a;
>         container foo {
>               container input {
>                   leaf foo1 {...}
>               }
>         }
>  
>          rpc foo {
>                input {
>                   leaf foo1 {...}
>                }
>                output {
>                   leaf foo1 {...}
>                }
>            }
>     }
> 
>     The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in container or 
> the leaf foo1 in rpc foo's input?
>  
> /frank
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
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 nobody Tue May 20 00:25:46 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5751A028F for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.1
X-Spam-Level: 
X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGRC430uzNnT for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:25:43 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E31A0035 for <netmod@ietf.org>; Tue, 20 May 2014 00:25:42 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 89D8F12AD9CF for <netmod@ietf.org>; Tue, 20 May 2014 15:25:29 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 0EFD573DC47; Tue, 20 May 2014 15:25:29 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s4K7PZiF037011; Tue, 20 May 2014 15:25:35 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140520071405.GA82265@elstar.local>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <20140520071405.GA82265@elstar.local>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
MIME-Version: 1.0
X-KeepSent: 9B1D121A:93F72658-48257CDE:00282473; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF9B1D121A.93F72658-ON48257CDE.00282473-48257CDE.0028CBD0@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 15:25:36 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 15:25:36, Serialize complete at 2014-05-20 15:25:36
Content-Type: multipart/alternative; boundary="=_alternative 0028CBD048257CDE_="
X-MAIL: mse01.zte.com.cn s4K7PZiF037011
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/140UVI1AZ1_LzOOKfBmYI15RSXI
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 07:25:45 -0000

This is a multipart message in MIME format.

--=_alternative 0028CBD048257CDE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SnVlcmdlbiwNCiAgICAgSSBkbyBrbm93IGl0LCBidXQgSSB3YW50IHRvIHVzZSBycGMncyB4cGF0
aCBhcyB0YXJnZXQgbm9kZSBpbiBhdWdtZW50IA0Kb3IgZGV2aWF0aW9uLg0KU28sIHRoZXJlIGlz
IG5vIFhNTCBpbnN0YW5jZSBkb2N1bWVudC4NCg0KRm9yIGV4YW1wbGU6DQoNCm1vZHVsZSBiIHsN
CiAgICBwcmVmaXggYjsNCiAgICBpbXBvcnQgYSB7DQogICAgICAgIHByZWZpeCBhOw0KICAgIH0N
Cg0KICAgIGF1Z21lbnQgImE6Zm9vL2E6aW5wdXQiIHsNCiAgICAgICAgICBsZWFmIGZvbzIgey4u
Ln0NCiAgICB9DQp9DQoNCldoaWNoIG5vZGUgaXMgdGhlIHRhcmdldCBub2RlIG9mIHRoaXMgYXVn
dW1lbnQ/IHRoZSBpbnB1dCBpbiBjb250YWluZXIgZm9vIA0Kb3IgdGhlIGlucHV0IGluIHJwYyBm
b28/DQoNCi9mcmFuaw0KSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGU+INC009ogDQoyMDE0LTA1LTIwIDE1OjE0OjA3Og0KDQo+IEp1ZXJn
ZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiAN
Cj4gMjAxNC0wNS0yMCAxNToxNA0KPiANCj4gx+u08Li0ILj4DQo+IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiANCj4gytW8/sjL
DQo+IA0KPiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBuZXRt
b2RAaWV0Zi5vcmcsIGR1LmJhb3dlaTIzQHp0ZS5jb20uY24sIGNoZW5nLnpodTFAenRlLmNvbS5j
biwgDQo+IGRhaS54aWFueGlhbkB6dGUuY29tLmNuDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW25l
dG1vZF0gQSBxdWVzdGlvbiBhYm91dCBycGMncyB4cGF0aA0KPiANCj4gU2VlIHNlY3Rpb24gNy41
LjMgb2YgUkZDIDYwMjA6DQo+IA0KPiAgICBvICBJZiB0aGUgY29udGV4dCBub2RlIHJlcHJlc2Vu
dHMgUlBDIGlucHV0IHBhcmFtZXRlcnMsIHRoZSB0cmVlIGlzDQo+ICAgICAgIHRoZSBSUEMgWE1M
IGluc3RhbmNlIGRvY3VtZW50LiAgVGhlIFhQYXRoIHJvb3Qgbm9kZSBoYXMgdGhlDQo+ICAgICAg
IGVsZW1lbnQgcmVwcmVzZW50aW5nIHRoZSBSUEMgb3BlcmF0aW9uIGJlaW5nIGRlZmluZWQgYXMg
dGhlIG9ubHkNCj4gICAgICAgY2hpbGQuDQo+IA0KPiAgICBvICBJZiB0aGUgY29udGV4dCBub2Rl
IHJlcHJlc2VudHMgUlBDIG91dHB1dCBwYXJhbWV0ZXJzLCB0aGUgdHJlZSBpcw0KPiAgICAgICB0
aGUgUlBDIHJlcGx5IGluc3RhbmNlIGRvY3VtZW50LiAgVGhlIFhQYXRoIHJvb3Qgbm9kZSBoYXMg
dGhlDQo+ICAgICAgIGVsZW1lbnRzIHJlcHJlc2VudGluZyB0aGUgUlBDIG91dHB1dCBwYXJhbWV0
ZXJzIGFzIGNoaWxkcmVuLg0KPiANCj4gU2VlIGFsc28gc2VjdGlvbiA3LjEzLjQgb2YgUkZDIDYw
MjAgZm9yIHRoZSBlbmNvZGluZyBvZiBSUENzLg0KPiANCj4gL2pzDQo+IA0KPiBPbiBUdWUsIE1h
eSAyMCwgMjAxNCBhdCAwMzowNToxOFBNICswODAwLCBmZW5nLmNob25nMzNAenRlLmNvbS5jbiB3
cm90ZToNCj4gPiBIaSBhbGwsDQo+ID4gICAgICAgSSdtIGNvbmZ1c2VkIHdpdGggcnBjJ3MgeHBh
dGggZXhwcmVzc2lvbi4NCj4gPiAgICAgICBGb3IgZXhhbXBsZToNCj4gPiAgICAgICBtb2R1bGUg
YSB7DQo+ID4gICAgICAgICAgICAgcHJlZml4IGE7DQo+ID4gICAgICAgICAgICBycGMgZm9vIHsN
Cj4gPiAgICAgICAgICAgICAgICBpbnB1dCB7DQo+ID4gICAgICAgICAgICAgICAgICAgbGVhZiBm
b28xIHsuLi59DQo+ID4gICAgICAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICAgICAgIG91dHB1
dCB7DQo+ID4gICAgICAgICAgICAgICAgICAgbGVhZiBmb28xIHsuLi59DQo+ID4gICAgICAgICAg
ICAgICAgfQ0KPiA+ICAgICAgICAgICAgfQ0KPiA+ICAgICAgIH0NCj4gPiANCj4gPiAgICAgVGhl
IHhwYXRoIG9mIHRoZSBsZWFmIG5hbWUgZm9vMSBpbiBmb28ncyBpbnB1dCBpcyANCj4gPiAiYTpm
b28vYTppbnB1dC9hOmZvbzEiPyBvciBpcyAiYTpmb28vYTpmb28xIj8NCj4gPiAgICAgSWYgaXQn
cyBsYXR0ZXIsIGhvdyB0byBleHByZXNzIHRoZSB4cGF0aCBvZiB0aGUgbGVhZiBmb28xIGluIGZv
bydzIA0KDQo+ID4gb3V0cHV0Pw0KPiA+IA0KPiA+ICAgICBBbm90aGVyIHF1ZXN0aW9uLCBob3cg
dG8gZGlzdGluZ3Vpc2ggdGhlIHhwYXRoIG9mIGRhdGFkZWYgYW5kIHRoZSANCj4gPiB4cGF0aCBv
ZiBycGM/DQo+ID4gICAgIEZvciBleGFtcGxlOg0KPiA+ICAgICBtb2R1bGUgYSB7DQo+ID4gICAg
ICAgICBwcmVmaXggYTsNCj4gPiAgICAgICAgIGNvbnRhaW5lciBmb28gew0KPiA+ICAgICAgICAg
ICAgICAgY29udGFpbmVyIGlucHV0IHsNCj4gPiAgICAgICAgICAgICAgICAgICBsZWFmIGZvbzEg
ey4uLn0NCj4gPiAgICAgICAgICAgICAgIH0NCj4gPiAgICAgICAgIH0NCj4gPiANCj4gPiAgICAg
ICAgICBycGMgZm9vIHsNCj4gPiAgICAgICAgICAgICAgICBpbnB1dCB7DQo+ID4gICAgICAgICAg
ICAgICAgICAgbGVhZiBmb28xIHsuLi59DQo+ID4gICAgICAgICAgICAgICAgfQ0KPiA+ICAgICAg
ICAgICAgICAgIG91dHB1dCB7DQo+ID4gICAgICAgICAgICAgICAgICAgbGVhZiBmb28xIHsuLi59
DQo+ID4gICAgICAgICAgICAgICAgfQ0KPiA+ICAgICAgICAgICAgfQ0KPiA+ICAgICB9DQo+ID4g
DQo+ID4gICAgIFRoZSB4cGF0aCAiYTpmb28vYTppbnB1dC9hOmZvbzEiIHBvaW50cyB0aGUgbGVh
ZiBmb28xIGluIGNvbnRhaW5lciANCm9yIA0KPiA+IHRoZSBsZWFmIGZvbzEgaW4gcnBjIGZvbydz
IGlucHV0Pw0KPiA+IA0KPiA+IC9mcmFuaw0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gWlRFIEluZm9ybWF0aW9uIFNlY3Vy
aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQo+IG1haWwgKGFu
ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg
DQo+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9m
IHRoZSBhZGRyZXNzZWUNCj4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBp
ZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90
aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gaW5mb3JtYXRpb24gY29udGFpbmVk
IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCANCj4gdGhpcyBt
YWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHku
DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp
b24gY29udGFpbmVkIGluIHRoaXMNCj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0
dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBp
bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJ
ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4g
cmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ug
b2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g
IElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxl
dGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gDQo+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0
DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4gDQo+IA0KPiAtLSANCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAg
ICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEg
MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4g
RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy
c2l0eS5kZS8+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0
dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu
ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy
ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u
LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y
bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg
aW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y
bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p
dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl
bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh
cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv
biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz
IGltbWVkaWF0ZWx5Lg0K

--=_alternative 0028CBD048257CDE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PHR0Pjxmb250IHNpemU9Mj5KdWVyZ2VuLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIGRvIGtub3cgaXQsIGJ1dCBJIHdhbnQgdG8gdXNlDQpy
cGMncyB4cGF0aCBhcyB0YXJnZXQgbm9kZSBpbiBhdWdtZW50IG9yIGRldmlhdGlvbi48L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlNvLCB0aGVyZSBpcyBubyBYTUwgaW5zdGFuY2Ug
ZG9jdW1lbnQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Gb3IgZXhh
bXBsZTo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm1vZHVsZSBiIHs8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgcHJlZml4IGI7
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7IGltcG9ydCBh
IHs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyBwcmVmaXggYTs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNw
OyAmbmJzcDsgfTwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7
ICZuYnNwOyBhdWdtZW50ICZxdW90O2E6Zm9vL2E6aW5wdXQmcXVvdDsgezwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBs
ZWFmIGZvbzIgey4uLn08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAm
bmJzcDsgfTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+fTwvZm9udD48L3R0Pg0K
PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+V2hpY2ggbm9kZSBpcyB0aGUgdGFyZ2V0IG5vZGUg
b2YgdGhpcyBhdWd1bWVudD8gdGhlDQppbnB1dCBpbiBjb250YWluZXIgZm9vIG9yIHRoZSBpbnB1
dCBpbiBycGMgZm9vPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz
YW5zLXNlcmlmIj4vZnJhbms8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5KdWVyZ2VuIFNj
aG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsN
CtC009ogMjAxNC0wNS0yMCAxNToxNDowNzo8YnI+DQo8YnI+DQomZ3Q7IEp1ZXJnZW4gU2Nob2Vu
d2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Ow0KPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIwMTQtMDUtMjAgMTU6MTQ8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDH67TwuLQguPg8
YnI+DQomZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29i
cy11bml2ZXJzaXR5LmRlJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyA8YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgbmV0bW9kQGlldGYub3JnLCBkdS5iYW93ZWky
M0B6dGUuY29tLmNuLCBjaGVuZy56aHUxQHp0ZS5jb20uY24sIDxicj4NCiZndDsgZGFpLnhpYW54
aWFuQHp0ZS5jb20uY248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy
Pg0KJmd0OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N
CiZndDsgUmU6IFtuZXRtb2RdIEEgcXVlc3Rpb24gYWJvdXQgcnBjJ3MgeHBhdGg8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBTZWUgc2VjdGlvbiA3LjUu
MyBvZiBSRkMgNjAyMDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7
SWYgdGhlIGNvbnRleHQgbm9kZSByZXByZXNlbnRzIFJQQyBpbnB1dCBwYXJhbWV0ZXJzLA0KdGhl
IHRyZWUgaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBSUEMgWE1MIGluc3Rh
bmNlIGRvY3VtZW50LiAmbmJzcDtUaGUgWFBhdGgNCnJvb3Qgbm9kZSBoYXMgdGhlPGJyPg0KJmd0
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbGVtZW50IHJlcHJlc2VudGluZyB0aGUgUlBDIG9wZXJh
dGlvbiBiZWluZw0KZGVmaW5lZCBhcyB0aGUgb25seTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgY2hpbGQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtvICZuYnNwO0lm
IHRoZSBjb250ZXh0IG5vZGUgcmVwcmVzZW50cyBSUEMgb3V0cHV0IHBhcmFtZXRlcnMsDQp0aGUg
dHJlZSBpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIFJQQyByZXBseSBpbnN0
YW5jZSBkb2N1bWVudC4gJm5ic3A7VGhlIFhQYXRoDQpyb290IG5vZGUgaGFzIHRoZTxicj4NCiZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZWxlbWVudHMgcmVwcmVzZW50aW5nIHRoZSBSUEMgb3V0
cHV0IHBhcmFtZXRlcnMNCmFzIGNoaWxkcmVuLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTZWUgYWxz
byBzZWN0aW9uIDcuMTMuNCBvZiBSRkMgNjAyMCBmb3IgdGhlIGVuY29kaW5nIG9mIFJQQ3MuPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IC9qczxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUdWUsIE1heSAy
MCwgMjAxNCBhdCAwMzowNToxOFBNICswODAwLCBmZW5nLmNob25nMzNAenRlLmNvbS5jbg0Kd3Jv
dGU6PGJyPg0KJmd0OyAmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgSSdtIGNvbmZ1c2VkIHdpdGggcnBjJ3MgeHBhdGggZXhwcmVzc2lvbi48YnI+DQomZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGU6PGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IG1vZHVsZSBhIHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJlZml4IGE7PGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cnBjIGZvbyB7PGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDtpbnB1dA0Kezxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KbGVhZiBmb28xIHsuLi59PGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDt9PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvdXRwdXQNCns8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmxl
YWYgZm9vMSB7Li4ufTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBU
aGUgeHBhdGggb2YgdGhlIGxlYWYgbmFtZSBmb28xIGluIGZvbydzIGlucHV0DQppcyA8YnI+DQom
Z3Q7ICZndDsgJnF1b3Q7YTpmb28vYTppbnB1dC9hOmZvbzEmcXVvdDs/IG9yIGlzICZxdW90O2E6
Zm9vL2E6Zm9vMSZxdW90Oz88YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBJZiBpdCdzIGxh
dHRlciwgaG93IHRvIGV4cHJlc3MgdGhlIHhwYXRoIG9mIHRoZQ0KbGVhZiBmb28xIGluIGZvbydz
IDxicj4NCiZndDsgJmd0OyBvdXRwdXQ/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7IEFub3RoZXIgcXVlc3Rpb24sIGhvdyB0byBkaXN0aW5ndWlzaCB0aGUgeHBh
dGgNCm9mIGRhdGFkZWYgYW5kIHRoZSA8YnI+DQomZ3Q7ICZndDsgeHBhdGggb2YgcnBjPzxicj4N
CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEZvciBleGFtcGxlOjxicj4NCiZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7IG1vZHVsZSBhIHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7IHByZWZpeCBhOzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgY29udGFpbmVyIGZvbyB7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWluZXIgaW5wdXQNCns8YnI+DQomZ3Q7ICZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsNCmxlYWYgZm9vMSB7Li4ufTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JwYyBmb28gezxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7aW5wdXQNCns8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmxlYWYgZm9vMSB7Li4ufTxicj4NCiZn
dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7fTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3V0cHV0DQp7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpsZWFm
IGZvbzEgey4uLn08YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg
fTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBUaGUgeHBhdGgg
JnF1b3Q7YTpmb28vYTppbnB1dC9hOmZvbzEmcXVvdDsgcG9pbnRzDQp0aGUgbGVhZiBmb28xIGlu
IGNvbnRhaW5lciBvciA8YnI+DQomZ3Q7ICZndDsgdGhlIGxlYWYgZm9vMSBpbiBycGMgZm9vJ3Mg
aW5wdXQ/PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAvZnJhbms8YnI+DQom
Z3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog
VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpczxicj4NCiZndDsgbWFpbCAoYW5kIGFu
eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCA8YnI+
DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl
IG9mIHRoZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4g
aW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgPGJyPg0KJmd0OyByZXByb2R1Y3Rp
b24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgPGJy
Pg0KJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5i
c3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBw
bGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
PGJyPg0KJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaW4NCnRoaXM8YnI+DQomZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNo
bWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyBj
b25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUg
YWRkcmVzc2VlPGJyPg0KJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk
IHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBkaXN0
cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsg
aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlv
dSBoYXZlIHJlY2VpdmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl
bGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
Jmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgbmV0bW9kQGlldGYu
b3JnPGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg
c2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgSnVl
cmdlbiBTY2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFj
b2JzIFVuaXZlcnNpdHkNCkJyZW1lbiBnR21iSDxicj4NCiZndDsgUGhvbmU6ICs0OSA0MjEgMjAw
IDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsDQoyODc1OSBC
cmVtZW4sIEdlcm1hbnk8YnI+DQomZ3Q7IEZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8v
d3d3LmphY29icy11bml2ZXJzaXR5LmRlLyI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3Lmph
Y29icy11bml2ZXJzaXR5LmRlLzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8
YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ
bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g
dGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHBy
aXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNp
dmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCBy
ZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv
dGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlz
IHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9m
b250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv
cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp
cyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp
bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg
dXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp
cGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl
ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0
cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy
b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250
PjwvcHJlPjxicj4NCg==

--=_alternative 0028CBD048257CDE_=--


From nobody Tue May 20 00:41:21 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016DE1A028F for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxm48Adn5XD5 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:41:18 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCB71A0035 for <netmod@ietf.org>; Tue, 20 May 2014 00:41:18 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF404D2D; Tue, 20 May 2014 09:41:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NX9rjqvlZKJL; Tue, 20 May 2014 09:41:15 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 May 2014 09:41:15 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6CF520017; Tue, 20 May 2014 09:41:15 +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 JYCXUPxHscDk; Tue, 20 May 2014 09:41:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BCD620013; Tue, 20 May 2014 09:41:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 67DAF2CEAC4F; Tue, 20 May 2014 09:41:13 +0200 (CEST)
Date: Tue, 20 May 2014 09:41:13 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: feng.chong33@zte.com.cn
Message-ID: <20140520074113.GC82265@elstar.local>
Mail-Followup-To: feng.chong33@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, du.baowei23@zte.com.cn, netmod@ietf.org
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <20140520071405.GA82265@elstar.local> <OF9B1D121A.93F72658-ON48257CDE.00282473-48257CDE.0028CBD0@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <OF9B1D121A.93F72658-ON48257CDE.00282473-48257CDE.0028CBD0@zte.com.cn>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/S0n2_rjmA37fu0LnC4bZ6a12RQg
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 07:41:20 -0000

On Tue, May 20, 2014 at 03:25:36PM +0800, feng.chong33@zte.com.cn wrote:
> Juergen,
>      I do know it, but I want to use rpc's xpath as target node in augment 
> or deviation.

No, you were asking the wrong question then. The path statement in an
augment has nothing to do with xpath. See section 7.15 of RFC 6020,
second paragraph.

/js

> So, there is no XML instance document.
> 
> For example:
> 
> module b {
>     prefix b;
>     import a {
>         prefix a;
>     }
> 
>     augment "a:foo/a:input" {
>           leaf foo2 {...}
>     }
> }
> 
> Which node is the target node of this augument? the input in container foo 
> or the input in rpc foo?
> 
> /frank
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> ċ†™äşŽ 
> 2014-05-20 15:14:07:
> 
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 
> > 2014-05-20 15:14
> > 
> > èŻ·ç­”ċ¤ çğ™
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > 
> > ĉ”ĥäğĥäşş
> > 
> > feng.chong33@zte.com.cn, 
> > 
> > ĉŠ„送
> > 
> > netmod@ietf.org, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, 
> > dai.xianxian@zte.com.cn
> > 
> > ä¸ğ题
> > 
> > Re: [netmod] A question about rpc's xpath
> > 
> > See section 7.5.3 of RFC 6020:
> > 
> >    o  If the context node represents RPC input parameters, the tree is
> >       the RPC XML instance document.  The XPath root node has the
> >       element representing the RPC operation being defined as the only
> >       child.
> > 
> >    o  If the context node represents RPC output parameters, the tree is
> >       the RPC reply instance document.  The XPath root node has the
> >       elements representing the RPC output parameters as children.
> > 
> > See also section 7.13.4 of RFC 6020 for the encoding of RPCs.
> > 
> > /js
> > 
> > On Tue, May 20, 2014 at 03:05:18PM +0800, feng.chong33@zte.com.cn wrote:
> > > Hi all,
> > >       I'm confused with rpc's xpath expression.
> > >       For example:
> > >       module a {
> > >             prefix a;
> > >            rpc foo {
> > >                input {
> > >                   leaf foo1 {...}
> > >                }
> > >                output {
> > >                   leaf foo1 {...}
> > >                }
> > >            }
> > >       }
> > > 
> > >     The xpath of the leaf name foo1 in foo's input is 
> > > "a:foo/a:input/a:foo1"? or is "a:foo/a:foo1"?
> > >     If it's latter, how to express the xpath of the leaf foo1 in foo's 
> 
> > > output?
> > > 
> > >     Another question, how to distinguish the xpath of datadef and the 
> > > xpath of rpc?
> > >     For example:
> > >     module a {
> > >         prefix a;
> > >         container foo {
> > >               container input {
> > >                   leaf foo1 {...}
> > >               }
> > >         }
> > > 
> > >          rpc foo {
> > >                input {
> > >                   leaf foo1 {...}
> > >                }
> > >                output {
> > >                   leaf foo1 {...}
> > >                }
> > >            }
> > >     }
> > > 
> > >     The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in container 
> or 
> > > the leaf foo1 in rpc foo's input?
> > > 
> > > /frank
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and 
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure, 
> > reproduction, distribution or other dissemination or use of the 
> > information contained is strictly prohibited.  If you have received 
> > this mail in error, please delete it and notify us immediately.
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and 
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure, 
> > reproduction, distribution or other dissemination or use of the 
> > information contained is strictly prohibited.  If you have received 
> > this mail in error, please delete it and notify us immediately.
> > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > -- 
> > 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/>
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

-- 
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 nobody Tue May 20 00:46:25 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682E1A02F4 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.6
X-Spam-Level: 
X-Spam-Status: No, score=-96.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOGvZHYISByh for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:46:20 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 792B01A0290 for <netmod@ietf.org>; Tue, 20 May 2014 00:46:19 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 73A3A12ADF31; Tue, 20 May 2014 15:46:06 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4K7k2Ug045744; Tue, 20 May 2014 15:46:02 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140520074113.GC82265@elstar.local>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <20140520071405.GA82265@elstar.local> <OF9B1D121A.93F72658-ON48257CDE.00282473-48257CDE.0028CBD0@zte.com.cn> <20140520074113.GC82265@elstar.local>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
MIME-Version: 1.0
X-KeepSent: 532EF376:C9FE1107-48257CDE:002A7E4F; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF532EF376.C9FE1107-ON48257CDE.002A7E4F-48257CDE.002AAB5E@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 15:46:03 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 15:46:05, Serialize complete at 2014-05-20 15:46:05
Content-Type: multipart/alternative; boundary="=_alternative 002AAB5C48257CDE_="
X-MAIL: mse02.zte.com.cn s4K7k2Ug045744
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/omwYXJYmTMAF9FDRtytdPCsQf24
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: [netmod] =?gb2312?b?tPC4tDogUmU6ICBBIHF1ZXN0aW9uIGFib3V0IHJwYydz?= =?gb2312?b?IHhwYXRo?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 07:46:22 -0000

This is a multipart message in MIME format.

--=_alternative 002AAB5C48257CDE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCk9LLiBJJ20gd3JvbmcuIEJ1dCBob3cgdG8gZXhwcmVzcyBycGMncyBhYnNvbHV0
ZS1zY2hlbWEtbm9kZWlkIGFuZCANCmRlc2NlbmRhbnQtc2NoZW1hLW5vZGVpZD8NCg0KSnVlcmdl
biBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+INC0
09ogDQoyMDE0LTA1LTIwIDE1OjQxOjEzOg0KDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCj4gMjAxNC0wNS0yMCAxNTo0MQ0K
PiANCj4gx+u08Li0ILj4DQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlPg0KPiANCj4gytW8/sjLDQo+IA0KPiBmZW5nLmNob25nMzNA
enRlLmNvbS5jbiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBjaGVuZy56aHUxQHp0ZS5jb20uY24sIGRh
aS54aWFueGlhbkB6dGUuY29tLmNuLCANCj4gZHUuYmFvd2VpMjNAenRlLmNvbS5jbiwgbmV0bW9k
QGlldGYub3JnDQo+IA0KPiDW98ziDQo+IA0KPiBSZTogW25ldG1vZF0gQSBxdWVzdGlvbiBhYm91
dCBycGMncyB4cGF0aA0KPiANCj4gT24gVHVlLCBNYXkgMjAsIDIwMTQgYXQgMDM6MjU6MzZQTSAr
MDgwMCwgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gSnVlcmdlbiwNCj4gPiAg
ICAgIEkgZG8ga25vdyBpdCwgYnV0IEkgd2FudCB0byB1c2UgcnBjJ3MgeHBhdGggYXMgdGFyZ2V0
IG5vZGUgaW4gDQphdWdtZW50IA0KPiA+IG9yIGRldmlhdGlvbi4NCj4gDQo+IE5vLCB5b3Ugd2Vy
ZSBhc2tpbmcgdGhlIHdyb25nIHF1ZXN0aW9uIHRoZW4uIFRoZSBwYXRoIHN0YXRlbWVudCBpbiBh
bg0KPiBhdWdtZW50IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggeHBhdGguIFNlZSBzZWN0aW9uIDcu
MTUgb2YgUkZDIDYwMjAsDQo+IHNlY29uZCBwYXJhZ3JhcGguDQo+IA0KPiAvanMNCj4gDQo+ID4g
U28sIHRoZXJlIGlzIG5vIFhNTCBpbnN0YW5jZSBkb2N1bWVudC4NCj4gPiANCj4gPiBGb3IgZXhh
bXBsZToNCj4gPiANCj4gPiBtb2R1bGUgYiB7DQo+ID4gICAgIHByZWZpeCBiOw0KPiA+ICAgICBp
bXBvcnQgYSB7DQo+ID4gICAgICAgICBwcmVmaXggYTsNCj4gPiAgICAgfQ0KPiA+IA0KPiA+ICAg
ICBhdWdtZW50ICJhOmZvby9hOmlucHV0IiB7DQo+ID4gICAgICAgICAgIGxlYWYgZm9vMiB7Li4u
fQ0KPiA+ICAgICB9DQo+ID4gfQ0KPiA+IA0KPiA+IFdoaWNoIG5vZGUgaXMgdGhlIHRhcmdldCBu
b2RlIG9mIHRoaXMgYXVndW1lbnQ/IHRoZSBpbnB1dCBpbiBjb250YWluZXIgDQpmb28gDQo+ID4g
b3IgdGhlIGlucHV0IGluIHJwYyBmb28/DQo+ID4gDQo+ID4gL2ZyYW5rDQo+ID4gSnVlcmdlbiBT
Y2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+INC009og
DQo+ID4gMjAxNC0wNS0yMCAxNToxNDowNzoNCj4gPiANCj4gPiA+IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCj4gPiA+IDIwMTQt
MDUtMjAgMTU6MTQNCj4gPiA+IA0KPiA+ID4gx+u08Li0ILj4DQo+ID4gPiBKdWVyZ2VuIFNjaG9l
bndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gPiA+IA0K
PiA+ID4gytW8/sjLDQo+ID4gPiANCj4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4g
PiA+IA0KPiA+ID4gs63LzQ0KPiA+ID4gDQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmcsIGR1LmJhb3dl
aTIzQHp0ZS5jb20uY24sIGNoZW5nLnpodTFAenRlLmNvbS5jbiwgDQo+ID4gPiBkYWkueGlhbnhp
YW5AenRlLmNvbS5jbg0KPiA+ID4gDQo+ID4gPiDW98ziDQo+ID4gPiANCj4gPiA+IFJlOiBbbmV0
bW9kXSBBIHF1ZXN0aW9uIGFib3V0IHJwYydzIHhwYXRoDQo+ID4gPiANCj4gPiA+IFNlZSBzZWN0
aW9uIDcuNS4zIG9mIFJGQyA2MDIwOg0KPiA+ID4gDQo+ID4gPiAgICBvICBJZiB0aGUgY29udGV4
dCBub2RlIHJlcHJlc2VudHMgUlBDIGlucHV0IHBhcmFtZXRlcnMsIHRoZSB0cmVlIA0KaXMNCj4g
PiA+ICAgICAgIHRoZSBSUEMgWE1MIGluc3RhbmNlIGRvY3VtZW50LiAgVGhlIFhQYXRoIHJvb3Qg
bm9kZSBoYXMgdGhlDQo+ID4gPiAgICAgICBlbGVtZW50IHJlcHJlc2VudGluZyB0aGUgUlBDIG9w
ZXJhdGlvbiBiZWluZyBkZWZpbmVkIGFzIHRoZSANCm9ubHkNCj4gPiA+ICAgICAgIGNoaWxkLg0K
PiA+ID4gDQo+ID4gPiAgICBvICBJZiB0aGUgY29udGV4dCBub2RlIHJlcHJlc2VudHMgUlBDIG91
dHB1dCBwYXJhbWV0ZXJzLCB0aGUgdHJlZSANCmlzDQo+ID4gPiAgICAgICB0aGUgUlBDIHJlcGx5
IGluc3RhbmNlIGRvY3VtZW50LiAgVGhlIFhQYXRoIHJvb3Qgbm9kZSBoYXMgdGhlDQo+ID4gPiAg
ICAgICBlbGVtZW50cyByZXByZXNlbnRpbmcgdGhlIFJQQyBvdXRwdXQgcGFyYW1ldGVycyBhcyBj
aGlsZHJlbi4NCj4gPiA+IA0KPiA+ID4gU2VlIGFsc28gc2VjdGlvbiA3LjEzLjQgb2YgUkZDIDYw
MjAgZm9yIHRoZSBlbmNvZGluZyBvZiBSUENzLg0KPiA+ID4gDQo+ID4gPiAvanMNCj4gPiA+IA0K
PiA+ID4gT24gVHVlLCBNYXkgMjAsIDIwMTQgYXQgMDM6MDU6MThQTSArMDgwMCwgZmVuZy5jaG9u
ZzMzQHp0ZS5jb20uY24gDQp3cm90ZToNCj4gPiA+ID4gSGkgYWxsLA0KPiA+ID4gPiAgICAgICBJ
J20gY29uZnVzZWQgd2l0aCBycGMncyB4cGF0aCBleHByZXNzaW9uLg0KPiA+ID4gPiAgICAgICBG
b3IgZXhhbXBsZToNCj4gPiA+ID4gICAgICAgbW9kdWxlIGEgew0KPiA+ID4gPiAgICAgICAgICAg
ICBwcmVmaXggYTsNCj4gPiA+ID4gICAgICAgICAgICBycGMgZm9vIHsNCj4gPiA+ID4gICAgICAg
ICAgICAgICAgaW5wdXQgew0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICBsZWFmIGZvbzEgey4u
Ln0NCj4gPiA+ID4gICAgICAgICAgICAgICAgfQ0KPiA+ID4gPiAgICAgICAgICAgICAgICBvdXRw
dXQgew0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICBsZWFmIGZvbzEgey4uLn0NCj4gPiA+ID4g
ICAgICAgICAgICAgICAgfQ0KPiA+ID4gPiAgICAgICAgICAgIH0NCj4gPiA+ID4gICAgICAgfQ0K
PiA+ID4gPiANCj4gPiA+ID4gICAgIFRoZSB4cGF0aCBvZiB0aGUgbGVhZiBuYW1lIGZvbzEgaW4g
Zm9vJ3MgaW5wdXQgaXMgDQo+ID4gPiA+ICJhOmZvby9hOmlucHV0L2E6Zm9vMSI/IG9yIGlzICJh
OmZvby9hOmZvbzEiPw0KPiA+ID4gPiAgICAgSWYgaXQncyBsYXR0ZXIsIGhvdyB0byBleHByZXNz
IHRoZSB4cGF0aCBvZiB0aGUgbGVhZiBmb28xIGluIA0KZm9vJ3MgDQo+ID4gDQo+ID4gPiA+IG91
dHB1dD8NCj4gPiA+ID4gDQo+ID4gPiA+ICAgICBBbm90aGVyIHF1ZXN0aW9uLCBob3cgdG8gZGlz
dGluZ3Vpc2ggdGhlIHhwYXRoIG9mIGRhdGFkZWYgYW5kIA0KdGhlIA0KPiA+ID4gPiB4cGF0aCBv
ZiBycGM/DQo+ID4gPiA+ICAgICBGb3IgZXhhbXBsZToNCj4gPiA+ID4gICAgIG1vZHVsZSBhIHsN
Cj4gPiA+ID4gICAgICAgICBwcmVmaXggYTsNCj4gPiA+ID4gICAgICAgICBjb250YWluZXIgZm9v
IHsNCj4gPiA+ID4gICAgICAgICAgICAgICBjb250YWluZXIgaW5wdXQgew0KPiA+ID4gPiAgICAg
ICAgICAgICAgICAgICBsZWFmIGZvbzEgey4uLn0NCj4gPiA+ID4gICAgICAgICAgICAgICB9DQo+
ID4gPiA+ICAgICAgICAgfQ0KPiA+ID4gPiANCj4gPiA+ID4gICAgICAgICAgcnBjIGZvbyB7DQo+
ID4gPiA+ICAgICAgICAgICAgICAgIGlucHV0IHsNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAg
bGVhZiBmb28xIHsuLi59DQo+ID4gPiA+ICAgICAgICAgICAgICAgIH0NCj4gPiA+ID4gICAgICAg
ICAgICAgICAgb3V0cHV0IHsNCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgbGVhZiBmb28xIHsu
Li59DQo+ID4gPiA+ICAgICAgICAgICAgICAgIH0NCj4gPiA+ID4gICAgICAgICAgICB9DQo+ID4g
PiA+ICAgICB9DQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgVGhlIHhwYXRoICJhOmZvby9hOmlucHV0
L2E6Zm9vMSIgcG9pbnRzIHRoZSBsZWFmIGZvbzEgaW4gDQpjb250YWluZXIgDQo+ID4gb3IgDQo+
ID4gPiA+IHRoZSBsZWFmIGZvbzEgaW4gcnBjIGZvbydzIGlucHV0Pw0KPiA+ID4gPiANCj4gPiA+
ID4gL2ZyYW5rDQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp
Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPiA+ID4gbWFpbCAoYW5kIGFu
eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4g
PiA+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9m
IHRoZSBhZGRyZXNzZWUNCj4gPiA+IChzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl
Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiA+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp
b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiA+ID4gaW5mb3JtYXRp
b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl
ZCANCj4gPiA+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5
IHVzIGltbWVkaWF0ZWx5Lg0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJp
dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCj4gPiA+IG1haWwg
KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBh
bmQgDQo+ID4gPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl
IHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+ID4gPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRl
bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiA+IHJlcHJvZHVjdGlvbiwgZGlz
dHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gPiA+IGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg
cmVjZWl2ZWQgDQo+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k
IG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+IA0KPiA+ID4gPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBuZXRtb2QgbWFpbGluZyBs
aXN0DQo+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IC0tIA0KPiA+
ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVt
ZW4gZ0dtYkgNCj4gPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJp
bmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+ID4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw
MyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gPiANCj4gPiAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
PiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250
YWluZWQgaW4gdGhpcw0KPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy
ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk
IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChzKS4gIElmIHlvdSBh
cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiByZXByb2R1
Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg
DQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91
IGhhdmUgcmVjZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBh
bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiANCj4gLS0gDQo+IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiAr
NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJt
YW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2Jz
LXVuaXZlcnNpdHkuZGUvPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl
IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0
cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp
cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm
IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv
ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo
ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90
aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K

--=_alternative 002AAB5C48257CDE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+T0suIEknbSB3cm9uZy4gQnV0IGhvdyB0byBl
eHByZXNzIHJwYydzDQphYnNvbHV0ZS1zY2hlbWEtbm9kZWlkIGFuZCBkZXNjZW5kYW50LXNjaGVt
YS1ub2RlaWQ/PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SnVlcmdlbiBTY2hv
ZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQrQ
tNPaIDIwMTQtMDUtMjAgMTU6NDE6MTM6PGJyPg0KPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCjwvZm9u
dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA1LTIwIDE1OjQxPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgx+u08Li0ILj4PGJy
Pg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
PGJyPg0KJmd0OyDK1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
PGJyPg0KJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgPC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGNoZW5nLnpodTFAenRlLmNvbS5jbiwgZGFpLnhp
YW54aWFuQHp0ZS5jb20uY24sIDxicj4NCiZndDsgZHUuYmFvd2VpMjNAenRlLmNvbS5jbiwgbmV0
bW9kQGlldGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N
CiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom
Z3Q7IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9uIGFib3V0IHJwYydzIHhwYXRoPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgT24gVHVlLCBNYXkgMjAsIDIw
MTQgYXQgMDM6MjU6MzZQTSArMDgwMCwgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24NCndyb3RlOjxi
cj4NCiZndDsgJmd0OyBKdWVyZ2VuLDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
O0kgZG8ga25vdyBpdCwgYnV0IEkgd2FudCB0byB1c2UgcnBjJ3MgeHBhdGgNCmFzIHRhcmdldCBu
b2RlIGluIGF1Z21lbnQgPGJyPg0KJmd0OyAmZ3Q7IG9yIGRldmlhdGlvbi48YnI+DQomZ3Q7IDxi
cj4NCiZndDsgTm8sIHlvdSB3ZXJlIGFza2luZyB0aGUgd3JvbmcgcXVlc3Rpb24gdGhlbi4gVGhl
IHBhdGggc3RhdGVtZW50IGluDQphbjxicj4NCiZndDsgYXVnbWVudCBoYXMgbm90aGluZyB0byBk
byB3aXRoIHhwYXRoLiBTZWUgc2VjdGlvbiA3LjE1IG9mIFJGQyA2MDIwLDxicj4NCiZndDsgc2Vj
b25kIHBhcmFncmFwaC48YnI+DQomZ3Q7IDxicj4NCiZndDsgL2pzPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7ICZndDsgU28sIHRoZXJlIGlzIG5vIFhNTCBpbnN0YW5jZSBkb2N1bWVudC48YnI+DQomZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZvciBleGFtcGxlOjxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgbW9kdWxlIGIgezxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHByZWZpeCBi
Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IGltcG9ydCBhIHs8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByZWZpeCBhOzxicj4NCiZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg
YXVnbWVudCAmcXVvdDthOmZvby9hOmlucHV0JnF1b3Q7IHs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmIGZvbzIgey4uLn08YnI+DQomZ3Q7ICZn
dDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7IH08YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7IFdoaWNoIG5vZGUgaXMgdGhlIHRhcmdldCBub2RlIG9mIHRoaXMgYXVndW1lbnQ/
IHRoZSBpbnB1dCBpbg0KY29udGFpbmVyIGZvbyA8YnI+DQomZ3Q7ICZndDsgb3IgdGhlIGlucHV0
IGluIHJwYyBmb28/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAvZnJhbms8YnI+DQom
Z3Q7ICZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2Jz
LXVuaXZlcnNpdHkuZGUmZ3Q7DQrQtNPaIDxicj4NCiZndDsgJmd0OyAyMDE0LTA1LTIwIDE1OjE0
OjA3Ojxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCjxicj4N
CiZndDsgJmd0OyAmZ3Q7IDIwMTQtMDUtMjAgMTU6MTQ8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyDH67TwuLQguPg8YnI+DQomZ3Q7ICZndDsgJmd0OyBKdWVyZ2VuIFNj
aG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDK1bz+yMs8YnI+DQomZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgs63LzTxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IG5ldG1vZEBpZXRmLm9yZywgZHUuYmFvd2Vp
MjNAenRlLmNvbS5jbiwgY2hlbmcuemh1MUB6dGUuY29tLmNuLA0KPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgZGFpLnhpYW54aWFuQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyDW98ziPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
UmU6IFtuZXRtb2RdIEEgcXVlc3Rpb24gYWJvdXQgcnBjJ3MgeHBhdGg8YnI+DQomZ3Q7ICZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBTZWUgc2VjdGlvbiA3LjUuMyBvZiBSRkMgNjAyMDo8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7byAm
bmJzcDtJZiB0aGUgY29udGV4dCBub2RlIHJlcHJlc2VudHMgUlBDDQppbnB1dCBwYXJhbWV0ZXJz
LCB0aGUgdHJlZSBpczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRo
ZSBSUEMgWE1MIGluc3RhbmNlIGRvY3VtZW50LiAmbmJzcDtUaGUNClhQYXRoIHJvb3Qgbm9kZSBo
YXMgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZWxlbWVudCBy
ZXByZXNlbnRpbmcgdGhlIFJQQyBvcGVyYXRpb24NCmJlaW5nIGRlZmluZWQgYXMgdGhlIG9ubHk8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjaGlsZC48YnI+DQomZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtJZiB0
aGUgY29udGV4dCBub2RlIHJlcHJlc2VudHMgUlBDDQpvdXRwdXQgcGFyYW1ldGVycywgdGhlIHRy
ZWUgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgUlBDIHJl
cGx5IGluc3RhbmNlIGRvY3VtZW50LiAmbmJzcDtUaGUNClhQYXRoIHJvb3Qgbm9kZSBoYXMgdGhl
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZWxlbWVudHMgcmVwcmVz
ZW50aW5nIHRoZSBSUEMgb3V0cHV0DQpwYXJhbWV0ZXJzIGFzIGNoaWxkcmVuLjxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlZSBhbHNvIHNlY3Rpb24gNy4xMy40IG9m
IFJGQyA2MDIwIGZvciB0aGUgZW5jb2Rpbmcgb2YNClJQQ3MuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgL2pzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgT24gVHVlLCBNYXkgMjAsIDIwMTQgYXQgMDM6MDU6MThQTSArMDgwMCwgZmVuZy5j
aG9uZzMzQHp0ZS5jb20uY24NCndyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgYWxs
LDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSdtIGNvbmZ1
c2VkIHdpdGggcnBjJ3MgeHBhdGgNCmV4cHJlc3Npb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhhbXBsZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1vZHVsZSBhIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByZWZpeCBhOzxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtycGMgZm9vIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnB1dA0Kezxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IGxlYWYgZm9vMSB7Li4ufTxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvdXRwdXQNCns8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsNCiZuYnNwOyBsZWFmIGZvbzEgey4uLn08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyBUaGUgeHBhdGggb2YgdGhlIGxlYWYgbmFtZSBmb28xIGluIGZvbydzDQppbnB1
dCBpcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZxdW90O2E6Zm9vL2E6aW5wdXQvYTpmb28x
JnF1b3Q7PyBvciBpcyAmcXVvdDthOmZvby9hOmZvbzEmcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmbmJzcDsgJm5ic3A7IElmIGl0J3MgbGF0dGVyLCBob3cgdG8gZXhwcmVzcyB0aGUg
eHBhdGgNCm9mIHRoZSBsZWFmIGZvbzEgaW4gZm9vJ3MgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgb3V0cHV0Pzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEFub3RoZXIgcXVlc3Rpb24sIGhvdyB0
byBkaXN0aW5ndWlzaA0KdGhlIHhwYXRoIG9mIGRhdGFkZWYgYW5kIHRoZSA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IHhwYXRoIG9mIHJwYz88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw
OyAmbmJzcDsgRm9yIGV4YW1wbGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7IG1vZHVsZSBhIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBwcmVmaXggYTs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyBjb250YWluZXIgZm9vIHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWlu
ZXINCmlucHV0IHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyBsZWFmIGZvbzEgey4u
Ln08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cnBjIGZvbyB7
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5wdXQNCns8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN
CiZuYnNwOyBsZWFmIGZvbzEgey4uLn08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7b3V0cHV0DQp7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg
bGVhZiBmb28xIHsuLi59PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBUaGUgeHBhdGggJnF1
b3Q7YTpmb28vYTppbnB1dC9hOmZvbzEmcXVvdDsNCnBvaW50cyB0aGUgbGVhZiBmb28xIGluIGNv
bnRhaW5lciA8YnI+DQomZ3Q7ICZndDsgb3IgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUg
bGVhZiBmb28xIGluIHJwYyBmb28ncyBpbnB1dD88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgL2ZyYW5rPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog
VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0KaW4gdGhpczxicj4NCiZndDsgJmd0OyAmZ3Q7IG1h
aWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdl
ZA0KYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg
Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk
aXNjbG9zdXJlLA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp
b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2UNCm9mIHRoZSA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7
SWYgeW91DQpoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoaXMgbWFpbCBpbiBl
cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlv
biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQNCmluIHRoaXM8YnI+
DQomZ3Q7ICZndDsgJmd0OyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy
ZXdpdGgpIGlzIHByaXZpbGVnZWQNCmFuZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjb25maWRlbnRp
YWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUNCmFkZHJlc3Nl
ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5k
ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlcHJv
ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlDQpvZiB0
aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5
IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdQ0KaGF2ZSByZWNlaXZlZCA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBp
bW1lZGlhdGVseS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDwvZm9udD48L3R0
PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0
Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0
OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7DQpKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQomZ3Q7ICZndDsgJmd0
OyBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2Ft
cHVzDQpSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsgJmd0OyAmZ3Q7IEZh
eDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom
bHQ7PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8i
Pjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2ZvbnQ+
PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzPGJyPg0KJmd0OyBtYWlsIChhbmQgYW55IGF0
dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZn
dDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg
dGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRl
bmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCA8YnI+DQomZ3Q7IHJlcHJvZHVjdGlvbiwg
ZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSA8YnI+DQom
Z3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJ
ZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7IDxicj4NCiZn
dDsgLS0gPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdHbWJIPGJyPg0KJmd0
OyBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2Ft
cHVzIFJpbmcgMSwNCjI4NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsgRmF4OiAmbmJzcDsg
KzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzwvZm9udD48
L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQg
c2l6ZT0yPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0
dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHByZT48Zm9udCBj
b2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y
bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p
dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl
bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh
cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv
biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz
IGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K

--=_alternative 002AAB5C48257CDE_=--


From nobody Tue May 20 00:52:50 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913371A03F4 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhdphRGOiJov for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 00:52:47 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98231A0307 for <netmod@ietf.org>; Tue, 20 May 2014 00:52:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 674534DA; Tue, 20 May 2014 09:52:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5q-Y9eUDPdlZ; Tue, 20 May 2014 09:52:44 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 May 2014 09:52:44 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25B1020017; Tue, 20 May 2014 09:52:44 +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 NmnVb7g1I-lt; Tue, 20 May 2014 09:52:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 026BB20013; Tue, 20 May 2014 09:52:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D5C682CEAE97; Tue, 20 May 2014 09:52:41 +0200 (CEST)
Date: Tue, 20 May 2014 09:52:41 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: feng.chong33@zte.com.cn
Message-ID: <20140520075241.GA82633@elstar.local>
Mail-Followup-To: feng.chong33@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, du.baowei23@zte.com.cn, netmod@ietf.org
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <20140520071405.GA82265@elstar.local> <OF9B1D121A.93F72658-ON48257CDE.00282473-48257CDE.0028CBD0@zte.com.cn> <20140520074113.GC82265@elstar.local> <OF532EF376.C9FE1107-ON48257CDE.002A7E4F-48257CDE.002AAB5E@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <OF532EF376.C9FE1107-ON48257CDE.002A7E4F-48257CDE.002AAB5E@zte.com.cn>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HGqAgIPEvYg726Rs9NCErpq5BGU
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] =?utf-8?b?562U5aSNOiBSZTogIEEgcXVlc3Rpb24gYWJvdXQgcnBj?= =?utf-8?q?=27s_xpath?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 07:52:48 -0000

If you need an example, take a look at the routing data model. But
yes, it is something like /a:foo/a:input/a:foo1 for your initial
example (reflecting the nesting in the schema tree).

/js

On Tue, May 20, 2014 at 03:46:03PM +0800, feng.chong33@zte.com.cn wrote:
> /frank
> 
> OK. I'm wrong. But how to express rpc's absolute-schema-nodeid and 
> descendant-schema-nodeid?
> 
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> ċ†™äşŽ 
> 2014-05-20 15:41:13:
> 
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 
> > 2014-05-20 15:41
> > 
> > èŻ·ç­”ċ¤ çğ™
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > 
> > ĉ”ĥäğĥäşş
> > 
> > feng.chong33@zte.com.cn, 
> > 
> > ĉŠ„送
> > 
> > cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, 
> > du.baowei23@zte.com.cn, netmod@ietf.org
> > 
> > ä¸ğ题
> > 
> > Re: [netmod] A question about rpc's xpath
> > 
> > On Tue, May 20, 2014 at 03:25:36PM +0800, feng.chong33@zte.com.cn wrote:
> > > Juergen,
> > >      I do know it, but I want to use rpc's xpath as target node in 
> augment 
> > > or deviation.
> > 
> > No, you were asking the wrong question then. The path statement in an
> > augment has nothing to do with xpath. See section 7.15 of RFC 6020,
> > second paragraph.
> > 
> > /js
> > 
> > > So, there is no XML instance document.
> > > 
> > > For example:
> > > 
> > > module b {
> > >     prefix b;
> > >     import a {
> > >         prefix a;
> > >     }
> > > 
> > >     augment "a:foo/a:input" {
> > >           leaf foo2 {...}
> > >     }
> > > }
> > > 
> > > Which node is the target node of this augument? the input in container 
> foo 
> > > or the input in rpc foo?
> > > 
> > > /frank
> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> ċ†™äşŽ 
> > > 2014-05-20 15:14:07:
> > > 
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 
> > > > 2014-05-20 15:14
> > > > 
> > > > èŻ·ç­”ċ¤ çğ™
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > > > 
> > > > ĉ”ĥäğĥäşş
> > > > 
> > > > feng.chong33@zte.com.cn, 
> > > > 
> > > > ĉŠ„送
> > > > 
> > > > netmod@ietf.org, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, 
> > > > dai.xianxian@zte.com.cn
> > > > 
> > > > ä¸ğ题
> > > > 
> > > > Re: [netmod] A question about rpc's xpath
> > > > 
> > > > See section 7.5.3 of RFC 6020:
> > > > 
> > > >    o  If the context node represents RPC input parameters, the tree 
> is
> > > >       the RPC XML instance document.  The XPath root node has the
> > > >       element representing the RPC operation being defined as the 
> only
> > > >       child.
> > > > 
> > > >    o  If the context node represents RPC output parameters, the tree 
> is
> > > >       the RPC reply instance document.  The XPath root node has the
> > > >       elements representing the RPC output parameters as children.
> > > > 
> > > > See also section 7.13.4 of RFC 6020 for the encoding of RPCs.
> > > > 
> > > > /js
> > > > 
> > > > On Tue, May 20, 2014 at 03:05:18PM +0800, feng.chong33@zte.com.cn 
> wrote:
> > > > > Hi all,
> > > > >       I'm confused with rpc's xpath expression.
> > > > >       For example:
> > > > >       module a {
> > > > >             prefix a;
> > > > >            rpc foo {
> > > > >                input {
> > > > >                   leaf foo1 {...}
> > > > >                }
> > > > >                output {
> > > > >                   leaf foo1 {...}
> > > > >                }
> > > > >            }
> > > > >       }
> > > > > 
> > > > >     The xpath of the leaf name foo1 in foo's input is 
> > > > > "a:foo/a:input/a:foo1"? or is "a:foo/a:foo1"?
> > > > >     If it's latter, how to express the xpath of the leaf foo1 in 
> foo's 
> > > 
> > > > > output?
> > > > > 
> > > > >     Another question, how to distinguish the xpath of datadef and 
> the 
> > > > > xpath of rpc?
> > > > >     For example:
> > > > >     module a {
> > > > >         prefix a;
> > > > >         container foo {
> > > > >               container input {
> > > > >                   leaf foo1 {...}
> > > > >               }
> > > > >         }
> > > > > 
> > > > >          rpc foo {
> > > > >                input {
> > > > >                   leaf foo1 {...}
> > > > >                }
> > > > >                output {
> > > > >                   leaf foo1 {...}
> > > > >                }
> > > > >            }
> > > > >     }
> > > > > 
> > > > >     The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in 
> container 
> > > or 
> > > > > the leaf foo1 in rpc foo's input?
> > > > > 
> > > > > /frank
> > > > > --------------------------------------------------------
> > > > > ZTE Information Security Notice: The information contained in this
> > > > mail (and any attachment transmitted herewith) is privileged and 
> > > > confidential and is intended for the exclusive use of the addressee
> > > > (s).  If you are not an intended recipient, any disclosure, 
> > > > reproduction, distribution or other dissemination or use of the 
> > > > information contained is strictly prohibited.  If you have received 
> > > > this mail in error, please delete it and notify us immediately.
> > > > > --------------------------------------------------------
> > > > > ZTE Information Security Notice: The information contained in this
> > > > mail (and any attachment transmitted herewith) is privileged and 
> > > > confidential and is intended for the exclusive use of the addressee
> > > > (s).  If you are not an intended recipient, any disclosure, 
> > > > reproduction, distribution or other dissemination or use of the 
> > > > information contained is strictly prohibited.  If you have received 
> > > > this mail in error, please delete it and notify us immediately.
> > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > 
> > > > -- 
> > > > 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/>
> > > 
> > > --------------------------------------------------------
> > > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and 
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure, 
> > reproduction, distribution or other dissemination or use of the 
> > information contained is strictly prohibited.  If you have received 
> > this mail in error, please delete it and notify us immediately.
> > 
> > -- 
> > 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/>
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

-- 
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 nobody Tue May 20 01:12:42 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E761A045D for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.1
X-Spam-Level: 
X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK2vzBUgWlCr for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:12:34 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A36431A0309 for <netmod@ietf.org>; Tue, 20 May 2014 01:12:33 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 0FC7A12AE6C7; Tue, 20 May 2014 16:12:18 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4K8CEW7003780; Tue, 20 May 2014 16:12:14 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140520075241.GA82633@elstar.local>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <20140520071405.GA82265@elstar.local> <OF9B1D121A.93F72658-ON48257CDE.00282473-48257CDE.0028CBD0@zte.com.cn> <20140520074113.GC82265@elstar.local> <OF532EF376.C9FE1107-ON48257CDE.002A7E4F-48257CDE.002AAB5E@zte.com.cn> <20140520075241.GA82633@elstar.local>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
MIME-Version: 1.0
X-KeepSent: 7AB3FA2F:8743D3E4-48257CDE:002C3AB9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF7AB3FA2F.8743D3E4-ON48257CDE.002C3AB9-48257CDE.002D11D2@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 16:12:16 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 16:12:17, Serialize complete at 2014-05-20 16:12:17
Content-Type: multipart/alternative; boundary="=_alternative 002D11D048257CDE_="
X-MAIL: mse02.zte.com.cn s4K8CEW7003780
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BX6UaloNYBce7TmTVQBrTOcE1_0
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:12:37 -0000

This is a multipart message in MIME format.

--=_alternative 002D11D048257CDE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SSBoYXZlIGxvb2tlZCB0aHJvdWdoIHJvdXRpbmcgZGF0YSBtb2RlbC4gQnV0IHRoaXMgZXhhbXBs
ZSBjYW4ndCByZXNvbHZlIA0KbXkgcXVlc3Rpb24uDQoNCklmIGEgbW9kdWxlIGRlZmluZWQgYSBj
b250YWluZXIgaGFzIGEgc2FtZSBuYW1lIHdpdGggcnBjLCBhbmQgdGhpcyANCmNvbnRhaW5lciBo
YXMgYSBjaGlsZCBuYW1lZCAnaW5wdXQnLA0KdGhlc2UgdHdvICdpbnB1dCdzIGhhdmUgdGhlIHNh
bWUgYWJzb2x1dGUtc2NoZW1hLW5vZGVpZC4NCg0KDQoNCg0KL2ZyYW5rDQoNCkp1ZXJnZW4gU2No
b2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiDQtNPaIA0K
MjAxNC0wNS0yMCAxNTo1Mjo0MToNCg0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vu
d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQo+IDIwMTQtMDUtMjAgMTU6NTINCj4gDQo+
IMfrtPC4tCC4+A0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv
YnMtdW5pdmVyc2l0eS5kZT4NCj4gDQo+IMrVvP7Iyw0KPiANCj4gZmVuZy5jaG9uZzMzQHp0ZS5j
b20uY24sIA0KPiANCj4gs63LzQ0KPiANCj4gY2hlbmcuemh1MUB6dGUuY29tLmNuLCBkYWkueGlh
bnhpYW5AenRlLmNvbS5jbiwgDQo+IGR1LmJhb3dlaTIzQHp0ZS5jb20uY24sIG5ldG1vZEBpZXRm
Lm9yZw0KPiANCj4g1vfM4g0KPiANCj4gUmU6ILTwuLQ6IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9u
IGFib3V0IHJwYydzIHhwYXRoDQo+IA0KPiBJZiB5b3UgbmVlZCBhbiBleGFtcGxlLCB0YWtlIGEg
bG9vayBhdCB0aGUgcm91dGluZyBkYXRhIG1vZGVsLiBCdXQNCj4geWVzLCBpdCBpcyBzb21ldGhp
bmcgbGlrZSAvYTpmb28vYTppbnB1dC9hOmZvbzEgZm9yIHlvdXIgaW5pdGlhbA0KPiBleGFtcGxl
IChyZWZsZWN0aW5nIHRoZSBuZXN0aW5nIGluIHRoZSBzY2hlbWEgdHJlZSkuDQo+IA0KPiAvanMN
Cj4gDQo+IE9uIFR1ZSwgTWF5IDIwLCAyMDE0IGF0IDAzOjQ2OjAzUE0gKzA4MDAsIGZlbmcuY2hv
bmczM0B6dGUuY29tLmNuIHdyb3RlOg0KPiA+IC9mcmFuaw0KPiA+IA0KPiA+IE9LLiBJJ20gd3Jv
bmcuIEJ1dCBob3cgdG8gZXhwcmVzcyBycGMncyBhYnNvbHV0ZS1zY2hlbWEtbm9kZWlkIGFuZCAN
Cj4gPiBkZXNjZW5kYW50LXNjaGVtYS1ub2RlaWQ/DQo+ID4gDQo+ID4gSnVlcmdlbiBTY2hvZW53
YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+INC009ogDQo+ID4g
MjAxNC0wNS0yMCAxNTo0MToxMzoNCj4gPiANCj4gPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCj4gPiA+IDIwMTQtMDUtMjAg
MTU6NDENCj4gPiA+IA0KPiA+ID4gx+u08Li0ILj4DQo+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxk
ZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gPiA+IA0KPiA+ID4g
ytW8/sjLDQo+ID4gPiANCj4gPiA+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCANCj4gPiA+IA0K
PiA+ID4gs63LzQ0KPiA+ID4gDQo+ID4gPiBjaGVuZy56aHUxQHp0ZS5jb20uY24sIGRhaS54aWFu
eGlhbkB6dGUuY29tLmNuLCANCj4gPiA+IGR1LmJhb3dlaTIzQHp0ZS5jb20uY24sIG5ldG1vZEBp
ZXRmLm9yZw0KPiA+ID4gDQo+ID4gPiDW98ziDQo+ID4gPiANCj4gPiA+IFJlOiBbbmV0bW9kXSBB
IHF1ZXN0aW9uIGFib3V0IHJwYydzIHhwYXRoDQo+ID4gPiANCj4gPiA+IE9uIFR1ZSwgTWF5IDIw
LCAyMDE0IGF0IDAzOjI1OjM2UE0gKzA4MDAsIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuIA0Kd3Jv
dGU6DQo+ID4gPiA+IEp1ZXJnZW4sDQo+ID4gPiA+ICAgICAgSSBkbyBrbm93IGl0LCBidXQgSSB3
YW50IHRvIHVzZSBycGMncyB4cGF0aCBhcyB0YXJnZXQgbm9kZSBpbiANCg0KPiA+IGF1Z21lbnQg
DQo+ID4gPiA+IG9yIGRldmlhdGlvbi4NCj4gPiA+IA0KPiA+ID4gTm8sIHlvdSB3ZXJlIGFza2lu
ZyB0aGUgd3JvbmcgcXVlc3Rpb24gdGhlbi4gVGhlIHBhdGggc3RhdGVtZW50IGluIA0KYW4NCj4g
PiA+IGF1Z21lbnQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB4cGF0aC4gU2VlIHNlY3Rpb24gNy4x
NSBvZiBSRkMgNjAyMCwNCj4gPiA+IHNlY29uZCBwYXJhZ3JhcGguDQo+ID4gPiANCj4gPiA+IC9q
cw0KPiA+ID4gDQo+ID4gPiA+IFNvLCB0aGVyZSBpcyBubyBYTUwgaW5zdGFuY2UgZG9jdW1lbnQu
DQo+ID4gPiA+IA0KPiA+ID4gPiBGb3IgZXhhbXBsZToNCj4gPiA+ID4gDQo+ID4gPiA+IG1vZHVs
ZSBiIHsNCj4gPiA+ID4gICAgIHByZWZpeCBiOw0KPiA+ID4gPiAgICAgaW1wb3J0IGEgew0KPiA+
ID4gPiAgICAgICAgIHByZWZpeCBhOw0KPiA+ID4gPiAgICAgfQ0KPiA+ID4gPiANCj4gPiA+ID4g
ICAgIGF1Z21lbnQgImE6Zm9vL2E6aW5wdXQiIHsNCj4gPiA+ID4gICAgICAgICAgIGxlYWYgZm9v
MiB7Li4ufQ0KPiA+ID4gPiAgICAgfQ0KPiA+ID4gPiB9DQo+ID4gPiA+IA0KPiA+ID4gPiBXaGlj
aCBub2RlIGlzIHRoZSB0YXJnZXQgbm9kZSBvZiB0aGlzIGF1Z3VtZW50PyB0aGUgaW5wdXQgaW4g
DQpjb250YWluZXIgDQo+ID4gZm9vIA0KPiA+ID4gPiBvciB0aGUgaW5wdXQgaW4gcnBjIGZvbz8N
Cj4gPiA+ID4gDQo+ID4gPiA+IC9mcmFuaw0KPiA+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg
PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4g0LTT2iANCj4gPiA+ID4gMjAx
NC0wNS0yMCAxNToxNDowNzoNCj4gPiA+ID4gDQo+ID4gPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVs
ZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IA0KPiA+ID4gPiA+IDIw
MTQtMDUtMjAgMTU6MTQNCj4gPiA+ID4gPiANCj4gPiA+ID4gPiDH67TwuLQguPgNCj4gPiA+ID4g
PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZT4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiDK1bz+yMsNCj4gPiA+ID4gPiANCj4gPiA+ID4g
PiBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gs63LzQ0K
PiA+ID4gPiA+IA0KPiA+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZywgZHUuYmFvd2VpMjNAenRlLmNv
bS5jbiwgY2hlbmcuemh1MUB6dGUuY29tLmNuLCANCj4gPiA+ID4gPiBkYWkueGlhbnhpYW5AenRl
LmNvbS5jbg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+INb3zOINCj4gPiA+ID4gPiANCj4gPiA+ID4g
PiBSZTogW25ldG1vZF0gQSBxdWVzdGlvbiBhYm91dCBycGMncyB4cGF0aA0KPiA+ID4gPiA+IA0K
PiA+ID4gPiA+IFNlZSBzZWN0aW9uIDcuNS4zIG9mIFJGQyA2MDIwOg0KPiA+ID4gPiA+IA0KPiA+
ID4gPiA+ICAgIG8gIElmIHRoZSBjb250ZXh0IG5vZGUgcmVwcmVzZW50cyBSUEMgaW5wdXQgcGFy
YW1ldGVycywgdGhlIA0KdHJlZSANCj4gPiBpcw0KPiA+ID4gPiA+ICAgICAgIHRoZSBSUEMgWE1M
IGluc3RhbmNlIGRvY3VtZW50LiAgVGhlIFhQYXRoIHJvb3Qgbm9kZSBoYXMgDQp0aGUNCj4gPiA+
ID4gPiAgICAgICBlbGVtZW50IHJlcHJlc2VudGluZyB0aGUgUlBDIG9wZXJhdGlvbiBiZWluZyBk
ZWZpbmVkIGFzIA0KdGhlIA0KPiA+IG9ubHkNCj4gPiA+ID4gPiAgICAgICBjaGlsZC4NCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiAgICBvICBJZiB0aGUgY29udGV4dCBub2RlIHJlcHJlc2VudHMgUlBD
IG91dHB1dCBwYXJhbWV0ZXJzLCB0aGUgDQp0cmVlIA0KPiA+IGlzDQo+ID4gPiA+ID4gICAgICAg
dGhlIFJQQyByZXBseSBpbnN0YW5jZSBkb2N1bWVudC4gIFRoZSBYUGF0aCByb290IG5vZGUgaGFz
IA0KdGhlDQo+ID4gPiA+ID4gICAgICAgZWxlbWVudHMgcmVwcmVzZW50aW5nIHRoZSBSUEMgb3V0
cHV0IHBhcmFtZXRlcnMgYXMgDQpjaGlsZHJlbi4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBTZWUg
YWxzbyBzZWN0aW9uIDcuMTMuNCBvZiBSRkMgNjAyMCBmb3IgdGhlIGVuY29kaW5nIG9mIFJQQ3Mu
DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gL2pzDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gT24gVHVl
LCBNYXkgMjAsIDIwMTQgYXQgMDM6MDU6MThQTSArMDgwMCwgDQpmZW5nLmNob25nMzNAenRlLmNv
bS5jbiANCj4gPiB3cm90ZToNCj4gPiA+ID4gPiA+IEhpIGFsbCwNCj4gPiA+ID4gPiA+ICAgICAg
IEknbSBjb25mdXNlZCB3aXRoIHJwYydzIHhwYXRoIGV4cHJlc3Npb24uDQo+ID4gPiA+ID4gPiAg
ICAgICBGb3IgZXhhbXBsZToNCj4gPiA+ID4gPiA+ICAgICAgIG1vZHVsZSBhIHsNCj4gPiA+ID4g
PiA+ICAgICAgICAgICAgIHByZWZpeCBhOw0KPiA+ID4gPiA+ID4gICAgICAgICAgICBycGMgZm9v
IHsNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgIGlucHV0IHsNCj4gPiA+ID4gPiA+ICAgICAg
ICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg
fQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAgb3V0cHV0IHsNCj4gPiA+ID4gPiA+ICAgICAg
ICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICAgICAg
fQ0KPiA+ID4gPiA+ID4gICAgICAgICAgICB9DQo+ID4gPiA+ID4gPiAgICAgICB9DQo+ID4gPiA+
ID4gPiANCj4gPiA+ID4gPiA+ICAgICBUaGUgeHBhdGggb2YgdGhlIGxlYWYgbmFtZSBmb28xIGlu
IGZvbydzIGlucHV0IGlzIA0KPiA+ID4gPiA+ID4gImE6Zm9vL2E6aW5wdXQvYTpmb28xIj8gb3Ig
aXMgImE6Zm9vL2E6Zm9vMSI/DQo+ID4gPiA+ID4gPiAgICAgSWYgaXQncyBsYXR0ZXIsIGhvdyB0
byBleHByZXNzIHRoZSB4cGF0aCBvZiB0aGUgbGVhZiBmb28xIA0KaW4gDQo+ID4gZm9vJ3MgDQo+
ID4gPiA+IA0KPiA+ID4gPiA+ID4gb3V0cHV0Pw0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAg
ICAgQW5vdGhlciBxdWVzdGlvbiwgaG93IHRvIGRpc3Rpbmd1aXNoIHRoZSB4cGF0aCBvZiBkYXRh
ZGVmIA0KYW5kIA0KPiA+IHRoZSANCj4gPiA+ID4gPiA+IHhwYXRoIG9mIHJwYz8NCj4gPiA+ID4g
PiA+ICAgICBGb3IgZXhhbXBsZToNCj4gPiA+ID4gPiA+ICAgICBtb2R1bGUgYSB7DQo+ID4gPiA+
ID4gPiAgICAgICAgIHByZWZpeCBhOw0KPiA+ID4gPiA+ID4gICAgICAgICBjb250YWluZXIgZm9v
IHsNCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgY29udGFpbmVyIGlucHV0IHsNCj4gPiA+ID4g
PiA+ICAgICAgICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufQ0KPiA+ID4gPiA+ID4gICAgICAg
ICAgICAgICB9DQo+ID4gPiA+ID4gPiAgICAgICAgIH0NCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+
ID4gICAgICAgICAgcnBjIGZvbyB7DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICBpbnB1dCB7
DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICBsZWFmIGZvbzEgey4uLn0NCj4gPiA+ID4g
PiA+ICAgICAgICAgICAgICAgIH0NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgIG91dHB1dCB7
DQo+ID4gPiA+ID4gPiAgICAgICAgICAgICAgICAgICBsZWFmIGZvbzEgey4uLn0NCj4gPiA+ID4g
PiA+ICAgICAgICAgICAgICAgIH0NCj4gPiA+ID4gPiA+ICAgICAgICAgICAgfQ0KPiA+ID4gPiA+
ID4gICAgIH0NCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gICAgIFRoZSB4cGF0aCAiYTpmb28v
YTppbnB1dC9hOmZvbzEiIHBvaW50cyB0aGUgbGVhZiBmb28xIGluIA0KPiA+IGNvbnRhaW5lciAN
Cj4gPiA+ID4gb3IgDQo+ID4gPiA+ID4gPiB0aGUgbGVhZiBmb28xIGluIHJwYyBmb28ncyBpbnB1
dD8NCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gL2ZyYW5rDQo+ID4gPiA+ID4gPiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4g
PiA+ID4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv
bnRhaW5lZCBpbiANCnRoaXMNCj4gPiA+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh
bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KDQo+ID4gPiA+ID4gY29uZmlk
ZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIA0KYWRk
cmVzc2VlDQo+ID4gPiA+ID4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBp
ZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+ID4gPiA+ID4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp
b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiA+ID4gPiA+IGluZm9y
bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgDQpy
ZWNlaXZlZCANCj4gPiA+ID4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQg
YW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiA+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPiBaVEUg
SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu
IA0KdGhpcw0KPiA+ID4gPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBo
ZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQoNCj4gPiA+ID4gPiBjb25maWRlbnRpYWwgYW5k
IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgDQphZGRyZXNzZWUNCj4g
PiA+ID4gPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk
aXNjbG9zdXJlLCANCj4gPiA+ID4gPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl
ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgDQo+ID4gPiA+ID4gaW5mb3JtYXRpb24gY29u
dGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSANCnJlY2VpdmVkIA0K
PiA+ID4gPiA+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5
IHVzIGltbWVkaWF0ZWx5Lg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+IG5ldG1vZCBtYWls
aW5nIGxpc3QNCj4gPiA+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+ID4gPiANCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiAtLSANCj4gPiA+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAg
ICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+ID4gPiA+IFBob25lOiAr
NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCANCkdl
cm1hbnkNCj4gPiA+ID4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDwNCmh0dHA6
Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+ID4gPiANCj4gPiA+ID4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4g
WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpbiB0aGlzDQo+ID4gPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy
ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiA+ID4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl
bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiA+ID4gKHMpLiAg
SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+
ID4gPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y
IHVzZSBvZiB0aGUgDQo+ID4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv
aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiA+ID4gdGhpcyBtYWlsIGluIGVycm9y
LCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+ID4gPiANCj4g
PiA+IC0tIA0KPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p
dmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAg
ICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+ID4gPiBGYXg6ICAgKzQ5
IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4N
Cj4gPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KPiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv
cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh
bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5k
IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChz
KS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUs
IA0KPiByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y
IHVzZSBvZiB0aGUgDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp
dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl
IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiANCj4gLS0gDQo+IEp1ZXJn
ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI
DQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkg
QnJlbWVuLCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6
Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5
IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkg
YXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlk
ZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJl
c3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Ns
b3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24g
b3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRl
ZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0
ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K

--=_alternative 002D11D048257CDE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBsb29rZWQgdGhyb3VnaCByb3V0
aW5nIGRhdGEgbW9kZWwuDQpCdXQgdGhpcyBleGFtcGxlIGNhbid0IHJlc29sdmUgbXkgcXVlc3Rp
b24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBh
IG1vZHVsZSBkZWZpbmVkIGEgY29udGFpbmVyIGhhcw0KYSBzYW1lIG5hbWUgd2l0aCBycGMsIGFu
ZCB0aGlzIGNvbnRhaW5lciBoYXMgYSBjaGlsZCBuYW1lZCAnaW5wdXQnLDwvZm9udD4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlc2UgdHdvICdpbnB1dCdzIGhhdmUgdGhl
IHNhbWUgPC9mb250Pjx0dD48Zm9udCBzaXplPTI+YWJzb2x1dGUtc2NoZW1hLW5vZGVpZDwvZm9u
dD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4uPC9mb250Pg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4vZnJhbms8
L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIg
Jmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCtC009ogMjAxNC0w
NS0yMCAxNTo1Mjo0MTo8YnI+DQo8YnI+DQomZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Ow0KPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIwMTQtMDUtMjAgMTU6NTI8L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDH67TwuLQguPg8YnI+DQomZ3Q7IEp1
ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5
LmRlJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7
IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7
IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgY2hlbmcuemh1MUB6dGUuY29tLmNuLCBkYWkueGlhbnhpYW5AenRl
LmNvbS5jbiwgPGJyPg0KJmd0OyBkdS5iYW93ZWkyM0B6dGUuY29tLmNuLCBuZXRtb2RAaWV0Zi5v
cmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98zi
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgUmU6ILTw
uLQ6IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9uIGFib3V0IHJwYydzIHhwYXRoPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSWYgeW91IG5lZWQgYW4gZXhh
bXBsZSwgdGFrZSBhIGxvb2sgYXQgdGhlIHJvdXRpbmcgZGF0YSBtb2RlbC4gQnV0PGJyPg0KJmd0
OyB5ZXMsIGl0IGlzIHNvbWV0aGluZyBsaWtlIC9hOmZvby9hOmlucHV0L2E6Zm9vMSBmb3IgeW91
ciBpbml0aWFsPGJyPg0KJmd0OyBleGFtcGxlIChyZWZsZWN0aW5nIHRoZSBuZXN0aW5nIGluIHRo
ZSBzY2hlbWEgdHJlZSkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9qczxicj4NCiZndDsgPGJyPg0K
Jmd0OyBPbiBUdWUsIE1heSAyMCwgMjAxNCBhdCAwMzo0NjowM1BNICswODAwLCBmZW5nLmNob25n
MzNAenRlLmNvbS5jbg0Kd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IC9mcmFuazxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgT0suIEknbSB3cm9uZy4gQnV0IGhvdyB0byBleHByZXNzIHJwYydz
IGFic29sdXRlLXNjaGVtYS1ub2RlaWQNCmFuZCA8YnI+DQomZ3Q7ICZndDsgZGVzY2VuZGFudC1z
Y2hlbWEtbm9kZWlkPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSnVlcmdlbiBTY2hv
ZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQrQ
tNPaIDxicj4NCiZndDsgJmd0OyAyMDE0LTA1LTIwIDE1OjQxOjEzOjxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2Fl
bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IDIwMTQt
MDUtMjAgMTU6NDE8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDH67Tw
uLQguPg8YnI+DQomZ3Q7ICZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyBmZW5nLmNob25nMzNAenRlLmNvbS5jbiwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgs63LzTxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IGNoZW5nLnpodTFAenRlLmNvbS5jbiwgZGFpLnhpYW54aWFuQHp0ZS5jb20uY24s
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGR1LmJhb3dlaTIzQHp0ZS5jb20uY24sIG5ldG1vZEBpZXRm
Lm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7INb3zOI8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBSZTogW25ldG1vZF0gQSBxdWVzdGlv
biBhYm91dCBycGMncyB4cGF0aDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IE9uIFR1ZSwgTWF5IDIwLCAyMDE0IGF0IDAzOjI1OjM2UE0gKzA4MDAsIGZlbmcuY2hvbmcz
M0B6dGUuY29tLmNuDQp3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEp1ZXJnZW4sPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0kgZG8ga25vdyBpdCwg
YnV0IEkgd2FudCB0byB1c2UNCnJwYydzIHhwYXRoIGFzIHRhcmdldCBub2RlIGluIDxicj4NCiZn
dDsgJmd0OyBhdWdtZW50IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb3IgZGV2aWF0aW9uLjxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5vLCB5b3Ugd2VyZSBhc2tp
bmcgdGhlIHdyb25nIHF1ZXN0aW9uIHRoZW4uIFRoZSBwYXRoIHN0YXRlbWVudA0KaW4gYW48YnI+
DQomZ3Q7ICZndDsgJmd0OyBhdWdtZW50IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggeHBhdGguIFNl
ZSBzZWN0aW9uIDcuMTUgb2YNClJGQyA2MDIwLDxicj4NCiZndDsgJmd0OyAmZ3Q7IHNlY29uZCBw
YXJhZ3JhcGguPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgL2pzPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBTbywgdGhlcmUgaXMg
bm8gWE1MIGluc3RhbmNlIGRvY3VtZW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGb3IgZXhhbXBsZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbW9kdWxlIGIgezxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwOyBwcmVmaXggYjs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDsgaW1wb3J0IGEgezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IHByZWZpeCBhOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgYXVnbWVudCAmcXVvdDthOmZvby9hOmlucHV0JnF1b3Q7IHs8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgbGVhZiBmb28yIHsuLi59PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7
IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgV2hpY2ggbm9kZSBpcyB0aGUgdGFyZ2V0IG5vZGUgb2Yg
dGhpcyBhdWd1bWVudD8gdGhlDQppbnB1dCBpbiBjb250YWluZXIgPGJyPg0KJmd0OyAmZ3Q7IGZv
byA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9yIHRoZSBpbnB1dCBpbiBycGMgZm9vPzxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAvZnJhbms8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53
YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Ow0K0LTT2iA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IDIwMTQtMDUtMjAgMTU6MTQ6MDc6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNj
aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgMjAxNC0wNS0yMCAxNToxNDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgx+u08Li0ILj4PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgytW8/sjLPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBmZW5nLmNob25nMzNAenRl
LmNvbS5jbiwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyCzrcvNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZXRtb2RAaWV0Zi5vcmcsIGR1LmJhb3dlaTIzQHp0ZS5j
b20uY24sIGNoZW5nLnpodTFAenRlLmNvbS5jbiwNCjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBkYWkueGlhbnhpYW5AenRlLmNvbS5jbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg1vfM4jxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgUmU6IFtuZXRtb2RdIEEg
cXVlc3Rpb24gYWJvdXQgcnBjJ3MgeHBhdGg8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlZSBzZWN0aW9uIDcuNS4zIG9mIFJGQyA2
MDIwOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7SWYgdGhlIGNvbnRleHQgbm9kZSByZXByZXNl
bnRzDQpSUEMgaW5wdXQgcGFyYW1ldGVycywgdGhlIHRyZWUgPGJyPg0KJmd0OyAmZ3Q7IGlzPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBSUEMg
WE1MIGluc3RhbmNlIGRvY3VtZW50Lg0KJm5ic3A7VGhlIFhQYXRoIHJvb3Qgbm9kZSBoYXMgdGhl
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVsZW1l
bnQgcmVwcmVzZW50aW5nIHRoZQ0KUlBDIG9wZXJhdGlvbiBiZWluZyBkZWZpbmVkIGFzIHRoZSA8
YnI+DQomZ3Q7ICZndDsgb25seTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBjaGlsZC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtvICZuYnNwO0lmIHRoZSBjb250
ZXh0IG5vZGUgcmVwcmVzZW50cw0KUlBDIG91dHB1dCBwYXJhbWV0ZXJzLCB0aGUgdHJlZSA8YnI+
DQomZ3Q7ICZndDsgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgdGhlIFJQQyByZXBseSBpbnN0YW5jZSBkb2N1bWVudC4NCiZuYnNwO1RoZSBYUGF0
aCByb290IG5vZGUgaGFzIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBlbGVtZW50cyByZXByZXNlbnRpbmcgdGhlDQpSUEMgb3V0cHV0IHBhcmFt
ZXRlcnMgYXMgY2hpbGRyZW4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZWUgYWxzbyBzZWN0aW9uIDcuMTMuNCBvZiBSRkMgNjAy
MCBmb3IgdGhlIGVuY29kaW5nDQpvZiBSUENzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgL2pzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBUdWUsIE1heSAyMCwg
MjAxNCBhdCAwMzowNToxOFBNICswODAwLCBmZW5nLmNob25nMzNAenRlLmNvbS5jbg0KPGJyPg0K
Jmd0OyAmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpIGFs
bCw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyBJJ20gY29uZnVzZWQgd2l0aCBycGMncw0KeHBhdGggZXhwcmVzc2lvbi48YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhhbXBsZTo8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBt
b2R1bGUgYSB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnByZWZpeCBhOzxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7cnBjDQpmb28gezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7aW5wdXQgezxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmIGZvbzEgey4uLn08
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K
Jm5ic3A7ICZuYnNwO291dHB1dCB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg
Jm5ic3A7IGxlYWYgZm9vMSB7Li4ufTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7
fTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IFRoZSB4
cGF0aCBvZiB0aGUgbGVhZiBuYW1lDQpmb28xIGluIGZvbydzIGlucHV0IGlzIDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZxdW90O2E6Zm9vL2E6aW5wdXQvYTpmb28xJnF1b3Q7
PyBvciBpcyAmcXVvdDthOmZvby9hOmZvbzEmcXVvdDs/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBJZiBpdCdzIGxhdHRlciwgaG93IHRvIGV4cHJlc3MN
CnRoZSB4cGF0aCBvZiB0aGUgbGVhZiBmb28xIGluIDxicj4NCiZndDsgJmd0OyBmb28ncyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IG91dHB1dD88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEFub3RoZXIgcXVlc3Rpb24sIGhv
dyB0byBkaXN0aW5ndWlzaA0KdGhlIHhwYXRoIG9mIGRhdGFkZWYgYW5kIDxicj4NCiZndDsgJmd0
OyB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgeHBhdGggb2YgcnBjPzxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1w
bGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBtb2R1
bGUgYSB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IHByZWZpeCBhOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWluZXIgZm9vDQp7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsNCiZuYnNwOyBjb250YWluZXIgaW5wdXQgezxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom
bmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmIGZvbzEgey4uLn08YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K
Jm5ic3A7IH08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtycGMgZm9vDQp7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDtpbnB1
dCB7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYgZm9vMSB7
Li4ufTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7fTxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7DQombmJzcDsgJm5ic3A7b3V0cHV0IHs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu
YnNwOyAmbmJzcDsgbGVhZiBmb28xIHsuLi59PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm
bmJzcDt9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwOyB9PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBUaGUgeHBh
dGggJnF1b3Q7YTpmb28vYTppbnB1dC9hOmZvbzEmcXVvdDsNCnBvaW50cyB0aGUgbGVhZiBmb28x
IGluIDxicj4NCiZndDsgJmd0OyBjb250YWluZXIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBv
ciA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgbGVhZiBmb28xIGluIHJw
YyBmb28ncyBpbnB1dD88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAvZnJhbms8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFpURSBJbmZv
cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbg0KY29udGFpbmVkIGluIHRo
aXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50
IHRyYW5zbWl0dGVkIGhlcmV3aXRoKQ0KaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs
dXNpdmUNCnVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LA0KYW55IGRp
c2Nsb3N1cmUsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXByb2R1Y3Rpb24sIGRp
c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uDQpvciB1c2Ugb2YgdGhlIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZC4NCiZuYnNwO0lmIHlvdSBoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v
dGlmeQ0KdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJp
dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24NCmNvbnRhaW5lZCBpbiB0aGlzPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBo
ZXJld2l0aCkNCmlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlDQp1c2Ugb2Yg
dGhlIGFkZHJlc3NlZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAocykuICZuYnNwO0lm
IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwNCmFueSBkaXNjbG9zdXJlLCA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Ig
b3RoZXIgZGlzc2VtaW5hdGlvbg0Kb3IgdXNlIG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuDQom
bmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
dGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkNCnVzIGltbWVk
aWF0ZWx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5ldG1vZCBtYWlsaW5n
IGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZXRtb2RAaWV0Zi5vcmc8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPjx0dD48Zm9udCBzaXpl
PTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2ZvbnQ+PC90
dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAtLSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVy
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IEphY29icyBVbml2ZXJzaXR5IEJy
ZW1lbiBnR21iSDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQaG9uZTogKzQ5IDQyMSAy
MDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkNhbXB1cyBSaW5nIDEsIDI4NzU5
IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBGYXg6ICZuYnNw
OyArNDkgNDIxIDIwMCAzMTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJmx0OzwvZm9u
dD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZv
bnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9h
Pjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9u
IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZA0KaW4gdGhpczxicj4N
CiZndDsgJmd0OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJl
d2l0aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmZpZGVudGlh
bCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KYWRkcmVzc2Vl
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRl
ZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLA0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVwcm9k
dWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2UNCm9mIHRo
ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZC4gJm5ic3A7SWYgeW91DQpoYXZlIHJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyAm
Z3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGlt
bWVkaWF0ZWx5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7DQpKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+DQom
Z3Q7ICZndDsgJmd0OyBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgQ2FtcHVzDQpSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsg
Jmd0OyAmZ3Q7IEZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7DQombHQ7PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5p
dmVyc2l0eS5kZS8iPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0
eS5kZS88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg
Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluDQp0aGlzPGJyPg0KJmd0OyBtYWls
IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg
YW5kIDxicj4NCiZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1
c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAmbmJzcDtJZiB5b3UgYXJl
IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCA8YnI+DQomZ3Q7IHJl
cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m
IHRoZSA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp
dGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0OyB0aGlzIG1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQom
Z3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdH
bWJIPGJyPg0KJmd0OyBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwNCjI4NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsg
RmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jmx0OzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv
Ij48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250
PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+
PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGlj
ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNo
bWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFs
IGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShz
KS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUs
IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNl
IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElm
IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBh
bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K

--=_alternative 002D11D048257CDE_=--


From nobody Tue May 20 01:14:38 2014
Return-Path: <jernej.tuljak@mg-soft.si>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CA91A03F4 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.95
X-Spam-Level: 
X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS_nGRS6lc8d for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:14:28 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB351A04A1 for <netmod@ietf.org>; Tue, 20 May 2014 01:14:27 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s4K8EPwT003043; Tue, 20 May 2014 10:14:25 +0200
Message-ID: <537B0EE0.5070601@mg-soft.com>
Date: Tue, 20 May 2014 10:14:24 +0200
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: feng.chong33@zte.com.cn
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn>
In-Reply-To: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn>
Content-Type: multipart/alternative; boundary="------------010008090107060107040200"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Uiu78vmWjKj9umn5LzHJJezv2HY
Cc: dai.xianxian@zte.com.cn, cheng.zhu1@zte.com.cn, du.baowei23@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:14:31 -0000

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

Dne 20.5.2014 9:05, pis(e feng.chong33@zte.com.cn:
> Hi all,
>       I'm confused with rpc's xpath expression.
>       For example:
>       module a {
>   prefix a;
>            rpc foo {
>    input {
>       leaf foo1 {...}
>    }
>    output {
>       leaf foo1 {...}
>    }
>            }
>       }
>
>     The xpath of the leaf name foo1 in foo's input is 
> "a:foo/a:input/a:foo1"? or is "a:foo/a:foo1"?
>     If it's latter, how to express the xpath of the leaf foo1 in foo's 
> output?

In order to augment/deviate your RPC, you need to use an absolute schema 
node identifier, not XPath.
/a:foo/a:input
/a:foo/a:output

Schema node identifiers identify schema nodes - nodes of the schema 
tree. Their paths may contain non-instantiable nodes, such as 
input-stmt, output-stmt, choice-stmt, case-stmt, ... The relative 
version is only applicable as an argument to a refine-stmt, unique-stmt 
and as an argument to the augment statement that is used as child to 
refine statement.

XPath is reserved for must-stmt, when-stmt and, in a very specific way, 
for path-stmt arguments. They are used to refer to instantiable nodes 
only -  nodes of the data tree.

>
>     Another question, how to distinguish the xpath of datadef and the 
> xpath of rpc?
>     For example:
>     module a {
>         prefix a;
>         container foo {
>   container input {
>       leaf foo1 {...}
>   }
>         }
>
>          rpc foo {
>    input {
>       leaf foo1 {...}
>    }
>    output {
>       leaf foo1 {...}
>    }
>            }
>     }
>
>     The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in container 
> or the leaf foo1 in rpc foo's input?

You example is not valid YANG. It contains a duplicated name "foo".

Jernej

>
> /frank
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------010008090107060107040200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dne 20.5.2014 9:05, pi&#353;e
      <a class="moz-txt-link-abbreviated" href="mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a>:<br>
    </div>
    <blockquote
cite="mid:OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn"
      type="cite"><font face="sans-serif" size="2">Hi all,</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; I'm confused with
        rpc's xpath expression.</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; For example:</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; module a {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; prefix a;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rpc
        foo {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;input {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;output {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; }</font>
      <br>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; The xpath of the leaf
        name foo1 in foo's input is "a:foo/a:input/a:foo1"? or is
        "a:foo/a:foo1"?</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; If it's latter, how to
        express the xpath of the leaf foo1 in foo's output?</font>
      <br>
    </blockquote>
    <br>
    In order to augment/deviate your RPC, you need to use an absolute
    schema node identifier, not XPath.<br>
    /a:foo/a:input<br>
    /a:foo/a:output<br>
    <br>
    Schema node identifiers identify schema nodes - nodes of the schema
    tree. Their paths may contain non-instantiable nodes, such as
    input-stmt, output-stmt, choice-stmt, case-stmt, ... The relative
    version is only applicable as an argument to a refine-stmt,
    unique-stmt and as an argument to the augment statement that is used
    as child to refine statement.<br>
    <br>
    XPath is reserved for must-stmt, when-stmt and, in a very specific
    way, for path-stmt arguments. They are used to refer to instantiable
    nodes only -&nbsp; nodes of the data tree.<br>
    <br>
    <blockquote
cite="mid:OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn"
      type="cite">
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; Another question, how
        to distinguish the xpath of datadef and the xpath of rpc?</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; For example:</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; module a {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; prefix a;</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; container
        foo {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; container input {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; }</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; }</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; </font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rpc
        foo {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;input {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;output {</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp; &nbsp; leaf foo1 {...}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
        &nbsp; &nbsp;}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; }</font>
      <br>
      <br>
      <font face="sans-serif" size="2">&nbsp; &nbsp; The xpath
        "a:foo/a:input/a:foo1"
        points the leaf foo1 in container or the leaf foo1 in rpc foo's
        input?</font>
      <br>
    </blockquote>
    <br>
    You example is not valid YANG. It contains a duplicated name "foo".<br>
    <br>
    Jernej<br>
    <br>
    <blockquote
cite="mid:OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn"
      type="cite"><font face="sans-serif" size="2">&nbsp; &nbsp; </font>
      <br>
      <font face="sans-serif" size="2">/frank</font>
      <br>
      <pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre>
      <br>
      <br>
      <pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
netmod mailing list
<a class="moz-txt-link-abbreviated" href="mailto:netmod@ietf.org">netmod@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org/mailman/listinfo/netmod</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------010008090107060107040200--


From nobody Tue May 20 01:17:33 2014
Return-Path: <jernej.tuljak@mg-soft.si>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505AF1A04A6 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.95
X-Spam-Level: 
X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_9iX8Es6Ww4 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:17:30 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F1F1A04A4 for <netmod@ietf.org>; Tue, 20 May 2014 01:17:29 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s4K8HR7Y003090; Tue, 20 May 2014 10:17:28 +0200
Message-ID: <537B0F96.2010502@mg-soft.com>
Date: Tue, 20 May 2014 10:17:26 +0200
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com>
In-Reply-To: <537B0EE0.5070601@mg-soft.com>
Content-Type: multipart/alternative; boundary="------------000108080205000004090105"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2rMNfffucM0nytaMRYX91TB2h18
Cc: cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org, du.baowei23@zte.com.cn
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:17:32 -0000

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

Dne 20.5.2014 10:14, pis(e Jernej Tuljak:
> Dne 20.5.2014 9:05, pis(e feng.chong33@zte.com.cn:
>> Hi all,
>>       I'm confused with rpc's xpath expression.
>>       For example:
>>       module a {
>>             prefix a;
>>            rpc foo {
>>                input {
>>                   leaf foo1 {...}
>>                }
>>                output {
>>                   leaf foo1 {...}
>>                }
>>            }
>>       }
>>
>>     The xpath of the leaf name foo1 in foo's input is 
>> "a:foo/a:input/a:foo1"? or is "a:foo/a:foo1"?
>>     If it's latter, how to express the xpath of the leaf foo1 in 
>> foo's output?
>
> In order to augment/deviate your RPC, you need to use an absolute 
> schema node identifier, not XPath.
> /a:foo/a:input
> /a:foo/a:output
>
> Schema node identifiers identify schema nodes - nodes of the schema 
> tree. Their paths may contain non-instantiable nodes, such as 
> input-stmt, output-stmt, choice-stmt, case-stmt, ... The relative 
> version is only applicable as an argument to a refine-stmt, 
> unique-stmt and as an argument to the augment statement that is used 
> as child to refine statement.

Sorry, "argument to the augment statement that is used as child to uses 
statement" would be correct.

Jernej

>
> XPath is reserved for must-stmt, when-stmt and, in a very specific 
> way, for path-stmt arguments. They are used to refer to instantiable 
> nodes only -  nodes of the data tree.
>
>>
>>     Another question, how to distinguish the xpath of datadef and the 
>> xpath of rpc?
>>     For example:
>>     module a {
>>         prefix a;
>>         container foo {
>>               container input {
>>                   leaf foo1 {...}
>>               }
>>         }
>>
>>          rpc foo {
>>                input {
>>                   leaf foo1 {...}
>>                }
>>                output {
>>                   leaf foo1 {...}
>>                }
>>            }
>>     }
>>
>>     The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in 
>> container or the leaf foo1 in rpc foo's input?
>
> You example is not valid YANG. It contains a duplicated name "foo".
>
> Jernej
>
>>
>> /frank
>>
>> --------------------------------------------------------
>> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>>
>>
>>
>>
>> --------------------------------------------------------
>> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------000108080205000004090105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dne 20.5.2014 10:14, pi&#353;e Jernej
      Tuljak:<br>
    </div>
    <blockquote cite="mid:537B0EE0.5070601@mg-soft.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Dne 20.5.2014 9:05, pi&#353;e <a
          moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a>:<br>
      </div>
      <blockquote
cite="mid:OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn"
        type="cite"><font face="sans-serif" size="2">Hi all,</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; I'm confused with rpc's
          xpath expression.</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; For example:</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; module a {</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; prefix a;</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rpc foo {</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;input {</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; leaf foo1
          {...}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;output {</font>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; leaf foo1
          {...}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; }</font> <br>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; The xpath of the leaf name
          foo1 in foo's input is "a:foo/a:input/a:foo1"? or is
          "a:foo/a:foo1"?</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; If it's latter, how to
          express the xpath of the leaf foo1 in foo's output?</font> <br>
      </blockquote>
      <br>
      In order to augment/deviate your RPC, you need to use an absolute
      schema node identifier, not XPath.<br>
      /a:foo/a:input<br>
      /a:foo/a:output<br>
      <br>
      Schema node identifiers identify schema nodes - nodes of the
      schema tree. Their paths may contain non-instantiable nodes, such
      as input-stmt, output-stmt, choice-stmt, case-stmt, ... The
      relative version is only applicable as an argument to a
      refine-stmt, unique-stmt and as an argument to the augment
      statement that is used as child to refine statement.<br>
    </blockquote>
    <br>
    Sorry, "argument to the augment statement that is used as child to
    uses statement" would be correct.<br>
    <br>
    Jernej<br>
    <br>
    <blockquote cite="mid:537B0EE0.5070601@mg-soft.com" type="cite"> <br>
      XPath is reserved for must-stmt, when-stmt and, in a very specific
      way, for path-stmt arguments. They are used to refer to
      instantiable nodes only -&nbsp; nodes of the data tree.<br>
      <br>
      <blockquote
cite="mid:OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn"
        type="cite"> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; Another question, how to
          distinguish the xpath of datadef and the xpath of rpc?</font>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; For example:</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; module a {</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; prefix a;</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; container foo {</font>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; container input {</font>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; leaf foo1
          {...}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; }</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; </font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;rpc foo {</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;input {</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; leaf foo1
          {...}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;output {</font>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; leaf foo1
          {...}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}</font> <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; }</font> <br>
        <br>
        <font face="sans-serif" size="2">&nbsp; &nbsp; The xpath
          "a:foo/a:input/a:foo1" points the leaf foo1 in container or
          the leaf foo1 in rpc foo's input?</font> <br>
      </blockquote>
      <br>
      You example is not valid YANG. It contains a duplicated name
      "foo".<br>
      <br>
      Jernej<br>
      <br>
      <blockquote
cite="mid:OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn"
        type="cite"><font face="sans-serif" size="2">&nbsp; &nbsp; </font> <br>
        <font face="sans-serif" size="2">/frank</font> <br>
        <pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre>
        <br>
        <br>
        <pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
netmod mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:netmod@ietf.org">netmod@ietf.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org/mailman/listinfo/netmod</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
netmod mailing list
<a class="moz-txt-link-abbreviated" href="mailto:netmod@ietf.org">netmod@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org/mailman/listinfo/netmod</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------000108080205000004090105--


From nobody Tue May 20 01:18:25 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2F1A04A6 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms7msQoPv4t3 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:18:23 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9061A04A4 for <netmod@ietf.org>; Tue, 20 May 2014 01:18:22 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 37AC312AE7E6; Tue, 20 May 2014 16:18:09 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4K8I9sj016908; Tue, 20 May 2014 16:18:09 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <537B0EE0.5070601@mg-soft.com>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
MIME-Version: 1.0
X-KeepSent: 06F13883:724E4B68-48257CDE:002D72BC; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 16:18:11 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 16:18:12, Serialize complete at 2014-05-20 16:18:12
Content-Type: multipart/alternative; boundary="=_alternative 002D9C7848257CDE_="
X-MAIL: mse02.zte.com.cn s4K8I9sj016908
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BUBsMMb825avheHOcC64ucrQMZ4
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:18:24 -0000

This is a multipart message in MIME format.

--=_alternative 002D9C7848257CDE_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCkplcm5laiBUdWxqYWsgPGplcm5lai50dWxqYWtAbWctc29mdC5zaT4g5YaZ5LqO
IDIwMTQtMDUtMjAgMTY6MTQ6MjQ6DQoNCj4gSmVybmVqIFR1bGphayA8amVybmVqLnR1bGpha0Bt
Zy1zb2Z0LnNpPiANCj4gMjAxNC0wNS0yMCAxNjoxNA0KPiANCj4g5pS25Lu25Lq6DQo+IA0KPiBm
ZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+IA0KPiDmioTpgIENCj4gDQo+IG5ldG1vZEBpZXRm
Lm9yZywgZHUuYmFvd2VpMjNAenRlLmNvbS5jbiwgY2hlbmcuemh1MUB6dGUuY29tLmNuLCANCj4g
ZGFpLnhpYW54aWFuQHp0ZS5jb20uY24NCj4gDQo+IOS4u+mimA0KPiANCj4gUmU6IFtuZXRtb2Rd
IEEgcXVlc3Rpb24gYWJvdXQgcnBjJ3MgeHBhdGgNCj4gDQo+IERuZSAyMC41LjIwMTQgOTowNSwg
cGnFoWUgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY246DQo+IEhpIGFsbCwgDQo+ICAgICAgIEknbSBj
b25mdXNlZCB3aXRoIHJwYydzIHhwYXRoIGV4cHJlc3Npb24uIA0KPiAgICAgICBGb3IgZXhhbXBs
ZTogDQo+ICAgICAgIG1vZHVsZSBhIHsgDQo+ICAgICAgICAgICAgIHByZWZpeCBhOyANCj4gICAg
ICAgICAgICBycGMgZm9vIHsgDQo+ICAgICAgICAgICAgICAgIGlucHV0IHsgDQo+ICAgICAgICAg
ICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufSANCj4gICAgICAgICAgICAgICAgfSANCj4gICAgICAg
ICAgICAgICAgb3V0cHV0IHsgDQo+ICAgICAgICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufSAN
Cj4gICAgICAgICAgICAgICAgfSANCj4gICAgICAgICAgICB9IA0KPiAgICAgICB9IA0KPiANCj4g
ICAgIFRoZSB4cGF0aCBvZiB0aGUgbGVhZiBuYW1lIGZvbzEgaW4gZm9vJ3MgaW5wdXQgaXMgImE6
Zm9vLw0KPiBhOmlucHV0L2E6Zm9vMSI/IG9yIGlzICJhOmZvby9hOmZvbzEiPyANCj4gICAgIElm
IGl0J3MgbGF0dGVyLCBob3cgdG8gZXhwcmVzcyB0aGUgeHBhdGggb2YgdGhlIGxlYWYgZm9vMSBp
biBmb28ncyANCm91dHB1dD8NCj4gDQo+IEluIG9yZGVyIHRvIGF1Z21lbnQvZGV2aWF0ZSB5b3Vy
IFJQQywgeW91IG5lZWQgdG8gdXNlIGFuIGFic29sdXRlIA0KPiBzY2hlbWEgbm9kZSBpZGVudGlm
aWVyLCBub3QgWFBhdGguDQo+IC9hOmZvby9hOmlucHV0DQo+IC9hOmZvby9hOm91dHB1dA0KPiAN
Cj4gU2NoZW1hIG5vZGUgaWRlbnRpZmllcnMgaWRlbnRpZnkgc2NoZW1hIG5vZGVzIC0gbm9kZXMg
b2YgdGhlIHNjaGVtYSANCj4gdHJlZS4gVGhlaXIgcGF0aHMgbWF5IGNvbnRhaW4gbm9uLWluc3Rh
bnRpYWJsZSBub2Rlcywgc3VjaCBhcyBpbnB1dC0NCj4gc3RtdCwgb3V0cHV0LXN0bXQsIGNob2lj
ZS1zdG10LCBjYXNlLXN0bXQsIC4uLiBUaGUgcmVsYXRpdmUgdmVyc2lvbiANCj4gaXMgb25seSBh
cHBsaWNhYmxlIGFzIGFuIGFyZ3VtZW50IHRvIGEgcmVmaW5lLXN0bXQsIHVuaXF1ZS1zdG10IGFu
ZCANCj4gYXMgYW4gYXJndW1lbnQgdG8gdGhlIGF1Z21lbnQgc3RhdGVtZW50IHRoYXQgaXMgdXNl
ZCBhcyBjaGlsZCB0byANCj4gcmVmaW5lIHN0YXRlbWVudC4NCj4gDQo+IFhQYXRoIGlzIHJlc2Vy
dmVkIGZvciBtdXN0LXN0bXQsIHdoZW4tc3RtdCBhbmQsIGluIGEgdmVyeSBzcGVjaWZpYyANCj4g
d2F5LCBmb3IgcGF0aC1zdG10IGFyZ3VtZW50cy4gVGhleSBhcmUgdXNlZCB0byByZWZlciB0byBp
bnN0YW50aWFibGUNCj4gbm9kZXMgb25seSAtICBub2RlcyBvZiB0aGUgZGF0YSB0cmVlLg0KDQo+
IA0KPiAgICAgQW5vdGhlciBxdWVzdGlvbiwgaG93IHRvIGRpc3Rpbmd1aXNoIHRoZSB4cGF0aCBv
ZiBkYXRhZGVmIGFuZCANCj4gdGhlIHhwYXRoIG9mIHJwYz8gDQo+ICAgICBGb3IgZXhhbXBsZTog
DQo+ICAgICBtb2R1bGUgYSB7IA0KPiAgICAgICAgIHByZWZpeCBhOyANCj4gICAgICAgICBjb250
YWluZXIgZm9vIHsgDQo+ICAgICAgICAgICAgICAgY29udGFpbmVyIGlucHV0IHsgDQo+ICAgICAg
ICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufSANCj4gICAgICAgICAgICAgICB9IA0KPiAgICAg
ICAgIH0gDQo+IA0KPiAgICAgICAgICBycGMgZm9vIHsgDQo+ICAgICAgICAgICAgICAgIGlucHV0
IHsgDQo+ICAgICAgICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufSANCj4gICAgICAgICAgICAg
ICAgfSANCj4gICAgICAgICAgICAgICAgb3V0cHV0IHsgDQo+ICAgICAgICAgICAgICAgICAgIGxl
YWYgZm9vMSB7Li4ufSANCj4gICAgICAgICAgICAgICAgfSANCj4gICAgICAgICAgICB9IA0KPiAg
ICAgfSANCj4gDQo+ICAgICBUaGUgeHBhdGggImE6Zm9vL2E6aW5wdXQvYTpmb28xIiBwb2ludHMg
dGhlIGxlYWYgZm9vMSBpbiANCj4gY29udGFpbmVyIG9yIHRoZSBsZWFmIGZvbzEgaW4gcnBjIGZv
bydzIGlucHV0PyANCj4gDQo+IFlvdSBleGFtcGxlIGlzIG5vdCB2YWxpZCBZQU5HLiBJdCBjb250
YWlucyBhIGR1cGxpY2F0ZWQgbmFtZSAiZm9vIi4NCj4gDQo+IEplcm5lag0KDQpZQU5HIHNwZWNp
ZnkgcnBjJ3MgaWRlbnRpZmllciBtdXN0IG5vdCBoYXZlIHRoZSBzYW1lIGlkZW50aWZpZXIgb2Yg
ZGF0YSANCmRlZmluaXRpb24gbm9kZT8NCj4gDQo+IC9mcmFuayANCj4gDQo+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZv
cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp
cyANCj4gbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBw
cml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4
Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBp
bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0
cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1h
dGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2Vp
dmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1
cyBpbW1lZGlhdGVseS4NCj4gDQoNCj4gDQoNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1
cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4gbWFpbCAo
YW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu
ZCANCj4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ug
b2YgdGhlIGFkZHJlc3NlZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp
cGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Ig
b3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWlu
ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlz
IG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVs
eS4NCj4gDQoNCj4gDQo+IA0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m
b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo
aXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2
aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl
IHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj
aXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3Ro
ZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBz
dHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVy
cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo=

--=_alternative 002D9C7848257CDE_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPkplcm5laiBUdWxqYWsgJmx0O2plcm5lai50dWxqYWtAbWctc29mdC5z
aSZndDsg5YaZ5LqODQoyMDE0LTA1LTIwIDE2OjE0OjI0Ojxicj4NCjxicj4NCiZndDsgSmVybmVq
IFR1bGphayAmbHQ7amVybmVqLnR1bGpha0BtZy1zb2Z0LnNpJmd0OyA8L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNS0yMCAxNjoxNDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IOaUtuS7tuS6ujwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29t
LmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDm
ioTpgIE8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBu
ZXRtb2RAaWV0Zi5vcmcsIGR1LmJhb3dlaTIzQHp0ZS5jb20uY24sIGNoZW5nLnpodTFAenRlLmNv
bS5jbiwgPGJyPg0KJmd0OyBkYWkueGlhbnhpYW5AenRlLmNvbS5jbjwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IOS4u+mimDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9u
IGFib3V0IHJwYydzIHhwYXRoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
IDxicj4NCiZndDsgRG5lIDIwLjUuMjAxNCA5OjA1LCBwacWhZSBmZW5nLmNob25nMzNAenRlLmNv
bS5jbjo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGkgYWxsLCA8YnI+
DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEknbSBjb25mdXNlZCB3aXRoIHJwYydzIHhwYXRo
IGV4cHJlc3Npb24uIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRm9yIGV4YW1wbGU6
IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbW9kdWxlIGEgeyA8YnI+DQomZ3Q7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByZWZpeCBhOyA8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cnBjIGZvbyB7IDxi
cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO2lucHV0IHsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmDQpmb28xIHsuLi59IDxicj4NCiZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O30gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7b3V0cHV0IHsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsZWFmDQpmb28xIHsuLi59IDxi
cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO30gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwO30gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9IDxicj4NCiZndDsgPGJyPg0K
Jmd0OyAmbmJzcDsgJm5ic3A7IFRoZSB4cGF0aCBvZiB0aGUgbGVhZiBuYW1lIGZvbzEgaW4gZm9v
J3MgaW5wdXQgaXMgJnF1b3Q7YTpmb28vPGJyPg0KJmd0OyBhOmlucHV0L2E6Zm9vMSZxdW90Oz8g
b3IgaXMgJnF1b3Q7YTpmb28vYTpmb28xJnF1b3Q7PyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg
SWYgaXQncyBsYXR0ZXIsIGhvdyB0byBleHByZXNzIHRoZSB4cGF0aCBvZiB0aGUgbGVhZg0KZm9v
MSBpbiBmb28ncyBvdXRwdXQ/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
IDxicj4NCiZndDsgSW4gb3JkZXIgdG8gYXVnbWVudC9kZXZpYXRlIHlvdXIgUlBDLCB5b3UgbmVl
ZCB0byB1c2UgYW4gYWJzb2x1dGUNCjxicj4NCiZndDsgc2NoZW1hIG5vZGUgaWRlbnRpZmllciwg
bm90IFhQYXRoLjxicj4NCiZndDsgL2E6Zm9vL2E6aW5wdXQ8YnI+DQomZ3Q7IC9hOmZvby9hOm91
dHB1dDxicj4NCiZndDsgPGJyPg0KJmd0OyBTY2hlbWEgbm9kZSBpZGVudGlmaWVycyBpZGVudGlm
eSBzY2hlbWEgbm9kZXMgLSBub2RlcyBvZiB0aGUgc2NoZW1hDQo8YnI+DQomZ3Q7IHRyZWUuIFRo
ZWlyIHBhdGhzIG1heSBjb250YWluIG5vbi1pbnN0YW50aWFibGUgbm9kZXMsIHN1Y2ggYXMgaW5w
dXQtPGJyPg0KJmd0OyBzdG10LCBvdXRwdXQtc3RtdCwgY2hvaWNlLXN0bXQsIGNhc2Utc3RtdCwg
Li4uIFRoZSByZWxhdGl2ZSB2ZXJzaW9uDQo8YnI+DQomZ3Q7IGlzIG9ubHkgYXBwbGljYWJsZSBh
cyBhbiBhcmd1bWVudCB0byBhIHJlZmluZS1zdG10LCB1bmlxdWUtc3RtdCBhbmQNCjxicj4NCiZn
dDsgYXMgYW4gYXJndW1lbnQgdG8gdGhlIGF1Z21lbnQgc3RhdGVtZW50IHRoYXQgaXMgdXNlZCBh
cyBjaGlsZCB0byA8YnI+DQomZ3Q7IHJlZmluZSBzdGF0ZW1lbnQuPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IFhQYXRoIGlzIHJlc2VydmVkIGZvciBtdXN0LXN0bXQsIHdoZW4tc3RtdCBhbmQsIGluIGEg
dmVyeSBzcGVjaWZpYw0KPGJyPg0KJmd0OyB3YXksIGZvciBwYXRoLXN0bXQgYXJndW1lbnRzLiBU
aGV5IGFyZSB1c2VkIHRvIHJlZmVyIHRvIGluc3RhbnRpYWJsZTxicj4NCiZndDsgbm9kZXMgb25s
eSAtICZuYnNwO25vZGVzIG9mIHRoZSBkYXRhIHRyZWUuPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBBbm90aGVyIHF1
ZXN0aW9uLCBob3cgdG8gZGlzdGluZ3Vpc2ggdGhlIHhwYXRoIG9mIGRhdGFkZWYNCmFuZCA8YnI+
DQomZ3Q7IHRoZSB4cGF0aCBvZiBycGM/IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhh
bXBsZTogPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IG1vZHVsZSBhIHsgPGJyPg0KJmd0OyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJlZml4IGE7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IGNvbnRhaW5lciBmb28geyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb250YWluZXIgaW5wdXQgew0KPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyBsZWFmDQpmb28xIHsuLi59IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0gPGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgfSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtycGMgZm9vIHsg
PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7aW5wdXQgeyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYNCmZvbzEgey4uLn0gPGJyPg0K
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7fSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtvdXRwdXQgeyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxlYWYNCmZvbzEgey4uLn0g
PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7fSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7fSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgfSA8YnI+DQomZ3Q7IDxicj4NCiZndDsg
Jm5ic3A7ICZuYnNwOyBUaGUgeHBhdGggJnF1b3Q7YTpmb28vYTppbnB1dC9hOmZvbzEmcXVvdDsg
cG9pbnRzIHRoZQ0KbGVhZiBmb28xIGluIDxicj4NCiZndDsgY29udGFpbmVyIG9yIHRoZSBsZWFm
IGZvbzEgaW4gcnBjIGZvbydzIGlucHV0PyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgPGJyPg0KJmd0OyBZb3UgZXhhbXBsZSBpcyBub3QgdmFsaWQgWUFORy4gSXQgY29u
dGFpbnMgYSBkdXBsaWNhdGVkIG5hbWUgJnF1b3Q7Zm9vJnF1b3Q7Ljxicj4NCiZndDsgPGJyPg0K
Jmd0OyBKZXJuZWo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPllBTkcg
c3BlY2lmeSBycGMncyBpZGVudGlmaWVyIG11c3Qgbm90IGhhdmUgdGhlIHNhbWUNCmlkZW50aWZp
ZXIgb2YgZGF0YSBkZWZpbml0aW9uIG5vZGU/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAvZnJhbmsgPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1h
dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0K
PGJyPg0KJmd0OyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgp
IGlzIHByaXZpbGVnZWQgYW5kIDxicj4NCiZndDsgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRl
ZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZTxicj4NCiZndDsgKHMpLiAm
bmJzcDtJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJl
LCA8YnI+DQomZ3Q7IHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu
YXRpb24gb3IgdXNlIG9mIHRoZSA8YnI+DQomZ3Q7IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBz
dHJpY3RseSBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZlZA0KPGJyPg0KJmd0
OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l
ZGlhdGVseS48YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy
Pg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQo8YnI+DQomZ3Q7IG1haWwgKGFuZCBhbnkgYXR0
YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0
OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0
aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVu
ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBk
aXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZn
dDsgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lm
IHlvdSBoYXZlIHJlY2VpdmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl
IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCiZndDsgPGJyPg0KPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0
PGJyPg0KJmd0OyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0Pjxmb250IHNp
emU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvZm9udD48
L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHByZT48
Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl
IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0
cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp
cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm
IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv
ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo
ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90
aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K

--=_alternative 002D9C7848257CDE_=--


From nobody Tue May 20 01:25:03 2014
Return-Path: <jernej.tuljak@mg-soft.si>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D581A04A6 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq8GHec9pYfj for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:25:00 -0700 (PDT)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3A61A0495 for <netmod@ietf.org>; Tue, 20 May 2014 01:24:59 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s4K8OwKJ003323; Tue, 20 May 2014 10:24:58 +0200
Message-ID: <537B1158.1010708@mg-soft.com>
Date: Tue, 20 May 2014 10:24:56 +0200
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: feng.chong33@zte.com.cn
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn>
In-Reply-To: <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn>
Content-Type: multipart/alternative; boundary="------------050306030801000906030601"
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cklJ275gaNgiVQOz0rc1CyXKvf0
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:25:02 -0000

This is a multi-part message in MIME format.
--------------050306030801000906030601
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Dne 20.5.2014 10:18, piĊĦe feng.chong33@zte.com.cn:
> /frank
>
> Jernej Tuljak <jernej.tuljak@mg-soft.si> ċ†™äşŽ 2014-05-20 16:14:24:
>
> > Jernej Tuljak <jernej.tuljak@mg-soft.si>
> > 2014-05-20 16:14
> >
> > ĉ”ĥäğĥäşş
> >
> > feng.chong33@zte.com.cn,
> >
> > ĉŠ„送
> >
> > netmod@ietf.org, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn,
> > dai.xianxian@zte.com.cn
> >
> > ä¸ğ题
> >
> > Re: [netmod] A question about rpc's xpath
> >
> > Dne 20.5.2014 9:05, piĊĦe feng.chong33@zte.com.cn:
> > Hi all,
> >       I'm confused with rpc's xpath expression.
> >       For example:
> >       module a {
> >             prefix a;
> >            rpc foo {
> >                input {
> >                   leaf foo1 {...}
> >                }
> >                output {
> >                   leaf foo1 {...}
> >                }
> >            }
> >       }
> >
> >     The xpath of the leaf name foo1 in foo's input is "a:foo/
> > a:input/a:foo1"? or is "a:foo/a:foo1"?
> >     If it's latter, how to express the xpath of the leaf foo1 in 
> foo's output?
> >
> > In order to augment/deviate your RPC, you need to use an absolute
> > schema node identifier, not XPath.
> > /a:foo/a:input
> > /a:foo/a:output
> >
> > Schema node identifiers identify schema nodes - nodes of the schema
> > tree. Their paths may contain non-instantiable nodes, such as input-
> > stmt, output-stmt, choice-stmt, case-stmt, ... The relative version
> > is only applicable as an argument to a refine-stmt, unique-stmt and
> > as an argument to the augment statement that is used as child to
> > refine statement.
> >
> > XPath is reserved for must-stmt, when-stmt and, in a very specific
> > way, for path-stmt arguments. They are used to refer to instantiable
> > nodes only -  nodes of the data tree.
>
> >
> >     Another question, how to distinguish the xpath of datadef and
> > the xpath of rpc?
> >     For example:
> >     module a {
> >         prefix a;
> >         container foo {
> >               container input {
> >                   leaf foo1 {...}
> >               }
> >         }
> >
> >          rpc foo {
> >                input {
> >                   leaf foo1 {...}
> >                }
> >                output {
> >                   leaf foo1 {...}
> >                }
> >            }
> >     }
> >
> >     The xpath "a:foo/a:input/a:foo1" points the leaf foo1 in
> > container or the leaf foo1 in rpc foo's input?
> >
> > You example is not valid YANG. It contains a duplicated name "foo".
> >
> > Jernej
>
> YANG specify rpc's identifier must not have the same identifier of 
> data definition node?

Yes. See section 6.2.1 in RFC6020.

    o  All leafs, leaf-lists, lists, containers, choices, rpcs,
       notifications, and anyxmls defined (directly or through a uses
       statement) within a parent node or at the top level of the module
       or its submodules share the same identifier namespace.  This
       namespace is scoped to the parent node or module, unless the
       parent node is a case node.  In that case, the namespace is scoped
       to the closest ancestor node that is not a case or choice node.


Jernej

> >
> > /frank
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately.
> >
>
> >
>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the addressee
> > (s).  If you are not an intended recipient, any disclosure,
> > reproduction, distribution or other dissemination or use of the
> > information contained is strictly prohibited.  If you have received
> > this mail in error, please delete it and notify us immediately.
> >
>
> >
> >
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
>
>


--------------050306030801000906030601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dne 20.5.2014 10:18, piĊĦe
      <a class="moz-txt-link-abbreviated" href="mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a>:<br>
    </div>
    <blockquote
cite="mid:OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn"
      type="cite"><font face="sans-serif" size="2">/frank</font>
      <br>
      <br>
      <tt><font size="2">Jernej Tuljak <a class="moz-txt-link-rfc2396E" href="mailto:jernej.tuljak@mg-soft.si">&lt;jernej.tuljak@mg-soft.si&gt;</a>
          ċ†™äşŽ
          2014-05-20 16:14:24:<br>
          <br>
          &gt; Jernej Tuljak <a class="moz-txt-link-rfc2396E" href="mailto:jernej.tuljak@mg-soft.si">&lt;jernej.tuljak@mg-soft.si&gt;</a> </font></tt>
      <br>
      <tt><font size="2">&gt; 2014-05-20 16:14</font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; ĉ”ĥäğĥäşş</font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a>, </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; ĉŠ„送</font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:netmod@ietf.org">netmod@ietf.org</a>, <a class="moz-txt-link-abbreviated" href="mailto:du.baowei23@zte.com.cn">du.baowei23@zte.com.cn</a>,
          <a class="moz-txt-link-abbreviated" href="mailto:cheng.zhu1@zte.com.cn">cheng.zhu1@zte.com.cn</a>, <br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:dai.xianxian@zte.com.cn">dai.xianxian@zte.com.cn</a></font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; ä¸ğ题</font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; Re: [netmod] A question about rpc's xpath</font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; Dne 20.5.2014 9:05, piĊĦe <a class="moz-txt-link-abbreviated" href="mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a>:</font></tt>
      <br>
      <tt><font size="2">&gt; Hi all, <br>
          &gt;       I'm confused with rpc's xpath expression. <br>
          &gt;       For example: <br>
          &gt;       module a { <br>
          &gt;             prefix a; <br>
          &gt;            rpc foo { <br>
          &gt;                input { <br>
          &gt;                   leaf
          foo1 {...} <br>
          &gt;                } <br>
          &gt;                output { <br>
          &gt;                   leaf
          foo1 {...} <br>
          &gt;                } <br>
          &gt;            } <br>
          &gt;       } <br>
          &gt; <br>
          &gt;     The xpath of the leaf name foo1 in foo's input is
          "a:foo/<br>
          &gt; a:input/a:foo1"? or is "a:foo/a:foo1"? <br>
          &gt;     If it's latter, how to express the xpath of the leaf
          foo1 in foo's output?</font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; In order to augment/deviate your RPC, you need to use an
          absolute
          <br>
          &gt; schema node identifier, not XPath.<br>
          &gt; /a:foo/a:input<br>
          &gt; /a:foo/a:output<br>
          &gt; <br>
          &gt; Schema node identifiers identify schema nodes - nodes of
          the schema
          <br>
          &gt; tree. Their paths may contain non-instantiable nodes,
          such as input-<br>
          &gt; stmt, output-stmt, choice-stmt, case-stmt, ... The
          relative version
          <br>
          &gt; is only applicable as an argument to a refine-stmt,
          unique-stmt and
          <br>
          &gt; as an argument to the augment statement that is used as
          child to <br>
          &gt; refine statement.<br>
          &gt; <br>
          &gt; XPath is reserved for must-stmt, when-stmt and, in a very
          specific
          <br>
          &gt; way, for path-stmt arguments. They are used to refer to
          instantiable<br>
          &gt; nodes only -  nodes of the data tree.<br>
        </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt;     Another question, how to distinguish the xpath of
          datadef
          and <br>
          &gt; the xpath of rpc? <br>
          &gt;     For example: <br>
          &gt;     module a { <br>
          &gt;         prefix a; <br>
          &gt;         container foo { <br>
          &gt;               container input {
          <br>
          &gt;                   leaf
          foo1 {...} <br>
          &gt;               } <br>
          &gt;         } <br>
          &gt;         <br>
          &gt;          rpc foo { <br>
          &gt;                input { <br>
          &gt;                   leaf
          foo1 {...} <br>
          &gt;                } <br>
          &gt;                output { <br>
          &gt;                   leaf
          foo1 {...} <br>
          &gt;                } <br>
          &gt;            } <br>
          &gt;     } <br>
          &gt; <br>
          &gt;     The xpath "a:foo/a:input/a:foo1" points the
          leaf foo1 in <br>
          &gt; container or the leaf foo1 in rpc foo's input? </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; You example is not valid YANG. It contains a duplicated
          name "foo".<br>
          &gt; <br>
          &gt; Jernej<br>
        </font></tt>
      <br>
      <tt><font size="2">YANG specify rpc's identifier must not have the
          same
          identifier of data definition node?</font></tt>
      <br>
    </blockquote>
    <br>
    Yes. See section 6.2.1 in RFC6020.<br>
    <br>
    <pre class="newpage">   o  All leafs, leaf-lists, lists, containers, choices, rpcs,
      notifications, and anyxmls defined (directly or through a uses
      statement) within a parent node or at the top level of the module
      or its submodules share the same identifier namespace.  This
      namespace is scoped to the parent node or module, unless the
      parent node is a case node.  In that case, the namespace is scoped
      to the closest ancestor node that is not a case or choice node.</pre>
    <br>
    Jernej<br>
    <br>
    <blockquote
cite="mid:OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn"
      type="cite"><tt><font size="2">&gt;     <br>
          &gt; /frank </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; --------------------------------------------------------<br>
          &gt; ZTE Information Security Notice: The information
          contained in this
          <br>
          &gt; mail (and any attachment transmitted herewith) is
          privileged and <br>
          &gt; confidential and is intended for the exclusive use of the
          addressee<br>
          &gt; (s).  If you are not an intended recipient, any
          disclosure, <br>
          &gt; reproduction, distribution or other dissemination or use
          of the <br>
          &gt; information contained is strictly prohibited.  If you
          have received
          <br>
          &gt; this mail in error, please delete it and notify us
          immediately.<br>
          &gt; <br>
        </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
        </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; --------------------------------------------------------<br>
          &gt; ZTE Information Security Notice: The information
          contained in this
          <br>
          &gt; mail (and any attachment transmitted herewith) is
          privileged and <br>
          &gt; confidential and is intended for the exclusive use of the
          addressee<br>
          &gt; (s).  If you are not an intended recipient, any
          disclosure, <br>
          &gt; reproduction, distribution or other dissemination or use
          of the <br>
          &gt; information contained is strictly prohibited.  If you
          have received
          <br>
          &gt; this mail in error, please delete it and notify us
          immediately.<br>
          &gt; <br>
        </font></tt>
      <br>
      <tt><font size="2">&gt; <br>
          &gt; <br>
        </font></tt>
      <br>
      <tt><font size="2">&gt;
          _______________________________________________<br>
          &gt; netmod mailing list<br>
          &gt; <a class="moz-txt-link-abbreviated" href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
          &gt; </font></tt><a moz-do-not-send="true"
        href="https://www.ietf.org/mailman/listinfo/netmod"><tt><font
            size="2">https://www.ietf.org/mailman/listinfo/netmod</font></tt></a><tt><font
          size="2"><br>
        </font></tt>
      <br>
      <pre><font color="blue">
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

</font></pre>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------050306030801000906030601--


From nobody Tue May 20 01:32:48 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325241A04B6 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW3UXguoxLCt for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 01:32:45 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0391A04AC for <netmod@ietf.org>; Tue, 20 May 2014 01:32:44 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id D491B12AECE7 for <netmod@ietf.org>; Tue, 20 May 2014 16:32:30 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 5C32173E4E2; Tue, 20 May 2014 16:32:30 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4K8WXvU054494; Tue, 20 May 2014 16:32:33 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <537B1158.1010708@mg-soft.com>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn> <537B1158.1010708@mg-soft.com>
To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
MIME-Version: 1.0
X-KeepSent: EC1333EA:133482D9-48257CDE:002EBEBB; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 16:32:33 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 16:32:35, Serialize complete at 2014-05-20 16:32:35
Content-Type: multipart/alternative; boundary="=_alternative 002EED4A48257CDE_="
X-MAIL: mse02.zte.com.cn s4K8WXvU054494
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EPitAyt7SZhsJj1GkwquFKD5OXw
Cc: du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:32:47 -0000

This is a multipart message in MIME format.

--=_alternative 002EED4A48257CDE_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCkplcm5laiBUdWxqYWsgPGplcm5lai50dWxqYWtAbWctc29mdC5zaT4g5YaZ5LqO
IDIwMTQtMDUtMjAgMTY6MjQ6NTY6DQoNCj4gSmVybmVqIFR1bGphayA8amVybmVqLnR1bGpha0Bt
Zy1zb2Z0LnNpPiANCj4gMjAxNC0wNS0yMCAxNjoyNA0KPiANCj4g5pS25Lu25Lq6DQo+IA0KPiBm
ZW5nLmNob25nMzNAenRlLmNvbS5jbiwgDQo+IA0KPiDmioTpgIENCj4gDQo+IEplcm5laiBUdWxq
YWsgPGplcm5lai50dWxqYWtAbWctc29mdC5zaT4sIGNoZW5nLnpodTFAenRlLmNvbS5jbiwgDQo+
IGRhaS54aWFueGlhbkB6dGUuY29tLmNuLCBkdS5iYW93ZWkyM0B6dGUuY29tLmNuLCBuZXRtb2RA
aWV0Zi5vcmcNCj4gDQo+IOS4u+mimA0KPiANCj4gUmU6IFtuZXRtb2RdIEEgcXVlc3Rpb24gYWJv
dXQgcnBjJ3MgeHBhdGgNCj4gDQo+IERuZSAyMC41LjIwMTQgMTA6MTgsIHBpxaFlIGZlbmcuY2hv
bmczM0B6dGUuY29tLmNuOg0KPiAvZnJhbmsgDQo+IA0KPiBKZXJuZWogVHVsamFrIDxqZXJuZWou
dHVsamFrQG1nLXNvZnQuc2k+IOWGmeS6jiAyMDE0LTA1LTIwIDE2OjE0OjI0Og0KPiANCj4gPiBK
ZXJuZWogVHVsamFrIDxqZXJuZWoudHVsamFrQG1nLXNvZnQuc2k+IA0KPiA+IDIwMTQtMDUtMjAg
MTY6MTQgDQo+ID4gDQo+ID4g5pS25Lu25Lq6IA0KPiA+IA0KPiA+IGZlbmcuY2hvbmczM0B6dGUu
Y29tLmNuLCANCj4gPiANCj4gPiDmioTpgIEgDQo+ID4gDQo+ID4gbmV0bW9kQGlldGYub3JnLCBk
dS5iYW93ZWkyM0B6dGUuY29tLmNuLCBjaGVuZy56aHUxQHp0ZS5jb20uY24sIA0KPiA+IGRhaS54
aWFueGlhbkB6dGUuY29tLmNuIA0KPiA+IA0KPiA+IOS4u+mimCANCj4gPiANCj4gPiBSZTogW25l
dG1vZF0gQSBxdWVzdGlvbiBhYm91dCBycGMncyB4cGF0aCANCj4gPiANCj4gPiBEbmUgMjAuNS4y
MDE0IDk6MDUsIHBpxaFlIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuOiANCj4gPiBIaSBhbGwsIA0K
PiA+ICAgICAgIEknbSBjb25mdXNlZCB3aXRoIHJwYydzIHhwYXRoIGV4cHJlc3Npb24uIA0KPiA+
ICAgICAgIEZvciBleGFtcGxlOiANCj4gPiAgICAgICBtb2R1bGUgYSB7IA0KPiA+ICAgICAgICAg
ICAgIHByZWZpeCBhOyANCj4gPiAgICAgICAgICAgIHJwYyBmb28geyANCj4gPiAgICAgICAgICAg
ICAgICBpbnB1dCB7IA0KPiA+ICAgICAgICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufSANCj4g
PiAgICAgICAgICAgICAgICB9IA0KPiA+ICAgICAgICAgICAgICAgIG91dHB1dCB7IA0KPiA+ICAg
ICAgICAgICAgICAgICAgIGxlYWYgZm9vMSB7Li4ufSANCj4gPiAgICAgICAgICAgICAgICB9IA0K
PiA+ICAgICAgICAgICAgfSANCj4gPiAgICAgICB9IA0KPiA+IA0KPiA+ICAgICBUaGUgeHBhdGgg
b2YgdGhlIGxlYWYgbmFtZSBmb28xIGluIGZvbydzIGlucHV0IGlzICJhOmZvby8NCj4gPiBhOmlu
cHV0L2E6Zm9vMSI/IG9yIGlzICJhOmZvby9hOmZvbzEiPyANCj4gPiAgICAgSWYgaXQncyBsYXR0
ZXIsIGhvdyB0byBleHByZXNzIHRoZSB4cGF0aCBvZiB0aGUgbGVhZiBmb28xIGluIA0KPiBmb28n
cyBvdXRwdXQ/IA0KPiA+IA0KPiA+IEluIG9yZGVyIHRvIGF1Z21lbnQvZGV2aWF0ZSB5b3VyIFJQ
QywgeW91IG5lZWQgdG8gdXNlIGFuIGFic29sdXRlIA0KPiA+IHNjaGVtYSBub2RlIGlkZW50aWZp
ZXIsIG5vdCBYUGF0aC4NCj4gPiAvYTpmb28vYTppbnB1dA0KPiA+IC9hOmZvby9hOm91dHB1dA0K
PiA+IA0KPiA+IFNjaGVtYSBub2RlIGlkZW50aWZpZXJzIGlkZW50aWZ5IHNjaGVtYSBub2RlcyAt
IG5vZGVzIG9mIHRoZSBzY2hlbWEgDQo+ID4gdHJlZS4gVGhlaXIgcGF0aHMgbWF5IGNvbnRhaW4g
bm9uLWluc3RhbnRpYWJsZSBub2Rlcywgc3VjaCBhcyBpbnB1dC0NCj4gPiBzdG10LCBvdXRwdXQt
c3RtdCwgY2hvaWNlLXN0bXQsIGNhc2Utc3RtdCwgLi4uIFRoZSByZWxhdGl2ZSB2ZXJzaW9uIA0K
PiA+IGlzIG9ubHkgYXBwbGljYWJsZSBhcyBhbiBhcmd1bWVudCB0byBhIHJlZmluZS1zdG10LCB1
bmlxdWUtc3RtdCBhbmQgDQo+ID4gYXMgYW4gYXJndW1lbnQgdG8gdGhlIGF1Z21lbnQgc3RhdGVt
ZW50IHRoYXQgaXMgdXNlZCBhcyBjaGlsZCB0byANCj4gPiByZWZpbmUgc3RhdGVtZW50Lg0KPiA+
IA0KPiA+IFhQYXRoIGlzIHJlc2VydmVkIGZvciBtdXN0LXN0bXQsIHdoZW4tc3RtdCBhbmQsIGlu
IGEgdmVyeSBzcGVjaWZpYyANCj4gPiB3YXksIGZvciBwYXRoLXN0bXQgYXJndW1lbnRzLiBUaGV5
IGFyZSB1c2VkIHRvIHJlZmVyIHRvIGluc3RhbnRpYWJsZQ0KPiA+IG5vZGVzIG9ubHkgLSAgbm9k
ZXMgb2YgdGhlIGRhdGEgdHJlZS4NCj4gDQo+ID4gDQo+ID4gICAgIEFub3RoZXIgcXVlc3Rpb24s
IGhvdyB0byBkaXN0aW5ndWlzaCB0aGUgeHBhdGggb2YgZGF0YWRlZiBhbmQgDQo+ID4gdGhlIHhw
YXRoIG9mIHJwYz8gDQo+ID4gICAgIEZvciBleGFtcGxlOiANCj4gPiAgICAgbW9kdWxlIGEgeyAN
Cj4gPiAgICAgICAgIHByZWZpeCBhOyANCj4gPiAgICAgICAgIGNvbnRhaW5lciBmb28geyANCj4g
PiAgICAgICAgICAgICAgIGNvbnRhaW5lciBpbnB1dCB7IA0KPiA+ICAgICAgICAgICAgICAgICAg
IGxlYWYgZm9vMSB7Li4ufSANCj4gPiAgICAgICAgICAgICAgIH0gDQo+ID4gICAgICAgICB9IA0K
PiA+ICAgICAgICAgDQo+ID4gICAgICAgICAgcnBjIGZvbyB7IA0KPiA+ICAgICAgICAgICAgICAg
IGlucHV0IHsgDQo+ID4gICAgICAgICAgICAgICAgICAgbGVhZiBmb28xIHsuLi59IA0KPiA+ICAg
ICAgICAgICAgICAgIH0gDQo+ID4gICAgICAgICAgICAgICAgb3V0cHV0IHsgDQo+ID4gICAgICAg
ICAgICAgICAgICAgbGVhZiBmb28xIHsuLi59IA0KPiA+ICAgICAgICAgICAgICAgIH0gDQo+ID4g
ICAgICAgICAgICB9IA0KPiA+ICAgICB9IA0KPiA+IA0KPiA+ICAgICBUaGUgeHBhdGggImE6Zm9v
L2E6aW5wdXQvYTpmb28xIiBwb2ludHMgdGhlIGxlYWYgZm9vMSBpbiANCj4gPiBjb250YWluZXIg
b3IgdGhlIGxlYWYgZm9vMSBpbiBycGMgZm9vJ3MgaW5wdXQ/IA0KPiA+IA0KPiA+IFlvdSBleGFt
cGxlIGlzIG5vdCB2YWxpZCBZQU5HLiBJdCBjb250YWlucyBhIGR1cGxpY2F0ZWQgbmFtZSAiZm9v
Ii4NCj4gPiANCj4gPiBKZXJuZWoNCj4gDQo+IFlBTkcgc3BlY2lmeSBycGMncyBpZGVudGlmaWVy
IG11c3Qgbm90IGhhdmUgdGhlIHNhbWUgaWRlbnRpZmllciBvZiANCj4gZGF0YSBkZWZpbml0aW9u
IG5vZGU/IA0KPiANCj4gWWVzLiBTZWUgc2VjdGlvbiA2LjIuMSBpbiBSRkM2MDIwLg0KDQo+ICAg
IG8gIEFsbCBsZWFmcywgbGVhZi1saXN0cywgbGlzdHMsIGNvbnRhaW5lcnMsIGNob2ljZXMsIHJw
Y3MsDQo+ICAgICAgIG5vdGlmaWNhdGlvbnMsIGFuZCBhbnl4bWxzIGRlZmluZWQgKGRpcmVjdGx5
IG9yIHRocm91Z2ggYSB1c2VzDQo+ICAgICAgIHN0YXRlbWVudCkgd2l0aGluIGEgcGFyZW50IG5v
ZGUgb3IgYXQgdGhlIHRvcCBsZXZlbCBvZiB0aGUgbW9kdWxlDQo+ICAgICAgIG9yIGl0cyBzdWJt
b2R1bGVzIHNoYXJlIHRoZSBzYW1lIGlkZW50aWZpZXIgbmFtZXNwYWNlLiAgVGhpcw0KPiAgICAg
ICBuYW1lc3BhY2UgaXMgc2NvcGVkIHRvIHRoZSBwYXJlbnQgbm9kZSBvciBtb2R1bGUsIHVubGVz
cyB0aGUNCj4gICAgICAgcGFyZW50IG5vZGUgaXMgYSBjYXNlIG5vZGUuICBJbiB0aGF0IGNhc2Us
IHRoZSBuYW1lc3BhY2UgaXMgc2NvcGVkDQo+ICAgICAgIHRvIHRoZSBjbG9zZXN0IGFuY2VzdG9y
IG5vZGUgdGhhdCBpcyBub3QgYSBjYXNlIG9yIGNob2ljZSBub2RlLg0KPiANCj4gSmVybmVqDQpU
aGFua3MgYSBsb3QhDQpCdXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBycGMnIGlkZW50aWZpZXIg
bXVzdCBub3QgYmUgdGhlIHNhbWUgdG8gZGF0YSANCmRlZmluaXRpb24gbm9kZSdzIGlkZW50aWZp
ZXIuDQo+ID4gICAgIA0KPiA+IC9mcmFuayANCj4gPiANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFpURSBJbmZvcm1hdGlv
biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4g
PiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp
bGVnZWQgYW5kIA0KPiA+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs
dXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUNCj4gPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBp
bnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCANCj4gPiByZXByb2R1Y3Rpb24sIGRp
c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgDQo+ID4gaW5m
b3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCANCj4gPiB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v
dGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiANCj4gDQo+ID4gDQo+IA0KPiA+IA0KPiA+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g
WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpbiB0aGlzIA0KPiA+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJl
d2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgDQo+ID4gY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRl
ZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZQ0KPiA+IChzKS4gIElmIHlv
dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiA+IHJl
cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m
IHRoZSANCj4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g
IElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiA+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl
bGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiA+IA0KPiANCj4gPiANCj4gPiAN
Cj4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KPiANCj4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIElu
Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0
aGlzIA0KPiBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlz
IHByaXZpbGVnZWQgYW5kIA0KPiBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUg
ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlDQo+IChzKS4gIElmIHlvdSBhcmUgbm90IGFu
IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIA0KPiByZXByb2R1Y3Rpb24sIGRp
c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgDQo+IGluZm9y
bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgDQo+IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5
IHVzIGltbWVkaWF0ZWx5Lg0KPiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6
IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1l
bnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBh
bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocyku
ICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCBy
ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv
ZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k
IG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl
OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2ht
ZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwg
YW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMp
LiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwg
cmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ug
b2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFu
ZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo=

--=_alternative 002EED4A48257CDE_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPkplcm5laiBUdWxqYWsgJmx0O2plcm5lai50dWxqYWtAbWctc29mdC5z
aSZndDsg5YaZ5LqODQoyMDE0LTA1LTIwIDE2OjI0OjU2Ojxicj4NCjxicj4NCiZndDsgSmVybmVq
IFR1bGphayAmbHQ7amVybmVqLnR1bGpha0BtZy1zb2Z0LnNpJmd0OyA8L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNS0yMCAxNjoyNDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IOaUtuS7tuS6ujwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29t
LmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDm
ioTpgIE8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBK
ZXJuZWogVHVsamFrICZsdDtqZXJuZWoudHVsamFrQG1nLXNvZnQuc2kmZ3Q7LCBjaGVuZy56aHUx
QHp0ZS5jb20uY24sDQo8YnI+DQomZ3Q7IGRhaS54aWFueGlhbkB6dGUuY29tLmNuLCBkdS5iYW93
ZWkyM0B6dGUuY29tLmNuLCBuZXRtb2RAaWV0Zi5vcmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDkuLvpopg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW25ldG1vZF0gQSBxdWVzdGlvbiBhYm91dCBy
cGMncyB4cGF0aDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom
Z3Q7IERuZSAyMC41LjIwMTQgMTA6MTgsIHBpxaFlIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuOjwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAvZnJhbmsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEplcm5laiBUdWxqYWsgJmx0O2plcm5lai50dWxqYWtAbWctc29mdC5zaSZndDsg
5YaZ5LqOIDIwMTQtMDUtMjAgMTY6MTQ6MjQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgSmVy
bmVqIFR1bGphayAmbHQ7amVybmVqLnR1bGpha0BtZy1zb2Z0LnNpJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgMjAxNC0wNS0yMCAxNjoxNCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IOaUtuS7
tuS6uiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29t
LmNuLCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IOaKhOmAgSA8YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IG5ldG1vZEBpZXRmLm9yZywgZHUuYmFvd2VpMjNAenRlLmNvbS5j
biwgY2hlbmcuemh1MUB6dGUuY29tLmNuLA0KPGJyPg0KJmd0OyAmZ3Q7IGRhaS54aWFueGlhbkB6
dGUuY29tLmNuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg5Li76aKYIDxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUmU6IFtuZXRtb2RdIEEgcXVlc3Rpb24gYWJvdXQgcnBj
J3MgeHBhdGggPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBEbmUgMjAuNS4yMDE0IDk6
MDUsIHBpxaFlIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuOiA8YnI+DQomZ3Q7ICZndDsgSGkgYWxs
LCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSdtIGNvbmZ1c2VkIHdpdGgg
cnBjJ3MgeHBhdGggZXhwcmVzc2lvbi4NCjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBGb3IgZXhhbXBsZTogPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1v
ZHVsZSBhIHsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IHByZWZpeCBhOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDtycGMgZm9vIHsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnB1dA0KeyA8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsNCmxlYWYgZm9vMSB7Li4ufSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO30gPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtvdXRwdXQNCnsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpsZWFmIGZvbzEgey4uLn0g
PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDt9IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO30gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0g
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IFRoZSB4cGF0aCBv
ZiB0aGUgbGVhZiBuYW1lIGZvbzEgaW4gZm9vJ3MgaW5wdXQNCmlzICZxdW90O2E6Zm9vLzxicj4N
CiZndDsgJmd0OyBhOmlucHV0L2E6Zm9vMSZxdW90Oz8gb3IgaXMgJnF1b3Q7YTpmb28vYTpmb28x
JnF1b3Q7PyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBJZiBpdCdzIGxhdHRlciwgaG93
IHRvIGV4cHJlc3MgdGhlIHhwYXRoIG9mIHRoZQ0KbGVhZiBmb28xIGluIDxicj4NCiZndDsgZm9v
J3Mgb3V0cHV0PyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIG9yZGVyIHRvIGF1
Z21lbnQvZGV2aWF0ZSB5b3VyIFJQQywgeW91IG5lZWQgdG8gdXNlIGFuIGFic29sdXRlDQo8YnI+
DQomZ3Q7ICZndDsgc2NoZW1hIG5vZGUgaWRlbnRpZmllciwgbm90IFhQYXRoLjxicj4NCiZndDsg
Jmd0OyAvYTpmb28vYTppbnB1dDxicj4NCiZndDsgJmd0OyAvYTpmb28vYTpvdXRwdXQ8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNjaGVtYSBub2RlIGlkZW50aWZpZXJzIGlkZW50aWZ5
IHNjaGVtYSBub2RlcyAtIG5vZGVzIG9mIHRoZQ0Kc2NoZW1hIDxicj4NCiZndDsgJmd0OyB0cmVl
LiBUaGVpciBwYXRocyBtYXkgY29udGFpbiBub24taW5zdGFudGlhYmxlIG5vZGVzLCBzdWNoIGFz
DQppbnB1dC08YnI+DQomZ3Q7ICZndDsgc3RtdCwgb3V0cHV0LXN0bXQsIGNob2ljZS1zdG10LCBj
YXNlLXN0bXQsIC4uLiBUaGUgcmVsYXRpdmUgdmVyc2lvbg0KPGJyPg0KJmd0OyAmZ3Q7IGlzIG9u
bHkgYXBwbGljYWJsZSBhcyBhbiBhcmd1bWVudCB0byBhIHJlZmluZS1zdG10LCB1bmlxdWUtc3Rt
dA0KYW5kIDxicj4NCiZndDsgJmd0OyBhcyBhbiBhcmd1bWVudCB0byB0aGUgYXVnbWVudCBzdGF0
ZW1lbnQgdGhhdCBpcyB1c2VkIGFzIGNoaWxkDQp0byA8YnI+DQomZ3Q7ICZndDsgcmVmaW5lIHN0
YXRlbWVudC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFhQYXRoIGlzIHJlc2VydmVk
IGZvciBtdXN0LXN0bXQsIHdoZW4tc3RtdCBhbmQsIGluIGEgdmVyeSBzcGVjaWZpYw0KPGJyPg0K
Jmd0OyAmZ3Q7IHdheSwgZm9yIHBhdGgtc3RtdCBhcmd1bWVudHMuIFRoZXkgYXJlIHVzZWQgdG8g
cmVmZXIgdG8gaW5zdGFudGlhYmxlPGJyPg0KJmd0OyAmZ3Q7IG5vZGVzIG9ubHkgLSAmbmJzcDtu
b2RlcyBvZiB0aGUgZGF0YSB0cmVlLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmbmJzcDsgJm5ic3A7IEFub3RoZXIgcXVlc3Rpb24sIGhvdyB0byBkaXN0aW5ndWlz
aCB0aGUgeHBhdGgNCm9mIGRhdGFkZWYgYW5kIDxicj4NCiZndDsgJmd0OyB0aGUgeHBhdGggb2Yg
cnBjPyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBGb3IgZXhhbXBsZTogPGJyPg0KJmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgbW9kdWxlIGEgeyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IHByZWZpeCBhOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7IGNvbnRhaW5lciBmb28geyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRhaW5lciBpbnB1dA0K
eyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmxlYWYgZm9vMSB7Li4ufSA8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0gPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9IDxicj4NCiZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDtycGMgZm9vIHsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnB1dA0KeyA8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsNCmxlYWYgZm9vMSB7Li4ufSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO30gPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtvdXRwdXQNCnsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpsZWFmIGZvbzEgey4uLn0g
PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDt9IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO30gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgfSA8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgVGhlIHhwYXRoICZxdW90O2E6
Zm9vL2E6aW5wdXQvYTpmb28xJnF1b3Q7IHBvaW50cw0KdGhlIGxlYWYgZm9vMSBpbiA8YnI+DQom
Z3Q7ICZndDsgY29udGFpbmVyIG9yIHRoZSBsZWFmIGZvbzEgaW4gcnBjIGZvbydzIGlucHV0PyA8
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFlvdSBleGFtcGxlIGlzIG5vdCB2YWxpZCBZ
QU5HLiBJdCBjb250YWlucyBhIGR1cGxpY2F0ZWQgbmFtZQ0KJnF1b3Q7Zm9vJnF1b3Q7Ljxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSmVybmVqPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlB
Tkcgc3BlY2lmeSBycGMncyBpZGVudGlmaWVyIG11c3Qgbm90IGhhdmUgdGhlIHNhbWUgaWRlbnRp
ZmllciBvZg0KPGJyPg0KJmd0OyBkYXRhIGRlZmluaXRpb24gbm9kZT8gPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgWWVzLiBTZWUgc2VjdGlvbiA2LjIu
MSBpbiBSRkM2MDIwLjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtBbGwgbGVhZnMsIGxlYWYtbGlzdHMsIGxpc3RzLA0KY29u
dGFpbmVycywgY2hvaWNlcywgcnBjcyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5v
dGlmaWNhdGlvbnMsIGFuZCBhbnl4bWxzIGRlZmluZWQgKGRpcmVjdGx5DQpvciB0aHJvdWdoIGEg
dXNlczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RhdGVtZW50KSB3aXRoaW4gYSBw
YXJlbnQgbm9kZSBvciBhdCB0aGUgdG9wDQpsZXZlbCBvZiB0aGUgbW9kdWxlPGJyPg0KJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBvciBpdHMgc3VibW9kdWxlcyBzaGFyZSB0aGUgc2FtZSBpZGVu
dGlmaWVyIG5hbWVzcGFjZS4NCiZuYnNwO1RoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IG5hbWVzcGFjZSBpcyBzY29wZWQgdG8gdGhlIHBhcmVudCBub2RlIG9yIG1vZHVsZSwNCnVu
bGVzcyB0aGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBhcmVudCBub2RlIGlzIGEg
Y2FzZSBub2RlLiAmbmJzcDtJbiB0aGF0IGNhc2UsDQp0aGUgbmFtZXNwYWNlIGlzIHNjb3BlZDxi
cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gdGhlIGNsb3Nlc3QgYW5jZXN0b3Igbm9k
ZSB0aGF0IGlzIG5vdCBhIGNhc2UNCm9yIGNob2ljZSBub2RlLjwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEplcm5lajxicj4NClRoYW5rcyBhIGxvdCE8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkJ1dCBJIGRvbid0IHVuZGVyc3RhbmQg
d2h5IHJwYycgaWRlbnRpZmllciBtdXN0IG5vdA0KYmUgdGhlIHNhbWUgdG8gZGF0YSBkZWZpbml0
aW9uIG5vZGUncyBpZGVudGlmaWVyLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IC9mcmFuayA8YnI+DQomZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1
cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4NCnRoaXMgPGJyPg0KJmd0
OyAmZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg
cHJpdmlsZWdlZA0KYW5kIDxicj4NCiZndDsgJmd0OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu
ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7
IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz
Y2xvc3VyZSwNCjxicj4NCiZndDsgJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBv
dGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUNCjxicj4NCiZndDsgJmd0OyBpbmZvcm1h
dGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUN
CnJlY2VpdmVkIDxicj4NCiZndDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxl
dGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tPGJyPg0KJmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp
bmZvcm1hdGlvbiBjb250YWluZWQgaW4NCnRoaXMgPGJyPg0KJmd0OyAmZ3Q7IG1haWwgKGFuZCBh
bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZA0KYW5kIDxi
cj4NCiZndDsgJmd0OyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVz
aXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlPGJyPg0KJmd0OyAmZ3Q7IChzKS4gJm5ic3A7SWYgeW91
IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwNCjxicj4NCiZn
dDsgJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9u
IG9yIHVzZSBvZiB0aGUNCjxicj4NCiZndDsgJmd0OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg
c3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUNCnJlY2VpdmVkIDxicj4NCiZn
dDsgJmd0OyB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1
cyBpbW1lZGlhdGVseS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IG5ldG1vZCBt
YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgbmV0bW9kQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7
IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2Q+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9u
dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBa
VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IGluIHRoaXMNCjxicj4NCiZndDsgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk
IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7IGNvbmZpZGVudGlhbCBhbmQg
aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWU8YnI+DQom
Z3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkg
ZGlzY2xvc3VyZSwgPGJyPg0KJmd0OyByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl
ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0OyBpbmZvcm1hdGlvbiBjb250
YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYgeW91IGhhdmUgcmVjZWl2ZWQN
Cjxicj4NCiZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3Rp
ZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxw
cmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6
IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1l
bnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBh
bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocyku
ICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCBy
ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv
ZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k
IG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+
PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo
ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg
dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQg
aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJ
ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXBy
b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0
aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v
dGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg==

--=_alternative 002EED4A48257CDE_=--


From nobody Tue May 20 01:45:58 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E6E1A02F3; Tue, 20 May 2014 01:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.252
X-Spam-Level: 
X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqAHKQ-YaYGT; Tue, 20 May 2014 01:45:56 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 14E951A04C1; Tue, 20 May 2014 01:45:55 -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 CE0D13B4212; Tue, 20 May 2014 10:45:53 +0200 (CEST)
Date: Tue, 20 May 2014 10:45:53 +0200 (CEST)
Message-Id: <20140520.104553.181790231923236761.mbj@tail-f.com>
To: feng.chong33@zte.com.cn
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn>
References: <20140519201800.GB81067@elstar.jacobs.jacobs-university.de> <OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ayqqRL9nKOXQoKydAUZktMGE1e8
Cc: netmod-bounces@ietf.org, netmod@ietf.org
Subject: Re: [netmod] =?utf-8?b?562U5aSNOiB5YW5nIDEuMSBzdGF0dXMgYW5kIG5leHQg?= =?utf-8?q?steps?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 08:45:57 -0000

SGksDQoNCmZlbmcuY2hvbmczM0B6dGUuY29tLmNuIHdyb3RlOg0KPiBodHRwOi8vd3d3LmlldGYu
b3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMDk3ODguaHRtbA0KPiANCj4g
V2h5IHRoaXMgaXNzdWUgaXMgbm90IGluY2x1ZGVkIGluIGlzc3VlIGxpc3Q/DQoNClRoaXMgZmFs
bHMgdW5kZXIgdGhlIGJyb2FkZXIgWTQ1Lg0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gL2ZyYW5rDQo+
IA0KPiAibmV0bW9kIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IOWGmeS6jiAyMDE0LTA1LTIw
IDA0OjE4OjAwOg0KPiANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQo+ID4g5Y+R5Lu25Lq6OiAgIm5ldG1vZCIgPG5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnPg0KPiA+IA0KPiA+IDIwMTQtMDUtMjAgMDQ6MTgNCj4gPiANCj4g
PiDor7fnrZTlpI0g57uZDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+ID4gDQo+ID4g5pS25Lu25Lq6DQo+ID4gDQo+ID4g
bmV0bW9kQGlldGYub3JnLCANCj4gPiANCj4gPiDmioTpgIENCj4gPiANCj4gPiDkuLvpopgNCj4g
PiANCj4gPiBbbmV0bW9kXSB5YW5nIDEuMSBzdGF0dXMgYW5kIG5leHQgc3RlcHMNCj4gPiANCj4g
PiBIaSwNCj4gPiANCj4gPiB0aGUgV0cgaGFzIGNvbGxlY3RlZCBhIG51bWJlciBvZiBpc3N1ZWQg
dG8gY29uc2lkZXIgZm9yIFlBTkcgMS4xLiBUaGUNCj4gPiByZXN1bHQgY2FuIGJlIGZvdW5kIGhl
cmU6DQo+ID4gDQo+ID4gICAgICAgaHR0cDovL3N2bi50b29scy5pZXRmLm9yZy9zdm4vd2cvbmV0
bW9kL3lhbmctMS4xLw0KPiA+IA0KPiA+IFRoZSBkZWFkbGluZSBmb3Igc3VibWl0dGluZyBpc3N1
ZXMgd2FzIDIwMTQtMDUtMDcuIEl0IHNlZW1zIG9uZSBpc3N1ZQ0KPiA+IGdvdCBzdWJtaXR0ZWQg
cGFzdCB0aGUgZGVhZGxpbmUgYW5kIG9uZSBpc3N1ZSB0aGF0IGNhbWUgdXAgZHVyaW5nIHRoZQ0K
PiA+IGRpc2N1c3Npb25zIHdhcyBub3QgaW5jbHVkZWQgaW4gdGhlIGlzc3VlcyBsaXN0LiBXZSBw
bGFuIHRvIGluY2x1ZGUNCj4gPiB0aGVzZSB0d28gaXNzdWVzIGJ1dCBvdGhlcndpc2UgdGhlIGlz
c3VlIGxpc3QgaXMgY2xvc2VkIG5vdy4NCj4gPiANCj4gPiBDdXJyZW50bHksIGFsbCBpc3N1ZXMg
YXJlIG1hcmtlZCBhcyBORVcuIFRoZSBXRyBub3cgaGFzIHRvIGRlY2lkZQ0KPiA+IHdoaWNoIGlz
c3VlcyBhcmUgaW4gc2NvcGUgb2YgdGhlIFlBTkcgMS4xIGVmZm9ydCAobW92aW5nIHRoZW0gdG8g
T1BFTikNCj4gPiBhbmQgd2hpY2ggb25lcyBhcmUgbm90IGluIHNjb3BlIChtb3ZpbmcgdGhlbSB0
byBERUFEKS4gVG8ga2lja29mZiB0aGlzDQo+ID4gc2VsZWN0aW9uIHByb2Nlc3MsIHRoZSBXRyBj
aGFpcnMsIHdpdGggdGhlIGhlbHAgb2Ygc29tZSBjb3JlDQo+ID4gY29udHJpYnV0b3JzIChuYW1l
bHkgTWFydGluLCBBbmR5LCBMYWRhKSwgaGF2ZSBwcm9kdWNlZCBhIHN0cmF3bWFuDQo+ID4gcHJv
cG9zYWwgdGhhdCB3ZSB3aWxsIGRpc3RyaWJ1dGUgaW4gc3Vic2VxdWVudCBtZXNzYWdlcy4gVGhl
IGdvYWwgaXMNCj4gPiB0byBkZXRlcm1pbmUgb24gd2hpY2ggaXNzdWVzIHRoZSBXRyBzdXBwb3J0
cyB0aGUgc3RyYXdtYW4gcHJvcG9zYWwuDQo+ID4gTm90ZSB0aGF0IHNvbWUgaXNzdWVzIHdlcmUg
bGVmdCB1bmRlY2lkZWQgYmVjYXVzZSB3ZSBjb3VsZCBub3QgY29tZSB1cA0KPiA+IHdpdGggYSBz
dHJhd21hbiAoZWl0aGVyIGJlY2F1c2UgdGhlcmUgYXJlIHNpbXBseSBkaWZmZXJlbnQgb3Bpbmlv
bnMgb3INCj4gPiB0aGVyZSBpcyBhIGxhY2sgb2YgdW5kZXJzdGFuZGluZyBvZiB0aGUgaXNzdWUp
Lg0KPiA+IA0KPiA+IE9uY2Ugd2UgaGF2ZSBzZWxlY3RlZCB0aGUgT1BFTiBpc3N1ZXMsIHdlIHdp
bGwgaGF2ZSB0byBpdGVyYXRlIG92ZXINCj4gPiB0aGVtIHdpdGggdGhlIGdvYWwgdG8gZmluZCBh
Z3JlZW1lbnQgb24gc29sdXRpb25zIHRoYXQgYWRkcmVzcyB0aGUNCj4gPiBpc3N1ZS4gSW4gb3Jk
ZXIgdG8gZG8gdGhhdCwgd2UgcGxhbiB0byBob2xkIHdlZWtseSBjb25mZXJlbmNlIGNhbGxzIG9u
DQo+ID4gV2VkbmVzZGF5cyAxNjowMC0xODowMCBDRVNULCBzdGFydGluZyBmcm9tIEp1bmUgNHRo
LiBCZW5vaXQgaXMNCj4gPiBzdXBwb3J0aW5nIHVzIGJ5IHByb3ZpZGluZyBXZWJFeCBmb3IgdGhl
c2UgdmlydHVhbCBtZWV0aW5ncy4gV2Ugd2lsbA0KPiA+IHNlbmQgb3V0IGZ1cnRoZXIgZGV0YWls
cyBhYm91dCB0aGUgY2FsbHMgaW4gYSBzdWJzZXF1ZW50IG1lc3NhZ2UuDQo+ID4gDQo+ID4gL2pz
DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gLS0gDQo+ID4g
SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4g
Z0dtYkgNCj4gPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEs
IDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg
ICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+IA0KPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1haWxp
bmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg
Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBh
dHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRl
bnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVz
c2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xv
c3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBv
ciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk
LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRl
IGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1
cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQg
YW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNv
bmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBh
ZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBk
aXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0
aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hp
Yml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBk
ZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg==


From nobody Tue May 20 02:28:20 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E571A04E9; Tue, 20 May 2014 02:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.1
X-Spam-Level: 
X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgtxMAcXUFMI; Tue, 20 May 2014 02:28:17 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC571A0327; Tue, 20 May 2014 02:28:16 -0700 (PDT)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id BC62512AFA4D; Tue, 20 May 2014 17:28:01 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s4K9S5lR061486; Tue, 20 May 2014 17:28:05 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <20140520.104553.181790231923236761.mbj@tail-f.com>
References: <20140519201800.GB81067@elstar.jacobs.jacobs-university.de>	<OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn> <20140520.104553.181790231923236761.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
MIME-Version: 1.0
X-KeepSent: 2D974636:6B5AA69D-48257CDE:0033ABD7; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF2D974636.6B5AA69D-ON48257CDE.0033ABD7-48257CDE.0034031A@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Tue, 20 May 2014 17:28:06 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-20 17:28:07, Serialize complete at 2014-05-20 17:28:07
Content-Type: multipart/alternative; boundary="=_alternative 0034031948257CDE_="
X-MAIL: mse01.zte.com.cn s4K9S5lR061486
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GDiS_yldS2jdXWQ3XrFV2ZqqZPQ
Cc: netmod-bounces@ietf.org, netmod@ietf.org
Subject: Re: [netmod] yang 1.1 status and next steps
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 09:28:19 -0000

This is a multipart message in MIME format.

--=_alternative 0034031948257CDE_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

Tm8uIEkgc3VnZ2VzdCByZW1vdmUgdGhlIHNwZWNpZmljYXRpb24gb2YgYWR2ZXJ0aXNlbWVudCBv
ZiBjb25mb3JtYW5jZSBpbiANCllBTkcuDQpZQU5HIHNob3VsZCBkZWZpbmUgd2hhdCB0aGUgY29u
Zm9ybWFuY2UgaXMuDQpIb3cgdG8gYWR2ZXJ0aXNlIGNvbmZvcm1hbmNlIGlzIE5FVENPTkYncyBq
b2IuIA0KL2ZyYW5rDQoNCk1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiDQtNPaIDIw
MTQtMDUtMjAgMTY6NDU6NTM6DQoNCj4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+
IA0KPiAyMDE0LTA1LTIwIDE2OjQ1DQo+IA0KPiDK1bz+yMsNCj4gDQo+IGZlbmcuY2hvbmczM0B6
dGUuY29tLmNuLCANCj4gDQo+ILOty80NCj4gDQo+IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p
dmVyc2l0eS5kZSwgbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcsIA0KbmV0bW9kQGlldGYub3JnDQo+
IA0KPiDW98ziDQo+IA0KPiBSZTogW25ldG1vZF0gtPC4tDogeWFuZyAxLjEgc3RhdHVzIGFuZCBu
ZXh0IHN0ZXBzDQo+IA0KPiBIaSwNCj4gDQo+IGZlbmcuY2hvbmczM0B6dGUuY29tLmNuIHdyb3Rl
Og0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVu
dC9tc2cwOTc4OC5odG1sDQo+ID4gDQo+ID4gV2h5IHRoaXMgaXNzdWUgaXMgbm90IGluY2x1ZGVk
IGluIGlzc3VlIGxpc3Q/DQo+IA0KPiBUaGlzIGZhbGxzIHVuZGVyIHRoZSBicm9hZGVyIFk0NS4N
Cj4gDQo+IA0KPiAvbWFydGluDQo+IA0KPiANCj4gDQo+ID4gL2ZyYW5rDQo+ID4gDQo+ID4gIm5l
dG1vZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTQtMDUtMjAgMDQ6MTg6MDA6
DQo+ID4gDQo+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv
YnMtdW5pdmVyc2l0eS5kZT4gDQo+ID4gPiC3orz+yMs6ICAibmV0bW9kIiA8bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmc+DQo+ID4gPiANCj4gPiA+IDIwMTQtMDUtMjAgMDQ6MTgNCj4gPiA+IA0KPiA+
ID4gx+u08Li0ILj4DQo+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gPiA+IA0KPiA+ID4gytW8/sjLDQo+ID4gPiANCj4g
PiA+IG5ldG1vZEBpZXRmLm9yZywgDQo+ID4gPiANCj4gPiA+ILOty80NCj4gPiA+IA0KPiA+ID4g
1vfM4g0KPiA+ID4gDQo+ID4gPiBbbmV0bW9kXSB5YW5nIDEuMSBzdGF0dXMgYW5kIG5leHQgc3Rl
cHMNCj4gPiA+IA0KPiA+ID4gSGksDQo+ID4gPiANCj4gPiA+IHRoZSBXRyBoYXMgY29sbGVjdGVk
IGEgbnVtYmVyIG9mIGlzc3VlZCB0byBjb25zaWRlciBmb3IgWUFORyAxLjEuIA0KVGhlDQo+ID4g
PiByZXN1bHQgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4gPiANCj4gPiA+ICAgICAgIGh0dHA6Ly9z
dm4udG9vbHMuaWV0Zi5vcmcvc3ZuL3dnL25ldG1vZC95YW5nLTEuMS8NCj4gPiA+IA0KPiA+ID4g
VGhlIGRlYWRsaW5lIGZvciBzdWJtaXR0aW5nIGlzc3VlcyB3YXMgMjAxNC0wNS0wNy4gSXQgc2Vl
bXMgb25lIA0KaXNzdWUNCj4gPiA+IGdvdCBzdWJtaXR0ZWQgcGFzdCB0aGUgZGVhZGxpbmUgYW5k
IG9uZSBpc3N1ZSB0aGF0IGNhbWUgdXAgZHVyaW5nIA0KdGhlDQo+ID4gPiBkaXNjdXNzaW9ucyB3
YXMgbm90IGluY2x1ZGVkIGluIHRoZSBpc3N1ZXMgbGlzdC4gV2UgcGxhbiB0byBpbmNsdWRlDQo+
ID4gPiB0aGVzZSB0d28gaXNzdWVzIGJ1dCBvdGhlcndpc2UgdGhlIGlzc3VlIGxpc3QgaXMgY2xv
c2VkIG5vdy4NCj4gPiA+IA0KPiA+ID4gQ3VycmVudGx5LCBhbGwgaXNzdWVzIGFyZSBtYXJrZWQg
YXMgTkVXLiBUaGUgV0cgbm93IGhhcyB0byBkZWNpZGUNCj4gPiA+IHdoaWNoIGlzc3VlcyBhcmUg
aW4gc2NvcGUgb2YgdGhlIFlBTkcgMS4xIGVmZm9ydCAobW92aW5nIHRoZW0gdG8gDQpPUEVOKQ0K
PiA+ID4gYW5kIHdoaWNoIG9uZXMgYXJlIG5vdCBpbiBzY29wZSAobW92aW5nIHRoZW0gdG8gREVB
RCkuIFRvIGtpY2tvZmYgDQp0aGlzDQo+ID4gPiBzZWxlY3Rpb24gcHJvY2VzcywgdGhlIFdHIGNo
YWlycywgd2l0aCB0aGUgaGVscCBvZiBzb21lIGNvcmUNCj4gPiA+IGNvbnRyaWJ1dG9ycyAobmFt
ZWx5IE1hcnRpbiwgQW5keSwgTGFkYSksIGhhdmUgcHJvZHVjZWQgYSBzdHJhd21hbg0KPiA+ID4g
cHJvcG9zYWwgdGhhdCB3ZSB3aWxsIGRpc3RyaWJ1dGUgaW4gc3Vic2VxdWVudCBtZXNzYWdlcy4g
VGhlIGdvYWwgaXMNCj4gPiA+IHRvIGRldGVybWluZSBvbiB3aGljaCBpc3N1ZXMgdGhlIFdHIHN1
cHBvcnRzIHRoZSBzdHJhd21hbiBwcm9wb3NhbC4NCj4gPiA+IE5vdGUgdGhhdCBzb21lIGlzc3Vl
cyB3ZXJlIGxlZnQgdW5kZWNpZGVkIGJlY2F1c2Ugd2UgY291bGQgbm90IGNvbWUgDQp1cA0KPiA+
ID4gd2l0aCBhIHN0cmF3bWFuIChlaXRoZXIgYmVjYXVzZSB0aGVyZSBhcmUgc2ltcGx5IGRpZmZl
cmVudCBvcGluaW9ucyANCm9yDQo+ID4gPiB0aGVyZSBpcyBhIGxhY2sgb2YgdW5kZXJzdGFuZGlu
ZyBvZiB0aGUgaXNzdWUpLg0KPiA+ID4gDQo+ID4gPiBPbmNlIHdlIGhhdmUgc2VsZWN0ZWQgdGhl
IE9QRU4gaXNzdWVzLCB3ZSB3aWxsIGhhdmUgdG8gaXRlcmF0ZSBvdmVyDQo+ID4gPiB0aGVtIHdp
dGggdGhlIGdvYWwgdG8gZmluZCBhZ3JlZW1lbnQgb24gc29sdXRpb25zIHRoYXQgYWRkcmVzcyB0
aGUNCj4gPiA+IGlzc3VlLiBJbiBvcmRlciB0byBkbyB0aGF0LCB3ZSBwbGFuIHRvIGhvbGQgd2Vl
a2x5IGNvbmZlcmVuY2UgY2FsbHMgDQpvbg0KPiA+ID4gV2VkbmVzZGF5cyAxNjowMC0xODowMCBD
RVNULCBzdGFydGluZyBmcm9tIEp1bmUgNHRoLiBCZW5vaXQgaXMNCj4gPiA+IHN1cHBvcnRpbmcg
dXMgYnkgcHJvdmlkaW5nIFdlYkV4IGZvciB0aGVzZSB2aXJ0dWFsIG1lZXRpbmdzLiBXZSB3aWxs
DQo+ID4gPiBzZW5kIG91dCBmdXJ0aGVyIGRldGFpbHMgYWJvdXQgdGhlIGNhbGxzIGluIGEgc3Vi
c2VxdWVudCBtZXNzYWdlLg0KPiA+ID4gDQo+ID4gPiAvanMNCj4gPiA+IA0KPiA+ID4gDQo+ID4g
PiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gLS0gDQo+ID4gPiBKdWVy
Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i
SA0KPiA+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAy
ODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4gPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg
ICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+ID4gDQo+ID4gPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gWlRFIEluZm9y
bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz
DQo+IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp
dmlsZWdlZCBhbmQgDQo+IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNs
dXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUNCj4gKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50
ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgDQo+IHJlcHJvZHVjdGlvbiwgZGlzdHJp
YnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSANCj4gaW5mb3JtYXRp
b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl
ZCANCj4gdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg
aW1tZWRpYXRlbHkuDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU
aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCj4gbWFpbCAoYW5kIGFueSBhdHRhY2ht
ZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCj4gY29uZmlkZW50
aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3Nl
ZQ0KPiAocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNj
bG9zdXJlLCANCj4gcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5h
dGlvbiBvciB1c2Ugb2YgdGhlIA0KPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIA0KPiB0aGlzIG1haWwgaW4gZXJyb3Is
IHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv
cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp
cyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp
bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg
dXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp
cGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl
ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0
cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy
b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg==

--=_alternative 0034031948257CDE_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5vLiBJIHN1Z2dlc3QgcmVtb3ZlIHRoZSBz
cGVjaWZpY2F0aW9uDQpvZiBhZHZlcnRpc2VtZW50IG9mIGNvbmZvcm1hbmNlIGluIFlBTkcuPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ZQU5HIHNob3VsZCBkZWZp
bmUgd2hhdCB0aGUgY29uZm9ybWFuY2UNCmlzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+SG93IHRvIGFkdmVydGlzZSBjb25mb3JtYW5jZSBpcyBORVRDT05GJ3MN
CmpvYi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4vZnJhbms8
L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5NYXJ0aW4gQmpvcmtsdW5kICZsdDtt
YmpAdGFpbC1mLmNvbSZndDsg0LTT2iAyMDE0LTA1LTIwDQoxNjo0NTo1Mzo8YnI+DQo8YnI+DQom
Z3Q7IE1hcnRpbiBCam9ya2x1bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OyA8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxNC0wNS0yMCAxNjo0NTwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUuY29t
LmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCz
rcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlLCBuZXRtb2QtYm91bmNlc0BpZXRmLm9y
ZywgbmV0bW9kQGlldGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
IDxicj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8
YnI+DQomZ3Q7IFJlOiBbbmV0bW9kXSC08Li0OiB5YW5nIDEuMSBzdGF0dXMgYW5kIG5leHQgc3Rl
cHM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIaSw8
YnI+DQomZ3Q7IDxicj4NCiZndDsgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0K
Jmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cwOTc4OC5odG1sIj48dHQ+PGZvbnQgc2l6ZT0y
Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cw
OTc4OC5odG1sPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyBXaHkgdGhpcyBpc3N1ZSBpcyBub3QgaW5jbHVkZWQgaW4gaXNzdWUg
bGlzdD88YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBmYWxscyB1bmRlciB0aGUgYnJvYWRlciBZ
NDUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgL21hcnRpbjxicj4NCiZndDsgPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAvZnJhbms8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmcmZ3Q7INC009ogMjAxNC0wNS0yMA0KMDQ6MTg6MDA6PGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgt6K8/sjLOiAm
bmJzcDsmcXVvdDtuZXRtb2QmcXVvdDsgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0Ozxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDIwMTQtMDUtMjAgMDQ6MTg8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDH67TwuLQguPg8YnI+DQom
Z3Q7ICZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBq
YWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyDK1bz+yMs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBu
ZXRtb2RAaWV0Zi5vcmcsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ILOty808YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDW98ziPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgW25ldG1vZF0geWFuZyAxLjEgc3Rh
dHVzIGFuZCBuZXh0IHN0ZXBzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgSGksPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIFdHIGhh
cyBjb2xsZWN0ZWQgYSBudW1iZXIgb2YgaXNzdWVkIHRvIGNvbnNpZGVyIGZvcg0KWUFORyAxLjEu
IFRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlc3VsdCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8
L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vc3ZuLnRvb2xzLmlldGYub3JnL3N2bi93Zy9uZXRt
b2QveWFuZy0xLjEvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly9zdm4udG9vbHMuaWV0Zi5vcmcv
c3ZuL3dnL25ldG1vZC95YW5nLTEuMS88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgZGVhZGxpbmUgZm9y
IHN1Ym1pdHRpbmcgaXNzdWVzIHdhcyAyMDE0LTA1LTA3LiBJdCBzZWVtcw0Kb25lIGlzc3VlPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgZ290IHN1Ym1pdHRlZCBwYXN0IHRoZSBkZWFkbGluZSBhbmQgb25l
IGlzc3VlIHRoYXQgY2FtZQ0KdXAgZHVyaW5nIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGRpc2N1
c3Npb25zIHdhcyBub3QgaW5jbHVkZWQgaW4gdGhlIGlzc3VlcyBsaXN0LiBXZSBwbGFuDQp0byBp
bmNsdWRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlc2UgdHdvIGlzc3VlcyBidXQgb3RoZXJ3aXNl
IHRoZSBpc3N1ZSBsaXN0IGlzIGNsb3NlZA0Kbm93Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IEN1cnJlbnRseSwgYWxsIGlzc3VlcyBhcmUgbWFya2VkIGFzIE5FVy4g
VGhlIFdHIG5vdyBoYXMNCnRvIGRlY2lkZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHdoaWNoIGlzc3Vl
cyBhcmUgaW4gc2NvcGUgb2YgdGhlIFlBTkcgMS4xIGVmZm9ydCAobW92aW5nDQp0aGVtIHRvIE9Q
RU4pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYW5kIHdoaWNoIG9uZXMgYXJlIG5vdCBpbiBzY29wZSAo
bW92aW5nIHRoZW0gdG8gREVBRCkuIFRvDQpraWNrb2ZmIHRoaXM8YnI+DQomZ3Q7ICZndDsgJmd0
OyBzZWxlY3Rpb24gcHJvY2VzcywgdGhlIFdHIGNoYWlycywgd2l0aCB0aGUgaGVscCBvZiBzb21l
DQpjb3JlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29udHJpYnV0b3JzIChuYW1lbHkgTWFydGluLCBB
bmR5LCBMYWRhKSwgaGF2ZSBwcm9kdWNlZA0KYSBzdHJhd21hbjxicj4NCiZndDsgJmd0OyAmZ3Q7
IHByb3Bvc2FsIHRoYXQgd2Ugd2lsbCBkaXN0cmlidXRlIGluIHN1YnNlcXVlbnQgbWVzc2FnZXMu
DQpUaGUgZ29hbCBpczxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIGRldGVybWluZSBvbiB3aGljaCBp
c3N1ZXMgdGhlIFdHIHN1cHBvcnRzIHRoZSBzdHJhd21hbg0KcHJvcG9zYWwuPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgTm90ZSB0aGF0IHNvbWUgaXNzdWVzIHdlcmUgbGVmdCB1bmRlY2lkZWQgYmVjYXVz
ZSB3ZSBjb3VsZA0Kbm90IGNvbWUgdXA8YnI+DQomZ3Q7ICZndDsgJmd0OyB3aXRoIGEgc3RyYXdt
YW4gKGVpdGhlciBiZWNhdXNlIHRoZXJlIGFyZSBzaW1wbHkgZGlmZmVyZW50DQpvcGluaW9ucyBv
cjxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZXJlIGlzIGEgbGFjayBvZiB1bmRlcnN0YW5kaW5nIG9m
IHRoZSBpc3N1ZSkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT25j
ZSB3ZSBoYXZlIHNlbGVjdGVkIHRoZSBPUEVOIGlzc3Vlcywgd2Ugd2lsbCBoYXZlIHRvIGl0ZXJh
dGUNCm92ZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGVtIHdpdGggdGhlIGdvYWwgdG8gZmluZCBh
Z3JlZW1lbnQgb24gc29sdXRpb25zIHRoYXQgYWRkcmVzcw0KdGhlPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgaXNzdWUuIEluIG9yZGVyIHRvIGRvIHRoYXQsIHdlIHBsYW4gdG8gaG9sZCB3ZWVrbHkgY29u
ZmVyZW5jZQ0KY2FsbHMgb248YnI+DQomZ3Q7ICZndDsgJmd0OyBXZWRuZXNkYXlzIDE2OjAwLTE4
OjAwIENFU1QsIHN0YXJ0aW5nIGZyb20gSnVuZSA0dGguIEJlbm9pdA0KaXM8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBzdXBwb3J0aW5nIHVzIGJ5IHByb3ZpZGluZyBXZWJFeCBmb3IgdGhlc2UgdmlydHVh
bCBtZWV0aW5ncy4NCldlIHdpbGw8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZW5kIG91dCBmdXJ0aGVy
IGRldGFpbHMgYWJvdXQgdGhlIGNhbGxzIGluIGEgc3Vic2VxdWVudA0KbWVzc2FnZS48YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAvanM8YnI+DQomZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAtLSA8YnI+DQomZ3Q7ICZndDsgJmd0
OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
Ow0KSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUGhv
bmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cw0K
UmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnk8YnI+DQomZ3Q7ICZndDsgJmd0OyBGYXg6ICZu
YnNwOyArNDkgNDIxIDIwMCAzMTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJmx0Ozwv
Zm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+
PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+
PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAm
Z3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhy
ZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0Pjxmb250
IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvZm9u
dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS08YnI+DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpczxicj4NCiZndDsgbWFpbCAoYW5kIGFueSBhdHRh
Y2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCA8YnI+DQomZ3Q7
IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo
ZSBhZGRyZXNzZWU8YnI+DQomZ3Q7IChzKS4gJm5ic3A7SWYgeW91IGFyZSBub3QgYW4gaW50ZW5k
ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgPGJyPg0KJmd0OyByZXByb2R1Y3Rpb24sIGRp
c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgPGJyPg0KJmd0
OyBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gJm5ic3A7SWYg
eW91IGhhdmUgcmVjZWl2ZWQNCjxicj4NCiZndDsgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2Ug
ZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K
Jmd0OyAmZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv
biBjb250YWluZWQgaW4NCnRoaXM8YnI+DQomZ3Q7IG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0
cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgPGJyPg0KJmd0OyBjb25maWRl
bnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVz
c2VlPGJyPg0KJmd0OyAocykuICZuYnNwO0lmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw
aWVudCwgYW55IGRpc2Nsb3N1cmUsIDxicj4NCiZndDsgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp
b24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIDxicj4NCiZndDsgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZl
IHJlY2VpdmVkDQo8YnI+DQomZ3Q7IHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBp
dCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Ljxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHBy
ZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog
VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVu
dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFu
ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g
IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJl
cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m
IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlv
dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg
bm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K

--=_alternative 0034031948257CDE_=--


From nobody Tue May 20 02:55:15 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174651A0676; Tue, 20 May 2014 02:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9oD_NL2Dhci; Tue, 20 May 2014 02:55:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2D01A05F5; Tue, 20 May 2014 02:55:12 -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 7BCDB3B4215; Tue, 20 May 2014 11:55:10 +0200 (CEST)
Date: Tue, 20 May 2014 11:55:10 +0200 (CEST)
Message-Id: <20140520.115510.916063469345208315.mbj@tail-f.com>
To: feng.chong33@zte.com.cn
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <OF2D974636.6B5AA69D-ON48257CDE.0033ABD7-48257CDE.0034031A@zte.com.cn>
References: <OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn> <20140520.104553.181790231923236761.mbj@tail-f.com> <OF2D974636.6B5AA69D-ON48257CDE.0033ABD7-48257CDE.0034031A@zte.com.cn>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Fkj0r_i1Nw4IGnhd3jTvlFu3C80
Cc: netmod-bounces@ietf.org, netmod@ietf.org
Subject: Re: [netmod] yang 1.1 status and next steps
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 09:55:14 -0000

feng.chong33@zte.com.cn wrote:
> No. I suggest remove the specification of advertisement of conformance in 
> YANG.
> YANG should define what the conformance is.
> How to advertise conformance is NETCONF's job. 

So this can be your proposed solution to Y45.


/martin


From nobody Tue May 20 08:21:07 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760A01A0744 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 08:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyKUxTUatJbQ for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 08:21:01 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAB81A0745 for <netmod@ietf.org>; Tue, 20 May 2014 08:20:59 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id r5so985682qcx.35 for <netmod@ietf.org>; Tue, 20 May 2014 08:20:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v6wb2uGJVq/gLWyotixa3WzxK1kSpC0bjOQtomtGX+M=; b=WG/XMt1iNKsJdyK4poiI3RAHMJUZpqqx4YoSxfqf6K2wvC9GIItO3qif0m+Z/0wR9y 2NLjs1NxAaBtMeZrxYHGBc6mVvzaXtbcdIpLrQr3RJeAOzDZHfTOvaeJGBN7MgeVHOqW 705EpUPfBeXzil3gXqcFWdPrsoqb5rmtr91xZed/5DwZeAsTIt2Xcx6ozH8cqK4qnLl0 y/COhX9ZfcptKQ6r4ckIGmyHnqwqAp6jqnp1fhOMtF4mqIKVns/CLCDfCoY+13Rjy9P0 ICpqi+GmzTNXPb7dXl+0PMkigrlMhYYv+qeygWYr5mS8tfTlQEII0nRfyMqg13kh71LT sxqw==
X-Gm-Message-State: ALoCoQloDjqAjg0D4nTOHui4x0521oiauweOFLFzpizNKY9erhQ8QKKCTGnIlCbNdzmdfKfzBTsH
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr57197242qgy.34.1400599258200; Tue, 20 May 2014 08:20:58 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Tue, 20 May 2014 08:20:58 -0700 (PDT)
In-Reply-To: <20140520.115510.916063469345208315.mbj@tail-f.com>
References: <OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn> <20140520.104553.181790231923236761.mbj@tail-f.com> <OF2D974636.6B5AA69D-ON48257CDE.0033ABD7-48257CDE.0034031A@zte.com.cn> <20140520.115510.916063469345208315.mbj@tail-f.com>
Date: Tue, 20 May 2014 08:20:58 -0700
Message-ID: <CABCOCHQTnMhEiZ-Z54WL=Bv3GU2PrpYDQ+XKt8GaVuk=OnDd+g@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: multipart/alternative; boundary=001a11c126ba4216a804f9d66d52
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1BIVM9V-2uMiM01yDqF0xF4ANLA
Cc: netmod <netmod-bounces@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] yang 1.1 status and next steps
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 15:21:02 -0000

--001a11c126ba4216a804f9d66d52
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 20, 2014 at 2:55 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> feng.chong33@zte.com.cn wrote:
> > No. I suggest remove the specification of advertisement of conformance in
> > YANG.
> > YANG should define what the conformance is.
> > How to advertise conformance is NETCONF's job.
>
> So this can be your proposed solution to Y45.
>
>
Y45 is really about how YANG conformance is specified.
Advertising service-level conformance instead of a list
of modules is a minor part of the problem.

I think there is a separate issue here wrt/ YANG module advertisement.
RFC 6020 is very NETCONF specific in this area. RESTCONF
does not advertise capabilities at all.  YANG needs to be
protocol-independent or at least be specific for NETCONF and RESTCONF.
There is at least a document clarification issue here.



> /martin
>

Andy


>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a11c126ba4216a804f9d66d52
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, May 20, 2014 at 2:55 AM, Martin Bjorklund <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><a href=3D"mailto:feng.chong33@zte.com.cn">f=
eng.chong33@zte.com.cn</a> wrote:<br>
&gt; No. I suggest remove the specification of advertisement of conformance=
 in<br>
&gt; YANG.<br>
&gt; YANG should define what the conformance is.<br>
&gt; How to advertise conformance is NETCONF&#39;s job.<br>
<br>
So this can be your proposed solution to Y45.<br>
<br></blockquote><div><br></div><div>Y45 is really about how YANG conforman=
ce is specified.</div><div>Advertising service-level conformance instead of=
 a list</div><div>of modules is a minor part of the problem.</div><div>
<br></div><div>I think there is a separate issue here wrt/ YANG module adve=
rtisement.</div><div>RFC 6020 is very NETCONF specific in this area. RESTCO=
NF</div><div>does not advertise capabilities at all. =A0YANG needs to be</d=
iv>
<div>protocol-independent or at least be specific for NETCONF and RESTCONF.=
</div><div>There is at least a document clarification issue here.</div><div=
><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
/martin<br></blockquote><div><br></div><div>Andy</div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
_______________________________________________<br>
netmod mailing list<br>
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/netmod</a><br>
</blockquote></div><br></div></div>

--001a11c126ba4216a804f9d66d52--


From nobody Tue May 20 12:21:41 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E064F1A0388 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 12:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33PEHEvr05Jf for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 12:21:38 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D3D1A0217 for <netmod@ietf.org>; Tue, 20 May 2014 12:21:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 579659F6; Tue, 20 May 2014 21:21:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a8cg1U-2U80X; Tue, 20 May 2014 21:21:35 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 20 May 2014 21:21:35 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D158620017; Tue, 20 May 2014 21:21:35 +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 rOsGnZ5wzqiH; Tue, 20 May 2014 21:21:35 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E750E20013; Tue, 20 May 2014 21:21:33 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id D41002CEC133; Tue, 20 May 2014 21:21:33 +0200 (CEST)
Date: Tue, 20 May 2014 21:21:33 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: feng.chong33@zte.com.cn
Message-ID: <20140520192133.GC83689@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: feng.chong33@zte.com.cn, Jernej Tuljak <jernej.tuljak@mg-soft.si>, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, netmod@ietf.org
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn> <537B1158.1010708@mg-soft.com> <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hQRiY0Az2Zr2hyu_GKO3CmBDwRA
Cc: dai.xianxian@zte.com.cn, cheng.zhu1@zte.com.cn, du.baowei23@zte.com.cn, netmod@ietf.org
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 19:21:40 -0000

On Tue, May 20, 2014 at 04:32:33PM +0800, feng.chong33@zte.com.cn wrote:
>
> But I don't understand why rpc' identifier must not be the same to data 
> definition node's identifier.

I think the examples in the thread motivate why disallowing name
clashes is a good idea.

/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 nobody Tue May 20 12:45:07 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF511A019B for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 12:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqMVSPjff7Sn for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 12:45:03 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874841A0388 for <netmod@ietf.org>; Tue, 20 May 2014 12:45:03 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so1533946qcv.33 for <netmod@ietf.org>; Tue, 20 May 2014 12:45:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OVTLaD42dPcWGDAWlyutzS9gUxPHfJtoYFYbVTe4Kuo=; b=Y/g9I+ZS6gCCHJWFwPm0DTq3U2pbS1bgk4wzYP4DUUAra169OIAeUYlCk9K9uVi6Zm acbFS1tHgssvZ4Kghmk9Vh2iK0x+qeKSpMa8Fm9a7C77kdJjc4SxBnUTT+N8rRyNYx02 uMXGQFQdlknLORAYdpAGrc3kIofDPwA5JS59EQvtT+Ei4r1/nxK3kZa+7vqT7UYqcBOD Zide664C4QLTUpfzKq7XTw7PBdmOfW7p5FiQ3FPOKaCqmBuELiQjbtVEH4zBEkJkRB3X BtOqaCcDK5gFopQz1CORtuAt8nBkbCWO9c3Tvcp0qCfbMPP0aDQRPIpcxfGl1RPIteV9 +mfA==
X-Gm-Message-State: ALoCoQkMXlA+mpfK/EF0On9X7X0GglJJVfprs2n48miab7meHBAzmAWu88h+yWflB+WPYIiEa4Fx
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr59489057qgo.25.1400615102460; Tue, 20 May 2014 12:45:02 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Tue, 20 May 2014 12:45:02 -0700 (PDT)
In-Reply-To: <20140520192133.GC83689@elstar.jacobs.jacobs-university.de>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn> <537B1158.1010708@mg-soft.com> <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn> <20140520192133.GC83689@elstar.jacobs.jacobs-university.de>
Date: Tue, 20 May 2014 12:45:02 -0700
Message-ID: <CABCOCHQE-dwYKK=CJ4XuyiY-runSzxJVpWan4B9GM_mznj2bUw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, feng.chong33@zte.com.cn,  Jernej Tuljak <jernej.tuljak@mg-soft.si>, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn,  dai.xianxian@zte.com.cn, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c17334a66e6a04f9da1d43
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9u6IOFp8LdxbN4dZmQYQJLVXUdU
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 19:45:05 -0000

--001a11c17334a66e6a04f9da1d43
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 20, 2014 at 12:21 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, May 20, 2014 at 04:32:33PM +0800, feng.chong33@zte.com.cn wrote:
> >
> > But I don't understand why rpc' identifier must not be the same to data
> > definition node's identifier.
>
> I think the examples in the thread motivate why disallowing name
> clashes is a good idea.
>
>
This was a design decision in order to make the path-stmt
easier to use (e.g., so augment-stmt works consistently
across rpc, data, and notification statements).


/js
>
>
Andy

--001a11c17334a66e6a04f9da1d43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, May 20, 2014 at 12:21 PM, Juergen Schoenwaelder <span dir=
=3D"ltr">&lt;<a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=
=3D"_blank">j.schoenwaelder@jacobs-university.de</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Tue, May 20, 2014 at 04:32:33PM +0800, <a=
 href=3D"mailto:feng.chong33@zte.com.cn">feng.chong33@zte.com.cn</a> wrote:=
<br>

&gt;<br>
&gt; But I don&#39;t understand why rpc&#39; identifier must not be the sam=
e to data<br>
&gt; definition node&#39;s identifier.<br>
<br>
I think the examples in the thread motivate why disallowing name<br>
clashes is a good idea.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>This was a design decision in order to make the path=
-stmt</div><div>easier to use (e.g., so augment-stmt works consistently</di=
v>
<div>across rpc, data, and notification statements).</div><div><br></div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb"><font co=
lor=3D"#888888">
/js<br>
<br></font></span></blockquote><div><br></div><div>Andy</div><div>=A0</div>=
</div></div></div>

--001a11c17334a66e6a04f9da1d43--


From nobody Tue May 20 12:59:25 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD62B1A038E for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 12:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvlo_Reddsu0 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 12:59:20 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F421A03B3 for <netmod@ietf.org>; Tue, 20 May 2014 12:59:20 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EDAC41113 for <netmod@ietf.org>; Tue, 20 May 2014 21:59:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9HUgQXHyXzHc for <netmod@ietf.org>; Tue, 20 May 2014 21:59:18 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Tue, 20 May 2014 21:59:18 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3880920017 for <netmod@ietf.org>; Tue, 20 May 2014 21:59:18 +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 LOf8tLQaKDlZ; Tue, 20 May 2014 21:59:17 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A83C320013; Tue, 20 May 2014 21:59:16 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id E5DD72CEC599; Tue, 20 May 2014 21:59:15 +0200 (CEST)
Date: Tue, 20 May 2014 21:59:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20140520195915.GA86272@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GgYFjKb48zXkgozhu6SFuHGNf_k
Subject: [netmod] NETMOD WG Virtual Interim Meetings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 19:59:23 -0000

The NETMOD WG will hold a series of weekly virtual interim meetings.
The meetings will take place on Wednesdays between 16:00 and 18:00
CEST. The first meeting will be on Wednesday 2014-06-04. The agenda is
to iterate over the YANG 1.1 issues list with the goal to close open
issues until there are none left open.

The WebEx details can be found below.

-----------------------------------------------------------------------
JOIN USING WebEx

Go To:
https://cisco.webex.com/cisco/j.php?J=202712764&PW=NOWQ0ZTRhOTkz

Meeting Password ----- netmod
Meeting Number ----- 202 712 764

----------------------------------------------------------------
ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES
----------------------------------------------------------------
Please dial the local access number for your area from the list below:
-  San Jose/Milpitas (408) area:  525-6800
-  RTP (919) area:  392-3330

Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones).  " If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number." Please use the call-back option whenever possible and otherwise dial local numbers only.  The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330

US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111  Germany: +49.619.6773.9002

Japan: +81.3.5763.9394  China: +86.10.8515.5666

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.

/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 nobody Tue May 20 23:03:04 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7905F1A0444; Tue, 20 May 2014 23:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjwUTzl6S762; Tue, 20 May 2014 23:02:59 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D1A1A027A; Tue, 20 May 2014 23:02:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0E9E31113; Wed, 21 May 2014 08:02:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q4AqdC6ohqTk; Wed, 21 May 2014 08:02:57 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 May 2014 08:02:57 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7874C2002C; Wed, 21 May 2014 08:02:57 +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 L8VpFHvp1J3b; Wed, 21 May 2014 08:02:57 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 063D820013; Wed, 21 May 2014 08:02:55 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id E681B2CECF36; Wed, 21 May 2014 08:02:54 +0200 (CEST)
Date: Wed, 21 May 2014 08:02:54 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20140521060254.GC87061@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, feng.chong33@zte.com.cn, netmod@ietf.org, netmod-bounces@ietf.org
References: <OF14458D6E.4E76B7E5-ON48257CDE.0005239C-48257CDE.00054D49@zte.com.cn> <20140520.104553.181790231923236761.mbj@tail-f.com> <OF2D974636.6B5AA69D-ON48257CDE.0033ABD7-48257CDE.0034031A@zte.com.cn> <20140520.115510.916063469345208315.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140520.115510.916063469345208315.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E2npUlepOKYATz_KVOtstsSbd4k
Cc: netmod-bounces@ietf.org, netmod@ietf.org
Subject: Re: [netmod] yang 1.1 status and next steps
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 06:03:01 -0000

On Tue, May 20, 2014 at 11:55:10AM +0200, Martin Bjorklund wrote:
> feng.chong33@zte.com.cn wrote:
> > No. I suggest remove the specification of advertisement of conformance in 
> > YANG.
> > YANG should define what the conformance is.
> > How to advertise conformance is NETCONF's job. 
> 
> So this can be your proposed solution to Y45.
> 

Could be even more a solution to Y16, no?

Perhaps the easiest from a process point of view is to add an issue
and then we can during the discussion whether it is in scope for YANG
1.1 determine whether it falls into another issue or not. Personally,
I do not see how the solution can be implemented in a meaningful way
since we are not chartered to revise NETCONF. But that is already a
different discussion.

/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 nobody Tue May 20 23:12:48 2014
Return-Path: <feng.chong33@zte.com.cn>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB331A0484 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 23:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.601
X-Spam-Level: 
X-Spam-Status: No, score=-97.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SORTED_RECIPS=2.499, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl2lyNeqL3Ye for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 23:12:22 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 695021A04A7 for <netmod@ietf.org>; Tue, 20 May 2014 23:12:18 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 4798312BF1BE for <netmod@ietf.org>; Wed, 21 May 2014 14:12:05 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 4EE8DCC9D6B; Wed, 21 May 2014 14:12:04 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s4L6C5mx012006; Wed, 21 May 2014 14:12:05 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn)
In-Reply-To: <CABCOCHQE-dwYKK=CJ4XuyiY-runSzxJVpWan4B9GM_mznj2bUw@mail.gmail.com>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn>	<537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn>	<537B1158.1010708@mg-soft.com> <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn>	<20140520192133.GC83689@elstar.jacobs.jacobs-university.de> <CABCOCHQE-dwYKK=CJ4XuyiY-runSzxJVpWan4B9GM_mznj2bUw@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
MIME-Version: 1.0
X-KeepSent: 51CC236D:D5BCDC46-48257CDF:002192FA; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF51CC236D.D5BCDC46-ON48257CDF.002192FA-48257CDF.0022115F@zte.com.cn>
From: feng.chong33@zte.com.cn
Date: Wed, 21 May 2014 14:12:06 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-21 14:12:07, Serialize complete at 2014-05-21 14:12:07
Content-Type: multipart/alternative; boundary="=_alternative 0022115D48257CDF_="
X-MAIL: mse01.zte.com.cn s4L6C5mx012006
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uy7fLLB1_3TNxkRAUztpTHDmxVQ
Cc: dai.xianxian@zte.com.cn, "netmod@ietf.org" <netmod@ietf.org>, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 06:12:24 -0000

This is a multipart message in MIME format.

--=_alternative 0022115D48257CDF_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

L2ZyYW5rDQoNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiDQtNPaIDIwMTQtMDUt
MjEgMDM6NDU6MDI6DQoNCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IA0KPiAy
MDE0LTA1LTIxIDAzOjQ1DQo+IA0KPiDK1bz+yMsNCj4gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiwgDQo+IGZlbmcuY2hvbmcz
M0B6dGUuY29tLmNuLCBKZXJuZWogVHVsamFrIDxqZXJuZWoudHVsamFrQG1nLXNvZnQuc2k+LCAN
Cj4gZHUuYmFvd2VpMjNAenRlLmNvbS5jbiwgY2hlbmcuemh1MUB6dGUuY29tLmNuLCANCj4gZGFp
LnhpYW54aWFuQHp0ZS5jb20uY24sICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+
LCANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9u
IGFib3V0IHJwYydzIHhwYXRoDQo+IA0KPiANCg0KPiBPbiBUdWUsIE1heSAyMCwgMjAxNCBhdCAx
MjoyMSBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDwNCj4gai5zY2hvZW53YWVsZGVyQGphY29i
cy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gT24gVHVlLCBNYXkgMjAsIDIwMTQgYXQgMDQ6MzI6
MzNQTSArMDgwMCwgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4NCj4gPiBCdXQg
SSBkb24ndCB1bmRlcnN0YW5kIHdoeSBycGMnIGlkZW50aWZpZXIgbXVzdCBub3QgYmUgdGhlIHNh
bWUgdG8gDQpkYXRhDQo+ID4gZGVmaW5pdGlvbiBub2RlJ3MgaWRlbnRpZmllci4NCj4gDQo+IEkg
dGhpbmsgdGhlIGV4YW1wbGVzIGluIHRoZSB0aHJlYWQgbW90aXZhdGUgd2h5IGRpc2FsbG93aW5n
IG5hbWUNCj4gY2xhc2hlcyBpcyBhIGdvb2QgaWRlYS4NCg0KPiANCj4gVGhpcyB3YXMgYSBkZXNp
Z24gZGVjaXNpb24gaW4gb3JkZXIgdG8gbWFrZSB0aGUgcGF0aC1zdG10DQo+IGVhc2llciB0byB1
c2UgKGUuZy4sIHNvIGF1Z21lbnQtc3RtdCB3b3JrcyBjb25zaXN0ZW50bHkNCj4gYWNyb3NzIHJw
YywgZGF0YSwgYW5kIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnRzKS4NCj4gDQpJIGRvbid0IHRoaW5r
IGl0J3MgYSBnb29kIGRlc2lnbi4gQWRkaW5nIGEgc3Vic3RhdGVtZW50IHN1Y2ggYXMgJ3R5cGUn
IHRvIA0KaW5kaWNhdGUgdGhlIHRhcmdldCBub2RlIGJlbG9uZ3MgdG8gd2hpY2ggdHlwZShlLmcu
IGRhdGEvcnBjL25vdGlmaWNhdGlvbikNCmlzIGEgYmV0dGVyIHNvbHV0aW9uLg0KPiAvanMNCg0K
PiANCj4gQW5keQ0KPiAgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFu
c21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBp
bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv
dSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVj
dGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBp
bmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZl
IHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5
IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp
bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJh
bnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMg
aW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5
b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1
Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlm
eSB1cyBpbW1lZGlhdGVseS4NCg==

--=_alternative 0022115D48257CDF_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyDQ
tNPaIDIwMTQtMDUtMjENCjAzOjQ1OjAyOjxicj4NCjxicj4NCiZndDsgQW5keSBCaWVybWFuICZs
dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyAyMDE0LTA1LTIxIDAzOjQ1PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7LA0KPGJyPg0KJmd0OyBmZW5nLmNob25nMzNAenRl
LmNvbS5jbiwgSmVybmVqIFR1bGphayAmbHQ7amVybmVqLnR1bGpha0BtZy1zb2Z0LnNpJmd0OywN
Cjxicj4NCiZndDsgZHUuYmFvd2VpMjNAenRlLmNvbS5jbiwgY2hlbmcuemh1MUB6dGUuY29tLmNu
LCA8YnI+DQomZ3Q7IGRhaS54aWFueGlhbkB6dGUuY29tLmNuLCAmcXVvdDtuZXRtb2RAaWV0Zi5v
cmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDssDQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBbbmV0bW9kXSBBIHF1ZXN0aW9uIGFib3V0IHJw
YydzIHhwYXRoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn
dDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIFR1ZSwg
TWF5IDIwLCAyMDE0IGF0IDEyOjIxIFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCiZsdDs8YnI+
DQomZ3Q7IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsgd3JvdGU6PC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIFR1ZSwgTWF5IDIwLCAyMDE0
IGF0IDA0OjMyOjMzUE0gKzA4MDAsIGZlbmcuY2hvbmczM0B6dGUuY29tLmNuDQp3cm90ZTo8YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgcnBj
JyBpZGVudGlmaWVyIG11c3Qgbm90IGJlIHRoZSBzYW1lDQp0byBkYXRhPGJyPg0KJmd0OyAmZ3Q7
IGRlZmluaXRpb24gbm9kZSdzIGlkZW50aWZpZXIuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhp
bmsgdGhlIGV4YW1wbGVzIGluIHRoZSB0aHJlYWQgbW90aXZhdGUgd2h5IGRpc2FsbG93aW5nIG5h
bWU8YnI+DQomZ3Q7IGNsYXNoZXMgaXMgYSBnb29kIGlkZWEuPGJyPg0KPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhpcyB3YXMgYSBkZXNpZ24gZGVj
aXNpb24gaW4gb3JkZXIgdG8gbWFrZSB0aGUgcGF0aC1zdG10PC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IGVhc2llciB0byB1c2UgKGUuZy4sIHNvIGF1Z21lbnQtc3RtdCB3
b3JrcyBjb25zaXN0ZW50bHk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
YWNyb3NzIHJwYywgZGF0YSwgYW5kIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnRzKS48L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj5JIGRvbid0IHRoaW5rIGl0J3MgYSBnb29kIGRlc2lnbi4gQWRkaW5nIGEgc3Vic3Rh
dGVtZW50DQpzdWNoIGFzICd0eXBlJyB0byBpbmRpY2F0ZSB0aGUgdGFyZ2V0IG5vZGUgYmVsb25n
cyB0byB3aGljaCB0eXBlKGUuZy4gZGF0YS9ycGMvbm90aWZpY2F0aW9uKTwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+aXMgYSBiZXR0ZXIgc29sdXRpb24uPGJyPg0KJmd0OyAvanM8
YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBB
bmR5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48
L3R0Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl
Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFu
ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg
Y29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl
IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55
IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu
YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv
aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl
IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJy
Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy
aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBh
bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29u
ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFk
ZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRp
c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRp
b24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl
bGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K

--=_alternative 0022115D48257CDF_=--


From nobody Tue May 20 23:45:46 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043DD1A02E2 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 23:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0Ad2QfllJVN for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 23:45:42 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1701A040A for <netmod@ietf.org>; Tue, 20 May 2014 23:45:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 69CB91113; Wed, 21 May 2014 08:45:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sqH_9rbts-0D; Wed, 21 May 2014 08:45:39 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 May 2014 08:45:39 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B53D920017; Wed, 21 May 2014 08:45:39 +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 0eE6h6IxDvZc; Wed, 21 May 2014 08:45:39 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3393A20013; Wed, 21 May 2014 08:45:38 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 6984F2CED039; Wed, 21 May 2014 08:45:37 +0200 (CEST)
Date: Wed, 21 May 2014 08:45:36 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: feng.chong33@zte.com.cn
Message-ID: <20140521064536.GA87257@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: feng.chong33@zte.com.cn, Andy Bierman <andy@yumaworks.com>, cheng.zhu1@zte.com.cn, dai.xianxian@zte.com.cn, du.baowei23@zte.com.cn, Jernej Tuljak <jernej.tuljak@mg-soft.si>, "netmod@ietf.org" <netmod@ietf.org>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn> <537B1158.1010708@mg-soft.com> <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn> <20140520192133.GC83689@elstar.jacobs.jacobs-university.de> <CABCOCHQE-dwYKK=CJ4XuyiY-runSzxJVpWan4B9GM_mznj2bUw@mail.gmail.com> <OF51CC236D.D5BCDC46-ON48257CDF.002192FA-48257CDF.0022115F@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF51CC236D.D5BCDC46-ON48257CDF.002192FA-48257CDF.0022115F@zte.com.cn>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/I2sRZVSiTwmcZILNdA0BPcJxeSw
Cc: dai.xianxian@zte.com.cn, "netmod@ietf.org" <netmod@ietf.org>, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 06:45:44 -0000

On Wed, May 21, 2014 at 02:12:06PM +0800, feng.chong33@zte.com.cn wrote:
> > 
> > This was a design decision in order to make the path-stmt
> > easier to use (e.g., so augment-stmt works consistently
> > across rpc, data, and notification statements).
> > 
> I don't think it's a good design. Adding a substatement such as 'type' to 
> indicate the target node belongs to which type(e.g. data/rpc/notification)
> is a better solution.

I do not see which real-world problem you are having with the current
way YANG works. Note that the YANG 1.1 effort is constrained by a
number of things, one of them is backwards compatibility with YANG
1.0. Changing the path-stmt or the schema tree namespaces hardly can
be done in a backwards compatible way.

And anyway, the window for submitting new issues is closed.

/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 nobody Tue May 20 23:51:32 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF4B1A0469 for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 23:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnK4isuCcWeh for <netmod@ietfa.amsl.com>; Tue, 20 May 2014 23:51:28 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B701A02E2 for <netmod@ietf.org>; Tue, 20 May 2014 23:51:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A8052101A for <netmod@ietf.org>; Wed, 21 May 2014 08:51:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T7A7SWrGg37o for <netmod@ietf.org>; Wed, 21 May 2014 08:51:25 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Wed, 21 May 2014 08:51:25 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF24920017 for <netmod@ietf.org>; Wed, 21 May 2014 08:51:25 +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 WSdnUet_64B0; Wed, 21 May 2014 08:51:24 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0FC520013; Wed, 21 May 2014 08:51:23 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id DE18F2CED094; Wed, 21 May 2014 08:51:23 +0200 (CEST)
Date: Wed, 21 May 2014 08:51:23 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20140521065123.GB87257@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: "netmod@ietf.org" <netmod@ietf.org>
References: <SNT147-W4621CB88DE833C67789FDDD3500@phx.gbl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <SNT147-W4621CB88DE833C67789FDDD3500@phx.gbl>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/t__Di8BsfHRPapNAObfv5faAstc
Subject: Re: [netmod] Discussion on draft-huang-netmod-acl-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 06:51:30 -0000

Hi,

is it correct that I did not see any answer to this message?

/js

On Tue, Apr 15, 2014 at 09:39:16AM -0700, YuekunLi wrote:
>  
> Hi Lisa/Alex/Andy,
> 
> I went through 'draft-huang-netmod-acl-03' and had a few points that I would like to discuss with you guys.
>  
> 1. I have some concern on the name of the feature we're modeling here.
>    'Stateless Packet Filter' is accurate to describe this feature.
>    However, none of the major vendors in the industry named their features as such.
>    Aligning with some major vendors would be appropriate since we're setting a standard.
>    From this perspective, I would suggest using 'Access Control List (ACL)'.
>  
> 2. The latest revision of this doc briefly mentioned how a SPF (ACL) is applied to a target.
>    I can see that section 3.3.4 covers the topic of attaching a SPF (ACL) to an interface.
>    In this case, SPF (ACL) is used for traffic filtering.
>    There are quite some scenarios, however, SPFs (ACLs) are deployed in other client applications such as QoS policy and routing protocols (e.g. BGP and OSPF).
>    In most of these cases, SPF (ACL) is used for classification or filtering some routing information.
>    Would you consider to initiate a new draft dedicated to topics of applying SPF (ACL) to each type of targets?
>  
> 3. This document has had a detailed coverage on object-groups (both port object-groups and network object-groups).
>    Could we consider to put object-groups in a separate module?
>    The benefit of this practice is that it's easy for object-groups to be re-used by other modules besides SPF (ACL).
>  
> 4. The packet-capture feature may not be appropriate in SPF (ACL) module.
>    This feature actually introduces some new 'actions' to execute after we found a match between packet and SPE (ACE).
>    These actions (forward and copy) are not purely filtering actions. 
>    Therefore, they may not fit in the SPF (ACL) module very well.
>  
> 5. In current SPF (ACL) module, each SPE (ACE) is assigned a string as its name.
>    This may be too expensive in terms of memory consumption.
>    Instead, a sequence number for each entry should be sufficient and easy to implement.
>    Besides, sequence number does give uses the flexibilty to insert an entry to certain position of an existing SPF (ACL).
>  
> 6. Is it better to have a higher level abstraction above SPF (ACL) module?
>    By this, I mean creating a separate module that defines some common typedef/groupings.
>    And not container in this module.
>    Is this going to be an improvement for the modularity?
> 
>  
> Please let me know if there is any confusion on above points.
>  
>  
> Thanks
>  
> ---------------
> Yuekun Li
>  		 	   		  
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
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 nobody Wed May 21 04:06:08 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7421A04CA for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 04:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqC7wuH8KxLO for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 04:06:04 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E98B1A0527 for <netmod@ietf.org>; Wed, 21 May 2014 04:06:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6E786540696; Wed, 21 May 2014 13:05:59 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd+kanpc1z9m; Wed, 21 May 2014 13:05:55 +0200 (CEST)
Received: from localhost (unknown [217.31.205.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 40A1B540171; Wed, 21 May 2014 13:05:54 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
In-Reply-To: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Wed, 21 May 2014 13:05:51 +0200
Message-ID: <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hsJHDEMSQY3_IuFihxt15mV1bWA
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 11:06:07 -0000

Hi J=C3=BCrgen,

thanks for the review, please see my responses inline.

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> Lada,
>
> while producing the writeup, I re-read the I-D and found a couple of
> nits that I propose to fix before we send the document forward.  Most
> of them are rather trivial but I think it is best we fix them now so
> that we do not have to track them.
>
> /js
>
> a) The three modules do not compile cleanly with pyang 1.3 using the
>    --ietf option because of missing description statements:
>
>    ietf-routing: container next-hop-list is missing a description
>                 substatement
>
>   ietf-ipv4-unicast-routing: container next-hop-list is missing a
>                              description substatement
>
>   ietf-ipv6-unicast-routing: container next-hop-list is missing a
>                              description substatement

Done.

>
> b) OLD
>
>       (read-write) and "ro" means state data (read-only).
>
>    NEW
>
>       (read-write), and "ro" means state data (read-only).
>
>    The RFC editor prefers a comma before and.

Done.

>
> c) Page 21 second bullet lists some paths and the text talks about
>    state data. I think the paths are incorrect and should point into
>    the /rt:routing-state subtree.

The second path is an RPC and it is actually correct, so I corrected the fi=
rst path and removed "as state data".

>
> d) In all three modules, replace David Kessens with Tom Nadeau as
>    co-chair.

Done.

>
> e) In all three modules, change the copyright year to 2014.

Done.

>
> f) The leaf cur-hop-limit in the state tree has a default statement
>    and also this sentence:
>
>               The default SHOULD be set to the value specified in IANA
>               Assigned Numbers that was in effect at the time of
>               implementation.
>
>    First, a default in the state tree is not really that useful.  This
>    text seems to imply that there should be no default at all since
>    the value can change. I think this SHOULD text should also be moved
>    to the corresponding object in the configuration subtree.

I agree the default should be probably removed, but then the text is an inf=
ormation for the server implementor about how to choose the operational def=
ault. One option would be to make cur-hop-limit mandatory instead - so a se=
rver implementor chooses an operational default value but the server has to=
 report it.=20=20

>
> g) The leaf default-lifetime in the state tree has this text:
>
>               If this parameter is not configured, a value of 3 *
>               max-rtr-adv-interval SHOULD be used.
>
>    This text seems more appropriate for the corresponding
>    configuration leaf and should perhaps be moved there.

This one is really a dynamic default so it is up to the server to compute t=
he value if nothing is configured.

>
> h) There is this text in the description of ipv6-router-advertisements
>    in the configuration subtree:
>
>             See the corresponding parameters under /rt:routing-state for
>             detailed descriptions and references.
>
>    Perhaps it is easier to move the few sentence that are specific for
>    the configuration objects right into the configuration object's
>    description clauses (and then to remove this sentence)?

I copied some sentences from descriptions in state to config, but then ther=
e are two other types of information that I am not sure about:

- Instructions for choosing operational defaults - see above, I am inclined=
 to leave it in state data.

- References to RFC: I think they needn't be twice in the module, and I sli=
ghtly prefer to leave them with state data because this is where the constr=
aints really matter.=20=20

>
> i) Please replace [YANG-IF] with [RFC7223] and update the references.

Done.

>
> j) I did compile the example-rip module. Of course, it is and example
>    and not intended to be complete. But perhaps it makes sense to add
>    the missing description clauses just to make sure people always see
>    descriptions clauses in RFCs (and perhaps add a comment that the
>    statements for module meta information has been left out for
>    brevity).

I am not sure what's better. The example is short and it's useful that the =
reader can easily see the structure of the entire module. Note that RFC 722=
3 also has the examples sans descriptions.

>
> k) Have you validated the example instance document in appendix D
>    against the YANG modules?

Yes, the example validates. However, before including it in the text, I hav=
e to insert a few extra line breaks in order to keep the prescribed line le=
ngth. It affects only the dates-and-times, I believe.=20

>
> l) In the security considerations, add a sentence at the end of the
>    first paragraph that points to the access control model. See
>    Section 7 in RFC 7223 as an example. You also need to add an
>    informative reference to RFC 6536 which this sentence refers to.

Done.

>
> m) In the security considerations, I suggest to place a color ':'
>    after the path:
>
>    OLD
>
>    /routing/routing-instance/interfaces/interface  This list assigns a
>       network layer interface to a routing instance and may also specify
>       interface parameters related to routing.
>
>    /routing/routing-instance/routing-protocols/routing-protocol  This
>       list specifies the routing protocols configured on a device.
>
>    /routing/route-filters/route-filter  This list specifies the
>       configured route filters which represent administrative policies
>       for redistributing and modifying routing information.
>
>    /routing/ribs/rib  This list specifies the RIBs configured for the
>       device.
>
>    NEW
>
>    /routing/routing-instance/interfaces/interface:  This list assigns a
>       network layer interface to a routing instance and may also specify
>       interface parameters related to routing.
>
>    /routing/routing-instance/routing-protocols/routing-protocol:  This
>       list specifies the routing protocols configured on a device.
>
>    /routing/route-filters/route-filter:  This list specifies the
>       configured route filters which represent administrative policies
>       for redistributing and modifying routing information.
>
>    /routing/ribs/rib:  This list specifies the RIBs configured for the
>       device.

Done.

Thanks, Lada

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

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed May 21 04:51:01 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B4B1A0340 for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 04:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzKTLgqNa5be for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 04:50:58 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8C51A032F for <netmod@ietf.org>; Wed, 21 May 2014 04:50:58 -0700 (PDT)
Received: from dev.martin.serak.ws.eth.2.office.nic.cz (unknown [172.20.20.228]) by mail.nic.cz (Postfix) with ESMTPSA id B7E1713FE2E for <netmod@ietf.org>; Wed, 21 May 2014 13:50:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400673056; bh=F8BcLXM9V+CPdWDSM5ZNqWRl/F/4ra0rNndawDK4EXI=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=B8vY0qJrhgfv23CvTVe7llPLPoc6DGuYnO8B+UhR78kIt3Ve0drzoSd4FsOmzy1PJ XhjsgMfEkfmCgVMUe4NzjYoozQP2cDRzIPmLe3o+OI2ILDkfE6XCdUC3/G6Jq79MXN 9bxSTa8z54FdYOv7QbJBflvCcYFv0QpITqMZdZZI=
From: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1F97CD1-91CB-4618-9832-D8A9379F7DD8@nic.cz>
Date: Wed, 21 May 2014 13:50:53 +0200
To: NETMOD Working Group <netmod@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CGeS6rcRlABWCjcAJllZIejwL04
Subject: [netmod] IPR statement - routing doc
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 11:50:59 -0000

Hi,

this is my statement about IPR with respect to =
draft-ietf-netmod-routing-cfg-13:

1. My company (CZ.NIC, z. s. p. o.) has no IPR claims related to the =
document.

2. I don't know about any other IPR affecting the document.

Should anybody be aware of any (potential) IPR issues, please let me =
know asap.

Thanks, Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed May 21 05:19:17 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77971A0538 for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 05:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvRbtyeRmIL7 for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 05:19:11 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAAA1A0425 for <netmod@ietf.org>; Wed, 21 May 2014 05:19:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 557B0116B; Wed, 21 May 2014 14:19:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XsEsnRKFFk-y; Wed, 21 May 2014 14:19:07 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 May 2014 14:19:02 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A0092002C; Wed, 21 May 2014 14:18:35 +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 IjxCCuySMdXb; Wed, 21 May 2014 14:18:34 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB3AC20017; Wed, 21 May 2014 14:18:33 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id C5C332CEDC78; Wed, 21 May 2014 14:18:32 +0200 (CEST)
Date: Wed, 21 May 2014 14:18:32 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/v7gs_qIwJduRRdNk1eiuUXJw4q4
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 12:19:14 -0000

On Wed, May 21, 2014 at 01:05:51PM +0200, Ladislav Lhotka wrote:
> Hi Jürgen,
> 
> thanks for the review, please see my responses inline.

Removing everything marked Done...

> > f) The leaf cur-hop-limit in the state tree has a default statement
> >    and also this sentence:
> >
> >               The default SHOULD be set to the value specified in IANA
> >               Assigned Numbers that was in effect at the time of
> >               implementation.
> >
> >    First, a default in the state tree is not really that useful.  This
> >    text seems to imply that there should be no default at all since
> >    the value can change. I think this SHOULD text should also be moved
> >    to the corresponding object in the configuration subtree.
> 
> I agree the default should be probably removed, but then the text is an information for the server implementor about how to choose the operational default. One option would be to make cur-hop-limit mandatory instead - so a server implementor chooses an operational default value but the server has to report it.  
> 

Now I see your point - you want to not report cur-hop-limit as long as
it is 64 (when you do not use explicit defaults during the
retrieval). Hm. More below... I guess my problem really is with the
text saying how to choose a value if no explicit config is provided.

> > g) The leaf default-lifetime in the state tree has this text:
> >
> >               If this parameter is not configured, a value of 3 *
> >               max-rtr-adv-interval SHOULD be used.
> >
> >    This text seems more appropriate for the corresponding
> >    configuration leaf and should perhaps be moved there.
> 
> This one is really a dynamic default so it is up to the server to compute the value if nothing is configured.
> 

Yes. But in my view, state objects really just report the actual
value. In other words, I would have placed the text that says how the
dynamic default is picked if a value is not configured into the
configuration tree, not the state tree. The state tree is supposed to
report the real value used. I do not expect that an implementor looks
into the description of state objects in order to figure out what to
do if a config object is not present.

> > h) There is this text in the description of ipv6-router-advertisements
> >    in the configuration subtree:
> >
> >             See the corresponding parameters under /rt:routing-state for
> >             detailed descriptions and references.
> >
> >    Perhaps it is easier to move the few sentence that are specific for
> >    the configuration objects right into the configuration object's
> >    description clauses (and then to remove this sentence)?
> 
> I copied some sentences from descriptions in state to config, but then there are two other types of information that I am not sure about:
> 
> - Instructions for choosing operational defaults - see above, I am inclined to leave it in state data.
> 
> - References to RFC: I think they needn't be twice in the module, and I slightly prefer to leave them with state data because this is where the constraints really matter.  

I would like have done it the other way around because the question
how something is initialized if it is not in the configuration really
matters when you implement the configuration logic, not the rather
simply logic to read out the current value.

> > j) I did compile the example-rip module. Of course, it is and example
> >    and not intended to be complete. But perhaps it makes sense to add
> >    the missing description clauses just to make sure people always see
> >    descriptions clauses in RFCs (and perhaps add a comment that the
> >    statements for module meta information has been left out for
> >    brevity).
> 
> I am not sure what's better. The example is short and it's useful that the reader can easily see the structure of the entire module. Note that RFC 7223 also has the examples sans descriptions.

OK - I can go along with that.

/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 nobody Wed May 21 08:13:45 2014
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6281A086F; Wed, 21 May 2014 08:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwV1FWJ156ZQ; Wed, 21 May 2014 08:13:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F51A0862; Wed, 21 May 2014 08:13:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary <iesg-secretary@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140521151332.19027.50588.idtracker@ietfa.amsl.com>
Date: Wed, 21 May 2014 08:13:32 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cw9jOf2qog-SOpeQuB3TIXhbPBM
Cc: netmod@ietf.org
Subject: [netmod] NETMOD WG Virtual Interim Meetings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 15:13:34 -0000

The NETMOD WG will hold a series of weekly virtual interim meetings.
The meetings will take place on Wednesdays between 16:00 and 18:00
CEST. The first meeting will be on Wednesday 2014-06-04. The agenda is
to iterate over the YANG 1.1 issues list with the goal to close open
issues until there are none left open.

The WebEx details can be found below.

-----------------------------------------------------------------------
JOIN USING WebEx

Go To:
https://cisco.webex.com/cisco/j.php?J=202712764&PW=NOWQ0ZTRhOTkz

Meeting Password ----- netmod
Meeting Number ----- 202 712 764

----------------------------------------------------------------
ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE 
(408) OR (919) AREA CODES
----------------------------------------------------------------
Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

Dialing the WebEx toll free numbers from within 408 or 919 area codes is 
not enabled (non-Cisco phones). " If you dial the toll-free numbers 
within the 408 or 919 area codes you will be instructed to hang up and 
dial the local access number." Please use the call-back option whenever 
possible and otherwise dial local numbers only. The affected toll free 
numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 
349-3520 for the RTP area.

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or 
Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

IMPORTANT NOTICE: This WebEx service includes a feature that allows 
audio and any documents and other materials exchanged or viewed during 
the session to be recorded. By joining this session, you automatically 
consent to such recordings. If you do not consent to the recording, 
discuss your concerns with the meeting host prior to the start of the 
recording or do not join the session. Please note that any such 
recordings may be subject to discovery in the event of litigation.


From nobody Wed May 21 08:22:43 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD11A0738 for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 08:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.472
X-Spam-Level: 
X-Spam-Status: No, score=0.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JO7sHKYuQ4ys for <netmod@ietfa.amsl.com>; Wed, 21 May 2014 08:22:39 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201561A06D6 for <netmod@ietf.org>; Wed, 21 May 2014 08:22:39 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id r5so3430068qcx.7 for <netmod@ietf.org>; Wed, 21 May 2014 08:22:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0yNVGpYpTivcZNSKS5218vo1+CBsz1vNRK3sVe+gYNc=; b=QW9mURrDE2x+tu5i+GZ7L6sQ9zIqI2edpOl4derwzpxk1YDYotIhoFG+DXkRWrWDqH jfA5r7o8lKvuMh5YuNXVhEDJsySwinBycnZuvRbQ6fKppTRzh/60tAGsqXgd4v1a2UrN 3j1Oh1kWFfiodcJqvqIjtPqEcbtM2J5Y6pgPRqBg5ilQJwQAMRCAxUN+YIl3uHVCWWoG 3v5L3Qr4OvejksHR9fUV4UCDoJI2rcczWAfvY+DCdJnGnMBo1QqrxkXlMPtA6ICfDXcI B5WbQSEFgihXYQyjZGfHgcIjfCC4KrT54ZsqAN4kx8nlh75161dnu0ybaE11Obs/teD2 nK6w==
X-Gm-Message-State: ALoCoQlGcXu+3SMu60a70Kf28Jb+jEaRUJAQ0tIP4hf43AVwJpP7JWrCpy2zaf8VU9R0VMxpa9pJ
MIME-Version: 1.0
X-Received: by 10.140.27.245 with SMTP id 108mr66868889qgx.18.1400685757678; Wed, 21 May 2014 08:22:37 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Wed, 21 May 2014 08:22:37 -0700 (PDT)
In-Reply-To: <OF51CC236D.D5BCDC46-ON48257CDF.002192FA-48257CDF.0022115F@zte.com.cn>
References: <OFC4C9BABF.6EB619B9-ON48257CDE.0025678D-48257CDE.0026F025@zte.com.cn> <537B0EE0.5070601@mg-soft.com> <OF06F13883.724E4B68-ON48257CDE.002D72BC-48257CDE.002D9C79@zte.com.cn> <537B1158.1010708@mg-soft.com> <OFEC1333EA.133482D9-ON48257CDE.002EBEBB-48257CDE.002EED4C@zte.com.cn> <20140520192133.GC83689@elstar.jacobs.jacobs-university.de> <CABCOCHQE-dwYKK=CJ4XuyiY-runSzxJVpWan4B9GM_mznj2bUw@mail.gmail.com> <OF51CC236D.D5BCDC46-ON48257CDF.002192FA-48257CDF.0022115F@zte.com.cn>
Date: Wed, 21 May 2014 08:22:37 -0700
Message-ID: <CABCOCHStvjww8XcvSBdaKnJ6u6jFCLoe+wHkLhHGq9CkoVSUoQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: feng.chong33@zte.com.cn
Content-Type: multipart/alternative; boundary=001a11c152600797bf04f9ea9153
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SGaB2Y2njjn6kRiQxcq3fH1aKv4
Cc: dai.xianxian@zte.com.cn, "netmod@ietf.org" <netmod@ietf.org>, du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn
Subject: Re: [netmod] A question about rpc's xpath
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 15:22:40 -0000

--001a11c152600797bf04f9ea9153
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

On Tue, May 20, 2014 at 11:12 PM, <feng.chong33@zte.com.cn> wrote:

> /frank
>
> Andy Bierman <andy@yumaworks.com> =D0=B4=D3=DA 2014-05-21 03:45:02:
>
> > Andy Bierman <andy@yumaworks.com>
> > 2014-05-21 03:45
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>,
> > feng.chong33@zte.com.cn, Jernej Tuljak <jernej.tuljak@mg-soft.si>,
> > du.baowei23@zte.com.cn, cheng.zhu1@zte.com.cn,
> > dai.xianxian@zte.com.cn, "netmod@ietf.org" <netmod@ietf.org>,
> >
> > =B3=AD=CB=CD
> >
> > =D6=F7=CC=E2
> >
> > Re: [netmod] A question about rpc's xpath
> >
> >
>
> > On Tue, May 20, 2014 at 12:21 PM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> > On Tue, May 20, 2014 at 04:32:33PM +0800, feng.chong33@zte.com.cn wrote=
:
> > >
> > > But I don't understand why rpc' identifier must not be the same to da=
ta
> > > definition node's identifier.
> >
> > I think the examples in the thread motivate why disallowing name
> > clashes is a good idea.
>
> >
> > This was a design decision in order to make the path-stmt
> > easier to use (e.g., so augment-stmt works consistently
> > across rpc, data, and notification statements).
> >
> I don't think it's a good design. Adding a substatement such as 'type' to
> indicate the target node belongs to which type(e.g. data/rpc/notification=
)
> is a better solution.
>


I do not agree. Changing a simple statement to multiple statements
adds complexity, it doesn't reduce it.  Perhaps we would have done somethin=
g
like that if identifier names were perceived as scarce resources.
It is not that hard to pick a different string.  A sub-statement would
allow the same string to represent a data, rpc, and/or notification node.
(that's it).




> > /js
>
> >
> > Andy
> >
>
>
Andy

--001a11c152600797bf04f9ea9153
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, May 20, 2014 at 11:12 PM,  <span dir=3D"ltr">&lt;<a href=3D=
"mailto:feng.chong33@zte.com.cn" target=3D"_blank">feng.chong33@zte.com.cn<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><font face=3D"sans-serif">/frank</font>
<br>
<br><tt><font>Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com" target=
=3D"_blank">andy@yumaworks.com</a>&gt; =D0=B4=D3=DA 2014-05-21
03:45:02:<br>
<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com" target=3D"_blan=
k">andy@yumaworks.com</a>&gt; </font></tt>
<br><tt><font>&gt; 2014-05-21 03:45</font></tt>
<br><tt><font>&gt; <br>
&gt; =CA=D5=BC=FE=C8=CB</font></tt>
<br><tt><font>&gt; <br>
&gt; Juergen Schoenwaelder &lt;<a href=3D"mailto:j.schoenwaelder@jacobs-uni=
versity.de" target=3D"_blank">j.schoenwaelder@jacobs-university.de</a>&gt;,
<br>
&gt; <a href=3D"mailto:feng.chong33@zte.com.cn" target=3D"_blank">feng.chon=
g33@zte.com.cn</a>, Jernej Tuljak &lt;<a href=3D"mailto:jernej.tuljak@mg-so=
ft.si" target=3D"_blank">jernej.tuljak@mg-soft.si</a>&gt;,
<br>
&gt; <a href=3D"mailto:du.baowei23@zte.com.cn" target=3D"_blank">du.baowei2=
3@zte.com.cn</a>, <a href=3D"mailto:cheng.zhu1@zte.com.cn" target=3D"_blank=
">cheng.zhu1@zte.com.cn</a>, <br>
&gt; <a href=3D"mailto:dai.xianxian@zte.com.cn" target=3D"_blank">dai.xianx=
ian@zte.com.cn</a>, &quot;<a href=3D"mailto:netmod@ietf.org" target=3D"_bla=
nk">netmod@ietf.org</a>&quot; &lt;<a href=3D"mailto:netmod@ietf.org" target=
=3D"_blank">netmod@ietf.org</a>&gt;,
</font></tt>
<br><tt><font>&gt; <br>
&gt; =B3=AD=CB=CD</font></tt>
<br><tt><font>&gt; <br>
&gt; =D6=F7=CC=E2</font></tt>
<br><tt><font>&gt; <br>
&gt; Re: [netmod] A question about rpc&#39;s xpath</font></tt>
<br><tt><font>&gt; <br>
&gt; <br>
</font></tt>
<br><tt><font>&gt; On Tue, May 20, 2014 at 12:21 PM, Juergen Schoenwaelder
&lt;<br>
&gt; <a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D"_bla=
nk">j.schoenwaelder@jacobs-university.de</a>&gt; wrote:</font></tt>
<br><tt><font>&gt; On Tue, May 20, 2014 at 04:32:33PM +0800, <a href=3D"mai=
lto:feng.chong33@zte.com.cn" target=3D"_blank">feng.chong33@zte.com.cn</a>
wrote:<br>
&gt; &gt;<br>
&gt; &gt; But I don&#39;t understand why rpc&#39; identifier must not be th=
e same
to data<br>
&gt; &gt; definition node&#39;s identifier.<br>
&gt; <br>
&gt; I think the examples in the thread motivate why disallowing name<br>
&gt; clashes is a good idea.<br>
</font></tt>
<br><tt><font>&gt; <br>
&gt; This was a design decision in order to make the path-stmt</font></tt>
<br><tt><font>&gt; easier to use (e.g., so augment-stmt works consistently<=
/font></tt>
<br><tt><font>&gt; across rpc, data, and notification statements).</font></=
tt>
<br><tt><font>&gt; </font></tt>
<br><tt><font>I don&#39;t think it&#39;s a good design. Adding a substateme=
nt
such as &#39;type&#39; to indicate the target node belongs to which type(e.=
g. data/rpc/notification)</font></tt>
<br><tt><font>is a better solution.<br></font></tt></blockquote><div><br></=
div><div><br></div><div>I do not agree. Changing a simple statement to mult=
iple statements</div><div>adds complexity, it doesn&#39;t reduce it. &nbsp;=
Perhaps we would have done something</div>
<div>like that if identifier names were perceived as scarce resources.</div=
><div>It is not that hard to pick a different string. &nbsp;A sub-statement=
 would</div><div>allow the same string to represent a data, rpc, and/or not=
ification node.</div>
<div>(that&#39;s it).</div><div><br></div><div><br></div><div>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><tt><font>
&gt; /js<br>
</font></tt>
<br><tt><font>&gt; <br>
&gt; Andy</font></tt>
<br><tt><font>&gt; &nbsp;</font></tt>

<br><pre><font color=3D"blue"></font></pre></blockquote><div><br></div><div=
>Andy</div><div><br></div></div></div></div>

--001a11c152600797bf04f9ea9153--


From nobody Thu May 22 01:56:55 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82F81A015A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 01:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdHfbrucfkQ2 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 01:56:51 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7261A0060 for <netmod@ietf.org>; Thu, 22 May 2014 01:56:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DDA5554060F; Thu, 22 May 2014 10:56:47 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3Vy5QAGowHb; Thu, 22 May 2014 10:56:43 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9055D540171; Thu, 22 May 2014 10:56:42 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
In-Reply-To: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 22 May 2014 10:56:41 +0200
Message-ID: <m261kyqjhy.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ImRDE_SwiP4xg0jiQZfP8JIIdfs
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 08:56:53 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Wed, May 21, 2014 at 01:05:51PM +0200, Ladislav Lhotka wrote:
>> Hi J=C3=BCrgen,
>>=20
>> thanks for the review, please see my responses inline.
>
> Removing everything marked Done...
>
>> > f) The leaf cur-hop-limit in the state tree has a default statement
>> >    and also this sentence:
>> >
>> >               The default SHOULD be set to the value specified in IANA
>> >               Assigned Numbers that was in effect at the time of
>> >               implementation.
>> >
>> >    First, a default in the state tree is not really that useful.  This
>> >    text seems to imply that there should be no default at all since
>> >    the value can change. I think this SHOULD text should also be moved
>> >    to the corresponding object in the configuration subtree.
>>=20
>> I agree the default should be probably removed, but then the text is an =
information for the server implementor about how to choose the operational =
default. One option would be to make cur-hop-limit mandatory instead - so a=
 server implementor chooses an operational default value but the server has=
 to report it.=20=20
>>=20
>
> Now I see your point - you want to not report cur-hop-limit as long as
> it is 64 (when you do not use explicit defaults during the
> retrieval). Hm. More below... I guess my problem really is with the
> text saying how to choose a value if no explicit config is provided.

I think it is somewhat unclear what the following sentence in 6020 means fo=
r defaults in configuration data:

   When the default value is in use, the server MUST operationally
   behave as if the leaf was present in the data tree with the default
   value as its value.

For example, assume the data model defines the default value for 'cur-hop-l=
imit' in *config* to be 64. Now, IANA changes the default TTL, and device X=
 uses this new value as its operational default (independent of NETCONF). I=
t can now mean two things:

1. Device X is no more compliant with the data model, or

2. When the NETCONF server is started on device X, it has to change the 'cu=
r-hop-limit' to 64 on its own so that the contract with its clients express=
ed by the data model still holds.=20=20

On the other hand, a default value defined for a state leaf must IMO be the=
 "native" operational default that the device uses even in the absence of N=
ETCONF.

>
>> > g) The leaf default-lifetime in the state tree has this text:
>> >
>> >               If this parameter is not configured, a value of 3 *
>> >               max-rtr-adv-interval SHOULD be used.
>> >
>> >    This text seems more appropriate for the corresponding
>> >    configuration leaf and should perhaps be moved there.
>>=20
>> This one is really a dynamic default so it is up to the server to comput=
e the value if nothing is configured.
>>=20
>
> Yes. But in my view, state objects really just report the actual
> value. In other words, I would have placed the text that says how the
> dynamic default is picked if a value is not configured into the
> configuration tree, not the state tree. The state tree is supposed to
> report the real value used. I do not expect that an implementor looks
> into the description of state objects in order to figure out what to
> do if a config object is not present.

It is true that such instructions are more of interest to those that implem=
ent the guts of the system, and state data should just tell the result. So =
I will move these parts of the descriptions to the config tree as you sugge=
st.

>
>> > h) There is this text in the description of ipv6-router-advertisements
>> >    in the configuration subtree:
>> >
>> >             See the corresponding parameters under /rt:routing-state f=
or
>> >             detailed descriptions and references.
>> >
>> >    Perhaps it is easier to move the few sentence that are specific for
>> >    the configuration objects right into the configuration object's
>> >    description clauses (and then to remove this sentence)?
>>=20
>> I copied some sentences from descriptions in state to config, but then t=
here are two other types of information that I am not sure about:
>>=20
>> - Instructions for choosing operational defaults - see above, I am incli=
ned to leave it in state data.
>>=20
>> - References to RFC: I think they needn't be twice in the module, and I =
slightly prefer to leave them with state data because this is where the con=
straints really matter.=20=20
>
> I would like have done it the other way around because the question
> how something is initialized if it is not in the configuration really
> matters when you implement the configuration logic, not the rather
> simply logic to read out the current value.

OK, will do.

Lada

>
>> > j) I did compile the example-rip module. Of course, it is and example
>> >    and not intended to be complete. But perhaps it makes sense to add
>> >    the missing description clauses just to make sure people always see
>> >    descriptions clauses in RFCs (and perhaps add a comment that the
>> >    statements for module meta information has been left out for
>> >    brevity).
>>=20
>> I am not sure what's better. The example is short and it's useful that t=
he reader can easily see the structure of the entire module. Note that RFC =
7223 also has the examples sans descriptions.
>
> OK - I can go along with that.
>
> /js
>
> --=20
> 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/>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Thu May 22 02:07:21 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564DD1A0060 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U57O-zIGpkNe for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:07:17 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5CF1A0166 for <netmod@ietf.org>; Thu, 22 May 2014 02:07:16 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1050D114C; Thu, 22 May 2014 11:07:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A-ZWL2UsaW3y; Thu, 22 May 2014 11:07:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 11:07:13 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27C3A20017; Thu, 22 May 2014 11:07:13 +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 pnsEAJzKXwzJ; Thu, 22 May 2014 11:07:12 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAFCA20013; Thu, 22 May 2014 11:07:11 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B5B0C2CF1944; Thu, 22 May 2014 11:07:10 +0200 (CEST)
Date: Thu, 22 May 2014 11:07:10 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140522090708.GB90713@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <m261kyqjhy.fsf@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i-Ef5H0gmKM-gfaTUqnmTEGbv_4
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 09:07:19 -0000

On Thu, May 22, 2014 at 10:56:41AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> 
> > On Wed, May 21, 2014 at 01:05:51PM +0200, Ladislav Lhotka wrote:
> >> Hi Jürgen,
> >> 
> >> thanks for the review, please see my responses inline.
> >
> > Removing everything marked Done...
> >
> >> > f) The leaf cur-hop-limit in the state tree has a default statement
> >> >    and also this sentence:
> >> >
> >> >               The default SHOULD be set to the value specified in IANA
> >> >               Assigned Numbers that was in effect at the time of
> >> >               implementation.
> >> >
> >> >    First, a default in the state tree is not really that useful.  This
> >> >    text seems to imply that there should be no default at all since
> >> >    the value can change. I think this SHOULD text should also be moved
> >> >    to the corresponding object in the configuration subtree.
> >> 
> >> I agree the default should be probably removed, but then the text is an information for the server implementor about how to choose the operational default. One option would be to make cur-hop-limit mandatory instead - so a server implementor chooses an operational default value but the server has to report it.  
> >> 
> >
> > Now I see your point - you want to not report cur-hop-limit as long as
> > it is 64 (when you do not use explicit defaults during the
> > retrieval). Hm. More below... I guess my problem really is with the
> > text saying how to choose a value if no explicit config is provided.
> 
> I think it is somewhat unclear what the following sentence in 6020 means for defaults in configuration data:
> 
>    When the default value is in use, the server MUST operationally
>    behave as if the leaf was present in the data tree with the default
>    value as its value.
> 
> For example, assume the data model defines the default value for 'cur-hop-limit' in *config* to be 64. Now, IANA changes the default TTL, and device X uses this new value as its operational default (independent of NETCONF). It can now mean two things:
> 
> 1. Device X is no more compliant with the data model, or
> 
> 2. When the NETCONF server is started on device X, it has to change the 'cur-hop-limit' to 64 on its own so that the contract with its clients expressed by the data model still holds.  

I would say 2. But in this case, there is no static default - the
default can be changed by IANA. Hence, there should not be a default
on the config leaf. There can only be text describing how to pick a
value if the leaf is not provided.
 
> On the other hand, a default value defined for a state leaf must IMO
> be the "native" operational default that the device uses even in the
> absence of NETCONF.

Or there is no default statement at all because there is not static
value that all device will use today and in the future.

> >> > g) The leaf default-lifetime in the state tree has this text:
> >> >
> >> >               If this parameter is not configured, a value of 3 *
> >> >               max-rtr-adv-interval SHOULD be used.
> >> >
> >> >    This text seems more appropriate for the corresponding
> >> >    configuration leaf and should perhaps be moved there.
> >> 
> >> This one is really a dynamic default so it is up to the server to compute the value if nothing is configured.
> >> 
> >
> > Yes. But in my view, state objects really just report the actual
> > value. In other words, I would have placed the text that says how the
> > dynamic default is picked if a value is not configured into the
> > configuration tree, not the state tree. The state tree is supposed to
> > report the real value used. I do not expect that an implementor looks
> > into the description of state objects in order to figure out what to
> > do if a config object is not present.
> 
> It is true that such instructions are more of interest to those that implement the guts of the system, and state data should just tell the result. So I will move these parts of the descriptions to the config tree as you suggest.
> 

Great.

/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 nobody Thu May 22 02:15:42 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBC1A0060 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZsxVDRKjsRZ for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:15:39 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62501A015E for <netmod@ietf.org>; Thu, 22 May 2014 02:15:38 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6306413F963; Thu, 22 May 2014 11:15:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400750136; bh=QTEi5RsQ9aucHEKOI3F1K71NjZyFXV4GR3Em5FkZR3c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=M33pbDKqeWnl7Sl87sLZzGNc9hnuWOEhUtuyqPJ12XerJ7WumYfwHxWna6WFyxJSR xQapN7ki+wtb8AdEDZBuoEHR2qDcLodG9zjwlBAKYKx34e+4itbZDseW0oSo1fWTFj V2+jWNI0+4S35U4mdkVoWW6xdW8qctTPwwR/Gjo0=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140522090708.GB90713@elstar.local>
Date: Thu, 22 May 2014 11:15:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ezKR9glE6TSY-bpspR_b5Y130Ao
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 09:15:40 -0000

On 22 May 2014, at 11:07, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, May 22, 2014 at 10:56:41AM +0200, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
>>=20
>>> On Wed, May 21, 2014 at 01:05:51PM +0200, Ladislav Lhotka wrote:
>>>> Hi J=FCrgen,
>>>>=20
>>>> thanks for the review, please see my responses inline.
>>>=20
>>> Removing everything marked Done...
>>>=20
>>>>> f) The leaf cur-hop-limit in the state tree has a default =
statement
>>>>>   and also this sentence:
>>>>>=20
>>>>>              The default SHOULD be set to the value specified in =
IANA
>>>>>              Assigned Numbers that was in effect at the time of
>>>>>              implementation.
>>>>>=20
>>>>>   First, a default in the state tree is not really that useful.  =
This
>>>>>   text seems to imply that there should be no default at all since
>>>>>   the value can change. I think this SHOULD text should also be =
moved
>>>>>   to the corresponding object in the configuration subtree.
>>>>=20
>>>> I agree the default should be probably removed, but then the text =
is an information for the server implementor about how to choose the =
operational default. One option would be to make cur-hop-limit mandatory =
instead - so a server implementor chooses an operational default value =
but the server has to report it. =20
>>>>=20
>>>=20
>>> Now I see your point - you want to not report cur-hop-limit as long =
as
>>> it is 64 (when you do not use explicit defaults during the
>>> retrieval). Hm. More below... I guess my problem really is with the
>>> text saying how to choose a value if no explicit config is provided.
>>=20
>> I think it is somewhat unclear what the following sentence in 6020 =
means for defaults in configuration data:
>>=20
>>   When the default value is in use, the server MUST operationally
>>   behave as if the leaf was present in the data tree with the default
>>   value as its value.
>>=20
>> For example, assume the data model defines the default value for =
'cur-hop-limit' in *config* to be 64. Now, IANA changes the default TTL, =
and device X uses this new value as its operational default (independent =
of NETCONF). It can now mean two things:
>>=20
>> 1. Device X is no more compliant with the data model, or
>>=20
>> 2. When the NETCONF server is started on device X, it has to change =
the 'cur-hop-limit' to 64 on its own so that the contract with its =
clients expressed by the data model still holds. =20
>=20
> I would say 2. But in this case, there is no static default - the
> default can be changed by IANA. Hence, there should not be a default
> on the config leaf. There can only be text describing how to pick a
> value if the leaf is not provided.

I agree, I used it just as an example.

>=20
>> On the other hand, a default value defined for a state leaf must IMO
>> be the "native" operational default that the device uses even in the
>> absence of NETCONF.
>=20
> Or there is no default statement at all because there is not static
> value that all device will use today and in the future.

I am just trying to figure out whether the semantics of the =91default=92 =
statement are different for config and state data. If we accept option =
#2 above, it looks like they really are.

Lada

>=20
>>>>> g) The leaf default-lifetime in the state tree has this text:
>>>>>=20
>>>>>              If this parameter is not configured, a value of 3 *
>>>>>              max-rtr-adv-interval SHOULD be used.
>>>>>=20
>>>>>   This text seems more appropriate for the corresponding
>>>>>   configuration leaf and should perhaps be moved there.
>>>>=20
>>>> This one is really a dynamic default so it is up to the server to =
compute the value if nothing is configured.
>>>>=20
>>>=20
>>> Yes. But in my view, state objects really just report the actual
>>> value. In other words, I would have placed the text that says how =
the
>>> dynamic default is picked if a value is not configured into the
>>> configuration tree, not the state tree. The state tree is supposed =
to
>>> report the real value used. I do not expect that an implementor =
looks
>>> into the description of state objects in order to figure out what to
>>> do if a config object is not present.
>>=20
>> It is true that such instructions are more of interest to those that =
implement the guts of the system, and state data should just tell the =
result. So I will move these parts of the descriptions to the config =
tree as you suggest.
>>=20
>=20
> Great.
>=20
> /js
>=20
> --=20
> 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/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 02:32:55 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037D11A0056 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as_5A53Bkba6 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:32:52 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5471A004E for <netmod@ietf.org>; Thu, 22 May 2014 02:32:51 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BB3ECF6A; Thu, 22 May 2014 11:32:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rRCMviCEB-Yb; Thu, 22 May 2014 11:32:48 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 11:32:49 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C3F22002C; Thu, 22 May 2014 11:32:49 +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 vsaF0f2hBnKN; Thu, 22 May 2014 11:32:48 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 309C520017; Thu, 22 May 2014 11:32:48 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 0ADA02CF1C81; Thu, 22 May 2014 11:32:48 +0200 (CEST)
Date: Thu, 22 May 2014 11:32:47 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140522093247.GD90713@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R8VdQ6mEBIruwok9ZioOryP6Yzg
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 09:32:54 -0000

On Thu, May 22, 2014 at 11:15:35AM +0200, Ladislav Lhotka wrote:
> 
> On 22 May 2014, at 11:07, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> > I would say 2. But in this case, there is no static default - the
> > default can be changed by IANA. Hence, there should not be a default
> > on the config leaf. There can only be text describing how to pick a
> > value if the leaf is not provided.
> 
> I agree, I used it just as an example.
> 

OK. So we close this specific case.

> >> On the other hand, a default value defined for a state leaf must IMO
> >> be the "native" operational default that the device uses even in the
> >> absence of NETCONF.
> > 
> > Or there is no default statement at all because there is not static
> > value that all device will use today and in the future.
> 
> I am just trying to figure out whether the semantics of the ‘default’ statement are different for config and state data. If we accept option #2 above, it looks like they really are.
> 

My understanding is that a default in the config tree says "if this
leaf is not provided in the config data tree, act as if the default
value is configured for the leaf". For operational state, my
understanding is that the only benefit of a default statement is
suppression of data in 'trim' and 'explicit' mode (RFC 6243).

For many subsystems, the logic to choose a certain operational value
if no config is provided and there is no default value in the config
tree is really deep inside the kernel or device driver. All the state
tree does it really digging out the value and reporting it.

Makes sense?

/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 nobody Thu May 22 02:37:54 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCCC1A0169 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX1sNPh6Z2Y3 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:37:52 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5A21A007E for <netmod@ietf.org>; Thu, 22 May 2014 02:37:51 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5461213F963; Thu, 22 May 2014 11:37:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400751469; bh=H17xGOdJ8IsmJw7RSjE1BYhR/uud7VoM7JcbTJQpz0Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CYsvD8ZFWhuB2Yjj4T03oAGaV1cmgeQpRROwL+no6NMN/nL9VCHDfRVgp5U8yqZud fDrFvQP82LmNplZfWnT5Xibvb74n+zY9eXzkF/kmLmAl59h8RhsJDqBFwSOe3pViGo /v7gQ+/aFgG48zXyV+iub8XrSwmpBE+7R8B5J7jc=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140522093247.GD90713@elstar.local>
Date: Thu, 22 May 2014 11:37:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SdaXuKSgymAYcNbSrn0W-4STiwc
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 09:37:53 -0000

On 22 May 2014, at 11:32, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, May 22, 2014 at 11:15:35AM +0200, Ladislav Lhotka wrote:
>>=20
>> On 22 May 2014, at 11:07, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
>>=20
>>> I would say 2. But in this case, there is no static default - the
>>> default can be changed by IANA. Hence, there should not be a default
>>> on the config leaf. There can only be text describing how to pick a
>>> value if the leaf is not provided.
>>=20
>> I agree, I used it just as an example.
>>=20
>=20
> OK. So we close this specific case.

Yup.

>=20
>>>> On the other hand, a default value defined for a state leaf must =
IMO
>>>> be the "native" operational default that the device uses even in =
the
>>>> absence of NETCONF.
>>>=20
>>> Or there is no default statement at all because there is not static
>>> value that all device will use today and in the future.
>>=20
>> I am just trying to figure out whether the semantics of the =91default=92=
 statement are different for config and state data. If we accept option =
#2 above, it looks like they really are.
>>=20
>=20
> My understanding is that a default in the config tree says "if this
> leaf is not provided in the config data tree, act as if the default
> value is configured for the leaf". For operational state, my
> understanding is that the only benefit of a default statement is
> suppression of data in 'trim' and 'explicit' mode (RFC 6243).

Agreed, but then it is protocol-dependent.

>=20
> For many subsystems, the logic to choose a certain operational value
> if no config is provided and there is no default value in the config
> tree is really deep inside the kernel or device driver. All the state
> tree does it really digging out the value and reporting it.
>=20
> Makes sense?

Yes, it does.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 02:50:04 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD51A00CD for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcX6mNFUwl2P for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 02:50:01 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB0A1A0056 for <netmod@ietf.org>; Thu, 22 May 2014 02:50:00 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BB803FAB; Thu, 22 May 2014 11:49:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p3XwA0ai_OMz; Thu, 22 May 2014 11:49:57 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 11:49:58 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 303E120017; Thu, 22 May 2014 11:49:58 +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 bdiiscsf0qGR; Thu, 22 May 2014 11:49:57 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1164C20013; Thu, 22 May 2014 11:49:57 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 3E52D2CF1D51; Thu, 22 May 2014 11:49:56 +0200 (CEST)
Date: Thu, 22 May 2014 11:49:55 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140522094955.GF90713@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gxCwx7-M29dQWFzw3JxIcVZSiqI
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 09:50:02 -0000

On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
> 
> > 
> > My understanding is that a default in the config tree says "if this
> > leaf is not provided in the config data tree, act as if the default
> > value is configured for the leaf". For operational state, my
> > understanding is that the only benefit of a default statement is
> > suppression of data in 'trim' and 'explicit' mode (RFC 6243).
> 
> Agreed, but then it is protocol-dependent.
> 

What is protocol dependent? RFC 6243 clarifies default handling
options. And yes, if your server only does report-all basic mode, the
default value has no effect.

For RESTCONF, it seems that currently things boil down to
report-all. But RESTCONF is not yet done (and I would hope that the
text in section 4.5.2 will be critically reviewed - I agree that
RESTCONF should simplify this, I am not sure what this section
currently says is the right solution). That said, our job is to
publish this data model - lets not worry about RESTCONF here.

/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 nobody Thu May 22 03:57:05 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B5B1A0190 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 03:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qqb-vhaTUQP for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 03:57:01 -0700 (PDT)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CA01A0181 for <netmod@ietf.org>; Thu, 22 May 2014 03:57:00 -0700 (PDT)
Received: by mail-qc0-f175.google.com with SMTP id w7so5343640qcr.20 for <netmod@ietf.org>; Thu, 22 May 2014 03:56:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NuhQw7AfVW+DrSnt4e3/bNH4Brij5aQ8ON8KN1ZiRJ4=; b=Py+caEEVidESpoP9KWK9KcisF6peUmtYsyHmiWtMXCvksTtDLlNF9YrZ9aL21y/fyg B7VsojYGkVmOWmGb8MFaE2+QHvnWM0rpHtVgaNJz+BAMet5pz9AnnWkttHqZeIz0SaO8 eaYBahwfbOpqrG3GqinaK7fPF2zRksc8NJbgI82/+WDJ8swpRFg0xOATMvqXIUncVxrC 4g1Xbt1HxyMDocvn88oRLb1k2+alb7R/cAvJAXgLj1BOvRKDSjRpp2f5D62mBh1GHQYA WGvyUshj2wP9DRdXPy7fvSqMHw3In5qJPSt5evOrL3Ax2MCA2RWM5Eg57wgDx+PP77Ks 82Rg==
X-Gm-Message-State: ALoCoQmO6ykXKxfsWiLRAJA/CIN1qODM9Ii5A8qX1tSpVK5QGbs2d87AGWV0Fl0ga/7F3VPpLAGA
MIME-Version: 1.0
X-Received: by 10.140.36.105 with SMTP id o96mr74228887qgo.25.1400756219071; Thu, 22 May 2014 03:56:59 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 22 May 2014 03:56:58 -0700 (PDT)
In-Reply-To: <20140522094955.GF90713@elstar.local>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local>
Date: Thu, 22 May 2014 03:56:58 -0700
Message-ID: <CABCOCHSWD_5XJf-hHd0uMgK-syUgd4Ku2iFp+7nvppwcjetOYw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c17334dae48204f9faf8aa
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aspZdKOd200bE7VLMiWJjM2fC8o
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 10:57:03 -0000

--001a11c17334dae48204f9faf8aa
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 22, 2014 at 2:49 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
> >
> > >
> > > My understanding is that a default in the config tree says "if this
> > > leaf is not provided in the config data tree, act as if the default
> > > value is configured for the leaf". For operational state, my
> > > understanding is that the only benefit of a default statement is
> > > suppression of data in 'trim' and 'explicit' mode (RFC 6243).
> >
> > Agreed, but then it is protocol-dependent.
> >
>
> What is protocol dependent? RFC 6243 clarifies default handling
> options. And yes, if your server only does report-all basic mode, the
> default value has no effect.
>
> For RESTCONF, it seems that currently things boil down to
> report-all. But RESTCONF is not yet done (and I would hope that the
> text in section 4.5.2 will be critically reviewed - I agree that
> RESTCONF should simplify this, I am not sure what this section
> currently says is the right solution). That said, our job is to
> publish this data model - lets not worry about RESTCONF here.
>
>

I don't think with-defaults basic mode applies to config=false nodes.
The 'explicit' mode means the leaf is only a default if the client sets
the value (which cannot happen in NC or RC).

For config=false, a default leaf is only used to save bytes in an
<rpc-reply>.
A missing default leaf means the operational value is the same as the
default.
(Unless the reason the leaf is missing is because of filters or access
control.)


Andy


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/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a11c17334dae48204f9faf8aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, May 22, 2014 at 2:49 AM, Juergen Schoenwaelder <span dir=3D=
"ltr">&lt;<a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D=
"_blank">j.schoenwaelder@jacobs-university.de</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Thu, May 22, 2014 at 11:37:48AM +0200, La=
dislav Lhotka wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; My understanding is that a default in the config tree says &quot;=
if this<br>
&gt; &gt; leaf is not provided in the config data tree, act as if the defau=
lt<br>
&gt; &gt; value is configured for the leaf&quot;. For operational state, my=
<br>
&gt; &gt; understanding is that the only benefit of a default statement is<=
br>
&gt; &gt; suppression of data in &#39;trim&#39; and &#39;explicit&#39; mode=
 (RFC 6243).<br>
&gt;<br>
&gt; Agreed, but then it is protocol-dependent.<br>
&gt;<br>
<br>
What is protocol dependent? RFC 6243 clarifies default handling<br>
options. And yes, if your server only does report-all basic mode, the<br>
default value has no effect.<br>
<br>
For RESTCONF, it seems that currently things boil down to<br>
report-all. But RESTCONF is not yet done (and I would hope that the<br>
text in section 4.5.2 will be critically reviewed - I agree that<br>
RESTCONF should simplify this, I am not sure what this section<br>
currently says is the right solution). That said, our job is to<br>
publish this data model - lets not worry about RESTCONF here.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div><br></div><div>I don&#39;t think with-defaults basic=
 mode applies to config=3Dfalse nodes.</div><div>The &#39;explicit&#39; mod=
e means the leaf is only a default if the client sets</div>
<div>the value (which cannot happen in NC or RC).</div><div><br></div><div>=
For config=3Dfalse, a default leaf is only used to save bytes in an &lt;rpc=
-reply&gt;.</div><div>A missing default leaf means the operational value is=
 the same as the default.</div>
<div>(Unless the reason the leaf is missing is because of filters or access=
 control.)</div><div><br></div><div><br></div><div>Andy</div><div><br></div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888">
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH<br=
>
Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German=
y<br>
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 &lt;<a href=3D"http://www.jacobs-=
university.de/" target=3D"_blank">http://www.jacobs-university.de/</a>&gt;<=
br>
<br>
_______________________________________________<br>
netmod mailing list<br>
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/netmod</a><br>
</font></span></blockquote></div><br></div></div>

--001a11c17334dae48204f9faf8aa--


From nobody Thu May 22 04:04:25 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CDE1A018A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW8PlE7SmKQq for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:04:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55BA1A0180 for <netmod@ietf.org>; Thu, 22 May 2014 04:04:18 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5445713F971; Thu, 22 May 2014 13:04:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400756656; bh=m8JERiVwkdBT0nwq6maRybdlFzukg2e7ob/FksF7ntY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IdUoyYeOevVojT49YZW6E5AaVF436oXxD9X2acF6hLZK0D3JxpgdP3jlI6F6y8cZ9 5stJnAUtdiPegrh8CvV25VTmD6qxOcKhyt+Suh1Mk7w5pFLqoRJnq4TpEpuv0x0T2u 2UHe3a+0UceLOS0S9X0O4biRiL+a67KJPEPp8gMY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140522094955.GF90713@elstar.local>
Date: Thu, 22 May 2014 13:04:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ov57naqjA85oOuTe0IZjroxJcQo
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:04:25 -0000

On 22 May 2014, at 11:49, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
>>=20
>>>=20
>>> My understanding is that a default in the config tree says "if this
>>> leaf is not provided in the config data tree, act as if the default
>>> value is configured for the leaf". For operational state, my
>>> understanding is that the only benefit of a default statement is
>>> suppression of data in 'trim' and 'explicit' mode (RFC 6243).
>>=20
>> Agreed, but then it is protocol-dependent.
>>=20
>=20
> What is protocol dependent? RFC 6243 clarifies default handling
> options. And yes, if your server only does report-all basic mode, the
> default value has no effect.

It is protocol-dependent because the description of the semantics in =
this case has to start with =93In NETCONF, =85=94. In RESTCONF it =
currently means nothing, and it is not clear yet what it could possibly =
mean for I2RS.

Lada=20

>=20
> For RESTCONF, it seems that currently things boil down to
> report-all. But RESTCONF is not yet done (and I would hope that the
> text in section 4.5.2 will be critically reviewed - I agree that
> RESTCONF should simplify this, I am not sure what this section
> currently says is the right solution). That said, our job is to
> publish this data model - lets not worry about RESTCONF here.
>=20
> /js
>=20
> --=20
> 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/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 04:17:32 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937491A0180 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSgd74avNhd3 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:17:29 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583471A015E for <netmod@ietf.org>; Thu, 22 May 2014 04:17:29 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DFA1C1408D0; Thu, 22 May 2014 13:17:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400757447; bh=DTQkcBf+hBTdme2iJO17erefDzkb5n4IUTSPw5+0LJU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XJ3a/mJon6w1oG33UG4zSkBs7QDAgg4yQShd2sHO2PZF4wjUnxOkJx/orDKPghYvp XpeQFrXLnmO1pPpfsYgaBH8iEsWuGiFP1X9q4EnjbTqfEd9/DrsWthRklmdBsB+qwG b+BYrWFgahfKYWFFQkqCIwLMSLqtuImdxlt9LN6A=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHSWD_5XJf-hHd0uMgK-syUgd4Ku2iFp+7nvppwcjetOYw@mail.gmail.com>
Date: Thu, 22 May 2014 13:17:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <156B6527-3B56-46F7-9A14-4231F699CB72@nic.cz>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <CABCOCHSWD_5XJf-hHd0uMgK-syUgd4Ku2iFp+7nvppwcjetOYw@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9W0j0Zaof6ST_9DbgUgOPlJpUqo
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:17:30 -0000

On 22 May 2014, at 12:56, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Thu, May 22, 2014 at 2:49 AM, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
> >
> > >
> > > My understanding is that a default in the config tree says "if =
this
> > > leaf is not provided in the config data tree, act as if the =
default
> > > value is configured for the leaf". For operational state, my
> > > understanding is that the only benefit of a default statement is
> > > suppression of data in 'trim' and 'explicit' mode (RFC 6243).
> >
> > Agreed, but then it is protocol-dependent.
> >
>=20
> What is protocol dependent? RFC 6243 clarifies default handling
> options. And yes, if your server only does report-all basic mode, the
> default value has no effect.
>=20
> For RESTCONF, it seems that currently things boil down to
> report-all. But RESTCONF is not yet done (and I would hope that the
> text in section 4.5.2 will be critically reviewed - I agree that
> RESTCONF should simplify this, I am not sure what this section
> currently says is the right solution). That said, our job is to
> publish this data model - lets not worry about RESTCONF here.
>=20
>=20
>=20
> I don't think with-defaults basic mode applies to config=3Dfalse =
nodes.

IMO =91report-all=92 and =91trim=92 modes do apply.

Lada

> The 'explicit' mode means the leaf is only a default if the client =
sets
> the value (which cannot happen in NC or RC).
>=20
> For config=3Dfalse, a default leaf is only used to save bytes in an =
<rpc-reply>.
> A missing default leaf means the operational value is the same as the =
default.
> (Unless the reason the leaf is missing is because of filters or access =
control.)
>=20
>=20
> Andy
>=20
>=20
> 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/>
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 04:34:21 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372101A019F for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZB_x9IWwynr for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:34:16 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A615D1A0195 for <netmod@ietf.org>; Thu, 22 May 2014 04:34:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7B9AA1138; Thu, 22 May 2014 13:34:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WYsFE3fqVRDF; Thu, 22 May 2014 13:34:11 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 13:34:12 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F94F20034; Thu, 22 May 2014 13:33:58 +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 5pne3Oi2BCI7; Thu, 22 May 2014 13:33:57 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1974320031; Thu, 22 May 2014 13:33:57 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id EC5B62CF1EFE; Thu, 22 May 2014 13:33:56 +0200 (CEST)
Date: Thu, 22 May 2014 13:33:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@yumaworks.com>
Message-ID: <20140522113356.GB91270@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <CABCOCHSWD_5XJf-hHd0uMgK-syUgd4Ku2iFp+7nvppwcjetOYw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABCOCHSWD_5XJf-hHd0uMgK-syUgd4Ku2iFp+7nvppwcjetOYw@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zYeN-kxvYyi6RjVNJx3ws0xEJpA
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:34:18 -0000

On Thu, May 22, 2014 at 03:56:58AM -0700, Andy Bierman wrote:
> On Thu, May 22, 2014 at 2:49 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
> > >
> > > >
> > > > My understanding is that a default in the config tree says "if this
> > > > leaf is not provided in the config data tree, act as if the default
> > > > value is configured for the leaf". For operational state, my
> > > > understanding is that the only benefit of a default statement is
> > > > suppression of data in 'trim' and 'explicit' mode (RFC 6243).
> > >
> > > Agreed, but then it is protocol-dependent.
> > >
> >
> > What is protocol dependent? RFC 6243 clarifies default handling
> > options. And yes, if your server only does report-all basic mode, the
> > default value has no effect.
> >
> > For RESTCONF, it seems that currently things boil down to
> > report-all. But RESTCONF is not yet done (and I would hope that the
> > text in section 4.5.2 will be critically reviewed - I agree that
> > RESTCONF should simplify this, I am not sure what this section
> > currently says is the right solution). That said, our job is to
> > publish this data model - lets not worry about RESTCONF here.
> >
> 
> I don't think with-defaults basic mode applies to config=false nodes.

The modes are 'report-all', 'trim', 'explicit'. Basic mode says which
one of the three is the normal behaviour.

> The 'explicit' mode means the leaf is only a default if the client sets
> the value (which cannot happen in NC or RC).

Yes.

> For config=false, a default leaf is only used to save bytes in an
> <rpc-reply>.
> A missing default leaf means the operational value is the same as the
> default.
> (Unless the reason the leaf is missing is because of filters or access
> control.)

Are you saying a server that does 'report-all' as its basic mode has
to do 'trim' when it return config false data? This would surprise 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 nobody Thu May 22 04:35:44 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E4A1A01A0 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:35:42 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8CvxOywBKYN for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:35:40 -0700 (PDT)
Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F861A019F for <netmod@ietf.org>; Thu, 22 May 2014 04:35:40 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id z60so5311098qgd.23 for <netmod@ietf.org>; Thu, 22 May 2014 04:35:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BWlKSRh9BZXfPch8Ymib3CXyhwy8EdobBYXcEYT0iqU=; b=VPyEH/feJZhoM5/iydhQvLw5q/Dik77OXOoYWC0q2+ckaoppLipytez+xoSeQQ2CTk +WWxicsmwSWaBVA/PxigeXACrmBRgJ3yyPbR/3y8FrUth5wM3f8Fm/TmBhjdI7qKU3Bh clBzTA2RsbktgDtlIDWVKxwM1CK/8AmbbwZJdCrP3xknpFpi9zk7H98dxQ6THzPP85TB xswIWL192VViR3mtMF9zJfEkel9HHHxDeZS4JJksO4MYrLKF5JjEWRTFvJ10PQJKm4oc uEOgDsANkz80lXtlm1vGcKzxnng74L3/GlI/r5Qhdx3ydVwNLvAHBPZewnXTfcpHXGl1 k4pQ==
X-Gm-Message-State: ALoCoQlcUEEvz+hmxrL8F+QD4tRDS6bmmhaOKMi8bPAC7GeKQiCOSQjPpIdf+C++2XYlpwTpnrhx
MIME-Version: 1.0
X-Received: by 10.229.192.7 with SMTP id do7mr78848866qcb.1.1400758538759; Thu, 22 May 2014 04:35:38 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 22 May 2014 04:35:38 -0700 (PDT)
In-Reply-To: <156B6527-3B56-46F7-9A14-4231F699CB72@nic.cz>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <CABCOCHSWD_5XJf-hHd0uMgK-syUgd4Ku2iFp+7nvppwcjetOYw@mail.gmail.com> <156B6527-3B56-46F7-9A14-4231F699CB72@nic.cz>
Date: Thu, 22 May 2014 04:35:38 -0700
Message-ID: <CABCOCHQMttTquGVxou7qUpJJTuxhVjYV0eGf+qAOLeg29u-OhA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11337d4a1ea9bc04f9fb8370
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uuJ3BRRmyK9ioUKt9OJnqeNJ-3w
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:35:42 -0000

--001a11337d4a1ea9bc04f9fb8370
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 22, 2014 at 4:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 22 May 2014, at 12:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Thu, May 22, 2014 at 2:49 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
> > >
> > > >
> > > > My understanding is that a default in the config tree says "if this
> > > > leaf is not provided in the config data tree, act as if the default
> > > > value is configured for the leaf". For operational state, my
> > > > understanding is that the only benefit of a default statement is
> > > > suppression of data in 'trim' and 'explicit' mode (RFC 6243).
> > >
> > > Agreed, but then it is protocol-dependent.
> > >
> >
> > What is protocol dependent? RFC 6243 clarifies default handling
> > options. And yes, if your server only does report-all basic mode, the
> > default value has no effect.
> >
> > For RESTCONF, it seems that currently things boil down to
> > report-all. But RESTCONF is not yet done (and I would hope that the
> > text in section 4.5.2 will be critically reviewed - I agree that
> > RESTCONF should simplify this, I am not sure what this section
> > currently says is the right solution). That said, our job is to
> > publish this data model - lets not worry about RESTCONF here.
> >
> >
> >
> > I don't think with-defaults basic mode applies to config=false nodes.
>
> IMO 'report-all' and 'trim' modes do apply.
>
>
They do not have any conformance meaning like configuration.
There is no requirement on the server to have any particular
operational state "by default".

A YANG default is the value in use if the leaf is not present.
For 'explicit', the client cannot set config=false so this mode does not
apply.
For 'report-all', every leaf is reported so a missing leaf in a <get> reply
does not mean anything either.  For 'trim', it could mean the YANG default
is the operational value for a missing leaf.

But access control can cause a config=false leaf to be missing in
a <get> reply so a client should never assume the YANG default
is the operational value in effect.

It is also unclear what mandatory=false means for config=false nodes.
This means the server is NEVER required to return a value (so how
does the client even know the server implements the node?)



> Lada
>

Andy



>
> > The 'explicit' mode means the leaf is only a default if the client sets
> > the value (which cannot happen in NC or RC).
> >
> > For config=false, a default leaf is only used to save bytes in an
> <rpc-reply>.
> > A missing default leaf means the operational value is the same as the
> default.
> > (Unless the reason the leaf is missing is because of filters or access
> control.)
> >
> >
> > Andy
> >
> >
> > 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/>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11337d4a1ea9bc04f9fb8370
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, May 22, 2014 at 4:17 AM, Ladislav Lhotka <span dir=3D"ltr">=
&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 22 May 2014, at 12:56, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, May 22, 2014 at 2:49 AM, Juergen Schoenwaelder &lt;<a href=3D"=
mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-univers=
ity.de</a>&gt; wrote:<br>
&gt; On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; My understanding is that a default in the config tree says &=
quot;if this<br>
&gt; &gt; &gt; leaf is not provided in the config data tree, act as if the =
default<br>
&gt; &gt; &gt; value is configured for the leaf&quot;. For operational stat=
e, my<br>
&gt; &gt; &gt; understanding is that the only benefit of a default statemen=
t is<br>
&gt; &gt; &gt; suppression of data in &#39;trim&#39; and &#39;explicit&#39;=
 mode (RFC 6243).<br>
&gt; &gt;<br>
&gt; &gt; Agreed, but then it is protocol-dependent.<br>
&gt; &gt;<br>
&gt;<br>
&gt; What is protocol dependent? RFC 6243 clarifies default handling<br>
&gt; options. And yes, if your server only does report-all basic mode, the<=
br>
&gt; default value has no effect.<br>
&gt;<br>
&gt; For RESTCONF, it seems that currently things boil down to<br>
&gt; report-all. But RESTCONF is not yet done (and I would hope that the<br=
>
&gt; text in section 4.5.2 will be critically reviewed - I agree that<br>
&gt; RESTCONF should simplify this, I am not sure what this section<br>
&gt; currently says is the right solution). That said, our job is to<br>
&gt; publish this data model - lets not worry about RESTCONF here.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I don&#39;t think with-defaults basic mode applies to config=3Dfalse n=
odes.<br>
<br>
IMO &lsquo;report-all&rsquo; and &lsquo;trim&rsquo; modes do apply.<br>
<br></blockquote><div><br></div><div>They do not have any conformance meani=
ng like configuration.</div><div>There is no requirement on the server to h=
ave any particular</div><div>operational state &quot;by default&quot;.</div=
>
<div><br></div><div>A YANG default is the value in use if the leaf is not p=
resent.</div><div>For &#39;explicit&#39;, the client cannot set config=3Dfa=
lse so this mode does not apply.</div><div>For &#39;report-all&#39;, every =
leaf is reported so a missing leaf in a &lt;get&gt; reply</div>
<div>does not mean anything either. &nbsp;For &#39;trim&#39;, it could mean=
 the YANG default</div><div>is the operational value for a missing leaf.</d=
iv><div><br></div><div>But access control can cause a config=3Dfalse leaf t=
o be missing in</div>
<div>a &lt;get&gt; reply so a client should never assume the YANG default</=
div><div>is the operational value in effect.</div><div><br></div><div>It is=
 also unclear what mandatory=3Dfalse means for config=3Dfalse nodes.</div><=
div>
This means the server is NEVER required to return a value (so how</div><div=
>does the client even know the server implements the node?)</div><div><br><=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Lada<br></blockquote><div><br></div><div>Andy</div><div><br></div><div>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; The &#39;explicit&#39; mode means the leaf is only a default if the cl=
ient sets<br>
&gt; the value (which cannot happen in NC or RC).<br>
&gt;<br>
&gt; For config=3Dfalse, a default leaf is only used to save bytes in an &l=
t;rpc-reply&gt;.<br>
&gt; A missing default leaf means the operational value is the same as the =
default.<br>
&gt; (Unless the reason the leaf is missing is because of filters or access=
 control.)<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt; Juergen Schoenwaelder &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Jacobs Univer=
sity Bremen gGmbH<br>
&gt; Phone: +49 421 200 3587 &nbsp; &nbsp; &nbsp; &nbsp; Campus Ring 1, 287=
59 Bremen, Germany<br>
&gt; Fax: &nbsp; +49 421 200 3103 &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href=
=3D"http://www.jacobs-university.de/" target=3D"_blank">http://www.jacobs-u=
niversity.de/</a>&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; netmod mailing list<br>
&gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11337d4a1ea9bc04f9fb8370--


From nobody Thu May 22 04:35:55 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9251A01A9 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRJmGybWoFi8 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:35:44 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1F81A019F for <netmod@ietf.org>; Thu, 22 May 2014 04:35:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4CA511136; Thu, 22 May 2014 13:35:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jDOpxzYZp00d; Thu, 22 May 2014 13:35:40 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 13:35:41 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A826D20013; Thu, 22 May 2014 13:35:41 +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 ge6K22KM2eFm; Thu, 22 May 2014 13:35:40 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AB332002C; Thu, 22 May 2014 13:35:40 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 097822CF1F2D; Thu, 22 May 2014 13:35:40 +0200 (CEST)
Date: Thu, 22 May 2014 13:35:39 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140522113539.GC91270@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/A1bOFHEQHJySUznaM9MW-b6Vmeg
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:35:48 -0000

On Thu, May 22, 2014 at 01:04:15PM +0200, Ladislav Lhotka wrote:
> 
> On 22 May 2014, at 11:49, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
> >> 
> >>> 
> >>> My understanding is that a default in the config tree says "if this
> >>> leaf is not provided in the config data tree, act as if the default
> >>> value is configured for the leaf". For operational state, my
> >>> understanding is that the only benefit of a default statement is
> >>> suppression of data in 'trim' and 'explicit' mode (RFC 6243).
> >> 
> >> Agreed, but then it is protocol-dependent.
> >> 
> > 
> > What is protocol dependent? RFC 6243 clarifies default handling
> > options. And yes, if your server only does report-all basic mode, the
> > default value has no effect.
> 
> It is protocol-dependent because the description of the semantics in this case has to start with “In NETCONF, â€Ĥ”. In RESTCONF it currently means nothing, and it is not clear yet what it could possibly mean for I2RS.
> 

I can't follow you. Why would the semantics of the leafs have to be
different?

/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 nobody Thu May 22 04:47:48 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6E31A018A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBG_KMOnfMf6 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:47:46 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417331A0027 for <netmod@ietf.org>; Thu, 22 May 2014 04:47:46 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6596D14128B; Thu, 22 May 2014 13:47:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400759263; bh=GTY1pY01/b703zTBxQBrkQ2yO3uIkiP+65YpWf9S8CY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KsMCNlLkTmso+03kOMB2lGOSa9ssWtRJC3G9RVwS7SAdbqyL6rNT3jgZXhtEIBOn8 xU+qQf72KjqL0Wd62Hcf3cQBTnJTClrYnOy04mROGXmfjzvN+kE2iaMiU+8H/mihBt JHB5unoKb2w7Xd1QR8U4dc1OwEgmf4P6I7TyR6v4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140522113539.GC91270@elstar.jacobs.jacobs-university.de>
Date: Thu, 22 May 2014 13:47:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B9BD293-479F-43CA-84BA-4286AA75C9CF@nic.cz>
References: <20140519162023.GA80368@elstar.jacobs.jacobs-university.de> <m2sio39ysw.fsf@dev.martin.serak.ws.eth.2.office.nic.cz> <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz> <20140522113539.GC91270@elstar.jacobs.jacobs-university.de>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gLsBngolvUefBQZKPAywhZd1-ds
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:47:47 -0000

On 22 May 2014, at 13:35, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, May 22, 2014 at 01:04:15PM +0200, Ladislav Lhotka wrote:
>>=20
>> On 22 May 2014, at 11:49, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
>>=20
>>> On Thu, May 22, 2014 at 11:37:48AM +0200, Ladislav Lhotka wrote:
>>>>=20
>>>>>=20
>>>>> My understanding is that a default in the config tree says "if =
this
>>>>> leaf is not provided in the config data tree, act as if the =
default
>>>>> value is configured for the leaf". For operational state, my
>>>>> understanding is that the only benefit of a default statement is
>>>>> suppression of data in 'trim' and 'explicit' mode (RFC 6243).
>>>>=20
>>>> Agreed, but then it is protocol-dependent.
>>>>=20
>>>=20
>>> What is protocol dependent? RFC 6243 clarifies default handling
>>> options. And yes, if your server only does report-all basic mode, =
the
>>> default value has no effect.
>>=20
>> It is protocol-dependent because the description of the semantics in =
this case has to start with =93In NETCONF, =85=94. In RESTCONF it =
currently means nothing, and it is not clear yet what it could possibly =
mean for I2RS.
>>=20
>=20
> I can't follow you. Why would the semantics of the leafs have to be
> different?

I mean sematics of the =91default=92 statement - what it actually means =
for state data seems to depend on the protocol.

The definitions in sec. 7.6.1 of RFC 6020 are clarly aimed at =
configuration data:

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.

For state data and NETCONF protocol, required server behaviour may =
depend on the with-defaults mode.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 04:52:59 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8BD1A018A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI5RME-D9e7S for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 04:52:57 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CDE1A0027 for <netmod@ietf.org>; Thu, 22 May 2014 04:52:56 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7B7010DA; Thu, 22 May 2014 13:52:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RNaL4xM-6WRo; Thu, 22 May 2014 13:52:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 13:52:54 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45E092002C; Thu, 22 May 2014 13:52:54 +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 W8tpqGefqdYm; Thu, 22 May 2014 13:52:53 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 877D920013; Thu, 22 May 2014 13:52:53 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 662D32CF2338; Thu, 22 May 2014 13:52:53 +0200 (CEST)
Date: Thu, 22 May 2014 13:52:53 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140522115253.GB91448@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz> <20140522113539.GC91270@elstar.jacobs.jacobs-university.de> <4B9BD293-479F-43CA-84BA-4286AA75C9CF@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B9BD293-479F-43CA-84BA-4286AA75C9CF@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/95Z3v6PS-Up8dRgXKGrQnUojhbc
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 11:52:58 -0000

On Thu, May 22, 2014 at 01:47:42PM +0200, Ladislav Lhotka wrote:
> 
> The definitions in sec. 7.6.1 of RFC 6020 are clarly aimed at configuration data:
> 
>    The default value of a leaf is the value that the server uses if the
>    leaf does not exist in the data tree.
> 
> For state data and NETCONF protocol, required server behaviour may depend on the with-defaults mode.
> 

Yes. But this is not a problem for finishing up this document so
lets not get side tracked.

/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 nobody Thu May 22 05:30:07 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA11A001A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 05:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRx6mV9ctdFW for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 05:30:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222261A0039 for <netmod@ietf.org>; Thu, 22 May 2014 05:30:02 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8532E13F971; Thu, 22 May 2014 14:29:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400761799; bh=ZALeFBX1kOAYhVGdgSTTrqDpUmUPqZhkMvxyCPR0OYs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ck1q5EdF/pZbm+anJvLmkPGda8tT81LZcopCBfJYFBV0OLzpsoWGSv96RgCgiqQEn u6Pd6zBRtGgms2UyMwmc4V7OQ2kdeWQZrGXVYFk9zHi/J/g+9PjlVNEQqeSWCzgbbZ TgJpKZFBnuX4WeSsp+A6qYxHiGHMqS2cRtewRWcw=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140522115253.GB91448@elstar.jacobs.jacobs-university.de>
Date: Thu, 22 May 2014 14:29:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <595C7B87-FAD9-42A6-9505-E10C6DB900A8@nic.cz>
References: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz> <20140522113539.GC91270@elstar.jacobs.jacobs-university.de> <4B9BD293-479F-43CA-84BA-4286AA75C9CF@nic.cz> <20140522115253.GB91448@elstar.jacobs.jacobs-university.de>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Z36pKAhq2JnfsL_1KBsdHlhfB4o
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 12:30:04 -0000

On 22 May 2014, at 13:52, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, May 22, 2014 at 01:47:42PM +0200, Ladislav Lhotka wrote:
>>=20
>> The definitions in sec. 7.6.1 of RFC 6020 are clarly aimed at =
configuration data:
>>=20
>>   The default value of a leaf is the value that the server uses if =
the
>>   leaf does not exist in the data tree.
>>=20
>> For state data and NETCONF protocol, required server behaviour may =
depend on the with-defaults mode.
>>=20
>=20
> Yes. But this is not a problem for finishing up this document so
> lets not get side tracked.

Of course. I am now ready to post revision -14, can I do it if the draft =
is stil in the state =93Waiting for WG Chair Go-Ahead=94?

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 05:53:53 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03951A001A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 05:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gTYH8WihZgb for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 05:53:48 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A006C1A0147 for <netmod@ietf.org>; Thu, 22 May 2014 05:53:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6E34BF55; Thu, 22 May 2014 14:53:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ihBYWX3Eymyx; Thu, 22 May 2014 14:53:44 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 14:53:45 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB4972002C; Thu, 22 May 2014 14:53:45 +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 uqLXHkt0a-3B; Thu, 22 May 2014 14:53:45 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1AA2A20013; Thu, 22 May 2014 14:53:45 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 0557A2CF26A5; Thu, 22 May 2014 14:53:43 +0200 (CEST)
Date: Thu, 22 May 2014 14:53:42 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140522125341.GA91552@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140522090708.GB90713@elstar.local> <5900E5E9-8E2A-4CAE-9FA8-74D35800C750@nic.cz> <20140522093247.GD90713@elstar.local> <405E1B27-300E-4FC6-B489-41442FE789F0@nic.cz> <20140522094955.GF90713@elstar.local> <70E4CF8F-1B92-427B-AA01-A72CECCFE6CA@nic.cz> <20140522113539.GC91270@elstar.jacobs.jacobs-university.de> <4B9BD293-479F-43CA-84BA-4286AA75C9CF@nic.cz> <20140522115253.GB91448@elstar.jacobs.jacobs-university.de> <595C7B87-FAD9-42A6-9505-E10C6DB900A8@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <595C7B87-FAD9-42A6-9505-E10C6DB900A8@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ULYA9Bu4ZDo_Fp9PLmAZGNhqSIM
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 12:53:50 -0000

On Thu, May 22, 2014 at 02:29:58PM +0200, Ladislav Lhotka wrote:
> 
> On 22 May 2014, at 13:52, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Thu, May 22, 2014 at 01:47:42PM +0200, Ladislav Lhotka wrote:
> >> 
> >> The definitions in sec. 7.6.1 of RFC 6020 are clarly aimed at configuration data:
> >> 
> >>   The default value of a leaf is the value that the server uses if the
> >>   leaf does not exist in the data tree.
> >> 
> >> For state data and NETCONF protocol, required server behaviour may depend on the with-defaults mode.
> >> 
> > 
> > Yes. But this is not a problem for finishing up this document so
> > lets not get side tracked.
> 
> Of course. I am now ready to post revision -14, can I do it if the draft is stil in the state “Waiting for WG Chair Go-Ahead”?
> 

Yes.

/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 nobody Thu May 22 08:54:56 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8286C1A01E0; Thu, 22 May 2014 08:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaVoQamwNMxa; Thu, 22 May 2014 08:54:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1221A1A01C8; Thu, 22 May 2014 08:54:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140522155452.23520.17757.idtracker@ietfa.amsl.com>
Date: Thu, 22 May 2014 08:54:52 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/w5viBpVkLTm93_i0G3Ffu7s5a58
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-14.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 15:54:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : A YANG Data Model for Routing Management
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-routing-cfg-14.txt
	Pages           : 95
	Date            : 2014-05-22

Abstract:
   This document contains a specification of three YANG modules.
   Together they form the core routing data model which serves as a
   framework for configuring and managing a routing subsystem.  It is
   expected that these modules will be augmented by additional YANG
   modules defining data models for individual routing protocols and
   other related functions.  The core routing data model provides common
   building blocks for such extensions - routing instances, routes,
   routing information bases (RIB), routing protocols and route filters.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Thu May 22 12:23:37 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B11A030C for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 12:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmhcDwKqB6dQ for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 12:23:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB411A01E1 for <netmod@ietf.org>; Thu, 22 May 2014 12:23:31 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C7493F401E; Thu, 22 May 2014 21:23:28 +0200 (CEST)
Date: Thu, 22 May 2014 21:23:27 +0200 (CEST)
Message-Id: <20140522.212327.40777774.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20140522090708.GB90713@elstar.local>
References: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T5Fryl4_WTE-YV4fXBCXrhY9gI0
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 19:23:34 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, May 22, 2014 at 10:56:41AM +0200, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes=
:
> > =

> > > On Wed, May 21, 2014 at 01:05:51PM +0200, Ladislav Lhotka wrote:
> > >> Hi J=FCrgen,
> > >> =

> > >> thanks for the review, please see my responses inline.
> > >
> > > Removing everything marked Done...
> > >
> > >> > f) The leaf cur-hop-limit in the state tree has a default stat=
ement
> > >> >    and also this sentence:
> > >> >
> > >> >               The default SHOULD be set to the value specified=
 in IANA
> > >> >               Assigned Numbers that was in effect at the time =
of
> > >> >               implementation.
> > >> >
> > >> >    First, a default in the state tree is not really that usefu=
l.  This
> > >> >    text seems to imply that there should be no default at all =
since
> > >> >    the value can change. I think this SHOULD text should also =
be moved
> > >> >    to the corresponding object in the configuration subtree.
> > >> =

> > >> I agree the default should be probably removed, but then the tex=
t is an
> > >> information for the server implementor about how to choose the o=
perational
> > >> default. One option would be to make cur-hop-limit mandatory ins=
tead - so
> > >> a server implementor chooses an operational default value but th=
e server
> > >> has to report it.
> > >> =

> > >
> > > Now I see your point - you want to not report cur-hop-limit as lo=
ng as
> > > it is 64 (when you do not use explicit defaults during the
> > > retrieval). Hm. More below... I guess my problem really is with t=
he
> > > text saying how to choose a value if no explicit config is provid=
ed.
> > =

> > I think it is somewhat unclear what the following sentence in 6020 =
means for
> > defaults in configuration data:
> > =

> >    When the default value is in use, the server MUST operationally
> >    behave as if the leaf was present in the data tree with the defa=
ult
> >    value as its value.
> > =

> > For example, assume the data model defines the default value for
> > 'cur-hop-limit' in *config* to be 64. Now, IANA changes the default=
 TTL, and
> > device X uses this new value as its operational default (independen=
t of
> > NETCONF). It can now mean two things:
> > =

> > 1. Device X is no more compliant with the data model, or
> > =

> > 2. When the NETCONF server is started on device X, it has to change=
 the
> > 'cur-hop-limit' to 64 on its own so that the contract with its clie=
nts
> > expressed by the data model still holds.
> =

> I would say 2. But in this case, there is no static default - the
> default can be changed by IANA. Hence, there should not be a default
> on the config leaf. There can only be text describing how to pick a
> value if the leaf is not provided.

I agree.

I noticed that in -14, this leaf has a default value of 64, and the
text that contradicts the default statement.  Did I miss something in
your mail discussion?  Shouldn't the default statement be removed?

This leaf's description says:

  The default value to be placed in the Cur Hop Limit field
      ^^^^^^^^^^^^^

All other similar leaf has this:

  The value to be placed in the XXX field

Should s/default value/value?  If not, what does this mean?


Minor nit: this leaf's reference text has hypens before the RFCs; that
sticks out as compared to the other leafs, and compared to e.g. the
system draft.


/martin


From nobody Thu May 22 13:06:14 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B161B1A02F1 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 13:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AuH6QqB7e2h for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 13:06:10 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC7C1A02DE for <netmod@ietf.org>; Thu, 22 May 2014 13:06:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8D691128; Thu, 22 May 2014 22:06:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HTNY6SIPlbpI; Thu, 22 May 2014 22:06:04 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 22:06:07 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76B1920017; Thu, 22 May 2014 22:06: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 XD7vL0D-bY3N; Thu, 22 May 2014 22:06:06 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6513C20013; Thu, 22 May 2014 22:06:06 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id BDF1E2CF2FE9; Thu, 22 May 2014 22:06:05 +0200 (CEST)
Date: Thu, 22 May 2014 22:06:05 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20140522200605.GA92422@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, lhotka@nic.cz, netmod@ietf.org
References: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140522.212327.40777774.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1cLqRY6cY3EQdc07hO-LsANxvyY
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 20:06:12 -0000

On Thu, May 22, 2014 at 09:23:27PM +0200, Martin Bjorklund wrote:
> 
> I noticed that in -14, this leaf has a default value of 64, and the
> text that contradicts the default statement.  Did I miss something in
> your mail discussion?  Shouldn't the default statement be removed?
> 

This kind of started this debate. ;-)

/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 nobody Thu May 22 13:08:22 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F6D1A0271 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 13:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqM3l0f1bZSx for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 13:08:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D9D1D1A026A for <netmod@ietf.org>; Thu, 22 May 2014 13:08:17 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id EAD2F3F401E; Thu, 22 May 2014 22:08:15 +0200 (CEST)
Date: Thu, 22 May 2014 22:08:15 +0200 (CEST)
Message-Id: <20140522.220815.422102117.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20140522200605.GA92422@elstar.jacobs.jacobs-university.de>
References: <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com> <20140522200605.GA92422@elstar.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/STLRKF1wERdO0g3QEh_VidT165Y
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 20:08:19 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Thu, May 22, 2014 at 09:23:27PM +0200, Martin Bjorklund wrote:
> > 
> > I noticed that in -14, this leaf has a default value of 64, and the
> > text that contradicts the default statement.  Did I miss something in
> > your mail discussion?  Shouldn't the default statement be removed?
> > 
> 
> This kind of started this debate. ;-)

Right, but I thought it was resolved (i.e., that the default should be
removed)?


/martin


From nobody Thu May 22 13:30:40 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9832A1A030A for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 13:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gMsmzz4S_Mz for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 13:30:37 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269101A032F for <netmod@ietf.org>; Thu, 22 May 2014 13:30:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BFACB1153; Thu, 22 May 2014 22:30:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zJHd_ix1R48b; Thu, 22 May 2014 22:30:29 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 May 2014 22:30:32 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2EF120034; Thu, 22 May 2014 22:30: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 XCdROvOavQRq; Thu, 22 May 2014 22:30:29 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBE252002F; Thu, 22 May 2014 22:30:28 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id D46E92CF30A1; Thu, 22 May 2014 22:30:28 +0200 (CEST)
Date: Thu, 22 May 2014 22:30:28 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20140522203028.GC92422@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, lhotka@nic.cz, netmod@ietf.org
References: <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com> <20140522200605.GA92422@elstar.jacobs.jacobs-university.de> <20140522.220815.422102117.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140522.220815.422102117.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ikWFDcgh_P1yJh3L4L-hTzUvbHQ
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 20:30:38 -0000

On Thu, May 22, 2014 at 10:08:15PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Thu, May 22, 2014 at 09:23:27PM +0200, Martin Bjorklund wrote:
> > > 
> > > I noticed that in -14, this leaf has a default value of 64, and the
> > > text that contradicts the default statement.  Did I miss something in
> > > your mail discussion?  Shouldn't the default statement be removed?
> > > 
> > 
> > This kind of started this debate. ;-)
> 
> Right, but I thought it was resolved (i.e., that the default should be
> removed)?
> 

Yes.

/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 nobody Thu May 22 15:47:36 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE931A0226 for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 15:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9-QkGvn3lgy for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 15:47:30 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02861A0270 for <netmod@ietf.org>; Thu, 22 May 2014 15:47:29 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CC48D13F971; Fri, 23 May 2014 00:47:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400798842; bh=CL6kyjOvCxHAcNmuCmLaus1mGuQdlcWbe3N3Hewhn+k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wimiXsBdIOh2OjBA9T1vnkjkRCDdNJMkovorwHkiRk6LwAU4bwxTWdN7teAI1BAqg OqquE+WqUdfgLppRBth98CfAg+GgAxzBx53OV3qnxvPV0pFvsh+FgRf8eVbPnEJstx YU6rLFBjofRJgBrQ5cWbfGXuac3yAPK4ZG9SQhCs=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140522.212327.40777774.mbj@tail-f.com>
Date: Fri, 23 May 2014 00:47:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B0274C7-472D-480C-990B-378BBE7F7884@nic.cz>
References: <20140521121830.GA88012@elstar.jacobs.jacobs-university.de> <m261kyqjhy.fsf@nic.cz> <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nnZq_OacAPd7cAKSrdGerTpMHqA
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 22:47:34 -0000

On 22 May 2014, at 21:23, Martin Bjorklund <mbj@tail-f.com> wrote:

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>> On Thu, May 22, 2014 at 10:56:41AM +0200, Ladislav Lhotka wrote:
>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
>>>=20
>>>> On Wed, May 21, 2014 at 01:05:51PM +0200, Ladislav Lhotka wrote:
>>>>> Hi J=FCrgen,
>>>>>=20
>>>>> thanks for the review, please see my responses inline.
>>>>=20
>>>> Removing everything marked Done...
>>>>=20
>>>>>> f) The leaf cur-hop-limit in the state tree has a default =
statement
>>>>>>   and also this sentence:
>>>>>>=20
>>>>>>              The default SHOULD be set to the value specified in =
IANA
>>>>>>              Assigned Numbers that was in effect at the time of
>>>>>>              implementation.
>>>>>>=20
>>>>>>   First, a default in the state tree is not really that useful.  =
This
>>>>>>   text seems to imply that there should be no default at all =
since
>>>>>>   the value can change. I think this SHOULD text should also be =
moved
>>>>>>   to the corresponding object in the configuration subtree.
>>>>>=20
>>>>> I agree the default should be probably removed, but then the text =
is an
>>>>> information for the server implementor about how to choose the =
operational
>>>>> default. One option would be to make cur-hop-limit mandatory =
instead - so
>>>>> a server implementor chooses an operational default value but the =
server
>>>>> has to report it.
>>>>>=20
>>>>=20
>>>> Now I see your point - you want to not report cur-hop-limit as long =
as
>>>> it is 64 (when you do not use explicit defaults during the
>>>> retrieval). Hm. More below... I guess my problem really is with the
>>>> text saying how to choose a value if no explicit config is =
provided.
>>>=20
>>> I think it is somewhat unclear what the following sentence in 6020 =
means for
>>> defaults in configuration data:
>>>=20
>>>   When the default value is in use, the server MUST operationally
>>>   behave as if the leaf was present in the data tree with the =
default
>>>   value as its value.
>>>=20
>>> For example, assume the data model defines the default value for
>>> 'cur-hop-limit' in *config* to be 64. Now, IANA changes the default =
TTL, and
>>> device X uses this new value as its operational default (independent =
of
>>> NETCONF). It can now mean two things:
>>>=20
>>> 1. Device X is no more compliant with the data model, or
>>>=20
>>> 2. When the NETCONF server is started on device X, it has to change =
the
>>> 'cur-hop-limit' to 64 on its own so that the contract with its =
clients
>>> expressed by the data model still holds.
>>=20
>> I would say 2. But in this case, there is no static default - the
>> default can be changed by IANA. Hence, there should not be a default
>> on the config leaf. There can only be text describing how to pick a
>> value if the leaf is not provided.
>=20
> I agree.
>=20
> I noticed that in -14, this leaf has a default value of 64, and the
> text that contradicts the default statement.  Did I miss something in
> your mail discussion?  Shouldn't the default statement be removed?

In his item (f), J=FCrgen was specifically complaining about the default =
for =91cur-hop-limit=92 in state data, and I removed that one. I think =
it is appropriate to leave it in config because that value doesn=92t =
seem to change very often. If there is no default value at all, the =
client may have no way to find out what value the server actually uses.

I also thought we agreed with J=FCrgen that even if IANA changes the =
default TTL there is no immediate need to update the =
ietf-ipv6-unicast-routing module - it is up to the NETCONF server to =
keep the contract and set the operational value to 64.=20

>=20
> This leaf's description says:
>=20
>  The default value to be placed in the Cur Hop Limit field
>      ^^^^^^^^^^^^^
>=20
> All other similar leaf has this:
>=20
>  The value to be placed in the XXX field
>=20
> Should s/default value/value?  If not, what does this mean?

I just used the text from RFC 4861. I guess it means it is the =93default =
TTL value=94 - the host that receives the RA may use another value. I do =
agree though that s/default value/value/ makes sense here.=20

>=20
>=20
> Minor nit: this leaf's reference text has hypens before the RFCs; that
> sticks out as compared to the other leafs, and compared to e.g. the
> system draft.

There are actually two references in that =91reference=92 statement, so =
I made them into an itemized list. Other leafs have only one reference.

Lada=20

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu May 22 23:13:45 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838791A038C for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 23:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a31uXAGVKbrn for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 23:13:43 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFE01A0015 for <netmod@ietf.org>; Thu, 22 May 2014 23:13:42 -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 AAF41574003; Fri, 23 May 2014 08:13:39 +0200 (CEST)
Date: Fri, 23 May 2014 08:13:39 +0200 (CEST)
Message-Id: <20140523.081339.665022241963872091.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <3B0274C7-472D-480C-990B-378BBE7F7884@nic.cz>
References: <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com> <3B0274C7-472D-480C-990B-378BBE7F7884@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gVBU3RmJdYIl6_TYxUotM5adg30
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 06:13:44 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDIyIE1heSAy
MDE0LCBhdCAyMToyMywgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K
PiANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p
dmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+IE9uIFRodSwgTWF5IDIyLCAyMDE0IGF0IDEwOjU2OjQx
QU0gKzAyMDAsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPj4+IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cml0ZXM6DQo+ID4+
PiANCj4gPj4+PiBPbiBXZWQsIE1heSAyMSwgMjAxNCBhdCAwMTowNTo1MVBNICswMjAwLCBMYWRp
c2xhdiBMaG90a2Egd3JvdGU6DQo+ID4+Pj4+IEhpIErDvHJnZW4sDQo+ID4+Pj4+IA0KPiA+Pj4+
PiB0aGFua3MgZm9yIHRoZSByZXZpZXcsIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4N
Cj4gPj4+PiANCj4gPj4+PiBSZW1vdmluZyBldmVyeXRoaW5nIG1hcmtlZCBEb25lLi4uDQo+ID4+
Pj4gDQo+ID4+Pj4+PiBmKSBUaGUgbGVhZiBjdXItaG9wLWxpbWl0IGluIHRoZSBzdGF0ZSB0cmVl
IGhhcyBhIGRlZmF1bHQgc3RhdGVtZW50DQo+ID4+Pj4+PiAgIGFuZCBhbHNvIHRoaXMgc2VudGVu
Y2U6DQo+ID4+Pj4+PiANCj4gPj4+Pj4+ICAgICAgICAgICAgICBUaGUgZGVmYXVsdCBTSE9VTEQg
YmUgc2V0IHRvIHRoZSB2YWx1ZSBzcGVjaWZpZWQgaW4gSUFOQQ0KPiA+Pj4+Pj4gICAgICAgICAg
ICAgIEFzc2lnbmVkIE51bWJlcnMgdGhhdCB3YXMgaW4gZWZmZWN0IGF0IHRoZSB0aW1lIG9mDQo+
ID4+Pj4+PiAgICAgICAgICAgICAgaW1wbGVtZW50YXRpb24uDQo+ID4+Pj4+PiANCj4gPj4+Pj4+
ICAgRmlyc3QsIGEgZGVmYXVsdCBpbiB0aGUgc3RhdGUgdHJlZSBpcyBub3QgcmVhbGx5IHRoYXQg
dXNlZnVsLiAgVGhpcw0KPiA+Pj4+Pj4gICB0ZXh0IHNlZW1zIHRvIGltcGx5IHRoYXQgdGhlcmUg
c2hvdWxkIGJlIG5vIGRlZmF1bHQgYXQgYWxsIHNpbmNlDQo+ID4+Pj4+PiAgIHRoZSB2YWx1ZSBj
YW4gY2hhbmdlLiBJIHRoaW5rIHRoaXMgU0hPVUxEIHRleHQgc2hvdWxkIGFsc28gYmUgbW92ZWQN
Cj4gPj4+Pj4+ICAgdG8gdGhlIGNvcnJlc3BvbmRpbmcgb2JqZWN0IGluIHRoZSBjb25maWd1cmF0
aW9uIHN1YnRyZWUuDQo+ID4+Pj4+IA0KPiA+Pj4+PiBJIGFncmVlIHRoZSBkZWZhdWx0IHNob3Vs
ZCBiZSBwcm9iYWJseSByZW1vdmVkLCBidXQgdGhlbiB0aGUgdGV4dCBpcw0KPiA+Pj4+PiBhbg0K
PiA+Pj4+PiBpbmZvcm1hdGlvbiBmb3IgdGhlIHNlcnZlciBpbXBsZW1lbnRvciBhYm91dCBob3cg
dG8gY2hvb3NlIHRoZQ0KPiA+Pj4+PiBvcGVyYXRpb25hbA0KPiA+Pj4+PiBkZWZhdWx0LiBPbmUg
b3B0aW9uIHdvdWxkIGJlIHRvIG1ha2UgY3VyLWhvcC1saW1pdCBtYW5kYXRvcnkgaW5zdGVhZCAt
DQo+ID4+Pj4+IHNvDQo+ID4+Pj4+IGEgc2VydmVyIGltcGxlbWVudG9yIGNob29zZXMgYW4gb3Bl
cmF0aW9uYWwgZGVmYXVsdCB2YWx1ZSBidXQgdGhlDQo+ID4+Pj4+IHNlcnZlcg0KPiA+Pj4+PiBo
YXMgdG8gcmVwb3J0IGl0Lg0KPiA+Pj4+PiANCj4gPj4+PiANCj4gPj4+PiBOb3cgSSBzZWUgeW91
ciBwb2ludCAtIHlvdSB3YW50IHRvIG5vdCByZXBvcnQgY3VyLWhvcC1saW1pdCBhcyBsb25nIGFz
DQo+ID4+Pj4gaXQgaXMgNjQgKHdoZW4geW91IGRvIG5vdCB1c2UgZXhwbGljaXQgZGVmYXVsdHMg
ZHVyaW5nIHRoZQ0KPiA+Pj4+IHJldHJpZXZhbCkuIEhtLiBNb3JlIGJlbG93Li4uIEkgZ3Vlc3Mg
bXkgcHJvYmxlbSByZWFsbHkgaXMgd2l0aCB0aGUNCj4gPj4+PiB0ZXh0IHNheWluZyBob3cgdG8g
Y2hvb3NlIGEgdmFsdWUgaWYgbm8gZXhwbGljaXQgY29uZmlnIGlzIHByb3ZpZGVkLg0KPiA+Pj4g
DQo+ID4+PiBJIHRoaW5rIGl0IGlzIHNvbWV3aGF0IHVuY2xlYXIgd2hhdCB0aGUgZm9sbG93aW5n
IHNlbnRlbmNlIGluIDYwMjANCj4gPj4+IG1lYW5zIGZvcg0KPiA+Pj4gZGVmYXVsdHMgaW4gY29u
ZmlndXJhdGlvbiBkYXRhOg0KPiA+Pj4gDQo+ID4+PiAgIFdoZW4gdGhlIGRlZmF1bHQgdmFsdWUg
aXMgaW4gdXNlLCB0aGUgc2VydmVyIE1VU1Qgb3BlcmF0aW9uYWxseQ0KPiA+Pj4gICBiZWhhdmUg
YXMgaWYgdGhlIGxlYWYgd2FzIHByZXNlbnQgaW4gdGhlIGRhdGEgdHJlZSB3aXRoIHRoZSBkZWZh
dWx0DQo+ID4+PiAgIHZhbHVlIGFzIGl0cyB2YWx1ZS4NCj4gPj4+IA0KPiA+Pj4gRm9yIGV4YW1w
bGUsIGFzc3VtZSB0aGUgZGF0YSBtb2RlbCBkZWZpbmVzIHRoZSBkZWZhdWx0IHZhbHVlIGZvcg0K
PiA+Pj4gJ2N1ci1ob3AtbGltaXQnIGluICpjb25maWcqIHRvIGJlIDY0LiBOb3csIElBTkEgY2hh
bmdlcyB0aGUgZGVmYXVsdA0KPiA+Pj4gVFRMLCBhbmQNCj4gPj4+IGRldmljZSBYIHVzZXMgdGhp
cyBuZXcgdmFsdWUgYXMgaXRzIG9wZXJhdGlvbmFsIGRlZmF1bHQgKGluZGVwZW5kZW50DQo+ID4+
PiBvZg0KPiA+Pj4gTkVUQ09ORikuIEl0IGNhbiBub3cgbWVhbiB0d28gdGhpbmdzOg0KPiA+Pj4g
DQo+ID4+PiAxLiBEZXZpY2UgWCBpcyBubyBtb3JlIGNvbXBsaWFudCB3aXRoIHRoZSBkYXRhIG1v
ZGVsLCBvcg0KPiA+Pj4gDQo+ID4+PiAyLiBXaGVuIHRoZSBORVRDT05GIHNlcnZlciBpcyBzdGFy
dGVkIG9uIGRldmljZSBYLCBpdCBoYXMgdG8gY2hhbmdlDQo+ID4+PiB0aGUNCj4gPj4+ICdjdXIt
aG9wLWxpbWl0JyB0byA2NCBvbiBpdHMgb3duIHNvIHRoYXQgdGhlIGNvbnRyYWN0IHdpdGggaXRz
IGNsaWVudHMNCj4gPj4+IGV4cHJlc3NlZCBieSB0aGUgZGF0YSBtb2RlbCBzdGlsbCBob2xkcy4N
Cj4gPj4gDQo+ID4+IEkgd291bGQgc2F5IDIuIEJ1dCBpbiB0aGlzIGNhc2UsIHRoZXJlIGlzIG5v
IHN0YXRpYyBkZWZhdWx0IC0gdGhlDQo+ID4+IGRlZmF1bHQgY2FuIGJlIGNoYW5nZWQgYnkgSUFO
QS4gSGVuY2UsIHRoZXJlIHNob3VsZCBub3QgYmUgYSBkZWZhdWx0DQo+ID4+IG9uIHRoZSBjb25m
aWcgbGVhZi4gVGhlcmUgY2FuIG9ubHkgYmUgdGV4dCBkZXNjcmliaW5nIGhvdyB0byBwaWNrIGEN
Cj4gPj4gdmFsdWUgaWYgdGhlIGxlYWYgaXMgbm90IHByb3ZpZGVkLg0KPiA+IA0KPiA+IEkgYWdy
ZWUuDQo+ID4gDQo+ID4gSSBub3RpY2VkIHRoYXQgaW4gLTE0LCB0aGlzIGxlYWYgaGFzIGEgZGVm
YXVsdCB2YWx1ZSBvZiA2NCwgYW5kIHRoZQ0KPiA+IHRleHQgdGhhdCBjb250cmFkaWN0cyB0aGUg
ZGVmYXVsdCBzdGF0ZW1lbnQuICBEaWQgSSBtaXNzIHNvbWV0aGluZyBpbg0KPiA+IHlvdXIgbWFp
bCBkaXNjdXNzaW9uPyAgU2hvdWxkbid0IHRoZSBkZWZhdWx0IHN0YXRlbWVudCBiZSByZW1vdmVk
Pw0KPiANCj4gSW4gaGlzIGl0ZW0gKGYpLCBKw7xyZ2VuIHdhcyBzcGVjaWZpY2FsbHkgY29tcGxh
aW5pbmcgYWJvdXQgdGhlIGRlZmF1bHQNCj4gZm9yIOKAmGN1ci1ob3AtbGltaXTigJkgaW4gc3Rh
dGUgZGF0YSwgYW5kIEkgcmVtb3ZlZCB0aGF0IG9uZS4gSSB0aGluayBpdA0KPiBpcyBhcHByb3By
aWF0ZSB0byBsZWF2ZSBpdCBpbiBjb25maWcgYmVjYXVzZSB0aGF0IHZhbHVlIGRvZXNu4oCZdCBz
ZWVtDQo+IHRvIGNoYW5nZSB2ZXJ5IG9mdGVuLiBJZiB0aGVyZSBpcyBubyBkZWZhdWx0IHZhbHVl
IGF0IGFsbCwgdGhlIGNsaWVudA0KPiBtYXkgaGF2ZSBubyB3YXkgdG8gZmluZCBvdXQgd2hhdCB2
YWx1ZSB0aGUgc2VydmVyIGFjdHVhbGx5IHVzZXMuDQo+IA0KPiBJIGFsc28gdGhvdWdodCB3ZSBh
Z3JlZWQgd2l0aCBKw7xyZ2VuIHRoYXQgZXZlbiBpZiBJQU5BIGNoYW5nZXMgdGhlDQo+IGRlZmF1
bHQgVFRMIHRoZXJlIGlzIG5vIGltbWVkaWF0ZSBuZWVkIHRvIHVwZGF0ZSB0aGUNCj4gaWV0Zi1p
cHY2LXVuaWNhc3Qtcm91dGluZyBtb2R1bGUgLSBpdCBpcyB1cCB0byB0aGUgTkVUQ09ORiBzZXJ2
ZXIgdG8NCj4ga2VlcCB0aGUgY29udHJhY3QgYW5kIHNldCB0aGUgb3BlcmF0aW9uYWwgdmFsdWUg
dG8gNjQuDQoNCkJ1dCB0aGVuIHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGUgZGVzY3JpcHRpb24g
c2hvdWxkIGJlIHJlbW92ZWQ6DQoNCiAgICAgIElmIHRoaXMgcGFyYW1ldGVyIGlzIG5vdCBjb25m
aWd1cmVkLCB0aGUgZGV2aWNlIFNIT1VMRCB1c2UNCiAgICAgIHRoZSB2YWx1ZSBzcGVjaWZpZWQg
aW4gSUFOQSBBc3NpZ25lZCBOdW1iZXJzIHRoYXQgd2FzIGluDQogICAgICBlZmZlY3QgYXQgdGhl
IHRpbWUgb2YgaW1wbGVtZW50YXRpb24uDQoNCnNpbmNlIHRoaXMgcGFyYWdyYXBoIGNvbnRyYWRp
Y3RzIHRoZSBmYWN0IHRoYXQgeW91IGhhdmUgYSBkZWZhdWx0DQpzdGF0ZW1lbnQuDQoNCihJIHdv
dWxkIGtlZXAgdGhlIHRleHQgYW5kIHJlbW92ZSB0aGUgZGVmYXVsdCB0aG91Z2guKQ0KDQoNCj4g
PiBUaGlzIGxlYWYncyBkZXNjcmlwdGlvbiBzYXlzOg0KPiA+IA0KPiA+ICBUaGUgZGVmYXVsdCB2
YWx1ZSB0byBiZSBwbGFjZWQgaW4gdGhlIEN1ciBIb3AgTGltaXQgZmllbGQNCj4gPiAgICAgIF5e
Xl5eXl5eXl5eXl4NCj4gPiANCj4gPiBBbGwgb3RoZXIgc2ltaWxhciBsZWFmIGhhcyB0aGlzOg0K
PiA+IA0KPiA+ICBUaGUgdmFsdWUgdG8gYmUgcGxhY2VkIGluIHRoZSBYWFggZmllbGQNCj4gPiAN
Cj4gPiBTaG91bGQgcy9kZWZhdWx0IHZhbHVlL3ZhbHVlPyAgSWYgbm90LCB3aGF0IGRvZXMgdGhp
cyBtZWFuPw0KPiANCj4gSSBqdXN0IHVzZWQgdGhlIHRleHQgZnJvbSBSRkMgNDg2MS4gSSBndWVz
cyBpdCBtZWFucyBpdCBpcyB0aGUNCj4g4oCcZGVmYXVsdCBUVEwgdmFsdWXigJ0gLSB0aGUgaG9z
dCB0aGF0IHJlY2VpdmVzIHRoZSBSQSBtYXkgdXNlIGFub3RoZXINCj4gdmFsdWUuIEkgZG8gYWdy
ZWUgdGhvdWdoIHRoYXQgcy9kZWZhdWx0IHZhbHVlL3ZhbHVlLyBtYWtlcyBzZW5zZSBoZXJlLg0K
PiANCj4gPiANCj4gPiANCj4gPiBNaW5vciBuaXQ6IHRoaXMgbGVhZidzIHJlZmVyZW5jZSB0ZXh0
IGhhcyBoeXBlbnMgYmVmb3JlIHRoZSBSRkNzOyB0aGF0DQo+ID4gc3RpY2tzIG91dCBhcyBjb21w
YXJlZCB0byB0aGUgb3RoZXIgbGVhZnMsIGFuZCBjb21wYXJlZCB0byBlLmcuIHRoZQ0KPiA+IHN5
c3RlbSBkcmFmdC4NCj4gDQo+IFRoZXJlIGFyZSBhY3R1YWxseSB0d28gcmVmZXJlbmNlcyBpbiB0
aGF0IOKAmHJlZmVyZW5jZeKAmSBzdGF0ZW1lbnQsIHNvIEkNCj4gbWFkZSB0aGVtIGludG8gYW4g
aXRlbWl6ZWQgbGlzdC4gT3RoZXIgbGVhZnMgaGF2ZSBvbmx5IG9uZSByZWZlcmVuY2UuDQoNClRo
ZSBvdGhlciBkb2N1bWVudHMgd2UgaGF2ZSBmb2xsb3cgdGhlIGNvbnZlbnRpb24gaW50cm9kdWNl
ZCBieSBSRkMNCjYwMjE6DQoNCiAgICAgIHJlZmVyZW5jZQ0KICAgICAgICAiUkZDIDMzMzk6IERh
dGUgYW5kIFRpbWUgb24gdGhlIEludGVybmV0OiBUaW1lc3RhbXBzDQogICAgICAgICBSRkMgMjU3
OTogVGV4dHVhbCBDb252ZW50aW9ucyBmb3IgU01JdjINCiAgICAgICAgIFhTRC1UWVBFUzogWE1M
IFNjaGVtYSBQYXJ0IDI6IERhdGF0eXBlcyBTZWNvbmQgRWRpdGlvbiI7DQoNCg0KDQovbWFydGlu
DQo=


From nobody Thu May 22 23:56:45 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BF41A03AE for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 23:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7fGa4k6mGja for <netmod@ietfa.amsl.com>; Thu, 22 May 2014 23:56:42 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDFF1A004D for <netmod@ietf.org>; Thu, 22 May 2014 23:56:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 67572FE4; Fri, 23 May 2014 08:56:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kv0dXPkdS4i0; Fri, 23 May 2014 08:56:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 May 2014 08:56:38 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 039A620017; Fri, 23 May 2014 08:56:39 +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 eyx2IbPgzQLa; Fri, 23 May 2014 08:56:38 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFEA520013; Fri, 23 May 2014 08:56:37 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id AACA62CF3549; Fri, 23 May 2014 08:56:36 +0200 (CEST)
Date: Fri, 23 May 2014 08:56:36 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20140523065636.GA93613@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, lhotka@nic.cz, netmod@ietf.org
References: <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com> <3B0274C7-472D-480C-990B-378BBE7F7884@nic.cz> <20140523.081339.665022241963872091.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20140523.081339.665022241963872091.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Vtt5hxKV_bBQyJRH83xaYrFMF58
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 06:56:44 -0000

On Fri, May 23, 2014 at 08:13:39AM +0200, Martin Bjorklund wrote:
> > 
> > I also thought we agreed with Jürgen that even if IANA changes the
> > default TTL there is no immediate need to update the
> > ietf-ipv6-unicast-routing module - it is up to the NETCONF server to
> > keep the contract and set the operational value to 64.
> 
> But then the last paragraph of the description should be removed:
> 
>       If this parameter is not configured, the device SHOULD use
>       the value specified in IANA Assigned Numbers that was in
>       effect at the time of implementation.
> 
> since this paragraph contradicts the fact that you have a default
> statement.
> 
> (I would keep the text and remove the default though.)

Just to avoid confusion, we are talking about the config leaf
cur-hop-limit in -14, right? I agree that having the default statement
together with the text quoted above is broken. And like Martin, I
would prefer to remove the default (because otherwise we kind of kill
the IANA control of this value).

/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 nobody Fri May 23 01:31:16 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564A31A03C8 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 01:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ5VAT5si77y for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 01:31:11 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCE71A03C5 for <netmod@ietf.org>; Fri, 23 May 2014 01:31:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7464510C5 for <netmod@ietf.org>; Fri, 23 May 2014 10:31:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id x0gYBAaZHyqm for <netmod@ietf.org>; Fri, 23 May 2014 10:31:02 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Fri, 23 May 2014 10:31:08 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C52120017 for <netmod@ietf.org>; Fri, 23 May 2014 10:31:08 +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 3j3_2GB-nacc; Fri, 23 May 2014 10:31:07 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF43A20013; Fri, 23 May 2014 10:31:06 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 44E702CF3813; Fri, 23 May 2014 10:31:06 +0200 (CEST)
Date: Fri, 23 May 2014 10:31:05 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9lWs6PrpI5a0_n7Cu9se8NoEXYg
Subject: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 08:31:13 -0000

Lada,

I have reviewed the changes. A few more nits (sorry) before I am
fully happy.

- On page 21, you have changed the first path but also removed hte
  "as state data" phrase. I also note that it is 'routes' not 'route'.
  Perhaps this should also provide a more complete overview. Looking
  at the v4ur and v6ur models, perhaps it makes sense to list this:

  OLD

          /rt:routing-state/rt:ribs/rt:rib/rt:route

      and

          /rt:active-route/rt:output/rt:route,

  NEW

	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
	  /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
       and
	  /rt:active-route/rt:output

- Concerning cur-hop-limit, isn't the right approach to leave the default
  statement in the state tree and to remove the default from the config
  tree? (See the other thread.)

If you agree with these changes, please post another update and I will
finally hand it over to Benoit.

/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 nobody Fri May 23 01:33:42 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782E61A0123 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 01:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hstjyRLZFvO4 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 01:33:35 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67181A0108 for <netmod@ietf.org>; Fri, 23 May 2014 01:33:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4F5E15405E1; Fri, 23 May 2014 10:33:32 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuWCM-Wt4+eO; Fri, 23 May 2014 10:33:27 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B2F8A540024; Fri, 23 May 2014 10:33:26 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20140523065636.GA93613@elstar.jacobs.jacobs-university.de>
References: <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com> <3B0274C7-472D-480C-990B-378BBE7F7884@nic.cz> <20140523.081339.665022241963872091.mbj@tail-f.com> <20140523065636.GA93613@elstar.jacobs.jacobs-university.de>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 23 May 2014 10:33:26 +0200
Message-ID: <m2egzk3ne1.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6epniIrEEN-PJSlSn5rAMnSvtSQ
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 08:33:40 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Fri, May 23, 2014 at 08:13:39AM +0200, Martin Bjorklund wrote:
>> >=20
>> > I also thought we agreed with J=C3=BCrgen that even if IANA changes the
>> > default TTL there is no immediate need to update the
>> > ietf-ipv6-unicast-routing module - it is up to the NETCONF server to
>> > keep the contract and set the operational value to 64.
>>=20
>> But then the last paragraph of the description should be removed:
>>=20
>>       If this parameter is not configured, the device SHOULD use
>>       the value specified in IANA Assigned Numbers that was in
>>       effect at the time of implementation.
>>=20
>> since this paragraph contradicts the fact that you have a default
>> statement.
>>=20
>> (I would keep the text and remove the default though.)
>
> Just to avoid confusion, we are talking about the config leaf
> cur-hop-limit in -14, right? I agree that having the default statement

I must admit I mixed up the two different cases in my head, I thought we we=
re talking about a leaf like 'default-lifetime' that really has no static d=
efault. Sorry for the confusion.

Now back to 'cur-hop-limit': its default value is IMO in the same position =
as those we already have in other similar cases. For example, ietf-ip has t=
he leaf 'temporary-valid-lifetime' with a default value of 1 week. If this =
value is updated in a future revision of RFC 4941, then we are in the same =
situation. So my preference is to keep the default - apparently, the recomm=
ended default TTL hasn't changed since 1994 (RFC 1700).

> together with the text quoted above is broken. And like Martin, I
> would prefer to remove the default (because otherwise we kind of kill
> the IANA control of this value).

I agree the text should be better removed.

Lada

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

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri May 23 01:50:05 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B01A0144 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 01:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWLGFvD36wit for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 01:50:00 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4438B1A0141 for <netmod@ietf.org>; Fri, 23 May 2014 01:50:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 698F95405E1; Fri, 23 May 2014 10:49:57 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGYvVNt9FhGh; Fri, 23 May 2014 10:49:53 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 60F61540171; Fri, 23 May 2014 10:49:53 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20140523.081339.665022241963872091.mbj@tail-f.com>
References: <20140522090708.GB90713@elstar.local> <20140522.212327.40777774.mbj@tail-f.com> <3B0274C7-472D-480C-990B-378BBE7F7884@nic.cz> <20140523.081339.665022241963872091.mbj@tail-f.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 23 May 2014 10:49:52 +0200
Message-ID: <m2bnuo3mmn.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QBRtAnpnONwsu4SA5bJMB11Rmjw
Cc: netmod@ietf.org
Subject: Re: [netmod] wg chair review of draft-ietf-netmod-routing-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 08:50:01 -0000

Martin Bjorklund <mbj@tail-f.com> writes:

...

>> >=20
>> > Minor nit: this leaf's reference text has hypens before the RFCs; that
>> > sticks out as compared to the other leafs, and compared to e.g. the
>> > system draft.
>>=20
>> There are actually two references in that =E2=80=98reference=E2=80=99 st=
atement, so I
>> made them into an itemized list. Other leafs have only one reference.
>
> The other documents we have follow the convention introduced by RFC
> 6021:
>
>       reference
>         "RFC 3339: Date and Time on the Internet: Timestamps
>          RFC 2579: Textual Conventions for SMIv2
>          XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";

I personally don't like this formatting, I think at the very least each ite=
m should be terminated with a full stop, and perhaps an empty line as well.=
 With references that span more lines it gets really messy. On the other ha=
nd, it is IMO not that important to be absolutely consistent in these free-=
form texts. If we want tools to be able to parse them easily, we should rea=
lly use some kind of markup.=20

Lada

>
>
>
> /martin

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri May 23 02:12:51 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49C21A014F for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 02:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level: 
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmsNiuYtTsuM for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 02:12:48 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9821A0143 for <netmod@ietf.org>; Fri, 23 May 2014 02:12:48 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 438DA13F976; Fri, 23 May 2014 11:12:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400836365; bh=muBEQ2UfdQAWoiqj7uAgEMhNzvd1oAG/JPee/0uQuE8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ksQKUSWC6C8CIGlgx2Onouj37518inVq9VHDu1rPApGZp1tzWMsuIyTYUfRXdq4gi om7c1fWIjVozNgn5aKhJwE2X9IZtqRa7oudWC/a+iPbrbUd7bPjidMRKoq8pqAqH/H SoqpluxksT7VFlFxFFLH1sT/edBQc8gJ4IgkrMI4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de>
Date: Fri, 23 May 2014 11:12:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dNpJX6yrx4cTwhAc-Zp-XASnIao
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 09:12:49 -0000

On 23 May 2014, at 10:31, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> Lada,
>=20
> I have reviewed the changes. A few more nits (sorry) before I am
> fully happy.
>=20
> - On page 21, you have changed the first path but also removed hte
>  "as state data" phrase. I also note that it is 'routes' not 'route=92.

Yes, you are right.

>  Perhaps this should also provide a more complete overview. Looking
>  at the v4ur and v6ur models, perhaps it makes sense to list this:
>=20
>  OLD
>=20
>          /rt:routing-state/rt:ribs/rt:rib/rt:route
>=20
>      and
>=20
>          /rt:active-route/rt:output/rt:route,
>=20
>  NEW
>=20
> 	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> 	  =
/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol

The =91routing-protocol=92 container and its contents have to be defined =
from scratch (see the third bullet) and its configuration in fact =
needn=92t contain any explicit routes. So I think this line shouldn't be =
there.


>       and
> 	  /rt:active-route/rt:output
>=20
> - Concerning cur-hop-limit, isn't the right approach to leave the =
default
>  statement in the state tree and to remove the default from the config
>  tree? (See the other thread.)

Hmm, I am not sure what to do with this. The other modules only have the =
defaults in config. Can other people comment?

>=20
> If you agree with these changes, please post another update and I will
> finally hand it over to Benoit.

I will, but let=92s resolve the defaults issue first.

Thanks, Lada

>=20
> /js
>=20
> --=20
> 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/>
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 03:10:03 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD32F1A03E3 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 03:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level: 
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZLGCjzQtf6l for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 03:10:00 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592911A03E2 for <netmod@ietf.org>; Fri, 23 May 2014 03:10:00 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A36A5742; Fri, 23 May 2014 12:09:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NABFzUi5kfFl; Fri, 23 May 2014 12:09:51 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 May 2014 12:09:56 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1699220013; Fri, 23 May 2014 12:09:57 +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 k82pzJaz98Ha; Fri, 23 May 2014 12:09:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5089120017; Fri, 23 May 2014 12:09:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 02A1E2CF3F8A; Fri, 23 May 2014 12:09:52 +0200 (CEST)
Date: Fri, 23 May 2014 12:09:52 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140523100950.GB198@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BJXnLowZtmZQnQFgtBGPyGsGirk
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 10:10:02 -0000

On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
> 
> On 23 May 2014, at 10:31, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> > Lada,
> > 
> > I have reviewed the changes. A few more nits (sorry) before I am
> > fully happy.
> > 
> > - On page 21, you have changed the first path but also removed hte
> >  "as state data" phrase. I also note that it is 'routes' not 'route’.
> 
> Yes, you are right.
> 
> >  Perhaps this should also provide a more complete overview. Looking
> >  at the v4ur and v6ur models, perhaps it makes sense to list this:
> > 
> >  OLD
> > 
> >          /rt:routing-state/rt:ribs/rt:rib/rt:route
> > 
> >      and
> > 
> >          /rt:active-route/rt:output/rt:route,
> > 
> >  NEW
> > 
> > 	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> > 	  /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
> 
> The ‘routing-protocol’ container and its contents have to be defined from scratch (see the third bullet) and its configuration in fact needn’t contain any explicit routes. So I think this line shouldn't be there.
> 

OK. Then just fix the first path.
 
> >       and
> > 	  /rt:active-route/rt:output
> > 
> > - Concerning cur-hop-limit, isn't the right approach to leave the default
> >  statement in the state tree and to remove the default from the config
> >  tree? (See the other thread.)
> 
> Hmm, I am not sure what to do with this. The other modules only have the defaults in config. Can other people comment?
> 

My understanding is that defaults on config false objects only provide
an optimization for implementations that support 'trim' defaults
handling. The question is whether it is worth it. [Once I trouble
shoot something, I usually prefer to see all values being used,
filtering them out as needed for the task at hand, that is I would use
'report-all' anyway if available. But that is just me.]

That said, I like to take a pragmatic decision. I see two options:

- Add default 64 to cur-hop-limit to be consistent with the other
  state objects that have a default.

- Remove all defaults from all state objects because the real value
  of defaults is for config true objects.

Both work for me. We should decide this quickly. Lada? Martin?
Andy? Anyone else?

/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 nobody Fri May 23 04:21:37 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD531A0171 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 04:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level: 
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyrr5GIeCTpc for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 04:21:35 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FEF1A0170 for <netmod@ietf.org>; Fri, 23 May 2014 04:21:33 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E00B71400FE; Fri, 23 May 2014 13:21:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400844091; bh=0gS18qK7vd9/BUBTyBoTIJtC7dO2utl8JS49y7mKVcM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=k7VOqUTNXOBusIGVCygbu9zLNjDylDjKiTVjIcwk/EIAi+Ck4Dch8kw3YB7c1pSCw uowwSWW6t8CCgSa4R1MULkzzCkIwyGL4q6jFpAv8U40K8+xRpvBdf1UAOlKmcTjNfM DlCJO3lAZc5/eLG21AX64oq8foTlhqyEVd/drLgk=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140523100950.GB198@elstar.local>
Date: Fri, 23 May 2014 13:21:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AAE379F1-AFC0-4576-B9E4-553674A9441F@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o2KNC2YO2ypsqZ3n9dEV_8I7Ehs
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 11:21:36 -0000

On 23 May 2014, at 12:09, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
>>=20
>> On 23 May 2014, at 10:31, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
>>=20
>>> Lada,
>>>=20
>>> I have reviewed the changes. A few more nits (sorry) before I am
>>> fully happy.
>>>=20
>>> - On page 21, you have changed the first path but also removed hte
>>> "as state data" phrase. I also note that it is 'routes' not 'route=92.=

>>=20
>> Yes, you are right.
>>=20
>>> Perhaps this should also provide a more complete overview. Looking
>>> at the v4ur and v6ur models, perhaps it makes sense to list this:
>>>=20
>>> OLD
>>>=20
>>>         /rt:routing-state/rt:ribs/rt:rib/rt:route
>>>=20
>>>     and
>>>=20
>>>         /rt:active-route/rt:output/rt:route,
>>>=20
>>> NEW
>>>=20
>>> 	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
>>> 	  =
/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
>>=20
>> The =91routing-protocol=92 container and its contents have to be =
defined from scratch (see the third bullet) and its configuration in =
fact needn=92t contain any explicit routes. So I think this line =
shouldn't be there.
>>=20
>=20
> OK. Then just fix the first path.

Yes, done.

>=20
>>>      and
>>> 	  /rt:active-route/rt:output
>>>=20
>>> - Concerning cur-hop-limit, isn't the right approach to leave the =
default
>>> statement in the state tree and to remove the default from the =
config
>>> tree? (See the other thread.)
>>=20
>> Hmm, I am not sure what to do with this. The other modules only have =
the defaults in config. Can other people comment?
>>=20
>=20
> My understanding is that defaults on config false objects only provide
> an optimization for implementations that support 'trim' defaults
> handling. The question is whether it is worth it. [Once I trouble
> shoot something, I usually prefer to see all values being used,
> filtering them out as needed for the task at hand, that is I would use
> 'report-all' anyway if available. But that is just me.]

[Another side-note: As you may remember, during the design session at =
IETF 70 I voted against having defaults in YANG. And I still think =
client software is a better place for dealing with them.]

>=20
> That said, I like to take a pragmatic decision. I see two options:
>=20
> - Add default 64 to cur-hop-limit to be consistent with the other
>  state objects that have a default.
>=20
> - Remove all defaults from all state objects because the real value
>  of defaults is for config true objects.

If we do this and keep the leafs optional, the client has no way to =
force the server to report the value it is actually using. So I prefer =
the former option.

Lada

>=20
> Both work for me. We should decide this quickly. Lada? Martin?
> Andy? Anyone else?
>=20
> /js
>=20
> --=20
> 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/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 04:36:20 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30AE1A0166 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 04:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-vry1rXwKc5 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 04:36:17 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE0E1A015E for <netmod@ietf.org>; Fri, 23 May 2014 04:36:16 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 240EEF63; Fri, 23 May 2014 13:36:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IzT8Q4QYy9PJ; Fri, 23 May 2014 13:36:07 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 May 2014 13:36:13 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBD6820017; Fri, 23 May 2014 13:36:13 +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 GruJgJmDgfg6; Fri, 23 May 2014 13:36:13 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D005920013; Fri, 23 May 2014 13:36:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2D1362CF4210; Fri, 23 May 2014 13:36:12 +0200 (CEST)
Date: Fri, 23 May 2014 13:36:12 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140523113611.GA737@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, netmod@ietf.org
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <AAE379F1-AFC0-4576-B9E4-553674A9441F@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AAE379F1-AFC0-4576-B9E4-553674A9441F@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/apw3k0Q0H693yAc5wUeagmKzTrE
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 11:36:19 -0000

On Fri, May 23, 2014 at 01:21:30PM +0200, Ladislav Lhotka wrote:
> 
> 
> If we do this and keep the leafs optional, the client has no way to force the server to report the value it is actually using. So I prefer the former option.
> 

If I do not implement a leaf, I do not implement it. It does not
matter whether there is a default defined for the leaf or not. Yes,
using trim mode, the difference may be subtle and unclear.

Perhaps revised conformance coming out of YANG 1.1 will allow us to
specify what needs to be implemented or not. But lets not go there
here.

/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 nobody Fri May 23 04:56:38 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABBB1A0166 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 04:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uj5Hlku7LXn for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 04:56:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACAE1A0188 for <netmod@ietf.org>; Fri, 23 May 2014 04:56:30 -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 412CC3941D1; Fri, 23 May 2014 13:56:27 +0200 (CEST)
Date: Fri, 23 May 2014 13:56:27 +0200 (CEST)
Message-Id: <20140523.135627.1822345686578986376.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20140523100950.GB198@elstar.local>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/B1Ys1DI0oINEFnAbfyVMDhdqgGA
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 11:56:34 -0000

SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku
ZGU+IHdyb3RlOg0KPiBPbiBGcmksIE1heSAyMywgMjAxNCBhdCAxMToxMjo0M0FNICswMjAwLCBM
YWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gDQo+ID4gT24gMjMgTWF5IDIwMTQsIGF0IDEwOjMx
LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZT4gd3JvdGU6DQo+ID4gDQo+ID4gPiBMYWRhLA0KPiA+ID4gDQo+ID4gPiBJIGhhdmUgcmV2
aWV3ZWQgdGhlIGNoYW5nZXMuIEEgZmV3IG1vcmUgbml0cyAoc29ycnkpIGJlZm9yZSBJIGFtDQo+
ID4gPiBmdWxseSBoYXBweS4NCj4gPiA+IA0KPiA+ID4gLSBPbiBwYWdlIDIxLCB5b3UgaGF2ZSBj
aGFuZ2VkIHRoZSBmaXJzdCBwYXRoIGJ1dCBhbHNvIHJlbW92ZWQgaHRlDQo+ID4gPiAgImFzIHN0
YXRlIGRhdGEiIHBocmFzZS4gSSBhbHNvIG5vdGUgdGhhdCBpdCBpcyAncm91dGVzJyBub3QgJ3Jv
dXRl4oCZLg0KPiA+IA0KPiA+IFllcywgeW91IGFyZSByaWdodC4NCj4gPiANCj4gPiA+ICBQZXJo
YXBzIHRoaXMgc2hvdWxkIGFsc28gcHJvdmlkZSBhIG1vcmUgY29tcGxldGUgb3ZlcnZpZXcuIExv
b2tpbmcNCj4gPiA+ICBhdCB0aGUgdjR1ciBhbmQgdjZ1ciBtb2RlbHMsIHBlcmhhcHMgaXQgbWFr
ZXMgc2Vuc2UgdG8gbGlzdCB0aGlzOg0KPiA+ID4gDQo+ID4gPiAgT0xEDQo+ID4gPiANCj4gPiA+
ICAgICAgICAgIC9ydDpyb3V0aW5nLXN0YXRlL3J0OnJpYnMvcnQ6cmliL3J0OnJvdXRlDQo+ID4g
PiANCj4gPiA+ICAgICAgYW5kDQo+ID4gPiANCj4gPiA+ICAgICAgICAgIC9ydDphY3RpdmUtcm91
dGUvcnQ6b3V0cHV0L3J0OnJvdXRlLA0KPiA+ID4gDQo+ID4gPiAgTkVXDQo+ID4gPiANCj4gPiA+
IAkgIC9ydDpyb3V0aW5nLXN0YXRlL3J0OnJpYnMvcnQ6cmliL3J0OnJvdXRlcy9ydDpyb3V0ZQ0K
PiA+ID4gCSAgL3J0OnJvdXRpbmcvcnQ6cm91dGluZy1pbnN0YW5jZS9ydDpyb3V0aW5nLXByb3Rv
Y29scy9ydDpyb3V0aW5nLXByb3RvY29sDQo+ID4gDQo+ID4gVGhlIOKAmHJvdXRpbmctcHJvdG9j
b2zigJkgY29udGFpbmVyIGFuZCBpdHMgY29udGVudHMgaGF2ZSB0byBiZSBkZWZpbmVkIGZyb20g
c2NyYXRjaCAoc2VlIHRoZSB0aGlyZCBidWxsZXQpIGFuZCBpdHMgY29uZmlndXJhdGlvbiBpbiBm
YWN0IG5lZWRu4oCZdCBjb250YWluIGFueSBleHBsaWNpdCByb3V0ZXMuIFNvIEkgdGhpbmsgdGhp
cyBsaW5lIHNob3VsZG4ndCBiZSB0aGVyZS4NCj4gPiANCj4gDQo+IE9LLiBUaGVuIGp1c3QgZml4
IHRoZSBmaXJzdCBwYXRoLg0KPiAgDQo+ID4gPiAgICAgICBhbmQNCj4gPiA+IAkgIC9ydDphY3Rp
dmUtcm91dGUvcnQ6b3V0cHV0DQo+ID4gPiANCj4gPiA+IC0gQ29uY2VybmluZyBjdXItaG9wLWxp
bWl0LCBpc24ndCB0aGUgcmlnaHQgYXBwcm9hY2ggdG8gbGVhdmUgdGhlIGRlZmF1bHQNCj4gPiA+
ICBzdGF0ZW1lbnQgaW4gdGhlIHN0YXRlIHRyZWUgYW5kIHRvIHJlbW92ZSB0aGUgZGVmYXVsdCBm
cm9tIHRoZSBjb25maWcNCj4gPiA+ICB0cmVlPyAoU2VlIHRoZSBvdGhlciB0aHJlYWQuKQ0KPiA+
IA0KPiA+IEhtbSwgSSBhbSBub3Qgc3VyZSB3aGF0IHRvIGRvIHdpdGggdGhpcy4gVGhlIG90aGVy
IG1vZHVsZXMgb25seSBoYXZlIHRoZSBkZWZhdWx0cyBpbiBjb25maWcuIENhbiBvdGhlciBwZW9w
bGUgY29tbWVudD8NCj4gPiANCj4gDQo+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBkZWZhdWx0
cyBvbiBjb25maWcgZmFsc2Ugb2JqZWN0cyBvbmx5IHByb3ZpZGUNCj4gYW4gb3B0aW1pemF0aW9u
IGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0ICd0cmltJyBkZWZhdWx0cw0KPiBoYW5k
bGluZy4gVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgaXQgaXMgd29ydGggaXQuIFtPbmNlIEkgdHJv
dWJsZQ0KPiBzaG9vdCBzb21ldGhpbmcsIEkgdXN1YWxseSBwcmVmZXIgdG8gc2VlIGFsbCB2YWx1
ZXMgYmVpbmcgdXNlZCwNCj4gZmlsdGVyaW5nIHRoZW0gb3V0IGFzIG5lZWRlZCBmb3IgdGhlIHRh
c2sgYXQgaGFuZCwgdGhhdCBpcyBJIHdvdWxkIHVzZQ0KPiAncmVwb3J0LWFsbCcgYW55d2F5IGlm
IGF2YWlsYWJsZS4gQnV0IHRoYXQgaXMganVzdCBtZS5dDQo+IA0KPiBUaGF0IHNhaWQsIEkgbGlr
ZSB0byB0YWtlIGEgcHJhZ21hdGljIGRlY2lzaW9uLiBJIHNlZSB0d28gb3B0aW9uczoNCj4gDQo+
IC0gQWRkIGRlZmF1bHQgNjQgdG8gY3VyLWhvcC1saW1pdCB0byBiZSBjb25zaXN0ZW50IHdpdGgg
dGhlIG90aGVyDQo+ICAgc3RhdGUgb2JqZWN0cyB0aGF0IGhhdmUgYSBkZWZhdWx0Lg0KPiANCj4g
LSBSZW1vdmUgYWxsIGRlZmF1bHRzIGZyb20gYWxsIHN0YXRlIG9iamVjdHMgYmVjYXVzZSB0aGUg
cmVhbCB2YWx1ZQ0KPiAgIG9mIGRlZmF1bHRzIGlzIGZvciBjb25maWcgdHJ1ZSBvYmplY3RzLg0K
PiANCj4gQm90aCB3b3JrIGZvciBtZS4gV2Ugc2hvdWxkIGRlY2lkZSB0aGlzIHF1aWNrbHkuIExh
ZGE/IE1hcnRpbj8NCj4gQW5keT8gQW55b25lIGVsc2U/DQoNCldlbGwsIGFzIEkgc3RhdGVkIGJl
Zm9yZSwgSSB0aGluayB0aGF0IHRoZSBkZWZhdWx0IHN0YXRlbWVudCBzaG91bGQgYmUNCnJlbW92
ZWQgZnJvbSB0aGUgY29uZmlnIGxlYWYuICBUaHVzLCBpdCBkb2Vzbid0IG1ha2UgYW55IHNlbnNl
IHRvIGhhdmUNCmEgZGVmYXVsdCBpbiB0aGUgb3BlciBzdGF0ZSBmb3IgdGhpcyBsZWFmLg0KDQoN
Cg0KL21hcnRpbg0K


From nobody Fri May 23 05:06:13 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562A91A04B7 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 05:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level: 
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmF6D8q-atmP for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 05:06:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360491A0484 for <netmod@ietf.org>; Fri, 23 May 2014 05:05:47 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D3BC31400FE; Fri, 23 May 2014 14:05:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400846744; bh=DcfkszFHWIB6n0LmLdllaMjAc7Ib8tS9RMljD/5A0yQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tNVzoewbeHcbtEquNitZxdvBEyKhWLVvPY6RZdECS+Vw61V0x+R3zTVLhifwGgnPc fL4ABK+pc6UuApRoEW4XP7I2x6N+hYAVroHVaTbpuDAzvgBwiYNDHbtT+3kHREVCJu oqKyUK1ZMYcWcu0KAvQ5O1ySr9djv9Wd6xLQsEcI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140523.135627.1822345686578986376.mbj@tail-f.com>
Date: Fri, 23 May 2014 14:05:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4BDE829-A7D8-4A1B-956D-193E91907D16@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <20140523.135627.1822345686578986376.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/z9AVpN3OXR7f9XzqN6Mihss803Y
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 12:06:11 -0000

On 23 May 2014, at 13:56, Martin Bjorklund <mbj@tail-f.com> wrote:

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>> On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
>>>=20
>>> On 23 May 2014, at 10:31, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
>>>=20
>>>> Lada,
>>>>=20
>>>> I have reviewed the changes. A few more nits (sorry) before I am
>>>> fully happy.
>>>>=20
>>>> - On page 21, you have changed the first path but also removed hte
>>>> "as state data" phrase. I also note that it is 'routes' not =
'route=92.
>>>=20
>>> Yes, you are right.
>>>=20
>>>> Perhaps this should also provide a more complete overview. Looking
>>>> at the v4ur and v6ur models, perhaps it makes sense to list this:
>>>>=20
>>>> OLD
>>>>=20
>>>>         /rt:routing-state/rt:ribs/rt:rib/rt:route
>>>>=20
>>>>     and
>>>>=20
>>>>         /rt:active-route/rt:output/rt:route,
>>>>=20
>>>> NEW
>>>>=20
>>>> 	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
>>>> 	  =
/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
>>>=20
>>> The =91routing-protocol=92 container and its contents have to be =
defined from scratch (see the third bullet) and its configuration in =
fact needn=92t contain any explicit routes. So I think this line =
shouldn't be there.
>>>=20
>>=20
>> OK. Then just fix the first path.
>>=20
>>>>      and
>>>> 	  /rt:active-route/rt:output
>>>>=20
>>>> - Concerning cur-hop-limit, isn't the right approach to leave the =
default
>>>> statement in the state tree and to remove the default from the =
config
>>>> tree? (See the other thread.)
>>>=20
>>> Hmm, I am not sure what to do with this. The other modules only have =
the defaults in config. Can other people comment?
>>>=20
>>=20
>> My understanding is that defaults on config false objects only =
provide
>> an optimization for implementations that support 'trim' defaults
>> handling. The question is whether it is worth it. [Once I trouble
>> shoot something, I usually prefer to see all values being used,
>> filtering them out as needed for the task at hand, that is I would =
use
>> 'report-all' anyway if available. But that is just me.]
>>=20
>> That said, I like to take a pragmatic decision. I see two options:
>>=20
>> - Add default 64 to cur-hop-limit to be consistent with the other
>>  state objects that have a default.
>>=20
>> - Remove all defaults from all state objects because the real value
>>  of defaults is for config true objects.
>>=20
>> Both work for me. We should decide this quickly. Lada? Martin?
>> Andy? Anyone else?
>=20
> Well, as I stated before, I think that the default statement should be
> removed from the config leaf.  Thus, it doesn't make any sense to have

Reasons? How is it different from, e.g., default-valid-lifetime in =
ietf-ip?

> a default in the oper state for this leaf.

Why not? As Juergen wrote, it is useful for the =91trim=92 mode, and it =
doesn=92t matter whether the default is defined for the config leaf or =
not.

Lada

>=20
>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 05:15:37 2014
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B731A047B for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 05:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level: 
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLGKrcWW6SgG for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 05:15:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 16AF01A046D for <netmod@ietf.org>; Fri, 23 May 2014 05:15:34 -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 138203941D1; Fri, 23 May 2014 14:15:32 +0200 (CEST)
Date: Fri, 23 May 2014 14:15:31 +0200 (CEST)
Message-Id: <20140523.141531.1719212826923970987.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <C4BDE829-A7D8-4A1B-956D-193E91907D16@nic.cz>
References: <20140523100950.GB198@elstar.local> <20140523.135627.1822345686578986376.mbj@tail-f.com> <C4BDE829-A7D8-4A1B-956D-193E91907D16@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PIesV268sNtmq8zqhX2sBPIQ0dQ
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 12:15:35 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDIzIE1heSAy
MDE0LCBhdCAxMzo1NiwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K
PiANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p
dmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+IE9uIEZyaSwgTWF5IDIzLCAyMDE0IGF0IDExOjEyOjQz
QU0gKzAyMDAsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gT24gMjMgTWF5
IDIwMTQsIGF0IDEwOjMxLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBq
YWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+PiANCj4gPj4+PiBMYWRhLA0KPiA+Pj4+
IA0KPiA+Pj4+IEkgaGF2ZSByZXZpZXdlZCB0aGUgY2hhbmdlcy4gQSBmZXcgbW9yZSBuaXRzIChz
b3JyeSkgYmVmb3JlIEkgYW0NCj4gPj4+PiBmdWxseSBoYXBweS4NCj4gPj4+PiANCj4gPj4+PiAt
IE9uIHBhZ2UgMjEsIHlvdSBoYXZlIGNoYW5nZWQgdGhlIGZpcnN0IHBhdGggYnV0IGFsc28gcmVt
b3ZlZCBodGUNCj4gPj4+PiAiYXMgc3RhdGUgZGF0YSIgcGhyYXNlLiBJIGFsc28gbm90ZSB0aGF0
IGl0IGlzICdyb3V0ZXMnIG5vdCAncm91dGXigJkuDQo+ID4+PiANCj4gPj4+IFllcywgeW91IGFy
ZSByaWdodC4NCj4gPj4+IA0KPiA+Pj4+IFBlcmhhcHMgdGhpcyBzaG91bGQgYWxzbyBwcm92aWRl
IGEgbW9yZSBjb21wbGV0ZSBvdmVydmlldy4gTG9va2luZw0KPiA+Pj4+IGF0IHRoZSB2NHVyIGFu
ZCB2NnVyIG1vZGVscywgcGVyaGFwcyBpdCBtYWtlcyBzZW5zZSB0byBsaXN0IHRoaXM6DQo+ID4+
Pj4gDQo+ID4+Pj4gT0xEDQo+ID4+Pj4gDQo+ID4+Pj4gICAgICAgICAvcnQ6cm91dGluZy1zdGF0
ZS9ydDpyaWJzL3J0OnJpYi9ydDpyb3V0ZQ0KPiA+Pj4+IA0KPiA+Pj4+ICAgICBhbmQNCj4gPj4+
PiANCj4gPj4+PiAgICAgICAgIC9ydDphY3RpdmUtcm91dGUvcnQ6b3V0cHV0L3J0OnJvdXRlLA0K
PiA+Pj4+IA0KPiA+Pj4+IE5FVw0KPiA+Pj4+IA0KPiA+Pj4+IAkgIC9ydDpyb3V0aW5nLXN0YXRl
L3J0OnJpYnMvcnQ6cmliL3J0OnJvdXRlcy9ydDpyb3V0ZQ0KPiA+Pj4+IAkgIC9ydDpyb3V0aW5n
L3J0OnJvdXRpbmctaW5zdGFuY2UvcnQ6cm91dGluZy1wcm90b2NvbHMvcnQ6cm91dGluZy1wcm90
b2NvbA0KPiA+Pj4gDQo+ID4+PiBUaGUg4oCYcm91dGluZy1wcm90b2NvbOKAmSBjb250YWluZXIg
YW5kIGl0cyBjb250ZW50cyBoYXZlIHRvIGJlIGRlZmluZWQgZnJvbSBzY3JhdGNoIChzZWUgdGhl
IHRoaXJkIGJ1bGxldCkgYW5kIGl0cyBjb25maWd1cmF0aW9uIGluIGZhY3QgbmVlZG7igJl0IGNv
bnRhaW4gYW55IGV4cGxpY2l0IHJvdXRlcy4gU28gSSB0aGluayB0aGlzIGxpbmUgc2hvdWxkbid0
IGJlIHRoZXJlLg0KPiA+Pj4gDQo+ID4+IA0KPiA+PiBPSy4gVGhlbiBqdXN0IGZpeCB0aGUgZmly
c3QgcGF0aC4NCj4gPj4gDQo+ID4+Pj4gICAgICBhbmQNCj4gPj4+PiAJICAvcnQ6YWN0aXZlLXJv
dXRlL3J0Om91dHB1dA0KPiA+Pj4+IA0KPiA+Pj4+IC0gQ29uY2VybmluZyBjdXItaG9wLWxpbWl0
LCBpc24ndCB0aGUgcmlnaHQgYXBwcm9hY2ggdG8gbGVhdmUgdGhlIGRlZmF1bHQNCj4gPj4+PiBz
dGF0ZW1lbnQgaW4gdGhlIHN0YXRlIHRyZWUgYW5kIHRvIHJlbW92ZSB0aGUgZGVmYXVsdCBmcm9t
IHRoZSBjb25maWcNCj4gPj4+PiB0cmVlPyAoU2VlIHRoZSBvdGhlciB0aHJlYWQuKQ0KPiA+Pj4g
DQo+ID4+PiBIbW0sIEkgYW0gbm90IHN1cmUgd2hhdCB0byBkbyB3aXRoIHRoaXMuIFRoZSBvdGhl
ciBtb2R1bGVzIG9ubHkgaGF2ZSB0aGUgZGVmYXVsdHMgaW4gY29uZmlnLiBDYW4gb3RoZXIgcGVv
cGxlIGNvbW1lbnQ/DQo+ID4+PiANCj4gPj4gDQo+ID4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhh
dCBkZWZhdWx0cyBvbiBjb25maWcgZmFsc2Ugb2JqZWN0cyBvbmx5IHByb3ZpZGUNCj4gPj4gYW4g
b3B0aW1pemF0aW9uIGZvciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0ICd0cmltJyBkZWZh
dWx0cw0KPiA+PiBoYW5kbGluZy4gVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgaXQgaXMgd29ydGgg
aXQuIFtPbmNlIEkgdHJvdWJsZQ0KPiA+PiBzaG9vdCBzb21ldGhpbmcsIEkgdXN1YWxseSBwcmVm
ZXIgdG8gc2VlIGFsbCB2YWx1ZXMgYmVpbmcgdXNlZCwNCj4gPj4gZmlsdGVyaW5nIHRoZW0gb3V0
IGFzIG5lZWRlZCBmb3IgdGhlIHRhc2sgYXQgaGFuZCwgdGhhdCBpcyBJIHdvdWxkIHVzZQ0KPiA+
PiAncmVwb3J0LWFsbCcgYW55d2F5IGlmIGF2YWlsYWJsZS4gQnV0IHRoYXQgaXMganVzdCBtZS5d
DQo+ID4+IA0KPiA+PiBUaGF0IHNhaWQsIEkgbGlrZSB0byB0YWtlIGEgcHJhZ21hdGljIGRlY2lz
aW9uLiBJIHNlZSB0d28gb3B0aW9uczoNCj4gPj4gDQo+ID4+IC0gQWRkIGRlZmF1bHQgNjQgdG8g
Y3VyLWhvcC1saW1pdCB0byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIG90aGVyDQo+ID4+ICBzdGF0
ZSBvYmplY3RzIHRoYXQgaGF2ZSBhIGRlZmF1bHQuDQo+ID4+IA0KPiA+PiAtIFJlbW92ZSBhbGwg
ZGVmYXVsdHMgZnJvbSBhbGwgc3RhdGUgb2JqZWN0cyBiZWNhdXNlIHRoZSByZWFsIHZhbHVlDQo+
ID4+ICBvZiBkZWZhdWx0cyBpcyBmb3IgY29uZmlnIHRydWUgb2JqZWN0cy4NCj4gPj4gDQo+ID4+
IEJvdGggd29yayBmb3IgbWUuIFdlIHNob3VsZCBkZWNpZGUgdGhpcyBxdWlja2x5LiBMYWRhPyBN
YXJ0aW4/DQo+ID4+IEFuZHk/IEFueW9uZSBlbHNlPw0KPiA+IA0KPiA+IFdlbGwsIGFzIEkgc3Rh
dGVkIGJlZm9yZSwgSSB0aGluayB0aGF0IHRoZSBkZWZhdWx0IHN0YXRlbWVudCBzaG91bGQgYmUN
Cj4gPiByZW1vdmVkIGZyb20gdGhlIGNvbmZpZyBsZWFmLiAgVGh1cywgaXQgZG9lc24ndCBtYWtl
IGFueSBzZW5zZSB0byBoYXZlDQo+IA0KPiBSZWFzb25zPyBIb3cgaXMgaXQgZGlmZmVyZW50IGZy
b20sIGUuZy4sIGRlZmF1bHQtdmFsaWQtbGlmZXRpbWUgaW4gaWV0Zi1pcD8NCg0KRm9yIGRlZmF1
bHQtdmFsaWQtbGlmZXRpbWUsIHRoZXJlIGlzIGFuIGV4cGxpY2l0IGRlZmF1bHQgdmFsdWUgaW4g
dGhlDQpSRkMuDQoNCkZvciBjdXItaG9wLWxpbWl0LCB0aGUgUkZDIHNheXMgdGhhdCB0aGUgaW1w
bGVtZW50YXRpb24gc2hvdWxkIHVzZSB0aGUNCnZhbHVlIGRlZmluZWQgYnkgSUFOQSBhdCB0aGUg
dGltZSBvZiBpbXBsZW1lbnRhdGlvbiwgaWYgaXQgaXNuJ3QNCmV4cGxpY2l0aWx5IGNvbmZpZ3Vy
ZWQuICBJZiB5b3UgaGF2ZSBhIGRlZmF1bHQgc3RhdGVtZW50IGhlcmUsIGFuZA0KSUFOQSB1cGRh
dGVzIGl0cyB2YWx1ZSwgaXQgaXMgaW1wb3NzaWJsZSBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8g
YmUNCmNvbXBsaWFudCB3aXRoIHRoaXMgWUFORyBtb2R1bGUgYW5kIFJGQyA0ODYxLg0KDQoNCj4g
PiBhIGRlZmF1bHQgaW4gdGhlIG9wZXIgc3RhdGUgZm9yIHRoaXMgbGVhZi4NCj4gDQo+IFdoeSBu
b3Q/IEFzIEp1ZXJnZW4gd3JvdGUsIGl0IGlzIHVzZWZ1bCBmb3IgdGhlIOKAmHRyaW3igJkgbW9k
ZSwgYW5kIGl0DQo+IGRvZXNu4oCZdCBtYXR0ZXIgd2hldGhlciB0aGUgZGVmYXVsdCBpcyBkZWZp
bmVkIGZvciB0aGUgY29uZmlnIGxlYWYgb3INCj4gbm90Lg0KDQpDb3JyZWN0LCBidXQgaXQgc2Vl
bXMgYSBiaXQgYXJiaXRyYXJ5IChldmVuIGlmIHRoZSB2YWx1ZSA2NCBpcw0KInN0YWJsZSIpLg0K
DQoNCi9tYXJ0aW4NCg==


From nobody Fri May 23 05:38:19 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463A81A01BC for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 05:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level: 
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_12=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aolZla-yk1n for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 05:38:16 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751A11A01BD for <netmod@ietf.org>; Fri, 23 May 2014 05:38:16 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5E2E31400FE; Fri, 23 May 2014 14:38:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400848693; bh=kDwzL9pOzs4cg1N14kIrXwZJ3Vz3Xp8qU2taPWFHX0Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Lgu397iCfGohScPuSHQKcVsih9tYsKvKiMiolqLqpmvNskXJ8wC0s9rMo5OUq4UsI zjzy9Gv17kZZnEsZ4PsSoBfVWbFtmEclw96ikoZO+brioZVuEKozhV45lOOMoNt+Te iLQHNAtmhRzx4W5s9mjkPuldKWOzX18atyVOR2UU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140523.141531.1719212826923970987.mbj@tail-f.com>
Date: Fri, 23 May 2014 14:38:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5C1F0C5-F54F-4A15-827E-8D6EBAEF2AF1@nic.cz>
References: <20140523100950.GB198@elstar.local> <20140523.135627.1822345686578986376.mbj@tail-f.com> <C4BDE829-A7D8-4A1B-956D-193E91907D16@nic.cz> <20140523.141531.1719212826923970987.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= <mbj@tail-f.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4zq0Fp1XTbuI4rZfXRPmGaVYQnk
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 12:38:18 -0000

On 23 May 2014, at 14:15, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>=20
>> On 23 May 2014, at 13:56, Martin Bjorklund <mbj@tail-f.com> wrote:
>>=20
>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>> On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
>>>>>=20
>>>>> On 23 May 2014, at 10:31, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
>>>>>=20
>>>>>> Lada,
>>>>>>=20
>>>>>> I have reviewed the changes. A few more nits (sorry) before I am
>>>>>> fully happy.
>>>>>>=20
>>>>>> - On page 21, you have changed the first path but also removed =
hte
>>>>>> "as state data" phrase. I also note that it is 'routes' not =
'route=92.
>>>>>=20
>>>>> Yes, you are right.
>>>>>=20
>>>>>> Perhaps this should also provide a more complete overview. =
Looking
>>>>>> at the v4ur and v6ur models, perhaps it makes sense to list this:
>>>>>>=20
>>>>>> OLD
>>>>>>=20
>>>>>>        /rt:routing-state/rt:ribs/rt:rib/rt:route
>>>>>>=20
>>>>>>    and
>>>>>>=20
>>>>>>        /rt:active-route/rt:output/rt:route,
>>>>>>=20
>>>>>> NEW
>>>>>>=20
>>>>>> 	  /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
>>>>>> 	  =
/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
>>>>>=20
>>>>> The =91routing-protocol=92 container and its contents have to be =
defined from scratch (see the third bullet) and its configuration in =
fact needn=92t contain any explicit routes. So I think this line =
shouldn't be there.
>>>>>=20
>>>>=20
>>>> OK. Then just fix the first path.
>>>>=20
>>>>>>     and
>>>>>> 	  /rt:active-route/rt:output
>>>>>>=20
>>>>>> - Concerning cur-hop-limit, isn't the right approach to leave the =
default
>>>>>> statement in the state tree and to remove the default from the =
config
>>>>>> tree? (See the other thread.)
>>>>>=20
>>>>> Hmm, I am not sure what to do with this. The other modules only =
have the defaults in config. Can other people comment?
>>>>>=20
>>>>=20
>>>> My understanding is that defaults on config false objects only =
provide
>>>> an optimization for implementations that support 'trim' defaults
>>>> handling. The question is whether it is worth it. [Once I trouble
>>>> shoot something, I usually prefer to see all values being used,
>>>> filtering them out as needed for the task at hand, that is I would =
use
>>>> 'report-all' anyway if available. But that is just me.]
>>>>=20
>>>> That said, I like to take a pragmatic decision. I see two options:
>>>>=20
>>>> - Add default 64 to cur-hop-limit to be consistent with the other
>>>> state objects that have a default.
>>>>=20
>>>> - Remove all defaults from all state objects because the real value
>>>> of defaults is for config true objects.
>>>>=20
>>>> Both work for me. We should decide this quickly. Lada? Martin?
>>>> Andy? Anyone else?
>>>=20
>>> Well, as I stated before, I think that the default statement should =
be
>>> removed from the config leaf.  Thus, it doesn't make any sense to =
have
>>=20
>> Reasons? How is it different from, e.g., default-valid-lifetime in =
ietf-ip?
>=20
> For default-valid-lifetime, there is an explicit default value in the
> RFC.

Default TTL used to be in Assigned Numbers RFC and RFC 3232 handed it =
over to the online IANA database. IMO, this is no substantial =
difference.
 =20
>=20
> For cur-hop-limit, the RFC says that the implementation should use the
> value defined by IANA at the time of implementation, if it isn't
> explicitily configured.  If you have a default statement here, and

As I wrote, I am prepared to remove that part of the description.

> IANA updates its value, it is impossible for an implementation to be
> compliant with this YANG module and RFC 4861.

The same will be true for default-valid-lifetime as soon as IETF updates =
its value.

>=20
>=20
>>> a default in the oper state for this leaf.
>>=20
>> Why not? As Juergen wrote, it is useful for the =91trim=92 mode, and =
it
>> doesn=92t matter whether the default is defined for the config leaf =
or
>> not.
>=20
> Correct, but it seems a bit arbitrary (even if the value 64 is
> "stable=94).

I don=92t know what you mean by arbitrary. A server operating in the =
=91trim=92 mode will suppress the leaf if its value is 64. It is usually =
a good thing because this parameter is mostly uninteresting.

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 06:12:34 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7481A01C0 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 06:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHsFRRjpit72 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 06:12:25 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6D71A002B for <netmod@ietf.org>; Fri, 23 May 2014 06:12:25 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3C310F60; Fri, 23 May 2014 15:12:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tsGXpg8nui2y; Fri, 23 May 2014 15:12:14 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 May 2014 15:12:20 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5777C20034; Fri, 23 May 2014 15:12:20 +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 W3xtRSLqWfrt; Fri, 23 May 2014 15:12:19 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D68320013; Fri, 23 May 2014 15:12:19 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D4D502CF497A; Fri, 23 May 2014 15:12:16 +0200 (CEST)
Date: Fri, 23 May 2014 15:12:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140523131214.GA495@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj@tail-f.com>, netmod@ietf.org
References: <20140523100950.GB198@elstar.local> <20140523.135627.1822345686578986376.mbj@tail-f.com> <C4BDE829-A7D8-4A1B-956D-193E91907D16@nic.cz> <20140523.141531.1719212826923970987.mbj@tail-f.com> <B5C1F0C5-F54F-4A15-827E-8D6EBAEF2AF1@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B5C1F0C5-F54F-4A15-827E-8D6EBAEF2AF1@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AX8FkK6mifAaV2Pg7yyGbBatl3o
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 13:12:32 -0000

On Fri, May 23, 2014 at 02:38:12PM +0200, Ladislav Lhotka wrote:
> 
> 
> > IANA updates its value, it is impossible for an implementation to be
> > compliant with this YANG module and RFC 4861.
> 
> The same will be true for default-valid-lifetime as soon as IETF updates its value.
> 

Looking at RFC 4861, it seems there is explicit text saying that
CurHopLimit is under IANA control (i.e., designed to change without
updating RFC 4861).

        CurHopLimit    The default hop limit to be used when sending IP
                       packets.

                       Default: The value specified in the "Assigned
                       Numbers" [ASSIGNED] that was in effect at the
                       time of implementation.

A change to AdvDefaultLifetime likely requires a new RFC and since
there will be explicit dependencies between the documents, one could
hope that at the time such an update happens someone figures out that
the YANG data model may also need work. So I think there is (at least
in principle) a difference between the two things and I think we
better follow what RFC 4861 says (namely that control of the default
for CurHopLimit is with IANA).

/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 nobody Fri May 23 07:03:18 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7501F1A052E for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 07:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XEamhAH-rts for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 07:03:14 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055101A0196 for <netmod@ietf.org>; Fri, 23 May 2014 07:03:02 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CA0DE1412AC; Fri, 23 May 2014 16:02:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400853780; bh=0oPqluddQkWmuYKDdeMblOaVENxqw9O+lJTPx+IsOGw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xbZFNihwkScUugDLDgHKHJqBUhDxmwC5O1cBkuS05XUpe8xSYFWEh2ZnrJlL3Vu5a 4nxvwdFmKR7uBRH2HyRSbj2f+WJMoM78rDinxHDbMDkG4c5l3AGjjswODoLOhFPP98 /rLYiyBQtTtMSF4pvm5s1fW+M9CfaY4+l1SHnqQA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20140523131214.GA495@elstar.local>
Date: Fri, 23 May 2014 16:02:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD8E3466-6E3F-4B7D-AAC6-BF427FDE1CAB@nic.cz>
References: <20140523100950.GB198@elstar.local> <20140523.135627.1822345686578986376.mbj@tail-f.com> <C4BDE829-A7D8-4A1B-956D-193E91907D16@nic.cz> <20140523.141531.1719212826923970987.mbj@tail-f.com> <B5C1F0C5-F54F-4A15-827E-8D6EBAEF2AF1@nic.cz> <20140523131214.GA495@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Zt61ttTfPzCEpi4YRanYvEvnFho
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 14:03:16 -0000

On 23 May 2014, at 15:12, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, May 23, 2014 at 02:38:12PM +0200, Ladislav Lhotka wrote:
>>=20
>>=20
>>> IANA updates its value, it is impossible for an implementation to be
>>> compliant with this YANG module and RFC 4861.
>>=20
>> The same will be true for default-valid-lifetime as soon as IETF =
updates its value.
>>=20
>=20
> Looking at RFC 4861, it seems there is explicit text saying that
> CurHopLimit is under IANA control (i.e., designed to change without
> updating RFC 4861).
>=20
>        CurHopLimit    The default hop limit to be used when sending IP
>                       packets.
>=20
>                       Default: The value specified in the "Assigned
>                       Numbers" [ASSIGNED] that was in effect at the
>                       time of implementation.

It all seems a bit clumsy because the IANA page only talks about default =
TTL, which is an IPv4-specific parameter. Oh well =85

>=20
> A change to AdvDefaultLifetime likely requires a new RFC and since
> there will be explicit dependencies between the documents, one could
> hope that at the time such an update happens someone figures out that
> the YANG data model may also need work. So I think there is (at least
> in principle) a difference between the two things and I think we
> better follow what RFC 4861 says (namely that control of the default
> for CurHopLimit is with IANA).

OK. It seems Martin prefers a third solution, namely to have a default =
for cur-hop-limit neither in config nor in state data. Assuming the =
other defaults will stay as they are, I can live with that.

Lada =20

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 07:48:36 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6AF1A01D8 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 07:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level: 
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AizDWACAPr5G for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 07:48:32 -0700 (PDT)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657A51A04A2 for <netmod@ietf.org>; Fri, 23 May 2014 07:48:32 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id q108so8229989qgd.13 for <netmod@ietf.org>; Fri, 23 May 2014 07:48:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=s8GFG+QhV+TYvOn6XsR8L0rmBa2CDAOzQRUG89uPOMs=; b=CEvv27dhIcavnX1d2cwIadqSNMj2daJ9eEATwxwA0YpAP9jgLUu3bs5Jd5LxP5G2Hh zEYYiMvSg2il0eySZ9dfWg7dB9HGG2ynlZBybYP1Y1egPrRBnmkTPJfQfdC6kKkB14B3 xZqWZko1w7EyN3gQ4vesuhemdwOvSbxdUqkTfe5aK0qRHV6UlvYRH3Sj7UWBNfy2+uJj taslKC0bRIlRfSCs1EYR4zFEU3QX58rZGuklCZ4OIcQjXORudaIX9UIEZbGArRG/o90v ei9QO9g0jRBdPnflsY4dqtPa94kXJSWCAaF5gscHZiYwU8HSWurVISGNZ0Oipp5ScKTk 2cKA==
X-Gm-Message-State: ALoCoQnOcUuiAhVZ5v7fcXUB0JbGQURrMmdqg3ofL7WcIyNtXvkKxRHZYtWTaC8AIrEkIZreaEGf
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr7081268qgy.34.1400856510240; Fri, 23 May 2014 07:48:30 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 23 May 2014 07:48:30 -0700 (PDT)
In-Reply-To: <20140523100950.GB198@elstar.local>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local>
Date: Fri, 23 May 2014 07:48:30 -0700
Message-ID: <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c126baacc8b504fa1252dd
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XL0eo8SExN8MntmUvjNuuElIExY
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 14:48:35 -0000

--001a11c126baacc8b504fa1252dd
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
> >
> > On 23 May 2014, at 10:31, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > Lada,
> > >
> > > I have reviewed the changes. A few more nits (sorry) before I am
> > > fully happy.
> > >
> > > - On page 21, you have changed the first path but also removed hte
> > >  "as state data" phrase. I also note that it is 'routes' not 'route'.
> >
> > Yes, you are right.
> >
> > >  Perhaps this should also provide a more complete overview. Looking
> > >  at the v4ur and v6ur models, perhaps it makes sense to list this:
> > >
> > >  OLD
> > >
> > >          /rt:routing-state/rt:ribs/rt:rib/rt:route
> > >
> > >      and
> > >
> > >          /rt:active-route/rt:output/rt:route,
> > >
> > >  NEW
> > >
> > >       /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> > >
> /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
> >
> > The 'routing-protocol' container and its contents have to be defined
> from scratch (see the third bullet) and its configuration in fact needn't
> contain any explicit routes. So I think this line shouldn't be there.
> >
>
> OK. Then just fix the first path.
>
> > >       and
> > >       /rt:active-route/rt:output
> > >
> > > - Concerning cur-hop-limit, isn't the right approach to leave the
> default
> > >  statement in the state tree and to remove the default from the config
> > >  tree? (See the other thread.)
> >
> > Hmm, I am not sure what to do with this. The other modules only have the
> defaults in config. Can other people comment?
> >
>
> My understanding is that defaults on config false objects only provide
> an optimization for implementations that support 'trim' defaults
> handling. The question is whether it is worth it. [Once I trouble
> shoot something, I usually prefer to see all values being used,
> filtering them out as needed for the task at hand, that is I would use
> 'report-all' anyway if available. But that is just me.]
>
> That said, I like to take a pragmatic decision. I see two options:
>
> - Add default 64 to cur-hop-limit to be consistent with the other
>   state objects that have a default.
>
> - Remove all defaults from all state objects because the real value
>   of defaults is for config true objects.
>
> Both work for me. We should decide this quickly. Lada? Martin?
> Andy? Anyone else?
>
>

I think we need to re-examine the default-stmt and mandatory-stmt
for config=false nodes. IMO they are both broken for the same reason:

NACM on the server can cause nodes to be silently dropped.
Unless the client is running as "root" (should be the exception)
then it does not know for sure why a leaf was missing in a <get>
reply.  Was it access control or was it the default for a "trim" basic-mode
server?

Both mandatory-stmt and default-stmt are unusable for config=false
nodes because of this ambiguity.

Short answer: remove defaults from all state objects.


/js
>
>

Andy

--001a11c126baacc8b504fa1252dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder <span dir=3D=
"ltr">&lt;<a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D=
"_blank">j.schoenwaelder@jacobs-university.de</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, May 23, 2014 at 11:12:43AM +0200, La=
dislav Lhotka wrote:<br>
&gt;<br>
&gt; On 23 May 2014, at 10:31, Juergen Schoenwaelder &lt;<a href=3D"mailto:=
j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-university.de<=
/a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Lada,<br>
&gt; &gt;<br>
&gt; &gt; I have reviewed the changes. A few more nits (sorry) before I am<=
br>
&gt; &gt; fully happy.<br>
&gt; &gt;<br>
&gt; &gt; - On page 21, you have changed the first path but also removed ht=
e<br>
&gt; &gt; &nbsp;&quot;as state data&quot; phrase. I also note that it is &#=
39;routes&#39; not &#39;route&rsquo;.<br>
&gt;<br>
&gt; Yes, you are right.<br>
&gt;<br>
&gt; &gt; &nbsp;Perhaps this should also provide a more complete overview. =
Looking<br>
&gt; &gt; &nbsp;at the v4ur and v6ur models, perhaps it makes sense to list=
 this:<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;OLD<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/rt:routing-state/rt:ribs/rt:ri=
b/rt:route<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp;and<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/rt:active-route/rt:output/rt:r=
oute,<br>
&gt; &gt;<br>
&gt; &gt; &nbsp;NEW<br>
&gt; &gt;<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; /rt:routing-state/rt:ribs/rt:rib/rt:routes/r=
t:route<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; /rt:routing/rt:routing-instance/rt:routing-p=
rotocols/rt:routing-protocol<br>
&gt;<br>
&gt; The &lsquo;routing-protocol&rsquo; container and its contents have to =
be defined from scratch (see the third bullet) and its configuration in fac=
t needn&rsquo;t contain any explicit routes. So I think this line shouldn&#=
39;t be there.<br>

&gt;<br>
<br>
OK. Then just fix the first path.<br>
<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; and<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; /rt:active-route/rt:output<br>
&gt; &gt;<br>
&gt; &gt; - Concerning cur-hop-limit, isn&#39;t the right approach to leave=
 the default<br>
&gt; &gt; &nbsp;statement in the state tree and to remove the default from =
the config<br>
&gt; &gt; &nbsp;tree? (See the other thread.)<br>
&gt;<br>
&gt; Hmm, I am not sure what to do with this. The other modules only have t=
he defaults in config. Can other people comment?<br>
&gt;<br>
<br>
My understanding is that defaults on config false objects only provide<br>
an optimization for implementations that support &#39;trim&#39; defaults<br=
>
handling. The question is whether it is worth it. [Once I trouble<br>
shoot something, I usually prefer to see all values being used,<br>
filtering them out as needed for the task at hand, that is I would use<br>
&#39;report-all&#39; anyway if available. But that is just me.]<br>
<br>
That said, I like to take a pragmatic decision. I see two options:<br>
<br>
- Add default 64 to cur-hop-limit to be consistent with the other<br>
&nbsp; state objects that have a default.<br>
<br>
- Remove all defaults from all state objects because the real value<br>
&nbsp; of defaults is for config true objects.<br>
<br>
Both work for me. We should decide this quickly. Lada? Martin?<br>
Andy? Anyone else?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div><br></div><div>I think we need to re-examine the def=
ault-stmt and mandatory-stmt</div><div>for config=3Dfalse nodes. IMO they a=
re both broken for the same reason:</div>
<div><br></div><div>NACM on the server can cause nodes to be silently dropp=
ed.<br></div><div>Unless the client is running as &quot;root&quot; (should =
be the exception)</div><div>then it does not know for sure why a leaf was m=
issing in a &lt;get&gt;</div>
<div>reply. &nbsp;Was it access control or was it the default for a &quot;t=
rim&quot; basic-mode</div><div>server?</div><div><br></div><div>Both mandat=
ory-stmt and default-stmt are unusable for config=3Dfalse</div><div>nodes b=
ecause of this ambiguity.</div>
<div><br></div><div>Short answer: remove defaults from all state objects.</=
div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"HOEnZb"><font color=3D"#888888">
/js<br>
<br></font></span></blockquote><div><br></div><div><br></div><div>Andy</div=
><div><br></div></div></div></div>

--001a11c126baacc8b504fa1252dd--


From nobody Fri May 23 08:33:24 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D501A01DF for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 08:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.498
X-Spam-Level: 
X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTmsFWxU1KJY for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 08:33:21 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7737F1A0019 for <netmod@ietf.org>; Fri, 23 May 2014 08:33:20 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AE5A0141294; Fri, 23 May 2014 17:33:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400859196; bh=NJsxexXKqLtWWZmTaRExojVU2EReIlxtNWkkIyA425k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LZF1ZgVoby6IfVxw76uL4GuHXnL8impAlDV+Kq04skkjImcSnprXi8/lHyoQrJEes NLSX8jFqGng+DV4h6pw6S3XCbbw+ymPJxxBMEswGKf5QVycD64wIt2OSlUf18ARfyu h+ka+F2GXeY3uw8Op6NShQ9GFAu1hGNZUTZbfCks=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com>
Date: Fri, 23 May 2014 17:33:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eno1CqmTFSJ6hF6IkdTOa-P0_lQ
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 15:33:23 -0000

On 23 May 2014, at 16:48, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
> On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
> >
> > On 23 May 2014, at 10:31, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > Lada,
> > >
> > > I have reviewed the changes. A few more nits (sorry) before I am
> > > fully happy.
> > >
> > > - On page 21, you have changed the first path but also removed hte
> > >  "as state data" phrase. I also note that it is 'routes' not =
'route=92.
> >
> > Yes, you are right.
> >
> > >  Perhaps this should also provide a more complete overview. =
Looking
> > >  at the v4ur and v6ur models, perhaps it makes sense to list this:
> > >
> > >  OLD
> > >
> > >          /rt:routing-state/rt:ribs/rt:rib/rt:route
> > >
> > >      and
> > >
> > >          /rt:active-route/rt:output/rt:route,
> > >
> > >  NEW
> > >
> > >       /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> > >       =
/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
> >
> > The =91routing-protocol=92 container and its contents have to be =
defined from scratch (see the third bullet) and its configuration in =
fact needn=92t contain any explicit routes. So I think this line =
shouldn't be there.
> >
>=20
> OK. Then just fix the first path.
>=20
> > >       and
> > >       /rt:active-route/rt:output
> > >
> > > - Concerning cur-hop-limit, isn't the right approach to leave the =
default
> > >  statement in the state tree and to remove the default from the =
config
> > >  tree? (See the other thread.)
> >
> > Hmm, I am not sure what to do with this. The other modules only have =
the defaults in config. Can other people comment?
> >
>=20
> My understanding is that defaults on config false objects only provide
> an optimization for implementations that support 'trim' defaults
> handling. The question is whether it is worth it. [Once I trouble
> shoot something, I usually prefer to see all values being used,
> filtering them out as needed for the task at hand, that is I would use
> 'report-all' anyway if available. But that is just me.]
>=20
> That said, I like to take a pragmatic decision. I see two options:
>=20
> - Add default 64 to cur-hop-limit to be consistent with the other
>   state objects that have a default.
>=20
> - Remove all defaults from all state objects because the real value
>   of defaults is for config true objects.
>=20
> Both work for me. We should decide this quickly. Lada? Martin?
> Andy? Anyone else?
>=20
>=20
>=20
> I think we need to re-examine the default-stmt and mandatory-stmt
> for config=3Dfalse nodes. IMO they are both broken for the same =
reason:
>=20
> NACM on the server can cause nodes to be silently dropped.
> Unless the client is running as "root" (should be the exception)
> then it does not know for sure why a leaf was missing in a <get>
> reply.  Was it access control or was it the default for a "trim" =
basic-mode
> server?

But don=92t config=3Dtrue nodes have exactly the same problem in a reply =
to <get> or <get-config>?

Lada

>=20
> Both mandatory-stmt and default-stmt are unusable for config=3Dfalse
> nodes because of this ambiguity.
>=20
> Short answer: remove defaults from all state objects.
>=20
>=20
> /js
>=20
>=20
>=20
> Andy
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 09:11:47 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598E71A0680 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 09:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.522
X-Spam-Level: 
X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id an5safdsUYuJ for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 09:11:37 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95A61A00B8 for <netmod@ietf.org>; Fri, 23 May 2014 09:11:36 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id f51so8313146qge.12 for <netmod@ietf.org>; Fri, 23 May 2014 09:11:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gxucQ+qbWnXdx+huYb71mDtF0IgrO3HwJHSIo/fmnW4=; b=MdGrIxjPNPMSRowjs/iqCUic67M/xBCuSBS7EVyF62QM0fKHXFaaIONGsSzoDs2zhr h/YrbcuWilrW5FrkXUu1umHZGDknyefBJRiN09gi1WNN4r5KKoOx4QakJRtkCcOCLY3O qHhSAkbs5ovZmYxO+4rShCo+tOZSsqXNsRhTMHGPWAQBGv7HrGoz4TM3KNiHIaAaW3jo g4cNj6qsQixuIxlWtcsziO45V8gOEmCD4ZmKXGPwCFLHH3LMr19A05T7Dm0HTMjW7voC LILekRwcJGcDPumC9BGrrSzUnhOeyIbeIRqbkaOTlBP3ZlKpP+aXr3w6Uy5e5hSRGClp cOCA==
X-Gm-Message-State: ALoCoQmkMV4Nc5LAHb/N6VkBhWb87b2Ew5z3UJhMz9LHOhDzp2wbMDsC0l4rPGgKXEOr7RQMmHiH
MIME-Version: 1.0
X-Received: by 10.224.24.134 with SMTP id v6mr8235581qab.88.1400861494734; Fri, 23 May 2014 09:11:34 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 23 May 2014 09:11:34 -0700 (PDT)
In-Reply-To: <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz>
Date: Fri, 23 May 2014 09:11:34 -0700
Message-ID: <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c252c6c6036f04fa137b36
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R2t33-SZHbfOEiRoRD_136IDsrE
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 16:11:45 -0000

--001a11c252c6c6036f04fa137b36
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 23, 2014 at 8:33 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 23 May 2014, at 16:48, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
> > >
> > > On 23 May 2014, at 10:31, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > > Lada,
> > > >
> > > > I have reviewed the changes. A few more nits (sorry) before I am
> > > > fully happy.
> > > >
> > > > - On page 21, you have changed the first path but also removed hte
> > > >  "as state data" phrase. I also note that it is 'routes' not 'route'.
> > >
> > > Yes, you are right.
> > >
> > > >  Perhaps this should also provide a more complete overview. Looking
> > > >  at the v4ur and v6ur models, perhaps it makes sense to list this:
> > > >
> > > >  OLD
> > > >
> > > >          /rt:routing-state/rt:ribs/rt:rib/rt:route
> > > >
> > > >      and
> > > >
> > > >          /rt:active-route/rt:output/rt:route,
> > > >
> > > >  NEW
> > > >
> > > >       /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> > > >
> /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
> > >
> > > The 'routing-protocol' container and its contents have to be defined
> from scratch (see the third bullet) and its configuration in fact needn't
> contain any explicit routes. So I think this line shouldn't be there.
> > >
> >
> > OK. Then just fix the first path.
> >
> > > >       and
> > > >       /rt:active-route/rt:output
> > > >
> > > > - Concerning cur-hop-limit, isn't the right approach to leave the
> default
> > > >  statement in the state tree and to remove the default from the
> config
> > > >  tree? (See the other thread.)
> > >
> > > Hmm, I am not sure what to do with this. The other modules only have
> the defaults in config. Can other people comment?
> > >
> >
> > My understanding is that defaults on config false objects only provide
> > an optimization for implementations that support 'trim' defaults
> > handling. The question is whether it is worth it. [Once I trouble
> > shoot something, I usually prefer to see all values being used,
> > filtering them out as needed for the task at hand, that is I would use
> > 'report-all' anyway if available. But that is just me.]
> >
> > That said, I like to take a pragmatic decision. I see two options:
> >
> > - Add default 64 to cur-hop-limit to be consistent with the other
> >   state objects that have a default.
> >
> > - Remove all defaults from all state objects because the real value
> >   of defaults is for config true objects.
> >
> > Both work for me. We should decide this quickly. Lada? Martin?
> > Andy? Anyone else?
> >
> >
> >
> > I think we need to re-examine the default-stmt and mandatory-stmt
> > for config=false nodes. IMO they are both broken for the same reason:
> >
> > NACM on the server can cause nodes to be silently dropped.
> > Unless the client is running as "root" (should be the exception)
> > then it does not know for sure why a leaf was missing in a <get>
> > reply.  Was it access control or was it the default for a "trim"
> basic-mode
> > server?
>
> But don't config=true nodes have exactly the same problem in a reply to
> <get> or <get-config>?
>
>
Yes, NACM has the same problem for config=true.  The operator needs
to know how NACM is configured -- clients that are not supposed to
know about some data node should not care if it is a default or not.

The ambiguity is wrt/ mandatory-stmt. (I think Martin pointed this out.)
The mandatory-stmt is 'false' if the default-stmt exists (has to be by
rule).

But if config=false and mandatory=false, the server
is not required to return instances of that node in an <rpc-reply>.
So the client does not know if the leaf is a 'trim' default or if the
server is electing not to include the leaf in the reply.



> Lada
>
>
Andy


> >
> > Both mandatory-stmt and default-stmt are unusable for config=false
> > nodes because of this ambiguity.
> >
> > Short answer: remove defaults from all state objects.
> >
> >
> > /js
> >
> >
> >
> > Andy
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c252c6c6036f04fa137b36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 23, 2014 at 8:33 AM, Ladislav Lhotka <span dir=3D"ltr">=
&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 23 May 2014, at 16:48, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder &lt;<a href=3D"=
mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-univers=
ity.de</a>&gt; wrote:<br>
&gt; On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:<br>
&gt; &gt;<br>
&gt; &gt; On 23 May 2014, at 10:31, Juergen Schoenwaelder &lt;<a href=3D"ma=
ilto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-universit=
y.de</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Lada,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I have reviewed the changes. A few more nits (sorry) before =
I am<br>
&gt; &gt; &gt; fully happy.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; - On page 21, you have changed the first path but also remov=
ed hte<br>
&gt; &gt; &gt; &nbsp;&quot;as state data&quot; phrase. I also note that it =
is &#39;routes&#39; not &#39;route&rsquo;.<br>
&gt; &gt;<br>
&gt; &gt; Yes, you are right.<br>
&gt; &gt;<br>
&gt; &gt; &gt; &nbsp;Perhaps this should also provide a more complete overv=
iew. Looking<br>
&gt; &gt; &gt; &nbsp;at the v4ur and v6ur models, perhaps it makes sense to=
 list this:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp;OLD<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/rt:routing-state/rt:ribs/=
rt:rib/rt:route<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp;and<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/rt:active-route/rt:output=
/rt:route,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp;NEW<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; /rt:routing-state/rt:ribs/rt:rib/rt:rou=
tes/rt:route<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; /rt:routing/rt:routing-instance/rt:rout=
ing-protocols/rt:routing-protocol<br>
&gt; &gt;<br>
&gt; &gt; The &lsquo;routing-protocol&rsquo; container and its contents hav=
e to be defined from scratch (see the third bullet) and its configuration i=
n fact needn&rsquo;t contain any explicit routes. So I think this line shou=
ldn&#39;t be there.<br>

&gt; &gt;<br>
&gt;<br>
&gt; OK. Then just fix the first path.<br>
&gt;<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; and<br>
&gt; &gt; &gt; &nbsp; &nbsp; &nbsp; /rt:active-route/rt:output<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; - Concerning cur-hop-limit, isn&#39;t the right approach to =
leave the default<br>
&gt; &gt; &gt; &nbsp;statement in the state tree and to remove the default =
from the config<br>
&gt; &gt; &gt; &nbsp;tree? (See the other thread.)<br>
&gt; &gt;<br>
&gt; &gt; Hmm, I am not sure what to do with this. The other modules only h=
ave the defaults in config. Can other people comment?<br>
&gt; &gt;<br>
&gt;<br>
&gt; My understanding is that defaults on config false objects only provide=
<br>
&gt; an optimization for implementations that support &#39;trim&#39; defaul=
ts<br>
&gt; handling. The question is whether it is worth it. [Once I trouble<br>
&gt; shoot something, I usually prefer to see all values being used,<br>
&gt; filtering them out as needed for the task at hand, that is I would use=
<br>
&gt; &#39;report-all&#39; anyway if available. But that is just me.]<br>
&gt;<br>
&gt; That said, I like to take a pragmatic decision. I see two options:<br>
&gt;<br>
&gt; - Add default 64 to cur-hop-limit to be consistent with the other<br>
&gt; &nbsp; state objects that have a default.<br>
&gt;<br>
&gt; - Remove all defaults from all state objects because the real value<br=
>
&gt; &nbsp; of defaults is for config true objects.<br>
&gt;<br>
&gt; Both work for me. We should decide this quickly. Lada? Martin?<br>
&gt; Andy? Anyone else?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I think we need to re-examine the default-stmt and mandatory-stmt<br>
&gt; for config=3Dfalse nodes. IMO they are both broken for the same reason=
:<br>
&gt;<br>
&gt; NACM on the server can cause nodes to be silently dropped.<br>
&gt; Unless the client is running as &quot;root&quot; (should be the except=
ion)<br>
&gt; then it does not know for sure why a leaf was missing in a &lt;get&gt;=
<br>
&gt; reply. &nbsp;Was it access control or was it the default for a &quot;t=
rim&quot; basic-mode<br>
&gt; server?<br>
<br>
But don&rsquo;t config=3Dtrue nodes have exactly the same problem in a repl=
y to &lt;get&gt; or &lt;get-config&gt;?<br>
<br></blockquote><div><br></div><div>Yes, NACM has the same problem for con=
fig=3Dtrue. &nbsp;The operator needs</div><div>to know how NACM is configur=
ed -- clients that are not supposed to</div><div>know about some data node =
should not care if it is a default or not.</div>
<div><br></div><div>The ambiguity is wrt/ mandatory-stmt. (I think Martin p=
ointed this out.)</div><div>The mandatory-stmt is &#39;false&#39; if the de=
fault-stmt exists (has to be by rule).</div><div><br></div><div>But if conf=
ig=3Dfalse and mandatory=3Dfalse, the server</div>
<div>is not required to return instances of that node in an &lt;rpc-reply&g=
t;.</div><div>So the client does not know if the leaf is a &#39;trim&#39; d=
efault or if the</div><div>server is electing not to include the leaf in th=
e reply.</div>
<div><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lada<br>
<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
&gt;<br>
&gt; Both mandatory-stmt and default-stmt are unusable for config=3Dfalse<b=
r>
&gt; nodes because of this ambiguity.<br>
&gt;<br>
&gt; Short answer: remove defaults from all state objects.<br>
&gt;<br>
&gt;<br>
&gt; /js<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c252c6c6036f04fa137b36--


From nobody Fri May 23 10:02:53 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481F51A064A for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 10:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3YX1RuElOWq for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 10:02:48 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D80E1A023A for <netmod@ietf.org>; Fri, 23 May 2014 10:02:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A1756F6D for <netmod@ietf.org>; Fri, 23 May 2014 19:02:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id n1aI5dGXBCvD for <netmod@ietf.org>; Fri, 23 May 2014 19:02:38 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Fri, 23 May 2014 19:02:44 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FC1D2002C for <netmod@ietf.org>; Fri, 23 May 2014 19:02:45 +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 PWKSB6BjUkvj; Fri, 23 May 2014 19:02:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A67BA20017; Fri, 23 May 2014 19:02:43 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 58D582CF5257; Fri, 23 May 2014 19:02:41 +0200 (CEST)
Date: Fri, 23 May 2014 19:02:41 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20140523170241.GB704@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DI4RVmDoM-g3X-TZzIEamirVIA4
Subject: [netmod] strawman proposal for moving yang 1.1 issues NEW -> OPEN
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 17:02:51 -0000

Hi,

as promised earlier, here is a strawman proposal which of the YANG 1.1
issues should be moved from NEW to OPEN (which means the issues are
considered in scope of the YANG 1.1 effort). For the issues list, see:

   http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

If you believe some of the issues should _not_ be addressed by the
YANG 1.1 effort, please speak up by the end of May and provide a
reasoning why you think the issue should not be addressed. Silence
will be interpreted as agreement to the strawman proposal.

  |-----+------+----------------------------------------------------------------+-------------------------|
  | Y01 | OPEN | allow boolean if-feature                                       | new feature             |
  | Y02 | OPEN | allow must in input, output, and notification                  | language consistency    |
  | Y03 | OPEN | allow if-feature in refine                                     | language consistency    |
  | Y04 | OPEN | accessible tree in xpath in notifs and rpc                     | language consistency    |
  | Y05 | OPEN | unprefixed path in top-level typedef                           | language consistency    |
  | Y06 | OPEN | escaped characters in double quoted strings                    | language consistency    |
  | Y07 | OPEN | do not allow when or if-feature on keys                        | language consistency    |
  | Y10 | OPEN | allow restrictions on enumerations                             | language consistency    |
  | Y11 | OPEN | allow if-feature on enums                                      | new feature             |
  | Y12 | OPEN | initialized-by system                                          | new feature             |
  | Y13 | OPEN | allow multiple inheritance for identities                      | new feature             |
  | Y14 | OPEN | clarify the string value for identities when used in must/when | language consistency    |
  | Y16 | OPEN | module advertisement optimization                              | performance improvement |
  | Y18 | OPEN | fix "when" expression context node problem                     | language consistency    |
  | Y20 | OPEN | new set of built-in XPath functions                            | new feature             |
  | Y23 | OPEN | support negative patterns as string restrictions               | new feature             |
  | Y25 | OPEN | make enum numbering purely informative and optional            | feature removal         |
  | Y28 | OPEN | support default values in leaf-lists                           | new feature             |
  | Y29 | OPEN | allow choice as a short-hand case                              | language consistency    |
  | Y30 | OPEN | allow leafref in union                                         | language consistency    |
  | Y34 | OPEN | remove/deprecate/replace the 'anyxml' statement                | generalization          |
  | Y35 | OPEN | allow empty in union                                           | language consistency    |
  | Y41 | OPEN | clarification of "must" in NP-container                        | language consistency    |
  | Y42 | OPEN | better model for configuration versus state data is needed     |                         |
  | Y44 | OPEN | add a mechanism to parameterize error-message                  | new feature             |
  | Y45 | OPEN | better conformance mechanism                                   | feature improvement     |
  | Y47 | OPEN | bit name too restrictive                                       | language consistency    |
  | Y49 | OPEN | clarify nested submodule behavior                              | language consistency    |
  |-----+------+----------------------------------------------------------------+-------------------------|

I hope I got the issue headlines all right. If there is a mismatch,
the issue number is authoritative.

/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 nobody Fri May 23 11:23:28 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BF81A023B for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 11:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.498
X-Spam-Level: 
X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 414TmBOfv29B for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 11:23:24 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3981A0224 for <netmod@ietf.org>; Fri, 23 May 2014 11:23:24 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 54D661412AC; Fri, 23 May 2014 20:23:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400869401; bh=/6PIiIIszQ6CVq2yGexytzNoLl87OemD5q+QraJ4o8A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sPJ7GdusezhrRUSXNPk81R9GqB/b1adPVrmTWJhDAmVmUG8uLHvrC1VDdrgSgHYOs hzgMli5Rh3oDBiDncY/O4QF5Sx7PM0bk/B9hyOqFrs4tC74f203JiyjCKLRMxHagLn AxYGnBCz5W0wKHK/df7ZEF9TZi4G+oxrtep8nFRQ=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com>
Date: Fri, 23 May 2014 20:23:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MsVaaVFG-mT0f4pFl4tukVb-4VU
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 18:23:26 -0000

On 23 May 2014, at 18:11, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Fri, May 23, 2014 at 8:33 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>=20
> On 23 May 2014, at 16:48, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
> > On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
> > >
> > > On 23 May 2014, at 10:31, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > > Lada,
> > > >
> > > > I have reviewed the changes. A few more nits (sorry) before I am
> > > > fully happy.
> > > >
> > > > - On page 21, you have changed the first path but also removed =
hte
> > > >  "as state data" phrase. I also note that it is 'routes' not =
'route=92.
> > >
> > > Yes, you are right.
> > >
> > > >  Perhaps this should also provide a more complete overview. =
Looking
> > > >  at the v4ur and v6ur models, perhaps it makes sense to list =
this:
> > > >
> > > >  OLD
> > > >
> > > >          /rt:routing-state/rt:ribs/rt:rib/rt:route
> > > >
> > > >      and
> > > >
> > > >          /rt:active-route/rt:output/rt:route,
> > > >
> > > >  NEW
> > > >
> > > >       /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> > > >       =
/rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
> > >
> > > The =91routing-protocol=92 container and its contents have to be =
defined from scratch (see the third bullet) and its configuration in =
fact needn=92t contain any explicit routes. So I think this line =
shouldn't be there.
> > >
> >
> > OK. Then just fix the first path.
> >
> > > >       and
> > > >       /rt:active-route/rt:output
> > > >
> > > > - Concerning cur-hop-limit, isn't the right approach to leave =
the default
> > > >  statement in the state tree and to remove the default from the =
config
> > > >  tree? (See the other thread.)
> > >
> > > Hmm, I am not sure what to do with this. The other modules only =
have the defaults in config. Can other people comment?
> > >
> >
> > My understanding is that defaults on config false objects only =
provide
> > an optimization for implementations that support 'trim' defaults
> > handling. The question is whether it is worth it. [Once I trouble
> > shoot something, I usually prefer to see all values being used,
> > filtering them out as needed for the task at hand, that is I would =
use
> > 'report-all' anyway if available. But that is just me.]
> >
> > That said, I like to take a pragmatic decision. I see two options:
> >
> > - Add default 64 to cur-hop-limit to be consistent with the other
> >   state objects that have a default.
> >
> > - Remove all defaults from all state objects because the real value
> >   of defaults is for config true objects.
> >
> > Both work for me. We should decide this quickly. Lada? Martin?
> > Andy? Anyone else?
> >
> >
> >
> > I think we need to re-examine the default-stmt and mandatory-stmt
> > for config=3Dfalse nodes. IMO they are both broken for the same =
reason:
> >
> > NACM on the server can cause nodes to be silently dropped.
> > Unless the client is running as "root" (should be the exception)
> > then it does not know for sure why a leaf was missing in a <get>
> > reply.  Was it access control or was it the default for a "trim" =
basic-mode
> > server?
>=20
> But don=92t config=3Dtrue nodes have exactly the same problem in a =
reply to <get> or <get-config>?
>=20
>=20
> Yes, NACM has the same problem for config=3Dtrue.  The operator needs
> to know how NACM is configured -- clients that are not supposed to
> know about some data node should not care if it is a default or not.

Hmm, maybe the nodes and subtrees blocked by NACM should be signalled =
somehow, e.g., by replacing the denied contents with <no-access/>.

>=20
> The ambiguity is wrt/ mandatory-stmt. (I think Martin pointed this =
out.)
> The mandatory-stmt is 'false' if the default-stmt exists (has to be by =
rule).
>=20
> But if config=3Dfalse and mandatory=3Dfalse, the server
> is not required to return instances of that node in an <rpc-reply>.
> So the client does not know if the leaf is a 'trim' default or if the
> server is electing not to include the leaf in the reply.

I agree this needs to be reconsidered and clarified, but we have to =
decide about the defaults in the routing document now. So how about this =
modification of -14:

1. Remove all defaults in state data.
2. In config, remove only the default of =91cur-hop-limit=92.

Lada


>=20
> =20
> Lada
>=20
>=20
> Andy
> =20
> >
> > Both mandatory-stmt and default-stmt are unusable for config=3Dfalse
> > nodes because of this ambiguity.
> >
> > Short answer: remove defaults from all state objects.
> >
> >
> > /js
> >
> >
> >
> > Andy
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri May 23 12:27:10 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C325F1A029B for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.178
X-Spam-Level: 
X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf7fdw2nZfAk for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:27:07 -0700 (PDT)
Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A16F1A0290 for <netmod@ietf.org>; Fri, 23 May 2014 12:27:07 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id i8so8870132qcq.15 for <netmod@ietf.org>; Fri, 23 May 2014 12:27:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mela4w+kEe94w8VpjOYHBZsKg4hu8mfVjkAephrd7Pk=; b=beXsBPE3ydUieG55H4ebk1q5J59KsJoIoxO8t5/ZX3wZuErDFKCRt/edzvB8D6Ds6g AMNVjL5Q2dsuAfsTHzY1VsRXVlFaxRr6QErS97rGIYomNtNOxkiKY7SOrlYpU5X17iZO LEcdaWk172V+PT1W192ZHHrd3wsx4aph/Olo/f4luQAUfqD5hMRizkRZ8iYlqmASyhP7 3wYvR6qCDSOixcbPJr53nzgOfEGE/yqK6sMtAhyEsOrRyFOXKKQhNk1PwKbu5dhw+P53 u5Nnbo8TBus2RnhNjo0cdshWmhSVX+bw1LkNLd9wLwVUz3iL/5S2Z6ejZCFLP8DApWj1 Hwcw==
X-Gm-Message-State: ALoCoQnjhkk3qohpFTSn9htoYQ9iytHQNxJDLh+Y3TwL1Lf68xHjVunZSOY42pDJSwReoemw6W8I
MIME-Version: 1.0
X-Received: by 10.224.24.134 with SMTP id v6mr10101222qab.88.1400873224862; Fri, 23 May 2014 12:27:04 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 23 May 2014 12:27:04 -0700 (PDT)
In-Reply-To: <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz>
Date: Fri, 23 May 2014 12:27:04 -0700
Message-ID: <CABCOCHQxGuFw27069eu6AECPB8qNNi2=ikGHQK1OVbC7=-W03g@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c252c6f1b1f804fa16362d
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U9tzTeVshWsQpcJ53sOUiuJf_tM
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 19:27:09 -0000

--001a11c252c6f1b1f804fa16362d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 23, 2014 at 11:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 23 May 2014, at 18:11, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Fri, May 23, 2014 at 8:33 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 23 May 2014, at 16:48, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > >
> > >
> > >
> > > On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > > On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:
> > > >
> > > > On 23 May 2014, at 10:31, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > > Lada,
> > > > >
> > > > > I have reviewed the changes. A few more nits (sorry) before I am
> > > > > fully happy.
> > > > >
> > > > > - On page 21, you have changed the first path but also removed hte
> > > > >  "as state data" phrase. I also note that it is 'routes' not
> 'route'.
> > > >
> > > > Yes, you are right.
> > > >
> > > > >  Perhaps this should also provide a more complete overview. Looking
> > > > >  at the v4ur and v6ur models, perhaps it makes sense to list this:
> > > > >
> > > > >  OLD
> > > > >
> > > > >          /rt:routing-state/rt:ribs/rt:rib/rt:route
> > > > >
> > > > >      and
> > > > >
> > > > >          /rt:active-route/rt:output/rt:route,
> > > > >
> > > > >  NEW
> > > > >
> > > > >       /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route
> > > > >
> /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol
> > > >
> > > > The 'routing-protocol' container and its contents have to be defined
> from scratch (see the third bullet) and its configuration in fact needn't
> contain any explicit routes. So I think this line shouldn't be there.
> > > >
> > >
> > > OK. Then just fix the first path.
> > >
> > > > >       and
> > > > >       /rt:active-route/rt:output
> > > > >
> > > > > - Concerning cur-hop-limit, isn't the right approach to leave the
> default
> > > > >  statement in the state tree and to remove the default from the
> config
> > > > >  tree? (See the other thread.)
> > > >
> > > > Hmm, I am not sure what to do with this. The other modules only have
> the defaults in config. Can other people comment?
> > > >
> > >
> > > My understanding is that defaults on config false objects only provide
> > > an optimization for implementations that support 'trim' defaults
> > > handling. The question is whether it is worth it. [Once I trouble
> > > shoot something, I usually prefer to see all values being used,
> > > filtering them out as needed for the task at hand, that is I would use
> > > 'report-all' anyway if available. But that is just me.]
> > >
> > > That said, I like to take a pragmatic decision. I see two options:
> > >
> > > - Add default 64 to cur-hop-limit to be consistent with the other
> > >   state objects that have a default.
> > >
> > > - Remove all defaults from all state objects because the real value
> > >   of defaults is for config true objects.
> > >
> > > Both work for me. We should decide this quickly. Lada? Martin?
> > > Andy? Anyone else?
> > >
> > >
> > >
> > > I think we need to re-examine the default-stmt and mandatory-stmt
> > > for config=false nodes. IMO they are both broken for the same reason:
> > >
> > > NACM on the server can cause nodes to be silently dropped.
> > > Unless the client is running as "root" (should be the exception)
> > > then it does not know for sure why a leaf was missing in a <get>
> > > reply.  Was it access control or was it the default for a "trim"
> basic-mode
> > > server?
> >
> > But don't config=true nodes have exactly the same problem in a reply to
> <get> or <get-config>?
> >
> >
> > Yes, NACM has the same problem for config=true.  The operator needs
> > to know how NACM is configured -- clients that are not supposed to
> > know about some data node should not care if it is a default or not.
>
> Hmm, maybe the nodes and subtrees blocked by NACM should be signalled
> somehow, e.g., by replacing the denied contents with <no-access/>.
>
>
No -- generally you don't tell an unauthorized user anything about
the data they are not allowed to see.



> >
> > The ambiguity is wrt/ mandatory-stmt. (I think Martin pointed this out.)
> > The mandatory-stmt is 'false' if the default-stmt exists (has to be by
> rule).
> >
> > But if config=false and mandatory=false, the server
> > is not required to return instances of that node in an <rpc-reply>.
> > So the client does not know if the leaf is a 'trim' default or if the
> > server is electing not to include the leaf in the reply.
>
> I agree this needs to be reconsidered and clarified, but we have to decide
> about the defaults in the routing document now. So how about this
> modification of -14:
>
>
OK


> 1. Remove all defaults in state data.
> 2. In config, remove only the default of 'cur-hop-limit'.
>
> Lada
>
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > >
> > > Both mandatory-stmt and default-stmt are unusable for config=false
> > > nodes because of this ambiguity.
> > >
> > > Short answer: remove defaults from all state objects.
> > >
> > >
> > > /js
> > >
> > >
> > >
> > > Andy
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c252c6f1b1f804fa16362d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 23, 2014 at 11:23 AM, Ladislav Lhotka <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 23 May 2014, at 18:11, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Fri, May 23, 2014 at 8:33 AM, Ladislav Lhotka &lt;<a href=3D"mailto=
:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 23 May 2014, at 16:48, Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Fri, May 23, 2014 at 3:09 AM, Juergen Schoenwaelder &lt;<a hre=
f=3D"mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-un=
iversity.de</a>&gt; wrote:<br>
&gt; &gt; On Fri, May 23, 2014 at 11:12:43AM +0200, Ladislav Lhotka wrote:<=
br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On 23 May 2014, at 10:31, Juergen Schoenwaelder &lt;<a href=
=3D"mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jacobs-uni=
versity.de</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Lada,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I have reviewed the changes. A few more nits (sorry) be=
fore I am<br>
&gt; &gt; &gt; &gt; fully happy.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; - On page 21, you have changed the first path but also =
removed hte<br>
&gt; &gt; &gt; &gt; &nbsp;&quot;as state data&quot; phrase. I also note tha=
t it is &#39;routes&#39; not &#39;route&rsquo;.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Yes, you are right.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp;Perhaps this should also provide a more complete =
overview. Looking<br>
&gt; &gt; &gt; &gt; &nbsp;at the v4ur and v6ur models, perhaps it makes sen=
se to list this:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp;OLD<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/rt:routing-state/rt:=
ribs/rt:rib/rt:route<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp;and<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/rt:active-route/rt:o=
utput/rt:route,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp;NEW<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; /rt:routing-state/rt:ribs/rt:rib/r=
t:routes/rt:route<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; /rt:routing/rt:routing-instance/rt=
:routing-protocols/rt:routing-protocol<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The &lsquo;routing-protocol&rsquo; container and its content=
s have to be defined from scratch (see the third bullet) and its configurat=
ion in fact needn&rsquo;t contain any explicit routes. So I think this line=
 shouldn&#39;t be there.<br>

&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; OK. Then just fix the first path.<br>
&gt; &gt;<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; and<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; /rt:active-route/rt:output<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; - Concerning cur-hop-limit, isn&#39;t the right approac=
h to leave the default<br>
&gt; &gt; &gt; &gt; &nbsp;statement in the state tree and to remove the def=
ault from the config<br>
&gt; &gt; &gt; &gt; &nbsp;tree? (See the other thread.)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hmm, I am not sure what to do with this. The other modules o=
nly have the defaults in config. Can other people comment?<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; My understanding is that defaults on config false objects only pr=
ovide<br>
&gt; &gt; an optimization for implementations that support &#39;trim&#39; d=
efaults<br>
&gt; &gt; handling. The question is whether it is worth it. [Once I trouble=
<br>
&gt; &gt; shoot something, I usually prefer to see all values being used,<b=
r>
&gt; &gt; filtering them out as needed for the task at hand, that is I woul=
d use<br>
&gt; &gt; &#39;report-all&#39; anyway if available. But that is just me.]<b=
r>
&gt; &gt;<br>
&gt; &gt; That said, I like to take a pragmatic decision. I see two options=
:<br>
&gt; &gt;<br>
&gt; &gt; - Add default 64 to cur-hop-limit to be consistent with the other=
<br>
&gt; &gt; &nbsp; state objects that have a default.<br>
&gt; &gt;<br>
&gt; &gt; - Remove all defaults from all state objects because the real val=
ue<br>
&gt; &gt; &nbsp; of defaults is for config true objects.<br>
&gt; &gt;<br>
&gt; &gt; Both work for me. We should decide this quickly. Lada? Martin?<br=
>
&gt; &gt; Andy? Anyone else?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I think we need to re-examine the default-stmt and mandatory-stmt=
<br>
&gt; &gt; for config=3Dfalse nodes. IMO they are both broken for the same r=
eason:<br>
&gt; &gt;<br>
&gt; &gt; NACM on the server can cause nodes to be silently dropped.<br>
&gt; &gt; Unless the client is running as &quot;root&quot; (should be the e=
xception)<br>
&gt; &gt; then it does not know for sure why a leaf was missing in a &lt;ge=
t&gt;<br>
&gt; &gt; reply. &nbsp;Was it access control or was it the default for a &q=
uot;trim&quot; basic-mode<br>
&gt; &gt; server?<br>
&gt;<br>
&gt; But don&rsquo;t config=3Dtrue nodes have exactly the same problem in a=
 reply to &lt;get&gt; or &lt;get-config&gt;?<br>
&gt;<br>
&gt;<br>
&gt; Yes, NACM has the same problem for config=3Dtrue. &nbsp;The operator n=
eeds<br>
&gt; to know how NACM is configured -- clients that are not supposed to<br>
&gt; know about some data node should not care if it is a default or not.<b=
r>
<br>
Hmm, maybe the nodes and subtrees blocked by NACM should be signalled someh=
ow, e.g., by replacing the denied contents with &lt;no-access/&gt;.<br>
<br></blockquote><div><br></div><div>No -- generally you don&#39;t tell an =
unauthorized user anything about</div><div>the data they are not allowed to=
 see.</div><div><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt;<br>
&gt; The ambiguity is wrt/ mandatory-stmt. (I think Martin pointed this out=
.)<br>
&gt; The mandatory-stmt is &#39;false&#39; if the default-stmt exists (has =
to be by rule).<br>
&gt;<br>
&gt; But if config=3Dfalse and mandatory=3Dfalse, the server<br>
&gt; is not required to return instances of that node in an &lt;rpc-reply&g=
t;.<br>
&gt; So the client does not know if the leaf is a &#39;trim&#39; default or=
 if the<br>
&gt; server is electing not to include the leaf in the reply.<br>
<br>
I agree this needs to be reconsidered and clarified, but we have to decide =
about the defaults in the routing document now. So how about this modificat=
ion of -14:<br>
<br></blockquote><div><br></div><div>OK</div><div>&nbsp;</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
1. Remove all defaults in state data.<br>
2. In config, remove only the default of &lsquo;cur-hop-limit&rsquo;.<br>
<br>
Lada<br>
<br>
<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Both mandatory-stmt and default-stmt are unusable for config=3Dfa=
lse<br>
&gt; &gt; nodes because of this ambiguity.<br>
&gt; &gt;<br>
&gt; &gt; Short answer: remove defaults from all state objects.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; /js<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Andy<br>
&gt; &gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c252c6f1b1f804fa16362d--


From nobody Fri May 23 12:27:48 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A8D1A02AF for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7x8WAEpirmJH for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:27:46 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E641A0290 for <netmod@ietf.org>; Fri, 23 May 2014 12:27:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0718FD7; Fri, 23 May 2014 21:27:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8LwdBfkZ-91K; Fri, 23 May 2014 21:27:35 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 May 2014 21:27:42 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D8252002C; Fri, 23 May 2014 21:27:42 +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 B65xNYGPQuI5; Fri, 23 May 2014 21:27:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A7CA20017; Fri, 23 May 2014 21:27:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 4B4592CF5464; Fri, 23 May 2014 21:27:40 +0200 (CEST)
Date: Fri, 23 May 2014 21:27:39 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140523192739.GA1081@elstar.local>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_xpfasOjQoaceVyV6Xn5CwTLSZE
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 19:27:47 -0000

On Fri, May 23, 2014 at 08:23:20PM +0200, Ladislav Lhotka wrote:
> 
> So how about this modification of -14:
> 
> 1. Remove all defaults in state data.
> 2. In config, remove only the default of ‘cur-hop-limit’.
> 

Works well for me.

As said before, I personally find the possible optimization for trim
mode not worthwhile and we are better consistent how we do this in our
YANG modules.

/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 nobody Fri May 23 12:40:58 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE71A02B0 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:40:54 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYVE96lHkj5a for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:40:53 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413DA1A0297 for <netmod@ietf.org>; Fri, 23 May 2014 12:40:53 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id 63so8785822qgz.16 for <netmod@ietf.org>; Fri, 23 May 2014 12:40:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=P7BYXHx1U30aHZADBCH2/BdNU4IrDlV+iUV/1UpxDZc=; b=AYfKgu6nZFJSlrkXOXd0Pz5LfYZM+qmLXXXuehuD4y5syaxcjaHbOVLWoRtykkNTvU jTVpT+l0m1UXibriMx8r749w+qNBqYDXPmvqTTYt+xMk9IrFoNQUuqm71P4xPeP2V24s /9WfER/aNkgN07VpTZI1NgymSUCXB7Ce1xb7wGxI7gAmf1a3TBN1998JzL7GA02qtaSi IcPjWq8m8Jvo6uHDbizhN0FR+V/ZpBphU1Z7H+6fgfOkba/osbnDtxjd10Vz/40wzAsH mJMcPfAZnGYyJLB2YxbQX1stZ0+BEQbK7hyYi/lFJIR+tbz2jjzdtgL8CL/Yzh6fckUO f81A==
X-Gm-Message-State: ALoCoQlBDNp57wZYR9V083hqQwwi8duMyYr2a1KKB6ajWLOm1y6tu/Wer4q0fUw34NeEheayh2pa
MIME-Version: 1.0
X-Received: by 10.224.64.132 with SMTP id e4mr10228926qai.16.1400874050663; Fri, 23 May 2014 12:40:50 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 23 May 2014 12:40:50 -0700 (PDT)
In-Reply-To: <20140523170241.GB704@elstar.local>
References: <20140523170241.GB704@elstar.local>
Date: Fri, 23 May 2014 12:40:50 -0700
Message-ID: <CABCOCHT0Xg1AzhkaJjvGNDV9ZSqfkaf4prRNE75KNbdf-61OAw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>,  "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c20e7a2a48ea04fa166816
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/20GDG4bk-X_-YVnbVjBc1D3p0RY
Subject: Re: [netmod] strawman proposal for moving yang 1.1 issues NEW -> OPEN
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 19:40:55 -0000

--001a11c20e7a2a48ea04fa166816
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have no objections to the open issue list.

I would like to propose that clarifications can be proposed at any time
during YANG 1.1. development, as opposed to new features,
which are locked out at some point (very soon).

E.g., add a clarification issue for server behavior for mandatory-stmt
for config=false data nodes.

I don't know what it means for a node to be mandatory
to implement (node part of base module) but if mandatory-stmt=false,
it is optional to return to the client?  Shouldn't the client
be deciding which nodes it wants in the reply?

IMO, mandatory-stmt should be ignored if used in a config=false
data node. The server MUST return every requested node
(modulo NACM) according to the YANG conformance.


Andy



On Fri, May 23, 2014 at 10:02 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> as promised earlier, here is a strawman proposal which of the YANG 1.1
> issues should be moved from NEW to OPEN (which means the issues are
> considered in scope of the YANG 1.1 effort). For the issues list, see:
>
>    http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/
>
> If you believe some of the issues should _not_ be addressed by the
> YANG 1.1 effort, please speak up by the end of May and provide a
> reasoning why you think the issue should not be addressed. Silence
> will be interpreted as agreement to the strawman proposal.
>
>
> |-----+------+----------------------------------------------------------------+-------------------------|
>   | Y01 | OPEN | allow boolean if-feature
>       | new feature             |
>   | Y02 | OPEN | allow must in input, output, and notification
>      | language consistency    |
>   | Y03 | OPEN | allow if-feature in refine
>       | language consistency    |
>   | Y04 | OPEN | accessible tree in xpath in notifs and rpc
>       | language consistency    |
>   | Y05 | OPEN | unprefixed path in top-level typedef
>       | language consistency    |
>   | Y06 | OPEN | escaped characters in double quoted strings
>      | language consistency    |
>   | Y07 | OPEN | do not allow when or if-feature on keys
>      | language consistency    |
>   | Y10 | OPEN | allow restrictions on enumerations
>       | language consistency    |
>   | Y11 | OPEN | allow if-feature on enums
>      | new feature             |
>   | Y12 | OPEN | initialized-by system
>      | new feature             |
>   | Y13 | OPEN | allow multiple inheritance for identities
>      | new feature             |
>   | Y14 | OPEN | clarify the string value for identities when used in
> must/when | language consistency    |
>   | Y16 | OPEN | module advertisement optimization
>      | performance improvement |
>   | Y18 | OPEN | fix "when" expression context node problem
>       | language consistency    |
>   | Y20 | OPEN | new set of built-in XPath functions
>      | new feature             |
>   | Y23 | OPEN | support negative patterns as string restrictions
>       | new feature             |
>   | Y25 | OPEN | make enum numbering purely informative and optional
>      | feature removal         |
>   | Y28 | OPEN | support default values in leaf-lists
>       | new feature             |
>   | Y29 | OPEN | allow choice as a short-hand case
>      | language consistency    |
>   | Y30 | OPEN | allow leafref in union
>       | language consistency    |
>   | Y34 | OPEN | remove/deprecate/replace the 'anyxml' statement
>      | generalization          |
>   | Y35 | OPEN | allow empty in union
>       | language consistency    |
>   | Y41 | OPEN | clarification of "must" in NP-container
>      | language consistency    |
>   | Y42 | OPEN | better model for configuration versus state data is
> needed     |                         |
>   | Y44 | OPEN | add a mechanism to parameterize error-message
>      | new feature             |
>   | Y45 | OPEN | better conformance mechanism
>       | feature improvement     |
>   | Y47 | OPEN | bit name too restrictive
>       | language consistency    |
>   | Y49 | OPEN | clarify nested submodule behavior
>      | language consistency    |
>
> |-----+------+----------------------------------------------------------------+-------------------------|
>
> I hope I got the issue headlines all right. If there is a mismatch,
> the issue number is authoritative.
>
> /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/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a11c20e7a2a48ea04fa166816
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I have no objections to the open is=
sue list.</div><div><br></div><div>I would like to propose that clarificati=
ons can be proposed at any time</div><div>during YANG 1.1. development, as =
opposed to new features,</div>
<div>which are locked out at some point (very soon).</div><div><br></div><d=
iv>E.g., add a clarification issue for server behavior for mandatory-stmt</=
div><div>for config=3Dfalse data nodes.</div><div><br></div><div>I don&#39;=
t know what it means for a node to be mandatory</div>
<div>to implement (node part of base module) but if mandatory-stmt=3Dfalse,=
</div><div>it is optional to return to the client? =A0Shouldn&#39;t the cli=
ent</div><div>be deciding which nodes it wants in the reply?</div><div><br>
</div><div>IMO, mandatory-stmt should be ignored if used in a config=3Dfals=
e</div><div>data node. The server MUST return every requested node</div><di=
v>(modulo NACM) according to the YANG conformance.</div><div><br></div><div=
>
<br></div><div>Andy</div><div><br><div class=3D"gmail_extra"><br><br><div c=
lass=3D"gmail_quote">On Fri, May 23, 2014 at 10:02 AM, Juergen Schoenwaelde=
r <span dir=3D"ltr">&lt;<a href=3D"mailto:j.schoenwaelder@jacobs-university=
.de" target=3D"_blank">j.schoenwaelder@jacobs-university.de</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<br>
as promised earlier, here is a strawman proposal which of the YANG 1.1<br>
issues should be moved from NEW to OPEN (which means the issues are<br>
considered in scope of the YANG 1.1 effort). For the issues list, see:<br>
<br>
=A0 =A0<a href=3D"http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/" target=
=3D"_blank">http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/</a><br>
<br>
If you believe some of the issues should _not_ be addressed by the<br>
YANG 1.1 effort, please speak up by the end of May and provide a<br>
reasoning why you think the issue should not be addressed. Silence<br>
will be interpreted as agreement to the strawman proposal.<br>
<br>
=A0 |-----+------+---------------------------------------------------------=
-------+-------------------------|<br>
=A0 | Y01 | OPEN | allow boolean if-feature =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | new feature =A0 =A0 =A0 =A0 =
=A0 =A0 |<br>
=A0 | Y02 | OPEN | allow must in input, output, and notification =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0| language consistency =A0 =A0|<br>
=A0 | Y03 | OPEN | allow if-feature in refine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =A0|=
<br>
=A0 | Y04 | OPEN | accessible tree in xpath in notifs and rpc =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =A0|<br>
=A0 | Y05 | OPEN | unprefixed path in top-level typedef =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =A0|<br>
=A0 | Y06 | OPEN | escaped characters in double quoted strings =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0| language consistency =A0 =A0|<br>
=A0 | Y07 | OPEN | do not allow when or if-feature on keys =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| language consistency =A0 =A0|<br>
=A0 | Y10 | OPEN | allow restrictions on enumerations =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =A0|<br>
=A0 | Y11 | OPEN | allow if-feature on enums =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| new feature =A0 =A0 =A0 =
=A0 =A0 =A0 |<br>
=A0 | Y12 | OPEN | initialized-by system =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| new feature =A0 =A0 =
=A0 =A0 =A0 =A0 |<br>
=A0 | Y13 | OPEN | allow multiple inheritance for identities =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| new feature =A0 =A0 =A0 =A0 =A0 =A0 |<br>
=A0 | Y14 | OPEN | clarify the string value for identities when used in mus=
t/when | language consistency =A0 =A0|<br>
=A0 | Y16 | OPEN | module advertisement optimization =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| performance improvement |<br>
=A0 | Y18 | OPEN | fix &quot;when&quot; expression context node problem =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =A0|<br>
=A0 | Y20 | OPEN | new set of built-in XPath functions =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| new feature =A0 =A0 =A0 =A0 =A0 =A0 |<=
br>
=A0 | Y23 | OPEN | support negative patterns as string restrictions =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 | new feature =A0 =A0 =A0 =A0 =A0 =A0 |<br>
=A0 | Y25 | OPEN | make enum numbering purely informative and optional =A0 =
=A0 =A0 =A0 =A0 =A0| feature removal =A0 =A0 =A0 =A0 |<br>
=A0 | Y28 | OPEN | support default values in leaf-lists =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | new feature =A0 =A0 =A0 =A0 =A0 =A0 |<br=
>
=A0 | Y29 | OPEN | allow choice as a short-hand case =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| language consistency =A0 =A0|<br>
=A0 | Y30 | OPEN | allow leafref in union =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =
=A0|<br>
=A0 | Y34 | OPEN | remove/deprecate/replace the &#39;anyxml&#39; statement =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| generalization =A0 =A0 =A0 =A0 =A0|<br>
=A0 | Y35 | OPEN | allow empty in union =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0=
 =A0|<br>
=A0 | Y41 | OPEN | clarification of &quot;must&quot; in NP-container =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| language consistency =A0 =A0|<=
br>
=A0 | Y42 | OPEN | better model for configuration versus state data is need=
ed =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<br>
=A0 | Y44 | OPEN | add a mechanism to parameterize error-message =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0| new feature =A0 =A0 =A0 =A0 =A0 =A0 |<br>
=A0 | Y45 | OPEN | better conformance mechanism =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | feature improvement =A0 =A0 |<br=
>
=A0 | Y47 | OPEN | bit name too restrictive =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | language consistency =A0 =A0=
|<br>
=A0 | Y49 | OPEN | clarify nested submodule behavior =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| language consistency =A0 =A0|<br>
=A0 |-----+------+---------------------------------------------------------=
-------+-------------------------|<br>
<br>
I hope I got the issue headlines all right. If there is a mismatch,<br>
the issue number is authoritative.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
/js<br>
<br>
--<br>
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH<br=
>
Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German=
y<br>
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 &lt;<a href=3D"http://www.jacobs-=
university.de/" target=3D"_blank">http://www.jacobs-university.de/</a>&gt;<=
br>
<br>
_______________________________________________<br>
netmod mailing list<br>
<a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/netmod</a><br>
</font></span></blockquote></div><br></div></div></div>

--001a11c20e7a2a48ea04fa166816--


From nobody Fri May 23 12:48:56 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A801A0329 for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuyNi7gJBsCO for <netmod@ietfa.amsl.com>; Fri, 23 May 2014 12:48:47 -0700 (PDT)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCE51A0325 for <netmod@ietf.org>; Fri, 23 May 2014 12:48:47 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id m20so8771511qcx.12 for <netmod@ietf.org>; Fri, 23 May 2014 12:48:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=I1yJ+Hdzv+jQ9Q8ndv/c/tG8EznZq6ix8GrOK7BmVd0=; b=PlE7mVEn5PbSg8xLr8K46ZRy94ZWcCN7tgxs300WQoNzsOa44wz74ei4c9n2pi3afG tQ9w5IsaiI3wW0OxLgVS29XO1LY6GdtWQuHGhFvswIM/VZ7ntxjlTjo4Ksa52doG1mbD X32HOnV9Opll1ZvJ2ulYxi2Ask54DuL7BulzEPaa2Qh4bKcaQprS+l6kVIeT0N6mXFep qlkqVdvmkZFvwf/GN5QaxTUGpKir23Kgylx6em516/Z8zQXlfTrJMrAvHSwpjFgaqr+6 6xnilSm0HdkIFcVf1WHp51bKsPvAIkVHxy/We8mFkNqx7qLcoYUzH3nWYvpoMwaUtdth 2qgQ==
X-Gm-Message-State: ALoCoQkHA4bNvZxxx6UH40kVSxTJZPqhdZWCiGgCvAsAMQHI3h9BUxcss+KipmQCME/rJ+cmxDeg
MIME-Version: 1.0
X-Received: by 10.224.138.3 with SMTP id y3mr10254928qat.78.1400874524990; Fri, 23 May 2014 12:48:44 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 23 May 2014 12:48:44 -0700 (PDT)
In-Reply-To: <20140523192739.GA1081@elstar.local>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <20140523192739.GA1081@elstar.local>
Date: Fri, 23 May 2014 12:48:44 -0700
Message-ID: <CABCOCHTV8mixAYjxLFq9dXrrZAWiO6DRfe2xpEgha3+vxkHBRA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Ladislav Lhotka <lhotka@nic.cz>,  Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b672b447000d404fa168414
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sf2M_xmgAJgqbh8kSFTF301U2-M
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 19:48:48 -0000

--047d7b672b447000d404fa168414
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 23, 2014 at 12:27 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, May 23, 2014 at 08:23:20PM +0200, Ladislav Lhotka wrote:
> >
> > So how about this modification of -14:
> >
> > 1. Remove all defaults in state data.
> > 2. In config, remove only the default of 'cur-hop-limit'.
> >
>
> Works well for me.
>
> As said before, I personally find the possible optimization for trim
> mode not worthwhile and we are better consistent how we do this in our
> YANG modules.
>
>
Agreed.

The thinking at the time RFC 6243 was written was based
on limited experience. One use case I had was a default
for a status knob, so if the status of lots of resources was
polled at once, only the "error" nodes would be returned
(e.g., default is "ok").

Since this RFC is optional, and trim mode is also optional,
we should not use defaults for config=false nodes in standard modules.


> /js
>
>
Andy

--047d7b672b447000d404fa168414
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, May 23, 2014 at 12:27 PM, Juergen Schoenwaelder <span dir=
=3D"ltr">&lt;<a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=
=3D"_blank">j.schoenwaelder@jacobs-university.de</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, May 23, 2014 at 08:23:20PM +0200, La=
dislav Lhotka wrote:<br>
&gt;<br>
&gt; So how about this modification of -14:<br>
&gt;<br>
&gt; 1. Remove all defaults in state data.<br>
&gt; 2. In config, remove only the default of &lsquo;cur-hop-limit&rsquo;.<=
br>
&gt;<br>
<br>
Works well for me.<br>
<br>
As said before, I personally find the possible optimization for trim<br>
mode not worthwhile and we are better consistent how we do this in our<br>
YANG modules.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>Agreed.</div><div><br></div><div>The thinking at the=
 time RFC 6243 was written was based</div><div>on limited experience. One u=
se case I had was a default</div>
<div>for a status knob, so if the status of lots of resources was</div><div=
>polled at once, only the &quot;error&quot; nodes would be returned</div><d=
iv>(e.g., default is &quot;ok&quot;).</div><div><br></div><div>Since this R=
FC is optional, and trim mode is also optional,</div>
<div>we should not use defaults for config=3Dfalse nodes in standard module=
s.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEn=
Zb"><font color=3D"#888888">
/js<br>
<br></font></span></blockquote><div><br></div><div>Andy</div><div><br></div=
></div></div></div>

--047d7b672b447000d404fa168414--


From nobody Sun May 25 10:56:42 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044251A033A; Sun, 25 May 2014 10:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzLZRx_VeilO; Sun, 25 May 2014 10:56:37 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFE21A0332; Sun, 25 May 2014 10:56:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140525175637.11805.57364.idtracker@ietfa.amsl.com>
Date: Sun, 25 May 2014 10:56:37 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LETOdiJsExcGggfyVUguMCHxNuE
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 17:56:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : A YANG Data Model for Routing Management
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-routing-cfg-15.txt
	Pages           : 95
	Date            : 2014-05-25

Abstract:
   This document contains a specification of three YANG modules.
   Together they form the core routing data model which serves as a
   framework for configuring and managing a routing subsystem.  It is
   expected that these modules will be augmented by additional YANG
   modules defining data models for individual routing protocols and
   other related functions.  The core routing data model provides common
   building blocks for such extensions - routing instances, routes,
   routing information bases (RIB), routing protocols and route filters.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Sun May 25 11:12:20 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B98F1A0351 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 11:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGdnx4uVJ-my for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 11:12:15 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC141A035A for <netmod@ietf.org>; Sun, 25 May 2014 11:12:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 444025406C1; Sun, 25 May 2014 20:12:01 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttpODCSjgP17; Sun, 25 May 2014 20:11:56 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5CFB554026C; Sun, 25 May 2014 20:11:56 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, "netmod\@ietf.org" <netmod@ietf.org>
In-Reply-To: <CABCOCHTV8mixAYjxLFq9dXrrZAWiO6DRfe2xpEgha3+vxkHBRA@mail.gmail.com>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <20140523192739.GA1081@elstar.local> <CABCOCHTV8mixAYjxLFq9dXrrZAWiO6DRfe2xpEgha3+vxkHBRA@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Sun, 25 May 2014 20:11:55 +0200
Message-ID: <m2mwe5d8yc.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CywEA61b2A7v2ElmhILtF1mfIBI
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 18:12:17 -0000

> On Fri, May 23, 2014 at 12:27 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Fri, May 23, 2014 at 08:23:20PM +0200, Ladislav Lhotka wrote:
>> >
>> > So how about this modification of -14:
>> >
>> > 1. Remove all defaults in state data.
>> > 2. In config, remove only the default of 'cur-hop-limit'.
>> >
>>
>> Works well for me.
>>
>> As said before, I personally find the possible optimization for trim
>> mode not worthwhile and we are better consistent how we do this in our
>> YANG modules.
>>
>>
> Agreed.

OK, see revision -15.

Lada

>
> The thinking at the time RFC 6243 was written was based
> on limited experience. One use case I had was a default
> for a status knob, so if the status of lots of resources was
> polled at once, only the "error" nodes would be returned
> (e.g., default is "ok").
>
> Since this RFC is optional, and trim mode is also optional,
> we should not use defaults for config=false nodes in standard modules.
>
>
>> /js
>>
>>
> Andy


From nobody Sun May 25 11:24:18 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834451A0341 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 11:24:16 -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=[BAYES_20=-0.001, J_CHICKENPOX_64=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj4gkvLjqwES for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 11:24:16 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0841A0338 for <netmod@ietf.org>; Sun, 25 May 2014 11:24:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 246045406C1; Sun, 25 May 2014 20:24:12 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnxlCR4LuWDK; Sun, 25 May 2014 20:24:08 +0200 (CEST)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 85F3154026C; Sun, 25 May 2014 20:24:07 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>
In-Reply-To: <CABCOCHQxGuFw27069eu6AECPB8qNNi2=ikGHQK1OVbC7=-W03g@mail.gmail.com>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <CABCOCHQxGuFw27069eu6AECPB8qNNi2=ikGHQK1OVbC7=-W03g@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Sun, 25 May 2014 20:24:06 +0200
Message-ID: <m2k399d8e1.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/upANgKL67dVjleduk6_ixziQZPA
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 18:24:16 -0000

Andy Bierman <andy@yumaworks.com> writes:
>> >
>> > Yes, NACM has the same problem for config=true.  The operator needs
>> > to know how NACM is configured -- clients that are not supposed to
>> > know about some data node should not care if it is a default or not.
>>
>> Hmm, maybe the nodes and subtrees blocked by NACM should be signalled
>> somehow, e.g., by replacing the denied contents with <no-access/>.
>>
>>
> No -- generally you don't tell an unauthorized user anything about
> the data they are not allowed to see.
>

I understand that firewalls use DROP rather than REJECT in order to avoid DoS attacks. For NACM, it doesn't make much sense to me because the client already has an open session and must have authenticated himself to the server. In filesystems and on the web, "access denied" replies are normal. 

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Sun May 25 11:57:04 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669421A035F for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 11:57:03 -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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZp2Q-2ymqIV for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 11:57:02 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5D91A01F7 for <netmod@ietf.org>; Sun, 25 May 2014 11:57:02 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id 63so10961804qgz.16 for <netmod@ietf.org>; Sun, 25 May 2014 11:56:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S1yZ6u5wPvIhwAhb60KZek46Vqt2sCAiln6wwgTLtzg=; b=QbYWPTWeeNpxEjx8CxUlTerGCjcC3bK6a6GQZ9lbE4cotq73pwltSIc9LBFISANlCW WjJrUnABWKtjgY4LtP6WWTdus9s9M5O+t1H22mMgSmcbcuQxieVxkwssX5CG94hmdIxu f+VI0O+BpmIa1tRDtJat4QZ9tb483OFL6y7p4rKpmgEeMnnNMPwpaeUjTftbEXJJgDSi TFrUHlVXU+2nvW7YiSIUO/vFTdjdbUJkv3lKGThGq1day7aOnkq/3sMeYx5nAcd7BQzn x0XuIiK7Kdut55gI0QGfQo8Pk0CtqrJ7eLIcF4hv/q85Zr74YPYusyoN5UVqKOa1jbYT paxA==
X-Gm-Message-State: ALoCoQlgj/YSgkh1O3h3Qyw5GessrSR6vLKDvBnyTc+HjlEO2txQDndKn4cIw3a/MY79p3Gld1ZW
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr24838859qgy.34.1401044219407; Sun, 25 May 2014 11:56:59 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Sun, 25 May 2014 11:56:59 -0700 (PDT)
In-Reply-To: <m2k399d8e1.fsf@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <CABCOCHQxGuFw27069eu6AECPB8qNNi2=ikGHQK1OVbC7=-W03g@mail.gmail.com> <m2k399d8e1.fsf@nic.cz>
Date: Sun, 25 May 2014 11:56:59 -0700
Message-ID: <CABCOCHQhiEz9nVW7AuCXkP1Axo-GMvM8EhCaCFUzYHvbx1eZOQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c126ba03621e04fa3e07fa
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HDTcxHA4YZ-pd25DBie0F9ZJ2jA
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 18:57:03 -0000

--001a11c126ba03621e04fa3e07fa
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 25, 2014 at 11:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Andy Bierman <andy@yumaworks.com> writes:
> >> >
> >> > Yes, NACM has the same problem for config=true.  The operator needs
> >> > to know how NACM is configured -- clients that are not supposed to
> >> > know about some data node should not care if it is a default or not.
> >>
> >> Hmm, maybe the nodes and subtrees blocked by NACM should be signalled
> >> somehow, e.g., by replacing the denied contents with <no-access/>.
> >>
> >>
> > No -- generally you don't tell an unauthorized user anything about
> > the data they are not allowed to see.
> >
>
> I understand that firewalls use DROP rather than REJECT in order to avoid
> DoS attacks. For NACM, it doesn't make much sense to me because the client
> already has an open session and must have authenticated himself to the
> server. In filesystems and on the web, "access denied" replies are normal.
>
>
That is not how NACM is defined.
I don't see any reason to redo the RFC.
The server sends 'access-denied' for RPC and edit authorization failures.
The instances and contents of unauthorized data are not disclosed.
NACM interprets a <get> or <get-config> as "retrieve the data I am
authorized to view".


Lada
>
>
Andy


> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--001a11c126ba03621e04fa3e07fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, May 25, 2014 at 11:24 AM, Ladislav Lhotka <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Andy Bierman &lt;<a href=3D"mailto:andy@yuma=
works.com">andy@yumaworks.com</a>&gt; writes:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes, NACM has the same problem for config=3Dtrue. =A0The oper=
ator needs<br>
&gt;&gt; &gt; to know how NACM is configured -- clients that are not suppos=
ed to<br>
&gt;&gt; &gt; know about some data node should not care if it is a default =
or not.<br>
&gt;&gt;<br>
&gt;&gt; Hmm, maybe the nodes and subtrees blocked by NACM should be signal=
led<br>
&gt;&gt; somehow, e.g., by replacing the denied contents with &lt;no-access=
/&gt;.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; No -- generally you don&#39;t tell an unauthorized user anything about=
<br>
&gt; the data they are not allowed to see.<br>
&gt;<br>
<br>
I understand that firewalls use DROP rather than REJECT in order to avoid D=
oS attacks. For NACM, it doesn&#39;t make much sense to me because the clie=
nt already has an open session and must have authenticated himself to the s=
erver. In filesystems and on the web, &quot;access denied&quot; replies are=
 normal.<br>

<br></blockquote><div><br></div><div>That is not how NACM is defined.</div>=
<div>I don&#39;t see any reason to redo the RFC.</div><div>The server sends=
 &#39;access-denied&#39; for RPC and edit authorization failures.</div>
<div>The instances and contents of unauthorized data are not disclosed.</di=
v><div>NACM interprets a &lt;get&gt; or &lt;get-config&gt; as &quot;retriev=
e the data I am</div><div>authorized to view&quot;.</div><div><br></div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Lada<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>Andy</div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span class=3D"HOEnZb"><font color=3D"#888888">
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
</font></span></blockquote></div><br></div></div>

--001a11c126ba03621e04fa3e07fa--


From nobody Sun May 25 12:04:57 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3151A0362 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 12:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.197
X-Spam-Level: *
X-Spam-Status: No, score=1.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7uNdAeFlVNy for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 12:04:55 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB111A035F for <netmod@ietf.org>; Sun, 25 May 2014 12:04:55 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7016B13FA15; Sun, 25 May 2014 21:04:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401044691; bh=pmM1+6reNrJnvkinLVVvA6p4KhVSfZZdhpzOLbz1eng=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QsPi9fOrOKhi4Mc0Law/i8WJm591jjsnVk23PVQh8mPDhsfR7xMJO9ewxfZv+PzQ+ 793xxQP6lEB/unDD4X3PRA++Q1EqkK1Wuqj3lmMXR9FL5b5SZYfvNKLHQY0Cy8y2Ek Rhe5yt00sGkWQ3cy3LK7xFzxpCu2Jd7pChtLCX5o=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHQhiEz9nVW7AuCXkP1Axo-GMvM8EhCaCFUzYHvbx1eZOQ@mail.gmail.com>
Date: Sun, 25 May 2014 21:04:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BB8E62E-8B08-44CB-995C-9B8321D8B48A@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <CABCOCHQxGuFw27069eu6AECPB8qNNi2=ikGHQK1OVbC7=-W03g@mail.gmail.com> <m2k399d8e1.fsf@nic.cz> <CABCOCHQhiEz9nVW7AuCXkP1Axo-GMvM8EhCaCFUzYHvbx1eZOQ@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o3-43QjRuGYSUyeXbPp_hkaZw74
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 19:04:56 -0000

On 25 May 2014, at 20:56, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Sun, May 25, 2014 at 11:24 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> Andy Bierman <andy@yumaworks.com> writes:
> >> >
> >> > Yes, NACM has the same problem for config=3Dtrue.  The operator =
needs
> >> > to know how NACM is configured -- clients that are not supposed =
to
> >> > know about some data node should not care if it is a default or =
not.
> >>
> >> Hmm, maybe the nodes and subtrees blocked by NACM should be =
signalled
> >> somehow, e.g., by replacing the denied contents with <no-access/>.
> >>
> >>
> > No -- generally you don't tell an unauthorized user anything about
> > the data they are not allowed to see.
> >
>=20
> I understand that firewalls use DROP rather than REJECT in order to =
avoid DoS attacks. For NACM, it doesn't make much sense to me because =
the client already has an open session and must have authenticated =
himself to the server. In filesystems and on the web, "access denied" =
replies are normal.
>=20
>=20
> That is not how NACM is defined.
> I don't see any reason to redo the RFC.

Then don=92t complain about not being able to distinguish a trimmed =
default from a denied node. :-)

Lada

> The server sends 'access-denied' for RPC and edit authorization =
failures.
> The instances and contents of unauthorized data are not disclosed.
> NACM interprets a <get> or <get-config> as "retrieve the data I am
> authorized to view".
>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sun May 25 12:21:00 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBD51A0370 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 12:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.121
X-Spam-Level: *
X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yxDdNd0sRJN for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 12:20:55 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2B81A0368 for <netmod@ietf.org>; Sun, 25 May 2014 12:20:55 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id e16so10900700qcx.41 for <netmod@ietf.org>; Sun, 25 May 2014 12:20:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aJwbA0nKDoYSn9jp5UEWFMhYKGhJpRKxIqL9UF71Kpo=; b=L2VVqAw8RfjI3yX3D+ZKSkmxA0mIyFYQrmp4HoyjC8QLVNKz1xlVJ5wj8ArRwYx71o 5YsMru2hzh+tnXXjT30rsMgCR/C5kNUuAdhhCotYZP5BxFxlBAk5PEz7HH7OAeDcp//3 zGjAwnoguNCT3Mwl4bs1SCh+2j1Tpgde/VeRlX0cGr/lRcXQ8JcWO2gogYkjBn0r6uwx 6eS7x+h3ljnoJ3D0cvDKLpmB3ZvDzRDwiGc6fWWGi4KnDtsfJOuyNLm/BybTiN7EfKSO 3uGGHfeGwPlG91kU6WG6xUmiLCIVOAYVLRkt9kYbq1StR+9inLw8xvYqPqBKqnJCzkix fCUQ==
X-Gm-Message-State: ALoCoQnI2wjv3xRru3xPhmGKfNV8zx0q6OIiW3eQrERRq1yhkRj36zwse4yw/8sJfdAixvyt7Hfz
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr24969422qgy.34.1401045652708; Sun, 25 May 2014 12:20:52 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Sun, 25 May 2014 12:20:52 -0700 (PDT)
In-Reply-To: <4BB8E62E-8B08-44CB-995C-9B8321D8B48A@nic.cz>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <CABCOCHQxGuFw27069eu6AECPB8qNNi2=ikGHQK1OVbC7=-W03g@mail.gmail.com> <m2k399d8e1.fsf@nic.cz> <CABCOCHQhiEz9nVW7AuCXkP1Axo-GMvM8EhCaCFUzYHvbx1eZOQ@mail.gmail.com> <4BB8E62E-8B08-44CB-995C-9B8321D8B48A@nic.cz>
Date: Sun, 25 May 2014 12:20:52 -0700
Message-ID: <CABCOCHRWYphxv01=tBDD+spW=S-2u5g6L+gFgnahTG_N4X4pWg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c126ba71a3cf04fa3e5c2f
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cmqyd2t4BWFyIH-zJHGyuJVTAsE
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 19:20:57 -0000

--001a11c126ba71a3cf04fa3e5c2f
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 25, 2014 at 12:04 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 25 May 2014, at 20:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Sun, May 25, 2014 at 11:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaworks.com> writes:
> > >> >
> > >> > Yes, NACM has the same problem for config=true.  The operator needs
> > >> > to know how NACM is configured -- clients that are not supposed to
> > >> > know about some data node should not care if it is a default or not.
> > >>
> > >> Hmm, maybe the nodes and subtrees blocked by NACM should be signalled
> > >> somehow, e.g., by replacing the denied contents with <no-access/>.
> > >>
> > >>
> > > No -- generally you don't tell an unauthorized user anything about
> > > the data they are not allowed to see.
> > >
> >
> > I understand that firewalls use DROP rather than REJECT in order to
> avoid DoS attacks. For NACM, it doesn't make much sense to me because the
> client already has an open session and must have authenticated himself to
> the server. In filesystems and on the web, "access denied" replies are
> normal.
> >
> >
> > That is not how NACM is defined.
> > I don't see any reason to redo the RFC.
>
> Then don't complain about not being able to distinguish a trimmed default
> from a denied node. :-)
>
>
I'm just pointing out that a client developer should think twice
before writing code that depends on 'trim' mode suppression of default
config=false leafs.


> Lada
>

Andy


>
> > The server sends 'access-denied' for RPC and edit authorization failures.
> > The instances and contents of unauthorized data are not disclosed.
> > NACM interprets a <get> or <get-config> as "retrieve the data I am
> > authorized to view".
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c126ba71a3cf04fa3e5c2f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, May 25, 2014 at 12:04 PM, Ladislav Lhotka <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 25 May 2014, at 20:56, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, May 25, 2014 at 11:24 AM, Ladislav Lhotka &lt;<a href=3D"mailt=
o:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt; Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.=
com</a>&gt; writes:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Yes, NACM has the same problem for config=3Dtrue. &nbsp;=
The operator needs<br>
&gt; &gt;&gt; &gt; to know how NACM is configured -- clients that are not s=
upposed to<br>
&gt; &gt;&gt; &gt; know about some data node should not care if it is a def=
ault or not.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Hmm, maybe the nodes and subtrees blocked by NACM should be s=
ignalled<br>
&gt; &gt;&gt; somehow, e.g., by replacing the denied contents with &lt;no-a=
ccess/&gt;.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt; No -- generally you don&#39;t tell an unauthorized user anything =
about<br>
&gt; &gt; the data they are not allowed to see.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I understand that firewalls use DROP rather than REJECT in order to av=
oid DoS attacks. For NACM, it doesn&#39;t make much sense to me because the=
 client already has an open session and must have authenticated himself to =
the server. In filesystems and on the web, &quot;access denied&quot; replie=
s are normal.<br>

&gt;<br>
&gt;<br>
&gt; That is not how NACM is defined.<br>
&gt; I don&#39;t see any reason to redo the RFC.<br>
<br>
Then don&rsquo;t complain about not being able to distinguish a trimmed def=
ault from a denied node. :-)<br>
<br></blockquote><div><br></div><div>I&#39;m just pointing out that a clien=
t developer should think twice</div><div>before writing code that depends o=
n &#39;trim&#39; mode suppression of default</div><div>config=3Dfalse leafs=
.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
Lada<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
&gt; The server sends &#39;access-denied&#39; for RPC and edit authorizatio=
n failures.<br>
&gt; The instances and contents of unauthorized data are not disclosed.<br>
&gt; NACM interprets a &lt;get&gt; or &lt;get-config&gt; as &quot;retrieve =
the data I am<br>
&gt; authorized to view&quot;.<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c126ba71a3cf04fa3e5c2f--


From nobody Sun May 25 18:56:06 2014
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEEF1A0420 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 18:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqxvKoXTzB3t for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 18:56:02 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 043C71A041F for <netmod@ietf.org>; Sun, 25 May 2014 18:56:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Higus2ThFke3mrA1vfsdg5ZVCPgZVSSNKhk55IISIepY48/YCXIavG8rNvSUx89V; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Wok8s-0004UT-LF for netmod@ietf.org; Sun, 25 May 2014 21:55:58 -0400
Received: from 76.254.53.37 by webmail.earthlink.net with HTTP; Sun, 25 May 2014 21:55:58 -0400
Message-ID: <18124755.1401069358447.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Date: Sun, 25 May 2014 18:55:58 -0700 (GMT-07:00)
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd817b31b302c9737f1c52e049096fd5e562350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.40
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/m1wYZc5ewXGEcUkCJMwhDHc_6AA
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 01:56:03 -0000

Hi -

>From: Ladislav Lhotka <lhotka@nic.cz>
>Sent: May 25, 2014 11:24 AM
>To: Andy Bierman <andy@yumaworks.com>
>Cc: "netmod@ietf.org" <netmod@ietf.org>
>Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
...
>I understand that firewalls use DROP rather than REJECT in
>order to avoid DoS attacks. For NACM, it doesn't make much
>sense to me because the client already has an open session
>and must have authenticated himself to the server. In
>filesystems and on the web, "access denied" replies are normal. 

The concern isn't about mitigating DoS.

The concern is that "access denied" leaks information.
For example, it could allow a relatively unprivileged
person to discover whether a system is used by a target,
whether a system has vulnerable hardware or software
installed on it, or whether high-value information is
present that would warrant a physical or social engineering
attack.  The authentication of a user doesn't mean they
can be completely trusted; it only means they should be
trusted no more than their access permissions allow.

Even in the case of HTTP, RFC 2616 section 10.4.4 on
"403 Forbidden" specifies that "[i]f the server does
not wish to make this information available to the client,
the status code 404 (Not Found) can be used instead."
That's also the motivation for disabling directory
listings on websites.

Randy


From nobody Sun May 25 21:36:14 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45701A0454 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 21:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR7GHvr8SCJI for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 21:36:10 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2ED21A01F4 for <netmod@ietf.org>; Sun, 25 May 2014 21:36:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 057675403AA; Mon, 26 May 2014 06:36:05 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCO6cXzNpCWQ; Mon, 26 May 2014 06:35:59 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 24CE4540331; Mon, 26 May 2014 06:35:58 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
In-Reply-To: <18124755.1401069358447.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <18124755.1401069358447.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 26 May 2014 06:35:58 +0200
Message-ID: <m2tx8ddump.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Yacvx4h2tr7meDM2D5gRcv7jXNg
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 04:36:12 -0000

Randy Presuhn <randy_presuhn@mindspring.com> writes:

> Hi -
>
>>From: Ladislav Lhotka <lhotka@nic.cz>
>>Sent: May 25, 2014 11:24 AM
>>To: Andy Bierman <andy@yumaworks.com>
>>Cc: "netmod@ietf.org" <netmod@ietf.org>
>>Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> ...
>>I understand that firewalls use DROP rather than REJECT in
>>order to avoid DoS attacks. For NACM, it doesn't make much
>>sense to me because the client already has an open session
>>and must have authenticated himself to the server. In
>>filesystems and on the web, "access denied" replies are normal. 
>
> The concern isn't about mitigating DoS.
>
> The concern is that "access denied" leaks information.
> For example, it could allow a relatively unprivileged
> person to discover whether a system is used by a target,
> whether a system has vulnerable hardware or software
> installed on it, or whether high-value information is
> present that would warrant a physical or social engineering
> attack.  The authentication of a user doesn't mean they
> can be completely trusted; it only means they should be
> trusted no more than their access permissions allow.

I still don't get it. The client had received the server's hello message so he knows the complete data model. Then, in my view, not receiving a node (subtree) is semantically equivalent to receiving it with the contents of <no-access/>.

In your example, a client could receive something like

<sys:platform>
  <nacm:no-access/>
</sys:platform>

I don't see how this helps an attacker compared to the case when <sys:platform> is not present.


>
> Even in the case of HTTP, RFC 2616 section 10.4.4 on
> "403 Forbidden" specifies that "[i]f the server does
> not wish to make this information available to the client,
> the status code 404 (Not Found) can be used instead."
> That's also the motivation for disabling directory
> listings on websites.

This doesn't work for NETCONF/YANG exactly because the server reveals its full data model. It would make sense only if the server could suppress advertising parts of the data model or features.

Lada

>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Sun May 25 23:09:01 2014
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBE11A0492 for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 23:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW3MoGYcRFfE for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 23:08:56 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id BEDD31A048A for <netmod@ietf.org>; Sun, 25 May 2014 23:08:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=c/aBTn1sDWox/ISlXUWHJh/7RV02+DEOUeUkiWaCoChJlOrj2JD+res6UUYimGfP; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Woo5c-0007yA-Jm for netmod@ietf.org; Mon, 26 May 2014 02:08:52 -0400
Received: from 76.254.53.37 by webmail.earthlink.net with HTTP; Mon, 26 May 2014 02:08:52 -0400
Message-ID: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Date: Sun, 25 May 2014 23:08:52 -0700 (GMT-07:00)
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd814f74473679b3ebea696377a2c797f8be350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.40
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-K4OT5MTO7pGQMgfYjmjuAbS5yw
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 06:08:57 -0000

Hi -

>From: Ladislav Lhotka <lhotka@nic.cz>
>Sent: May 25, 2014 9:35 PM
>To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
>Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
...
>I still don't get it. The client had received the server's
>hello message so he knows the complete data model. Then, in
>my view, not receiving a node (subtree) is semantically
>equivalent to receiving it with the contents of <no-access/>.

No, the two are not semantically equivalent.
The server's hello message reveals the sorts
of things that are *potentially* present.
It doesn't identify all the instances.

So, for example, the hello message might tell
me that a system contains "jewels".  The hello
message does not tell me *which* jewels might
be there, but "access denied" responses allow
me to probe to see whether some jewels named
"crown" or "ER" are present, even if I lack
the authority to examine them.

>In your example, a client could receive something like
>
><sys:platform>
>  <nacm:no-access/>
></sys:platform>
>
>I don't see how this helps an attacker compared to the case when <sys:platform> is not present.

It's much more interesting in cases where multiple instances
of a resource may be present, and some instances are more
interesting than others.

>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
>> "403 Forbidden" specifies that "[i]f the server does
>> not wish to make this information available to the client,
>> the status code 404 (Not Found) can be used instead."
>> That's also the motivation for disabling directory
>> listings on websites.
>
>This doesn't work for NETCONF/YANG exactly because the
>server reveals its full data model. It would make sense
>only if the server could suppress advertising parts of the
>data model or features.

I agree that the hello unnecessarily exposes information,
but that risk is mitigated to some extent by the fact
that hello only says what a system is capable of supporting,
and doesn't inform the attacker what is actually present
nor does it enumerate the instances.

Randy


From nobody Sun May 25 23:26:28 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9A1A023D for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 23:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SN-oHm0hN9a for <netmod@ietfa.amsl.com>; Sun, 25 May 2014 23:26:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934981A022B for <netmod@ietf.org>; Sun, 25 May 2014 23:26:18 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9417213F871; Mon, 26 May 2014 08:26:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401085574; bh=HMRaAfSwCepqSbRSDHLDag75sDGCB4frt72lQrIO7aw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pGR9D/WusSU6sHGDDDWPy0jGyj4dd1FU7qURCVfqrOGZALjGRCtusoZ83sYjCSRCv BqiffF7fdunV2d+AByCWTrAfNr1qIGg20zj4plC4a5x9rGwATRoY/prRuBGT60/ejZ iiGrJjmlnPXlRe1M0ELGXl+HdKvW5NO53rWVmFrM=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Date: Mon, 26 May 2014 08:26:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E50755E-3C81-4609-B3BB-891D7F648F70@nic.cz>
References: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
To: Randy Presuhn <randy_presuhn@mindspring.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jVPEM5X4ztfdKoxPoCOahLzWfwg
Cc: netmod@ietf.org
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 06:26:20 -0000

On 26 May 2014, at 08:08, Randy Presuhn <randy_presuhn@mindspring.com> =
wrote:

> Hi -
>=20
>> From: Ladislav Lhotka <lhotka@nic.cz>
>> Sent: May 25, 2014 9:35 PM
>> To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
>> Subject: Re: [netmod] trim vs. NACM [WAS: =
draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> ...
>> I still don't get it. The client had received the server's
>> hello message so he knows the complete data model. Then, in
>> my view, not receiving a node (subtree) is semantically
>> equivalent to receiving it with the contents of <no-access/>.
>=20
> No, the two are not semantically equivalent.
> The server's hello message reveals the sorts
> of things that are *potentially* present.
> It doesn't identify all the instances.
>=20
> So, for example, the hello message might tell
> me that a system contains "jewels".  The hello
> message does not tell me *which* jewels might
> be there, but "access denied" responses allow
> me to probe to see whether some jewels named
> "crown" or "ER" are present, even if I lack
> the authority to examine them.

If a user has no read access to a list node, say =93jewel=94, he should =
of course always receive the same data, no matter what the number of =
list entries is (even zero):

<jewel>
  <nacm:no-access/>
</jewel>

This gives no extra information to an attacker but still provides quite =
a useful clue to regular users.

Lada


>=20
>> In your example, a client could receive something like
>>=20
>> <sys:platform>
>> <nacm:no-access/>
>> </sys:platform>
>>=20
>> I don't see how this helps an attacker compared to the case when =
<sys:platform> is not present.
>=20
> It's much more interesting in cases where multiple instances
> of a resource may be present, and some instances are more
> interesting than others.
>=20
>>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
>>> "403 Forbidden" specifies that "[i]f the server does
>>> not wish to make this information available to the client,
>>> the status code 404 (Not Found) can be used instead."
>>> That's also the motivation for disabling directory
>>> listings on websites.
>>=20
>> This doesn't work for NETCONF/YANG exactly because the
>> server reveals its full data model. It would make sense
>> only if the server could suppress advertising parts of the
>> data model or features.
>=20
> I agree that the hello unnecessarily exposes information,
> but that risk is mitigated to some extent by the fact
> that hello only says what a system is capable of supporting,
> and doesn't inform the attacker what is actually present
> nor does it enumerate the instances.
>=20
> Randy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May 26 09:21:51 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114621A01C9 for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MDW1BBtK4JH for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:21:48 -0700 (PDT)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14711A01C0 for <netmod@ietf.org>; Mon, 26 May 2014 09:21:47 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so12463539qgf.35 for <netmod@ietf.org>; Mon, 26 May 2014 09:21:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9hnLZpBZbj36wzj039BAnDtGz1vY0m4zATeCsz5wrAo=; b=Y+72+sLZJf1ZBSpzngtNDBZvXcc+OAyYYZWAyDGGSt4BXNuDz1995D+MQ922YQ1hK6 S4kFA3cttB7uv0YYX6+jMvrDUzN9S9orMHZziF0g7zcSV7bZ04j53gO1YkJeJlUkXdAW EgSHy4pR0ukCIQ5toVn/t2ddcbjYOlvEFdD7OgXMStRcWDAqK5D5quRMvfXnrAewxcoj rd9Y37gAUZ+WpQhrzeasgNuGk5j4sYZ9p4pa8scx4+0G7NLNPAgduFUWNSBhluI/Ecdz bZmd/UIyUwEBY307m8VO5GU8Pm/2r337L4BXwyLqGuxEo0l+0xL/zTKjKz/ha1RpE55g kXiw==
X-Gm-Message-State: ALoCoQljfBaXWfKG0EgL577BSHtkU4m5MUPHAvAz8+9ILaaFl7HXHzpfsFt78VuIo+9pxG0OuTIE
MIME-Version: 1.0
X-Received: by 10.140.104.204 with SMTP id a70mr11929483qgf.91.1401121304686;  Mon, 26 May 2014 09:21:44 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Mon, 26 May 2014 09:21:44 -0700 (PDT)
In-Reply-To: <9E50755E-3C81-4609-B3BB-891D7F648F70@nic.cz>
References: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <9E50755E-3C81-4609-B3BB-891D7F648F70@nic.cz>
Date: Mon, 26 May 2014 09:21:44 -0700
Message-ID: <CABCOCHSgsGBE=NFfULYcfS5yRcfuqkYvRdwNuLMvGTUc5uBLzg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a1134f42aa7665504fa4ff960
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FAOrvAeRZgPFVJeA5D3i6s9mvlg
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 16:21:50 -0000

--001a1134f42aa7665504fa4ff960
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 26 May 2014, at 08:08, Randy Presuhn <randy_presuhn@mindspring.com>
> wrote:
>
> > Hi -
> >
> >> From: Ladislav Lhotka <lhotka@nic.cz>
> >> Sent: May 25, 2014 9:35 PM
> >> To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
> >> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> > ...
> >> I still don't get it. The client had received the server's
> >> hello message so he knows the complete data model. Then, in
> >> my view, not receiving a node (subtree) is semantically
> >> equivalent to receiving it with the contents of <no-access/>.
> >
> > No, the two are not semantically equivalent.
> > The server's hello message reveals the sorts
> > of things that are *potentially* present.
> > It doesn't identify all the instances.
> >
> > So, for example, the hello message might tell
> > me that a system contains "jewels".  The hello
> > message does not tell me *which* jewels might
> > be there, but "access denied" responses allow
> > me to probe to see whether some jewels named
> > "crown" or "ER" are present, even if I lack
> > the authority to examine them.
>
> If a user has no read access to a list node, say "jewel", he should of
> course always receive the same data, no matter what the number of list
> entries is (even zero):
>
> <jewel>
>   <nacm:no-access/>
> </jewel>
>
> This gives no extra information to an attacker but still provides quite a
> useful clue to regular users.
>


It tells an unauthorized user that the data they are trying to hack does
in fact exist on the device.  That is disclosure of unauthorized
information.



>
> Lada
>

Andy


>
>
> >
> >> In your example, a client could receive something like
> >>
> >> <sys:platform>
> >> <nacm:no-access/>
> >> </sys:platform>
> >>
> >> I don't see how this helps an attacker compared to the case when
> <sys:platform> is not present.
> >
> > It's much more interesting in cases where multiple instances
> > of a resource may be present, and some instances are more
> > interesting than others.
> >
> >>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
> >>> "403 Forbidden" specifies that "[i]f the server does
> >>> not wish to make this information available to the client,
> >>> the status code 404 (Not Found) can be used instead."
> >>> That's also the motivation for disabling directory
> >>> listings on websites.
> >>
> >> This doesn't work for NETCONF/YANG exactly because the
> >> server reveals its full data model. It would make sense
> >> only if the server could suppress advertising parts of the
> >> data model or features.
> >
> > I agree that the hello unnecessarily exposes information,
> > but that risk is mitigated to some extent by the fact
> > that hello only says what a system is capable of supporting,
> > and doesn't inform the attacker what is actually present
> > nor does it enumerate the instances.
> >
> > Randy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a1134f42aa7665504fa4ff960
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka <span dir="ltr">&lt;<a href="mailto:lhotka@nic.cz" target="_blank">lhotka@nic.cz</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 26 May 2014, at 08:08, Randy Presuhn &lt;<a href="mailto:randy_presuhn@mindspring.com">randy_presuhn@mindspring.com</a>&gt; wrote:<br>
<br>
&gt; Hi -<br>
&gt;<br>
&gt;&gt; From: Ladislav Lhotka &lt;<a href="mailto:lhotka@nic.cz">lhotka@nic.cz</a>&gt;<br>
&gt;&gt; Sent: May 25, 2014 9:35 PM<br>
&gt;&gt; To: Randy Presuhn &lt;<a href="mailto:randy_presuhn@mindspring.com">randy_presuhn@mindspring.com</a>&gt;, <a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt;&gt; Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]<br>
&gt; ...<br>
&gt;&gt; I still don&#39;t get it. The client had received the server&#39;s<br>
&gt;&gt; hello message so he knows the complete data model. Then, in<br>
&gt;&gt; my view, not receiving a node (subtree) is semantically<br>
&gt;&gt; equivalent to receiving it with the contents of &lt;no-access/&gt;.<br>
&gt;<br>
&gt; No, the two are not semantically equivalent.<br>
&gt; The server&#39;s hello message reveals the sorts<br>
&gt; of things that are *potentially* present.<br>
&gt; It doesn&#39;t identify all the instances.<br>
&gt;<br>
&gt; So, for example, the hello message might tell<br>
&gt; me that a system contains &quot;jewels&quot;. &nbsp;The hello<br>
&gt; message does not tell me *which* jewels might<br>
&gt; be there, but &quot;access denied&quot; responses allow<br>
&gt; me to probe to see whether some jewels named<br>
&gt; &quot;crown&quot; or &quot;ER&quot; are present, even if I lack<br>
&gt; the authority to examine them.<br>
<br>
If a user has no read access to a list node, say &ldquo;jewel&rdquo;, he should of course always receive the same data, no matter what the number of list entries is (even zero):<br>
<br>
&lt;jewel&gt;<br>
&nbsp; &lt;nacm:no-access/&gt;<br>
&lt;/jewel&gt;<br>
<br>
This gives no extra information to an attacker but still provides quite a useful clue to regular users.<br></blockquote><div><br></div><div><br></div><div>It tells an unauthorized user that the data they are trying to hack does</div>
<div>in fact exist on the device. &nbsp;That is disclosure of unauthorized information.</div><div><br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Lada<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
&gt;<br>
&gt;&gt; In your example, a client could receive something like<br>
&gt;&gt;<br>
&gt;&gt; &lt;sys:platform&gt;<br>
&gt;&gt; &lt;nacm:no-access/&gt;<br>
&gt;&gt; &lt;/sys:platform&gt;<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t see how this helps an attacker compared to the case when &lt;sys:platform&gt; is not present.<br>
&gt;<br>
&gt; It&#39;s much more interesting in cases where multiple instances<br>
&gt; of a resource may be present, and some instances are more<br>
&gt; interesting than others.<br>
&gt;<br>
&gt;&gt;&gt; Even in the case of HTTP, RFC 2616 section 10.4.4 on<br>
&gt;&gt;&gt; &quot;403 Forbidden&quot; specifies that &quot;[i]f the server does<br>
&gt;&gt;&gt; not wish to make this information available to the client,<br>
&gt;&gt;&gt; the status code 404 (Not Found) can be used instead.&quot;<br>
&gt;&gt;&gt; That&#39;s also the motivation for disabling directory<br>
&gt;&gt;&gt; listings on websites.<br>
&gt;&gt;<br>
&gt;&gt; This doesn&#39;t work for NETCONF/YANG exactly because the<br>
&gt;&gt; server reveals its full data model. It would make sense<br>
&gt;&gt; only if the server could suppress advertising parts of the<br>
&gt;&gt; data model or features.<br>
&gt;<br>
&gt; I agree that the hello unnecessarily exposes information,<br>
&gt; but that risk is mitigated to some extent by the fact<br>
&gt; that hello only says what a system is capable of supporting,<br>
&gt; and doesn&#39;t inform the attacker what is actually present<br>
&gt; nor does it enumerate the instances.<br>
&gt;<br>
&gt; Randy<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; netmod mailing list<br>
&gt; <a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/netmod" target="_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
netmod mailing list<br>
<a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/netmod" target="_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
</blockquote></div><br></div></div>

--001a1134f42aa7665504fa4ff960--


From nobody Mon May 26 09:34:15 2014
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F471A01C0 for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaXK6f1oqArX for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:34:12 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5941A0108 for <netmod@ietf.org>; Mon, 26 May 2014 09:34:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FCc5QJaHrROjJxAd8l5hqdBvns0kACghBg1hEX92mJOPKXx129wotM1j6EIwlaNL; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Woxqi-0006Aa-Ls for netmod@ietf.org; Mon, 26 May 2014 12:34:08 -0400
Received: from 76.254.53.37 by webmail.earthlink.net with HTTP; Mon, 26 May 2014 12:34:08 -0400
Message-ID: <10158301.1401122048653.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
Date: Mon, 26 May 2014 09:34:08 -0700 (GMT-07:00)
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81939846bc9a9da11dead598fc70b91c6a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.33
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Wxr9xFT8EqJDYJ_3rgxvP-CIMlo
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 16:34:13 -0000

Hi -

>From: Ladislav Lhotka=20
>Sent: May 25, 2014 11:26 PM
>To: Randy Presuhn=20
>Cc: netmod@ietf.org
>Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14=
.txt (review of changes)]
>
>
>On 26 May 2014, at 08:08, Randy Presuhn  wrote:
>
>> Hi -
>>=20
>>> From: Ladislav Lhotka=20
>>> Sent: May 25, 2014 9:35 PM
>>> To: Randy Presuhn , netmod@ietf.org
>>> Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg=
-14.txt (review of changes)]
>> ...
>>> I still don't get it. The client had received the server's
>>> hello message so he knows the complete data model. Then, in
>>> my view, not receiving a node (subtree) is semantically
>>> equivalent to receiving it with the contents of .
>>=20
>> No, the two are not semantically equivalent.
>> The server's hello message reveals the sorts
>> of things that are *potentially* present.
>> It doesn't identify all the instances.
>>=20
>> So, for example, the hello message might tell
>> me that a system contains "jewels".  The hello
>> message does not tell me *which* jewels might
>> be there, but "access denied" responses allow
>> me to probe to see whether some jewels named
>> "crown" or "ER" are present, even if I lack
>> the authority to examine them.
>
>If a user has no read access to a list node, say =E2=80=9Cjewel=E2=80=9D,
>he should of course always receive the same data, no matter
>what the number of list entries is (even zero):
>
>
> =20
>
>
>This gives no extra information to an attacker but still
>provides quite a useful clue to regular users.

That is true only if the attacker is allowed no access
to any jewels.  If the attacker is allowed access to
the family jewels, but not the crown jewels, then
information can leak if the responses to requests
regarding the crown jewels indicate whether they are
present, even if no access is allowed to them and
the attacker's access is limited to the family jewels.

Perhaps a more concrete example would help.  I might
wish to allow customers to configure certain aspects
of their respective dedicated, mnemonically-named
interfaces on a box serving multiple customers.
What is undesirable is that giving "access denied"
indications allows one customer to find out whether
another given customer also has an interface on the
same box.

This principle is reflected in RFC 6536:
  3.2.2. <get> and <get-config> Operations
  Data nodes to which the client does not have read access are silently
  omitted from the <rpc-reply> message. This is done to allow NETCONF
  filters for <get> and <get-config> to function properly, instead of
  causing an "access-denied" error because the filter criteria would
  otherwise include unauthorized read access to some data nodes. For
  NETCONF filtering purposes, the selection criteria is applied to the
  subset of nodes that the user is authorized to read, not the entire
  datastore.

The vulnerability is recognized in RFC 6536 as well:
  3.7.2. General Configuration Issues
  ...
  It is possible for a session with some write access (e.g., allowed to
  invoke <edit-config>), but without any access to a particular
  datastore subtree containing sensitive data, to determine the
  presence or non-presence of that data. This can be done by
  repeatedly issuing some sort of edit request (create, update, or
  delete) and possibly receiving "access-denied" errors in response.
  These "fishing" attacks can identify the presence or non-presence of
  specific sensitive data even without the "error-path" field being
  present within the <rpc-error> response.

Along with the related vulnerability:
  A data model may contain external keys (e.g., YANG leafref), which
  expose values from a different data structure. An administrator
  needs to be aware of sensitive data models that contain leafref
  nodes. This entails finding all the leafref objects that "point" at
  the sensitive data (i.e., "path-stmt" values) that implicitly or
  explicitly include the sensitive data node.

Randy


From nobody Mon May 26 09:37:05 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD88A1A01D4 for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2ESoIsvPwCy for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:37:01 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F451A01C0 for <netmod@ietf.org>; Mon, 26 May 2014 09:37:01 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6803013F721; Mon, 26 May 2014 18:36:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401122217; bh=oNp+r+cCW30v63QIOmu7K4qCJqpZzn8KzgYYbl55DsY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hqhIs17nn6jemLAxo2Qb7mx9Kyxlj4B5OshC5RsfTNmVAqwRUUCDFMdvZJhfUu8Pv bTo5Lgji8UW2VIKAGaNnnt8+bRybf+EWsAovQFK/fz2vs6BziOvZEwa7IXf4t5qyN5 suDVZlLjUQGdnG7WsjFJdvHHFRad8s6PxgbwvAWk=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHSgsGBE=NFfULYcfS5yRcfuqkYvRdwNuLMvGTUc5uBLzg@mail.gmail.com>
Date: Mon, 26 May 2014 18:36:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CA240948-067E-4088-A9FA-7F74C8033CA4@nic.cz>
References: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <9E50755E-3C81-4609-B3BB-891D7F648F70@nic.cz> <CABCOCHSgsGBE=NFfULYcfS5yRcfuqkYvRdwNuLMvGTUc5uBLzg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2hhr3Jb44SPxs8RbfETbUPp2aNE
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 16:37:03 -0000

On 26 May 2014, at 18:21, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>=20
> On 26 May 2014, at 08:08, Randy Presuhn <randy_presuhn@mindspring.com> =
wrote:
>=20
> > Hi -
> >
> >> From: Ladislav Lhotka <lhotka@nic.cz>
> >> Sent: May 25, 2014 9:35 PM
> >> To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
> >> Subject: Re: [netmod] trim vs. NACM [WAS: =
draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> > ...
> >> I still don't get it. The client had received the server's
> >> hello message so he knows the complete data model. Then, in
> >> my view, not receiving a node (subtree) is semantically
> >> equivalent to receiving it with the contents of <no-access/>.
> >
> > No, the two are not semantically equivalent.
> > The server's hello message reveals the sorts
> > of things that are *potentially* present.
> > It doesn't identify all the instances.
> >
> > So, for example, the hello message might tell
> > me that a system contains "jewels".  The hello
> > message does not tell me *which* jewels might
> > be there, but "access denied" responses allow
> > me to probe to see whether some jewels named
> > "crown" or "ER" are present, even if I lack
> > the authority to examine them.
>=20
> If a user has no read access to a list node, say =93jewel=94, he =
should of course always receive the same data, no matter what the number =
of list entries is (even zero):
>=20
> <jewel>
>   <nacm:no-access/>
> </jewel>
>=20
> This gives no extra information to an attacker but still provides =
quite a useful clue to regular users.
>=20
>=20
> It tells an unauthorized user that the data they are trying to hack =
does
> in fact exist on the device.  That is disclosure of unauthorized =
information.

No, it isn=92t. As I wrote, the same element would be returned even if =
there are no instances of the =93jewel=94 list at all. The node exists =
in server=92s data model but the attacker already knows this. On the =
other hand, a proper client needn=92t guess whether no instances are =
present because none were configured or whether they were filtered by =
access control.

Lada

>=20
> =20
>=20
> Lada
>=20
> Andy
> =20
>=20
>=20
> >
> >> In your example, a client could receive something like
> >>
> >> <sys:platform>
> >> <nacm:no-access/>
> >> </sys:platform>
> >>
> >> I don't see how this helps an attacker compared to the case when =
<sys:platform> is not present.
> >
> > It's much more interesting in cases where multiple instances
> > of a resource may be present, and some instances are more
> > interesting than others.
> >
> >>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
> >>> "403 Forbidden" specifies that "[i]f the server does
> >>> not wish to make this information available to the client,
> >>> the status code 404 (Not Found) can be used instead."
> >>> That's also the motivation for disabling directory
> >>> listings on websites.
> >>
> >> This doesn't work for NETCONF/YANG exactly because the
> >> server reveals its full data model. It would make sense
> >> only if the server could suppress advertising parts of the
> >> data model or features.
> >
> > I agree that the hello unnecessarily exposes information,
> > but that risk is mitigated to some extent by the fact
> > that hello only says what a system is capable of supporting,
> > and doesn't inform the attacker what is actually present
> > nor does it enumerate the instances.
> >
> > Randy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May 26 09:43:48 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095991A01C0 for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw8IHniLX88H for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:43:41 -0700 (PDT)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73061A01D9 for <netmod@ietf.org>; Mon, 26 May 2014 09:43:39 -0700 (PDT)
Received: by mail-qc0-f175.google.com with SMTP id w7so12377401qcr.20 for <netmod@ietf.org>; Mon, 26 May 2014 09:43:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F4MpSqPuDgWCgQZKL/vognBRW1Ww+kRNcaDgRgwYN9U=; b=SaeXTfcE30BixZTO7QzhfCh5dXWzLXfvpWIH/jdnITayVyx/B2Zv66Q9r294AS6XjH PFtLcl76K0o2UeagQ5vAmrwkayCPyQQISBzI+fjo5mhOfkUGvmeKIVnQHvRSUIMkKve9 HTAlYwe4/s/nK58LnNk+MN5jEFv5lHgq83576/hBFd2VO2nQHgD/j7quJ6xINCOIWT9i fygW9UPFjeA90KJEiMiqgTxgE/BXI2FX7tfk5JBO1I8NlqRTPCDr3WGaKoyxPni8RqVX qSUdPK7aG7D0Q+Sw4ii5EMCBICU2izjA8UsHFXVIckoIpvzLBspqS+B1v5n9dTgkRaIw EUnQ==
X-Gm-Message-State: ALoCoQmpLHuXVB8mofFTUxyy9m4gwkkDb5r73806B1wKEYEVNPfJOLZpWXmXIXu+2xKmFi6d4kqx
MIME-Version: 1.0
X-Received: by 10.140.27.23 with SMTP id 23mr13658003qgw.94.1401122616608; Mon, 26 May 2014 09:43:36 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Mon, 26 May 2014 09:43:36 -0700 (PDT)
In-Reply-To: <CA240948-067E-4088-A9FA-7F74C8033CA4@nic.cz>
References: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <9E50755E-3C81-4609-B3BB-891D7F648F70@nic.cz> <CABCOCHSgsGBE=NFfULYcfS5yRcfuqkYvRdwNuLMvGTUc5uBLzg@mail.gmail.com> <CA240948-067E-4088-A9FA-7F74C8033CA4@nic.cz>
Date: Mon, 26 May 2014 09:43:36 -0700
Message-ID: <CABCOCHQptOEGuD4NAPWqjyQWrptJxza5CTP3GekzTBos2OO4fg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c14a7cd9b89004fa50478d
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yO7EnBazABtaiBuXBLHb84BWsZI
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 16:43:45 -0000

--001a11c14a7cd9b89004fa50478d
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 26, 2014 at 9:36 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 26 May 2014, at 18:21, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > On 26 May 2014, at 08:08, Randy Presuhn <randy_presuhn@mindspring.com>
> wrote:
> >
> > > Hi -
> > >
> > >> From: Ladislav Lhotka <lhotka@nic.cz>
> > >> Sent: May 25, 2014 9:35 PM
> > >> To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
> > >> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> > > ...
> > >> I still don't get it. The client had received the server's
> > >> hello message so he knows the complete data model. Then, in
> > >> my view, not receiving a node (subtree) is semantically
> > >> equivalent to receiving it with the contents of <no-access/>.
> > >
> > > No, the two are not semantically equivalent.
> > > The server's hello message reveals the sorts
> > > of things that are *potentially* present.
> > > It doesn't identify all the instances.
> > >
> > > So, for example, the hello message might tell
> > > me that a system contains "jewels".  The hello
> > > message does not tell me *which* jewels might
> > > be there, but "access denied" responses allow
> > > me to probe to see whether some jewels named
> > > "crown" or "ER" are present, even if I lack
> > > the authority to examine them.
> >
> > If a user has no read access to a list node, say "jewel", he should of
> course always receive the same data, no matter what the number of list
> entries is (even zero):
> >
> > <jewel>
> >   <nacm:no-access/>
> > </jewel>
> >
> > This gives no extra information to an attacker but still provides quite
> a useful clue to regular users.
> >
> >
> > It tells an unauthorized user that the data they are trying to hack does
> > in fact exist on the device.  That is disclosure of unauthorized
> information.
>
> No, it isn't. As I wrote, the same element would be returned even if there
> are no instances of the "jewel" list at all. The node exists in server's
> data model but the attacker already knows this. On the other hand, a proper
> client needn't guess whether no instances are present because none were
> configured or whether they were filtered by access control.
>
>
You mean the same data structure, except for the <nacm:no-access/> leaf
that tells the client "the parent contains child nodes you are
not allowed to even know about."  The insertion of a "you found something
interesting" flag for attackers to use does not seem like a great idea.




> Lada
>

Andy


>
> >
> >
> >
> > Lada
> >
> > Andy
> >
> >
> >
> > >
> > >> In your example, a client could receive something like
> > >>
> > >> <sys:platform>
> > >> <nacm:no-access/>
> > >> </sys:platform>
> > >>
> > >> I don't see how this helps an attacker compared to the case when
> <sys:platform> is not present.
> > >
> > > It's much more interesting in cases where multiple instances
> > > of a resource may be present, and some instances are more
> > > interesting than others.
> > >
> > >>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
> > >>> "403 Forbidden" specifies that "[i]f the server does
> > >>> not wish to make this information available to the client,
> > >>> the status code 404 (Not Found) can be used instead."
> > >>> That's also the motivation for disabling directory
> > >>> listings on websites.
> > >>
> > >> This doesn't work for NETCONF/YANG exactly because the
> > >> server reveals its full data model. It would make sense
> > >> only if the server could suppress advertising parts of the
> > >> data model or features.
> > >
> > > I agree that the hello unnecessarily exposes information,
> > > but that risk is mitigated to some extent by the fact
> > > that hello only says what a system is capable of supporting,
> > > and doesn't inform the attacker what is actually present
> > > nor does it enumerate the instances.
> > >
> > > Randy
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c14a7cd9b89004fa50478d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, May 26, 2014 at 9:36 AM, Ladislav Lhotka <span dir=3D"ltr">=
&lt;<a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
On 26 May 2014, at 18:21, Andy Bierman &lt;<a href=3D"mailto:andy@yumaworks=
.com">andy@yumaworks.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka &lt;<a href=3D"mailt=
o:lhotka@nic.cz">lhotka@nic.cz</a>&gt; wrote:<br>
&gt;<br>
&gt; On 26 May 2014, at 08:08, Randy Presuhn &lt;<a href=3D"mailto:randy_pr=
esuhn@mindspring.com">randy_presuhn@mindspring.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Hi -<br>
&gt; &gt;<br>
&gt; &gt;&gt; From: Ladislav Lhotka &lt;<a href=3D"mailto:lhotka@nic.cz">lh=
otka@nic.cz</a>&gt;<br>
&gt; &gt;&gt; Sent: May 25, 2014 9:35 PM<br>
&gt; &gt;&gt; To: Randy Presuhn &lt;<a href=3D"mailto:randy_presuhn@mindspr=
ing.com">randy_presuhn@mindspring.com</a>&gt;, <a href=3D"mailto:netmod@iet=
f.org">netmod@ietf.org</a><br>
&gt; &gt;&gt; Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-r=
outing-cfg-14.txt (review of changes)]<br>
&gt; &gt; ...<br>
&gt; &gt;&gt; I still don&#39;t get it. The client had received the server&=
#39;s<br>
&gt; &gt;&gt; hello message so he knows the complete data model. Then, in<b=
r>
&gt; &gt;&gt; my view, not receiving a node (subtree) is semantically<br>
&gt; &gt;&gt; equivalent to receiving it with the contents of &lt;no-access=
/&gt;.<br>
&gt; &gt;<br>
&gt; &gt; No, the two are not semantically equivalent.<br>
&gt; &gt; The server&#39;s hello message reveals the sorts<br>
&gt; &gt; of things that are *potentially* present.<br>
&gt; &gt; It doesn&#39;t identify all the instances.<br>
&gt; &gt;<br>
&gt; &gt; So, for example, the hello message might tell<br>
&gt; &gt; me that a system contains &quot;jewels&quot;. &nbsp;The hello<br>
&gt; &gt; message does not tell me *which* jewels might<br>
&gt; &gt; be there, but &quot;access denied&quot; responses allow<br>
&gt; &gt; me to probe to see whether some jewels named<br>
&gt; &gt; &quot;crown&quot; or &quot;ER&quot; are present, even if I lack<b=
r>
&gt; &gt; the authority to examine them.<br>
&gt;<br>
&gt; If a user has no read access to a list node, say &ldquo;jewel&rdquo;, =
he should of course always receive the same data, no matter what the number=
 of list entries is (even zero):<br>
&gt;<br>
&gt; &lt;jewel&gt;<br>
&gt; &nbsp; &lt;nacm:no-access/&gt;<br>
&gt; &lt;/jewel&gt;<br>
&gt;<br>
&gt; This gives no extra information to an attacker but still provides quit=
e a useful clue to regular users.<br>
&gt;<br>
&gt;<br>
&gt; It tells an unauthorized user that the data they are trying to hack do=
es<br>
&gt; in fact exist on the device. &nbsp;That is disclosure of unauthorized =
information.<br>
<br>
No, it isn&rsquo;t. As I wrote, the same element would be returned even if =
there are no instances of the &ldquo;jewel&rdquo; list at all. The node exi=
sts in server&rsquo;s data model but the attacker already knows this. On th=
e other hand, a proper client needn&rsquo;t guess whether no instances are =
present because none were configured or whether they were filtered by acces=
s control.<br>

<br></blockquote><div><br></div><div>You mean the same data structure, exce=
pt for the &lt;nacm:no-access/&gt; leaf</div><div>that tells the client &qu=
ot;the parent contains child nodes you are</div><div>not allowed to even kn=
ow about.&quot; &nbsp;The insertion of a &quot;you found something</div>
<div>interesting&quot; flag for attackers to use does not seem like a great=
 idea.</div><div><br></div><div><br></div><div>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

Lada<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Lada<br>
&gt;<br>
&gt; Andy<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt; In your example, a client could receive something like<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &lt;sys:platform&gt;<br>
&gt; &gt;&gt; &lt;nacm:no-access/&gt;<br>
&gt; &gt;&gt; &lt;/sys:platform&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I don&#39;t see how this helps an attacker compared to the ca=
se when &lt;sys:platform&gt; is not present.<br>
&gt; &gt;<br>
&gt; &gt; It&#39;s much more interesting in cases where multiple instances<=
br>
&gt; &gt; of a resource may be present, and some instances are more<br>
&gt; &gt; interesting than others.<br>
&gt; &gt;<br>
&gt; &gt;&gt;&gt; Even in the case of HTTP, RFC 2616 section 10.4.4 on<br>
&gt; &gt;&gt;&gt; &quot;403 Forbidden&quot; specifies that &quot;[i]f the s=
erver does<br>
&gt; &gt;&gt;&gt; not wish to make this information available to the client=
,<br>
&gt; &gt;&gt;&gt; the status code 404 (Not Found) can be used instead.&quot=
;<br>
&gt; &gt;&gt;&gt; That&#39;s also the motivation for disabling directory<br=
>
&gt; &gt;&gt;&gt; listings on websites.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; This doesn&#39;t work for NETCONF/YANG exactly because the<br=
>
&gt; &gt;&gt; server reveals its full data model. It would make sense<br>
&gt; &gt;&gt; only if the server could suppress advertising parts of the<br=
>
&gt; &gt;&gt; data model or features.<br>
&gt; &gt;<br>
&gt; &gt; I agree that the hello unnecessarily exposes information,<br>
&gt; &gt; but that risk is mitigated to some extent by the fact<br>
&gt; &gt; that hello only says what a system is capable of supporting,<br>
&gt; &gt; and doesn&#39;t inform the attacker what is actually present<br>
&gt; &gt; nor does it enumerate the instances.<br>
&gt; &gt;<br>
&gt; &gt; Randy<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; netmod mailing list<br>
&gt; &gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; &gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt;<br>
&gt; --<br>
&gt; Ladislav Lhotka, CZ.NIC Labs<br>
&gt; PGP Key ID: E74E8C0C<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; netmod mailing list<br>
&gt; <a href=3D"mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/netmod" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
&gt;<br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>

--001a11c14a7cd9b89004fa50478d--


From nobody Mon May 26 09:51:14 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F69D1A01D9 for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwAaijn4GHXP for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:51:11 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E5C1A01D6 for <netmod@ietf.org>; Mon, 26 May 2014 09:51:10 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CE9A513F721; Mon, 26 May 2014 18:51:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401123066; bh=qa+VxfgC6cavXnjt1EPinQD2SMFk+JFtbYTX9fwVtqM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EpIRtIxztc3bTCD34V6A52dibjC4vl7L9GbSqbbGThi3x0OOQkXJQpIjAAjXEA8ik fxMBrr+TF1JIOiLWJS/NzbKsZ/HIk+K4HMhHR/zJSBYQO0m20opJNHOXv3iNdZYUQj BArbrxOZRUaXlo1fgBlUCwb2Hhw8y52R5zUagHN8=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <10158301.1401122048653.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
Date: Mon, 26 May 2014 18:51:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <12F8B0CD-D2BB-4B0F-9C01-75E56C0F3C7E@nic.cz>
References: <10158301.1401122048653.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
To: Randy Presuhn <randy_presuhn@mindspring.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6d98ScQaxWzEUNcv5wRng0CLo24
Cc: netmod@ietf.org
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 16:51:12 -0000

On 26 May 2014, at 18:34, Randy Presuhn <randy_presuhn@mindspring.com> =
wrote:

> Hi -
>=20
>> From: Ladislav Lhotka=20
>> Sent: May 25, 2014 11:26 PM
>> To: Randy Presuhn=20
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] trim vs. NACM [WAS: =
draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
>>=20
>>=20
>> On 26 May 2014, at 08:08, Randy Presuhn  wrote:
>>=20
>>> Hi -
>>>=20
>>>> From: Ladislav Lhotka=20
>>>> Sent: May 25, 2014 9:35 PM
>>>> To: Randy Presuhn , netmod@ietf.org
>>>> Subject: Re: [netmod] trim vs. NACM [WAS: =
draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
>>> ...
>>>> I still don't get it. The client had received the server's
>>>> hello message so he knows the complete data model. Then, in
>>>> my view, not receiving a node (subtree) is semantically
>>>> equivalent to receiving it with the contents of .
>>>=20
>>> No, the two are not semantically equivalent.
>>> The server's hello message reveals the sorts
>>> of things that are *potentially* present.
>>> It doesn't identify all the instances.
>>>=20
>>> So, for example, the hello message might tell
>>> me that a system contains "jewels".  The hello
>>> message does not tell me *which* jewels might
>>> be there, but "access denied" responses allow
>>> me to probe to see whether some jewels named
>>> "crown" or "ER" are present, even if I lack
>>> the authority to examine them.
>>=20
>> If a user has no read access to a list node, say =93jewel=94,
>> he should of course always receive the same data, no matter
>> what the number of list entries is (even zero):
>>=20
>>=20
>>=20
>>=20
>>=20
>> This gives no extra information to an attacker but still
>> provides quite a useful clue to regular users.
>=20
> That is true only if the attacker is allowed no access
> to any jewels.  If the attacker is allowed access to
> the family jewels, but not the crown jewels, then
> information can leak if the responses to requests
> regarding the crown jewels indicate whether they are
> present, even if no access is allowed to them and
> the attacker's access is limited to the family jewels.
>=20
> Perhaps a more concrete example would help.  I might
> wish to allow customers to configure certain aspects
> of their respective dedicated, mnemonically-named
> interfaces on a box serving multiple customers.
> What is undesirable is that giving "access denied"
> indications allows one customer to find out whether
> another given customer also has an interface on the
> same box.

I see your point, but it doesn=92t apply to the ambiguity between =
trimming of defaults and access-control filtering.

Lada

>=20
> This principle is reflected in RFC 6536:
>  3.2.2. <get> and <get-config> Operations
>  Data nodes to which the client does not have read access are silently
>  omitted from the <rpc-reply> message. This is done to allow NETCONF
>  filters for <get> and <get-config> to function properly, instead of
>  causing an "access-denied" error because the filter criteria would
>  otherwise include unauthorized read access to some data nodes. For
>  NETCONF filtering purposes, the selection criteria is applied to the
>  subset of nodes that the user is authorized to read, not the entire
>  datastore.
>=20
> The vulnerability is recognized in RFC 6536 as well:
>  3.7.2. General Configuration Issues
>  ...
>  It is possible for a session with some write access (e.g., allowed to
>  invoke <edit-config>), but without any access to a particular
>  datastore subtree containing sensitive data, to determine the
>  presence or non-presence of that data. This can be done by
>  repeatedly issuing some sort of edit request (create, update, or
>  delete) and possibly receiving "access-denied" errors in response.
>  These "fishing" attacks can identify the presence or non-presence of
>  specific sensitive data even without the "error-path" field being
>  present within the <rpc-error> response.
>=20
> Along with the related vulnerability:
>  A data model may contain external keys (e.g., YANG leafref), which
>  expose values from a different data structure. An administrator
>  needs to be aware of sensitive data models that contain leafref
>  nodes. This entails finding all the leafref objects that "point" at
>  the sensitive data (i.e., "path-stmt" values) that implicitly or
>  explicitly include the sensitive data node.
>=20
> Randy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May 26 09:59:06 2014
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF5E1A01DE for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73HY_WLxN88x for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 09:59:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759511A01D6 for <netmod@ietf.org>; Mon, 26 May 2014 09:59:02 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6F04513F721; Mon, 26 May 2014 18:58:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401123538; bh=noYT8g6E5d76NrKAxc7C0YZ00KzR7/r1v7B4Hqnldxk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CbiAhgAdkXHUu0zurs+VSZPjM34efHg16ztdcGvDGNu2MHqK1I0HtMFfQmbkb9I00 exwMBaHH8t1J2NOReXUeZxsc7M3TpdZX72GLi5SNjsdhi9M7BR28x4MYEIxeF/w939 /Ulb3JPqDCTwiLdX/A8cLgxg18CK84/y7eSdb0XI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CABCOCHQptOEGuD4NAPWqjyQWrptJxza5CTP3GekzTBos2OO4fg@mail.gmail.com>
Date: Mon, 26 May 2014 18:58:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC51FFDC-CF89-41D4-9FF0-6485D3BFA8C8@nic.cz>
References: <31791965.1401084532373.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <9E50755E-3C81-4609-B3BB-891D7F648F70@nic.cz> <CABCOCHSgsGBE=NFfULYcfS5yRcfuqkYvRdwNuLMvGTUc5uBLzg@mail.gmail.com> <CA240948-067E-4088-A9FA-7F74C8033CA4@nic.cz> <CABCOCHQptOEGuD4NAPWqjyQWrptJxza5CTP3GekzTBos2OO4fg@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SCS8ZuJ6tB52pWaEExYdjTyehYY
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 16:59:04 -0000

On 26 May 2014, at 18:43, Andy Bierman <andy@yumaworks.com> wrote:

>=20
>=20
>=20
> On Mon, May 26, 2014 at 9:36 AM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
>=20
> On 26 May 2014, at 18:21, Andy Bierman <andy@yumaworks.com> wrote:
>=20
> >
> >
> >
> > On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka <lhotka@nic.cz> =
wrote:
> >
> > On 26 May 2014, at 08:08, Randy Presuhn =
<randy_presuhn@mindspring.com> wrote:
> >
> > > Hi -
> > >
> > >> From: Ladislav Lhotka <lhotka@nic.cz>
> > >> Sent: May 25, 2014 9:35 PM
> > >> To: Randy Presuhn <randy_presuhn@mindspring.com>, netmod@ietf.org
> > >> Subject: Re: [netmod] trim vs. NACM [WAS: =
draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> > > ...
> > >> I still don't get it. The client had received the server's
> > >> hello message so he knows the complete data model. Then, in
> > >> my view, not receiving a node (subtree) is semantically
> > >> equivalent to receiving it with the contents of <no-access/>.
> > >
> > > No, the two are not semantically equivalent.
> > > The server's hello message reveals the sorts
> > > of things that are *potentially* present.
> > > It doesn't identify all the instances.
> > >
> > > So, for example, the hello message might tell
> > > me that a system contains "jewels".  The hello
> > > message does not tell me *which* jewels might
> > > be there, but "access denied" responses allow
> > > me to probe to see whether some jewels named
> > > "crown" or "ER" are present, even if I lack
> > > the authority to examine them.
> >
> > If a user has no read access to a list node, say =93jewel=94, he =
should of course always receive the same data, no matter what the number =
of list entries is (even zero):
> >
> > <jewel>
> >   <nacm:no-access/>
> > </jewel>
> >
> > This gives no extra information to an attacker but still provides =
quite a useful clue to regular users.
> >
> >
> > It tells an unauthorized user that the data they are trying to hack =
does
> > in fact exist on the device.  That is disclosure of unauthorized =
information.
>=20
> No, it isn=92t. As I wrote, the same element would be returned even if =
there are no instances of the =93jewel=94 list at all. The node exists =
in server=92s data model but the attacker already knows this. On the =
other hand, a proper client needn=92t guess whether no instances are =
present because none were configured or whether they were filtered by =
access control.
>=20
>=20
> You mean the same data structure, except for the <nacm:no-access/> =
leaf
> that tells the client "the parent contains child nodes you are
> not allowed to even know about."  The insertion of a "you found =
something
> interesting" flag for attackers to use does not seem like a great =
idea.

Clever attackers already know there might be something interesting from =
the data model. The only new information is that some (unspecified) =
access control is applied to a particular node but in most cases this =
will be hardly surprising.=20

Lada

>=20
>=20
> =20
> Lada
>=20
> Andy
> =20
>=20
> >
> >
> >
> > Lada
> >
> > Andy
> >
> >
> >
> > >
> > >> In your example, a client could receive something like
> > >>
> > >> <sys:platform>
> > >> <nacm:no-access/>
> > >> </sys:platform>
> > >>
> > >> I don't see how this helps an attacker compared to the case when =
<sys:platform> is not present.
> > >
> > > It's much more interesting in cases where multiple instances
> > > of a resource may be present, and some instances are more
> > > interesting than others.
> > >
> > >>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
> > >>> "403 Forbidden" specifies that "[i]f the server does
> > >>> not wish to make this information available to the client,
> > >>> the status code 404 (Not Found) can be used instead."
> > >>> That's also the motivation for disabling directory
> > >>> listings on websites.
> > >>
> > >> This doesn't work for NETCONF/YANG exactly because the
> > >> server reveals its full data model. It would make sense
> > >> only if the server could suppress advertising parts of the
> > >> data model or features.
> > >
> > > I agree that the hello unnecessarily exposes information,
> > > but that risk is mitigated to some extent by the fact
> > > that hello only says what a system is capable of supporting,
> > > and doesn't inform the attacker what is actually present
> > > nor does it enumerate the instances.
> > >
> > > Randy
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon May 26 10:12:04 2014
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445F51A01DD for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 10:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qpApUouyN_H for <netmod@ietfa.amsl.com>; Mon, 26 May 2014 10:12:01 -0700 (PDT)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB901A01DE for <netmod@ietf.org>; Mon, 26 May 2014 10:12:00 -0700 (PDT)
Received: by mail-qg0-f46.google.com with SMTP id q108so12027258qgd.19 for <netmod@ietf.org>; Mon, 26 May 2014 10:11:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q7Qtik/aVA0FofoZp1U86KmsxRFHtClIUbDtKmZwuz0=; b=EPmZj9TINoPL+vt26JvixhE3v0JXXUCVz8dQe74I07tS9OoYS57Ji1NAcCO2VCMRjc W0Qg3K5ZR+ExZu/AQSbUCI7qZ0ZvYMFq35Bd1GmFxqfCfgIHca8A53h0s/htaPfwFyls Hx6UJYkGvz7alIe8f6KatyplIMdpyvwPXnjeY4SfycDwxXuxxAyKl1m5Z0NrSasBGJNK goNBm2fPtjh2rWj7iWiyJrGOjHmb5SpVjXpg/jKktzhnwatOLovTeraYpQfwxNv7qZrX nDyPv5TemxYh41IIUJjR1aGPcls1J2fMeWRnCeVq2JrkGoaseTnkdceLbfHfIj+He3X/ zlUw==
X-Gm-Message-State: ALoCoQkjpcKUzf8kHNwj5mW+xdGI0bFx0mo2PWC3tBcNxH6RE+jq6JlzE6oZhbQmGy9R+nLogMgZ
MIME-Version: 1.0
X-Received: by 10.140.41.75 with SMTP id y69mr32732370qgy.34.1401124317727; Mon, 26 May 2014 10:11:57 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Mon, 26 May 2014 10:11:57 -0700 (PDT)
In-Reply-To: <12F8B0CD-D2BB-4B0F-9C01-75E56C0F3C7E@nic.cz>
References: <10158301.1401122048653.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> <12F8B0CD-D2BB-4B0F-9C01-75E56C0F3C7E@nic.cz>
Date: Mon, 26 May 2014 10:11:57 -0700
Message-ID: <CABCOCHS46x15u44kMnN5WMAFCbJc9qwYNzOw28EVG67Y3VrUOQ@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary=001a11c126ba3ea20204fa50adba
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/trOLeE8Iocv6kPtxoLn3MwsSSn4
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 17:12:03 -0000

--001a11c126ba3ea20204fa50adba
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 26, 2014 at 9:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>
> On 26 May 2014, at 18:34, Randy Presuhn <randy_presuhn@mindspring.com>
> wrote:
>
> > Hi -
> >
> >> From: Ladislav Lhotka
> >> Sent: May 25, 2014 11:26 PM
> >> To: Randy Presuhn
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> >>
> >>
> >> On 26 May 2014, at 08:08, Randy Presuhn  wrote:
> >>
> >>> Hi -
> >>>
> >>>> From: Ladislav Lhotka
> >>>> Sent: May 25, 2014 9:35 PM
> >>>> To: Randy Presuhn , netmod@ietf.org
> >>>> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> >>> ...
> >>>> I still don't get it. The client had received the server's
> >>>> hello message so he knows the complete data model. Then, in
> >>>> my view, not receiving a node (subtree) is semantically
> >>>> equivalent to receiving it with the contents of .
> >>>
> >>> No, the two are not semantically equivalent.
> >>> The server's hello message reveals the sorts
> >>> of things that are *potentially* present.
> >>> It doesn't identify all the instances.
> >>>
> >>> So, for example, the hello message might tell
> >>> me that a system contains "jewels".  The hello
> >>> message does not tell me *which* jewels might
> >>> be there, but "access denied" responses allow
> >>> me to probe to see whether some jewels named
> >>> "crown" or "ER" are present, even if I lack
> >>> the authority to examine them.
> >>
> >> If a user has no read access to a list node, say "jewel",
> >> he should of course always receive the same data, no matter
> >> what the number of list entries is (even zero):
> >>
> >>
> >>
> >>
> >>
> >> This gives no extra information to an attacker but still
> >> provides quite a useful clue to regular users.
> >
> > That is true only if the attacker is allowed no access
> > to any jewels.  If the attacker is allowed access to
> > the family jewels, but not the crown jewels, then
> > information can leak if the responses to requests
> > regarding the crown jewels indicate whether they are
> > present, even if no access is allowed to them and
> > the attacker's access is limited to the family jewels.
> >
> > Perhaps a more concrete example would help.  I might
> > wish to allow customers to configure certain aspects
> > of their respective dedicated, mnemonically-named
> > interfaces on a box serving multiple customers.
> > What is undesirable is that giving "access denied"
> > indications allows one customer to find out whether
> > another given customer also has an interface on the
> > same box.
>
> I see your point, but it doesn't apply to the ambiguity between trimming
> of defaults and access-control filtering.
>
>
If the choice is between keeping the server more secure or
saving some bytes in an <rpc-reply> to the client, security is
going to win.

If the server returns nothing for a "miss" and <nacm:no-access/>
for a "hit", then an attacker can discover the existence of all the
sensitive data and all the key leaf values.


Lada
>

Andy


>
> >
> > This principle is reflected in RFC 6536:
> >  3.2.2. <get> and <get-config> Operations
> >  Data nodes to which the client does not have read access are silently
> >  omitted from the <rpc-reply> message. This is done to allow NETCONF
> >  filters for <get> and <get-config> to function properly, instead of
> >  causing an "access-denied" error because the filter criteria would
> >  otherwise include unauthorized read access to some data nodes. For
> >  NETCONF filtering purposes, the selection criteria is applied to the
> >  subset of nodes that the user is authorized to read, not the entire
> >  datastore.
> >
> > The vulnerability is recognized in RFC 6536 as well:
> >  3.7.2. General Configuration Issues
> >  ...
> >  It is possible for a session with some write access (e.g., allowed to
> >  invoke <edit-config>), but without any access to a particular
> >  datastore subtree containing sensitive data, to determine the
> >  presence or non-presence of that data. This can be done by
> >  repeatedly issuing some sort of edit request (create, update, or
> >  delete) and possibly receiving "access-denied" errors in response.
> >  These "fishing" attacks can identify the presence or non-presence of
> >  specific sensitive data even without the "error-path" field being
> >  present within the <rpc-error> response.
> >
> > Along with the related vulnerability:
> >  A data model may contain external keys (e.g., YANG leafref), which
> >  expose values from a different data structure. An administrator
> >  needs to be aware of sensitive data models that contain leafref
> >  nodes. This entails finding all the leafref objects that "point" at
> >  the sensitive data (i.e., "path-stmt" values) that implicitly or
> >  explicitly include the sensitive data node.
> >
> > Randy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a11c126ba3ea20204fa50adba
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 9:51 AM, Ladislav Lhotka <span dir="ltr">&lt;<a href="mailto:lhotka@nic.cz" target="_blank">lhotka@nic.cz</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 26 May 2014, at 18:34, Randy Presuhn &lt;<a href="mailto:randy_presuhn@mindspring.com">randy_presuhn@mindspring.com</a>&gt; wrote:<br>
<br>
&gt; Hi -<br>
&gt;<br>
&gt;&gt; From: Ladislav Lhotka<br>
&gt;&gt; Sent: May 25, 2014 11:26 PM<br>
&gt;&gt; To: Randy Presuhn<br>
&gt;&gt; Cc: <a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt;&gt; Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 26 May 2014, at 08:08, Randy Presuhn &nbsp;wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Hi -<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; From: Ladislav Lhotka<br>
&gt;&gt;&gt;&gt; Sent: May 25, 2014 9:35 PM<br>
&gt;&gt;&gt;&gt; To: Randy Presuhn , <a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt;&gt;&gt;&gt; Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]<br>
&gt;&gt;&gt; ...<br>
&gt;&gt;&gt;&gt; I still don&#39;t get it. The client had received the server&#39;s<br>
&gt;&gt;&gt;&gt; hello message so he knows the complete data model. Then, in<br>
&gt;&gt;&gt;&gt; my view, not receiving a node (subtree) is semantically<br>
&gt;&gt;&gt;&gt; equivalent to receiving it with the contents of .<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; No, the two are not semantically equivalent.<br>
&gt;&gt;&gt; The server&#39;s hello message reveals the sorts<br>
&gt;&gt;&gt; of things that are *potentially* present.<br>
&gt;&gt;&gt; It doesn&#39;t identify all the instances.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; So, for example, the hello message might tell<br>
&gt;&gt;&gt; me that a system contains &quot;jewels&quot;. &nbsp;The hello<br>
&gt;&gt;&gt; message does not tell me *which* jewels might<br>
&gt;&gt;&gt; be there, but &quot;access denied&quot; responses allow<br>
&gt;&gt;&gt; me to probe to see whether some jewels named<br>
&gt;&gt;&gt; &quot;crown&quot; or &quot;ER&quot; are present, even if I lack<br>
&gt;&gt;&gt; the authority to examine them.<br>
&gt;&gt;<br>
&gt;&gt; If a user has no read access to a list node, say &ldquo;jewel&rdquo;,<br>
&gt;&gt; he should of course always receive the same data, no matter<br>
&gt;&gt; what the number of list entries is (even zero):<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; This gives no extra information to an attacker but still<br>
&gt;&gt; provides quite a useful clue to regular users.<br>
&gt;<br>
&gt; That is true only if the attacker is allowed no access<br>
&gt; to any jewels. &nbsp;If the attacker is allowed access to<br>
&gt; the family jewels, but not the crown jewels, then<br>
&gt; information can leak if the responses to requests<br>
&gt; regarding the crown jewels indicate whether they are<br>
&gt; present, even if no access is allowed to them and<br>
&gt; the attacker&#39;s access is limited to the family jewels.<br>
&gt;<br>
&gt; Perhaps a more concrete example would help. &nbsp;I might<br>
&gt; wish to allow customers to configure certain aspects<br>
&gt; of their respective dedicated, mnemonically-named<br>
&gt; interfaces on a box serving multiple customers.<br>
&gt; What is undesirable is that giving &quot;access denied&quot;<br>
&gt; indications allows one customer to find out whether<br>
&gt; another given customer also has an interface on the<br>
&gt; same box.<br>
<br>
I see your point, but it doesn&rsquo;t apply to the ambiguity between trimming of defaults and access-control filtering.<br>
<br></blockquote><div><br></div><div>If the choice is between keeping the server more secure or</div><div>saving some bytes in an &lt;rpc-reply&gt; to the client, security is</div><div>going to win.</div><div><br></div><div>
If the server returns nothing for a &quot;miss&quot; and &lt;nacm:no-access/&gt;</div><div>for a &quot;hit&quot;, then an attacker can discover the existence of all the</div><div>sensitive data and all the key leaf values.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lada<br></blockquote><div><br></div><div>Andy</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;<br>
&gt; This principle is reflected in RFC 6536:<br>
&gt; &nbsp;3.2.2. &lt;get&gt; and &lt;get-config&gt; Operations<br>
&gt; &nbsp;Data nodes to which the client does not have read access are silently<br>
&gt; &nbsp;omitted from the &lt;rpc-reply&gt; message. This is done to allow NETCONF<br>
&gt; &nbsp;filters for &lt;get&gt; and &lt;get-config&gt; to function properly, instead of<br>
&gt; &nbsp;causing an &quot;access-denied&quot; error because the filter criteria would<br>
&gt; &nbsp;otherwise include unauthorized read access to some data nodes. For<br>
&gt; &nbsp;NETCONF filtering purposes, the selection criteria is applied to the<br>
&gt; &nbsp;subset of nodes that the user is authorized to read, not the entire<br>
&gt; &nbsp;datastore.<br>
&gt;<br>
&gt; The vulnerability is recognized in RFC 6536 as well:<br>
&gt; &nbsp;3.7.2. General Configuration Issues<br>
&gt; &nbsp;...<br>
&gt; &nbsp;It is possible for a session with some write access (e.g., allowed to<br>
&gt; &nbsp;invoke &lt;edit-config&gt;), but without any access to a particular<br>
&gt; &nbsp;datastore subtree containing sensitive data, to determine the<br>
&gt; &nbsp;presence or non-presence of that data. This can be done by<br>
&gt; &nbsp;repeatedly issuing some sort of edit request (create, update, or<br>
&gt; &nbsp;delete) and possibly receiving &quot;access-denied&quot; errors in response.<br>
&gt; &nbsp;These &quot;fishing&quot; attacks can identify the presence or non-presence of<br>
&gt; &nbsp;specific sensitive data even without the &quot;error-path&quot; field being<br>
&gt; &nbsp;present within the &lt;rpc-error&gt; response.<br>
&gt;<br>
&gt; Along with the related vulnerability:<br>
&gt; &nbsp;A data model may contain external keys (e.g., YANG leafref), which<br>
&gt; &nbsp;expose values from a different data structure. An administrator<br>
&gt; &nbsp;needs to be aware of sensitive data models that contain leafref<br>
&gt; &nbsp;nodes. This entails finding all the leafref objects that &quot;point&quot; at<br>
&gt; &nbsp;the sensitive data (i.e., &quot;path-stmt&quot; values) that implicitly or<br>
&gt; &nbsp;explicitly include the sensitive data node.<br>
&gt;<br>
&gt; Randy<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; netmod mailing list<br>
&gt; <a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/netmod" target="_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
<br>
--<br>
Ladislav Lhotka, CZ.NIC Labs<br>
PGP Key ID: E74E8C0C<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
netmod mailing list<br>
<a href="mailto:netmod@ietf.org">netmod@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/netmod" target="_blank">https://www.ietf.org/mailman/listinfo/netmod</a><br>
</blockquote></div><br></div></div>

--001a11c126ba3ea20204fa50adba--


From nobody Tue May 27 07:53:15 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322D11A043D for <netmod@ietfa.amsl.com>; Tue, 27 May 2014 07:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfHvLxdhMqzn for <netmod@ietfa.amsl.com>; Tue, 27 May 2014 07:53:01 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA1E1A0433 for <netmod@ietf.org>; Tue, 27 May 2014 07:53:01 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6E1D5736; Tue, 27 May 2014 16:52:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A8Gc-L2cN6gC; Tue, 27 May 2014 16:52:47 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 May 2014 16:52:52 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7123B20036; Tue, 27 May 2014 16:52:42 +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 d-kxsGU0ZYVm; Tue, 27 May 2014 16:52:41 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACB9220037; Tue, 27 May 2014 16:52:40 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id B88892CF8D32; Tue, 27 May 2014 16:52:39 +0200 (CEST)
Date: Tue, 27 May 2014 16:52:38 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@nic.cz>
Message-ID: <20140527145238.GA4621@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Ladislav Lhotka <lhotka@nic.cz>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <20140523083105.GD93835@elstar.jacobs.jacobs-university.de> <5BD707DC-E9FE-4C53-9F34-C9BD47630B36@nic.cz> <20140523100950.GB198@elstar.local> <CABCOCHRPjwEtADwnR9ds8gmbREsNkRER8WC17qdCGXj-zHb-7Q@mail.gmail.com> <C4607CE4-BE16-46F1-97A2-7568B11992ED@nic.cz> <CABCOCHTMVOp77BhKspAtHxnzUP8S1tiD2512ez-zwGfMKDEMqA@mail.gmail.com> <EE7724DE-E99C-4429-B47B-80A1FE789F0E@nic.cz> <20140523192739.GA1081@elstar.local> <CABCOCHTV8mixAYjxLFq9dXrrZAWiO6DRfe2xpEgha3+vxkHBRA@mail.gmail.com> <m2mwe5d8yc.fsf@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2mwe5d8yc.fsf@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JfnO9xW3pzleKqhfmOJObfYiWyU
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-14.txt (review of changes)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2014 14:53:11 -0000

On Sun, May 25, 2014 at 08:11:55PM +0200, Ladislav Lhotka wrote:
> > On Fri, May 23, 2014 at 12:27 PM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Fri, May 23, 2014 at 08:23:20PM +0200, Ladislav Lhotka wrote:
> >> >
> >> > So how about this modification of -14:
> >> >
> >> > 1. Remove all defaults in state data.
> >> > 2. In config, remove only the default of 'cur-hop-limit'.
> >> >
> >>
> >> Works well for me.
> >>
> >> As said before, I personally find the possible optimization for trim
> >> mode not worthwhile and we are better consistent how we do this in our
> >> YANG modules.
> >>
> >>
> > Agreed.
> 
> OK, see revision -15.
> 

Thanks. I will send this document to Benoit now.

/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 nobody Tue May 27 08:04:27 2014
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F391A034B for <netmod@ietfa.amsl.com>; Tue, 27 May 2014 08:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6bfK6WDU_AP for <netmod@ietfa.amsl.com>; Tue, 27 May 2014 08:04:20 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5599D1A013B for <netmod@ietf.org>; Tue, 27 May 2014 08:04:20 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 73B636D9; Tue, 27 May 2014 17:04:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EwfyLOCd-X-7; Tue, 27 May 2014 17:04:14 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 May 2014 17:04:13 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87A7F20017; Tue, 27 May 2014 17:04:14 +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 3b7ujansmT0s; Tue, 27 May 2014 17:04:11 +0200 (CEST)
Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 976ED20013; Tue, 27 May 2014 17:04:10 +0200 (CEST)
Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 42FC72CF8D9F; Tue, 27 May 2014 17:04:09 +0200 (CEST)
Date: Tue, 27 May 2014 17:04:08 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Benoit Claise <bclaise@cisco.com>
Message-ID: <20140527150408.GB4621@elstar.jacobs.jacobs-university.de>
Mail-Followup-To: Benoit Claise <bclaise@cisco.com>, netmod@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB"
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rfLNQiNZan5DxDF72tpDIMVN3DY
Cc: netmod@ietf.org
Subject: [netmod] request for publications: A YANG Data Model for Routing Management
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 May 2014 15:04:25 -0000

--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Benoit,

attached please find the document writeup for the routing document.

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15

The netmod wg would hereby like to ask the IESG to consider this
document for publication as proposed standard.

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

--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="routing-writeup.txt"

  This is the document writeup for draft-ietf-netmod-routing-cfg-15.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

  Technical Summary:

    This document defines three YANG core data models (ietf-routing,
    ietf-ipv4-unicast-routing, ietf-ipv6-unicast-routing) for
    configuring and managing a routing subsystem. It is expected that
    these modules will be augmented by additional YANG modules
    defining data models for individual routing protocols and other
    related functions.  The core routing data model provides common
    building blocks for such extensions - routing instances, routes,
    routing information bases (RIB), routing protocols and route
    filters.

  Working Group Summary:

    The normal WG process was followed and the documents reflect WG
    consensus with nothing special worth mentioning.

  Document Quality:

    This set of documents received extensive review within the working
    group and ample time was spent to review and reconsider all design
    choices. The document has been reviewed by Martin Bjorklund, who
    is also a YANG doctor. Since the document is heavily touching on
    routing issues, the following routing area reviews have been
    obtained:

     - Early review from the routing area has been requested in Eric
       Gray provided some helpful feedback.

     - Further routing area reviews have been requested in 2012. Yi
       Yang and Thomas Morin provided a review back than.

     - Further reviews were also requested by I2RS people in
       2012. Bruno Rijsman provided a review.

     - The WG last call been posted to the routing directorate in 2013
       and no comments have been received.

    At least one vendor has indicated to implement this data model for
    simple routers. The author has worked on an implementation based
    on the BIRD daemon (almost complete except route filters) and he
    wrote an XSLT stylesheet for an earlier version of this I-D that
    translates data into Cisco IOS syntax.

  Personnel:

    Juergen Schoenwaelder is the Document Shepherd and Benoit Claise
    is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd reviewed the documents for correctness after
  earlier reviews done when the documents were Last Called.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has received several detailed reviews from subject
  matter experts.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  As described under (2), several reviews from the routing area were
  solicitated during the development of the document.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  None

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  We have not received any IPR disclosures. The document editor has
  posted on the mailing list that he is not aware of any IPR affecting
  this document.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is strong concensus. This is not a large working group but it
  is an active and diverse working group with many contributing
  individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  None (those found got fixed before submitting the document)

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  This document has been reviewed by Martin Bjorklund as a YANG
  Doctor.

(13) Have all references within this document been identified as
either normative or informative?

  Yes

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  All normative references are either standards-track documents, BCPs,
  or I-Ds sitting in the RFC Editor queue.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  No

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  The IANA considerations have been reviewed and seem appropriate
  and complete.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The modules have been compiled with pyang 1.3 using the --ietf
  option and everything seems to be fine.

--tThc/1wpZn/ma/RB--