From ietfc@btconnect.com  Tue Aug  2 08:29:34 2011
Return-Path: <ietfc@btconnect.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041BF21F873E for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 08:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.679
X-Spam-Level: 
X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 930rP1USvJkG for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 08:29:33 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0980D21F873A for <netmod@ietf.org>; Tue,  2 Aug 2011 08:29:32 -0700 (PDT)
Received: from pc6 (host109-153-78-164.range109-153.btcentralplus.com [109.153.78.164]) by c2bthomr10.btconnect.com (MOS 4.2.2-FCS) with SMTP id DXI46109; Tue, 2 Aug 2011 16:29:28 +0100
X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4E3817D5.0097, actions=tag
Message-ID: <000f01cc5120$247432a0$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: <phil@juniper.net>, "Martin Bjorklund" <mbj@tail-f.com>, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
References: <012401cc488c$e3c595a0$4001a8c0@gateway.2wire.net><201107221735.p6MHZ38P027700@idle.juniper.net><20110722.200757.407860334.mbj@tail-f.com> <016801cc4924$1e7f20c0$4001a8c0@gateway.2wire.net>
Date: Tue, 2 Aug 2011 16:25:17 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.8.2.143617:17:7.586, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __CP_NAME_BODY, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E3817E1.0056,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: netmod@ietf.org
Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 15:29:34 -0000

I said that I would check out my memory of why I expect mask bits to be
contiguous and I find:

RFC950
 "Subnet Field
      The bit field in an Internet address denoting the subnet number.
      The bits making up this field are not necessarily contiguous in
      the address."

RFC1122
"This notation is not intended to imply that the 1-bits in an address mask need
be contiguous."

RFC1812
 "The <Subnet-number> bits SHOULD be contiguous and fall between the
   <Network-number> and the <Host-number> fields.  More up to date
   protocols do not refer to a subnet mask, but to a prefix length; "

and

" Architecturally
   correct subnet masks are capable of being represented using the
   prefix length description.  They comprise that subset of all possible
   bits patterns that have

     o a contiguous string of ones at the more significant end,
     o a contiguous string of zeros at the less significant end, and
     o no intervening bits.

   Routers SHOULD always treat a route as a network prefix, and SHOULD
   reject configuration and routing information inconsistent with that
   model."

which I would summarise as SHOULD be contiguous.  Some routing protocols and MIB
modules make that a MUST (eg BGP4, OSPFv3).

Tom Petch

----- Original Message -----
From: "t.petch" <ietfc@btconnect.com>
To: <phil@juniper.net>; "Martin Bjorklund" <mbj@tail-f.com>
Cc: <netmod@ietf.org>
Sent: Saturday, July 23, 2011 12:34 PM
Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00


> ----- Original Message -----
> From: "Martin Bjorklund" <mbj@tail-f.com>
> To: <phil@juniper.net>
> Cc: <ietfc@btconnect.com>; <netmod@ietf.org>
> Sent: Friday, July 22, 2011 8:07 PM
> > Phil Shafer <phil@juniper.net> wrote:
> > > "t.petch" writes:
> > > >Ouch; I disagree.  I have come across non-contiguous netmasks invariably
> > > >created by accident and boy, were they a nightmare to track down and put
> > > >right.
> > > >I have not checked what the standards say but my recollection is that
they
> > > >are
> > > >taboo.  (I would say suicidal).
> > >
> > > Suicidal or not, customers use them on both our gear and that other router
> > > company's gear.  We had to implement to allow customers to upgrade to our
> > > boxes, so I know that they are in use and quite intentional.  OSPF doesn't
> > > like this, but it's definitely out there.
> >
> > So the question is if it is worth standardizing, or if a
> > vendor-specific augmentation will do it?
>
> vendor-specific:-)
>
> I will look for the statements that I think exist in standards-track protocol
> RFC about them.  As Juergen says, MIB modules do not support it and I believe
> that that reflects the underlying protocol but I will look some more.
>
> Tom Petch
>
> > /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From kwatsen@juniper.net  Tue Aug  2 13:43:22 2011
Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE1821F85F6 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 13:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZxOOKw1bEpx for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 13:43:21 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 906C321F85F2 for <netmod@ietf.org>; Tue,  2 Aug 2011 13:43:20 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTjhhchZxd9fLLU5LmJ19Q2HCYYe6kaNe@postini.com; Tue, 02 Aug 2011 13:43:30 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 2 Aug 2011 13:43:25 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: "netmod@ietf.org" <netmod@ietf.org>
Date: Tue, 2 Aug 2011 13:43:23 -0700
Thread-Topic: must every yang module have a unique namespace?
Thread-Index: AcxRVNISku1IMghJQCuINybkNIm3zw==
Message-ID: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 20:43:22 -0000

RFC 6020 section 5.3 says:

   All YANG definitions are specified within a module that is bound to a
   particular XML namespace [XML-NAMES], which is a globally unique URI
   [RFC3986].

After discussing this with Martin in Quebec, I understand that the intentio=
n was for each YANG module to have a unique namespace, but my initial readi=
ng of this paragraph did not lead me to this conclusion and, since it's bee=
n pointed out, I question why we care to impose such a restriction.

Regarding my reading of the paragraph, is parsed it in two distinct parts: =
(1) All YANG definitions are specified within a module that is bound to a p=
articular XML namespace and (2) XML namespaces are defined by a globally un=
ique URI, which is true.  I didn't string them together to understand that =
each module had to have unique namespace.  I've also asked a couple colleag=
ues that have a strong command of the English language, and they agreed wit=
h my interpretation.

Regarding my questioning why we care to impose this restriction, this force=
s a technical solution for what could be handled by the maintainers for a *=
shared* namespace - that is, the maintainers could ensure no namespace coll=
isions ever occur within their namespace without ever resorting to declarin=
g a unique namespace per module.  This is what my team has been doing for a=
 couple years now with our proprietary YANG modules...

One way or the other, we need a CLR for this paragraph.  I suggest we relax=
 the constraint since it seems artificially contrived in the first place.  =
Relaxing the constraint would be backwards-compatible with the "intended" i=
nterpretation, so all existing modules would still be valid.

Thoughts?

Thanks,
Kent


From ietf@andybierman.com  Tue Aug  2 14:02:15 2011
Return-Path: <ietf@andybierman.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECBA21F8760 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJwKoy9vtyFa for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:02:15 -0700 (PDT)
Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9508721F8757 for <netmod@ietf.org>; Tue,  2 Aug 2011 14:02:08 -0700 (PDT)
Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p72L2GlP027280 for <netmod@ietf.org>; Tue, 2 Aug 2011 17:02:18 -0400
Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN)
X-Authenticated-UID: andy@andybierman.com
Received: from [75.84.164.152] ([75.84.164.152:58047] helo=[192.168.0.146]) by cm-omr10 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id A6/A3-25295-6D5683E4; Tue, 02 Aug 2011 17:02:16 -0400
Message-ID: <4E3865D3.908@andybierman.com>
Date: Tue, 02 Aug 2011 14:02:11 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 21:02:15 -0000

On 08/02/2011 01:43 PM, Kent Watsen wrote:
>
> RFC 6020 section 5.3 says:
>
>     All YANG definitions are specified within a module that is bound to a
>     particular XML namespace [XML-NAMES], which is a globally unique URI
>     [RFC3986].
>



I do not think the YANG standard needs to be altered to let multiple modules
share the same namespace. (That is what sub-modules are for.)
For modules defined in YANG, the namespace-uri string needs to
be the exact URI identifying content from that module in XML.


Andy


> After discussing this with Martin in Quebec, I understand that the intention was for each YANG module to have a unique namespace, but my initial reading of this paragraph did not lead me to this conclusion and, since it's been pointed out, I question why we care to impose such a restriction.
>
> Regarding my reading of the paragraph, is parsed it in two distinct parts: (1) All YANG definitions are specified within a module that is bound to a particular XML namespace and (2) XML namespaces are defined by a globally unique URI, which is true.  I didn't string them together to understand that each module had to have unique namespace.  I've also asked a couple colleagues that have a strong command of the English language, and they agreed with my interpretation.
>
> Regarding my questioning why we care to impose this restriction, this forces a technical solution for what could be handled by the maintainers for a *shared* namespace - that is, the maintainers could ensure no namespace collisions ever occur within their namespace without ever resorting to declaring a unique namespace per module.  This is what my team has been doing for a couple years now with our proprietary YANG modules...
>
> One way or the other, we need a CLR for this paragraph.  I suggest we relax the constraint since it seems artificially contrived in the first place.  Relaxing the constraint would be backwards-compatible with the "intended" interpretation, so all existing modules would still be valid.
>
> Thoughts?
>
> Thanks,
> Kent
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>


From j.schoenwaelder@jacobs-university.de  Tue Aug  2 14:07:53 2011
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6779711E80A9 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.073
X-Spam-Level: 
X-Spam-Status: No, score=-103.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwuV5es9a6M6 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:07:52 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 95CD711E808F for <netmod@ietf.org>; Tue,  2 Aug 2011 14:07:52 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB84920BE7; Tue,  2 Aug 2011 23:08:01 +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 nLzUSjhZE-ET; Tue,  2 Aug 2011 23:08:00 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68D6820BE4; Tue,  2 Aug 2011 23:08:00 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 07BB21A224F8; Tue,  2 Aug 2011 23:07:59 +0200 (CEST)
Date: Tue, 2 Aug 2011 23:07:59 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.net>
Message-ID: <20110802210759.GA42767@elstar.local>
Mail-Followup-To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 21:07:53 -0000

On Tue, Aug 02, 2011 at 01:43:23PM -0700, Kent Watsen wrote:
> 
> RFC 6020 section 5.3 says:
> 
>    All YANG definitions are specified within a module that is bound to a
>    particular XML namespace [XML-NAMES], which is a globally unique URI
>    [RFC3986].
> 
> After discussing this with Martin in Quebec, I understand that the intention was for each YANG module to have a unique namespace, but my initial reading of this paragraph did not lead me to this conclusion and, since it's been pointed out, I question why we care to impose such a restriction.
> 
> Regarding my reading of the paragraph, is parsed it in two distinct parts: (1) All YANG definitions are specified within a module that is bound to a particular XML namespace and (2) XML namespaces are defined by a globally unique URI, which is true.  I didn't string them together to understand that each module had to have unique namespace.  I've also asked a couple colleagues that have a strong command of the English language, and they agreed with my interpretation.
> 
> Regarding my questioning why we care to impose this restriction, this forces a technical solution for what could be handled by the maintainers for a *shared* namespace - that is, the maintainers could ensure no namespace collisions ever occur within their namespace without ever resorting to declaring a unique namespace per module.  This is what my team has been doing for a couple years now with our proprietary YANG modules...
> 
> One way or the other, we need a CLR for this paragraph.  I suggest we relax the constraint since it seems artificially contrived in the first place.  Relaxing the constraint would be backwards-compatible with the "intended" interpretation, so all existing modules would still be valid.
> 

YANG has submodules and I think they do what you want today without
any changes to YANG.

/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 kwatsen@juniper.net  Tue Aug  2 14:11:03 2011
Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6B221F850B for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czkRRFgnVaEa for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:11:03 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id D777121F84FE for <netmod@ietf.org>; Tue,  2 Aug 2011 14:11:02 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTjhn77JAHYv/dKnSlumeMe7C8jx6GORM@postini.com; Tue, 02 Aug 2011 14:11:13 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 2 Aug 2011 14:08:52 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: Andy Bierman <ietf@andybierman.com>
Date: Tue, 2 Aug 2011 14:08:50 -0700
Thread-Topic: [netmod] must every yang module have a unique namespace?
Thread-Index: AcxRV3fmEuZvql64T2mDXJYIIiYA1wAAGbIQ
Message-ID: <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com>
In-Reply-To: <4E3865D3.908@andybierman.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 21:11:03 -0000

> I do not think the YANG standard needs to be altered to let multiple modu=
les
> share the same namespace. (That is what sub-modules are for.)

Heh - this was also Martin's first comment. =20

We can't use sub-modules because each module is versioned independently and=
 represents an optionally advertized capability, but they are all maintaine=
d by the same project and hence we can ensure no namespace collision can ev=
er occur...

Thanks,
Kent

=20


From j.schoenwaelder@jacobs-university.de  Tue Aug  2 14:23:47 2011
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DD311E8095 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.075
X-Spam-Level: 
X-Spam-Status: No, score=-103.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+ZcKgPh+tik for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:23:45 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA25D11E808F for <netmod@ietf.org>; Tue,  2 Aug 2011 14:23:44 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 905AA20BE9; Tue,  2 Aug 2011 23:23:54 +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 3A44xhVNCANO; Tue,  2 Aug 2011 23:23:53 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B66620BE8; Tue,  2 Aug 2011 23:23:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2BF0D1A225F8; Tue,  2 Aug 2011 23:23:53 +0200 (CEST)
Date: Tue, 2 Aug 2011 23:23:53 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.net>
Message-ID: <20110802212353.GC42767@elstar.local>
Mail-Followup-To: Kent Watsen <kwatsen@juniper.net>, Andy Bierman <ietf@andybierman.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 21:23:47 -0000

On Tue, Aug 02, 2011 at 02:08:50PM -0700, Kent Watsen wrote:
> > I do not think the YANG standard needs to be altered to let multiple modules
> > share the same namespace. (That is what sub-modules are for.)
> 
> Heh - this was also Martin's first comment.  
> 

> We can't use sub-modules because each module is versioned
> independently and represents an optionally advertized capability,
> but they are all maintained by the same project and hence we can
> ensure no namespace collision can ever occur...

What does 'versioned' mean to you? A submodule has its own revision
clauses. The main module includes the versioned submodules and
attaches a revision to it. So it is always clear what is being
referred to.

/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 ietf@andybierman.com  Tue Aug  2 14:27:00 2011
Return-Path: <ietf@andybierman.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10EB11E808F for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH3OMX9wf7TC for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 14:27:00 -0700 (PDT)
Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0207E11E8095 for <netmod@ietf.org>; Tue,  2 Aug 2011 14:26:53 -0700 (PDT)
Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p72LR3gs015206 for <netmod@ietf.org>; Tue, 2 Aug 2011 17:27:03 -0400
Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN)
X-Authenticated-UID: andy@andybierman.com
Received: from [75.84.164.152] ([75.84.164.152:53182] helo=[192.168.0.146]) by cm-omr10 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 06/3F-25295-7AB683E4; Tue, 02 Aug 2011 17:27:03 -0400
Message-ID: <4E386BA3.6000805@andybierman.com>
Date: Tue, 02 Aug 2011 14:26:59 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 21:27:00 -0000

On 08/02/2011 02:08 PM, Kent Watsen wrote:
>> I do not think the YANG standard needs to be altered to let multiple modules
>> share the same namespace. (That is what sub-modules are for.)
>
> Heh - this was also Martin's first comment.
>
> We can't use sub-modules because each module is versioned independently and represents an optionally advertized capability, but they are all maintained by the same project and hence we can ensure no namespace collision can ever occur...
>

I don't agree.
You can put all the sub-modules in the netconf-monitoring <schema> list.
Sub-modules can have revision-stmts.  Include-by-revision can allow
multiple active top-level modules to include different versions of
particular sub-modules.  You can also put a proprietary capability for sub-modules
into the <hello>.

There are lots of options that do not involve breaking the mapping between XML namespace
and globally unique YANG namespace-stmt URI value.


> Thanks,
> Kent
>

Andy


>
>
>
>


From kwatsen@juniper.net  Tue Aug  2 15:25:50 2011
Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4477711E80D7 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 15:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oxfHcDvUo4x for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 15:25:49 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 70BB511E80CD for <netmod@ietf.org>; Tue,  2 Aug 2011 15:25:49 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTjh5c2c+1zXn0salDL1GKEhD/jGYL/he@postini.com; Tue, 02 Aug 2011 15:25:59 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 2 Aug 2011 15:23:56 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Date: Tue, 2 Aug 2011 15:23:54 -0700
Thread-Topic: [netmod] must every yang module have a unique namespace?
Thread-Index: AcxRWn1wVrZtYhmCT269bQzh/r+NhwABRVRQ
Message-ID: <84600D05C20FF943918238042D7670FD3E86E1B0FF@EMBX01-HQ.jnpr.net>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net> <20110802212353.GC42767@elstar.local>
In-Reply-To: <20110802212353.GC42767@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 22:25:50 -0000

> What does 'versioned' mean to you? A submodule has its own revision
> clauses. The main module includes the versioned submodules and
> attaches a revision to it. So it is always clear what is being
> referred to.

Let's assume we have project "X" that defines a number of modules using the=
 *shared* namespace "http://xml.juniper.net/x".  These modules are, for ins=
tance, "hardware", "software", "license", etc.  Each of these modules are i=
ndependently versioned (i.e. a YANG revision) and each of our various devic=
e-teams can pick and choose which modules and which revision of those modul=
es they want their release to support. =20

For instance, we could have the "current release" of routers advertising:

  http://xml.juniper.net/x?module=3Dhardware&revision=3D2010-10-01
  http://xml.juniper.net/x?module=3Dsoftware&revision=3D2008-11-05
  http://xml.juniper.net/x?module=3Dlicense&revision=3D2008-11-05

And Firewalls advertising:

  http://xml.juniper.net/x?module=3Dhardware&revision=3D2008-11-05
  http://xml.juniper.net/x?module=3Dsoftware&revision=3D2010-10-01

And Switches advertising:

  http://xml.juniper.net/x?module=3Dhardware&revision=3D2011-07-28
  http://xml.juniper.net/x?module=3Dsoftware&revision=3D2010-10-01


Of course, we have more kinds of devices and more kinds of modules, so ther=
e are numerous combinations.  I don't know how it is  possible for a single=
 "parent" module to use sub-modules to express this.  Maybe the "deviations=
" concept could do it, but it is too under-specified and hacky for us to ev=
er touch it, especially when the "intention" to force each module to have a=
 unique namespace seems arbitrary and the YANG spec is worded in such a way=
 as allow for our interpretation.

Thanks,
Kent


From ietf@andybierman.com  Tue Aug  2 16:23:19 2011
Return-Path: <ietf@andybierman.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42F011E80DD for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 16:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRFbbnX30mbG for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 16:23:12 -0700 (PDT)
Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF0011E8095 for <netmod@ietf.org>; Tue,  2 Aug 2011 16:23:11 -0700 (PDT)
Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p72NNLTX015328 for <netmod@ietf.org>; Tue, 2 Aug 2011 19:23:21 -0400
Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN)
X-Authenticated-UID: andy@andybierman.com
Received: from [75.84.164.152] ([75.84.164.152:57278] helo=[192.168.0.146]) by cm-omr1 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 03/CA-06308-8E6883E4; Tue, 02 Aug 2011 19:23:21 -0400
Message-ID: <4E3886E5.3030605@andybierman.com>
Date: Tue, 02 Aug 2011 16:23:17 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net> <20110802212353.GC42767@elstar.local> <84600D05C20FF943918238042D7670FD3E86E1B0FF@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD3E86E1B0FF@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 23:23:19 -0000

On 08/02/2011 03:23 PM, Kent Watsen wrote:
>
>> What does 'versioned' mean to you? A submodule has its own revision
>> clauses. The main module includes the versioned submodules and
>> attaches a revision to it. So it is always clear what is being
>> referred to.
>
> Let's assume we have project "X" that defines a number of modules using the *shared* namespace "http://xml.juniper.net/x".  These modules are, for instance, "hardware", "software", "license", etc.  Each of these modules are independently versioned (i.e. a YANG revision) and each of our various device-teams can pick and choose which modules and which revision of those modules they want their release to support.
>
> For instance, we could have the "current release" of routers advertising:
>
>    http://xml.juniper.net/x?module=hardware&revision=2010-10-01
>    http://xml.juniper.net/x?module=software&revision=2008-11-05
>    http://xml.juniper.net/x?module=license&revision=2008-11-05
>
> And Firewalls advertising:
>
>    http://xml.juniper.net/x?module=hardware&revision=2008-11-05
>    http://xml.juniper.net/x?module=software&revision=2010-10-01
>
> And Switches advertising:
>
>    http://xml.juniper.net/x?module=hardware&revision=2011-07-28
>    http://xml.juniper.net/x?module=software&revision=2010-10-01
>

If you are going to advertise multiple YANG files per namespace URI,
then they might as well be sub-modules.  Just advertise all the submodules
and the main module in the <hello>.

I do not agree that deviations are hacky or relevant here.
Your interpretation of YANG XML namespace usage is not
supported by the RFC 6020 text.


>
> Of course, we have more kinds of devices and more kinds of modules, so there are numerous combinations.  I don't know how it is  possible for a single "parent" module to use sub-modules to express this.  Maybe the "deviations" concept could do it, but it is too under-specified and hacky for us to ever touch it, especially when the "intention" to force each module to have a unique namespace seems arbitrary and the YANG spec is worded in such a way as allow for our interpretation.
>
> Thanks,
> Kent
>
>
>

Andy


From kwatsen@juniper.net  Tue Aug  2 16:49:33 2011
Return-Path: <kwatsen@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844321F86BF for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 16:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RXUafKNfxAL for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 16:49:32 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7F21F86C0 for <netmod@ietf.org>; Tue,  2 Aug 2011 16:49:32 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTjiNFI9jkKR4X/UaKCM20YdDuDasv+tr@postini.com; Tue, 02 Aug 2011 16:49:43 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 2 Aug 2011 16:46:53 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: Andy Bierman <ietf@andybierman.com>
Date: Tue, 2 Aug 2011 16:46:51 -0700
Thread-Topic: [netmod] must every yang module have a unique namespace?
Thread-Index: AcxRayyyjhzmHsNrTvWqEsuA2PTV6gAAdCDg
Message-ID: <84600D05C20FF943918238042D7670FD3E86E1B1FB@EMBX01-HQ.jnpr.net>
References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net> <20110802212353.GC42767@elstar.local> <84600D05C20FF943918238042D7670FD3E86E1B0FF@EMBX01-HQ.jnpr.net> <4E3886E5.3030605@andybierman.com>
In-Reply-To: <4E3886E5.3030605@andybierman.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] must every yang module have a unique namespace?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Aug 2011 23:49:33 -0000

> If you are going to advertise multiple YANG files per namespace URI,
> then they might as well be sub-modules.  Just advertise all the submodule=
s
> and the main module in the <hello>.

Huh?  - the arbitrary combinations I mentioned before won't allow it.


> I do not agree that deviations are hacky or relevant here.

I least we agree that deviations are not relevant, albeit for different rea=
sons  ;)


> Your interpretation of YANG XML namespace usage is not
> supported by the RFC 6020 text.

6020 is only unambiguous for standards-based modules (i.e. IETF-defined).  =
Can you source the text, other than what I quoted, that cinches it for non =
standards-based modules?




From randy_presuhn@mindspring.com  Tue Aug  2 19:28:44 2011
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2D11E80BB for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 19:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.516
X-Spam-Level: 
X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbpxgFINnC13 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 19:28:43 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2A411E8081 for <netmod@ietf.org>; Tue,  2 Aug 2011 19:28:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aiILJD0EbW2YWBUb1S/W8vgnsQjXU24efxwJUkmWrMGKT1F1mZe6leO0RiI3uL8I; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.33.92.146] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1QoRCV-0004s0-C3 for netmod@ietf.org; Tue, 02 Aug 2011 22:28:51 -0400
Message-ID: <007201cc5185$ebc29580$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netmod@ietf.org>
References: <012401cc488c$e3c595a0$4001a8c0@gateway.2wire.net><201107221735.p6MHZ38P027700@idle.juniper.net><20110722.200757.407860334.mbj@tail-f.com><016801cc4924$1e7f20c0$4001a8c0@gateway.2wire.net> <000f01cc5120$247432a0$4001a8c0@gateway.2wire.net>
Date: Tue, 2 Aug 2011 19:34:50 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288dc143e9d0fe21b8056af23161ba3c36d350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.92.146
Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Aug 2011 02:28:44 -0000

Hi -

> From: "t.petch" <ietfc@btconnect.com>
> To: <phil@juniper.net>; "Martin Bjorklund" <mbj@tail-f.com>; "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
> Cc: <netmod@ietf.org>
> Sent: Tuesday, August 02, 2011 7:25 AM
> Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00
>
> I said that I would check out my memory of why I expect mask bits to be
> contiguous and I find:
> 
> RFC950
>  "Subnet Field
>       The bit field in an Internet address denoting the subnet number.
>       The bits making up this field are not necessarily contiguous in
>       the address."
> 
> RFC1122
> "This notation is not intended to imply that the 1-bits in an address mask need
> be contiguous."
> 
> RFC1812
>  "The <Subnet-number> bits SHOULD be contiguous and fall between the
>    <Network-number> and the <Host-number> fields.  More up to date
>    protocols do not refer to a subnet mask, but to a prefix length; "
> 
> and
> 
> " Architecturally
>    correct subnet masks are capable of being represented using the
>    prefix length description.  They comprise that subset of all possible
>    bits patterns that have
> 
>      o a contiguous string of ones at the more significant end,
>      o a contiguous string of zeros at the less significant end, and
>      o no intervening bits.
> 
>    Routers SHOULD always treat a route as a network prefix, and SHOULD
>    reject configuration and routing information inconsistent with that
>    model."
> 
> which I would summarise as SHOULD be contiguous.  Some routing protocols and MIB
> modules make that a MUST (eg BGP4, OSPFv3).
...

So where does this lead?  I think...

If the "contiguous" requirement is merely a SHOULD, then the configuration
model needs to be able to represent discontiguous ones as well, since
they are merely discouraged, but not forbidden by the base specifications.
Otherwise, vendors whose equipment supports the possibility of being
configured with discontiguous masks will need to resort to proprietary
models, defeating the purpose of a standard.

Randy


From randy_presuhn@mindspring.com  Tue Aug  2 19:37:51 2011
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4644911E8081 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 19:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.058
X-Spam-Level: 
X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnvlt2-RKU55 for <netmod@ietfa.amsl.com>; Tue,  2 Aug 2011 19:37:50 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 56D2211E8077 for <netmod@ietf.org>; Tue,  2 Aug 2011 19:37:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VDGgkVUbuJsGKGPyYZku2B+9qseaGB/i5IKxsQeVBPFyGYEDZFS2QeajaT8x99kX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.33.92.146] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1QoRLK-0003qc-KK for netmod@ietf.org; Tue, 02 Aug 2011 22:37:58 -0400
Message-ID: <008d01cc5187$335efe00$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netmod@ietf.org>
References: <000601cc4d7c$32087400$6801a8c0@oemcomputer><20110728232433.GB32028@elstar.local><002201cc4d99$c2cc3680$6801a8c0@oemcomputer> <20110729.083334.304026312.mbj@tail-f.com>
Date: Tue, 2 Aug 2011 19:43:59 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee288cc785120d5edbb0414c7d337974d3fbc350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.33.92.146
Subject: Re: [netmod] snmp configuration data model charter addition
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Aug 2011 02:37:51 -0000

Hi -

> From: "Martin Bjorklund" <mbj@tail-f.com>
> To: <randy_presuhn@mindspring.com>
> Cc: <netmod@ietf.org>
> Sent: Friday, July 29, 2011 5:33 AM
> Subject: Re: [netmod] snmp configuration data model charter addition
>
> "Randy Presuhn" <randy_presuhn@mindspring.com> wrote:
> > Perhaps this is what is meant?
> >    5. Data model for configuring SNMP engines. The model must be
> >        capable of representing all SNMP engine configurations possible
> >        with the standard SNMPv3 MIB modules.
> 
> This is not exactly what the current document tries to do.  It is
> capabale of representing all "usable" configurations, but for example,
> the MIBs allow an snmpTargetParamsEntry with:
> 
>   snmpTargetParamsMPModel = 0
>   snmpTargetParamsSecurityModel = 3
> 
> but this is not possible in the YANG model.
> 
> Here's another example: (copy&pasting from a comment...)
> 
> # In some cases, the YANG model imposes stricter constraints on valid
> # configurations than the corresponding MIB model.  For example, the
> # leaf "/snmp/community/tag" is a leafref, which means that in a valid
> # configuration, it MUST refer to an existing target tag, as defined in
> # ^RFC6020^.  There is no such constraint the MIBs.

Consider this case:
   Such a configuration has been put in place using SNMP or other means.
   (a)  What happens when a NETCONF client attempts to
          retrieve that configuration?
   (b)  What happens in a configuration backup / restore scenario when
          NETCONF is the protocol used to shovel the information around
          using this model?

It seems to me that this fails to meet one of the most basic configuration
management use cases.

Randy


From mbj@tail-f.com  Wed Aug 17 14:51:53 2011
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2AA21F8B46 for <netmod@ietfa.amsl.com>; Wed, 17 Aug 2011 14:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gc0Op4UcoYv for <netmod@ietfa.amsl.com>; Wed, 17 Aug 2011 14:51:53 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8B721F8B34 for <netmod@ietf.org>; Wed, 17 Aug 2011 14:51:52 -0700 (PDT)
Received: from localhost (213-65-184-200-no181.tbcn.telia.com [213.65.184.200]) by mail.tail-f.com (Postfix) with ESMTPSA id 919AD1200AF4; Wed, 17 Aug 2011 23:49:26 +0200 (CEST)
Date: Wed, 17 Aug 2011 23:52:38 +0200 (CEST)
Message-Id: <20110817.235238.347463526.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <007201cc5185$ebc29580$6801a8c0@oemcomputer>
References: <016801cc4924$1e7f20c0$4001a8c0@gateway.2wire.net> <000f01cc5120$247432a0$4001a8c0@gateway.2wire.net> <007201cc5185$ebc29580$6801a8c0@oemcomputer>
X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Aug 2011 21:51:53 -0000

"Randy Presuhn" <randy_presuhn@mindspring.com> wrote:
> So where does this lead?  I think...
> 
> If the "contiguous" requirement is merely a SHOULD, then the configuration
> model needs to be able to represent discontiguous ones as well, since
> they are merely discouraged, but not forbidden by the base specifications.
> Otherwise, vendors whose equipment supports the possibility of being
> configured with discontiguous masks will need to resort to proprietary
> models, defeating the purpose of a standard.

Yes, but if the usage of non-contiguous masks are rare, this might
still be ok.

This said, if the WG believes we should support this case, we can do:

         choice subnet {
           leaf prefix-length {
             type uint8 {
               range "0..32";
             }
           }
           leaf netmask {
             type inet:ipv4-address;
           }
         }

And if we want to be even more advanced, we can do:

         choice subnet {
           leaf prefix-length {
             type uint8 {
               range "0..32";
             }
           }
           leaf netmask {
             if-feature non-contiguous-netmasks;
             type inet:ipv4-address;
           }
         }



/martin

From phil@juniper.net  Thu Aug 18 10:57:48 2011
Return-Path: <phil@juniper.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3343E21F871C for <netmod@ietfa.amsl.com>; Thu, 18 Aug 2011 10:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHM8fhYhLqsG for <netmod@ietfa.amsl.com>; Thu, 18 Aug 2011 10:57:47 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6C36721F86EA for <netmod@ietf.org>; Thu, 18 Aug 2011 10:57:44 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTk1SzqZGlN9ZBomDkLYkriOJGbODuLJN@postini.com; Thu, 18 Aug 2011 10:58:42 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 18 Aug 2011 08:36:58 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p7IFas372454; Thu, 18 Aug 2011 08:36:54 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p7IFA8Lp048719; Thu, 18 Aug 2011 15:10:08 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <201108181510.p7IFA8Lp048719@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20110817.235238.347463526.mbj@tail-f.com> 
Date: Thu, 18 Aug 2011 11:10:08 -0400
From: Phil Shafer <phil@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Aug 2011 17:57:48 -0000

Martin Bjorklund writes:
>This said, if the WG believes we should support this case, we can do:
>
>         choice subnet {
>           leaf prefix-length {
>             type uint8 {
>               range "0..32";
>             }
>           }
>           leaf netmask {
>             type inet:ipv4-address;
>           }
>         }
>
>And if we want to be even more advanced, we can do:
>
>         choice subnet {
>           leaf prefix-length {
>             type uint8 {
>               range "0..32";
>             }
>           }
>           leaf netmask {
>             if-feature non-contiguous-netmasks;
>             type inet:ipv4-address;
>           }
>         }

Very slick.  And for places that accept either a prefix or an
address, can we default the prefix-length to 32, right?

Thanks,
 Phil

From mbj@tail-f.com  Fri Aug 19 01:50:10 2011
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3396021F8781 for <netmod@ietfa.amsl.com>; Fri, 19 Aug 2011 01:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU3etElADXrl for <netmod@ietfa.amsl.com>; Fri, 19 Aug 2011 01:50:09 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7883621F877F for <netmod@ietf.org>; Fri, 19 Aug 2011 01:50:09 -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 076BC1200AEF; Fri, 19 Aug 2011 10:47:41 +0200 (CEST)
Date: Fri, 19 Aug 2011 10:51:02 +0200 (CEST)
Message-Id: <20110819.105102.545012517145474189.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <201108181510.p7IFA8Lp048719@idle.juniper.net>
References: <20110817.235238.347463526.mbj@tail-f.com> <201108181510.p7IFA8Lp048719@idle.juniper.net>
X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Aug 2011 08:50:10 -0000

Phil Shafer <phil@juniper.net> wrote:
> Martin Bjorklund writes:
> >This said, if the WG believes we should support this case, we can do:
> >
> >         choice subnet {
> >           leaf prefix-length {
> >             type uint8 {
> >               range "0..32";
> >             }
> >           }
> >           leaf netmask {
> >             type inet:ipv4-address;
> >           }
> >         }
> >
> >And if we want to be even more advanced, we can do:
> >
> >         choice subnet {
> >           leaf prefix-length {
> >             type uint8 {
> >               range "0..32";
> >             }
> >           }
> >           leaf netmask {
> >             if-feature non-contiguous-netmasks;
> >             type inet:ipv4-address;
> >           }
> >         }
> 
> Very slick.  And for places that accept either a prefix or an
> address, can we default the prefix-length to 32, right?

Sorry, I don't understand.  Can you examplify?


/martin

From j.schoenwaelder@jacobs-university.de  Tue Aug 23 23:58:42 2011
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A1621F8B08 for <netmod@ietfa.amsl.com>; Tue, 23 Aug 2011 23:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.092
X-Spam-Level: 
X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KazICgK3YH+3 for <netmod@ietfa.amsl.com>; Tue, 23 Aug 2011 23:58:41 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0004921F8B04 for <netmod@ietf.org>; Tue, 23 Aug 2011 23:58:40 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 597E320BD5 for <netmod@ietf.org>; Wed, 24 Aug 2011 08:59:49 +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 WZ6ukE9t0DUc; Wed, 24 Aug 2011 08:59:47 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B757207B1; Wed, 24 Aug 2011 08:59:47 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 72EF31A388EF; Wed, 24 Aug 2011 08:59:40 +0200 (CEST)
Date: Wed, 24 Aug 2011 08:59:39 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20110824065939.GA36074@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.5.21 (2010-09-15)
Subject: [netmod] [dromasca@avaya.com: [opsarea-chairs] FW: Nomcom 2011-2012: Call for Nominations]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Aug 2011 06:58:42 -0000

Hi,

please think who would be good candidates for our leadership.

/js

----- Forwarded message from "Romascanu, Dan (Dan)" <dromasca@avaya.com> -----

Date: Tue, 23 Aug 2011 11:30:55 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: opsarea-chairs@ietf.org
Subject: [opsarea-chairs] FW: Nomcom 2011-2012: Call for Nominations
Message-ID: <EDC652A26FB23C4EB6384A4584434A0403860771@307622ANEX5.global.avaya.com>

Hi,

Please distribute the Nomcom message to the WG mail lists and invite
participants to nominate the best candidates for the positions that need
to be filled. 

Thanks and Regards,

Dan




-----Original Message-----
From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair
Sent: Tuesday, August 23, 2011 1:30 AM
To: IETF Announcement list
Cc: ietf@ietf.org
Subject: Nomcom 2011-2012: Call for Nominations 

Hi All,

The 2011-2012 Nominating committee is seeking nominations from now 
until October 2, 2011. The list of open positions can be found at:

https://www.ietf.org/group/nomcom/2011/

Nominations may be made directly on the NomCom 2011-2012 pages by 
selecting the Nominate link at the top of the page.  The URL for
NomCom 2011-2012 pages is: 

https://www.ietf.org/group/nomcom/2011/

Nominations may also be made by email to nomcom11@ietf.org.
If you do so, please include the word "Nominate" in the Subject and 
indicate in the email who is being nominated, their email address (to
confirm acceptance of the nomination), and the position for which you 
are making the nomination. If you wish to nominate someone via email 
for more than one position, please use separate emails to do so.

Self nomination is welcome. 

NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing 
Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of 
nominees willing to be considered for positions under review in the 
current NomCom cycle is not confidential". Willing Nominees for each 
position will be publicly listed.  The public nominee list will be 
updated at least once a week and possibly more often as nominations are 
received.

With the exception of publicly listing willing nominees, the 
confidentiality requirements of RFC 3777 remain in effect.  All 
feedback and NomCom deliberations will remain confidential and not 
disclosed. 

Because the list of nominees this year is public, we will accept 
feedback on the nominees starting August 23, 2011. Per RFC 5680, we 
will accept feedback from the entire IETF community on all the nominees.


If you wish to provide anonymous feedback, the chair or any of the 
members will be happy to handle this for you.  The Nominating Committee 
chair can be reached at nomcom-chair@ietf.org and the entire nominating 
committee can be reached at nomcom11@ietf.org. The email addresses of 
individual NomCom members is also on the NomCom 2011-2012 pages.

In addition to nominations, the Nominating Committee is actively
seeking community input on the jobs that need to be filled.  We have
received the job descriptions from the IAB, IESG, and IAOC and they can
be found at:

https://www.ietf.org/group/nomcom/2011/iab-requirements
https://www.ietf.org/group/nomcom/2011/iesg-requirements
https://www.ietf.org/group/nomcom/2011/iaoc-requirements

However, we also need the community's views and input on the jobs 
within each organization. If you have ideas on job responsibilities 
(more, less, different), please let us know.  Please send suggestions 
and feedback to nomcom11@ietf.org. 

Thank you,

Suresh Krishnan
Chair, NomCom 2011-2012
nomcom-chair@ietf.org
suresh.krishnan@ericsson.com
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
opsarea-chairs mailing list
opsarea-chairs@ietf.org
https://www.ietf.org/mailman/listinfo/opsarea-chairs

----- End forwarded message -----

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

From j.schoenwaelder@jacobs-university.de  Fri Aug 26 14:14:31 2011
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF221F8C17 for <netmod@ietfa.amsl.com>; Fri, 26 Aug 2011 14:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.094
X-Spam-Level: 
X-Spam-Status: No, score=-103.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBJYhWyEjTcK for <netmod@ietfa.amsl.com>; Fri, 26 Aug 2011 14:14:30 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 166D621F8B66 for <netmod@ietf.org>; Fri, 26 Aug 2011 14:14:30 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C84B20C08 for <netmod@ietf.org>; Fri, 26 Aug 2011 23:15:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aJB+4gtZyfiU; Fri, 26 Aug 2011 23:15: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 2410320C0D; Fri, 26 Aug 2011 23:15:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C1FB71A3C930; Fri, 26 Aug 2011 23:15:36 +0200 (CEST)
Date: Fri, 26 Aug 2011 23:15:36 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20110826211534.GA41938@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.5.21 (2010-09-15)
Subject: [netmod] minutes of the Quebec meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Aug 2011 21:14:31 -0000

Hi,

I have uploaded the minutes of the Quebec meeting:

http://www.ietf.org/proceedings/81/minutes/netmod.txt

Thanks to Kent Watsen for taking notes. Please send any necessary
corrections to me or the list.

/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 ietf@andybierman.com  Sat Aug 27 10:19:07 2011
Return-Path: <ietf@andybierman.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3FE21F876F for <netmod@ietfa.amsl.com>; Sat, 27 Aug 2011 10:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXVT4tD9sUl4 for <netmod@ietfa.amsl.com>; Sat, 27 Aug 2011 10:19:06 -0700 (PDT)
Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9835A21F86B3 for <netmod@ietf.org>; Sat, 27 Aug 2011 10:19:06 -0700 (PDT)
Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7RHKK5a026064 for <netmod@ietf.org>; Sat, 27 Aug 2011 13:20:25 -0400
Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN)
X-Authenticated-UID: andy@andybierman.com
Received: from [75.84.164.152] ([75.84.164.152:51521] helo=[192.168.0.146]) by cm-omr11 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C1/29-01304-457295E4; Sat, 27 Aug 2011 13:20:20 -0400
Message-ID: <4E592768.1060702@andybierman.com>
Date: Sat, 27 Aug 2011 10:20:40 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
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
Subject: [netmod] bug in RFC 6020
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Aug 2011 17:19:07 -0000

Hi,

I was looking into a yuma bug report on leafrefs, so I re-read RFC 6020,
and I can't believe we missed this...

The ABNF clearly shows that the 'require-instance' statement is allowed
in a leafref definition:

    leafref-specification =
                          ;; these stmts can appear in any order
                          path-stmt stmtsep
                          [require-instance-stmt stmtsep]


Yet in sec 9.9 (leafref builtin type):

9.9.1.  Restrictions

    A leafref cannot be restricted.

Compare that with the instance-identifier (9.13.1 and 9.13.2) for the correct text.

I remember from interim meetings and mailing list discussion that the intent of the NETMOD WG
is reflected in the ABNF, not the normative definition.  Does anybody remember it differently?
Which is correct? The ABNF or section 9.9.1?


Andy

From ietf@andybierman.com  Sat Aug 27 11:07:07 2011
Return-Path: <ietf@andybierman.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012FF21F877B for <netmod@ietfa.amsl.com>; Sat, 27 Aug 2011 11:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrYicPuNL3a4 for <netmod@ietfa.amsl.com>; Sat, 27 Aug 2011 11:07:06 -0700 (PDT)
Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id F376E21F8B0F for <netmod@ietf.org>; Sat, 27 Aug 2011 11:07:05 -0700 (PDT)
Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7RI8PLt029476 for <netmod@ietf.org>; Sat, 27 Aug 2011 14:08:25 -0400
Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN)
X-Authenticated-UID: andy@andybierman.com
Received: from [75.84.164.152] ([75.84.164.152:52039] helo=[192.168.0.146]) by cm-omr3 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 30/D5-21584-892395E4; Sat, 27 Aug 2011 14:08:25 -0400
Message-ID: <4E5932AC.2060402@andybierman.com>
Date: Sat, 27 Aug 2011 11:08:44 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
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
Subject: [netmod] when are 'when' and leafref checked?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Aug 2011 18:07:07 -0000

Hi,

1) when-stmt:

The 'when-stmt' is not considered a validation constraint wrt/
constraint rules of procedure in sec. 8.3. It is supposed to have
instant results (8.3.2, last bullet).  All false when-stmt nodes
are supposed to all get deleted as part of the edit-config that
changes a value (causing the new false result to occur).

This introduces ordering requirements into edit-config,
and goes against the scratchpad design of the candidate.

Martin says it is a feature that when-stmt works like choice-stmt
and automatically deletes nodes right away.

But it also applies to nodes you are creating in the candidate, not
just the ones already there.  Any node with a when-stmt becomes
an order-dependency statement.  The nodes in the when-stmt expression have to
all be set up first, then the node with the when-stmt.  And if
those nodes have when-stmts, it gets really complicated.

IMO the value of the candidate is greatly diminished if the client
cannot build up a valid config with any sequence of partial edits.


2) leafref-stmt)

The text in 9.9 is not really clear about when a leafref type
needs to be valid:

    The leafref type is used to reference a particular leaf instance in
    the data tree.

This is code for the current tree.  Otherwise the text would mention
a valid configuration.  But 8.3.3 clearly says a leafref is checked
during a 'validate':

    o  Any referential integrity constraints defined via the "path"
       statement MUST be satisfied.

So is a leafref path-stmt included here?
leafref-stmt is the only one that uses path-stmt, so it must.
Is the text in sec. 9.9 incomplete or wrong?



Andy



From mbj@tail-f.com  Sun Aug 28 13:42:35 2011
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7225721F85C6 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 13:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBXo92Ey8AZT for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 13:42:34 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 89AEF21F85B1 for <netmod@ietf.org>; Sun, 28 Aug 2011 13:42:34 -0700 (PDT)
Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B0AD1200AF4; Sun, 28 Aug 2011 22:39:45 +0200 (CEST)
Date: Sun, 28 Aug 2011 22:43:52 +0200 (CEST)
Message-Id: <20110828.224352.273878340.mbj@tail-f.com>
To: ietf@andybierman.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4E592768.1060702@andybierman.com>
References: <4E592768.1060702@andybierman.com>
X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in RFC 6020
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Aug 2011 20:42:35 -0000

Hi,

Andy Bierman <ietf@andybierman.com> wrote:
> I remember from interim meetings and mailing list discussion that the intent of
> the NETMOD WG
> is reflected in the ABNF, not the normative definition.  Does anybody remember
> it differently?
> Which is correct? The ABNF or section 9.9.1?

(Unfortunatley) section 9.9.1 is correct and the ABNF is wrong.

require-instance on leafrefs was there, but removed in WG draft -06.
There are a couple of ML threads around April-June 2009, e.g., one
called "leafref issues" discussing the semantics of leafrefs, and
after that, the consensus was to remove require-instance for leafrefs.


/martin

From ietf@andybierman.com  Sun Aug 28 16:00:26 2011
Return-Path: <ietf@andybierman.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7416221F8726 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 16:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level: 
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INIuD4G-6+l9 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 16:00:25 -0700 (PDT)
Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id B1E6E21F86FF for <netmod@ietf.org>; Sun, 28 Aug 2011 16:00:25 -0700 (PDT)
Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7SN1jun008874 for <netmod@ietf.org>; Sun, 28 Aug 2011 19:01:47 -0400
Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN)
X-Authenticated-UID: andy@andybierman.com
Received: from [75.84.164.152] ([75.84.164.152:60929] helo=[192.168.0.146]) by cm-omr7 (envelope-from <ietf@andybierman.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C2/75-15332-8D8CA5E4; Sun, 28 Aug 2011 19:01:45 -0400
Message-ID: <4E5AC8F6.3050007@andybierman.com>
Date: Sun, 28 Aug 2011 16:02:14 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4E592768.1060702@andybierman.com> <20110828.224352.273878340.mbj@tail-f.com>
In-Reply-To: <20110828.224352.273878340.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] bug in RFC 6020
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Aug 2011 23:00:26 -0000

On 08/28/2011 01:43 PM, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman<ietf@andybierman.com>  wrote:
>> I remember from interim meetings and mailing list discussion that the intent of
>> the NETMOD WG
>> is reflected in the ABNF, not the normative definition.  Does anybody remember
>> it differently?
>> Which is correct? The ABNF or section 9.9.1?
>
> (Unfortunatley) section 9.9.1 is correct and the ABNF is wrong.
>
> require-instance on leafrefs was there, but removed in WG draft -06.
> There are a couple of ML threads around April-June 2009, e.g., one
> called "leafref issues" discussing the semantics of leafrefs, and
> after that, the consensus was to remove require-instance for leafrefs.
>
>

That explains why there is a field for it in the yuma code
but the parser code never sets it -- because YANG doesn't allow
require-instance for a leafref.

Is there an Errata node for the ABNF already?

Also, what about the text that seems to indicate leafref instance checking
is done right away (at edit-config time) even though it clearly is done
when a config is validated? IMO, the leafref builtin type section
could be more clear the constraint refers to a valid datastore, not a data tree.


> /martin
>
>

Andy

From wwwrun@rfc-editor.org  Sun Aug 28 18:08:42 2011
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8522921F8772 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 18:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level: 
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C1m+8qj3n-6 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 18:08:42 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 24FDD21F86BE for <netmod@ietf.org>; Sun, 28 Aug 2011 18:08:42 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7E5D998C24A; Sun, 28 Aug 2011 18:09:49 -0700 (PDT)
To: mbj@tail-f.com, dromasca@avaya.com, rbonica@juniper.net, david.kessens@nsn.com, j.schoenwaelder@jacobs-university.de
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20110829010949.7E5D998C24A@rfc-editor.org>
Date: Sun, 28 Aug 2011 18:09:49 -0700 (PDT)
Cc: netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6020 (2949)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2011 01:08:42 -0000

The following errata report has been submitted for RFC6020,
"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=2949

--------------------------------------
Type: Technical
Reported by: Andy Bierman <biermana@brocade.com>

Section: 12

Original Text
-------------
(top of page 149)

 leafref-specification =
                         ;; these stmts can appear in any order
                         path-stmt stmtsep
                         [require-instance-stmt stmtsep]


Corrected Text
--------------
 leafref-specification = path-stmt stmtsep


Notes
-----
require-instance-stmt not allowed in leafref

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6020 (draft-ietf-netmod-yang-13)
--------------------------------------
Title               : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
Publication Date    : October 2010
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

From lhotka@cesnet.cz  Sun Aug 28 23:38:46 2011
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CCB21F85F2 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 23:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSYT6A7A1iN6 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 23:38:46 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 11D6E21F85C6 for <netmod@ietf.org>; Sun, 28 Aug 2011 23:38:45 -0700 (PDT)
Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9A0AA2CDE059; Mon, 29 Aug 2011 08:40:05 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-1--862127554; protocol="application/pkcs7-signature"; micalg=sha1
From: Ladislav Lhotka <lhotka@cesnet.cz>
In-Reply-To: <4E5932AC.2060402@andybierman.com>
Date: Mon, 29 Aug 2011 08:40:04 +0200
Message-Id: <8EEEB78B-3741-4720-922A-79BDE559B556@cesnet.cz>
References: <4E5932AC.2060402@andybierman.com>
To: Andy Bierman <ietf@andybierman.com>
X-Mailer: Apple Mail (2.1084)
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] when are 'when' and leafref checked?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2011 06:38:47 -0000

--Apple-Mail-1--862127554
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Aug 27, 2011, at 8:08 PM, Andy Bierman wrote:

> Hi,
>=20
> 1) when-stmt:
>=20
> The 'when-stmt' is not considered a validation constraint wrt/
> constraint rules of procedure in sec. 8.3. It is supposed to have
> instant results (8.3.2, last bullet).  All false when-stmt nodes
> are supposed to all get deleted as part of the edit-config that
> changes a value (causing the new false result to occur).
>=20
> This introduces ordering requirements into edit-config,
> and goes against the scratchpad design of the candidate.
>=20
> Martin says it is a feature that when-stmt works like choice-stmt
> and automatically deletes nodes right away.

The big difference between when-stmt and choice-stmt is that the latter =
by design never depends on node *values*.

The auto-deletion behaviour also goes against the principle of least =
embarrassment in that a trivial typo in a node value may potentially =
lead to deletion of large parts of candidate.

>=20
> But it also applies to nodes you are creating in the candidate, not
> just the ones already there.  Any node with a when-stmt becomes
> an order-dependency statement.  The nodes in the when-stmt expression =
have to
> all be set up first, then the node with the when-stmt.  And if
> those nodes have when-stmts, it gets really complicated.
>=20
> IMO the value of the candidate is greatly diminished if the client
> cannot build up a valid config with any sequence of partial edits.

I agree. Only grammatical and data type constraints should be enforced =
for candidate and the rest should be checked during commit. In fact, =
I've been thinking about introducing a new "sandbox" datastore with this =
semantics in our Netopeer implementation.

Lada

>=20
>=20
> 2) leafref-stmt)
>=20
> The text in 9.9 is not really clear about when a leafref type
> needs to be valid:
>=20
>   The leafref type is used to reference a particular leaf instance in
>   the data tree.
>=20
> This is code for the current tree.  Otherwise the text would mention
> a valid configuration.  But 8.3.3 clearly says a leafref is checked
> during a 'validate':
>=20
>   o  Any referential integrity constraints defined via the "path"
>      statement MUST be satisfied.
>=20
> So is a leafref path-stmt included here?
> leafref-stmt is the only one that uses path-stmt, so it must.
> Is the text in sec. 9.9 incomplete or wrong?
>=20
>=20
>=20
> Andy
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C





--Apple-Mail-1--862127554
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw
ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT
MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS
VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD
ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy
bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek
KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU
6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr
Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0
1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID
AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6
NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB
hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw
MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG
SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS
k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ
x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0
+B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6
+iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ
J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML
QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD
VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw
NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp
dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51
c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv
biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu
zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o
kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n
NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD
/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X
KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL
VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy
dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb
fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l
RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82
u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O
P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl
/i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA
MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h
bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD
VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3
MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L
eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON
kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv
kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy
/b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf
EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud
DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/
BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs
Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h
Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl
cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl
c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut
ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz
ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ
xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl
5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC
BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT
AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV
U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD
VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw
NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B
MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q
JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG
KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W
JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb
A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW
gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD
VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC
HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz
dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB
BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG
AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT
LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT
stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p
AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q
yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher
qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G
A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv
Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMTEwODI5MDY0MDA1WjAjBgkqhkiG9w0BCQQxFgQUUTG2FFvCETkP291B5gB0jJWSVkcwXgYJ
KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU
RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx
CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD
QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBbK5+zFFskFSSZ+S68xef2f3Xx
0eimIdt0ObpvI59yFNdfPGskR1Ya3s97kYSYYEJOOD283Do5nJgQXR8UgnI6g8NnVBc4oYrotEYp
hSKAy7W1xUbTowHR47B/UyGIer8sKw1Oh4A7XnDYe6d+0Amamu53CPlcrc8pSAJxZJ4MdSEKH+UB
AKK6umLj0TkpnSP2PmJW4y+R0WczPs3QtIIp8NlOaHdij9d4QLD9NBhX3BGzRO+6UeVEQnvKNg29
NdGG9trDcIkOMJzz1Zm67OZ05u0rK9gcLdFK1rZxtbUJ1cmwb7u+dqPaePsctj66e+ZDl7zx9WGi
y6UC0CV5JKNNAAAAAAAA

--Apple-Mail-1--862127554--

From mbj@tail-f.com  Sun Aug 28 23:45:59 2011
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14FF21F84F8 for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 23:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvuk4xikbKjW for <netmod@ietfa.amsl.com>; Sun, 28 Aug 2011 23:45:59 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 236BF21F84EF for <netmod@ietf.org>; Sun, 28 Aug 2011 23:45:59 -0700 (PDT)
Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 714441200043; Mon, 29 Aug 2011 08:43:10 +0200 (CEST)
Date: Mon, 29 Aug 2011 08:47:20 +0200 (CEST)
Message-Id: <20110829.084720.490402441.mbj@tail-f.com>
To: ietf@andybierman.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4E5932AC.2060402@andybierman.com>
References: <4E5932AC.2060402@andybierman.com>
X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] when are 'when' and leafref checked?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2011 06:45:59 -0000

Andy Bierman <ietf@andybierman.com> wrote:
> 2) leafref-stmt)
> 
> The text in 9.9 is not really clear about when a leafref type
> needs to be valid:
> 
>    The leafref type is used to reference a particular leaf instance in
>    the data tree.
> 
> This is code for the current tree.  Otherwise the text would mention
> a valid configuration.  But 8.3.3 clearly says a leafref is checked
> during a 'validate':
> 
>    o  Any referential integrity constraints defined via the "path"
>       statement MUST be satisfied.
> 
> So is a leafref path-stmt included here?
> leafref-stmt is the only one that uses path-stmt, so it must.
> Is the text in sec. 9.9 incomplete or wrong?

9.9 also says:

   All leafref nodes MUST reference
   existing leaf instances or leafs with default values in use (see
   Section 7.6.1) for the data to be valid.  This constraint is enforced
   according to the rules in Section 8.

So I think it is clear from 9.9 when this constraint is enforced.

I fear I might have misunderstood your concern.


/martin

From dromasca@avaya.com  Mon Aug 29 01:29:36 2011
Return-Path: <dromasca@avaya.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7371721F886A for <netmod@ietfa.amsl.com>; Mon, 29 Aug 2011 01:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.902
X-Spam-Level: 
X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQjWSLirILXI for <netmod@ietfa.amsl.com>; Mon, 29 Aug 2011 01:29:35 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C712121F874B for <netmod@ietf.org>; Mon, 29 Aug 2011 01:29:35 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArAAAK1NW06HCzI1/2dsb2JhbAAoGpgbj153gUABAQEBAxIeCj8MBAIBCA0DAQQBAQsGDAsBBgFFCQgBAQQBEggah1QjmiMCmy6FbGAEmEuLWmk
X-IronPort-AV: E=Sophos;i="4.68,296,1312171200"; d="scan'208";a="204498436"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Aug 2011 04:30:59 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Aug 2011 04:22:20 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 29 Aug 2011 10:30:56 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04038D661E@307622ANEX5.global.avaya.com>
In-Reply-To: <20110829010949.7E5D998C24A@rfc-editor.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Technical Errata Reported] RFC6020 (2949)
Thread-Index: Acxl6GW3kIdPpn++SyihGaOX6W0ArQAPKeow
References: <20110829010949.7E5D998C24A@rfc-editor.org>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "RFC Errata System" <rfc-editor@rfc-editor.org>, <mbj@tail-f.com>, <rbonica@juniper.net>, <david.kessens@nsn.com>, <j.schoenwaelder@jacobs-university.de>
Cc: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (2949)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2011 08:29:36 -0000

Two questions:=20

1. Does everybody agree with the opinions of Andy and Martin that the
bug is in the ABNF?=20
2. If the answer to the above is yes - Should we mark this erratum as
'Verified' or as 'Hold for document update'? With bugs in MIB modules I
usually am taking the later approach, as a change in a MIB module
implies a change in the version. Here we are dealing with the basic
definition of the language, the text in section 9.9.1 is OK and the ABNF
mistaken, so we could go both ways.=20

Thanks and Regards,

Dan




> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Sent: Monday, August 29, 2011 4:10 AM
> To: mbj@tail-f.com; Romascanu, Dan (Dan); rbonica@juniper.net;
> david.kessens@nsn.com; j.schoenwaelder@jacobs-university.de
> Cc: biermana@brocade.com; netmod@ietf.org; rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC6020 (2949)
>=20
>=20
> The following errata report has been submitted for RFC6020,
> "YANG - A Data Modeling Language for the Network Configuration
Protocol
> (NETCONF)".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D2949
>=20
> --------------------------------------
> Type: Technical
> Reported by: Andy Bierman <biermana@brocade.com>
>=20
> Section: 12
>=20
> Original Text
> -------------
> (top of page 149)
>=20
>=20
>=20
>  leafref-specification =3D
>=20
>                          ;; these stmts can appear in any order
>=20
>                          path-stmt stmtsep
>=20
>                          [require-instance-stmt stmtsep]
>=20
>=20
>=20
> Corrected Text
> --------------
>  leafref-specification =3D path-stmt stmtsep
>=20
>=20
>=20
> Notes
> -----
> require-instance-stmt not allowed in leafref
>=20
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>=20
> --------------------------------------
> RFC6020 (draft-ietf-netmod-yang-13)
> --------------------------------------
> Title               : YANG - A Data Modeling Language for the Network
> Configuration Protocol (NETCONF)
> Publication Date    : October 2010
> Author(s)           : M. Bjorklund, Ed.
> Category            : PROPOSED STANDARD
> Source              : NETCONF Data Modeling Language
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG

From lhotka@cesnet.cz  Mon Aug 29 02:23:03 2011
Return-Path: <lhotka@cesnet.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4E621F891D for <netmod@ietfa.amsl.com>; Mon, 29 Aug 2011 02:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level: 
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q9Yn06Ty9MU for <netmod@ietfa.amsl.com>; Mon, 29 Aug 2011 02:23:03 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id D77FC21F8839 for <netmod@ietf.org>; Mon, 29 Aug 2011 02:23:02 -0700 (PDT)
Received: from stardust-w.lhotkovi.cz (unknown [IPv6:2001:718:1a02:7:5ab0:35ff:fe73:8f1d]) by office2.cesnet.cz (Postfix) with ESMTPSA id 410CC2CDE059; Mon, 29 Aug 2011 11:24:26 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-2--852266746; protocol="application/pkcs7-signature"; micalg=sha1
From: Ladislav Lhotka <lhotka@cesnet.cz>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A04038D661E@307622ANEX5.global.avaya.com>
Date: Mon, 29 Aug 2011 11:24:25 +0200
Message-Id: <A9EC3CC1-A403-4C93-9571-D45A106703A7@cesnet.cz>
References: <20110829010949.7E5D998C24A@rfc-editor.org> <EDC652A26FB23C4EB6384A4584434A04038D661E@307622ANEX5.global.avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-Mailer: Apple Mail (2.1084)
Cc: netmod@ietf.org, rbonica@juniper.net, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (2949)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Aug 2011 09:23:03 -0000

--Apple-Mail-2--852266746
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Aug 29, 2011, at 10:30 AM, Romascanu, Dan (Dan) wrote:

> Two questions:=20
>=20
> 1. Does everybody agree with the opinions of Andy and Martin that the
> bug is in the ABNF?=20

Yes, definitely.

> 2. If the answer to the above is yes - Should we mark this erratum as
> 'Verified' or as 'Hold for document update'? With bugs in MIB modules =
I
> usually am taking the later approach, as a change in a MIB module
> implies a change in the version. Here we are dealing with the basic
> definition of the language, the text in section 9.9.1 is OK and the =
ABNF
> mistaken, so we could go both ways.

I think the erratum should be available to implementors asap, so the =
former options seems more appropriate.

Lada
=20
>=20
>=20
> Thanks and Regards,
>=20
> Dan
>=20
>=20
>=20
>=20
>> -----Original Message-----
>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>> Sent: Monday, August 29, 2011 4:10 AM
>> To: mbj@tail-f.com; Romascanu, Dan (Dan); rbonica@juniper.net;
>> david.kessens@nsn.com; j.schoenwaelder@jacobs-university.de
>> Cc: biermana@brocade.com; netmod@ietf.org; rfc-editor@rfc-editor.org
>> Subject: [Technical Errata Reported] RFC6020 (2949)
>>=20
>>=20
>> The following errata report has been submitted for RFC6020,
>> "YANG - A Data Modeling Language for the Network Configuration
> Protocol
>> (NETCONF)".
>>=20
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D2949
>>=20
>> --------------------------------------
>> Type: Technical
>> Reported by: Andy Bierman <biermana@brocade.com>
>>=20
>> Section: 12
>>=20
>> Original Text
>> -------------
>> (top of page 149)
>>=20
>>=20
>>=20
>> leafref-specification =3D
>>=20
>>                         ;; these stmts can appear in any order
>>=20
>>                         path-stmt stmtsep
>>=20
>>                         [require-instance-stmt stmtsep]
>>=20
>>=20
>>=20
>> Corrected Text
>> --------------
>> leafref-specification =3D path-stmt stmtsep
>>=20
>>=20
>>=20
>> Notes
>> -----
>> require-instance-stmt not allowed in leafref
>>=20
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>=20
>> --------------------------------------
>> RFC6020 (draft-ietf-netmod-yang-13)
>> --------------------------------------
>> Title               : YANG - A Data Modeling Language for the Network
>> Configuration Protocol (NETCONF)
>> Publication Date    : October 2010
>> Author(s)           : M. Bjorklund, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : NETCONF Data Modeling Language
>> Area                : Operations and Management
>> Stream              : IETF
>> Verifying Party     : IESG
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C





--Apple-Mail-2--852266746
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw
ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT
MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS
VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD
ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy
bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek
KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU
6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr
Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0
1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID
AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6
NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB
hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw
MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG
SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS
k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ
x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0
+B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6
+iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ
J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML
QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD
VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw
NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp
dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51
c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv
biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu
zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o
kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n
NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD
/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X
KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL
VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB
Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy
dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb
fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l
RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82
u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O
P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl
/i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA
MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h
bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD
VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3
MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L
eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON
kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv
kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy
/b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf
EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud
DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd
BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/
BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs
Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h
Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl
cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl
c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut
ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz
ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ
xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl
5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC
BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT
AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV
U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD
VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw
NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B
MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q
JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG
KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W
JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb
A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW
gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD
VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC
HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz
dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB
BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG
AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT
LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT
stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p
AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q
yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher
qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G
A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv
Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMTEwODI5MDkyNDI2WjAjBgkqhkiG9w0BCQQxFgQU7sfpBaQW3Ya9l/urzNiMVNckDggwXgYJ
KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU
RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx
CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD
QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAa/BeFeTiFNP4Mw7x2ebQQVwkL
6LQEZiWklMDe9nsbdw8rffpKbOYkl/BB2jka+3h18aGgE/93j+2AWSWTzct8MQObNZWeci+E4Kd1
//scryDCrGImllrDaC1riNk8WCKbuso2L4hhYLsG9cKh+2QhVVVU1EXAgDSqjoqqr/udfKrK7aYj
4BCGvZr/d7toSpODFhtHKkDfrIqsUn8BoHOd+aL4MV7Bvlw6r8veRJArMF2Jqm0pV3j93rsCd//U
QXP0oSEHn7524envCfBDsKEMKCaqy1sSp2kiOvybz5vCuHLJYV3IRx/AOLcTu25UQNpxrL5lkv6D
2ZmphnsFv3fgAAAAAAAA

--Apple-Mail-2--852266746--

From david.kessens@nsn.com  Tue Aug 30 12:45:42 2011
Return-Path: <david.kessens@nsn.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AC821F8E9B for <netmod@ietfa.amsl.com>; Tue, 30 Aug 2011 12:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.399
X-Spam-Level: 
X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JUM0wvK8yH0 for <netmod@ietfa.amsl.com>; Tue, 30 Aug 2011 12:45:41 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 09BA421F8E99 for <netmod@ietf.org>; Tue, 30 Aug 2011 12:45:40 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p7UJl118015743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2011 21:47:01 +0200
Received: from localhost.localdomain ([10.138.51.172]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7UJkuW8002121; Tue, 30 Aug 2011 21:46:58 +0200
Received: from localhost.localdomain (X1 [127.0.0.1]) by localhost.localdomain (8.14.4/8.14.4) with ESMTP id p7UJktDO012339;  Tue, 30 Aug 2011 12:46:56 -0700
Received: (from david@localhost) by localhost.localdomain (8.14.4/8.14.4/Submit) id p7UJkqbE012337; Tue, 30 Aug 2011 12:46:52 -0700
X-Authentication-Warning: localhost.localdomain: david set sender to david.kessens@nsn.com using -f
Date: Tue, 30 Aug 2011 12:46:52 -0700
From: David Kessens <david.kessens@nsn.com>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Message-ID: <20110830194652.GG7262@nsn.com>
References: <20110829010949.7E5D998C24A@rfc-editor.org> <EDC652A26FB23C4EB6384A4584434A04038D661E@307622ANEX5.global.avaya.com> <A9EC3CC1-A403-4C93-9571-D45A106703A7@cesnet.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A9EC3CC1-A403-4C93-9571-D45A106703A7@cesnet.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org, rbonica@juniper.net, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (2949)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Aug 2011 19:45:42 -0000

Dan,

I agree with Lada.

David Kessens
---

On Mon, Aug 29, 2011 at 11:24:25AM +0200, Ladislav Lhotka wrote:
> 
> On Aug 29, 2011, at 10:30 AM, Romascanu, Dan (Dan) wrote:
> 
> > Two questions: 
> > 
> > 1. Does everybody agree with the opinions of Andy and Martin that the
> > bug is in the ABNF? 
> 
> Yes, definitely.
> 
> > 2. If the answer to the above is yes - Should we mark this erratum as
> > 'Verified' or as 'Hold for document update'? With bugs in MIB modules I
> > usually am taking the later approach, as a change in a MIB module
> > implies a change in the version. Here we are dealing with the basic
> > definition of the language, the text in section 9.9.1 is OK and the ABNF
> > mistaken, so we could go both ways.
> 
> I think the erratum should be available to implementors asap, so the former options seems more appropriate.
> 
> Lada
>  
> > 
> > 
> > Thanks and Regards,
> > 
> > Dan
> > 
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> >> Sent: Monday, August 29, 2011 4:10 AM
> >> To: mbj@tail-f.com; Romascanu, Dan (Dan); rbonica@juniper.net;
> >> david.kessens@nsn.com; j.schoenwaelder@jacobs-university.de
> >> Cc: biermana@brocade.com; netmod@ietf.org; rfc-editor@rfc-editor.org
> >> Subject: [Technical Errata Reported] RFC6020 (2949)
> >> 
> >> 
> >> The following errata report has been submitted for RFC6020,
> >> "YANG - A Data Modeling Language for the Network Configuration
> > Protocol
> >> (NETCONF)".
> >> 
> >> --------------------------------------
> >> You may review the report below and at:
> >> http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=2949
> >> 
> >> --------------------------------------
> >> Type: Technical
> >> Reported by: Andy Bierman <biermana@brocade.com>
> >> 
> >> Section: 12
> >> 
> >> Original Text
> >> -------------
> >> (top of page 149)
> >> 
> >> 
> >> 
> >> leafref-specification =
> >> 
> >>                         ;; these stmts can appear in any order
> >> 
> >>                         path-stmt stmtsep
> >> 
> >>                         [require-instance-stmt stmtsep]
> >> 
> >> 
> >> 
> >> Corrected Text
> >> --------------
> >> leafref-specification = path-stmt stmtsep
> >> 
> >> 
> >> 
> >> Notes
> >> -----
> >> require-instance-stmt not allowed in leafref
> >> 
> >> Instructions:
> >> -------------
> >> This errata is currently posted as "Reported". If necessary, please
> >> use "Reply All" to discuss whether it should be verified or
> >> rejected. When a decision is reached, the verifying party (IESG)
> >> can log in to change the status and edit the report, if necessary.
> >> 
> >> --------------------------------------
> >> RFC6020 (draft-ietf-netmod-yang-13)
> >> --------------------------------------
> >> Title               : YANG - A Data Modeling Language for the Network
> >> Configuration Protocol (NETCONF)
> >> Publication Date    : October 2010
> >> Author(s)           : M. Bjorklund, Ed.
> >> Category            : PROPOSED STANDARD
> >> Source              : NETCONF Data Modeling Language
> >> Area                : Operations and Management
> >> Stream              : IETF
> >> Verifying Party     : IESG
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C
> 
> 
> 
> 



David Kessens
---