From lhotka@nic.cz Fri Feb 1 01:29:45 2013 Return-Path: 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 E64EC21F879B for ; Fri, 1 Feb 2013 01:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 P1sNLVg3e1uq for ; Fri, 1 Feb 2013 01:29:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 187B121F8812 for ; Fri, 1 Feb 2013 01:29:43 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 026A413F9A9; Fri, 1 Feb 2013 10:29:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1359710982; bh=FgsyhTMpvlnYGgENNYWC64ghaeQGRXWM74F5/VPvUf0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tgiDSwB7xjwKyZAE44HIEHCyuOseAAUUdk6lsu/eXRVI8x4X/K4n6oY5/ZEUawWRZ oeFJRpxUr5JDB417QpuNzmNpyWEEskS7fUrp3PMcz3ZBKS1LMe3XWsD16IJNd4ZM/k NgSQZAx8SCAZdNlk4b3OtRR27fsL7/4dIxf0pvtE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130131.203734.312880471.mbj@tail-f.com> Date: Fri, 1 Feb 2013 10:29:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6CA2CA17-9FBD-4CE1-8F5F-F55663D1A226@nic.cz> References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> <20130131.203734.312880471.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 09:29:46 -0000 On Jan 31, 2013, at 8:37 PM, Martin Bjorklund wrote: > Hi, >=20 > Andy Bierman wrote: >> Hi, >>=20 >> IMO, the best solution would be if the tool authors would write >> a short RFC defining the syntax and showing a few examples. >=20 > Since we don't want to wait for that document at this point, I suggest > we do as the rest of the current documents, and include something > like this: >=20 > 1.2. Tree Diagrams >=20 > A simplified graphical representation of the data model is used in > this document. The meaning of the symbols in these diagrams is as > follows: >=20 > o Brackets "[" and "]" enclose list keys. >=20 > o Abbreviations before data node names: "rw" means configuration > (read-write) and "ro" state data (read-only). >=20 > o Symbols after data node names: "?" means an optional node and "*" > denotes a "leaf-list". >=20 > o Parentheses enclose choice and case nodes, and case nodes are = also > marked with a colon (":"). Quite often, the trees are collapsed in some way, and then there should = be a fourth item like this: o Ellipsis ("...") stands for contents of subtrees that are not shown.=20 The best place for that subsection is probably the "Terminology and = Notation" section. Lada >=20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Feb 1 10:00:36 2013 Return-Path: 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 9D5E821E8041 for ; Fri, 1 Feb 2013 10:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 yW6T6vIqSz+M for ; Fri, 1 Feb 2013 10:00:35 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EB21E8040 for ; Fri, 1 Feb 2013 10:00:34 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id jz10so3151968veb.35 for ; Fri, 01 Feb 2013 10:00:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=mXssnUnD/BYok6/F7pathXuasolQEwNWHZ6RqAzHo7w=; b=IilJw8XykcCZgYEFP9naMRIk4WNnX7yvJKqay4qAD9e9AMM1kyI4GXVtgoqVSPx2L1 6+qdRybDpFidK1FU4huJFRhEXWubzikUdOZkW8GfkkMOsseESOfuSrTxPV1UpH9WZVgo uT/sHF6ZznzFtmEfWQ1lfEqY2txuSfdymjz1gcViSFUtQL8iqDoG0Rp1ssBKYccyVQJD 9Z7MFUMTf9dmQcrXfnOln8C//F1QNENKMbWJC6HgjJEXEefKaJGddVWSFYwUsS+GtxVy 6XpqAy/T0d9CJC8wHssKSn82ESgQEFEa8NFIAMbsP/3epqMNULC72HImtIgASkyyT4eQ xN0A== MIME-Version: 1.0 X-Received: by 10.220.239.14 with SMTP id ku14mr11913472vcb.57.1359741634099; Fri, 01 Feb 2013 10:00:34 -0800 (PST) Received: by 10.58.33.67 with HTTP; Fri, 1 Feb 2013 10:00:33 -0800 (PST) In-Reply-To: <6CA2CA17-9FBD-4CE1-8F5F-F55663D1A226@nic.cz> References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> <20130131.203734.312880471.mbj@tail-f.com> <6CA2CA17-9FBD-4CE1-8F5F-F55663D1A226@nic.cz> Date: Fri, 1 Feb 2013 10:00:33 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae9cfcc30163b4004d4ad85f1 X-Gm-Message-State: ALoCoQllFCeRXUEZEsPdjXK6eHA+wqosUMbLZtBQ1mwXeSHrzy6pmZ166WFv/wUXbMU6W426aV8K Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 18:00:36 -0000 --14dae9cfcc30163b4004d4ad85f1 Content-Type: text/plain; charset=UTF-8 Hi, I suppose an Informational RFC is too much work, but there is an easy solution available. We can publish an OPS WEB page with a boilerplate for RFCs that contain YANG modules. There is already one for MIB modules: http://trac.tools.ietf.org/area/ops/trac/wiki/mib-boilerplate Andy On Fri, Feb 1, 2013 at 1:29 AM, Ladislav Lhotka wrote: > > On Jan 31, 2013, at 8:37 PM, Martin Bjorklund wrote: > > > Hi, > > > > Andy Bierman wrote: > >> Hi, > >> > >> IMO, the best solution would be if the tool authors would write > >> a short RFC defining the syntax and showing a few examples. > > > > Since we don't want to wait for that document at this point, I suggest > > we do as the rest of the current documents, and include something > > like this: > > > > 1.2. Tree Diagrams > > > > A simplified graphical representation of the data model is used in > > this document. The meaning of the symbols in these diagrams is as > > follows: > > > > o Brackets "[" and "]" enclose list keys. > > > > o Abbreviations before data node names: "rw" means configuration > > (read-write) and "ro" state data (read-only). > > > > o Symbols after data node names: "?" means an optional node and "*" > > denotes a "leaf-list". > > > > o Parentheses enclose choice and case nodes, and case nodes are also > > marked with a colon (":"). > > Quite often, the trees are collapsed in some way, and then there should be > a fourth item like this: > > o Ellipsis ("...") stands for contents of subtrees that are not > shown. > > The best place for that subsection is probably the "Terminology and > Notation" section. > > Lada > > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --14dae9cfcc30163b4004d4ad85f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

I suppose an Informational RFC is too much work, but= there is
an easy solution available. =C2=A0We can publish an OPS= WEB page
with a boilerplate for RFCs that contain YANG modules.<= /div>

There is already one for MIB modules:

Andy

On Fri,= Feb 1, 2013 at 1:29 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:<= br>

On Jan 31, 2013, at 8:37 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> Andy Bierman <andy@yumaworks.= com> wrote:
>> Hi,
>>
>> IMO, the best solution would be if the tool authors would write >> a short RFC defining the syntax and showing a few examples.
>
> Since we don't want to wait for that document at this point, I sug= gest
> we do as the rest of the current documents, and include something
> like this:
>
> 1.2. =C2=A0Tree Diagrams
>
> =C2=A0 A simplified graphical representation of the data model is used= in
> =C2=A0 this document. =C2=A0The meaning of the symbols in these diagra= ms is as
> =C2=A0 follows:
>
> =C2=A0 o =C2=A0Brackets "[" and "]" enclose list k= eys.
>
> =C2=A0 o =C2=A0Abbreviations before data node names: "rw" me= ans configuration
> =C2=A0 =C2=A0 =C2=A0(read-write) and "ro" state data (read-o= nly).
>
> =C2=A0 o =C2=A0Symbols after data node names: "?" means an o= ptional node and "*"
> =C2=A0 =C2=A0 =C2=A0denotes a "leaf-list".
>
> =C2=A0 o =C2=A0Parentheses enclose choice and case nodes, and case nod= es are also
> =C2=A0 =C2=A0 =C2=A0marked with a colon (":").

Quite often, the trees are collapsed in some way, and then there should be = a fourth item like this:

=C2=A0 =C2=A0o =C2=A0Ellipsis ("...") stands for contents of subt= rees that are not
=C2=A0 =C2=A0 =C2=A0 shown.

The best place for that subsection is probably the "Terminology and No= tation" section.

Lada

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

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





--14dae9cfcc30163b4004d4ad85f1-- From xiangli@seguesoft.com Fri Feb 1 11:01:07 2013 Return-Path: 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 D879B11E80A2 for ; Fri, 1 Feb 2013 11:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] 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 VWCkm5h8FLs9 for ; Fri, 1 Feb 2013 11:01:06 -0800 (PST) Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) by ietfa.amsl.com (Postfix) with ESMTP id C84D511E809C for ; Fri, 1 Feb 2013 11:01:06 -0800 (PST) Received: from [192.168.2.16] ([98.212.151.151]) by p3plsmtpa07-03.prod.phx3.secureserver.net with id v7111k0013GEayi0171126; Fri, 01 Feb 2013 12:01:01 -0700 Message-ID: <510C10F0.8020806@seguesoft.com> Date: Fri, 01 Feb 2013 13:01:04 -0600 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: netmod@ietf.org References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> <20130131.203734.312880471.mbj@tail-f.com> <6CA2CA17-9FBD-4CE1-8F5F-F55663D1A226@nic.cz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070601020606040003000709" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:01:08 -0000 This is a multi-part message in MIME format. --------------070601020606040003000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andy, I think the easy way and arguably a better place is to put it in the "Terminology and Notation" section as Lada suggested, since you have multiple places that show tree diagrams in this draft. I am not sure it is a good idea for a reader/operator to locate the boilerplate for this information (probably ok for IETF module editors). --Xiang On 2/1/2013 12:00 PM, Andy Bierman wrote: > Hi, > > I suppose an Informational RFC is too much work, but there is > an easy solution available. We can publish an OPS WEB page > with a boilerplate for RFCs that contain YANG modules. > > There is already one for MIB modules: > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-boilerplate > > > Andy > > On Fri, Feb 1, 2013 at 1:29 AM, Ladislav Lhotka > wrote: > > > On Jan 31, 2013, at 8:37 PM, Martin Bjorklund > wrote: > > > Hi, > > > > Andy Bierman > wrote: > >> Hi, > >> > >> IMO, the best solution would be if the tool authors would write > >> a short RFC defining the syntax and showing a few examples. > > > > Since we don't want to wait for that document at this point, I > suggest > > we do as the rest of the current documents, and include something > > like this: > > > > 1.2. Tree Diagrams > > > > A simplified graphical representation of the data model is used in > > this document. The meaning of the symbols in these diagrams is as > > follows: > > > > o Brackets "[" and "]" enclose list keys. > > > > o Abbreviations before data node names: "rw" means configuration > > (read-write) and "ro" state data (read-only). > > > > o Symbols after data node names: "?" means an optional node > and "*" > > denotes a "leaf-list". > > > > o Parentheses enclose choice and case nodes, and case nodes > are also > > marked with a colon (":"). > > Quite often, the trees are collapsed in some way, and then there > should be a fourth item like this: > > o Ellipsis ("...") stands for contents of subtrees that are not > shown. > > The best place for that subsection is probably the "Terminology > and Notation" section. > > Lada > > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (217) 472-4108 Cell 1 (217) 819-0942 --------------070601020606040003000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andy,

I think the easy way and  arguably a better place is to put it in the
"Terminology and Notation" section as Lada suggested,  since you
have multiple places that show tree diagrams in this draft.

I am not sure it  is a good idea for a reader/operator to locate the
boilerplate for this information (probably ok for IETF module  editors).

--Xiang


On 2/1/2013 12:00 PM, Andy Bierman wrote:
Hi,

I suppose an Informational RFC is too much work, but there is
an easy solution available.  We can publish an OPS WEB page
with a boilerplate for RFCs that contain YANG modules.

There is already one for MIB modules:


Andy

On Fri, Feb 1, 2013 at 1:29 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On Jan 31, 2013, at 8:37 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Hi,
>
> Andy Bierman <andy@yumaworks.com> wrote:
>> Hi,
>>
>> IMO, the best solution would be if the tool authors would write
>> a short RFC defining the syntax and showing a few examples.
>
> Since we don't want to wait for that document at this point, I suggest
> we do as the rest of the current documents, and include something
> like this:
>
> 1.2.  Tree Diagrams
>
>   A simplified graphical representation of the data model is used in
>   this document.  The meaning of the symbols in these diagrams is as
>   follows:
>
>   o  Brackets "[" and "]" enclose list keys.
>
>   o  Abbreviations before data node names: "rw" means configuration
>      (read-write) and "ro" state data (read-only).
>
>   o  Symbols after data node names: "?" means an optional node and "*"
>      denotes a "leaf-list".
>
>   o  Parentheses enclose choice and case nodes, and case nodes are also
>      marked with a colon (":").

Quite often, the trees are collapsed in some way, and then there should be a fourth item like this:

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

The best place for that subsection is probably the "Terminology and Notation" section.

Lada

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

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







_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


-- 
--
Xiang Li
Web: www.seguesoft.com
Voice:   1 (217) 472-4108 Cell 1 (217) 819-0942
--------------070601020606040003000709-- From j.schoenwaelder@jacobs-university.de Fri Feb 1 11:11:47 2013 Return-Path: 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 048A421E8039 for ; Fri, 1 Feb 2013 11:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.148 X-Spam-Level: X-Spam-Status: No, score=-103.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 5GwC3DdUt0Qn for ; Fri, 1 Feb 2013 11:11:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63A11E809C for ; Fri, 1 Feb 2013 11:11:46 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 130A321BF1; Fri, 1 Feb 2013 20:11:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Xsdv9a3rDoi6; Fri, 1 Feb 2013 20:11:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C23321BE5; Fri, 1 Feb 2013 20:11:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0E925244E337; Fri, 1 Feb 2013 20:11:44 +0100 (CET) Date: Fri, 1 Feb 2013 20:11:44 +0100 From: Juergen Schoenwaelder To: Xiang Li Message-ID: <20130201191144.GB33625@elstar.local> Mail-Followup-To: Xiang Li , netmod@ietf.org References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> <20130131.203734.312880471.mbj@tail-f.com> <6CA2CA17-9FBD-4CE1-8F5F-F55663D1A226@nic.cz> <510C10F0.8020806@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <510C10F0.8020806@seguesoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:11:47 -0000 On Fri, Feb 01, 2013 at 01:01:04PM -0600, Xiang Li wrote: > Andy, > > I think the easy way and arguably a better place is to put it in the > "Terminology and Notation" section as Lada suggested, since you > have multiple places that show tree diagrams in this draft. > > I am not sure it is a good idea for a reader/operator to locate the > boilerplate for this information (probably ok for IETF module editors). Xiang, the MIB boilerplate is copied into every document containing a MIB module. So a reader would easily spot it and authors would easily find the right text to include. (And who knows, the new xml2rfc might even be hacked to generate such boilerplates automatically - that would be cool.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From xiangli@seguesoft.com Fri Feb 1 11:19:58 2013 Return-Path: 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 C1C7F21F8D49 for ; Fri, 1 Feb 2013 11:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, 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 uameYNQ4oRa0 for ; Fri, 1 Feb 2013 11:19:58 -0800 (PST) Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79321F8D46 for ; Fri, 1 Feb 2013 11:19:58 -0800 (PST) Received: from [192.168.2.16] ([98.212.151.151]) by p3plsmtpa06-01.prod.phx3.secureserver.net with id v7Kw1k00D3GEayi017Kxqw; Fri, 01 Feb 2013 12:19:57 -0700 Message-ID: <510C1560.1080502@seguesoft.com> Date: Fri, 01 Feb 2013 13:20:00 -0600 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: netmod@ietf.org References: <20121226204528.1846.85674.idtracker@ietfa.amsl.com> <50F03BA8.3000203@seguesoft.com> <20130131.203734.312880471.mbj@tail-f.com> <6CA2CA17-9FBD-4CE1-8F5F-F55663D1A226@nic.cz> <510C10F0.8020806@seguesoft.com> <20130201191144.GB33625@elstar.local> In-Reply-To: <20130201191144.GB33625@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 19:19:58 -0000 On 2/1/2013 1:11 PM, Juergen Schoenwaelder wrote: > the MIB boilerplate is copied into every document containing a MIB > module. Apparently I did not know that...that's probably the best then. --Xiang > So a reader would easily spot it and authors would easily find > the right text to include. (And who knows, the new xml2rfc might even > be hacked to generate such boilerplates automatically - that would be > cool.) > > /js > From internet-drafts@ietf.org Wed Feb 6 07:16:56 2013 Return-Path: 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 8343321F8A6D; Wed, 6 Feb 2013 07:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 g6vSqtMcJcPP; Wed, 6 Feb 2013 07:16:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8D21F8A3D; Wed, 6 Feb 2013 07:16:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206151656.17912.68269.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2013 07:16:56 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:16:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Interface Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-09.txt Pages : 38 Date : 2013-02-06 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Feb 6 07:18:15 2013 Return-Path: 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 2659021F8B08; Wed, 6 Feb 2013 07:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 JPn1gZ5UJgSx; Wed, 6 Feb 2013 07:18:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23621F8A6D; Wed, 6 Feb 2013 07:18:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206151814.7577.50877.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2013 07:18:14 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:18:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for IP Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-08.txt Pages : 22 Date : 2013-02-06 Abstract: This document defines a YANG data model for management of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Feb 6 09:06:36 2013 Return-Path: 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 1A36121F8A0D; Wed, 6 Feb 2013 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 F5IuMeO0nPbO; Wed, 6 Feb 2013 09:06:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A235921F8999; Wed, 6 Feb 2013 09:06:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206170635.12977.3979.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2013 09:06:35 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6021-bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:06:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : Common YANG Data Types Author(s) : Juergen Schoenwaelder Filename : draft-ietf-netmod-rfc6021-bis-00.txt Pages : 36 Date : 2013-02-05 Abstract: This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-rfc6021-bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.kessens@nsn.com Wed Feb 6 09:20:47 2013 Return-Path: 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 D501C21F8809 for ; Wed, 6 Feb 2013 09:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 q2zycwCfxLlm for ; Wed, 6 Feb 2013 09:20:47 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 83F7521F8526 for ; Wed, 6 Feb 2013 09:20:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r16HKgx0031898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Feb 2013 18:20:43 +0100 Received: from P ([10.138.50.55]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r16HKem6023400 for ; Wed, 6 Feb 2013 18:20:42 +0100 Received: from P (localhost.localdomain [127.0.0.1]) by P (8.14.5/8.14.5) with ESMTP id r16HKdCv002801 for ; Wed, 6 Feb 2013 09:20:39 -0800 Received: (from david@localhost) by P (8.14.5/8.14.5/Submit) id r16HKdSm002799 for netmod@ietf.org; Wed, 6 Feb 2013 09:20:39 -0800 Date: Wed, 6 Feb 2013 09:19:39 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20130206171937.GC2307@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1014 X-purgate-ID: 151667::1360171243-00003C02-8E362BBD/0-0/0-0 Subject: [netmod] Last Call & adoption of: draft-ietf-netmod-rfc6021-bis (20130212) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:20:48 -0000 Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/id/draft-ietf-netmod-rfc6021-bis Juergen has posted an updated draft (previously called: draft-schoenw-netmod-rfc6021-bis-01) and he has addressed the comments that came in during the first last call. While we implicitly already adopted this work, we did not do a formal call for adoption of this document so this last call also intends to correct this and confirm with the working group that we are ok that we adopted this document. This document is needed in order to move: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06 towards the IESG and publication. Please indicate your support by February 12, 2013. Or alternatively, let us know in the same timeframe whether there are still issues that need to be resolved. Thanks! David Kessens co-chair netmod wg --- From j.schoenwaelder@jacobs-university.de Wed Feb 6 09:39:55 2013 Return-Path: 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 D4E5721F8759 for ; Wed, 6 Feb 2013 09:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 026ywhZYZzRq for ; Wed, 6 Feb 2013 09:39:55 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1B99621F8546 for ; Wed, 6 Feb 2013 09:39:55 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F006209DC; Wed, 6 Feb 2013 18:39:54 +0100 (CET) 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 ok23PsjmetxA; Wed, 6 Feb 2013 18:39:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDD8D20933; Wed, 6 Feb 2013 18:39:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8DC11246DB48; Wed, 6 Feb 2013 18:39:59 +0100 (CET) Date: Wed, 6 Feb 2013 18:39:59 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130206173959.GB83997@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] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:39:55 -0000 Hi, Martin has posted two new IDs: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 These documents did already pass WG last call. However, there were some non-editorial changes (in particular in draft-ietf-netmod-ip-cfg-08) in order to make use of the types that have been moved to 6021bis. I like to ask people to check the changes and to raise any issues they might have with the changes as soon as possible but not later than February 12th, 2013. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Feb 6 09:51:11 2013 Return-Path: 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 2D24E21F85CC for ; Wed, 6 Feb 2013 09:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 V9wpQ2VuZ-8M for ; Wed, 6 Feb 2013 09:51:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB8121F84F6 for ; Wed, 6 Feb 2013 09:51:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90B9E2095C; Wed, 6 Feb 2013 18:51:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HIW4reYoxlJ9; Wed, 6 Feb 2013 18:51:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1731A20825; Wed, 6 Feb 2013 18:51:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DAD77246DC3C; Wed, 6 Feb 2013 18:51:14 +0100 (CET) Date: Wed, 6 Feb 2013 18:51:14 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org, Dave Thaler Message-ID: <20130206175114.GD83997@elstar.local> Mail-Followup-To: netmod@ietf.org, Dave Thaler References: <20130206173959.GB83997@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130206173959.GB83997@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:51:11 -0000 On Wed, Feb 06, 2013 at 06:39:59PM +0100, Juergen Schoenwaelder wrote: > Hi, > > Martin has posted two new IDs: > > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > These documents did already pass WG last call. However, there were some > non-editorial changes (in particular in draft-ietf-netmod-ip-cfg-08) > in order to make use of the types that have been moved to 6021bis. I > like to ask people to check the changes and to raise any issues they > might have with the changes as soon as possible but not later than > February 12th, 2013. > Speaking as technical contributor, I like to highlight that the new version disallows zone indexes in IP addresses of interfaces and in the neighbor tables. This is technically fine since everything is scoped by an interface, so implicitely the information is always there. The question is whether this is convenient or the approach existing systems usually follow. It seems that BSD like systems tend to show the zone index while Linux like systems tend to hide it, leaving it to the context information. I do not know about Windows, maybe Dave Thaler can inform us. If we allow zone indexes (as we had before), of course the question comes up whether the canonical representation is without a zone index or with a zone index for non-global addresses. (This was not specified before either but frankly should have been.) I am raising this issue here explicitely since I want that the WG takes an informed decision about this change. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Thu Feb 7 07:25:11 2013 Return-Path: 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 60DAD21F84D9 for ; Thu, 7 Feb 2013 07:25:11 -0800 (PST) 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 hkIQjLRq8gKm for ; Thu, 7 Feb 2013 07:25:10 -0800 (PST) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id B44AC21F8530 for ; Thu, 7 Feb 2013 07:25:08 -0800 (PST) Received: from alpmlip13.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKURPHVBYPuGEQK9d2p/Zx+LjcUFSo0MYH@postini.com; Thu, 07 Feb 2013 07:25:08 PST Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip13.e2k.ad.ge.com with ESMTP; 07 Feb 2013 10:25:03 -0500 Received: from cinmlef17.e2k.ad.ge.com ([3.159.213.93]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 10:25:02 -0500 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef17.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 10:25:03 -0500 Received: from CINMBAPD01.e2k.ad.ge.com (3.159.212.67) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 7 Feb 2013 10:24:58 -0500 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.118]) by CINMBAPD01.e2k.ad.ge.com ([169.254.7.224]) with mapi id 14.02.0309.002; Thu, 7 Feb 2013 10:24:58 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt Thread-Index: AQHOBH1Mkr1X7DxDGUGDS/YABIH/D5hug81A Date: Thu, 7 Feb 2013 15:24:58 +0000 Message-ID: References: <20130206151814.7577.50877.idtracker@ietfa.amsl.com> In-Reply-To: <20130206151814.7577.50877.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2013 15:25:03.0271 (UTC) FILETIME=[4CFBCB70:01CE0547] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:25:11 -0000 One quick comment on ietf-ip, the nodes "ipv4/neighbor/phys-address" & "ipv= 6/neighbor/phys-address" should be mandatory. Phys-address is the only lea= f in the neighbor list other than the key (ip), and it doesn't make any sen= se to create a static ARP entry without a physical address. -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Wednesday, February 06, 2013 10:18 AM > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the NETCONF Data Modeling Language Working > Group of the IETF. >=20 > Title : A YANG Data Model for IP Management > Author(s) : Martin Bjorklund > Filename : draft-ietf-netmod-ip-cfg-08.txt > Pages : 22 > Date : 2013-02-06 >=20 > Abstract: > This document defines a YANG data model for management of IP > implementations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From equinox@diac24.net Thu Feb 7 07:29:06 2013 Return-Path: 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 C51D521F86EF for ; Thu, 7 Feb 2013 07:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 3hhapDuTPK0h for ; Thu, 7 Feb 2013 07:29:06 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2411D21F862A for ; Thu, 7 Feb 2013 07:29:06 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3TPM-0001fh-3A; Thu, 07 Feb 2013 16:29:04 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U3TP9-00BwWF-0V; Thu, 07 Feb 2013 16:28:53 +0100 Date: Thu, 7 Feb 2013 16:28:50 +0100 From: David Lamparter To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20130207152850.GS1775516@jupiter.n2.diac24.net> References: <20130206151814.7577.50877.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:29:06 -0000 On Thu, Feb 07, 2013 at 03:24:58PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: > One quick comment on ietf-ip, the nodes "ipv4/neighbor/phys-address" & > "ipv6/neighbor/phys-address" should be mandatory. Phys-address is the > only leaf in the neighbor list other than the key (ip), and it doesn't > make any sense to create a static ARP entry without a physical > address. There are devices that support creation of static "unreachable" ARP entries. If the phys-address is mandatory, this will need some ugly hack instead of a simple schema extension. -David > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf Of internet-drafts@ietf.org > > Sent: Wednesday, February 06, 2013 10:18 AM > > To: i-d-announce@ietf.org > > Cc: netmod@ietf.org > > Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the NETCONF Data Modeling Language Working > > Group of the IETF. > > > > Title : A YANG Data Model for IP Management > > Author(s) : Martin Bjorklund > > Filename : draft-ietf-netmod-ip-cfg-08.txt > > Pages : 22 > > Date : 2013-02-06 > > > > Abstract: > > This document defines a YANG data model for management of IP > > implementations. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-ip-cfg-08 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ From jeffrey.K.lange@ge.com Thu Feb 7 07:35:24 2013 Return-Path: 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 87A5921F86F4 for ; Thu, 7 Feb 2013 07:35:24 -0800 (PST) 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 eQYPjnn10Vz0 for ; Thu, 7 Feb 2013 07:35:23 -0800 (PST) Received: from exprod5og117.obsmtp.com (exprod5og117.obsmtp.com [64.18.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id C34D521F86CD for ; Thu, 7 Feb 2013 07:35:22 -0800 (PST) Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob117.postini.com ([64.18.4.12]) with SMTP ID DSNKURPJufzz1o2GsCDvNlaygPfb2ibQO9AM@postini.com; Thu, 07 Feb 2013 07:35:23 PST Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by alpmlip12.e2k.ad.ge.com with ESMTP; 07 Feb 2013 10:34:52 -0500 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 10:34:52 -0500 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 10:34:51 -0500 Received: from CINMBAPD07.e2k.ad.ge.com (3.159.212.46) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 7 Feb 2013 10:34:49 -0500 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.118]) by CINMBAPD07.e2k.ad.ge.com ([169.254.9.101]) with mapi id 14.02.0309.002; Thu, 7 Feb 2013 10:34:49 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: David Lamparter Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt Thread-Index: AQHOBH1Mkr1X7DxDGUGDS/YABIH/D5hug81AgABWsgD//61pMA== Date: Thu, 7 Feb 2013 15:34:48 +0000 Message-ID: References: <20130206151814.7577.50877.idtracker@ietfa.amsl.com> <20130207152850.GS1775516@jupiter.n2.diac24.net> In-Reply-To: <20130207152850.GS1775516@jupiter.n2.diac24.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2013 15:34:51.0287 (UTC) FILETIME=[AB77EA70:01CE0548] Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:35:24 -0000 > There are devices that support creation of static "unreachable" ARP entri= es. > If the phys-address is mandatory, this will need some ugly hack instead o= f a > simple schema extension. That makes sense. However if that's the intended use-case of leaving it em= pty, perhaps there should be a note in the description about what it means = if that leaf is not present. -Jeff > -----Original Message----- > From: David Lamparter [mailto:equinox@diac24.net] > Sent: Thursday, February 07, 2013 10:29 AM > To: Lange, Jeffrey K (GE Energy Management) > Cc: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt >=20 > On Thu, Feb 07, 2013 at 03:24:58PM +0000, Lange, Jeffrey K (GE Energy > Management) wrote: > > One quick comment on ietf-ip, the nodes "ipv4/neighbor/phys-address" & > > "ipv6/neighbor/phys-address" should be mandatory. Phys-address is the > > only leaf in the neighbor list other than the key (ip), and it doesn't > > make any sense to create a static ARP entry without a physical > > address. >=20 > There are devices that support creation of static "unreachable" ARP entri= es. > If the phys-address is mandatory, this will need some ugly hack instead o= f a > simple schema extension. >=20 > -David >=20 > > > -----Original Message----- > > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > > Behalf Of internet-drafts@ietf.org > > > Sent: Wednesday, February 06, 2013 10:18 AM > > > To: i-d-announce@ietf.org > > > Cc: netmod@ietf.org > > > Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-08.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > This draft is a work item of the NETCONF Data Modeling Language > > > Working Group of the IETF. > > > > > > Title : A YANG Data Model for IP Management > > > Author(s) : Martin Bjorklund > > > Filename : draft-ietf-netmod-ip-cfg-08.txt > > > Pages : 22 > > > Date : 2013-02-06 > > > > > > Abstract: > > > This document defines a YANG data model for management of IP > > > implementations. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-08 > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Fri Feb 8 00:33:37 2013 Return-Path: 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 C29E421F86AB for ; Fri, 8 Feb 2013 00:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, 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 OlOdFOUjLtJW for ; Fri, 8 Feb 2013 00:33:37 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED4C21F8510 for ; Fri, 8 Feb 2013 00:33:37 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0636720BEF; Fri, 8 Feb 2013 09:33:36 +0100 (CET) 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 cg2TNqIZJ1Dx; Fri, 8 Feb 2013 09:33:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 223C220BE9; Fri, 8 Feb 2013 09:33:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 39B842471986; Fri, 8 Feb 2013 09:33:38 +0100 (CET) Date: Fri, 8 Feb 2013 09:33:38 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130208083337.GB88625@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] meetings at the orlando ietf (draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 08:33:37 -0000 Hi, the first draft IETF 86 agenda has been published. The most relevant meetings for this WG are currently scheduled like this (but note that things can still change): NETMOD Tuesday 15:20-16:50 NETCONF Monday 15:40-17:10 Other WG meetings that might be covering YANG/NETCONF topics: OPSAWG Tuesday 13:00-15:00 OPSAREA Tuesday 13:00-15:00 LMAP Wednesday 15:10-17:10 (BOF with likely some YANG discussion) I2RS Thursday 09:00-11:30 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Fri Feb 8 11:44:29 2013 Return-Path: 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 861DD21F8BE7 for ; Fri, 8 Feb 2013 11:44:29 -0800 (PST) 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 tyqzZ06lBnH6 for ; Fri, 8 Feb 2013 11:44:28 -0800 (PST) Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7411721F8AB2 for ; Fri, 8 Feb 2013 11:44:28 -0800 (PST) Received: from cinmlip11.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKURVVmxz0wA5wBs9S91HUrsCgJWG76oaE@postini.com; Fri, 08 Feb 2013 11:44:28 PST Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by cinmlip11.e2k.ad.ge.com with ESMTP; 08 Feb 2013 14:44:27 -0500 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Feb 2013 14:44:27 -0500 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Feb 2013 14:44:25 -0500 Received: from CINMBCNA08.e2k.ad.ge.com (3.159.212.37) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 8 Feb 2013 14:44:25 -0500 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.118]) by CINMBCNA08.e2k.ad.ge.com ([169.254.2.249]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 14:44:25 -0500 From: "Lange, Jeffrey K (GE Energy Management)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] ietf-ip open issue Thread-Index: AQHN1xGiOiC1+zEeo0O6dpANOj++iJgSygwAgAATZ4CAXd0F8A== Date: Fri, 8 Feb 2013 19:44:24 +0000 Message-ID: References: <20121210.210438.342222070.mbj@tail-f.com> <20121210200855.GA50491@elstar.local> <20121210.221823.456701977.mbj@tail-f.com> In-Reply-To: <20121210.221823.456701977.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2013 19:44:25.0691 (UTC) FILETIME=[B35262B0:01CE0634] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-ip open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:44:29 -0000 Bringing back an old thread here, but looking at the latest ietf-ip, the pr= efix-length is still defaulted to 32/128. Was there an intent to change th= is to a mandatory field as stated by Martin below? -Jeff > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Monday, December 10, 2012 4:18 PM > To: j.schoenwaelder@jacobs-university.de > Cc: netmod@ietf.org > Subject: Re: [netmod] ietf-ip open issue >=20 > Juergen Schoenwaelder wrote: > > On Mon, Dec 10, 2012 at 09:04:38PM +0100, Martin Bjorklund wrote: > > > Hi, > > > > > > One WGLC comment was if the prefix-length really should have a > > > default value (32 resp. 128). There are two options: > > > > > > 1. Keep the defaults > > > > > > 2. Make prefix-length mandatory > > > > > > > > > I think I agree with Lada that we should do (2). The current > > > defaults are not so common that it saves lots of config to use the > > > default values. Comments? > > > > I generally agree with the direction. But how would this work for IPv4 > > where we have either a prefix-length or a netmask? >=20 > It actually works fine: >=20 > choice subnet { > mandatory true; > ... > leaf prefix-length { ... } > leaf netmask { > if-feature ipv4-non-contiguous-netmasks; > ... > } > } >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From internet-drafts@ietf.org Sun Feb 10 23:13:22 2013 Return-Path: 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 4164121F88FD; Sun, 10 Feb 2013 23:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 afLmksLyRa3f; Sun, 10 Feb 2013 23:13:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D605721F8956; Sun, 10 Feb 2013 23:13:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211071321.2778.2660.idtracker@ietfa.amsl.com> Date: Sun, 10 Feb 2013 23:13:21 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 07:13:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for IP Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-09.txt Pages : 22 Date : 2013-02-10 Abstract: This document defines a YANG data model for management of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Mon Feb 11 00:28:17 2013 Return-Path: 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 EE3F421F8496 for ; Mon, 11 Feb 2013 00:28:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0gBd68wcgXF for ; Mon, 11 Feb 2013 00:28:17 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0963721F847C for ; Mon, 11 Feb 2013 00:28:16 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 88D931200AF6; Mon, 11 Feb 2013 09:28:14 +0100 (CET) Date: Mon, 11 Feb 2013 08:15:12 +0100 (CET) Message-Id: <20130211.081512.470959967.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20121210200855.GA50491@elstar.local> <20121210.221823.456701977.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] ietf-ip open issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 08:28:18 -0000 Hi, "Lange, Jeffrey K (GE Energy Management)" wrote: > Bringing back an old thread here, but looking at the latest ietf-ip, the > prefix-length is still defaulted to 32/128. Was there an intent to change this > to a mandatory field as stated by Martin below? Thanks for catching this, it was my mistake. I have fixed this, and posted -09, and also I updated the "tree" overview to match the new types introduced in -08. /martin > > -Jeff > > > -----Original Message----- > > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf Of Martin Bjorklund > > Sent: Monday, December 10, 2012 4:18 PM > > To: j.schoenwaelder@jacobs-university.de > > Cc: netmod@ietf.org > > Subject: Re: [netmod] ietf-ip open issue > > > > Juergen Schoenwaelder wrote: > > > On Mon, Dec 10, 2012 at 09:04:38PM +0100, Martin Bjorklund wrote: > > > > Hi, > > > > > > > > One WGLC comment was if the prefix-length really should have a > > > > default value (32 resp. 128). There are two options: > > > > > > > > 1. Keep the defaults > > > > > > > > 2. Make prefix-length mandatory > > > > > > > > > > > > I think I agree with Lada that we should do (2). The current > > > > defaults are not so common that it saves lots of config to use the > > > > default values. Comments? > > > > > > I generally agree with the direction. But how would this work for IPv4 > > > where we have either a prefix-length or a netmask? > > > > It actually works fine: > > > > choice subnet { > > mandatory true; > > ... > > leaf prefix-length { ... } > > leaf netmask { > > if-feature ipv4-non-contiguous-netmasks; > > ... > > } > > } > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > From internet-drafts@ietf.org Mon Feb 11 04:22:22 2013 Return-Path: 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 A63F421F88B5; Mon, 11 Feb 2013 04:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 stNJJxFg64QB; Mon, 11 Feb 2013 04:22:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3737621F8771; Mon, 11 Feb 2013 04:22:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211122222.18814.95604.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 04:22:22 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 12:22:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for SNMP Configuration Author(s) : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-01.txt Pages : 75 Date : 2013-02-11 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-snmp-cfg-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Mon Feb 11 04:25:03 2013 Return-Path: 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 29F4221F8AE0 for ; Mon, 11 Feb 2013 04:25:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipGBCddYZOj4 for ; Mon, 11 Feb 2013 04:25:02 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 389F921F8A91 for ; Mon, 11 Feb 2013 04:25:02 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EEF7C1200AF6 for ; Mon, 11 Feb 2013 13:25:00 +0100 (CET) Date: Mon, 11 Feb 2013 13:25:00 +0100 (CET) Message-Id: <20130211.132500.458970580.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20130211122222.18814.95604.idtracker@ietfa.amsl.com> References: <20130211122222.18814.95604.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 12:25:03 -0000 Hi, I have posted a new version of the snmp-cfg document, where I believe all review comments have been addressed. /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group > of the IETF. > > Title : A YANG Data Model for SNMP Configuration > Author(s) : Martin Bjorklund > Juergen Schoenwaelder > Filename : draft-ietf-netmod-snmp-cfg-01.txt > Pages : 75 > Date : 2013-02-11 > > Abstract: > This document defines a collection of YANG definitions for > configuring SNMP engines. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From lhotka@nic.cz Mon Feb 11 04:49:09 2013 Return-Path: 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 81B0E21F8877 for ; Mon, 11 Feb 2013 04:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 sm+qGTVx-xYc for ; Mon, 11 Feb 2013 04:49:08 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6423021F87BB for ; Mon, 11 Feb 2013 04:49:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9B7C15406A9; Mon, 11 Feb 2013 13:49:01 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apk5k1S8Uqsn; Mon, 11 Feb 2013 13:48:49 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 10B7554057F; Mon, 11 Feb 2013 13:48:40 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org, Dave Thaler In-Reply-To: <20130206175114.GD83997@elstar.local> References: <20130206173959.GB83997@elstar.local> <20130206175114.GD83997@elstar.local> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Juergen Schoenwaelder , netmod@ietf.org, Dave Thaler Date: Mon, 11 Feb 2013 13:48:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 12:49:09 -0000 Juergen Schoenwaelder writes: > On Wed, Feb 06, 2013 at 06:39:59PM +0100, Juergen Schoenwaelder wrote: >> Hi, >> >> Martin has posted two new IDs: >> >> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 >> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 >> >> These documents did already pass WG last call. However, there were some >> non-editorial changes (in particular in draft-ietf-netmod-ip-cfg-08) >> in order to make use of the types that have been moved to 6021bis. I >> like to ask people to check the changes and to raise any issues they >> might have with the changes as soon as possible but not later than >> February 12th, 2013. >> > > Speaking as technical contributor, I like to highlight that the new > version disallows zone indexes in IP addresses of interfaces and in > the neighbor tables. This is technically fine since everything is > scoped by an interface, so implicitely the information is always > there. The question is whether this is convenient or the approach > existing systems usually follow. It seems that BSD like systems tend > to show the zone index while Linux like systems tend to hide it, > leaving it to the context information. I do not know about Windows, > maybe Dave Thaler can inform us. > > If we allow zone indexes (as we had before), of course the question > comes up whether the canonical representation is without a zone index > or with a zone index for non-global addresses. (This was not specified > before either but frankly should have been.) I think there is no common canonical form that would fit all potential uses of the "ipv[46]-address" type. Depending on the context, the zone index may be superfluous (global addresses), convenient but redundant (as in BSD ifconfig output) or necessary (link-local next hops in routing tables). On the other hand, I agree that having no canonical form is a problem, because we cannot reliably determine whether two IP addresses are equal or not. For instance, in previous revisions of the "ip-cfg" draft, the following two addresses would have to be treated as different keys of the "ip" list: fe80::7aac:c0ff:fe88:9494 fe80::7aac:c0ff:fe88:9494%bge1 Lada > > I am raising this issue here explicitely since I want that the WG > takes an informed decision about this change. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Mon Feb 11 07:08:10 2013 Return-Path: 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 8A63F21F86CD; Mon, 11 Feb 2013 07:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 vyIM5T2VGdvd; Mon, 11 Feb 2013 07:08:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA43D21F86F5; Mon, 11 Feb 2013 07:08:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211150809.16637.82904.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 07:08:09 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:08:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Routing Management Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-07.txt Pages : 68 Date : 2013-02-11 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - router instances, routes, routing tables, routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lhotka@nic.cz Mon Feb 11 07:16:14 2013 Return-Path: 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 3071721F8AB1 for ; Mon, 11 Feb 2013 07:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 cKljmTAGHodA for ; Mon, 11 Feb 2013 07:16:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8FD21F8A6B for ; Mon, 11 Feb 2013 07:16:13 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 84E4513F802 for ; Mon, 11 Feb 2013 16:16:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1360595772; bh=xz7pgnSx5lSC6fP9cS+J1JGSscGjb6oGDBStf5sup7o=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=tQ9O0/VHhiA6OpWUfWjumb8Z6JV3tKyYf/uuyfmQAFQb6e70VrUSRhdzIMH8xDnRs FXKRxUsIzAjEeXACAC/NW/kC3Zewgx5EicpGGZ8oK/0Oav8AtI/92fuYqLGlr7cWvO C2UoGWeOi5qj79nm7nkuvauYvyWBe+42eQpQwfMw= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Feb 2013 16:16:11 +0100 References: <20130211150809.16637.82904.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <77D8A3ED-6D7E-49D4-9648-0C4AA9E56554@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:16:14 -0000 Hi, this revision of the routing draft only adjusts the type of "router-id" = to 6021bis (yang:dotted-quad), and fixes a few trivial errors discovered = since -06. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-07.txt > Date: February 11, 2013 4:08:09 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : A YANG Data Model for Routing Management > Author(s) : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-07.txt > Pages : 68 > Date : 2013-02-11 >=20 > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for individual routing protocols and > other related functions. The core routing data model provides = common > building blocks for such extensions - router instances, routes, > routing tables, routing protocols and route filters. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Mon Feb 11 07:57:38 2013 Return-Path: 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 439FC21F8632; Mon, 11 Feb 2013 07:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 Wil3L35A2fD3; Mon, 11 Feb 2013 07:57:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC55A21F8645; Mon, 11 Feb 2013 07:57:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211155737.25258.95007.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 07:57:37 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:57:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Routing Management Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-08.txt Pages : 68 Date : 2013-02-11 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - router instances, routes, routing tables, routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lhotka@nic.cz Mon Feb 11 08:00:45 2013 Return-Path: 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 413D421F8A71 for ; Mon, 11 Feb 2013 08:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 95Hy1VwibCW9 for ; Mon, 11 Feb 2013 08:00:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8291D21F887F for ; Mon, 11 Feb 2013 08:00:44 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BF0B913F802 for ; Mon, 11 Feb 2013 17:00:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1360598443; bh=8tnQhZDefOpNLUTL8IgUpzZn3mm/ojrzXxazJpgvFz0=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=xAeQdZm/ijp52kbnVBpI9iMWewkf6dWLj3a3gILUMbMn/iT6ijj2e/OSqtxUM0dvx rWnokUkLaf2o0HuxfLI93vOWRRV9yjMZwsdYI2algH+ZGYiupdsD/1qL+tByLH8aYw lFHPLkHyrRuuR0UK+fdHeIrNLm3C4EGNec+AlL8w= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Feb 2013 17:00:43 +0100 References: <20130211155737.25258.95007.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <67B273A1-7D62-4F2C-8785-620E7E8E998A@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:00:45 -0000 Sorry, I forgot to change the normative reference from RFC6021 to the = 6021bis I-D, so I posted the -08 revision fixing this. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-08.txt > Date: February 11, 2013 4:57:37 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : A YANG Data Model for Routing Management > Author(s) : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-08.txt > Pages : 68 > Date : 2013-02-11 >=20 > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for individual routing protocols and > other related functions. The core routing data model provides = common > building blocks for such extensions - router instances, routes, > routing tables, routing protocols and route filters. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-08 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-08 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bclaise@cisco.com Tue Feb 12 06:52:15 2013 Return-Path: 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 C209C21F8EB0 for ; Tue, 12 Feb 2013 06:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 slkFrFCQbm-W for ; Tue, 12 Feb 2013 06:52:15 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DA64F21F8EA7 for ; Tue, 12 Feb 2013 06:52:14 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1CEqDK7010397 for ; Tue, 12 Feb 2013 15:52:13 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1CEpwxM001008 for ; Tue, 12 Feb 2013 15:52:08 +0100 (CET) Message-ID: <511A570D.3010403@cisco.com> Date: Tue, 12 Feb 2013 15:51:57 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: NETMOD Working Group References: <20130212144552.6710AB1E002@rfc-editor.org> In-Reply-To: <20130212144552.6710AB1E002@rfc-editor.org> X-Forwarded-Message-Id: <20130212144552.6710AB1E002@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------030700060207000803050100" Subject: [netmod] Fwd: [Errata Verified] RFC6020 (3470) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:52:15 -0000 This is a multi-part message in MIME format. --------------030700060207000803050100 Content-Type: multipart/alternative; boundary="------------050301000908060409090703" --------------050301000908060409090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Original Message -------- Subject: [Errata Verified] RFC6020 (3470) Date: Tue, 12 Feb 2013 06:45:52 -0800 (PST) From: RFC Errata System To: lhotka@nic.cz, mbj@tail-f.com CC: bclaise@cisco.com, iesg@ietf.org, rfc-editor@rfc-editor.org The following errata report has been verified 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=3470 -------------------------------------- Status: Verified Type: Technical Reported by: Ladislav Lhotka Date Reported: 2013-01-24 Verified by: Benoit Claise (IESG) Section: 7.16.2 Original Text ------------- An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities. Corrected Text -------------- The derivation of identities has the following properties: o It is irreflexive, which means that an identity is not derived from itself. o It is transitive, which means that if identity B is derived from A and C is derived from B, then C is also derived from A. Notes ----- The desired properties of identity derivation are not clearly stated. The discussion in the NETMOD mailing led to a general agreement that identity derivation is supposed to be irreflexive and transitive. These two properties together also eliminate the possibility of a circular derivation. -------------------------------------- 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 --------------050301000908060409090703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Original Message --------
Subject: [Errata Verified] RFC6020 (3470)
Date: Tue, 12 Feb 2013 06:45:52 -0800 (PST)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: lhotka@nic.cz, mbj@tail-f.com
CC: bclaise@cisco.com, iesg@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been verified 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=3470

--------------------------------------
Status: Verified
Type: Technical

Reported by: Ladislav Lhotka <lhotka@nic.cz>
Date Reported: 2013-01-24
Verified by: Benoit Claise (IESG)

Section: 7.16.2

Original Text
-------------
An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.

Corrected Text
--------------
The derivation of identities has the following properties:

o It is irreflexive, which means that an identity is not derived from itself.

o It is transitive, which means that if identity B is derived from A and
  C is derived from B, then C is also derived from A.

Notes
-----
The desired properties of identity derivation are not clearly stated. The discussion in the NETMOD mailing led to a general agreement that identity derivation is supposed to be irreflexive and transitive. These two properties together also eliminate the possibility of a circular derivation.

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


--------------050301000908060409090703-- --------------030700060207000803050100 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------030700060207000803050100-- From mbj@tail-f.com Tue Feb 12 13:00:06 2013 Return-Path: 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 A338021F88D6 for ; Tue, 12 Feb 2013 13:00:06 -0800 (PST) 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 45-ECWOs0nqe for ; Tue, 12 Feb 2013 13:00:06 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2399321F88CF for ; Tue, 12 Feb 2013 13:00:03 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 731361200054; Tue, 12 Feb 2013 22:00:01 +0100 (CET) Date: Tue, 12 Feb 2013 22:00:01 +0100 (CET) Message-Id: <20130212.220001.197654139.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <67B273A1-7D62-4F2C-8785-620E7E8E998A@nic.cz> References: <20130211155737.25258.95007.idtracker@ietfa.amsl.com> <67B273A1-7D62-4F2C-8785-620E7E8E998A@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 21:00:06 -0000 Hi, I think the majestic must expression for the connected-routing-table might be wrong. The problem is that it checks that: not (*some* preceding-sibling has same afi AND *some* preceding-sibling has same safi) So this instance document snippet does not validate, although I believe it is correct: st0 rt:static tab-1 tab-2 tab-3 ... tab-1 ipv6 nlri-unicast tab-2 ipv4 nlri-multicast tab-3 ipv4 nlri-unicast /martin From lhotka@nic.cz Wed Feb 13 00:44:14 2013 Return-Path: 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 6603221F8545 for ; Wed, 13 Feb 2013 00:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 RCzy7rZUOKt6 for ; Wed, 13 Feb 2013 00:44:14 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2F21F8510 for ; Wed, 13 Feb 2013 00:43:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 30DF65407CD for ; Wed, 13 Feb 2013 09:42:55 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YArueBej4KF for ; Wed, 13 Feb 2013 09:42:43 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5CE3854055C for ; Wed, 13 Feb 2013 09:42:38 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130212.220001.197654139.mbj@tail-f.com> References: <20130211155737.25258.95007.idtracker@ietfa.amsl.com> <67B273A1-7D62-4F2C-8785-620E7E8E998A@nic.cz> <20130212.220001.197654139.mbj@tail-f.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 13 Feb 2013 09:42:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 08:44:14 -0000 Martin Bjorklund writes: > Hi, > > I think the majestic must expression for the connected-routing-table > might be wrong. The problem is that it checks that: > > not (*some* preceding-sibling has same afi > AND > *some* preceding-sibling has same safi) Good catch, the logic is indeed broken. The following 'must' should work better (and is even less majestic, good:-): must "not(/routing/routing-tables/" + "routing-table[name=current()/" + "preceding-sibling::connected-routing-table/" + "name and address-family=/routing/routing-tables/" + "routing-table[name=current()/name]/" + "address-family and safi=/routing/routing-tables/" + "routing-table[name=current()/name]/safi])" { error-message "Duplicate address family for " + "connected routing tables."; description "For each AFN/SAFI pair there MUST NOT be more than one connected routing table."; } To the chairs: Should I post a new revision of the draft with this fix now? Thanks, Lada > > So this instance document snippet does not validate, although I > believe it is correct: > > > > st0 > rt:static > > > tab-1 > > > tab-2 > > > tab-3 > > > > > ... > > > tab-1 > ipv6 > nlri-unicast > > > > tab-2 > ipv4 > nlri-multicast > > > > tab-3 > ipv4 > nlri-unicast > > > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Feb 13 05:34:57 2013 Return-Path: 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 6FC8421F86D6 for ; Wed, 13 Feb 2013 05:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 jVCn5Pr81A1U for ; Wed, 13 Feb 2013 05:34:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA1221F86E6 for ; Wed, 13 Feb 2013 05:34:53 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9604520B6C; Wed, 13 Feb 2013 14:34:52 +0100 (CET) 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 rG8LpfeW26Zh; Wed, 13 Feb 2013 14:34:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D6DB20BDB; Wed, 13 Feb 2013 14:34:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 414C0247B761; Wed, 13 Feb 2013 14:34:59 +0100 (CET) Date: Wed, 13 Feb 2013 14:34:59 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130213133459.GA5732@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20130211155737.25258.95007.idtracker@ietfa.amsl.com> <67B273A1-7D62-4F2C-8785-620E7E8E998A@nic.cz> <20130212.220001.197654139.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:34:57 -0000 On Wed, Feb 13, 2013 at 09:42:37AM +0100, Ladislav Lhotka wrote: > > To the chairs: Should I post a new revision of the draft with this fix now? > Lets wait some someone to ack that the fix is correct before you post a new I-D. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Feb 13 05:55:39 2013 Return-Path: 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 C153521F86F8 for ; Wed, 13 Feb 2013 05:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=0.516, 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 vW2iwNPdRVtl for ; Wed, 13 Feb 2013 05:55:39 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2068E21F86EF for ; Wed, 13 Feb 2013 05:55:39 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 427751200D7A; Wed, 13 Feb 2013 14:55:37 +0100 (CET) Date: Wed, 13 Feb 2013 14:55:37 +0100 (CET) Message-Id: <20130213.145537.623958454941354290.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130213133459.GA5732@elstar.local> References: <20130212.220001.197654139.mbj@tail-f.com> <20130213133459.GA5732@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:55:39 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 13, 2013 at 09:42:37AM +0100, Ladislav Lhotka wrote: > > > > To the chairs: Should I post a new revision of the draft with this fix now? > > > > Lets wait some someone to ack that the fix is correct before you post > a new I-D. I think the new expression is correct. /martin From j.schoenwaelder@jacobs-university.de Wed Feb 13 08:45:47 2013 Return-Path: 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 4F51421F8943 for ; Wed, 13 Feb 2013 08:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 NSdRy5Ypz0yD for ; Wed, 13 Feb 2013 08:45:46 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5555121F8938 for ; Wed, 13 Feb 2013 08:45:43 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95BDB20BDC; Wed, 13 Feb 2013 17:45:42 +0100 (CET) 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 hw1cGbyupQDm; Wed, 13 Feb 2013 17:45:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F17C20BDB; Wed, 13 Feb 2013 17:45:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 270D5247BC3C; Wed, 13 Feb 2013 17:45:49 +0100 (CET) Date: Wed, 13 Feb 2013 17:45:49 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130213164549.GA6157@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130212.220001.197654139.mbj@tail-f.com> <20130213133459.GA5732@elstar.local> <20130213.145537.623958454941354290.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130213.145537.623958454941354290.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:45:47 -0000 On Wed, Feb 13, 2013 at 02:55:37PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Feb 13, 2013 at 09:42:37AM +0100, Ladislav Lhotka wrote: > > > > > > To the chairs: Should I post a new revision of the draft with this fix now? > > > > > > > Lets wait some someone to ack that the fix is correct before you post > > a new I-D. > > I think the new expression is correct. > Thanks. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Feb 21 00:55:41 2013 Return-Path: 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 179CB21F8E2C for ; Thu, 21 Feb 2013 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_20=-0.74, J_CHICKENPOX_23=0.6] 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 N+sRZnLQiIHu for ; Thu, 21 Feb 2013 00:55:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7EF21F8E2A for ; Thu, 21 Feb 2013 00:55:40 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id CC24813F9A9 for ; Thu, 21 Feb 2013 09:55:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361436937; bh=oe2FVW7HpbFND6uTZmXUzcYqXKcFH9XjvzQGE7hIVM0=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=FItUWSrCuKMamLzMQarvT54G2NNYQ0kl74uoCeRfbKH5mDXIu38TQHUuiNkeZDXjs shf57a9ZhxMUf+WwW22FO0xUT3RKFKKPTKsZl+dm8uwp1DNfJoIaeALQTVLV657y+L Uhfbwu2R18A57lQmv0R9TzFE74OJn+aYyhG8AYXw= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> Date: Thu, 21 Feb 2013 09:55:37 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 08:55:41 -0000 Hi, I am wondering about the following situation: Module M includes submodule A, and A in turn includes submodule B, but M = does NOT include B. I think this is not supposed to be legal (and so does pyang), but I = cannot find any text in RFC 6020 saying that this is not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Feb 21 01:00:30 2013 Return-Path: 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 E7FAE21F8E3E for ; Thu, 21 Feb 2013 01:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_23=0.6] 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 2sVZMNISA0OP for ; Thu, 21 Feb 2013 01:00:29 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id BA54921F8E3D for ; Thu, 21 Feb 2013 01:00:28 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r1L90R67000687; Thu, 21 Feb 2013 10:00:27 +0100 Message-ID: <5125E228.1030007@mg-soft.com> Date: Thu, 21 Feb 2013 10:00:25 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> In-Reply-To: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:00:31 -0000 It's right there in "7.1.6. The Include Statement": The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. Hence, a submodule may only include parent module's submodules. Jernej Dne 21.2.2013 9:55, piše Ladislav Lhotka: > Hi, > > I am wondering about the following situation: > > Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. > > I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. > > So how is it actually? > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu Feb 21 01:01:18 2013 Return-Path: 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 CC28321F8E3F for ; Thu, 21 Feb 2013 01:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 R2n5uBNcElMW for ; Thu, 21 Feb 2013 01:01:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7B21F8E3D for ; Thu, 21 Feb 2013 01:01:17 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E387420BC1; Thu, 21 Feb 2013 10:01:16 +0100 (CET) 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 1CpNi79YRoI2; Thu, 21 Feb 2013 10:01:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20ADC20A13; Thu, 21 Feb 2013 10:01:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6E3C324AA3B0; Thu, 21 Feb 2013 10:01:24 +0100 (CET) Date: Thu, 21 Feb 2013 10:01:23 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130221090123.GA55591@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:01:18 -0000 On Thu, Feb 21, 2013 at 09:55:37AM +0100, Ladislav Lhotka wrote: > Hi, > > I am wondering about the following situation: > > Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. > > I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. > > So how is it actually? Does M reference anything defined in B? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Feb 21 01:03:28 2013 Return-Path: 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 C27C821F8A6D for ; Thu, 21 Feb 2013 01:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 dR6mkBSiq3LF for ; Thu, 21 Feb 2013 01:03:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 45F0B21F8DEF for ; Thu, 21 Feb 2013 01:03:28 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9448C13F9A9 for ; Thu, 21 Feb 2013 10:03:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361437407; bh=cy4ZLsvT+YRTLtsflQd0hLxZVCmgIT9AZAp22wGcaUg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=vfadlgM/KEWsWziqaoPRUFtjk2UzUcFFg+bwAGr7lTto5hK1cUnEAXDwYeuj1hYYX ld4szgXsLHMYmMsxR5bQw4CETlb1AanoP6go8PjyeMd1f6fpBO5/neTrKgvmo3Pkge NJb/99eLdm48veqe4GxuLT5kOQk/nT1AR+h3oWmU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130221090123.GA55591@elstar.local> Date: Thu, 21 Feb 2013 10:03:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <768352A5-E355-4A8F-9B8B-182E9C932EDD@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <20130221090123.GA55591@elstar.local> To: netmod@ietf.org X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:03:28 -0000 On Feb 21, 2013, at 10:01 AM, Juergen Schoenwaelder = wrote: > On Thu, Feb 21, 2013 at 09:55:37AM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> I am wondering about the following situation: >>=20 >> Module M includes submodule A, and A in turn includes submodule B, = but M does NOT include B. >>=20 >> I think this is not supposed to be legal (and so does pyang), but I = cannot find any text in RFC 6020 saying that this is not allowed. >>=20 >> So how is it actually? >=20 > Does M reference anything defined in B? No. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Feb 21 01:10:18 2013 Return-Path: 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 2DA0721F8E40 for ; Thu, 21 Feb 2013 01:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 NwYFMCNvV4Ni for ; Thu, 21 Feb 2013 01:10:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4253321F8E3C for ; Thu, 21 Feb 2013 01:10:16 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 83B1813F9A9; Thu, 21 Feb 2013 10:10:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361437809; bh=2MXK76Z29+vQUmnvNxuwMBseH+7MSeD+fJhXKfBukYg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qSQwsrbSuXg1UEeEB8wdMNBItqn8UbdgWvRQ/hvdSzhnmzkKvr92u+ZSEFY5aCl6y zBvkcphEhvRpkNeV2bBdetgOjeiSyhwPGYhoJ8tzVcjm/JHD/2TC3C5/EJTZNO1FX1 qFqITQ8HtG+OTofUjmeKW/+hFhi/ji23Yct69c1w= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <5125E228.1030007@mg-soft.com> Date: Thu, 21 Feb 2013 10:10:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:10:18 -0000 On Feb 21, 2013, at 10:00 AM, Jernej Tuljak = wrote: > It's right there in "7.1.6. The Include Statement": >=20 > The "include" statement is used to make content from a submodule > available to that submodule's parent module, or to another submodule > of that parent module. Right, but suppose one doesn't want/need to make the content of B = available in M (and in modules importing M). >=20 > Hence, a submodule may only include parent module's submodules. My reading is that a submodule is assigned to a main module via = 'belongs-to'. Lada >=20 > Jernej >=20 >=20 > Dne 21.2.2013 9:55, pi=9Ae Ladislav Lhotka: >> Hi, >>=20 >> I am wondering about the following situation: >>=20 >> Module M includes submodule A, and A in turn includes submodule B, = but M does NOT include B. >>=20 >> I think this is not supposed to be legal (and so does pyang), but I = cannot find any text in RFC 6020 saying that this is not allowed. >>=20 >> So how is it actually? >>=20 >> Thanks, Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Feb 21 01:20:05 2013 Return-Path: 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 713AD21F8E3D for ; Thu, 21 Feb 2013 01:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 9n-f0qDS-mwV for ; Thu, 21 Feb 2013 01:20:04 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3A621F8E19 for ; Thu, 21 Feb 2013 01:20:03 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r1L9K2Bf001041; Thu, 21 Feb 2013 10:20:02 +0100 Message-ID: <5125E6C0.6080002@mg-soft.com> Date: Thu, 21 Feb 2013 10:20:00 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> In-Reply-To: <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:20:05 -0000 Dne 21.2.2013 10:10, piše Ladislav Lhotka: > On Feb 21, 2013, at 10:00 AM, Jernej Tuljak wrote: > >> It's right there in "7.1.6. The Include Statement": >> >> The "include" statement is used to make content from a submodule >> available to that submodule's parent module, or to another submodule >> of that parent module. > Right, but suppose one doesn't want/need to make the content of B available in M (and in modules importing M). > You cannot achieve that. The relationship between a module and a submodule is clearly composition, not an association. A submodule is just a way to split a large file into multiple smaller ones, nothing else. You eventually end up with a single logical file no matter what you do. What you are trying to do would require submodules being treated as imports, IMHO. Jernej >> Hence, a submodule may only include parent module's submodules. > My reading is that a submodule is assigned to a main module via 'belongs-to'. > > Lada > >> Jernej >> >> >> Dne 21.2.2013 9:55, piše Ladislav Lhotka: >>> Hi, >>> >>> I am wondering about the following situation: >>> >>> Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. >>> >>> I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. >>> >>> So how is it actually? >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From jonathan@hansfords.net Thu Feb 21 01:24:31 2013 Return-Path: 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 39BBF21F8D0A for ; Thu, 21 Feb 2013 01:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 z51+PoslRXh7 for ; Thu, 21 Feb 2013 01:24:24 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id CAB3021F8E20 for ; Thu, 21 Feb 2013 01:24:22 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 2xQL1l0024CLSd801xQMyl; Thu, 21 Feb 2013 09:24:21 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=48vgC7mUAAAA:8 a=D7Y84tkWjEhXtgNNwCQA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=4J-8bSQHZSv2PxN_j88A:9 a=_W_S_7VecoQA:10 a=TLcNHBmN6eKXsrjq:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 21 Feb 2013 09:24:20 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1ae2d01abe55fa4b616c7ca5ccbac71a" Date: Thu, 21 Feb 2013 09:24:20 +0000 From: Jonathan Hansford To: In-Reply-To: <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> Message-ID: <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:24:32 -0000 --=_1ae2d01abe55fa4b616c7ca5ccbac71a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On 21.02.2013 09:10, Ladislav Lhotka wrote: > On Feb 21, 2013, at 10:00 AM, Jernej Tuljak wrote: > >> It's right there in "7.1.6. The Include Statement": The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. > > Right, but suppose one doesn't want/need to make the content of B available in M (and in modules importing M). > >> Hence, a submodule may only include parent module's submodules. > > My reading is that a submodule is assigned to a main module via 'belongs-to'. I agree, it is 'belongs-to' that defines the module/submodule relationship, not 'include'. And surely, if a module includes submodule A which itself includes submodule B, then the module has indirectly included submodule B. Jonathan > Lada > >> Jernej Dne 21.2.2013 9:55, piÅ¡e Ladislav Lhotka: >> >>> Hi, I am wondering about the following situation: Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org [1]https://www.ietf.org/mailman/listinfo/netmod [2] > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod Links: ------ [1] mailto:netmod@ietf.org [2] https://www.ietf.org/mailman/listinfo/netmod --=_1ae2d01abe55fa4b616c7ca5ccbac71a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 21.02.2013 09:10, Ladislav Lhotka wrote:

On Feb 21, 2013, at 10:00 AM, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:
It's right there in "7.1.6. The Inclu= de Statement": The "include" statement is used to make content from a submo= dule available to that submodule's parent module, or to another submodule o= f that parent module.
Right, but suppose one doesn't want/need to make the content of B avai=
lable in M (and in modules importing M).
Hence, a submodule may only include p= arent module's submodules.
My reading is that a submodule is assigned to a main module via 'belon=
gs-to'.
 
I agree, it is 'belongs-to' that defines the module/submodule relation=
ship, not 'include'. And surely, if a module includes submodule A which its=
elf includes submodule B, then the module has indirectly included submodule=
 B.
 
Jonathan
Lada
Jernej Dne 21.2.2013 9:55, piš= e Ladislav Lhotka:
Hi, I am wondering about the followin= g situation: Module M includes submodule A, and A in turn includes submodul= e B, but M does NOT include B. I think this is not supposed to be legal (an= d so does pyang), but I cannot find any text in RFC 6020 saying that this i= s not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ= =2ENIC Labs PGP Key ID: E74E8C0C __________________________________________= _____ netmod mailing list netmod@ietf.or= ghttps://www= =2Eietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
 
--=_1ae2d01abe55fa4b616c7ca5ccbac71a-- From lhotka@nic.cz Thu Feb 21 01:31:14 2013 Return-Path: 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 D316921F8E54 for ; Thu, 21 Feb 2013 01:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 cTif65rSJMKD for ; Thu, 21 Feb 2013 01:31:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2421F8E58 for ; Thu, 21 Feb 2013 01:31:13 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F3DBD13F9A9; Thu, 21 Feb 2013 10:31:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361439073; bh=U2/vWJ/2IQC/QPT5UGU4w0OBzE9tUPFyCPCld8xpX6Y=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XY34dWT/w2alMFuF/rLXoNzoZE89rq8s66KKyS1QPv3p1JsLpCj/vuyqQhY2T4zcd YICw3Xcrx9pEB4Em9PKySWVGnM6FYepp8v9dawKkR++Z3vHzB7i1uAu8OREhJBwy5z rq8KBLvH8tFBRANkiBoJRVbvCHHy4gCUsN0ZXqaI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <5125E6C0.6080002@mg-soft.com> Date: Thu, 21 Feb 2013 10:31:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <686E388B-EF25-4173-9132-BD4498E7FC3C@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <5125E6C0.6080002@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:31:15 -0000 On Feb 21, 2013, at 10:20 AM, Jernej Tuljak = wrote: > Dne 21.2.2013 10:10, pi=9Ae Ladislav Lhotka: >> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak = wrote: >>=20 >>> It's right there in "7.1.6. The Include Statement": >>>=20 >>> The "include" statement is used to make content from a submodule >>> available to that submodule's parent module, or to another = submodule >>> of that parent module. >> Right, but suppose one doesn't want/need to make the content of B = available in M (and in modules importing M). >>=20 >=20 > You cannot achieve that. The relationship between a module and a = submodule is clearly composition, not an association. A submodule is = just a way to split a large file into multiple smaller ones, nothing = else. You eventually end up with a single logical file no matter what = you do. Not really. For example, a submodule cannot reference stuff defined in = the main module. >=20 > What you are trying to do would require submodules being treated as = imports, IMHO. I don't think so. In fact, the situation I described might be useful as = an additional way for structuring the name space. Lada >=20 > Jernej >=20 >>> Hence, a submodule may only include parent module's submodules. >> My reading is that a submodule is assigned to a main module via = 'belongs-to'. >>=20 >> Lada >>=20 >>> Jernej >>>=20 >>>=20 >>> Dne 21.2.2013 9:55, pi=9Ae Ladislav Lhotka: >>>> Hi, >>>>=20 >>>> I am wondering about the following situation: >>>>=20 >>>> Module M includes submodule A, and A in turn includes submodule B, = but M does NOT include B. >>>>=20 >>>> I think this is not supposed to be legal (and so does pyang), but I = cannot find any text in RFC 6020 saying that this is not allowed. >>>>=20 >>>> So how is it actually? >>>>=20 >>>> Thanks, Lada >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Feb 21 01:42:20 2013 Return-Path: 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 1B6D721F8E41 for ; Thu, 21 Feb 2013 01:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 iecmv-A9l99P for ; Thu, 21 Feb 2013 01:42:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5521F8E3D for ; Thu, 21 Feb 2013 01:42:18 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 644DA13F64C; Thu, 21 Feb 2013 10:42:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361439737; bh=owj1kIrYZpitQsvQgBuXYRRdXJybNwy/Vq2pwOh9m/c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZMz40v3B40M14PWbyVBjG84brfOoNg3BUJVb+Z+fx//ECS76moQ6lIMDGfjjT2TnU qUbVPYn6+eMzr5+i+t/e/mBLLyfzu81pILW2QscMO8QUm0nxjSbIr+rqMhcZm/0f4R 1n3AdBJnGQHuSE0QBfwoWYU38tpzzjyFPX3dko30= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> Date: Thu, 21 Feb 2013 10:42:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> To: Jonathan Hansford X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 09:42:20 -0000 On Feb 21, 2013, at 10:24 AM, Jonathan Hansford = wrote: > =20 > On 21.02.2013 09:10, Ladislav Lhotka wrote: >=20 >> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak = wrote: >>> It's right there in "7.1.6. The Include Statement": The "include" = statement is used to make content from a submodule available to that = submodule's parent module, or to another submodule of that parent = module. >> Right, but suppose one doesn't want/need to make the content of B = available in M (and in modules importing M). >>> Hence, a submodule may only include parent module's submodules. >> My reading is that a submodule is assigned to a main module via = 'belongs-to'. >> =20 > I agree, it is 'belongs-to' that defines the module/submodule = relationship, not 'include'. And surely, if a module includes submodule = A which itself includes submodule B, then the module has indirectly = included submodule B. This conclusion can hardly be drawn from 6020 text, and I actually think = submodule inclusion was not designed to be transitive. For instance, if = submodule A includes submodule B, and B includes C, then A cannot refer = to C's definitions without including C. Lada =20 > =20 > Jonathan >> Lada >>> Jernej Dne 21.2.2013 9:55, pi=9Ae Ladislav Lhotka: >>>> Hi, I am wondering about the following situation: Module M includes = submodule A, and A in turn includes submodule B, but M does NOT include = B. I think this is not supposed to be legal (and so does pyang), but I = cannot find any text in RFC 6020 saying that this is not allowed. So how = is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: = E74E8C0C _______________________________________________ netmod mailing = list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >>=20 >> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Thu Feb 21 02:25:06 2013 Return-Path: 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 7290E21F8E50 for ; Thu, 21 Feb 2013 02:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.943 X-Spam-Level: X-Spam-Status: No, score=-4.943 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 6GOOmTISKhfO for ; Thu, 21 Feb 2013 02:25:05 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 479A921F8E4F for ; Thu, 21 Feb 2013 02:25:04 -0800 (PST) Received: from mail43-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 10:25:04 +0000 Received: from mail43-tx2 (localhost [127.0.0.1]) by mail43-tx2-R.bigfish.com (Postfix) with ESMTP id 330014A01BB; Thu, 21 Feb 2013 10:25:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I542I1432I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL8275dhz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh304l1155h) Received: from mail43-tx2 (localhost.localdomain [127.0.0.1]) by mail43-tx2 (MessageSwitch) id 1361442302932162_32189; Thu, 21 Feb 2013 10:25:02 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.242]) by mail43-tx2.bigfish.com (Postfix) with ESMTP id D5C022A0083; Thu, 21 Feb 2013 10:25:02 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Feb 2013 10:25:02 +0000 Received: from DBXPRD0611HT001.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 21 Feb 2013 10:24:59 +0000 Message-ID: <015901ce101d$3bd2f4a0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Jonathan Hansford References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz><5125E228.1030007@mg-soft.com><14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz><0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> Date: Thu, 21 Feb 2013 10:21:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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-Originating-IP: [157.56.254.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:25:06 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "Jonathan Hansford" Cc: Sent: Thursday, February 21, 2013 9:42 AM Subject: Re: [netmod] include On Feb 21, 2013, at 10:24 AM, Jonathan Hansford wrote: > > On 21.02.2013 09:10, Ladislav Lhotka wrote: > >> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak wrote: >>> It's right there in "7.1.6. The Include Statement": The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. >> Right, but suppose one doesn't want/need to make the content of B available in M (and in modules importing M). >>> Hence, a submodule may only include parent module's submodules. >> My reading is that a submodule is assigned to a main module via 'belongs-to'. >> > I agree, it is 'belongs-to' that defines the module/submodule relationship, not 'include'. And surely, if a module includes submodule A which itself includes submodule B, then the module has indirectly included submodule B. This conclusion can hardly be drawn from 6020 text, and I actually think submodule inclusion was not designed to be transitive. For instance, if submodule A includes submodule B, and B includes C, then A cannot refer to C's definitions without including C. s5.1 "There MUST NOT be any circular chains of imports or includes. For example, if submodule "a" includes submodule "b", "b" cannot include "a". " so chains are clearly permitted do " o For a module to reference definitions in one of its submodules, the module MUST include the submodule. o For a submodule to reference definitions in a second submodule of the same module, the first submodule MUST include the second submodule." seems clear that A must include C even if B includes C. Tom Petch Lada > > Jonathan >> Lada >>> Jernej Dne 21.2.2013 9:55, pi=9Ae Ladislav Lhotka: >>>> Hi, I am wondering about the following situation: Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Thu Feb 21 02:34:29 2013 Return-Path: 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 1F1E521F8E5D for ; Thu, 21 Feb 2013 02:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 qeD7c8BJs5x5 for ; Thu, 21 Feb 2013 02:34:28 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 34C2121F8E5B for ; Thu, 21 Feb 2013 02:34:28 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r1LAYPEx001981; Thu, 21 Feb 2013 11:34:25 +0100 Message-ID: <5125F82F.6070100@mg-soft.com> Date: Thu, 21 Feb 2013 11:34:23 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> In-Reply-To: <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:34:29 -0000 Dne 21.2.2013 10:42, piše Ladislav Lhotka: > On Feb 21, 2013, at 10:24 AM, Jonathan Hansford wrote: > >> >> On 21.02.2013 09:10, Ladislav Lhotka wrote: >> >>> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak wrote: >>>> It's right there in "7.1.6. The Include Statement": The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. >>> Right, but suppose one doesn't want/need to make the content of B available in M (and in modules importing M). >>>> Hence, a submodule may only include parent module's submodules. >>> My reading is that a submodule is assigned to a main module via 'belongs-to'. >>> >> I agree, it is 'belongs-to' that defines the module/submodule relationship, not 'include'. And surely, if a module includes submodule A which itself includes submodule B, then the module has indirectly included submodule B. > This conclusion can hardly be drawn from 6020 text, and I actually think submodule inclusion was not designed to be transitive. For instance, if submodule A includes submodule B, and B includes C, then A cannot refer to C's definitions without including C. 5.1 says that "submodules are partial modules that contribute definitions to a module" (not to a submodule). A submodule that contributes nothing is therefore not a submodule. And a submodule may only be allowed to contribute to a module via an include statement. I can't find text to support a contribution of another kind. Both "belongs-to" and "include" are required counterparts (a belongs-to must always be matched to an include statement in the main module) and define a composition relationship. This also eliminates transitivity as an option. A "belongs-to" is not enough to define the relationship between a module and a submodule, because a module is never even aware of a submodule's existence if include statement is not used. A base unit of definition in YANG is a module. There's no such thing as a standalone submodule without contributions. Jernej > > Lada > >> >> Jonathan >>> Lada >>>> Jernej Dne 21.2.2013 9:55, piše Ladislav Lhotka: >>>>> Hi, I am wondering about the following situation: Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> >>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Thu Feb 21 02:36:53 2013 Return-Path: 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 709F821F8E63 for ; Thu, 21 Feb 2013 02:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] 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 VxxwiQR6qj9t for ; Thu, 21 Feb 2013 02:36:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5985C21F8E5D for ; Thu, 21 Feb 2013 02:36:52 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5B35913F64C; Thu, 21 Feb 2013 11:36:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361443011; bh=J0ub0VoPKj7fr0RO1fVfV+Z+zQ7TQJ4BAkAWSDMvyqk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BAw7FtBHUmh1c+xQFuoo2DQdZnV+as0lQCxXcSdyrhcrzY1UVUfAZ+V+yooAWQGWY BqU/+ZhFlSKfYiy9MPVt0UEZRNkLQFmI8lJ3BB4Tc40yPOjC50aG0CRBgXgr2N/n+Y Mr9MdiXzYjK3n9A+u/LhsuWClZsqFjHj2l7XN148= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <015901ce101d$3bd2f4a0$4001a8c0@gateway.2wire.net> Date: Thu, 21 Feb 2013 11:36:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz><5125E228.1030007@mg-soft.com><14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz><0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <015901ce101d$3bd2f4a0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:36:53 -0000 On Feb 21, 2013, at 11:21 AM, t.petch wrote: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Jonathan Hansford" > Cc: > Sent: Thursday, February 21, 2013 9:42 AM > Subject: Re: [netmod] include >=20 >=20 >=20 > On Feb 21, 2013, at 10:24 AM, Jonathan Hansford = > wrote: >=20 >>=20 >> On 21.02.2013 09:10, Ladislav Lhotka wrote: >>=20 >>> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak > wrote: >>>> It's right there in "7.1.6. The Include Statement": The "include" > statement is used to make content from a submodule available to that > submodule's parent module, or to another submodule of that parent > module. >>> Right, but suppose one doesn't want/need to make the content of B > available in M (and in modules importing M). >>>> Hence, a submodule may only include parent module's submodules. >>> My reading is that a submodule is assigned to a main module via > 'belongs-to'. >>>=20 >> I agree, it is 'belongs-to' that defines the module/submodule > relationship, not 'include'. And surely, if a module includes = submodule > A which itself includes submodule B, then the module has indirectly > included submodule B. >=20 > This conclusion can hardly be drawn from 6020 text, and I actually = think > submodule inclusion was not designed to be transitive. For instance, = if > submodule A includes submodule B, and B includes C, then A cannot = refer > to C's definitions without including C. >=20 > > s5.1 > "There MUST NOT be any circular chains of imports or includes. For > example, if submodule "a" includes submodule "b", "b" cannot include > "a". " > so chains are clearly permitted >=20 > do > " > o For a module to reference definitions in one of its submodules, > the module MUST include the submodule. >=20 > o For a submodule to reference definitions in a second submodule of > the same module, the first submodule MUST include the second > submodule." >=20 > seems clear that A must include C even if B includes C. Yes, that was exactly my point - and the first bullet above indicates = that there is no indirect inclusion for the main module either. Lada >=20 > Tom Petch >=20 > Lada >>=20 >> Jonathan >>> Lada >>>> Jernej Dne 21.2.2013 9:55, pi=9Ae Ladislav Lhotka: >>>>> Hi, I am wondering about the following situation: Module M = includes > submodule A, and A in turn includes submodule B, but M does NOT = include > B. I think this is not supposed to be legal (and so does pyang), but I > cannot find any text in RFC 6020 saying that this is not allowed. So = how > is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key = ID: > E74E8C0C _______________________________________________ >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Feb 21 02:54:44 2013 Return-Path: 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 A018D21F8E49 for ; Thu, 21 Feb 2013 02:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 Kw8ytnEPhCUI for ; Thu, 21 Feb 2013 02:54:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 93D7221F8E46 for ; Thu, 21 Feb 2013 02:54:43 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D232013F64C; Thu, 21 Feb 2013 11:54:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361444082; bh=m7GHpdRVLaHaIDd38gBTDQRF69/5r48Y6QVR9R0SeJc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Bc0dur3uM0sbZGRKSgi6lRatOy7iPn9fTQ0JA59eZaLY6AM0v8iC/OQv34Q5IRfDD K9DcqnAhgbr2upka75zkthRdjdbP16SR8/4mVgnr6zGk3g/HRugbpbbjtF7Jabs1tp B3xcWf6/wbslXxWCu63MjDpUEpgw5aisXBg5X1JE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <5125F82F.6070100@mg-soft.com> Date: Thu, 21 Feb 2013 11:54:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:54:44 -0000 On Feb 21, 2013, at 11:34 AM, Jernej Tuljak = wrote: > Dne 21.2.2013 10:42, pi=9Ae Ladislav Lhotka: >> On Feb 21, 2013, at 10:24 AM, Jonathan Hansford = wrote: >>=20 >>> On 21.02.2013 09:10, Ladislav Lhotka wrote: >>>=20 >>>> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak = wrote: >>>>> It's right there in "7.1.6. The Include Statement": The "include" = statement is used to make content from a submodule available to that = submodule's parent module, or to another submodule of that parent = module. >>>> Right, but suppose one doesn't want/need to make the content of B = available in M (and in modules importing M). >>>>> Hence, a submodule may only include parent module's submodules. >>>> My reading is that a submodule is assigned to a main module via = 'belongs-to'. >>>> =20 >>> I agree, it is 'belongs-to' that defines the module/submodule = relationship, not 'include'. And surely, if a module includes submodule = A which itself includes submodule B, then the module has indirectly = included submodule B. >> This conclusion can hardly be drawn from 6020 text, and I actually = think submodule inclusion was not designed to be transitive. For = instance, if submodule A includes submodule B, and B includes C, then A = cannot refer to C's definitions without including C. >=20 > 5.1 says that "submodules are partial modules that contribute = definitions to a module" (not to a submodule). A submodule that = contributes nothing is therefore not a submodule. And a submodule may = only be allowed to contribute to a module via an include statement. I = can't find text to support a contribution of another kind. It depends on what you mean by "contribute". A submodule can provide = type and grouping definitions that are used by other submodules that are = included by the main module and contribute data nodes to the model = schema. Assuming the same static scoping as for imports, this could work = just fine. >=20 > Both "belongs-to" and "include" are required counterparts (a = belongs-to must always be matched to an include statement in the main = module) and define a composition relationship. This also eliminates = transitivity as an option. This might indeed be the right thing to do but my point is that it = doesn't follow from RFC 6020, and the opposite interpretation could IMO = make sense, too. >=20 > A "belongs-to" is not enough to define the relationship between a = module and a submodule, because a module is never even aware of a = submodule's existence if include statement is not used. A base unit of = definition in YANG is a module. There's no such thing as a standalone = submodule without contributions. It is more about visibility of definitions. Lada >=20 > Jernej >=20 >>=20 >> Lada >>=20 >>> Jonathan >>>> Lada >>>>> Jernej Dne 21.2.2013 9:55, pi=9Ae Ladislav Lhotka: >>>>>> Hi, I am wondering about the following situation: Module M = includes submodule A, and A in turn includes submodule B, but M does NOT = include B. I think this is not supposed to be legal (and so does pyang), = but I cannot find any text in RFC 6020 saying that this is not allowed. = So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP = Key ID: E74E8C0C _______________________________________________ netmod = mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>>=20 >>>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jonathan@hansfords.net Thu Feb 21 03:03:30 2013 Return-Path: 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 8736D21F89AE for ; Thu, 21 Feb 2013 03:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 O2eCBqOCas-1 for ; Thu, 21 Feb 2013 03:03:28 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6A60521F8413 for ; Thu, 21 Feb 2013 03:03:26 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 2z3P1l0094CLSd801z3QH7; Thu, 21 Feb 2013 11:03:25 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=48vgC7mUAAAA:8 a=Xz10PCVoK5jFa6idsIcA:9 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=lZB815dzVvQA:10 a=zU7ctqMk8GsRawc1oXQA:9 a=_W_S_7VecoQA:10 a=48QFA3YN36HPPusz:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 21 Feb 2013 11:03:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ccdf36d9378f78fc6478f223b600baa9" Date: Thu, 21 Feb 2013 11:03:23 +0000 From: Jonathan Hansford To: Jernej Tuljak In-Reply-To: <5125F82F.6070100@mg-soft.com> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> Message-ID: <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 11:03:30 -0000 --=_ccdf36d9378f78fc6478f223b600baa9 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 On 21.02.2013 10:34, Jernej Tuljak wrote: > Dne 21.2.2013 10:42, piÅ¡e Ladislav Lhotka: > >> On Feb 21, 2013, at 10:24 AM, Jonathan Hansford wrote: >> >>> On 21.02.2013 09:10, Ladislav Lhotka wrote: >>> >>>> On Feb 21, 2013, at 10:00 AM, Jernej Tuljak wrote: >>>> >>>>> It's right there in "7.1.6. The Include Statement": The "include" statement is used to make content from a submodule available to that submodule's parent module, or to another submodule of that parent module. >>>> Right, but suppose one doesn't want/need to make the content of B available in M (and in modules importing M). >>>> >>>>> Hence, a submodule may only include parent module's submodules. >>>> My reading is that a submodule is assigned to a main module via 'belongs-to'. >>> I agree, it is 'belongs-to' that defines the module/submodule relationship, not 'include'. And surely, if a module includes submodule A which itself includes submodule B, then the module has indirectly included submodule B. >> This conclusion can hardly be drawn from 6020 text, and I actually think submodule inclusion was not designed to be transitive. For instance, if submodule A includes submodule B, and B includes C, then A cannot refer to C's definitions without including C. > > 5.1 says that "submodules are partial modules that contribute > definitions to a module" (not to a submodule). A submodule that > contributes nothing is therefore not a submodule. And a submodule may > only be allowed to contribute to a module via an include statement. I > can't find text to support a contribution of another kind. > > Both "belongs-to" and "include" are required counterparts (a belongs-to > must always be matched to an include statement in the main module) and > define a composition relationship. This also eliminates transitivity as > an option. > > A "belongs-to" is not enough to define the relationship between a module > and a submodule, because a module is never even aware of a submodule's > existence if include statement is not used. A base unit of definition in > YANG is a module. There's no such thing as a standalone submodule > without contributions. 5.1 states "For a module to reference definitions in one of its submodules, the module MUST include the submodule." That would seem to infer that a module only needs to include a submodule if it needs to reference definitions from that submodule. Some submodules may only be referenced by other submodules rather than by the module itself. Does the module need to be "aware" of a submodule's existence if it doesn't reference it? Jernej >> Lada >> >>> Jonathan >>> >>>> Lada >>>> >>>>> Jernej Dne 21.2.2013 9:55, piÅ¡e Ladislav Lhotka: >>>>> >>>>>> Hi, I am wondering about the following situation: Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. I think this is not supposed to be legal (and so does pyang), but I cannot find any text in RFC 6020 saying that this is not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.orghttps: [3]//www.ietf.org/mailman/listinfo/netmod >>>> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.orghttps: [4]//www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ netmod mailing list netmod@ietf.org [5]https://www.ietf.org/mailman/listinfo/netmod [6] >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org [7]https://www.ietf.org/mailman/listinfo/netmod [8] Links: ------ [1] mailto:jernej.tuljak@mg-soft.si [2] mailto:Jonathan@hansfords.net [3] mailto:netmod@ietf.orghttps: [4] mailto:netmod@ietf.orghttps: [5] mailto:netmod@ietf.org [6] https://www.ietf.org/mailman/listinfo/netmod [7] mailto:netmod@ietf.org [8] https://www.ietf.org/mailman/listinfo/netmod --=_ccdf36d9378f78fc6478f223b600baa9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 21.02.2013 10:34, Jernej Tuljak wrote:

Dne 21.2.2013 10:42, piše Ladislav Lhotka:
On Feb 21, 2013, at 10:24 AM, Jonatha= n Hansford <Jonathan@hansfords= =2Enet> wrote:
On 21.02.2013 09:10, Ladislav Lhotka = wrote:
On Feb 21, 2013, at 10:00 AM, Jernej = Tuljak <jernej.tuljak@mg-sof= t.si> wrote:
It's right there in "7.1.6. The Inclu= de Statement": The "include" statement is used to make content from a submo= dule available to that submodule's parent module, or to another submodule o= f that parent module.
Right, but suppose one doesn't want/need to make the content of B available= in M (and in modules importing M).
Hence, a submodule may only include p= arent module's submodules.
My reading is that a submodule is assigned to a main module via 'belongs-to= '.
I agree, it is 'belongs-to' that defines the module/submodule relationship,= not 'include'. And surely, if a module includes submodule A which itself i= ncludes submodule B, then the module has indirectly included submodule B. This conclusion can hardly be drawn from 6020 text, and I actually think su= bmodule inclusion was not designed to be transitive. For instance, if submo= dule A includes submodule B, and B includes C, then A cannot refer to C's d= efinitions without including C.
5.1 says that "submodules are partial modules that contribute=20
definitions to a  module" (not to a submodule). A submodule that=20
contributes nothing is therefore not a submodule. And a submodule may=20
only be allowed to contribute to a module via an include statement. I=20
can't find text to support a contribution of another kind.

Both "belongs-to" and "include" are required counterparts (a belongs-to=20
must always be matched to an include statement in the main module) and=20
define a composition relationship. This also eliminates transitivity as=20
an option.

A "belongs-to" is not enough to define the relationship between a module=20
and a submodule, because a module is never even aware of a submodule's=20
existence if include statement is not used. A base unit of definition in=20
YANG is a module. There's no such thing as a standalone submodule=20
without contributions.
 
5.1 states "For a module to reference definitions in one of its submod=
ules, the module MUST include the submodule." That would seem to infer that=
 a module only needs to include a submodule if it needs to reference defini=
tions from that submodule. Some submodules may only be referenced by other =
submodules rather than by the module itself. Does the module need to be "aw=
are" of a submodule's existence if it doesn't reference it?
Jernej
Lada
Jonathan
Lada
Jernej Dne 21.2.2013 9:55, piš= e Ladislav Lhotka:
Hi, I am wondering about the followin= g situation: Module M includes submodule A, and A in turn includes submodul= e B, but M does NOT include B. I think this is not supposed to be legal (an= d so does pyang), but I cannot find any text in RFC 6020 saying that this i= s not allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ= =2ENIC Labs PGP Key ID: E74E8C0C __________________________________________= _____ netmod mailing list netmod@i= etf.orghttps://www.ietf.org/mailman/listinfo/netmod
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netm= od
_______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmo= d
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
 
--=_ccdf36d9378f78fc6478f223b600baa9-- From andy@yumaworks.com Thu Feb 21 05:28:49 2013 Return-Path: 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 8C44121F8A56 for ; Thu, 21 Feb 2013 05:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 CJ-uo1nUEWMQ for ; Thu, 21 Feb 2013 05:28:48 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8E71921F87C5 for ; Thu, 21 Feb 2013 05:28:48 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so8207816iaf.14 for ; Thu, 21 Feb 2013 05:28:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=sh/qBZEy6wq3jeDTVSbUx35d7WTTz0Us83vtiLyhiyc=; b=QDCMwF5kO23B/13YTBDi1p11jd7G/k8IYa8yA3/FA6xazZfGWPF3cBXJB+HJzH92vQ dkVmu2U7isTspVNPQ0CEKrFDCS3Z40jauqZVps0oLfZXw32tO17+FY9P2zUr5uJjk7N/ /LzC1Rwxq28/gGQrqH1rSYrCFsvjWvXIIgyucfXko7Tf5RYGjjXnVThFo92tEbQPz3yP O+SAsJ+OeKtkYOirmy0SrkGb0LbViEk6OZ6TV5XH4roF2ohC4petPSLle/wPihEbPqif mXmviJumJbT37BLis7WXANjHj4Nl648/C8kQlnMS0EQywq+UIybXNmVbAiYiLephVj2n T/Pw== MIME-Version: 1.0 X-Received: by 10.42.201.73 with SMTP id ez9mr10367372icb.29.1361453328051; Thu, 21 Feb 2013 05:28:48 -0800 (PST) Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 05:28:47 -0800 (PST) In-Reply-To: <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> Date: Thu, 21 Feb 2013 05:28:47 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=20cf301cc498ff2f4004d63c0d30 X-Gm-Message-State: ALoCoQk92er9esCzM8LsjezesseWUeMTk95CkOXDIVSiugISRkp/yQez11STUY73PQT+pZegI8Bz Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 13:28:49 -0000 --20cf301cc498ff2f4004d63c0d30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 3:03 AM, Jonathan Hansford wrote: > ** > > > > On 21.02.2013 10:34, Jernej Tuljak wrote: > > Dne 21.2.2013 10:42, pi=C5=A1e Ladislav Lhotka: > > On Feb 21, 2013, at 10:24 AM, Jonathan Hansford > wrote: > > On 21.02.2013 09:10, Ladislav Lhotka wrote: > > On Feb 21, 2013, at 10:00 AM, Jernej Tuljak > wrote: > > It's right there in "7.1.6. The Include Statement": The "include" > statement is used to make content from a submodule available to that > submodule's parent module, or to another submodule of that parent module. > > Right, but suppose one doesn't want/need to make the content of B > available in M (and in modules importing M). > > Hence, a submodule may only include parent module's submodules. > > My reading is that a submodule is assigned to a main module via > 'belongs-to'. > > I agree, it is 'belongs-to' that defines the module/submodule > relationship, not 'include'. And surely, if a module includes submodule A > which itself includes submodule B, then the module has indirectly include= d > submodule B. > > This conclusion can hardly be drawn from 6020 text, and I actually think > submodule inclusion was not designed to be transitive. For instance, if > submodule A includes submodule B, and B includes C, then A cannot refer t= o > C's definitions without including C. > > 5.1 says that "submodules are partial modules that contribute > definitions to a module" (not to a submodule). A submodule that > contributes nothing is therefore not a submodule. And a submodule may > only be allowed to contribute to a module via an include statement. I > can't find text to support a contribution of another kind. > > Both "belongs-to" and "include" are required counterparts (a belongs-to > must always be matched to an include statement in the main module) and > define a composition relationship. This also eliminates transitivity as > an option. > > A "belongs-to" is not enough to define the relationship between a module > and a submodule, because a module is never even aware of a submodule's > existence if include statement is not used. A base unit of definition in > YANG is a module. There's no such thing as a standalone submodule > without contributions. > > > > 5.1 states "For a module to reference definitions in one of its submodul= es, the module MUST include the submodule." That would seem to infer that a= module only needs to include a submodule if it needs to reference definiti= ons from that submodule. Some submodules may only be referenced by other su= bmodules rather than by the module itself. Does the module need to be "awar= e" of a submodule's existence if it doesn't reference it? > > Sub-modules are not that intuitive. They appear to create a hierarchy but that is not true. If mod-A includes submod-B includes submod-C and C defines top level definitions (including augment) then a client that imports mod-A can access the definitions from submod-C. The hierarchy is only for using definitions. mod-A cannot directly reference definitions from submod-C without including it. Submodules cannot reference any definitions from the main module ever, which is really not intuitive. Include-stmt only affects definition resolution within the module. To the client, submodules are semantically invisible. Jernej > > Lada > > Jonathan > > Lada > > Andy > Jernej Dne 21.2.2013 9:55, pi=C5=A1e Ladislav Lhotka: > > Hi, I am wondering about the following situation: Module M includes > submodule A, and A in turn includes submodule B, but M does NOT include B= . > I think this is not supposed to be legal (and so does pyang), but I canno= t > find any text in RFC 6020 saying that this is not allowed. So how is it > actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C= 0C > _______________________________________________ netmod mailing list > netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C > _______________________________________________ netmod mailing list > netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ netmod mailing list > netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C > _______________________________________________ netmod mailing list > netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --20cf301cc498ff2f4004d63c0d30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 21, 2013 at 3:03 AM, Jonatha= n Hansford <Jonathan@hansfords.net> wrote:

=C2=A0

On 21.02.2013 10:34, Jernej Tuljak wrote:

Dne 21.2.2013 10:42, pi=C5=A1e Ladislav Lhotka:
On Feb 21, 2013, at 10:24 AM, Jonathan H= ansford <Jon= athan@hansfords.net> wrote:
On 21.02.2013 09:10, Ladislav Lhotka wro= te:
On Feb 21, 2013, at 10:00 AM, Jernej Tul= jak <jerne= j.tuljak@mg-soft.si> wrote:
It's right there in "7.1.6. The= Include Statement": The "include" statement is used to make= content from a submodule available to that submodule's parent module, = or to another submodule of that parent module.
Right, but suppose one doesn't want/need to make the content of B avail= able in M (and in modules importing M).
Hence, a submodule may only include pare= nt module's submodules.
My reading is that a submodule is assigned to a main module via 'belong= s-to'.
I agree, it is 'belongs-to' that defines the module/submodule relat= ionship, not 'include'. And surely, if a module includes submodule = A which itself includes submodule B, then the module has indirectly include= d submodule B.
This conclusion can hardly be drawn from 6020 text, and I actually think su= bmodule inclusion was not designed to be transitive. For instance, if submo= dule A includes submodule B, and B includes C, then A cannot refer to C'= ;s definitions without including C.
5.1 says that "submodules are partial modules that contribute=20
definitions to a  module" (not to a submodule). A submodule that=20
contributes nothing is therefore not a submodule. And a submodule may=20
only be allowed to contribute to a module via an include statement. I=20
can't find text to support a contribution of another kind.

Both "belongs-to" and "include" are required counterpar=
ts (a belongs-to=20
must always be matched to an include statement in the main module) and=20
define a composition relationship. This also eliminates transitivity as=20
an option.

A "belongs-to" is not enough to define the relationship between a=
 module=20
and a submodule, because a module is never even aware of a submodule's=
=20
existence if include statement is not used. A base unit of definition in=20
YANG is a module. There's no such thing as a standalone submodule=20
without contributions.
=C2=A0
5.1 states "For a module to reference definitions in one of its s=
ubmodules, the module MUST include the submodule." That would seem to =
infer that a module only needs to include a submodule if it needs to refere=
nce definitions from that submodule. Some submodules may only be referenced=
 by other submodules rather than by the module itself. Does the module need=
 to be "aware" of a submodule's existence if it doesn't r=
eference it?

Sub-modules are not that intuitive.<= /div>
They appear to create a hierarchy but that is not true.
If mod-A includes submod-B includes submod-C and C defines top
level definitions (including augment) then a client that imports
= mod-A can access the definitions from submod-C.

Th= e hierarchy is only for using definitions.
mod-A cannot directly = reference definitions from submod-C without including it.
Submodules cannot reference any definitions from the main module ever,=
which is really not intuitive.

Include-= stmt only affects definition resolution within the module.
To the= client, submodules are semantically invisible.


Jernej
Lada
Jonathan
Lada


Andy<= /div>
=C2=A0
Jernej Dne 21.2.2013 9:55, pi=C5=A1e Lad= islav Lhotka:
Hi, I am wondering about the following s= ituation: Module M includes submodule A, and A in turn includes submodule B= , but M does NOT include B. I think this is not supposed to be legal (and s= o does pyang), but I cannot find any text in RFC 6020 saying that this is n= ot allowed. So how is it actually? Thanks, Lada -- Ladislav Lhotka, CZ.NIC = Labs PGP Key ID: E74E8C0C _______________________________________________ n= etmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailma= n/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.orghttps://ww= w.ietf.org/mailman/listinfo/netmod
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/lis= tinfo/netmod
=C2=A0

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


--20cf301cc498ff2f4004d63c0d30-- From lhotka@nic.cz Thu Feb 21 05:53:37 2013 Return-Path: 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 AE92021F8686 for ; Thu, 21 Feb 2013 05:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 jFHDBDeFZgKK for ; Thu, 21 Feb 2013 05:53:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 810FB21F841C for ; Thu, 21 Feb 2013 05:53:22 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B1EF813F9A9; Thu, 21 Feb 2013 14:53:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361454790; bh=E4VlgzIxd0zxQ7qoqAD702fmQMMUw1oALUjvAWWnKRE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oODDakAplUSUMfNX0WDDnt5VUyeawHQeIgf29Snl1oGSmxVZy8BfJZ/ujRIS9ODUF s0apeCpW+KOzmk5JEFSKW71ORPJTdZudfQRD66twW8SP7wLFhaKXKxssfq2d8ct2Z4 TpxG9PpYyT+Ora2UAPP3309Y3Ui6WdAnkBIsBKRc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 21 Feb 2013 14:53:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 13:53:37 -0000 On Feb 21, 2013, at 2:28 PM, Andy Bierman wrote: >=20 > Sub-modules are not that intuitive. > They appear to create a hierarchy but that is not true. > If mod-A includes submod-B includes submod-C and C defines top > level definitions (including augment) then a client that imports > mod-A can access the definitions from submod-C. Even if mod-A doesn't include submod-C? This could lead to nasty = ambiguities, for example if both mod-A and submod-C define a top-level = grouping with the same name. =46rom the viewpoint of mod-A it is OK = because mod-A doesn't see the C's definition, but an importing module = would see both. Lada >=20 > The hierarchy is only for using definitions. > mod-A cannot directly reference definitions from submod-C without = including it. > Submodules cannot reference any definitions from the main module ever, > which is really not intuitive. >=20 > Include-stmt only affects definition resolution within the module. > To the client, submodules are semantically invisible. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Feb 21 06:09:10 2013 Return-Path: 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 50C5D21F8C48 for ; Thu, 21 Feb 2013 06:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 0QryeA75epqt for ; Thu, 21 Feb 2013 06:09:09 -0800 (PST) Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A5ED921F8BE4 for ; Thu, 21 Feb 2013 06:09:09 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so11490274ieb.29 for ; Thu, 21 Feb 2013 06:09:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2qaJC7l0EXRj5J7Kq07aGjAQgNLt9bW+LfIsXVyHMHY=; b=eTq3oIAlvm7D46qZKvYeFUz5im89XZ8+l4vIDZxOQX3/VJBuu7rJOB6AMmvr9Jq7nj lA4H/ADjpUrXIdIpgBK3KP+Qz5zpGDah6Jg4HhVvxrCXCG08ISwUQGuzwI9YN5UItdTe hu6M5wFijFbpyyyePkTdvfPAYp8wKnV2WYOQLs0Lboq4HPB6H+xg8ieOCBTmzGigKTa7 Trrq+RVoq0AcbiKHQHCVIxmGmUzv0My1elx16EAzDg8JJxlJMSxAAesSjAUZRj5w/vdV MvWoDmvSxAz/gr8e8NeKrMszA+iH81mTYYDZ/XLkFuZRTMGHhy0Uo6U0TXVFxHzqbA2l 6s+A== MIME-Version: 1.0 X-Received: by 10.50.183.167 with SMTP id en7mr13126914igc.58.1361455747380; Thu, 21 Feb 2013 06:09:07 -0800 (PST) Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 06:09:07 -0800 (PST) In-Reply-To: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> Date: Thu, 21 Feb 2013 06:09:07 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae9340ca333357204d63c9e5d X-Gm-Message-State: ALoCoQkSftppPGZFgRljd2KFhkq8CCofZFSo2TJpu5hCo/4aDT6eFQc8POHW+vTeI1mRb7Vgz0as Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:09:10 -0000 --14dae9340ca333357204d63c9e5d Content-Type: text/plain; charset=UTF-8 On Thu, Feb 21, 2013 at 5:53 AM, Ladislav Lhotka wrote: > > On Feb 21, 2013, at 2:28 PM, Andy Bierman wrote: > > > > Sub-modules are not that intuitive. > > They appear to create a hierarchy but that is not true. > > If mod-A includes submod-B includes submod-C and C defines top > > level definitions (including augment) then a client that imports > > mod-A can access the definitions from submod-C. > > Even if mod-A doesn't include submod-C? This could lead to nasty > ambiguities, for example if both mod-A and submod-C define a top-level > grouping with the same name. From the viewpoint of mod-A it is OK because > mod-A doesn't see the C's definition, but an importing module would see > both. > > The YANG compiler has to detect this name conflict. Breaking up a module into sub-modules does not change the rule that sibling identifiers cannot have the same extended-name. Example: module A { ... prefix a; include ipv4; include ipv6; container ipv4 { uses ipv4-group; } container ipv6 { uses ipv6-group; } } submodule ipv4 { belongs-to A { prefix a; } include ip; grouping ipv4-group { uses ip-group; .... } } submodule ipv6 { belongs-to A { prefix a; } include ip; grouping ipv6-group { uses ip-group; .... } } submodule ip { belongs-to A { prefix a; } grouping ip-group { .... } } Lada > > Andy > > > > The hierarchy is only for using definitions. > > mod-A cannot directly reference definitions from submod-C without > including it. > > Submodules cannot reference any definitions from the main module ever, > > which is really not intuitive. > > > > Include-stmt only affects definition resolution within the module. > > To the client, submodules are semantically invisible. > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --14dae9340ca333357204d63c9e5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 21, 2013 at 5:53 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:
>
> Sub-modules are not that intuitive.
> They appear to create a hierarchy but that is not true.
> If mod-A includes submod-B includes submod-C and C defines top
> level definitions (including augment) then a client that imports
> mod-A can access the definitions from submod-C.

Even if mod-A doesn't include submod-C? This could lead to nasty ambigu= ities, for example if both mod-A and submod-C define a top-level grouping w= ith the same name. From the viewpoint of mod-A it is OK because mod-A doesn= 't see the C's definition, but an importing module would see both.<= br>

The YANG compiler has to detect this n= ame conflict.
Breaking up a module into sub-modules does not chan= ge the rule
that sibling identifiers cannot have the same extende= d-name.

Example:

module A {
= =C2=A0 =C2=A0...
=C2=A0 =C2=A0prefix a;
=C2=A0 =C2=A0in= clude ipv4;
=C2=A0 =C2=A0include ipv6;

= =C2=A0 container ipv4 {
=C2=A0 =C2=A0 =C2=A0uses ipv4-group;
=C2=A0 }
=C2=A0 container ipv6 {
=C2=A0 =C2=A0 =C2= =A0uses ipv6-group;
=C2=A0 }
}=C2=A0

submodule ipv4 {
=C2=A0 =C2=A0belongs-to A { prefix a; }
=C2=A0 =C2=A0include ip;

=C2=A0 =C2=A0grouping ipv4-group {
=C2=A0 =C2=A0 =C2=A0 uses= ip-group;
=C2=A0 =C2=A0 =C2=A0 ....
=C2=A0 =C2=A0 }
}

submodule ipv6 {
=C2=A0 = =C2=A0belongs-to A { prefix a; }
=C2=A0 =C2=A0include ip;

=C2=A0 =C2=A0grouping ipv6-group {
=C2=A0 =C2= =A0 =C2=A0 uses ip-group;
=C2=A0 =C2=A0 =C2=A0 ....
=C2= =A0 =C2=A0 }
}

submodule ip {=
=C2=A0 =C2=A0belongs-to A { prefix a; }
=C2=A0 =C2=A0grouping ip-group {
=C2=A0 =C2=A0 =C2=A0 ....
=C2=A0 =C2=A0 }
}


Lada


Andy
=C2=A0
>
> The hierarchy is only for using definitions.
> mod-A cannot directly reference definitions from submod-C without incl= uding it.
> Submodules cannot reference any definitions from the main module ever,=
> which is really not intuitive.
>
> Include-stmt only affects definition resolution within the module.
> To the client, submodules are semantically invisible.

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





--14dae9340ca333357204d63c9e5d-- From lhotka@nic.cz Thu Feb 21 06:32:32 2013 Return-Path: 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 C8D1D21F8BE0 for ; Thu, 21 Feb 2013 06:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 40gfdHnjnElm for ; Thu, 21 Feb 2013 06:32:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E231721F893E for ; Thu, 21 Feb 2013 06:32:31 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2786F13F64C; Thu, 21 Feb 2013 15:32:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361457151; bh=v9vCXCa0m04VOOKzm1Bom1l6CZz73IDtS8vE3k0YHuU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pfcxG35fSdkJho5XkSxkf7WGzRS1Ho+0ulJYmekWfyFzmF6MnNIJwnrLQy3UfJabs 7vcOzeNNZNwgrSkAHUrtsQQxFCIMJAwzAZB3fdlQ8VXBYTfNpNyWir7lr1e3jAhksP X2NH27eC6kTBz222ei6jnl3CbhHT9AnIyV2JKGdk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 21 Feb 2013 15:32:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:32:32 -0000 On Feb 21, 2013, at 3:09 PM, Andy Bierman wrote: >=20 >=20 > On Thu, Feb 21, 2013 at 5:53 AM, Ladislav Lhotka = wrote: >=20 > On Feb 21, 2013, at 2:28 PM, Andy Bierman wrote: > > > > Sub-modules are not that intuitive. > > They appear to create a hierarchy but that is not true. > > If mod-A includes submod-B includes submod-C and C defines top > > level definitions (including augment) then a client that imports > > mod-A can access the definitions from submod-C. >=20 > Even if mod-A doesn't include submod-C? This could lead to nasty = ambiguities, for example if both mod-A and submod-C define a top-level = grouping with the same name. =46rom the viewpoint of mod-A it is OK = because mod-A doesn't see the C's definition, but an importing module = would see both. >=20 >=20 > The YANG compiler has to detect this name conflict. > Breaking up a module into sub-modules does not change the rule > that sibling identifiers cannot have the same extended-name. Hmm, so does it matter at all whether mod-A includes submod-C or not? I = would say top-level defs from submod-C are not siblings of top-level = defs in mod-A *unless* mod-A includes submod-C. I'd like to hear Martin's opinion, but he is most likely skiing or = something. Given how he implemented the parser in pyang, I guess he will = say that the main module must include all submodules belonging to it. Lada=20 >=20 > Example: >=20 > module A { > ... > prefix a; > include ipv4; > include ipv6; >=20 > container ipv4 { > uses ipv4-group; > } > container ipv6 { > uses ipv6-group; > } > }=20 >=20 > submodule ipv4 { > belongs-to A { prefix a; } > include ip; >=20 > grouping ipv4-group { > uses ip-group; > .... > } > } >=20 > submodule ipv6 { > belongs-to A { prefix a; } > include ip; >=20 > grouping ipv6-group { > uses ip-group; > .... > } > } >=20 > submodule ip { > belongs-to A { prefix a; } > grouping ip-group { > .... > } > } >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > The hierarchy is only for using definitions. > > mod-A cannot directly reference definitions from submod-C without = including it. > > Submodules cannot reference any definitions from the main module = ever, > > which is really not intuitive. > > > > Include-stmt only affects definition resolution within the module. > > To the client, submodules are semantically invisible. >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Feb 21 06:56:20 2013 Return-Path: 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 7138C21F8E05 for ; Thu, 21 Feb 2013 06:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 RqYMyI1TNIsA for ; Thu, 21 Feb 2013 06:56:18 -0800 (PST) Received: from mail-ia0-x235.google.com (ia-in-x0235.1e100.net [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDF921F8E45 for ; Thu, 21 Feb 2013 06:56:18 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id e16so7877195iaa.26 for ; Thu, 21 Feb 2013 06:56:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=OuMN3/YstZTmD3ge3MM2IXj1sa9DTNyX41WiODSVqJw=; b=gh95+jA8Q9T8ucHaodPNeXbKkfyARu8IpjaXEqHKkOKZk4m0Wt/sNTKMl49Nisbl1l wyswo3pN9NSOMCdR/FYAqDdsiPgx9tts2vrItFUQVhp8Vrlaxs//Ckgv0JZCyWHxQ7N+ 6mXeLIYWcVWF5wwk+OLAKWH5dY7SQW5BGZPeGzStD7SyLxQ+cAo4bLI/ib+OewO1yakw u28dR4+aLg/Bm0ECGGevPDNBkeC0iml+CYL8k1plNdPr9FIFg0+AL1trP+WMuJQ3EDnS 3RNkGnLSVqdOOcUfwO0zAL1FBGZD38Oc0VSm4Ls9ZRRAPrxqPTB+HA1MPNzbMocWx3yh 8f/Q== MIME-Version: 1.0 X-Received: by 10.50.196.132 with SMTP id im4mr12465081igc.58.1361458577483; Thu, 21 Feb 2013 06:56:17 -0800 (PST) Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 06:56:17 -0800 (PST) In-Reply-To: <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> References: <70B464D6-81AA-455D-8954-41564676BF9B@nic.cz> <5125E228.1030007@mg-soft.com> <14D8FB18-C017-49A6-BE6B-D3AD1DDBE88B@nic.cz> <0ac4e8dbfe0d656045671e6c37ef78f1@imap.plus.net> <1E155144-659B-4228-BDAF-2E26D8D96FED@nic.cz> <5125F82F.6070100@mg-soft.com> <7d421f63b3f7ab1edb6d2561a194264a@imap.plus.net> <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> Date: Thu, 21 Feb 2013 06:56:17 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae9340b63e325f404d63d46b6 X-Gm-Message-State: ALoCoQlZECXtCaf5YS51vbgcA+6GV/gzMukPLq5Y9VmtrUHBL9oLL17GOYlBqvPYspKaQect7AOZ Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:56:21 -0000 --14dae9340b63e325f404d63d46b6 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 21, 2013 at 6:32 AM, Ladislav Lhotka wrote: > > On Feb 21, 2013, at 3:09 PM, Andy Bierman wrote: > > > > > > > On Thu, Feb 21, 2013 at 5:53 AM, Ladislav Lhotka wrote: > > > > On Feb 21, 2013, at 2:28 PM, Andy Bierman wrote: > > > > > > Sub-modules are not that intuitive. > > > They appear to create a hierarchy but that is not true. > > > If mod-A includes submod-B includes submod-C and C defines top > > > level definitions (including augment) then a client that imports > > > mod-A can access the definitions from submod-C. > > > > Even if mod-A doesn't include submod-C? This could lead to nasty > ambiguities, for example if both mod-A and submod-C define a top-level > grouping with the same name. From the viewpoint of mod-A it is OK because > mod-A doesn't see the C's definition, but an importing module would see > both. > > > > > > The YANG compiler has to detect this name conflict. > > Breaking up a module into sub-modules does not change the rule > > that sibling identifiers cannot have the same extended-name. > > Hmm, so does it matter at all whether mod-A includes submod-C or not? I > would say top-level defs from submod-C are not siblings of top-level defs > in mod-A *unless* mod-A includes submod-C. > > I'd like to hear Martin's opinion, but he is most likely skiing or > something. Given how he implemented the parser in pyang, I guess he will > say that the main module must include all submodules belonging to it. > > >From my understanding of groupings, nothing in the above example breaks any rules in RFC 6020. I'd like to hear from Phil, because he was the one who has the most experience with submodules (IMO). There is supposed to be the same layered information hiding that groupings provide if they are in modules or submodules. The YANG compiler only needs to use submod-A definitions within mod-A if there any statements in modA itself that reference those definitions. It really doesn't matter if it's groupings, identities, data nodes, typedefs, etc. In my interpretation, the belongs-to-stmt says that definitions in this submodule are added to the namespace for that module. The include-stmt does not affect the definitions that are exported, it affected the definitions that are imported. > Lada > > Andy > > > > Example: > > > > module A { > > ... > > prefix a; > > include ipv4; > > include ipv6; > > > > container ipv4 { > > uses ipv4-group; > > } > > container ipv6 { > > uses ipv6-group; > > } > > } > > > > submodule ipv4 { > > belongs-to A { prefix a; } > > include ip; > > > > grouping ipv4-group { > > uses ip-group; > > .... > > } > > } > > > > submodule ipv6 { > > belongs-to A { prefix a; } > > include ip; > > > > grouping ipv6-group { > > uses ip-group; > > .... > > } > > } > > > > submodule ip { > > belongs-to A { prefix a; } > > grouping ip-group { > > .... > > } > > } > > > > > > Lada > > > > > > Andy > > > > > > > > The hierarchy is only for using definitions. > > > mod-A cannot directly reference definitions from submod-C without > including it. > > > Submodules cannot reference any definitions from the main module ever, > > > which is really not intuitive. > > > > > > Include-stmt only affects definition resolution within the module. > > > To the client, submodules are semantically invisible. > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --14dae9340b63e325f404d63d46b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 21, 2013 at 6:32 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

>
>
> On Thu, Feb 21, 2013 at 5:53 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On Feb 21, 2013, at 2:28 PM, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Sub-modules are not that intuitive.
> > They appear to create a hierarchy but that is not true.
> > If mod-A includes submod-B includes submod-C and C defines top > > level definitions (including augment) then a client that imports<= br> > > mod-A can access the definitions from submod-C.
>
> Even if mod-A doesn't include submod-C? This could lead to nasty a= mbiguities, for example if both mod-A and submod-C define a top-level group= ing with the same name. From the viewpoint of mod-A it is OK because mod-A = doesn't see the C's definition, but an importing module would see b= oth.
>
>
> The YANG compiler has to detect this name conflict.
> Breaking up a module into sub-modules does not change the rule
> that sibling identifiers cannot have the same extended-name.

Hmm, so does it matter at all whether mod-A includes submod-C or not? I wou= ld say top-level defs from submod-C are not siblings of top-level defs in m= od-A *unless* mod-A includes submod-C.

I'd like to hear Martin's opinion, but he is most likely skiing or = something. Given how he implemented the parser in pyang, I guess he will sa= y that the main module must include all submodules belonging to it.


From my understanding of groupings, no= thing in the above example breaks
any rules in RFC 6020.

I'd like to hear from Phil, because he was the one who= has the most experience
with submodules (IMO). =C2=A0There is supposed to be the same layered = information
hiding that groupings provide if they are in modules = or submodules.

The YANG compiler only needs to use= submod-A definitions within mod-A
if there any statements in modA itself that reference those definition= s.
It really doesn't matter if it's groupings, identities= , data nodes, typedefs, etc.

In my interpretation,= the belongs-to-stmt says that definitions in this
submodule are added to the namespace for that module.

The include-stmt does not affect the definitions that are exported= ,
it affected the definitions that are imported.


=C2=A0
Lada


Andy
=C2=A0
>
> Example:
>
> module A {
> =C2=A0 =C2=A0...
> =C2=A0 =C2=A0prefix a;
> =C2=A0 =C2=A0include ipv4;
> =C2=A0 =C2=A0include ipv6;
>
> =C2=A0 container ipv4 {
> =C2=A0 =C2=A0 =C2=A0uses ipv4-group;
> =C2=A0 }
> =C2=A0 container ipv6 {
> =C2=A0 =C2=A0 =C2=A0uses ipv6-group;
> =C2=A0 }
> }
>
> submodule ipv4 {
> =C2=A0 =C2=A0belongs-to A { prefix a; }
> =C2=A0 =C2=A0include ip;
>
> =C2=A0 =C2=A0grouping ipv4-group {
> =C2=A0 =C2=A0 =C2=A0 uses ip-group;
> =C2=A0 =C2=A0 =C2=A0 ....
> =C2=A0 =C2=A0 }
> }
>
> submodule ipv6 {
> =C2=A0 =C2=A0belongs-to A { prefix a; }
> =C2=A0 =C2=A0include ip;
>
> =C2=A0 =C2=A0grouping ipv6-group {
> =C2=A0 =C2=A0 =C2=A0 uses ip-group;
> =C2=A0 =C2=A0 =C2=A0 ....
> =C2=A0 =C2=A0 }
> }
>
> submodule ip {
> =C2=A0 =C2=A0belongs-to A { prefix a; }
> =C2=A0 =C2=A0grouping ip-group {
> =C2=A0 =C2=A0 =C2=A0 ....
> =C2=A0 =C2=A0 }
> }
>
>
> Lada
>
>
> Andy
>
> >
> > The hierarchy is only for using definitions.
> > mod-A cannot directly reference definitions from submod-C without= including it.
> > Submodules cannot reference any definitions from the main module = ever,
> > which is really not intuitive.
> >
> > Include-stmt only affects definition resolution within the module= .
> > To the client, submodules are semantically invisible.
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--14dae9340b63e325f404d63d46b6-- From mbj@tail-f.com Thu Feb 21 06:56:27 2013 Return-Path: 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 5557E21F8E45 for ; Thu, 21 Feb 2013 06:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 D5O0hmTE7pEv for ; Thu, 21 Feb 2013 06:56:26 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6A00821F8E55 for ; Thu, 21 Feb 2013 06:56:26 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 954F21200045; Thu, 21 Feb 2013 15:56:24 +0100 (CET) Date: Thu, 21 Feb 2013 15:56:24 +0100 (CET) Message-Id: <20130221.155624.698928986915671857.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> References: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:56:27 -0000 Hi, Ladislav Lhotka wrote: > I'd like to hear Martin's opinion, but he is most likely skiing or > something. Not yet, but next week! > Given how he implemented the parser in pyang, I guess he > will say that the main module must include all submodules belonging to > it. Yes. So the original question was: Module M includes submodule A, and A in turn includes submodule B, but M does NOT include B. I think this is not supposed to be legal (and so does pyang) This is correct, it is not legal. A module must include all its submodules. /martin From andy@yumaworks.com Thu Feb 21 07:00:44 2013 Return-Path: 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 92FFA21F880F for ; Thu, 21 Feb 2013 07:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 03vsBKhCaB29 for ; Thu, 21 Feb 2013 07:00:44 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0921F8E56 for ; Thu, 21 Feb 2013 07:00:43 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so11199805ieb.25 for ; Thu, 21 Feb 2013 07:00:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=yL8vfhkWWEwCh0Y8NeUbxESaz4SzOxTGymZA83vDrkE=; b=CHkS12yyglRhEZfsUoCoCQacBEYC3X8AqGmSP5uUZ5D3XttKSktaOF1SqJym/XGQ6D Rq36B71w1L0OaoeRo77l1zBS2ZVRwJv6PRdbyxiRMeopGQYLKJRgV6EZ8v6Ri06QnKJ1 6b2lVZiwbfAAKgrhetFXl7+FaInpsJ63+wNGcDJabHqgJpmcGJw/TkNOfCaBfJFU2vUS LfuDHHNvt/zoWRm1Z1NOx3VjthupNEBmE1CvtDtjkofQJgeY/bTDGKkv3lJQDlLLaVNP Duv9Lx9JtJhZ4eL8nQTf8pu6NORmalMrNfNyWTfKOjaucIPOaCT4n0QVRHXvV4JOwTZG 6BeA== MIME-Version: 1.0 X-Received: by 10.50.12.133 with SMTP id y5mr13337130igb.108.1361458843149; Thu, 21 Feb 2013 07:00:43 -0800 (PST) Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 07:00:43 -0800 (PST) In-Reply-To: <20130221.155624.698928986915671857.mbj@tail-f.com> References: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> <20130221.155624.698928986915671857.mbj@tail-f.com> Date: Thu, 21 Feb 2013 07:00:43 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae9340f1db8e73204d63d569a X-Gm-Message-State: ALoCoQkBlY6js0mMAHuxTodEEmSFntLtyWlcFcsAsgu536HEeYHK/3UeiOag2rLb9OLptNj1U+L1 Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:00:44 -0000 --14dae9340f1db8e73204d63d569a Content-Type: text/plain; charset=UTF-8 On Thu, Feb 21, 2013 at 6:56 AM, Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: > > I'd like to hear Martin's opinion, but he is most likely skiing or > > something. > > Not yet, but next week! > > > Given how he implemented the parser in pyang, I guess he > > will say that the main module must include all submodules belonging to > > it. > > Yes. So the original question was: > > Module M includes submodule A, and A in turn includes submodule B, but > M does NOT include B. > > I think this is not supposed to be legal (and so does pyang) > > This is correct, it is not legal. A module must include all its > submodules. > > Where does it say that, because that sure is not how Phil explained submodules to the design team way back when it was written. > > /martin > > > Andy --14dae9340f1db8e73204d63d569a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 21, 2013 at 6:56 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Hi,

Ladislav Lhotka <lhotka@nic.cz> = wrote:
> I'd like to hear Martin's opinion, but he is most likely skiin= g or
> something.

Not yet, but next week!

> Given how he implemented the parser in pyang, I guess he
> will say that the main module must include all submodules belonging to=
> it.

Yes. =C2=A0So the original question was:

=C2=A0 Module M includes submodule A, and A in turn includes submodule B, b= ut
=C2=A0 M does NOT include B.

=C2=A0 I think this is not supposed to be legal (and so does pyang)

This is correct, it is not legal. =C2=A0A module must include all its
submodules.


Where does it say that, because that sure is not how= Phil explained submodules
to the design team way back when it wa= s written.

=C2=A0

/martin



Andy

--14dae9340f1db8e73204d63d569a-- From lhotka@nic.cz Thu Feb 21 07:11:15 2013 Return-Path: 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 2CB6A21F8E63 for ; Thu, 21 Feb 2013 07:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 P7AOWdQM4TQ9 for ; Thu, 21 Feb 2013 07:11:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A01C421F8E64 for ; Thu, 21 Feb 2013 07:11:13 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DE0F613F64C; Thu, 21 Feb 2013 16:11:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361459472; bh=LTBdJ192UbEpjgcCSLPaxIeN6geQjXww1AHUsHh4o6g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yIcDaWcRVfyTRs6Wa7HwKI1gZQg+JoW+JMqgilYfEsO282HL9KUw1+msS6nhdTwVg pIgfhACm7Dore0Cm/m70VML2vlC8D68vJi39jEqPM9MLsHBuenqnxR6mxJN7kQWnLb FKepoBTXZM93imybOc9PS4oTJvcv4/YFUzgoFP+4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130221.155624.698928986915671857.mbj@tail-f.com> Date: Thu, 21 Feb 2013 16:11:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C62675B-72AD-40CB-B8EC-8DCDCB941BDE@nic.cz> References: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> <20130221.155624.698928986915671857.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:11:15 -0000 On Feb 21, 2013, at 3:56 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> I'd like to hear Martin's opinion, but he is most likely skiing or >> something. >=20 > Not yet, but next week! >=20 >> Given how he implemented the parser in pyang, I guess he >> will say that the main module must include all submodules belonging = to >> it. >=20 > Yes. So the original question was: >=20 > Module M includes submodule A, and A in turn includes submodule B, = but > M does NOT include B. >=20 > I think this is not supposed to be legal (and so does pyang) >=20 > This is correct, it is not legal. A module must include all its > submodules. Yup. I originally thought the problem was only in the (lack of) = specification in 6020 but apparently Andy's view of how submodules work = is different. So I am afraid a simple erratum of 6020 won't do. Lada =20 >=20 >=20 > /martin >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Feb 21 07:17:59 2013 Return-Path: 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 30EE621F8E7F for ; Thu, 21 Feb 2013 07:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 epUnL7qIz9-Z for ; Thu, 21 Feb 2013 07:17:58 -0800 (PST) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4FD21F8E7D for ; Thu, 21 Feb 2013 07:17:58 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so8416268iab.9 for ; Thu, 21 Feb 2013 07:17:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=YqvulFWTpjkjBPxF5Yr2Is9eFNbdF/7QvacG27VKtnI=; b=nofbQHyEXFPPvrqAoiirqCm71f2dQPQA2iC5W2uu/DNgKiKl06rsDaYbpyIrBG0w1r p4I55I4ytJucjQf6R5faED8yUpNQ7s8nQ4UmDZZVSLRup1il+3hp3utT9Ixzx8NcI7bp cv09pKa3h3alK4TJll78KcLMGERCWmRgnc/HgMV0TvJPlE3j6oHe2q91dHZNPUhSFz+u 98BmonGLF+9FRXuLsvhJkJEuUM2/qS18bbHYQeddyi684WMPXPWDMsCpyTXVodlaNKTU W5beG4r4jvOqKBczZZYXkQ8ojHZ/SnnPqZj2DPduoOy6EvzMjId/RNT/tz7uwlVxkzt7 hOZw== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr6593443igc.91.1361459878080; Thu, 21 Feb 2013 07:17:58 -0800 (PST) Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 07:17:57 -0800 (PST) In-Reply-To: <3C62675B-72AD-40CB-B8EC-8DCDCB941BDE@nic.cz> References: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> <20130221.155624.698928986915671857.mbj@tail-f.com> <3C62675B-72AD-40CB-B8EC-8DCDCB941BDE@nic.cz> Date: Thu, 21 Feb 2013 07:17:57 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae934034568af3604d63d9427 X-Gm-Message-State: ALoCoQmLMSyW/KElaK6B7QyqSsNWhfImYiPj9rtkq86zeTuVKJRUhKjBP+nvMZqF8koDSMfvf/HM Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:17:59 -0000 --14dae934034568af3604d63d9427 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 21, 2013 at 7:11 AM, Ladislav Lhotka wrote: > > On Feb 21, 2013, at 3:56 PM, Martin Bjorklund wrote: > > > Hi, > > > > Ladislav Lhotka wrote: > >> I'd like to hear Martin's opinion, but he is most likely skiing or > >> something. > > > > Not yet, but next week! > > > >> Given how he implemented the parser in pyang, I guess he > >> will say that the main module must include all submodules belonging to > >> it. > > > > Yes. So the original question was: > > > > Module M includes submodule A, and A in turn includes submodule B, but > > M does NOT include B. > > > > I think this is not supposed to be legal (and so does pyang) > > > > This is correct, it is not legal. A module must include all its > > submodules. > > Yup. I originally thought the problem was only in the (lack of) > specification in 6020 but apparently Andy's view of how submodules work is > different. So I am afraid a simple erratum of 6020 won't do. > > The include-stmt just affects how prefixed definitions are resolved within the current sub-module. There is only 1 module namespace and the belongs-to-stmt indicates that all top-level definitions in the sub-module are top-level definitions in the module namespace. When mod-B imports mod-A it is importing the entire mod-A namespace, not some hierarchy of sub-module namespaces. > Lada > > Andy > > > > > > /martin > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --14dae934034568af3604d63d9427 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 21, 2013 at 7:11 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
mbj@tail-f.com> wrote:

> Hi,
>
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> I'd like to hear Martin's opinion, but he is most likely s= kiing or
>> something.
>
> Not yet, but next week!
>
>> Given how he implemented the parser in pyang, I guess he
>> will say that the main module must include all submodules belongin= g to
>> it.
>
> Yes. =C2=A0So the original question was:
>
> =C2=A0Module M includes submodule A, and A in turn includes submodule = B, but
> =C2=A0M does NOT include B.
>
> =C2=A0I think this is not supposed to be legal (and so does pyang)
>
> This is correct, it is not legal. =C2=A0A module must include all its<= br> > submodules.

Yup. I originally thought the problem was only in the (lack of) specificati= on in 6020 but apparently Andy's view of how submodules work is differe= nt. So I am afraid a simple erratum of 6020 won't do.


The include-stmt just affects how pref= ixed definitions are resolved within
the current sub-module.

There is only 1 module namespace and the belongs-to-st= mt indicates
that all top-level definitions in the sub-module are top-level definit= ions
in the module namespace.

When mod-B= imports mod-A it is importing the entire mod-A namespace,
not so= me hierarchy of sub-module namespaces.

=C2=A0
Lada


Andy
=C2=A0
>
>
> /martin
>
>

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





--14dae934034568af3604d63d9427-- From jonathan@hansfords.net Thu Feb 21 07:20:00 2013 Return-Path: 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 073EB21F89A3 for ; Thu, 21 Feb 2013 07:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 31dvbAuawuMR for ; Thu, 21 Feb 2013 07:19:59 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1B11021F8CB2 for ; Thu, 21 Feb 2013 07:19:57 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 33Kv1l0074CLSd8013KwuD; Thu, 21 Feb 2013 15:19:57 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=48vgC7mUAAAA:8 a=sDHQ2k_XdpUY8RguDREA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=II6h17yG-4WsshDpo4YA:9 a=_W_S_7VecoQA:10 a=-vU6A1KKZpTMCiPc:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 21 Feb 2013 15:19:55 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_21430a2cc0b25d4b83b56dbe9a35cc2b" Date: Thu, 21 Feb 2013 15:19:55 +0000 From: Jonathan Hansford To: In-Reply-To: <20130221.155624.698928986915671857.mbj@tail-f.com> References: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz> <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> <20130221.155624.698928986915671857.mbj@tail-f.com> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:20:00 -0000 --=_21430a2cc0b25d4b83b56dbe9a35cc2b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 21.02.2013 14:56, Martin Bjorklund wrote: > Hi, > > Ladislav Lhotka wrote: > >> I'd like to hear Martin's opinion, but he is most likely skiing or something. > > Not yet, but next week! > >> Given how he implemented the parser in pyang, I guess he will say that the main module must include all submodules belonging to it. > > Yes. So the original question was: > > Module M includes submodule A, and A in turn includes submodule B, but > M does NOT include B. > > I think this is not supposed to be legal (and so does pyang) > > This is correct, it is not legal. A module must include all its > submodules. If it is not legal, why does 5.1 just state "For a module to reference definitions in one of its submodules, the module MUST include the submodule" rather than the explicit "A module MUST include all its submodules"? Jonathan /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --=_21430a2cc0b25d4b83b56dbe9a35cc2b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 21.02.2013 14:56, Martin Bjorklund wrote:

Hi,

Ladislav Lhotka <lhotka@nic.cz> =
wrote:
I'd like to hear Martin's opinion, bu= t he is most likely skiing or something.
Not yet, but next week!
Given how he implemented the parser i= n pyang, I guess he will say that the main module must include all submodul= es belonging to it.
Yes.  So the original question was:

  Module M includes submodule A, and A in turn includes submodule B, but
  M does NOT include B.

  I think this is not supposed to be legal (and so does pyang)

This is correct, it is not legal.  A module must include all its
submodules.
 
If it is not legal, why does 5.1 just state "For a module to reference=
 definitions in one of its submodules, the module MUST include the submodul=
e" rather than the explicit "A module MUST include all its submodules"?

 


Jonathan



/martin


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf=
=2Eorg/mailman/listinfo/netmod 


 



--=_21430a2cc0b25d4b83b56dbe9a35cc2b--


From phil@juniper.net  Thu Feb 21 07:51:02 2013
Return-Path: 
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 2F29121F8EA4 for ; Thu, 21 Feb 2013 07:51:02 -0800 (PST)
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 zTXVjCILasO0 for ; Thu, 21 Feb 2013 07:51:01 -0800 (PST)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8267E21F8E9D for ; Thu, 21 Feb 2013 07:50:58 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUSZCYt9Y5bzE5R5BBA2y/8SrcflkEp+p@postini.com; Thu, 21 Feb 2013 07:51:01 PST
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.3.213.0; Thu, 21 Feb 2013 07:32:28 -0800
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 r1LFWQ380894; Thu, 21 Feb 2013 07:32:27 -0800 (PST)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r1LFVUfX089492; Thu, 21 Feb 2013 10:31:50 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201302211531.r1LFVUfX089492@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Thu, 21 Feb 2013 10:31:30 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 15:51:02 -0000

Andy Bierman writes:
>I'd like to hear from Phil....

My take is that there's nothing wrong with SM-A including SM-B which
isn't explicitly included by the module.  The "belongs-to" should
suffice to tell the compiler that this is acceptable.  Forcing the
module to grok the division of submodules is not necessary or
convenient.

Thanks,
 Phil

From lhotka@nic.cz  Thu Feb 21 07:52:25 2013
Return-Path: 
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 E24D121F8EA0 for ; Thu, 21 Feb 2013 07:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.353
X-Spam-Level: 
X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6]
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 KkRw1ZSy2Q7I for ; Thu, 21 Feb 2013 07:52:25 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 166B821F8E9C for ; Thu, 21 Feb 2013 07:52:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 737D4540472 for ; Thu, 21 Feb 2013 16:52:18 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhFH66juv-IL for ; Thu, 21 Feb 2013 16:52:06 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E7C73540042 for ; Thu, 21 Feb 2013 16:52:00 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: 
References: <499ABD76-522F-46A3-97F2-1079449D48DA@nic.cz>  <0168542D-CCFF-401F-AC6C-1D9E4B0092F2@nic.cz> <20130221.155624.698928986915671857.mbj@tail-f.com> <3C62675B-72AD-40CB-B8EC-8DCDCB941BDE@nic.cz> 
User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: netmod@ietf.org
Date: Thu, 21 Feb 2013 16:52:00 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 15:52:26 -0000

Andy Bierman  writes:

> On Thu, Feb 21, 2013 at 7:11 AM, Ladislav Lhotka  wrote:
>
>>
>> On Feb 21, 2013, at 3:56 PM, Martin Bjorklund  wrote:
>>
>> > Hi,
>> >
>> > Ladislav Lhotka  wrote:
>> >> I'd like to hear Martin's opinion, but he is most likely skiing or
>> >> something.
>> >
>> > Not yet, but next week!
>> >
>> >> Given how he implemented the parser in pyang, I guess he
>> >> will say that the main module must include all submodules belonging to
>> >> it.
>> >
>> > Yes.  So the original question was:
>> >
>> >  Module M includes submodule A, and A in turn includes submodule B, but
>> >  M does NOT include B.
>> >
>> >  I think this is not supposed to be legal (and so does pyang)
>> >
>> > This is correct, it is not legal.  A module must include all its
>> > submodules.
>>
>> Yup. I originally thought the problem was only in the (lack of)
>> specification in 6020 but apparently Andy's view of how submodules work is
>> different. So I am afraid a simple erratum of 6020 won't do.
>>
>>
> The include-stmt just affects how prefixed definitions are resolved within
> the current sub-module.
>
> There is only 1 module namespace and the belongs-to-stmt indicates
> that all top-level definitions in the sub-module are top-level definitions
> in the module namespace.

This is not what 6020 says.

7.2.2.  The belongs-to Statement

   The "belongs-to" statement specifies the module to which the
   submodule belongs.  The argument is an identifier that is the name of
   the module.

   A submodule MUST only be included by the module to which it belongs,
   or by another submodule that belongs to that module.

   ...

It is the 'include' statement that pulls in the submodule contents. Sec. 7.1.6:

   When a module includes a submodule, it incorporates the contents of
   the submodule into the node hierarchy of the module.  When a
   submodule includes another submodule, the target submodule's
   definitions are made available to the current submodule.

IMO, the interpretation that is closest to the current text is:

The main module needn't include all submodules that are declared as belonging to it. However, only the contents of explicitly included submodules are available in the main module and, by extension, in any modules that import it.

>
> When mod-B imports mod-A it is importing the entire mod-A namespace,
> not some hierarchy of sub-module namespaces.

It imports the contents of the main module, which may be affected by include statements that are present in the main module.

Lada

>
>
>
>> Lada
>>
>>
> Andy
>
>
>> >
>> >
>> > /martin
>> >
>> >
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

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

From lhotka@nic.cz  Thu Feb 21 07:57:34 2013
Return-Path: 
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 4AC2021F8EA1 for ; Thu, 21 Feb 2013 07:57:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level: 
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.205,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 eG1461HSta5E for ; Thu, 21 Feb 2013 07:57:33 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E40A821F8E6B for ; Thu, 21 Feb 2013 07:57:31 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 25BBA13F64C; Thu, 21 Feb 2013 16:57:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361462251; bh=2RzEEfiK6CPN3gTOHGej2zvDfsZViQjLHwIPQ4DPG7s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L2POyRid9Amdsk8P7mtP2Wy+xUulyZnA3ijTEc9p8nLAXw3rhdOjGVbL5RS0ulO1a fNxww0cWC8kNrpcgnfCFgXtwZNFnPAjRARSiRYvb+7zYq3kfg+KxeJWENeCz/S3oLy 5gi5IjbUdaNyLY5JwAggTksszQ8qDaBu3kbQGh6c=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <201302211531.r1LFVUfX089492@idle.juniper.net>
Date: Thu, 21 Feb 2013 16:57:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201302211531.r1LFVUfX089492@idle.juniper.net>
To: Phil Shafer 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 15:57:34 -0000

On Feb 21, 2013, at 4:31 PM, Phil Shafer  wrote:

> Andy Bierman writes:
>> I'd like to hear from Phil....
>=20
> My take is that there's nothing wrong with SM-A including SM-B which
> isn't explicitly included by the module.  The "belongs-to" should
> suffice to tell the compiler that this is acceptable.  Forcing the
> module to grok the division of submodules is not necessary or
> convenient.

But what about the other aspect: If the main module doesn't include =
SM-B, is the SM-B content part of the module or not?

Lada
=20
>=20
> Thanks,
> Phil

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





From andy@yumaworks.com  Thu Feb 21 08:58:40 2013
Return-Path: 
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 1F5FA21F8936 for ; Thu, 21 Feb 2013 08:58:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level: 
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-0.043,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
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 H9KU0LnEXFBH for ; Thu, 21 Feb 2013 08:58:39 -0800 (PST)
Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7B20821F8916 for ; Thu, 21 Feb 2013 08:58:37 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id c11so11602734ieb.1 for ; Thu, 21 Feb 2013 08:58:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=j5Vo1A8n7d5eX3cM0Wkr53GEStmW+TlrE7pCohdD8s8=; b=QWejhKtiPsYJp16MdpcBdw5pZAhU9NkvTGIcqPjtx87w4BZaqhX1NlgkyoiJGvsHfu kCK+MbZjynRUdr43QLGZMewrSTmo3jcZ8iVp6jY0IHMDfxeLu67INqQ9PMFTUMZZfPmA SDrdSsyDRphzNmENoYayetf3/I8hS0P4nPBo/G8lz5n8IPw4VyNapfPL/jEdlJt8KAYD HhFJFWm5jQpebeQr/8XvVe6wpRfNB9P8i9gDTPgewNzH7fMJl1vROLYXB0hWuOcebFR1 /qdUYoVbWMGqINW6CpOv5zMlD5v5X6iEOI4KxtaHbxW9gdHWHOEw6ltlaMYO8xuIMwGR gJpg==
MIME-Version: 1.0
X-Received: by 10.50.208.40 with SMTP id mb8mr6758465igc.91.1361465916854; Thu, 21 Feb 2013 08:58:36 -0800 (PST)
Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 08:58:36 -0800 (PST)
In-Reply-To: 
References: <201302211531.r1LFVUfX089492@idle.juniper.net> 
Date: Thu, 21 Feb 2013 08:58:36 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=14dae934034559138c04d63efc15
X-Gm-Message-State: ALoCoQn1osjUt9+eM4kUmNj7CtCLNPq69o+YC0A1Qu9OdDOR1V0zSnuOzEk3q9PM8wRUGgFevEYH
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 16:58:40 -0000

--14dae934034559138c04d63efc15
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 21, 2013 at 7:57 AM, Ladislav Lhotka  wrote:

>
> On Feb 21, 2013, at 4:31 PM, Phil Shafer  wrote:
>
> > Andy Bierman writes:
> >> I'd like to hear from Phil....
> >
> > My take is that there's nothing wrong with SM-A including SM-B which
> > isn't explicitly included by the module.  The "belongs-to" should
> > suffice to tell the compiler that this is acceptable.  Forcing the
> > module to grok the division of submodules is not necessary or
> > convenient.
>
> But what about the other aspect: If the main module doesn't include SM-B,
> is the SM-B content part of the module or not?
>
>

I agree with Phil and also the text that Jonathan pointed out.
Here is some more:

7.2.2.  The belongs-to Statement

   The "belongs-to" statement specifies the module to which the
   submodule belongs.  The argument is an identifier that is the name of
   the module.

   A submodule MUST only be included by the module to which it belongs,
   or by another submodule that belongs to that module.

   The mandatory "prefix" substatement assigns a prefix for the module
   to which the submodule belongs.  All definitions in the local
   submodule and any included submodules can be accessed by using the
   prefix.


 - para 1 identifies how the module namespace is derived.
 - para 2 says that a sub-module can only be part of 1 module namespace.
 - para 3 seems to be ambiguous because you think it refers to external
   modules that reference definitions from the module with submods.
   Looks to me like the last sentence refers only to referencing definitions
   within the current module.

The intent of sub-modules was that they are implementation mechanisms
used by the server developer -- like code.  If mod-A includes submod-B
and the developers decide submod-B is getting too big and would
like to partition it, this should not affect the upstream sub-modules or
main module.



> Lada
>
>
Andy



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

--14dae934034559138c04d63efc15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Feb 21, 2013 at 7:57 AM, Ladisla=
v Lhotka <lhotka@nic.cz> wrote:
phil@juniper.net> wrote:



> Andy Bierman writes:

>> I'd like to hear from Phil....

>

> My take is that there's nothing wrong with SM-A including SM-B whi=
ch

> isn't explicitly included by the module. =C2=A0The "belongs-t=
o" should

> suffice to tell the compiler that this is acceptable. =C2=A0Forcing th=
e

> module to grok the division of submodules is not necessary or

> convenient.



But what about the other aspect: If the main module doesn't include SM-=
B, is the SM-B content part of the module or not?




I agree with Phil and a=
lso the text that Jonathan pointed out.
Here is some more:
<=
div>
7.2.=
2.  The belongs-to Statement

   The "belongs-to" statement specifies the module to which the
   submodule belongs.  The argument is an identifier that is the name of
   the module.

   A submodule MUST only be included by the module to which it belongs,
   or by another submodule that belongs to that module.

   The mandatory "prefix" substatement assigns a prefix for the m=
odule
   to which the submodule belongs.  All definitions in the local
   submodule and any included submodules can be accessed by using the
   prefix.


=C2=A0- para 1 identifies how the module namespac=
e is derived.
=C2=A0- para 2 says that a sub-module can only be p=
art of 1 module namespace.
=C2=A0- para 3 seems to be ambiguous b=
ecause you think it refers to external


=C2=A0 =C2=A0modules that reference definitions from the module with s=
ubmods.
=C2=A0 =C2=A0Looks to me like the last sentence refers on=
ly to referencing definitions
=C2=A0 =C2=A0within the current mod=
ule.


The intent of sub-modules was that they are implementation mechanisms
=

used by the server developer -- like code. =C2=A0If mod-A includes sub=
mod-B
and the developers decide submod-B is getting too big and w=
ould


like to partition it, this should not affect the upstream sub-modules =
or main module.

=C2=A0


Lada



Andy

=C2=A0

>

> Thanks,

> Phil



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--14dae934034559138c04d63efc15--

From mbj@tail-f.com  Thu Feb 21 09:43:55 2013
Return-Path: 
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 0AB9C21F8EEC for ; Thu, 21 Feb 2013 09:43:55 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyhDb6HxUkUB for ; Thu, 21 Feb 2013 09:43:54 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 722B321F8EB7 for ; Thu, 21 Feb 2013 09:43:54 -0800 (PST)
Received: from localhost (unknown [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id 5BFFA1200045; Thu, 21 Feb 2013 18:43:53 +0100 (CET)
Date: Thu, 21 Feb 2013 18:43:52 +0100 (CET)
Message-Id: <20130221.184352.325005457.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <201302211531.r1LFVUfX089492@idle.juniper.net>  
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 17:43:55 -0000

Hi,

So I checked the archives and found out that also I can change my
mind: http://www.ietf.org/mail-archive/web/netmod/current/msg01599.html

But I can't find an definitive answer anywhere.  My guess is that we
found the problems that Lada points out below, and changed this so
that the module must list all its submodules.

Note this text from 7.1.6

   When a module includes a submodule, it incorporates the contents of
   the submodule into the node hierarchy of the module.  When a
   submodule includes another submodule, the target submodule's
   definitions are made available to the current submodule.

So when a submodule includes another submodule it works in the same
way as when a module imports another modules - the submodule can refer
to the definitions in the included submodule, but its contents are not
"copied".

More below:

Andy Bierman  wrote:
> On Thu, Feb 21, 2013 at 7:57 AM, Ladislav Lhotka  wrote:
> 
> >
> > On Feb 21, 2013, at 4:31 PM, Phil Shafer  wrote:
> >
> > > Andy Bierman writes:
> > >> I'd like to hear from Phil....
> > >
> > > My take is that there's nothing wrong with SM-A including SM-B which
> > > isn't explicitly included by the module.  The "belongs-to" should
> > > suffice to tell the compiler that this is acceptable.  Forcing the
> > > module to grok the division of submodules is not necessary or
> > > convenient.
> >
> > But what about the other aspect: If the main module doesn't include SM-B,
> > is the SM-B content part of the module or not?

Exactly, this is a very relevant question.

I don't think the current text supports the use case that Phil
mentioned, since when SM-A includes SM-B, SM-B's definitions are NOT
incorporated into SM-A.

But then if the above would be allowed anyway, what would this mean:

  module M {
    ....
    include SM-A;
  }

  submodule SM-A {
    ...
    include SM-B;

    augment /b {
      leaf a { ... }
    }
  }

  submodule SM-B {
    ...
    container b;
  }

M doesn't include SM-B, so container /b isn't exported. Whatabout
/b/a?


/martin

From lhotka@nic.cz  Thu Feb 21 09:52:24 2013
Return-Path: 
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 7499121F8E84 for ; Thu, 21 Feb 2013 09:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.802
X-Spam-Level: 
X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.197,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 W3c2vKaFWUqy for ; Thu, 21 Feb 2013 09:52:23 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6F79621F8EEF for ; Thu, 21 Feb 2013 09:52:23 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DF81E13F64C; Thu, 21 Feb 2013 18:52:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361469139; bh=r6EzO59xlzIdfjVA4XPB3svbv/hkgix2OlF5Nas29a0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Tsfoqbxo3VKcT0PU8Q/zVwXDzu75cpbZcoMinLKuUNnPg9ly0lnjAf75YFar04R5t S120lcg4Ig784sxonQbpnxfhgZgSQFDzJTiWQ9yXjaT5bsyS1RPSsO1bcmoGOpHh7O 339ItRQvnykK7FOw75yiwMtssYaKon9uL1fKCASQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20130221.184352.325005457.mbj@tail-f.com>
Date: Thu, 21 Feb 2013 18:52:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8B85F10E-E971-4FF3-B0C0-2AA7F5908B35@nic.cz>
References: <201302211531.r1LFVUfX089492@idle.juniper.net>   <20130221.184352.325005457.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 17:52:24 -0000

On Feb 21, 2013, at 6:43 PM, Martin Bjorklund  wrote:

> Hi,
>=20
> So I checked the archives and found out that also I can change my
> mind: =
http://www.ietf.org/mail-archive/web/netmod/current/msg01599.html
>=20
> But I can't find an definitive answer anywhere.  My guess is that we
> found the problems that Lada points out below, and changed this so
> that the module must list all its submodules.
>=20
> Note this text from 7.1.6
>=20
>   When a module includes a submodule, it incorporates the contents of
>   the submodule into the node hierarchy of the module.  When a
>   submodule includes another submodule, the target submodule's
>   definitions are made available to the current submodule.
>=20
> So when a submodule includes another submodule it works in the same
> way as when a module imports another modules - the submodule can refer
> to the definitions in the included submodule, but its contents are not
> "copied".
>=20
> More below:
>=20
> Andy Bierman  wrote:
>> On Thu, Feb 21, 2013 at 7:57 AM, Ladislav Lhotka  =
wrote:
>>=20
>>>=20
>>> On Feb 21, 2013, at 4:31 PM, Phil Shafer  wrote:
>>>=20
>>>> Andy Bierman writes:
>>>>> I'd like to hear from Phil....
>>>>=20
>>>> My take is that there's nothing wrong with SM-A including SM-B =
which
>>>> isn't explicitly included by the module.  The "belongs-to" should
>>>> suffice to tell the compiler that this is acceptable.  Forcing the
>>>> module to grok the division of submodules is not necessary or
>>>> convenient.
>>>=20
>>> But what about the other aspect: If the main module doesn't include =
SM-B,
>>> is the SM-B content part of the module or not?
>=20
> Exactly, this is a very relevant question.
>=20
> I don't think the current text supports the use case that Phil
> mentioned, since when SM-A includes SM-B, SM-B's definitions are NOT
> incorporated into SM-A.
>=20
> But then if the above would be allowed anyway, what would this mean:
>=20
>  module M {
>    ....
>    include SM-A;
>  }
>=20
>  submodule SM-A {
>    ...
>    include SM-B;
>=20
>    augment /b {
>      leaf a { ... }
>    }
>  }
>=20
>  submodule SM-B {
>    ...
>    container b;
>  }
>=20
> M doesn't include SM-B, so container /b isn't exported. Whatabout
> /b/a?

In my view, neither /b nor /b/a can be part of the module tree. In fact, =
we can get a very similar issue with imports.

Lada

=20
>=20
>=20
> /martin

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





From phil@juniper.net  Thu Feb 21 10:38:14 2013
Return-Path: 
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 EF3C221F8F41 for ; Thu, 21 Feb 2013 10:38:13 -0800 (PST)
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 NxK6BONM7e-8 for ; Thu, 21 Feb 2013 10:38:01 -0800 (PST)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D321F8F31 for ; Thu, 21 Feb 2013 10:37:58 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUSZphfxsnqUmYZVjBvr3mjCC+zWKEgxI@postini.com; Thu, 21 Feb 2013 10:38:01 PST
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.3.213.0; Thu, 21 Feb 2013 10:32:46 -0800
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 r1LIWi385556; Thu, 21 Feb 2013 10:32:44 -0800 (PST)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id r1LIVl59090980; Thu, 21 Feb 2013 13:32:03 -0500 (EST)	(envelope-from phil@idle.juniper.net)
Message-ID: <201302211832.r1LIVl59090980@idle.juniper.net>
To: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 21 Feb 2013 13:31:47 -0500
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 18:38:14 -0000

Ladislav Lhotka writes:
>> My take is that there's nothing wrong with SM-A including SM-B which
>> isn't explicitly included by the module.  The "belongs-to" should
>> suffice to tell the compiler that this is acceptable.  Forcing the
>> module to grok the division of submodules is not necessary or
>> convenient.
>
>But what about the other aspect: If the main module doesn't include SM-B, is the SM-B co
>ntent part of the module or not?

No, since it was never included.  SM-B may be a set of types/grouping/etc
that are not needed for the module, only the submodules.

Thanks,
 Phil

From mbj@tail-f.com  Thu Feb 21 10:45:14 2013
Return-Path: 
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 2F2AD21F8F20 for ; Thu, 21 Feb 2013 10:45:14 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFwANBmuMzoY for ; Thu, 21 Feb 2013 10:45:08 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3585121F8F1E for ; Thu, 21 Feb 2013 10:45:08 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 38BDF1200A6E; Thu, 21 Feb 2013 19:45:07 +0100 (CET)
Date: Thu, 21 Feb 2013 19:45:06 +0100 (CET)
Message-Id: <20130221.194506.123253977.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund 
In-Reply-To: <201302211832.r1LIVl59090980@idle.juniper.net>
References:  <201302211832.r1LIVl59090980@idle.juniper.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 18:45:14 -0000

Phil Shafer  wrote:
> Ladislav Lhotka writes:
> >> My take is that there's nothing wrong with SM-A including SM-B which
> >> isn't explicitly included by the module.  The "belongs-to" should
> >> suffice to tell the compiler that this is acceptable.  Forcing the
> >> module to grok the division of submodules is not necessary or
> >> convenient.
> >
> >But what about the other aspect: If the main module doesn't include SM-B, is
> >the SM-B co
> >ntent part of the module or not?
> 
> No, since it was never included.  SM-B may be a set of types/grouping/etc
> that are not needed for the module, only the submodules.

This would work only for typedefs and groupings.  If the submodule
defines rpcs, they won't be exported through the module.  Same for
notifications, containers, lists, ..., identities, features.

There is nothing in RFC 6020 that explains this behavior, so I don't
think this works.

When I checked the archives (both yang & netmod @ ietf and private
design team emails), the motivation for allowing this was that a
submodule owner was free to split his submodule into more submodules,
w/o having to update the main module.  The interpretation above does
not support this use case.


/martin

From andy@yumaworks.com  Thu Feb 21 10:58:33 2013
Return-Path: 
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 C7F6321F87B1 for ; Thu, 21 Feb 2013 10:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.715
X-Spam-Level: 
X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.262,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 E5Ukh-6mffev for ; Thu, 21 Feb 2013 10:58:33 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05621F87AA for ; Thu, 21 Feb 2013 10:58:30 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id c10so11582423ieb.17 for ; Thu, 21 Feb 2013 10:58:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=qla+TXBwFsjP81OpWzFM/u3V6cdRH+Px/q0LaXmdYXw=; b=Zc/yDKmSpnwjkgHUlLr333qbFPaHx4T820bgs5g0mjFDlXqg7OXGePSKznLUIIAwMy FAMk25cbpBoSn8IcQ1aC6z9urMh0y1j3kuIPkyat4wQXllJH3/YfMY6y1+gzGYMXFmum Jtn08KGExuYqsud7b9jtC6Q3/1n7gyRkVNIGQvY9wOOeF+SzEEcQtPndBjVh+7qVeo97 knQa0svFYuczXdFp/JxzCf/c09IfS5Z4HdGKhb+NxOCMuLdxZ0rC03RUOq2ilpoTslO1 5BHzx/pdLOl0rS80tEgQm6sQHj8gPuUdCJdzImASw/RbJ0KHxZ0EhgErs2opsZP8YSp3 hlzw==
MIME-Version: 1.0
X-Received: by 10.42.91.209 with SMTP id q17mr11382534icm.50.1361473110018; Thu, 21 Feb 2013 10:58:30 -0800 (PST)
Received: by 10.231.235.201 with HTTP; Thu, 21 Feb 2013 10:58:29 -0800 (PST)
In-Reply-To: <201302211832.r1LIVl59090980@idle.juniper.net>
References:  <201302211832.r1LIVl59090980@idle.juniper.net>
Date: Thu, 21 Feb 2013 10:58:29 -0800
Message-ID: 
From: Andy Bierman 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=90e6ba5bbe131808e804d640a993
X-Gm-Message-State: ALoCoQldQ/6ppcnu9Z05ohMVsuFDoaY5McNiBr1r5etqelDDSENGLrNEWQmIDZ6i4xSVb2q6vhAh
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 18:58:33 -0000

--90e6ba5bbe131808e804d640a993
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 21, 2013 at 10:31 AM, Phil Shafer  wrote:

> Ladislav Lhotka writes:
> >> My take is that there's nothing wrong with SM-A including SM-B which
> >> isn't explicitly included by the module.  The "belongs-to" should
> >> suffice to tell the compiler that this is acceptable.  Forcing the
> >> module to grok the division of submodules is not necessary or
> >> convenient.
> >
> >But what about the other aspect: If the main module doesn't include SM-B,
> is the SM-B co
> >ntent part of the module or not?
>
> No, since it was never included.  SM-B may be a set of types/grouping/etc
> that are not needed for the module, only the submodules.
>
>

Another example:

module AA {
   include B;
   leaf x { type string; }
}

submodule B {
   include C;
   leaf y { type string; }

   uses aa:C-GRP;

}

submodule C {
   leaf z { type string; }

   grouping C-GRP {
      leaf zz {
          when "/aa:z = 'test-one'";
          type string;
        }
    }
}

You are saying that leafs x, y, zz will be visible to an external
module, but not leaf z?

I don't think that is what we implemented.
All 4 leafs will be exported.

What about the when expression in leaf zz that references leaf z?
Is that an error or does that auto-magically export leaf z?




> Thanks,
>  Phil
>

Andy

--90e6ba5bbe131808e804d640a993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Feb 21, 2013 at 10:31 AM, Phil S=
hafer <phil@juniper.net> wrote:

Ladislav Lhotka writes:

>> My take is that there's nothing wrong with SM-A including SM-B=
 which

>> isn't explicitly included by the module. =C2=A0The "belon=
gs-to" should

>> suffice to tell the compiler that this is acceptable. =C2=A0Forcin=
g the

>> module to grok the division of submodules is not necessary or

>> convenient.

>

>But what about the other aspect: If the main module doesn't include=
 SM-B, is the SM-B co

>ntent part of the module or not?



No, since it was never included. =C2=A0SM-B may be a set of types/grouping/=
etc

that are not needed for the module, only the submodules.




Another example:
<=
div>
module AA {
=C2=A0 =C2=A0include B;
=
=C2=A0 =C2=A0leaf x { type string; }
}

<=
div>submodule B {


=C2=A0 =C2=A0include C;
=C2=A0 =C2=A0leaf y { type string; }=


=C2=A0 =C2=A0uses aa:C-GRP;

<=
div>}

submodule C {
=C2=A0 = =C2=A0leaf z { type string; }

=C2=A0 =C2=A0grouping C-GRP {
=C2=A0 =C2=A0 =C2=A0= leaf zz {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "/a= a:z =3D 'test-one'";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 = =C2=A0 }=C2=A0
}

You are saying that leafs x, y, zz will be visible to an ext= ernal
module, but not leaf z?=C2=A0

I do= n't think that is what we implemented.
All 4 leafs will be ex= ported.

What about the when expression in leaf zz that referenc= es leaf z?
Is that an error or does that auto-magically export le= af z?


=C2=A0
Thanks,
=C2=A0Phil

Andy

--90e6ba5bbe131808e804d640a993-- From dthaler@microsoft.com Thu Feb 21 14:20:15 2013 Return-Path: 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 17E9621E8054 for ; Thu, 21 Feb 2013 14:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 nmxnLnKVmBo9 for ; Thu, 21 Feb 2013 14:20:13 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9846521E804D for ; Thu, 21 Feb 2013 14:20:13 -0800 (PST) Received: from BY2FFO11FD022.protection.gbl (10.1.15.201) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 21 Feb 2013 22:20:10 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 21 Feb 2013 22:20:10 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 21 Feb 2013 22:19:42 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 21 Feb 2013 14:19:42 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.12]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0328.011; Thu, 21 Feb 2013 14:19:42 -0800 From: Dave Thaler To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 Thread-Index: AQHOBJL1zzYlWCEWeEyMFqUDipIaQJiFf5ug Date: Thu, 21 Feb 2013 22:19:41 +0000 Message-ID: <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <20130206173959.GB83997@elstar.local> <20130206175114.GD83997@elstar.local> In-Reply-To: <20130206175114.GD83997@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(199002)(189002)(24454001)(13464002)(47976001)(49866001)(50986001)(33656001)(46406002)(47736001)(55846006)(65816001)(54316002)(76482001)(15202345001)(74502001)(47776003)(63696002)(56776001)(46102001)(53806001)(74662001)(20776003)(47446002)(16796002)(4396001)(5343655001)(50466001)(51856001)(77982001)(54356001)(44976002)(16406001)(80022001)(59766001)(56816002)(23726001)(31966008)(66066001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB025; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0764C4A8CD X-Mailman-Approved-At: Thu, 21 Feb 2013 21:04:42 -0800 Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:20:15 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Wednesday, February 6, 2013 9:51 AM > To: netmod@ietf.org; Dave Thaler > Subject: Re: draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip= - > cfg-08 >=20 > On Wed, Feb 06, 2013 at 06:39:59PM +0100, Juergen Schoenwaelder wrote: > > Hi, > > > > Martin has posted two new IDs: > > > > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > These documents did already pass WG last call. However, there were > > some non-editorial changes (in particular in > > draft-ietf-netmod-ip-cfg-08) in order to make use of the types that > > have been moved to 6021bis. I like to ask people to check the changes > > and to raise any issues they might have with the changes as soon as > > possible but not later than February 12th, 2013. > > >=20 > Speaking as technical contributor, I like to highlight that the new versi= on > disallows zone indexes in IP addresses of interfaces and in the neighbor > tables. This is technically fine since everything is scoped by an interfa= ce, so > implicitely the information is always there. The question is whether this= is > convenient or the approach existing systems usually follow. It seems that > BSD like systems tend to show the zone index while Linux like systems ten= d > to hide it, leaving it to the context information. I do not know about > Windows, maybe Dave Thaler can inform us. It is correct to disallow zone indexes in IP addresses that are already sco= ped by an interface, and require them in cases that are not scoped to an interf= ace. When you say "tend to show", I'm not sure if you are referring to command line tools or something else. If command line tools and other UI, then on Windows it varies by command/UI whether the zone id is shown or not. It's obviously shown in any context that's not scoped to an interface. Note that zone indexes are properties of an interface, and I'm not seeing them as interface properties in http://tools.ietf.org/html/draft-ietf-netmo= d-ip-cfg-08 -Dave =20 > If we allow zone indexes (as we had before), of course the question comes > up whether the canonical representation is without a zone index or with a > zone index for non-global addresses. (This was not specified before eithe= r > but frankly should have been.) > > I am raising this issue here explicitely since I want that the WG takes a= n > informed decision about this change. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Feb 22 01:34:24 2013 Return-Path: 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 60AB621F8E65 for ; Fri, 22 Feb 2013 01:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 g9+nkKjVNJXy for ; Fri, 22 Feb 2013 01:34:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA13221F8E4B for ; Fri, 22 Feb 2013 01:34:22 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1708B20BEC; Fri, 22 Feb 2013 10:34:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qh9_dlLZF8S4; Fri, 22 Feb 2013 10:34:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B08E207E0; Fri, 22 Feb 2013 10:34:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B3A2424AC519; Fri, 22 Feb 2013 10:34:29 +0100 (CET) Date: Fri, 22 Feb 2013 10:34:29 +0100 From: Juergen Schoenwaelder To: Dave Thaler Message-ID: <20130222093427.GC62099@elstar.local> Mail-Followup-To: Dave Thaler , "netmod@ietf.org" References: <20130206173959.GB83997@elstar.local> <20130206175114.GD83997@elstar.local> <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 09:34:24 -0000 On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Wednesday, February 6, 2013 9:51 AM > > To: netmod@ietf.org; Dave Thaler > > Subject: Re: draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip- > > cfg-08 > > > > On Wed, Feb 06, 2013 at 06:39:59PM +0100, Juergen Schoenwaelder wrote: > > > Hi, > > > > > > Martin has posted two new IDs: > > > > > > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09 > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > > > These documents did already pass WG last call. However, there were > > > some non-editorial changes (in particular in > > > draft-ietf-netmod-ip-cfg-08) in order to make use of the types that > > > have been moved to 6021bis. I like to ask people to check the changes > > > and to raise any issues they might have with the changes as soon as > > > possible but not later than February 12th, 2013. > > > > > > > Speaking as technical contributor, I like to highlight that the new version > > disallows zone indexes in IP addresses of interfaces and in the neighbor > > tables. This is technically fine since everything is scoped by an interface, so > > implicitely the information is always there. The question is whether this is > > convenient or the approach existing systems usually follow. It seems that > > BSD like systems tend to show the zone index while Linux like systems tend > > to hide it, leaving it to the context information. I do not know about > > Windows, maybe Dave Thaler can inform us. > > It is correct to disallow zone indexes in IP addresses that are already scoped > by an interface, and require them in cases that are not scoped to an interface. So you are saying what we have in draft-ietf-netmod-ip-cfg-08 is correct. That's useful input. > When you say "tend to show", I'm not sure if you are referring to command > line tools or something else. If command line tools and other UI, then on > Windows it varies by command/UI whether the zone id is shown or not. > It's obviously shown in any context that's not scoped to an interface. > > Note that zone indexes are properties of an interface, and I'm not seeing > them as interface properties in http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 The relevant information is in the definition of generic interfaces, see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We have an interface/name and an interface/if-index for every interface. The IP model extends the generic interface model with IP specific configuration information. So I think we are fine. Or do we need to add text somewhere to make it clear that people find that information when they just look at the IP configuration model? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Feb 22 02:30:17 2013 Return-Path: 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 A261E21F8E4D for ; Fri, 22 Feb 2013 02:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 0PUwXrB0P5cE for ; Fri, 22 Feb 2013 02:30:17 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id E36B221F8E4B for ; Fri, 22 Feb 2013 02:30:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E40AC5405ED for ; Fri, 22 Feb 2013 11:30:10 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-bgtm-YkYcl for ; Fri, 22 Feb 2013 11:30:04 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C45E9540030 for ; Fri, 22 Feb 2013 11:29:59 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <201302211832.r1LIVl59090980@idle.juniper.net> References: <201302211832.r1LIVl59090980@idle.juniper.net> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 22 Feb 2013 11:30:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:30:17 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>> My take is that there's nothing wrong with SM-A including SM-B which >>> isn't explicitly included by the module. The "belongs-to" should >>> suffice to tell the compiler that this is acceptable. Forcing the >>> module to grok the division of submodules is not necessary or >>> convenient. >> >>But what about the other aspect: If the main module doesn't include SM-B, is the SM-B co >>ntent part of the module or not? > > No, since it was never included. SM-B may be a set of types/grouping/etc > that are not needed for the module, only the submodules. Yes, this makes good sense, and is in fact in accord with the spec. I think it is absolutely necessary that all submodules that contribute nodes to the schema (+ features etc.) be listed in the main module (or otherwise they would have to be in the server's hello). Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Feb 22 02:40:02 2013 Return-Path: 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 7A89E21F8E3A for ; Fri, 22 Feb 2013 02:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 wK9RXsYJG9mp for ; Fri, 22 Feb 2013 02:40:01 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5B17921F8E2C for ; Fri, 22 Feb 2013 02:40:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5A52C5405ED for ; Fri, 22 Feb 2013 11:40:00 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kYFFWH6FUQr for ; Fri, 22 Feb 2013 11:39:56 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 87403540030 for ; Fri, 22 Feb 2013 11:39:56 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130221.194506.123253977.mbj@tail-f.com> References: <201302211832.r1LIVl59090980@idle.juniper.net> <20130221.194506.123253977.mbj@tail-f.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 22 Feb 2013 11:39:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:40:02 -0000 Martin Bjorklund writes: > Phil Shafer wrote: >> Ladislav Lhotka writes: >> >> My take is that there's nothing wrong with SM-A including SM-B which >> >> isn't explicitly included by the module. The "belongs-to" should >> >> suffice to tell the compiler that this is acceptable. Forcing the >> >> module to grok the division of submodules is not necessary or >> >> convenient. >> > >> >But what about the other aspect: If the main module doesn't include SM-B, is >> >the SM-B co >> >ntent part of the module or not? >> >> No, since it was never included. SM-B may be a set of types/grouping/etc >> that are not needed for the module, only the submodules. > > This would work only for typedefs and groupings. If the submodule > defines rpcs, they won't be exported through the module. Same for > notifications, containers, lists, ..., identities, features. Right, if they are not included in the main module, then they are not present. > > There is nothing in RFC 6020 that explains this behavior, so I don't > think this works. I think this sentence is clear enough: When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. IMO this implies that if a submodule is not included by the main module, its contents are not incorporated. > > When I checked the archives (both yang & netmod @ ietf and private > design team emails), the motivation for allowing this was that a > submodule owner was free to split his submodule into more submodules, > w/o having to update the main module. The interpretation above does > not support this use case. Yes, but writing a new submodule must not mean that its contents are automatically incorporated in the schema. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Feb 22 02:56:19 2013 Return-Path: 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 B016E21F8E20 for ; Fri, 22 Feb 2013 02:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 6cp6sRepmxp1 for ; Fri, 22 Feb 2013 02:56:19 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8B621F8783 for ; Fri, 22 Feb 2013 02:56:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 550E35405ED for ; Fri, 22 Feb 2013 11:56:18 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcnITpUautB1 for ; Fri, 22 Feb 2013 11:56:15 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 79B47540030 for ; Fri, 22 Feb 2013 11:56:15 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <201302211832.r1LIVl59090980@idle.juniper.net> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 22 Feb 2013 11:56:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:56:19 -0000 Andy Bierman writes: > On Thu, Feb 21, 2013 at 10:31 AM, Phil Shafer wrote: > >> Ladislav Lhotka writes: >> >> My take is that there's nothing wrong with SM-A including SM-B which >> >> isn't explicitly included by the module. The "belongs-to" should >> >> suffice to tell the compiler that this is acceptable. Forcing the >> >> module to grok the division of submodules is not necessary or >> >> convenient. >> > >> >But what about the other aspect: If the main module doesn't include SM-B, >> is the SM-B co >> >ntent part of the module or not? >> >> No, since it was never included. SM-B may be a set of types/grouping/etc >> that are not needed for the module, only the submodules. >> >> > > Another example: > > module AA { > include B; > leaf x { type string; } > } > > submodule B { > include C; > leaf y { type string; } > > uses aa:C-GRP; > > } > > submodule C { > leaf z { type string; } > > grouping C-GRP { > leaf zz { > when "/aa:z = 'test-one'"; > type string; > } > } > } > > You are saying that leafs x, y, zz will be visible to an external > module, but not leaf z? > > I don't think that is what we implemented. > All 4 leafs will be exported. > > What about the when expression in leaf zz that references leaf z? > Is that an error or does that auto-magically export leaf z? This is just another race condition wrt 'when', and I would only have to repeat my previous objections against making 'when' constraints a part of schema validation. In my view, a sound procedure for your example would be something like this: 1. First construct the schema: it contains x, y and zz, but not z because C is not included by AA. 2. Then, an instance document containing zz would be classified as invalid because the 'when' *semantic* condition can never be true. Lada > > > > >> Thanks, >> Phil >> > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Feb 22 03:06:17 2013 Return-Path: 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 A6B2521F8E47 for ; Fri, 22 Feb 2013 03:06:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3noJHf97l6P for ; Fri, 22 Feb 2013 03:06:15 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0959021F8E56 for ; Fri, 22 Feb 2013 03:06:11 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DDFE01200AF6; Fri, 22 Feb 2013 12:06:07 +0100 (CET) Date: Fri, 22 Feb 2013 12:06:07 +0100 (CET) Message-Id: <20130222.120607.248909208.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <201302211832.r1LIVl59090980@idle.juniper.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:06:17 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > Another example: > > > > module AA { > > include B; > > leaf x { type string; } > > } > > > > submodule B { > > include C; > > leaf y { type string; } > > > > uses aa:C-GRP; > > > > } > > > > submodule C { > > leaf z { type string; } > > > > grouping C-GRP { > > leaf zz { > > when "/aa:z = 'test-one'"; > > type string; > > } > > } > > } > > > > You are saying that leafs x, y, zz will be visible to an external > > module, but not leaf z? > > > > I don't think that is what we implemented. > > All 4 leafs will be exported. > > > > What about the when expression in leaf zz that references leaf z? > > Is that an error or does that auto-magically export leaf z? > > This is just another race condition wrt 'when', and I would only have to > repeat my previous objections against making 'when' constraints a part of > schema validation. In my view, this is simple. When the 'when' expression is evaluated, there is no node /a:z, so it will always fail. But this is also a reason for requiring modules to list all submodules. Otherwise, people will forget to include them, and get confused by the result. /martin From lhotka@nic.cz Fri Feb 22 03:55:03 2013 Return-Path: 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 5549121F8EBE for ; Fri, 22 Feb 2013 03:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.782 X-Spam-Level: X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 yTkmwCDL3IqO for ; Fri, 22 Feb 2013 03:54:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E153821F8E96 for ; Fri, 22 Feb 2013 03:54:56 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1E5F513F9D2; Fri, 22 Feb 2013 12:54:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361534094; bh=X6IIl2a110QYFuqFX5vZ3FEbHDAc6g7Jpr+dRJ1jrRw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nJrB55I2SEEHrzsj0JCWY2wjwgFK1ByMLqVapDohqIiCRN/+RtDXpqdihgiA4Zzae 9s872JYsJ0rWhJ5deE3r5+LPZY8vPnauD6jp7T69SWh8lUsHkQ0VwdRGHJZDmjFNph 5bFlfYRKzs/4mnCcKDomT2oV8s8AsbqJoNEFY0Lk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130222.120607.248909208.mbj@tail-f.com> Date: Fri, 22 Feb 2013 12:54:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201302211832.r1LIVl59090980@idle.juniper.net> <20130222.120607.248909208.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:55:03 -0000 On Feb 22, 2013, at 12:06 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Andy Bierman writes: >>> Another example: >>>=20 >>> module AA { >>> include B; >>> leaf x { type string; } >>> } >>>=20 >>> submodule B { >>> include C; >>> leaf y { type string; } >>>=20 >>> uses aa:C-GRP; >>>=20 >>> } >>>=20 >>> submodule C { >>> leaf z { type string; } >>>=20 >>> grouping C-GRP { >>> leaf zz { >>> when "/aa:z =3D 'test-one'"; >>> type string; >>> } >>> } >>> } >>>=20 >>> You are saying that leafs x, y, zz will be visible to an external >>> module, but not leaf z? >>>=20 >>> I don't think that is what we implemented. >>> All 4 leafs will be exported. >>>=20 >>> What about the when expression in leaf zz that references leaf z? >>> Is that an error or does that auto-magically export leaf z? >>=20 >> This is just another race condition wrt 'when', and I would only have = to >> repeat my previous objections against making 'when' constraints a = part of >> schema validation. >=20 > In my view, this is simple. When the 'when' expression is evaluated, > there is no node /a:z, so it will always fail. >=20 > But this is also a reason for requiring modules to list all > submodules. Otherwise, people will forget to include them, and get > confused by the result. Yes, but if a submodule only defines groupings/typedefs that are used by = other submodules, then the main module needn't be involved, and there is = no risk of confusion or interoperability problems. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Feb 22 05:10:16 2013 Return-Path: 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 CC39E21F8F44 for ; Fri, 22 Feb 2013 05:10:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fVJX057xTC8 for ; Fri, 22 Feb 2013 05:10:15 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A09AE21F87AA for ; Fri, 22 Feb 2013 05:10:15 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A9D911200A6E; Fri, 22 Feb 2013 14:10:14 +0100 (CET) Date: Fri, 22 Feb 2013 14:10:14 +0100 (CET) Message-Id: <20130222.141014.235169504.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130222093427.GC62099@elstar.local> References: <20130206175114.GD83997@elstar.local> <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <20130222093427.GC62099@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, dthaler@microsoft.com Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:10:17 -0000 Hi, Juergen Schoenwaelder wrote: > On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > Note that zone indexes are properties of an interface, and I'm not seeing > > them as interface properties in > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > The relevant information is in the definition of generic interfaces, > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We > have an interface/name and an interface/if-index for every interface. > The IP model extends the generic interface model with IP specific > configuration information. So I think we are fine. 6021 (and bis) says: For link-local addresses, the zone index will typically be the interface index number or the name of an interface. First of all it says "typically", which I interpret to mean that it can also be something else. Second, it is not clear that the interface index number is the same as ifIndex (I don't think it is the same in all implementations), and further, ifIndex has an if-feature. So it is not clear what the zone index would be. But even so, RFC 4007 talks about "link-local scope" and "interface-local scope". I assume the "interface-local scope" can be the interface index, but the link local scope may be something else? /martin From j.schoenwaelder@jacobs-university.de Fri Feb 22 05:29:58 2013 Return-Path: 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 42A4521F8EAA for ; Fri, 22 Feb 2013 05:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 yrEdacJYjPr7 for ; Fri, 22 Feb 2013 05:29:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7721F8E93 for ; Fri, 22 Feb 2013 05:29:57 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C441D20BE4; Fri, 22 Feb 2013 14:29:56 +0100 (CET) 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 Fc8BfPhb-p5v; Fri, 22 Feb 2013 14:29:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5141820BE2; Fri, 22 Feb 2013 14:29:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E373924ACBC4; Fri, 22 Feb 2013 14:30:04 +0100 (CET) Date: Fri, 22 Feb 2013 14:30:04 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130222133003.GA63107@elstar.local> Mail-Followup-To: Martin Bjorklund , dthaler@microsoft.com, netmod@ietf.org References: <20130206175114.GD83997@elstar.local> <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130222.141014.235169504.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org, dthaler@microsoft.com Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:29:58 -0000 On Fri, Feb 22, 2013 at 02:10:14PM +0100, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > > Note that zone indexes are properties of an interface, and I'm not seeing > > > them as interface properties in > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > The relevant information is in the definition of generic interfaces, > > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We > > have an interface/name and an interface/if-index for every interface. > > The IP model extends the generic interface model with IP specific > > configuration information. So I think we are fine. > > 6021 (and bis) says: > > For link-local addresses, the zone index will > typically be the interface index number or the name of an > interface. > > First of all it says "typically", which I interpret to mean that it > can also be something else. Second, it is not clear that the > interface index number is the same as ifIndex (I don't think it is the > same in all implementations), and further, ifIndex has an if-feature. > > So it is not clear what the zone index would be. I think API implementation often accept both a name and a number and the number typically is the interface index. RFC 4007 says implementations must support numbers and should support names as well. In the SMIv2 MIB space, a zone identifier is always a number. > But even so, RFC 4007 talks about "link-local scope" and > "interface-local scope". I assume the "interface-local scope" can be > the interface index, but the link local scope may be something else? With link-local scope, you usually use the interface index/name of the link to identify the zone. Are you suggesting that there should be a separate (mandatory?) zone-id object? Or are you suggesting we should make ifIndex mandatory? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Feb 22 05:36:26 2013 Return-Path: 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 9C9C321F8FD1 for ; Fri, 22 Feb 2013 05:36:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOr-elAjbB6S for ; Fri, 22 Feb 2013 05:36:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AE67221F8ECA for ; Fri, 22 Feb 2013 05:36:25 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id F3C001200A6E; Fri, 22 Feb 2013 14:36:24 +0100 (CET) Date: Fri, 22 Feb 2013 14:36:24 +0100 (CET) Message-Id: <20130222.143624.522177974.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130222133003.GA63107@elstar.local> References: <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> <20130222133003.GA63107@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, dthaler@microsoft.com Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:36:26 -0000 Juergen Schoenwaelder wrote: > On Fri, Feb 22, 2013 at 02:10:14PM +0100, Martin Bjorklund wrote: > > Hi, > > > > Juergen Schoenwaelder wrote: > > > On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > > > Note that zone indexes are properties of an interface, and I'm not seeing > > > > them as interface properties in > > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > > > The relevant information is in the definition of generic interfaces, > > > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We > > > have an interface/name and an interface/if-index for every interface. > > > The IP model extends the generic interface model with IP specific > > > configuration information. So I think we are fine. > > > > 6021 (and bis) says: > > > > For link-local addresses, the zone index will > > typically be the interface index number or the name of an > > interface. > > > > First of all it says "typically", which I interpret to mean that it > > can also be something else. Second, it is not clear that the > > interface index number is the same as ifIndex (I don't think it is the > > same in all implementations), and further, ifIndex has an if-feature. > > > > So it is not clear what the zone index would be. > > I think API implementation often accept both a name and a number and > the number typically is the interface index. RFC 4007 says > implementations must support numbers and should support names as > well. In the SMIv2 MIB space, a zone identifier is always a number. > > > But even so, RFC 4007 talks about "link-local scope" and > > "interface-local scope". I assume the "interface-local scope" can be > > the interface index, but the link local scope may be something else? > > With link-local scope, you usually use the interface index/name of the > link to identify the zone. Isn't the difference between link-local scope and interface-local scope that there can be more than one interface attached to one link? Which interface's number would you use as the link zone identifier? > Are you suggesting that there should be a separate (mandatory?) > zone-id object? Or are you suggesting we should make ifIndex > mandatory? At this point I am not suggesting anything. I just think it must be clear what we mean and what we require from an implementation. /martin From andy@yumaworks.com Fri Feb 22 05:37:13 2013 Return-Path: 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 24F8A21F8EAA for ; Fri, 22 Feb 2013 05:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 c9VO8e49hPYu for ; Fri, 22 Feb 2013 05:37:12 -0800 (PST) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5021F8E6C for ; Fri, 22 Feb 2013 05:37:12 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so539231iaz.2 for ; Fri, 22 Feb 2013 05:37:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=iSOEFOw8OV7YAwcobcfoJIRJUd4eQd3jtQsRSYwoXxY=; b=kHQW+eBbD/d4TbEe4Ts+B7Zd0Fds21ZCv2KwtsLb9JywkeS6XEW0mtlQjaFJmdOzdd YAn956i6PCIjg261coe59slkgjlx9hJvNBL6b5kwMe+qKPbKkvaBb/Sdbpb7c/vy/4DJ NKKDMBoVCrzxMXFojjSapNfVzsZX9SS/Nkx84wU58DyGFkoZYzexJviPBr5OcpCozFjv cEC5Vl1o1QAYyTR38tJGUZCZVXsI938R4rcSqFZBneO2NLQvDtMizquZ+cL0BVpqa2J6 ue981Oy3FrLSwvPMh2oiCCk3x4PEtHr5WFrbYfyeVxmynUSk/qEFhsbMvR5uQU6Jt92H uMJw== MIME-Version: 1.0 X-Received: by 10.50.12.133 with SMTP id y5mr15025402igb.108.1361540231975; Fri, 22 Feb 2013 05:37:11 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 05:37:11 -0800 (PST) In-Reply-To: <20130222.120607.248909208.mbj@tail-f.com> References: <201302211832.r1LIVl59090980@idle.juniper.net> <20130222.120607.248909208.mbj@tail-f.com> Date: Fri, 22 Feb 2013 05:37:11 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae9340f1ddfd2a204d6504995 X-Gm-Message-State: ALoCoQmiQlYOw2RFe6xxFPsMyq761VInKv8iOBAAST5DcZxsmuYjJRL3U7T3NpkxtqowiWaLSKrn Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:37:13 -0000 --14dae9340f1ddfd2a204d6504995 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 3:06 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Andy Bierman writes: > > > Another example: > > > > > > module AA { > > > include B; > > > leaf x { type string; } > > > } > > > > > > submodule B { > > > include C; > > > leaf y { type string; } > > > > > > uses aa:C-GRP; > > > > > > } > > > > > > submodule C { > > > leaf z { type string; } > > > > > > grouping C-GRP { > > > leaf zz { > > > when "/aa:z = 'test-one'"; > > > type string; > > > } > > > } > > > } > > > > > > You are saying that leafs x, y, zz will be visible to an external > > > module, but not leaf z? > > > > > > I don't think that is what we implemented. > > > All 4 leafs will be exported. > > > > > > What about the when expression in leaf zz that references leaf z? > > > Is that an error or does that auto-magically export leaf z? > > > > This is just another race condition wrt 'when', and I would only have to > > repeat my previous objections against making 'when' constraints a part of > > schema validation. > > In my view, this is simple. When the 'when' expression is evaluated, > there is no node /a:z, so it will always fail. > > But this is also a reason for requiring modules to list all > submodules. Otherwise, people will forget to include them, and get > confused by the result. > I disagree. Perhaps the spec is ambiguous, but I don't agree adding busy work for the YANG module writer is needed. The YANG compiler can easily figure out what to do based on the belongs-to-stmt. IMO, the text for that clause says definitions in a submodule are part of the module. I haven't read anything in this thread that would cause me to change any code. The spec supports both implementation plans IMO, and it will take a lot more than an errata to change it. > > > /martin > Andy --14dae9340f1ddfd2a204d6504995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 3:06 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> = wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
> > Another example:
> >
> > module AA {
> > =C2=A0 =C2=A0include B;
> > =C2=A0 =C2=A0leaf x { type string; }
> > }
> >
> > submodule B {
> > =C2=A0 =C2=A0include C;
> > =C2=A0 =C2=A0leaf y { type string; }
> >
> > =C2=A0 =C2=A0uses aa:C-GRP;
> >
> > }
> >
> > submodule C {
> > =C2=A0 =C2=A0leaf z { type string; }
> >
> > =C2=A0 =C2=A0grouping C-GRP {
> > =C2=A0 =C2=A0 =C2=A0 leaf zz {
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "/aa:z =3D 'test= -one'";
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > =C2=A0 =C2=A0 }
> > }
> >
> > You are saying that leafs x, y, zz will be visible to an external=
> > module, but not leaf z?
> >
> > I don't think that is what we implemented.
> > All 4 leafs will be exported.
> >
> > What about the when expression in leaf zz that references leaf z?=
> > Is that an error or does that auto-magically export leaf z?
>
> This is just another race condition wrt 'when', and I would on= ly have to
> repeat my previous objections against making 'when' constraint= s a part of
> schema validation.

In my view, this is simple. =C2=A0When the 'when' expression is eva= luated,
there is no node /a:z, so it will always fail.

But this is also a reason for requiring modules to list all
submodules. =C2=A0Otherwise, people will forget to include them, and get confused by the result.

I disagree.
Perhaps the spec is ambiguous, but I don't agree adding busy wor= k for
the YANG module writer is needed. =C2=A0The YANG compiler c= an easily
figure out what to do based on the belongs-to-stmt. =C2=A0IMO, the tex= t
for that clause says definitions in a submodule are part of the= module.

I haven't read anything in this threa= d that would cause me to change any code.
The spec supports both implementation plans IMO, and it will take a lo= t
more than an errata to change it.

=C2= =A0


/martin

Andy

= =C2=A0
--14dae9340f1ddfd2a204d6504995-- From j.schoenwaelder@jacobs-university.de Fri Feb 22 05:49:51 2013 Return-Path: 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 7EDF421F8E17 for ; Fri, 22 Feb 2013 05:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 HvtLa8VtXr3g for ; Fri, 22 Feb 2013 05:49:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CEFC221F8F70 for ; Fri, 22 Feb 2013 05:49:50 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E3E620BE2; Fri, 22 Feb 2013 14:49:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Zbbjs9h6Uux1; Fri, 22 Feb 2013 14:49:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1750B20BE4; Fri, 22 Feb 2013 14:49:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CC17324ACCB2; Fri, 22 Feb 2013 14:49:56 +0100 (CET) Date: Fri, 22 Feb 2013 14:49:56 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130222134956.GA63213@elstar.local> Mail-Followup-To: Martin Bjorklund , dthaler@microsoft.com, netmod@ietf.org References: <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> <20130222133003.GA63107@elstar.local> <20130222.143624.522177974.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130222.143624.522177974.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org, dthaler@microsoft.com Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:49:51 -0000 On Fri, Feb 22, 2013 at 02:36:24PM +0100, Martin Bjorklund wrote: > > > But even so, RFC 4007 talks about "link-local scope" and > > > "interface-local scope". I assume the "interface-local scope" can be > > > the interface index, but the link local scope may be something else? > > > > With link-local scope, you usually use the interface index/name of the > > link to identify the zone. > > Isn't the difference between link-local scope and interface-local > scope that there can be more than one interface attached to one link? > Which interface's number would you use as the link zone identifier? In this case, I assume implementations accept any of them as valid input to identify the zone. Which one do you use as the canonical output? No clue, likely no RFC ever talks about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Feb 22 05:50:23 2013 Return-Path: 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 11DB821F8F72 for ; Fri, 22 Feb 2013 05:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 ceEpfuCh4iW5 for ; Fri, 22 Feb 2013 05:50:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5441521F8EAF for ; Fri, 22 Feb 2013 05:50:08 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8A07113F9D2; Fri, 22 Feb 2013 14:50:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361541007; bh=TM/WOcNpZOLG1S2iA+snp9DtnzcHaWzWoSi+ptFhG18=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nSppHQGpBbfdu+QJyE79HR97ow4IqZzWQ58fmqGD4PNtiAVf1WaqiOYObF18Krlux EFYOWwtEgxujCfxls95uJWyIln82n4NGejqrrI03w3E+EYqf6mkzig2QhKqJCs7/sl c85Gv23W/H9yPKPP6bJ9w3T3chj1kNYg7EC7k+wM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 14:50:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FA9668F-E6DD-4F5B-B60D-93A72D634EB9@nic.cz> References: <201302211832.r1LIVl59090980@idle.juniper.net> <20130222.120607.248909208.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:50:23 -0000 On Feb 22, 2013, at 2:37 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 3:06 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > Andy Bierman writes: > > > Another example: > > > > > > module AA { > > > include B; > > > leaf x { type string; } > > > } > > > > > > submodule B { > > > include C; > > > leaf y { type string; } > > > > > > uses aa:C-GRP; > > > > > > } > > > > > > submodule C { > > > leaf z { type string; } > > > > > > grouping C-GRP { > > > leaf zz { > > > when "/aa:z =3D 'test-one'"; > > > type string; > > > } > > > } > > > } > > > > > > You are saying that leafs x, y, zz will be visible to an external > > > module, but not leaf z? > > > > > > I don't think that is what we implemented. > > > All 4 leafs will be exported. > > > > > > What about the when expression in leaf zz that references leaf z? > > > Is that an error or does that auto-magically export leaf z? > > > > This is just another race condition wrt 'when', and I would only = have to > > repeat my previous objections against making 'when' constraints a = part of > > schema validation. >=20 > In my view, this is simple. When the 'when' expression is evaluated, > there is no node /a:z, so it will always fail. >=20 > But this is also a reason for requiring modules to list all > submodules. Otherwise, people will forget to include them, and get > confused by the result. >=20 > I disagree. > Perhaps the spec is ambiguous, but I don't agree adding busy work for > the YANG module writer is needed. The YANG compiler can easily > figure out what to do based on the belongs-to-stmt. IMO, the text Do you mean this? module M { /* no include at all */ } submodule A { /* some data nodes */ } What if the server has the submodule but the client hasn't? Then the = contract breaks because each side has a different data model. I also = don't like the idea that someone smuggles a submodule into a repository = and its contents automatically become part of a module whose author = needn't be aware of it. This looks like a security hole. Lada > for that clause says definitions in a submodule are part of the = module. >=20 > I haven't read anything in this thread that would cause me to change = any code. > The spec supports both implementation plans IMO, and it will take a = lot > more than an errata to change it. >=20 > =20 >=20 >=20 > /martin >=20 > Andy >=20 > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Feb 22 05:51:19 2013 Return-Path: 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 57FD621F8F70 for ; Fri, 22 Feb 2013 05:51:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXIy-oWem+fj for ; Fri, 22 Feb 2013 05:51:17 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 027AD21F8E17 for ; Fri, 22 Feb 2013 05:51:17 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 224481200A6E; Fri, 22 Feb 2013 14:51:16 +0100 (CET) Date: Fri, 22 Feb 2013 14:51:15 +0100 (CET) Message-Id: <20130222.145115.368561051.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130222.120607.248909208.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:51:19 -0000 Andy Bierman wrote: > Perhaps the spec is ambiguous, but I don't agree adding busy work for > the YANG module writer is needed. The YANG compiler can easily > figure out what to do based on the belongs-to-stmt. No one has suggested this. > I haven't read anything in this thread that would cause me to change any > code. > The spec supports both implementation plans IMO, and it will take a lot > more than an errata to change it. There are three, not two, alternatives: 1. Require the module to list all submodules (current pyang behavior) 2. Recursively incorporate the contents from all submodules into the module (current yuma behavior) 3. Allow submodules that are not listed in the main module, but do not incorporate contents from non-listed submodules The spec is not crystal clear, but I think that only interpretation (3) above is supported by the spec. Specifically, this text makes (1) unsupported: Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to include other submodules belonging to the same module. And this text makes (2) unsupported: When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule. This is unfortunate. I think both (1) and (2) are useful, but (3) is mostly just confusing. /martin From j.schoenwaelder@jacobs-university.de Fri Feb 22 06:03:10 2013 Return-Path: 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 D31AE21F8E4D for ; Fri, 22 Feb 2013 06:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 ilBckVlWGLYJ for ; Fri, 22 Feb 2013 06:03:10 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D1D3821F8E45 for ; Fri, 22 Feb 2013 06:03:09 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1603F20A1F; Fri, 22 Feb 2013 15:03:09 +0100 (CET) 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 z3LkW09roOeW; Fri, 22 Feb 2013 15:03:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3AAE209D7; Fri, 22 Feb 2013 15:03:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4D62224ACDAD; Fri, 22 Feb 2013 15:03:17 +0100 (CET) Date: Fri, 22 Feb 2013 15:03:16 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130222140316.GA63273@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20130222.120607.248909208.mbj@tail-f.com> <20130222.145115.368561051.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130222.145115.368561051.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:03:11 -0000 On Fri, Feb 22, 2013 at 02:51:15PM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > Perhaps the spec is ambiguous, but I don't agree adding busy work for > > the YANG module writer is needed. The YANG compiler can easily > > figure out what to do based on the belongs-to-stmt. > > No one has suggested this. > > > I haven't read anything in this thread that would cause me to change any > > code. > > The spec supports both implementation plans IMO, and it will take a lot > > more than an errata to change it. > > There are three, not two, alternatives: > > 1. Require the module to list all submodules (current pyang > behavior) > > 2. Recursively incorporate the contents from all submodules into > the module (current yuma behavior) > > 3. Allow submodules that are not listed in the main module, but do > not incorporate contents from non-listed submodules > > The spec is not crystal clear, but I think that only interpretation > (3) above is supported by the spec. > > Specifically, this text makes (1) unsupported: > > Modules are only allowed to > include submodules that belong to that module, as defined by the > "belongs-to" statement (see Section 7.2.2). Submodules are only > allowed to include other submodules belonging to the same module. I do not see why this text makes (1) unsupported. This text only puts up a restriction that you can't include submodules that belong to other modules, no? > And this text makes (2) unsupported: > > When a module includes a submodule, it incorporates the contents of > the submodule into the node hierarchy of the module. When a > submodule includes another submodule, the target submodule's > definitions are made available to the current submodule. I think the text is ambiguous since it remains unclear what "made available to the current submodule" means. > This is unfortunate. I think both (1) and (2) are useful, but (3) is > mostly just confusing. My reading is that the current text is ambiguous (and apparently implementors came to two different interpretations). So we need to decide what was/is desired and then fix things to avoid the ambiguity. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jonathan@hansfords.net Fri Feb 22 06:09:19 2013 Return-Path: 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 D982F21F8EAF for ; Fri, 22 Feb 2013 06:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 znFbXElLi+tq for ; Fri, 22 Feb 2013 06:09:19 -0800 (PST) Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id C770321F893F for ; Fri, 22 Feb 2013 06:09:18 -0800 (PST) Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id 3S9G1l0043BT6uC01S9Geo; Fri, 22 Feb 2013 14:09:16 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=Df3JXIRW c=1 sm=1 a=jSQgp9IWXRf89EXR5FPwJg==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=xskcdSivAAAA:8 a=WjfS9EJ_deIWHDjS3I8A:9 a=QEXdDO2ut3YA:10 a=ChEcuLpljosA:10 a=wp5rPLkunvAL16zUbLUA:9 a=_W_S_7VecoQA:10 a=stJItQRlw7Hvdh6Y:21 a=jSQgp9IWXRf89EXR5FPwJg==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 22 Feb 2013 14:09:16 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7fd9fa297d9d964ee9f73b6ba42cb5dd" Date: Fri, 22 Feb 2013 14:09:16 +0000 From: Jonathan Hansford To: Martin Bjorklund , , In-Reply-To: <20130222140316.GA63273@elstar.local> References: <20130222.120607.248909208.mbj@tail-f.com> <20130222.145115.368561051.mbj@tail-f.com> <20130222140316.GA63273@elstar.local> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:09:20 -0000 --=_7fd9fa297d9d964ee9f73b6ba42cb5dd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Can someone clarify why transitivity is considered so unacceptable? I'm still learning about YANG and a clarification of this point would really help. On 22.02.2013 14:03, Juergen Schoenwaelder wrote: > On Fri, Feb 22, 2013 at 02:51:15PM +0100, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> >>> Perhaps the spec is ambiguous, but I don't agree adding busy work for the YANG module writer is needed. The YANG compiler can easily figure out what to do based on the belongs-to-stmt. >> No one has suggested this. >> >>> I haven't read anything in this thread that would cause me to change any code. The spec supports both implementation plans IMO, and it will take a lot more than an errata to change it. >> There are three, not two, alternatives: 1. Require the module to list all submodules (current pyang behavior) 2. Recursively incorporate the contents from all submodules into the module (current yuma behavior) 3. Allow submodules that are not listed in the main module, but do not incorporate contents from non-listed submodules The spec is not crystal clear, but I think that only interpretation (3) above is supported by the spec. Specifically, this text makes (1) unsupported: Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to include other submodules belonging to the same module. > > I do not see why this text makes (1) unsupported. This text only puts > up a restriction that you can't include submodules that belong to > other modules, no? > >> And this text makes (2) unsupported: When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule. > > I think the text is ambiguous since it remains unclear what "made > available to the current submodule" means. > This is unfortunate. I think both (1) and (2) are useful, but (3) is mostly just confusing. > > My reading is that the current text is ambiguous (and apparently > implementors came to two different interpretatio> Links: ------ [1] mailto:andy@yumaworks.com --=_7fd9fa297d9d964ee9f73b6ba42cb5dd Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Can someone clarify why transitivity is considered so unaccept= able? I'm still learning about YANG and a clarification of this point would= really help.

On 22.02.2013 14:03, Juergen Schoenwaelder wrote:

On Fri, Feb 22, 2013 at 02:51:15PM +0100, Martin Bjorklund wrote:

Andy Bierman <andy@yumaworks.com> wrote:

Perhaps the spec is ambiguous, but I =
don't agree adding busy work for the YANG module writer is needed. The YANG=
 compiler can easily figure out what to do based on the belongs-to-stmt.
No one has suggested this.

I haven't read anything in this threa=
d that would cause me to change any code. The spec supports both implementa=
tion plans IMO, and it will take a lot more than an errata to change it.
There are three, not two, alternatives: 1. Require the module to list all s=
ubmodules (current pyang behavior) 2. Recursively incorporate the contents =
from all submodules into the module (current yuma behavior) 3. Allow submod=
ules that are not listed in the main module, but do not incorporate content=
s from non-listed submodules The spec is not crystal clear, but I think tha=
t only interpretation (3) above is supported by the spec. Specifically, thi=
s text makes (1) unsupported: Modules are only allowed to include submodule=
s that belong to that module, as defined by the "belongs-to" statement (see=
 Section 7.2.2). Submodules are only allowed to include other submodules be=
longing to the same module.


I do not see why this text makes (1) unsupported. This text only puts
up a restriction that you can't include submodules that belong to
other modules, no?


And this text makes (2) unsupported: =
When a module includes a submodule, it incorporates the contents of the sub=
module into the node hierarchy of the module. When a submodule includes ano=
ther submodule, the target submodule's definitions are made available to th=
e current submodule.


I think the text is ambiguous since it remains unclear what "made
available to the current submodule" means.


This is unfortunate. I think both (1)=
 and (2) are useful, but (3) is mostly just confusing.


My reading is that the current text is ambiguous (and apparently
implementors came to two different interpretations). So we need to
decide what was/is desired and then fix things to avoid the ambiguity.

/js





 



--=_7fd9fa297d9d964ee9f73b6ba42cb5dd--


From mbj@tail-f.com  Fri Feb 22 06:10:39 2013
Return-Path: 
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 A08AF21F893F for ; Fri, 22 Feb 2013 06:10:39 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TicWHbmSbMYe for ; Fri, 22 Feb 2013 06:10:34 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1979321F873C for ; Fri, 22 Feb 2013 06:10:34 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C98A21200AF6; Fri, 22 Feb 2013 15:10:27 +0100 (CET)
Date: Fri, 22 Feb 2013 15:10:27 +0100 (CET)
Message-Id: <20130222.151027.440655736.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20130222140316.GA63273@elstar.local>
References:  <20130222.145115.368561051.mbj@tail-f.com> <20130222140316.GA63273@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:10:39 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Feb 22, 2013 at 02:51:15PM +0100, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> > > Perhaps the spec is ambiguous, but I don't agree adding busy work for
> > > the YANG module writer is needed.  The YANG compiler can easily
> > > figure out what to do based on the belongs-to-stmt.
> > 
> > No one has suggested this.
> > 
> > > I haven't read anything in this thread that would cause me to change any
> > > code.
> > > The spec supports both implementation plans IMO, and it will take a lot
> > > more than an errata to change it.
> > 
> > There are three, not two, alternatives:
> > 
> >   1.  Require the module to list all submodules (current pyang
> >       behavior)
> > 
> >   2.  Recursively incorporate the contents from all submodules into
> >       the module (current yuma behavior)
> > 
> >   3.  Allow submodules that are not listed in the main module, but do
> >       not incorporate contents from non-listed submodules
> > 
> > The spec is not crystal clear, but I think that only interpretation
> > (3) above is supported by the spec.
> > 
> > Specifically, this text makes (1) unsupported:
> > 
> >    Modules are only allowed to
> >    include submodules that belong to that module, as defined by the
> >    "belongs-to" statement (see Section 7.2.2).  Submodules are only
> >    allowed to include other submodules belonging to the same module.
> 
> I do not see why this text makes (1) unsupported. This text only puts
> up a restriction that you can't include submodules that belong to
> other modules, no?

You can interpret this text to allow a submodule A to include a
submodule B that has a "belongs-to M" statement.  But no other text
says that M MUST also include B.

> > And this text makes (2) unsupported:
> > 
> >    When a module includes a submodule, it incorporates the contents of
> >    the submodule into the node hierarchy of the module.  When a
> >    submodule includes another submodule, the target submodule's
> >    definitions are made available to the current submodule.
> 
> I think the text is ambiguous since it remains unclear what "made
> available to the current submodule" means.

Exactly the same words are used to describe "import".  When a
submodule uses "include" on a submodule it works like "import" on a
module.


/martin

From lhotka@nic.cz  Fri Feb 22 06:12:38 2013
Return-Path: 
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 305AD21F86F6 for ; Fri, 22 Feb 2013 06:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level: 
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.203,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 oc9RTIcjYTta for ; Fri, 22 Feb 2013 06:12:37 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6A21F86AB for ; Fri, 22 Feb 2013 06:12:37 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AFA8C13F9D2; Fri, 22 Feb 2013 15:12:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361542356; bh=bqv35VRz1M3Q6UfYqUf+Jc8Tlu/A7nwwYrISXtslxFU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Unf41jR5oBwYh/HWrCHB/nJM4KQLKpYNEFgZN2bbvaJKKXmPgV2HDY9DROstu6gsR /Jp3g27hdRFbc0bW6zpMFDZ+derL2fHfIoBr3qw9BHhKSac+8AYSxeK5r4CYh1qTqf pNqXF6CLaixIjLevwgClMgHDsptuv48TAkx8GZM0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20130222.145115.368561051.mbj@tail-f.com>
Date: Fri, 22 Feb 2013 15:12:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz>
References:  <20130222.120607.248909208.mbj@tail-f.com>  <20130222.145115.368561051.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:12:38 -0000

On Feb 22, 2013, at 2:51 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
>> Perhaps the spec is ambiguous, but I don't agree adding busy work for
>> the YANG module writer is needed.  The YANG compiler can easily
>> figure out what to do based on the belongs-to-stmt.
>=20
> No one has suggested this.
>=20
>> I haven't read anything in this thread that would cause me to change =
any
>> code.
>> The spec supports both implementation plans IMO, and it will take a =
lot
>> more than an errata to change it.
>=20
> There are three, not two, alternatives:
>=20
>  1.  Require the module to list all submodules (current pyang
>      behavior)
>=20
>  2.  Recursively incorporate the contents from all submodules into
>      the module (current yuma behavior)

I wonder what "all" means here. Are the submodules looked up in an =
implementation-dependent list of search directories, or in the entire =
universe?
=20
>=20
>  3.  Allow submodules that are not listed in the main module, but do
>      not incorporate contents from non-listed submodules
>=20
> The spec is not crystal clear, but I think that only interpretation
> (3) above is supported by the spec.
>=20
> Specifically, this text makes (1) unsupported:
>=20
>   Modules are only allowed to
>   include submodules that belong to that module, as defined by the
>   "belongs-to" statement (see Section 7.2.2).  Submodules are only
>   allowed to include other submodules belonging to the same module.
>=20
> And this text makes (2) unsupported:
>=20
>   When a module includes a submodule, it incorporates the contents of
>   the submodule into the node hierarchy of the module.  When a
>   submodule includes another submodule, the target submodule's
>   definitions are made available to the current submodule.
>=20
>=20
> This is unfortunate.  I think both (1) and (2) are useful, but (3) is
> mostly just confusing.

I am fine with (1), which however needs an update to RFC 6020.

I have strong objections against (2).

And I don't agree (3) is confusing. In C, if you don't include an =
existing header file, its content is missing. How this could be =
confusing or surprising? I actually think (3) can be occassionally =
useful, and it is essentially compatible with the current spec.

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

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





From mbj@tail-f.com  Fri Feb 22 06:17:26 2013
Return-Path: 
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 691CF21F8DF0 for ; Fri, 22 Feb 2013 06:17:26 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YZG9yT2qm4C for ; Fri, 22 Feb 2013 06:17:26 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9F21F8DDA for ; Fri, 22 Feb 2013 06:17:25 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 18BEA1200AF6; Fri, 22 Feb 2013 15:17:25 +0100 (CET)
Date: Fri, 22 Feb 2013 15:17:24 +0100 (CET)
Message-Id: <20130222.151724.456917633.mbj@tail-f.com>
To: Jonathan@hansfords.net
From: Martin Bjorklund 
In-Reply-To: 
References: <20130222.145115.368561051.mbj@tail-f.com> <20130222140316.GA63273@elstar.local> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:17:26 -0000

Jonathan Hansford  wrote:
>  
> 
> Can someone clarify why transitivity is considered so unacceptable?

As I wrote earlier, I think it could be useful.  But the text doesn't
support it, imo.

Pro: Lets a submodule designer be free to split the submodule into more
     submodules w/o touching the main module.

Con: When you look at the module, it is less obvious what is actually
     included; you need to follow all the pointers recursively to find
     out.

(and the current text needs some tweakings to allow this)


/martin

From jonathan@hansfords.net  Fri Feb 22 06:18:01 2013
Return-Path: 
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 25DC521F8F35 for ; Fri, 22 Feb 2013 06:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Level: 
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
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 5xb7S+1Ikyzt for ; Fri, 22 Feb 2013 06:18:00 -0800 (PST)
Received: from avasout03.plus.net (avasout03.plus.net [84.93.230.244]) by ietfa.amsl.com (Postfix) with ESMTP id EF3C821F8F34 for ; Fri, 22 Feb 2013 06:17:59 -0800 (PST)
Received: from webmail.plus.net ([84.93.228.147]) by avasout03 with smtp id 3SHz1l0083BT6uC01SHzDH; Fri, 22 Feb 2013 14:17:59 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.0 cv=Df3JXIRW c=1 sm=1 a=jSQgp9IWXRf89EXR5FPwJg==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=u07AKapRAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=WjfS9EJ_deIWHDjS3I8A:9 a=QEXdDO2ut3YA:10 a=XqebBV1NYWwA:10 a=ChEcuLpljosA:10 a=wp5rPLkunvAL16zUbLUA:9 a=_W_S_7VecoQA:10 a=lZB815dzVvQA:10 a=lCU6Wq_3XgmRBoVn:21 a=jSQgp9IWXRf89EXR5FPwJg==:117
X-AUTH: hansfords+us:2500
Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 22 Feb 2013 14:17:59 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_922efe7fee507bd0ca2b48c72e58af42"
Date: Fri, 22 Feb 2013 14:17:59 +0000
From: Jonathan Hansford 
To: 
In-Reply-To: <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz>
References:  <20130222.120607.248909208.mbj@tail-f.com>  <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz>
Message-ID: <80ed09a642c220a49e399599e627442a@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.2
X-Originating-IP: [81.136.210.13]
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:18:01 -0000

--=_922efe7fee507bd0ca2b48c72e58af42
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=UTF-8

 

On 22.02.2013 14:12, Ladislav Lhotka wrote: 

> On Feb 22, 2013, at
2:51 PM, Martin Bjorklund  wrote:
> 
>> Andy Bierman
 wrote: 
>> 
>>> Perhaps the spec is ambiguous,
but I don't agree adding busy work for the YANG module writer is needed.
The YANG compiler can easily figure out what to do based on the
belongs-to-stmt.
>> No one has suggested this. 
>> 
>>> I haven't read
anything in this thread that would cause me to change any code. The spec
supports both implementation plans IMO, and it will take a lot more than
an errata to change it.
>> There are three, not two, alternatives: 1.
Require the module to list all submodules (current pyang behavior) 2.
Recursively incorporate the contents from all submodules into the module
(current yuma behavior)
> 
> I wonder what "all" means here. Are the
submodules looked up in an implementation-dependent list of search
directories, or in the entire universe?

Surely "all" means all directly
or indirectly included submodules. Just writing a YANG submodule with a
"belongs-to" shouldn't make it part of the module unless the module or
an included submodule includes it.

Jonathan

>> 3. Allow submodules
that are not listed in the main module, but do not incorporate contents
from non-listed submodules The spec is not crystal clear, but I think
that only interpretation (3) above is supported by the spec.
Specifically, this text makes (1) unsupported: Modules are only allowed
to include submodules that belong to that module, as defined by the
"belongs-to" statement (see Section 7.2.2). Submodules are only allowed
to include other submodules belonging to the same module. And this text
makes (2) unsupported: When a module includes a submodule, it
incorporates the contents of the submodule into the node hierarchy of
the module. When a submodule includes another submodule, the target
submodule's definitions are made available to the current submodule.
This is unfortunate. I think both (1) and (2) are useful, but (3) is
mostly just confusing.
> 
> I am fine with (1), which however needs an
update to RFC 6020.
> 
> I have strong objections against (2).
> 
> And
I don't agree (3) is confusing. In C, if you don't include an existing
header file, its content is missing. How this could be confusing or
surprising? I actually think (3) can be occassionally useful, and it is
essentially compatible with the current spec.
> 
> Lada
> 
>> /martin
>

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




Links:
------
[1] mailto:andy@yumaworks.com

--=_922efe7fee507bd0ca2b48c72e58af42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8




 


On 22.02.2013 14:12, Ladislav Lhotka wrote:




On Feb 22, 2013, at 2:51 PM, Martin Bjorklund <mbj@tail-f.com> wrote:


Andy Bierman <andy@yumaworks.com> wrote:

Perhaps the spec is ambiguous, but I =
don't agree adding busy work for the YANG module writer is needed. The YANG=
 compiler can easily figure out what to do based on the belongs-to-stmt.
No one has suggested this.

I haven't read anything in this threa=
d that would cause me to change any code. The spec supports both implementa=
tion plans IMO, and it will take a lot more than an errata to change it.
There are three, not two, alternatives: 1. Require the module to list all s=
ubmodules (current pyang behavior) 2. Recursively incorporate the contents =
from all submodules into the module (current yuma behavior)


I wonder what "all" means here. Are the submodules looked up in an imp=
lementation-dependent list of search directories, or in the entire universe=
?


 




Surely "all" means all directly or indirectly included submodules. Jus=
t writing a YANG submodule with a "belongs-to" shouldn't make it part of th=
e module unless the module or an included submodule includes it.


 


Jonathan




3. Allow submodules that are not list=
ed in the main module, but do not incorporate contents from non-listed subm=
odules The spec is not crystal clear, but I think that only interpretation =
(3) above is supported by the spec. Specifically, this text makes (1) unsup=
ported: Modules are only allowed to include submodules that belong to that =
module, as defined by the "belongs-to" statement (see Section 7.2.2). Submo=
dules are only allowed to include other submodules belonging to the same mo=
dule. And this text makes (2) unsupported: When a module includes a submodu=
le, it incorporates the contents of the submodule into the node hierarchy o=
f the module. When a submodule includes another submodule, the target submo=
dule's definitions are made available to the current submodule. This is unf=
ortunate. I think both (1) and (2) are useful, but (3) is mostly just confu=
sing.


I am fine with (1), which however needs an update to RFC 6020.

I have strong objections against (2).

And I don't agree (3) is confusing. In C, if you don't include an existing =
header file, its content is missing. How this could be confusing or surpris=
ing? I actually think (3) can be occassionally useful, and it is essentiall=
y compatible with the current spec.

Lada


/martin


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




_______________________________________________
netmod mailing list
netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod




 



--=_922efe7fee507bd0ca2b48c72e58af42--


From andy@yumaworks.com  Fri Feb 22 06:21:57 2013
Return-Path: 
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 6E72121F8E7B for ; Fri, 22 Feb 2013 06:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Level: 
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
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 4H30BgQmQz0u for ; Fri, 22 Feb 2013 06:21:56 -0800 (PST)
Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A3DA521F8E71 for ; Fri, 22 Feb 2013 06:21:56 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id c11so744044ieb.29 for ; Fri, 22 Feb 2013 06:21:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=3yV0RoTF39iEpnbvVSERYJbZTKuA2s3pDP7q/HocqjM=; b=fQ+8JzJV+xE9kyBdBWcNZP/yDd4LhOZn3oOdQLgR7g2yPY24WDEG8w0yix7mPH52Zd xyaiJKIE8Qly1BH0j58RyMaK4YYc+zLuWSq4yJ+rdvpoorODOZ6EwOOIIezaru5Rl98c VJEIYXz/qpFq9GrE5F9mwKDjthbiw//vLaYmp0ZTr3EJaAUKaiPbCAeL1XEQa5Mmvk4C +Z0i9Ok7ONzRkLhq/VR92s1efO3IKFxtIAZTQ6SuT+Hu0WNGgtcLkA7Yxx+lIuKNksdY ImarFyOEhql1Mpm/Z/j1YK5sMJ08D4DdBCwZrDdIA/r4HUE6ekYpi17+eYlMsKU2Uwvb HQhA==
MIME-Version: 1.0
X-Received: by 10.50.208.40 with SMTP id mb8mr8317732igc.91.1361542916105; Fri, 22 Feb 2013 06:21:56 -0800 (PST)
Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 06:21:55 -0800 (PST)
In-Reply-To: <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz>
References:  <20130222.120607.248909208.mbj@tail-f.com>  <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz>
Date: Fri, 22 Feb 2013 06:21:55 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=14dae9340345dc67b904d650e9ed
X-Gm-Message-State: ALoCoQnOUfclzbWpVMK4ZrlEdpw7m17+ZerVkiX/XtuqUjXNAHeV6X+5AU6pHzxXpsl/+Z1eFSjh
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:21:57 -0000

--14dae9340345dc67b904d650e9ed
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 22, 2013 at 6:12 AM, Ladislav Lhotka  wrote:

>
> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund  wrote:
>
> > Andy Bierman  wrote:
> >> Perhaps the spec is ambiguous, but I don't agree adding busy work for
> >> the YANG module writer is needed.  The YANG compiler can easily
> >> figure out what to do based on the belongs-to-stmt.
> >
> > No one has suggested this.
> >
> >> I haven't read anything in this thread that would cause me to change any
> >> code.
> >> The spec supports both implementation plans IMO, and it will take a lot
> >> more than an errata to change it.
> >
> > There are three, not two, alternatives:
> >
> >  1.  Require the module to list all submodules (current pyang
> >      behavior)
> >
> >  2.  Recursively incorporate the contents from all submodules into
> >      the module (current yuma behavior)
>
> I wonder what "all" means here. Are the submodules looked up in an
> implementation-dependent list of search directories, or in the entire
> universe?
>

What does this have to do with the problem?
Finding submod-C is no different whether the include-stmt is
in the main module or a submodule.

I like the C language definition of #include and this it works fine
for YANG -- if A includes B and B includes C then the definitions
from C are available to A.  You could never refactor code if you
had to change all the upstream code to add new #include statements.
I don't understand your strong objections.  Why is this a bug and
not a feature?


Andy


> >
> >  3.  Allow submodules that are not listed in the main module, but do
> >      not incorporate contents from non-listed submodules
> >
> > The spec is not crystal clear, but I think that only interpretation
> > (3) above is supported by the spec.
> >
> > Specifically, this text makes (1) unsupported:
> >
> >   Modules are only allowed to
> >   include submodules that belong to that module, as defined by the
> >   "belongs-to" statement (see Section 7.2.2).  Submodules are only
> >   allowed to include other submodules belonging to the same module.
> >
> > And this text makes (2) unsupported:
> >
> >   When a module includes a submodule, it incorporates the contents of
> >   the submodule into the node hierarchy of the module.  When a
> >   submodule includes another submodule, the target submodule's
> >   definitions are made available to the current submodule.
> >
> >
> > This is unfortunate.  I think both (1) and (2) are useful, but (3) is
> > mostly just confusing.
>
> I am fine with (1), which however needs an update to RFC 6020.
>
> I have strong objections against (2).
>
> And I don't agree (3) is confusing. In C, if you don't include an existing
> header file, its content is missing. How this could be confusing or
> surprising? I actually think (3) can be occassionally useful, and it is
> essentially compatible with the current spec.
>
> Lada
>
> >
> >
> > /martin
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--14dae9340345dc67b904d650e9ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Fri, Feb 22, 2013 at 6:12 AM, Ladisla=
v Lhotka <lhotka@nic.cz> wrote:
mbj@tail-f.com> wrote:



> Andy Bierman <andy@yumaworks.=
com> wrote:

>> Perhaps the spec is ambiguous, but I don't agree adding busy w=
ork for

>> the YANG module writer is needed. =C2=A0The YANG compiler can easi=
ly

>> figure out what to do based on the belongs-to-stmt.

>

> No one has suggested this.

>

>> I haven't read anything in this thread that would cause me to =
change any

>> code.

>> The spec supports both implementation plans IMO, and it will take =
a lot

>> more than an errata to change it.

>

> There are three, not two, alternatives:

>

> =C2=A01. =C2=A0Require the module to list all submodules (current pyan=
g

> =C2=A0 =C2=A0 =C2=A0behavior)

>

> =C2=A02. =C2=A0Recursively incorporate the contents from all submodule=
s into

> =C2=A0 =C2=A0 =C2=A0the module (current yuma behavior)



I wonder what "all" means here. Are the submodules looked up in a=
n implementation-dependent list of search directories, or in the entire uni=
verse?

What does this have to do with t=
he problem?


Finding submod-C is no different whether the include-stmt is
in the main module or a submodule.

I like the C l=
anguage definition of #include and this it works fine
for YANG --=
 if A includes B and B includes C then the definitions


from C are available to A. =C2=A0You could never refactor code if you<=
/div>
had to change all the upstream code to add new #include statement=
s.
I don't understand your strong objections. =C2=A0Why is th=
is a bug and


not a feature?


Andy
=




>

> =C2=A03. =C2=A0Allow submodules that are not listed in the main module=
, but do

> =C2=A0 =C2=A0 =C2=A0not incorporate contents from non-listed submodule=
s

>

> The spec is not crystal clear, but I think that only interpretation
> (3) above is supported by the spec.

>

> Specifically, this text makes (1) unsupported:

>

> =C2=A0 Modules are only allowed to

> =C2=A0 include submodules that belong to that module, as defined by th=
e

> =C2=A0 "belongs-to" statement (see Section 7.2.2). =C2=A0Sub=
modules are only

> =C2=A0 allowed to include other submodules belonging to the same modul=
e.

>

> And this text makes (2) unsupported:

>

> =C2=A0 When a module includes a submodule, it incorporates the content=
s of

> =C2=A0 the submodule into the node hierarchy of the module. =C2=A0When=
 a

> =C2=A0 submodule includes another submodule, the target submodule'=
s

> =C2=A0 definitions are made available to the current submodule.

>

>

> This is unfortunate. =C2=A0I think both (1) and (2) are useful, but (3=
) is

> mostly just confusing.



I am fine with (1), which however needs an update to RFC 6020.



I have strong objections against (2).



And I don't agree (3) is confusing. In C, if you don't include an e=
xisting header file, its content is missing. How this could be confusing or=
 surprising? I actually think (3) can be occassionally useful, and it is es=
sentially compatible with the current spec.




Lada



>

>

> /martin



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--14dae9340345dc67b904d650e9ed--

From lhotka@nic.cz  Fri Feb 22 06:24:44 2013
Return-Path: 
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 5A7D421F8472 for ; Fri, 22 Feb 2013 06:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.803
X-Spam-Level: 
X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.196,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 N6hoJVhq5KnO for ; Fri, 22 Feb 2013 06:24:41 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEDF21F8EC1 for ; Fri, 22 Feb 2013 06:24:37 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9791713F9D2; Fri, 22 Feb 2013 15:24:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361543076; bh=qB8uk3wGHgOdGmToH7CM3Y/33RcKZNFTilVHgaRdsNA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eKEil6gXVdvtWavQfj7m0fOy5ouF8rG7ATWrwoCye0h5BXCb5qS0AisfE2Q69zPEa QR0h8CaTOfyGoFkybVmOIzsn99+cIAMtnlE4ByPNR5/cfhVKFRjAcO06uyMXxML9NR ZkJ5sOSCmPOfmyqhZspOCEX/U+awPGpWDV8BKWLU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <80ed09a642c220a49e399599e627442a@imap.plus.net>
Date: Fri, 22 Feb 2013 15:24:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz>
References:  <20130222.120607.248909208.mbj@tail-f.com>  <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz> <80ed09a642c220a49e399599e627442a@imap.plus.net>
To: Jonathan Hansford 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:24:44 -0000

On Feb 22, 2013, at 3:17 PM, Jonathan Hansford  =
wrote:

> =20
> On 22.02.2013 14:12, Ladislav Lhotka wrote:
>=20
>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund  wrote:
>>> Andy Bierman  wrote:
>>>> Perhaps the spec is ambiguous, but I don't agree adding busy work =
for the YANG module writer is needed. The YANG compiler can easily =
figure out what to do based on the belongs-to-stmt.
>>> No one has suggested this.
>>>> I haven't read anything in this thread that would cause me to =
change any code. The spec supports both implementation plans IMO, and it =
will take a lot more than an errata to change it.
>>> There are three, not two, alternatives: 1. Require the module to =
list all submodules (current pyang behavior) 2. Recursively incorporate =
the contents from all submodules into the module (current yuma behavior)
>> I wonder what "all" means here. Are the submodules looked up in an =
implementation-dependent list of search directories, or in the entire =
universe?
>> =20
> Surely "all" means all directly or indirectly included submodules. =
Just writing a YANG submodule with a "belongs-to" shouldn't make it part =
of the module unless the module or an included submodule includes it.

I may have misunderstood Andy, but he wrote that it is the "belongs-to" =
statement that incorporates the contents of a submodule into the main =
module.

Lada
=20
> =20
> Jonathan
>>> 3. Allow submodules that are not listed in the main module, but do =
not incorporate contents from non-listed submodules The spec is not =
crystal clear, but I think that only interpretation (3) above is =
supported by the spec. Specifically, this text makes (1) unsupported: =
Modules are only allowed to include submodules that belong to that =
module, as defined by the "belongs-to" statement (see Section 7.2.2). =
Submodules are only allowed to include other submodules belonging to the =
same module. And this text makes (2) unsupported: When a module includes =
a submodule, it incorporates the contents of the submodule into the node =
hierarchy of the module. When a submodule includes another submodule, =
the target submodule's definitions are made available to the current =
submodule. This is unfortunate. I think both (1) and (2) are useful, but =
(3) is mostly just confusing.
>> I am fine with (1), which however needs an update to RFC 6020.
>>=20
>> I have strong objections against (2).
>>=20
>> And I don't agree (3) is confusing. In C, if you don't include an =
existing header file, its content is missing. How this could be =
confusing or surprising? I actually think (3) can be occassionally =
useful, and it is essentially compatible with the current spec.
>>=20
>> Lada
>>=20
>>> /martin
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>>=20
>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> =20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From andy@yumaworks.com  Fri Feb 22 06:35:18 2013
Return-Path: 
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 88F8621F8E36 for ; Fri, 22 Feb 2013 06:35:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.459
X-Spam-Level: 
X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
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 BoGENq0OHkU9 for ; Fri, 22 Feb 2013 06:35:17 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AD45121F8E33 for ; Fri, 22 Feb 2013 06:35:17 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id 13so751865iea.14 for ; Fri, 22 Feb 2013 06:35:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=QWYkmYBsudI+Jw0n97jfrJYhoJ+0xfnPgxS/ifWMgnk=; b=YejWvkfK0TD779ZabmGGH8j7qwZMQLytDftQD2SWjxnlwt6+9H8hbMYsPPA2UDvcuo Jgt9NImIgzHCj4Pvu0hBnrVjfGI6Y37aRGLpAQrpNmk0JsL8pEIuqmI4nYmluYlhSWS4 EBGtppI4V5PTdjrULaCRKwPHm18KXlRR9POP5z0FWjNmmR6Rl5eO1AWm5u8ztBwV8qUm sIu1FfPiyhpONoI4+vYzxg0WbvTNHM6LTF/4pqYI6HiyPlTkdF3dNtHiGqQVhSNIaCW+ aAEw/ihCx4w1BpEW5v7Uwx8iEKbw+jj4XMQXKBef/YCODl2VWgwlN1/SIVRt8qrvwAjY C0iA==
MIME-Version: 1.0
X-Received: by 10.50.183.167 with SMTP id en7mr14977972igc.58.1361543717116; Fri, 22 Feb 2013 06:35:17 -0800 (PST)
Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 06:35:16 -0800 (PST)
In-Reply-To: <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz>
References:  <20130222.120607.248909208.mbj@tail-f.com>  <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz> <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz>
Date: Fri, 22 Feb 2013 06:35:16 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=14dae9340ca39adbdc04d65119c4
X-Gm-Message-State: ALoCoQlPtiYl7zW4z3HAlgihGP8CtcIIApTVBEzRmWooqz6Q2BvMSbT80ArkwQN7fmas+qnmD32W
Cc: netmod@ietf.org
Subject: Re: [netmod] include
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Feb 2013 14:35:18 -0000

--14dae9340ca39adbdc04d65119c4
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka  wrote:

>
> On Feb 22, 2013, at 3:17 PM, Jonathan Hansford 
> wrote:
>
> >
> > On 22.02.2013 14:12, Ladislav Lhotka wrote:
> >
> >> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund  wrote:
> >>> Andy Bierman  wrote:
> >>>> Perhaps the spec is ambiguous, but I don't agree adding busy work for
> the YANG module writer is needed. The YANG compiler can easily figure out
> what to do based on the belongs-to-stmt.
> >>> No one has suggested this.
> >>>> I haven't read anything in this thread that would cause me to change
> any code. The spec supports both implementation plans IMO, and it will take
> a lot more than an errata to change it.
> >>> There are three, not two, alternatives: 1. Require the module to list
> all submodules (current pyang behavior) 2. Recursively incorporate the
> contents from all submodules into the module (current yuma behavior)
> >> I wonder what "all" means here. Are the submodules looked up in an
> implementation-dependent list of search directories, or in the entire
> universe?
> >>
> > Surely "all" means all directly or indirectly included submodules. Just
> writing a YANG submodule with a "belongs-to" shouldn't make it part of the
> module unless the module o an included submodule includes it.
>
> I may have misunderstood Andy, but he wrote that it is the "belongs-to"
> statement that incorporates the contents of a submodule into the main
> module.



I am not suggesting that submodules that are not included in any way are
part of
the module. They are just bugs.  Obviously a YANG compiler cannot guess that
unmentioned submodules exist somewhere.  But anytime the compiler encounters
an include or import, it has to process it.

It is up to the developer to decide if the submodule organization is an
unmanageable mess
or a work or art.  Since a module does not need to list all the nested
imports that will
occur (mod A imports B which imports C -- mod A doesn't need to say
anything about C),
I don't agree this is needed for submodules either.


> Lada
>
>
Andy


>
> > Jonathan
> >>> 3. Allow submodules that are not listed in the main module, but do not
> incorporate contents from non-listed submodules The spec is not crystal
> clear, but I think that only interpretation (3) above is supported by the
> spec. Specifically, this text makes (1) unsupported: Modules are only
> allowed to include submodules that belong to that module, as defined by the
> "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to
> include other submodules belonging to the same module. And this text makes
> (2) unsupported: When a module includes a submodule, it incorporates the
> contents of the submodule into the node hierarchy of the module. When a
> submodule includes another submodule, the target submodule's definitions
> are made available to the current submodule. This is unfortunate. I think
> both (1) and (2) are useful, but (3) is mostly just confusing.
> >> I am fine with (1), which however needs an update to RFC 6020.
> >>
> >> I have strong objections against (2).
> >>
> >> And I don't agree (3) is confusing. In C, if you don't include an
> existing header file, its content is missing. How this could be confusing
> or surprising? I actually think (3) can be occassionally useful, and it is
> essentially compatible with the current spec.
> >>
> >> Lada
> >>
> >>> /martin
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >>
> >> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--14dae9340ca39adbdc04d65119c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Fri, Feb 22, 2013 at 6:24 AM, Ladisla=
v Lhotka <lhotka@nic.cz> wrote:
Jonathan@hansfords.net> wrote:



>

> On 22.02.2013 14:12, Ladislav Lhotka wrote:

>

>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

>>> Andy Bierman <andy@yu=
maworks.com> wrote:

>>>> Perhaps the spec is ambiguous, but I don't agree addin=
g busy work for the YANG module writer is needed. The YANG compiler can eas=
ily figure out what to do based on the belongs-to-stmt.

>>> No one has suggested this.

>>>> I haven't read anything in this thread that would caus=
e me to change any code. The spec supports both implementation plans IMO, a=
nd it will take a lot more than an errata to change it.

>>> There are three, not two, alternatives: 1. Require the module =
to list all submodules (current pyang behavior) 2. Recursively incorporate =
the contents from all submodules into the module (current yuma behavior)

>> I wonder what "all" means here. Are the submodules looke=
d up in an implementation-dependent list of search directories, or in the e=
ntire universe?

>>

> Surely "all" means all directly or indirectly included submo=
dules. Just writing a YANG submodule with a "belongs-to" shouldn&=
#39;t make it part of the module unless the module o an included submodule =
includes it.




I may have misunderstood Andy, but he wrote that it is the "belongs-to=
" statement that incorporates the contents of a submodule into the mai=
n module.
=C2=A0

I am not suggest=
ing that submodules that are not included in any way are part of


the module. They are just bugs. =C2=A0Obviously a YANG compiler cannot=
 guess that
unmentioned submodules exist somewhere. =C2=A0But any=
time the compiler encounters
an include or import, it has to proc=
ess it.



It is up to the developer to decide if the submodule or=
ganization is an unmanageable mess
or a work or art. =C2=A0Since =
a module does not need to list all the nested imports that will
o=
ccur (mod A imports B which imports C -- mod A doesn't need to say anyt=
hing about C),


I don't agree this is needed for submodules either. =C2=A0




Lada



Andy
=C2=A0


> Jonathan

>>> 3. Allow submodules that are not listed in the main module, bu=
t do not incorporate contents from non-listed submodules The spec is not cr=
ystal clear, but I think that only interpretation (3) above is supported by=
 the spec. Specifically, this text makes (1) unsupported: Modules are only =
allowed to include submodules that belong to that module, as defined by the=
 "belongs-to" statement (see Section 7.2.2). Submodules are only =
allowed to include other submodules belonging to the same module. And this =
text makes (2) unsupported: When a module includes a submodule, it incorpor=
ates the contents of the submodule into the node hierarchy of the module. W=
hen a submodule includes another submodule, the target submodule's defi=
nitions are made available to the current submodule. This is unfortunate. I=
 think both (1) and (2) are useful, but (3) is mostly just confusing.


>> I am fine with (1), which however needs an update to RFC 6020.

>>

>> I have strong objections against (2).

>>

>> And I don't agree (3) is confusing. In C, if you don't inc=
lude an existing header file, its content is missing. How this could be con=
fusing or surprising? I actually think (3) can be occassionally useful, and=
 it is essentially compatible with the current spec.


>>

>> Lada

>>

>>> /martin

>> --

>> Ladislav Lhotka, CZ.NIC Labs

>> PGP Key ID: E74E8C0C

>>

>>

>>

>>

>> _______________________________________________

>> netmod mailing list

>>

>> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod

--14dae9340ca39adbdc04d65119c4-- From mbj@tail-f.com Fri Feb 22 06:43:03 2013 Return-Path: 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 F36D321F8F34 for ; Fri, 22 Feb 2013 06:43:02 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6+97TcZ9uYL for ; Fri, 22 Feb 2013 06:43:02 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BCD8221F8F23 for ; Fri, 22 Feb 2013 06:43:01 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B97CC1200AF6; Fri, 22 Feb 2013 15:43:00 +0100 (CET) Date: Fri, 22 Feb 2013 15:43:00 +0100 (CET) Message-Id: <20130222.154300.306593673.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:43:03 -0000 Andy Bierman wrote: > Since a module does not need to list all the nested > imports that will > occur (mod A imports B which imports C -- mod A doesn't need to say > anything about C), Huh? module A { ... import B { prefix b; } leaf foo { type c:bar; // do you think this is legal? } } module B { ... import C { prefix c; } } module C { ... typedef bar { ... } } I would say that the example above is illegal, and why would include work differently? /martin From lhotka@nic.cz Fri Feb 22 06:50:25 2013 Return-Path: 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 12C5221F8F44 for ; Fri, 22 Feb 2013 06:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 WxEDZeRnpymV for ; Fri, 22 Feb 2013 06:50:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7D421F8F51 for ; Fri, 22 Feb 2013 06:50:18 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6006013F9D2; Fri, 22 Feb 2013 15:50:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361544617; bh=67f/sMjEpkdjNbg6tBYrd05hwetDuI0XFQ4hnOL5zQY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UeF1p5j3i56EKIx478bAwHKWqbAmgEkisa4ELp6S9CRuUKvwPw0YV/ZEOdwSBYXXv KXpAm0/d56dQql4UWFw1YaXwfB9kZmsrNG+CcVXVTEe2i3c/GFWM5El141KlRotDsL snRoGxndScS8avuKQsLYvF1YV5lArLAi+NO9UMos= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 15:50:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> References: <20130222.120607.248909208.mbj@tail-f.com> <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz> <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:50:25 -0000 On Feb 22, 2013, at 3:35 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka = wrote: >=20 > On Feb 22, 2013, at 3:17 PM, Jonathan Hansford = wrote: >=20 > > > > On 22.02.2013 14:12, Ladislav Lhotka wrote: > > > >> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund = wrote: > >>> Andy Bierman wrote: > >>>> Perhaps the spec is ambiguous, but I don't agree adding busy work = for the YANG module writer is needed. The YANG compiler can easily = figure out what to do based on the belongs-to-stmt. > >>> No one has suggested this. > >>>> I haven't read anything in this thread that would cause me to = change any code. The spec supports both implementation plans IMO, and it = will take a lot more than an errata to change it. > >>> There are three, not two, alternatives: 1. Require the module to = list all submodules (current pyang behavior) 2. Recursively incorporate = the contents from all submodules into the module (current yuma behavior) > >> I wonder what "all" means here. Are the submodules looked up in an = implementation-dependent list of search directories, or in the entire = universe? > >> > > Surely "all" means all directly or indirectly included submodules. = Just writing a YANG submodule with a "belongs-to" shouldn't make it part = of the module unless the module o an included submodule includes it. >=20 > I may have misunderstood Andy, but he wrote that it is the = "belongs-to" statement that incorporates the contents of a submodule = into the main module. > =20 >=20 > I am not suggesting that submodules that are not included in any way = are part of > the module. They are just bugs. Obviously a YANG compiler cannot = guess that > unmentioned submodules exist somewhere. But anytime the compiler = encounters > an include or import, it has to process it. OK, so it was indeed a misunderstanding. >=20 > It is up to the developer to decide if the submodule organization is = an unmanageable mess > or a work or art. Since a module does not need to list all the nested = imports that will > occur (mod A imports B which imports C -- mod A doesn't need to say = anything about C), > I don't agree this is needed for submodules either. I now have an impression that the concept of submodules is unnecessarily = complicated, perhaps it could work simply as #include in cpp, i. e. the = text of a module would be constructed by applying recursively all = includes. Then submodules could also directly refer to definitions in = the main module.=20 Lada > =20 >=20 >=20 > Lada >=20 >=20 > Andy > =20 >=20 > > Jonathan > >>> 3. Allow submodules that are not listed in the main module, but do = not incorporate contents from non-listed submodules The spec is not = crystal clear, but I think that only interpretation (3) above is = supported by the spec. Specifically, this text makes (1) unsupported: = Modules are only allowed to include submodules that belong to that = module, as defined by the "belongs-to" statement (see Section 7.2.2). = Submodules are only allowed to include other submodules belonging to the = same module. And this text makes (2) unsupported: When a module includes = a submodule, it incorporates the contents of the submodule into the node = hierarchy of the module. When a submodule includes another submodule, = the target submodule's definitions are made available to the current = submodule. This is unfortunate. I think both (1) and (2) are useful, but = (3) is mostly just confusing. > >> I am fine with (1), which however needs an update to RFC 6020. > >> > >> I have strong objections against (2). > >> > >> And I don't agree (3) is confusing. In C, if you don't include an = existing header file, its content is missing. How this could be = confusing or surprising? I actually think (3) can be occassionally = useful, and it is essentially compatible with the current spec. > >> > >> Lada > >> > >>> /martin > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> > >> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Feb 22 06:55:28 2013 Return-Path: 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 E319221F867D for ; Fri, 22 Feb 2013 06:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 zKLCcv-VLbU4 for ; Fri, 22 Feb 2013 06:55:28 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 56F6621F8510 for ; Fri, 22 Feb 2013 06:55:28 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so611317iaf.28 for ; Fri, 22 Feb 2013 06:55:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=YFl/AKwo5x1Z03ZJOwdj41j6FHZdQL+8Fn3QRkCwORg=; b=B3Z5WA1YWGgmZZ1CP31yJfiUZPuExTDmQL0sAanf1JQDd7Ch+9D60Qhp1omjK1mlTM Yd/5mD6s2hMN2vin3GKmrNF9GhxrXGY0+k0i9Xd6bG3FzgsEACvz9iFQv5OrXiTTCwo6 BFSQavSbi7yv3WuIj3Qw9vOqDl8LBkkUW/EA7ydd3DhNJcNHyrDAYOto0W8zauW5eyn+ iEENNpHEy4zc/1/Lox+Dt2NGX1V389ADvBBtumx235QLl1w2OTXXQz90zKQNnkrHn+qD GUdKv//R+C+Rbt87XLIoC+dqBgjNv7L/qxSsVqlJdnGOGKVqdG9q2MnnXI1ZBzysonl5 2vYQ== MIME-Version: 1.0 X-Received: by 10.50.196.132 with SMTP id im4mr1007937igc.58.1361544927935; Fri, 22 Feb 2013 06:55:27 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 06:55:27 -0800 (PST) In-Reply-To: <20130222.154300.306593673.mbj@tail-f.com> References: <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz> <20130222.154300.306593673.mbj@tail-f.com> Date: Fri, 22 Feb 2013 06:55:27 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae9340b63c67c3204d651618a X-Gm-Message-State: ALoCoQmZg2mZ4/wuISM+lPVSGxeOdRFG37B3IAHMa+o4KWUk9NQizeR4FNMyF939DWunr03SCrWT Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:55:29 -0000 --14dae9340b63c67c3204d651618a Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 6:43 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Since a module does not need to list all the nested > > imports that will > > occur (mod A imports B which imports C -- mod A doesn't need to say > > anything about C), > > Huh? > > module A { > ... > import B { > prefix b; > } > > leaf foo { > type c:bar; // do you think this is legal? > } > } > > module B { > ... > import C { > prefix c; > } > } > > module C { > ... > typedef bar { ... } > } > > > I would say that the example above is illegal, and why would include > work differently? > > This isn't what I said -- module B uses module C, not A. Obviously if module A uses something in C it needs to import it directly, but it will pick up any definitions from B that are using definitions from C. I think the text in question is ambiguous and open to misinterpretation, but let's stop with the strawman stuff. The issue is whether definitions from nested submodules are visible to external modules or not. > /martin > Andy --14dae9340b63c67c3204d651618a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 6:43 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Since a module does not need to list all the nested
> imports that will
> occur (mod A imports B which imports C -- mod A doesn't need to sa= y
> anything about C),

Huh?

=C2=A0 module A {
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 import B {
=C2=A0 =C2=A0 =C2=A0 prefix b;
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 leaf foo {
=C2=A0 =C2=A0 =C2=A0 type c:bar; =C2=A0// do you think this is legal?
=C2=A0 =C2=A0 }
=C2=A0 }

=C2=A0 module B {
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 import C {
=C2=A0 =C2=A0 =C2=A0 prefix c;
=C2=A0 =C2=A0 }
=C2=A0 }

=C2=A0 module C {
=C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 typedef bar { ... }
=C2=A0 }


I would say that the example above is illegal, and why would include
work differently?


This isn't what I said -- module B uses module C= , not A.
Obviously if module A uses something in C it needs to im= port it
directly, but it will pick up any definitions from B that are using
definitions from C.

I think the text in qu= estion is ambiguous and open to misinterpretation,
but let's = stop with the strawman stuff. =C2=A0The issue is whether
definitions from nested submodules are visible to external modules or = not.




/martin

Andy

--14dae9340b63c67c3204d651618a-- From jonathan@hansfords.net Fri Feb 22 06:55:31 2013 Return-Path: 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 A998E21F8510 for ; Fri, 22 Feb 2013 06:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 cke5Pfj3k7VU for ; Fri, 22 Feb 2013 06:55:29 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 68ADF21F86AB for ; Fri, 22 Feb 2013 06:55:28 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 3SvS1l0024CLSd801SvTo6; Fri, 22 Feb 2013 14:55:27 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=xskcdSivAAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=kF3tXtfOU2UEhcUaCUwA:9 a=QEXdDO2ut3YA:10 a=ChEcuLpljosA:10 a=1rgnPY4EEFsA:10 a=XqebBV1NYWwA:10 a=lZB815dzVvQA:10 a=UdlCCyTEvnIgT81B2icA:9 a=_W_S_7VecoQA:10 a=9LSCfJVO1wVORsW7:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 22 Feb 2013 14:55:26 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_e972e1f87cdf41072cb1d3d97a42bdf1" Date: Fri, 22 Feb 2013 14:55:26 +0000 From: Jonathan Hansford To: Ladislav Lhotka In-Reply-To: <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> References: <20130222.120607.248909208.mbj@tail-f.com> <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz> <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz> <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> Message-ID: <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:55:31 -0000 --=_e972e1f87cdf41072cb1d3d97a42bdf1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 22.02.2013 14:50, Ladislav Lhotka wrote: > On Feb 22, 2013, at 3:35 PM, Andy Bierman wrote: > >> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka wrote: On Feb 22, 2013, at 3:17 PM, Jonathan Hansford wrote: >> >>> On 22.02.2013 14:12, Ladislav Lhotka wrote: >>> >>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund wrote: >>>> >>>>> Andy Bierman wrote: >>>>> >>>>>> Perhaps the spec is ambiguous, but I don't agree adding busy work for the YANG module writer is needed. The YANG compiler can easily figure out what to do based on the belongs-to-stmt. >>>>> No one has suggested this. >>>>> >>>>>> I haven't read anything in this thread that would cause me to change any code. The spec supports both implementation plans IMO, and it will take a lot more than an errata to change it. >>>>> There are three, not two, alternatives: 1. Require the module to list all submodules (current pyang behavior) 2. Recursively incorporate the contents from all submodules into the module (current yuma behavior) >>>> I wonder what "all" means here. Are the submodules looked up in an implementation-dependent list of search directories, or in the entire universe? >>> Surely "all" means all directly or indirectly included submodules. Just writing a YANG submodule with a "belongs-to" shouldn't make it part of the module unless the module o an included submodule includes it. >> I may have misunderstood Andy, but he wrote that it is the "belongs-to" statement that incorporates the contents of a submodule into the main module. I am not suggesting that submodules that are not included in any way are part of the module. They are just bugs. Obviously a YANG compiler cannot guess that unmentioned submodules exist somewhere. But anytime the compiler encounters an include or import, it has to process it. > > OK, so it was indeed a misunderstanding. > >> It is up to the developer to decide if the submodule organization is an unmanageable mess or a work or art. Since a module does not need to list all the nested imports that will occur (mod A imports B which imports C -- mod A doesn't need to say anything about C), I don't agree this is needed for submodules either. > > I now have an impression that the concept of submodules is unnecessarily complicated, perhaps it could work simply as #include in cpp, i. e. the text of a module would be constructed by applying recursively all includes. Then submodules could also directly refer to definitions in the main module. Wouldn't that require the submodule to include the module, which is not allowed? Jonathan Lada >> Lada Andy >> >>> Jonathan >>> >>>>> 3. Allow submodules that are not listed in the main module, but do not incorporate contents from non-listed submodules The spec is not crystal clear, but I think that only interpretation (3) above is supported by the spec. Specifically, this text makes (1) unsupported: Modules are only allowed to include submodules that belong to that module, as defined by the "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to include other submodules belonging to the same module. And this text makes (2) unsupported: When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule. This is unfortunate. I think both (1) and (2) are useful, but (3) is mostly just confusing. >>>> I am fine with (1), which however needs an update to RFC 6020. I have strong objections against (2). And I don't agree (3) is confusing. In C, if you don't include an existing header file, its content is missing. How this could be confusing or surprising? I actually think (3) can be occassionally useful, and it is essentially compatible with the current spec. Lada >>>> >>>>> /martin >>>> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.orghttps: [5]//www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ netmod mailing list netmod@ietf.org [6]https://www.ietf.org/mailman/listinfo/netmod [7] >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org [8]https://www.ietf.org/mailman/listinfo/netmod [9] > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C Links: ------ [1] mailto:andy@yumaworks.com [2] mailto:mbj@tail-f.com [3] mailto:lhotka@nic.cz [4] mailto:Jonathan@hansfords.net [5] mailto:netmod@ietf.orghttps: [6] mailto:netmod@ietf.org [7] https://www.ietf.org/mailman/listinfo/netmod [8] mailto:netmod@ietf.org [9] https://www.ietf.org/mailman/listinfo/netmod --=_e972e1f87cdf41072cb1d3d97a42bdf1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 22.02.2013 14:50, Ladislav Lhotka wrote:

On Feb 22, 2013, at 3:35 PM, Andy Bierman <andy@yumaworks.com> wrote:
On Fri, Feb 22, 2013 at 6:24 AM, Ladi= slav Lhotka <lhotka@nic.cz> wrot= e: On Feb 22, 2013, at 3:17 PM, Jonathan Hansford <Jonathan@hansfords.net> wrote:
On 22.02.2013 14:12, Ladislav Lhotka = wrote:
On Feb 22, 2013, at 2:51 PM, Martin B= jorklund <mbj@tail-f.com> wrote= :
Andy Bierman <andy@yumaworks.com> wrote:
Perhaps the spec is ambiguous, but I = don't agree adding busy work for the YANG module writer is needed. The YANG= compiler can easily figure out what to do based on the belongs-to-stmt. No one has suggested this.
I haven't read anything in this threa= d that would cause me to change any code. The spec supports both implementa= tion plans IMO, and it will take a lot more than an errata to change it. There are three, not two, alternatives: 1. Require the module to list all s= ubmodules (current pyang behavior) 2. Recursively incorporate the contents = from all submodules into the module (current yuma behavior)
I wonder what "all" means here. Are the submodules looked up in an implemen= tation-dependent list of search directories, or in the entire universe? Surely "all" means all directly or indirectly included submodules. Just wri= ting a YANG submodule with a "belongs-to" shouldn't make it part of the mod= ule unless the module o an included submodule includes it.
I may have misunderstood Andy, but he wrote that it is the "belongs-to" sta= tement that incorporates the contents of a submodule into the main module= =2E I am not suggesting that submodules that are not included in any way ar= e part of the module. They are just bugs. Obviously a YANG compiler cannot = guess that unmentioned submodules exist somewhere. But anytime the compiler= encounters an include or import, it has to process it.
OK, so it was indeed a misunderstanding.
It is up to the developer to decide i= f the submodule organization is an unmanageable mess or a work or art. Sinc= e a module does not need to list all the nested imports that will occur (mo= d A imports B which imports C -- mod A doesn't need to say anything about C= ), I don't agree this is needed for submodules either.
I now have an impression that the concept of submodules is unnecessari=
ly complicated, perhaps it could work simply as #include in cpp, i. e. the =
text of a module would be constructed by applying recursively all includes=
=2E Then submodules could also directly refer to definitions in the main mo=
dule. 
 
Wouldn't that require the submodule to include the module, which is no=
t allowed?
 
Jonathan

Lada
Lada Andy
Jonathan
3. Allow submodules that are not list= ed in the main module, but do not incorporate contents from non-listed subm= odules The spec is not crystal clear, but I think that only interpretation = (3) above is supported by the spec. Specifically, this text makes (1) unsup= ported: Modules are only allowed to include submodules that belong to that = module, as defined by the "belongs-to" statement (see Section 7.2.2). Submo= dules are only allowed to include other submodules belonging to the same mo= dule. And this text makes (2) unsupported: When a module includes a submodu= le, it incorporates the contents of the submodule into the node hierarchy o= f the module. When a submodule includes another submodule, the target submo= dule's definitions are made available to the current submodule. This is unf= ortunate. I think both (1) and (2) are useful, but (3) is mostly just confu= sing.
I am fine with (1), which however needs an update to RFC 6020. I have stron= g objections against (2). And I don't agree (3) is confusing. In C, if you = don't include an existing header file, its content is missing. How this cou= ld be confusing or surprising? I actually think (3) can be occassionally us= eful, and it is essentially compatible with the current spec. Lada
/martin
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netm= od
_______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmo= d
-- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ______________________= _________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
 
--=_e972e1f87cdf41072cb1d3d97a42bdf1-- From lhotka@nic.cz Fri Feb 22 06:57:36 2013 Return-Path: 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 7FA4821F8ECC for ; Fri, 22 Feb 2013 06:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 VeLujLcZ9M24 for ; Fri, 22 Feb 2013 06:57:18 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF321F8510 for ; Fri, 22 Feb 2013 06:57:14 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D461113F9D2; Fri, 22 Feb 2013 15:57:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361545033; bh=mC+S1avMMJlp1U02GE8KRkGoGylGGLtBq+DjYLh04rs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XI2tJsE0kHc9y0A75J2VVSdMT5SawzpDBkGPBLKnZWQR4C1JJ4UoWN/8JIVeOgZt2 S6asKIsPEbinnOzj0dbtTnG5A2FOS8QHAOCvNvnUluokEdJhRRzqNCxOZTvZ1qaN4B I+RY9F1u66I3g6LlTuriZxZK45XSdY8yEn/vG1/A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130222.154300.306593673.mbj@tail-f.com> Date: Fri, 22 Feb 2013 15:57:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5BF1F921-A3F9-41B6-94C3-4927A9BF66FF@nic.cz> References: <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz> <20130222.154300.306593673.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:57:37 -0000 On Feb 22, 2013, at 3:43 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Since a module does not need to list all the nested >> imports that will >> occur (mod A imports B which imports C -- mod A doesn't need to say >> anything about C), >=20 > Huh? >=20 > module A { > ... > import B { > prefix b; > } >=20 > leaf foo { > type c:bar; // do you think this is legal? > } > } >=20 > module B { > ... > import C { > prefix c; > } > } >=20 > module C { > ... > typedef bar { ... } > } >=20 >=20 > I would say that the example above is illegal, and why would include > work differently? It is clearly illegal because there is no definition of the "c" prefix = in the context of module A. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Feb 22 07:13:34 2013 Return-Path: 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 243A021F8602 for ; Fri, 22 Feb 2013 07:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 rWnEM4voOOxc for ; Fri, 22 Feb 2013 07:13:33 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0774721F855F for ; Fri, 22 Feb 2013 07:13:33 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2B43613F9D2; Fri, 22 Feb 2013 16:13:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361546012; bh=c7KqxDUCiPNRsk+E+OlknXBLFXehL10pMmfjF9P1iOc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=P9FkSYnOVNHAhXibicMS/n2tWdt1PM0CPJ+JJ604K0fo/7u/u/Caouy4H+e0WT5Ut gxrWjl7HSrV8ZkjSslx9vj9FEd9U5AM7va7j1Kyy3mYKQnlTDZyFsfyfHppeLkY4n9 EQSDfyM8Qckc/cJC+WZs0mfaqb/JfTnDJlwxYgqE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> Date: Fri, 22 Feb 2013 16:13:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130222.120607.248909208.mbj@tail-f.com> <20130222.145115.368561051.mbj@tail-f.com> <3DAD4841-DDD2-4976-8BDE-E82A2ED4BB19@nic.cz> <80ed09a642c220a49e399599e627442a@imap.plus.net> <5FDC138F-C391-4CC6-AEAA-C5194D5DB0E5@nic.cz> <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> To: Jonathan Hansford X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:13:34 -0000 On Feb 22, 2013, at 3:55 PM, Jonathan Hansford = wrote: > =20 > On 22.02.2013 14:50, Ladislav Lhotka wrote: >=20 >> On Feb 22, 2013, at 3:35 PM, Andy Bierman wrote: >>> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka = wrote: On Feb 22, 2013, at 3:17 PM, Jonathan Hansford = wrote: >>>> On 22.02.2013 14:12, Ladislav Lhotka wrote: >>>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund = wrote: >>>>>> Andy Bierman wrote: >>>>>>> Perhaps the spec is ambiguous, but I don't agree adding busy = work for the YANG module writer is needed. The YANG compiler can easily = figure out what to do based on the belongs-to-stmt. >>>>>> No one has suggested this. >>>>>>> I haven't read anything in this thread that would cause me to = change any code. The spec supports both implementation plans IMO, and it = will take a lot more than an errata to change it. >>>>>> There are three, not two, alternatives: 1. Require the module to = list all submodules (current pyang behavior) 2. Recursively incorporate = the contents from all submodules into the module (current yuma behavior) >>>>> I wonder what "all" means here. Are the submodules looked up in an = implementation-dependent list of search directories, or in the entire = universe? >>>> Surely "all" means all directly or indirectly included submodules. = Just writing a YANG submodule with a "belongs-to" shouldn't make it part = of the module unless the module o an included submodule includes it. >>> I may have misunderstood Andy, but he wrote that it is the = "belongs-to" statement that incorporates the contents of a submodule = into the main module. I am not suggesting that submodules that are not = included in any way are part of the module. They are just bugs. = Obviously a YANG compiler cannot guess that unmentioned submodules exist = somewhere. But anytime the compiler encounters an include or import, it = has to process it. >> OK, so it was indeed a misunderstanding. >>> It is up to the developer to decide if the submodule organization is = an unmanageable mess or a work or art. Since a module does not need to = list all the nested imports that will occur (mod A imports B which = imports C -- mod A doesn't need to say anything about C), I don't agree = this is needed for submodules either. >> I now have an impression that the concept of submodules is = unnecessarily complicated, perhaps it could work simply as #include in = cpp, i. e. the text of a module would be constructed by applying = recursively all includes. Then submodules could also directly refer to = definitions in the main module.=20 >> =20 > Wouldn't that require the submodule to include the module, which is = not allowed? No. I mean that each include would be simply replaced by the contents of = the corresponding submodule (data nodes, rpcs, identities, features = etc., but obviously not metadata). If recursive includes were allowed, I = see no benefit of requiring the main module to include a submodule in = order to be able to use definitions from that submodule. Whenever namespace modularity is needed, modules and imports should be = used, and not submodules.=20 Lada > =20 > Jonathan >=20 > Lada >=20 >>> Lada Andy >>>> Jonathan >>>>>> 3. Allow submodules that are not listed in the main module, but = do not incorporate contents from non-listed submodules The spec is not = crystal clear, but I think that only interpretation (3) above is = supported by the spec. Specifically, this text makes (1) unsupported: = Modules are only allowed to include submodules that belong to that = module, as defined by the "belongs-to" statement (see Section 7.2.2). = Submodules are only allowed to include other submodules belonging to the = same module. And this text makes (2) unsupported: When a module includes = a submodule, it incorporates the contents of the submodule into the node = hierarchy of the module. When a submodule includes another submodule, = the target submodule's definitions are made available to the current = submodule. This is unfortunate. I think both (1) and (2) are useful, but = (3) is mostly just confusing. >>>>> I am fine with (1), which however needs an update to RFC 6020. I = have strong objections against (2). And I don't agree (3) is confusing. = In C, if you don't include an existing header file, its content is = missing. How this could be confusing or surprising? I actually think (3) = can be occassionally useful, and it is essentially compatible with the = current spec. Lada >>>>>> /martin >>>>> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C = _______________________________________________ netmod mailing list = netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>>> _______________________________________________ netmod mailing list = netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >>> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C = _______________________________________________ netmod mailing list = netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >>=20 > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Feb 22 07:19:18 2013 Return-Path: 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 95B6121F8E47 for ; Fri, 22 Feb 2013 07:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 QZppCGsU8UXw for ; Fri, 22 Feb 2013 07:19:18 -0800 (PST) Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CDD5521F8E3A for ; Fri, 22 Feb 2013 07:19:17 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so826743ieb.29 for ; Fri, 22 Feb 2013 07:19:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=G7NkzWUtigUS5DVni5djOoqJgiq0KoYcp9OwLyk+IxM=; b=D+GHvqNeHQl0MHRjHB4mnAeHjBxcQ92iMaKRNSlaaZLiv9rejcQ5ftWTYslkAfYnfZ T1TpGZtKU5uGF3KdOeBaicDIstIqEGdyB03zTEjqcDPf4h4J0v1JH3ye/6IWOhnOOVso E/tEbvnE4+b2gEDz9JMC9Z84TR+5R8qmwaIEuGADbR0bcW2Od2G93YmqqNvYpkhKz7eS y4/RUIGM2ca/T76CmSJuaiSawoTwsWLEW4FydQ6driceO8fAI4Q89Itg9qmtOntXXHk7 zlWL5Ixr7fQd4eHmjRIdnZRx2Tl0sAay6o6aooaCVC9iXtu0rWl6PGI9WHyudbT9SzE2 a4UA== MIME-Version: 1.0 X-Received: by 10.50.183.167 with SMTP id en7mr15045162igc.58.1361546357363; Fri, 22 Feb 2013 07:19:17 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 07:19:17 -0800 (PST) In-Reply-To: References: <20130222.120607.248909208.mbj@tail-f.com> <20130222.145115.368561051.mbj@tail-f.com> <20130222140316.GA63273@elstar.local> Date: Fri, 22 Feb 2013 07:19:17 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=14dae9340ca3f9d5ae04d651b602 X-Gm-Message-State: ALoCoQkONB/aFZGnipGmdHMTtON3za0EKZ2zA6lU75v5gUszmbSsHdvtskSxKqn0ioMu+WCd/mnR Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:19:18 -0000 --14dae9340ca3f9d5ae04d651b602 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 6:09 AM, Jonathan Hansford wrote: > ** > > Can someone clarify why transitivity is considered so unacceptable? I'm > still learning about YANG and a clarification of this point would really > help. > I think we are all still learning YANG ;-) Even if a submodule was considered its own namespace, the transitivity seems to work fine. 1) Does the including mod or submod inherit everything from the included namespace? A: Yes: All top-level definitions are exported; there is no way to declare such a definition to be private. 2) What are the contents of the submodule namespace? A or B? A) all of the top-level definitions in just that submodule B) all of the top-level definitions in the submodule and any submodules included into that submodule (or nested) We are saying the answer is B and Martin and Lada are saying A. The text is not entirely clear, and you can over-emphisise some text and ignore other text to make a point, but that doesn't fix the RFC. Andy On 22.02.2013 14:03, Juergen Schoenwaelder wrote: > > On Fri, Feb 22, 2013 at 02:51:15PM +0100, Martin Bjorklund wrote: > > Andy Bierman wrote: > > Perhaps the spec is ambiguous, but I don't agree adding busy work for the > YANG module writer is needed. The YANG compiler can easily figure out what > to do based on the belongs-to-stmt. > > No one has suggested this. > > I haven't read anything in this thread that would cause me to change any > code. The spec supports both implementation plans IMO, and it will take a > lot more than an errata to change it. > > There are three, not two, alternatives: 1. Require the module to list all > submodules (current pyang behavior) 2. Recursively incorporate the contents > from all submodules into the module (current yuma behavior) 3. Allow > submodules that are not listed in the main module, but do not incorporate > contents from non-listed submodules The spec is not crystal clear, but I > think that only interpretation (3) above is supported by the spec. > Specifically, this text makes (1) unsupported: Modules are only allowed to > include submodules that belong to that module, as defined by the > "belongs-to" statement (see Section 7.2.2). Submodules are only allowed to > include other submodules belonging to the same module. > > I do not see why this text makes (1) unsupported. This text only puts > up a restriction that you can't include submodules that belong to > other modules, no? > > And this text makes (2) unsupported: When a module includes a submodule, > it incorporates the contents of the submodule into the node hierarchy of > the module. When a submodule includes another submodule, the target > submodule's definitions are made available to the current submodule. > > I think the text is ambiguous since it remains unclear what "made > available to the current submodule" means. > > This is unfortunate. I think both (1) and (2) are useful, but (3) is > mostly just confusing. > > My reading is that the current text is ambiguous (and apparently > implementors came to two different interpretations). So we need to > decide what was/is desired and then fix things to avoid the ambiguity. > > /js > > > --14dae9340ca3f9d5ae04d651b602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 6:09 AM, Jonatha= n Hansford <Jonathan@hansfords.net> wrote:

Can someone clarify why=C2=A0transitivity=C2=A0is considered so unaccept= able? I'm still learning about YANG and a clarification of this point w= ould really help.


I think we are = all still learning YANG ;-)

Even if a submodule was considered its own namespace, t= he transitivity seems to work fine.

1) Does the in= cluding mod or submod inherit everything from the included namespace?
=C2=A0A: Yes: All top-level definitions are exported; there is no way = to declare such a definition
=C2=A0 =C2=A0 =C2=A0to be private.

2) What are the contents of the submodule namespace= ? A or B?
=C2=A0 =C2=A0 A) all of the top-level definitions in just that submodule
=C2=A0 =C2=A0 B) all of the top-level definitions in the submodule = and any submodules
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0included int= o that submodule (or nested)

We are saying the answer is B and Martin and Lada are saying A.<= /div>
The text is not entirely clear, and you can over-emphisise some t= ext and
ignore other text to make a point, but that doesn't f= ix the RFC.


Andy


=

On 22.02.2013 14:03, Juergen Schoenwaelder wrote:

On Fri, Feb 22, 2013 at 02:51:15PM +0100, Martin Bjorklund wrote:

Andy Bierman <andy@yumaworks.com> wrote:

Perhaps the spec is ambiguous, but I don=
't agree adding busy work for the YANG module writer is needed. The YAN=
G compiler can easily figure out what to do based on the belongs-to-stmt.

No one has suggested this.

I haven't read anything in this thre=
ad that would cause me to change any code. The spec supports both implement=
ation plans IMO, and it will take a lot more than an errata to change it.

There are three, not two, alternatives: 1. Require the module to list all s=
ubmodules (current pyang behavior) 2. Recursively incorporate the contents =
from all submodules into the module (current yuma behavior) 3. Allow submod=
ules that are not listed in the main module, but do not incorporate content=
s from non-listed submodules The spec is not crystal clear, but I think tha=
t only interpretation (3) above is supported by the spec. Specifically, thi=
s text makes (1) unsupported: Modules are only allowed to include submodule=
s that belong to that module, as defined by the "belongs-to" stat=
ement (see Section 7.2.2). Submodules are only allowed to include other sub=
modules belonging to the same module.



I do not see why this text makes (1) unsupported. This text only puts
up a restriction that you can't include submodules that belong to
other modules, no?


And this text makes (2) unsupported: Whe=
n a module includes a submodule, it incorporates the contents of the submod=
ule into the node hierarchy of the module. When a submodule includes anothe=
r submodule, the target submodule's definitions are made available to t=
he current submodule.



I think the text is ambiguous since it remains unclear what "made
available to the current submodule" means.


This is unfortunate. I think both (1) an=
d (2) are useful, but (3) is mostly just confusing.


My reading is that the current text is ambiguous (and apparently
implementors came to two different interpretations). So we need to
decide what was/is desired and then fix things to avoid the ambiguity.

/js





=C2=A0

--14dae9340ca3f9d5ae04d651b602-- From mbj@tail-f.com Fri Feb 22 07:19:44 2013 Return-Path: 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 28C6E21F8E50 for ; Fri, 22 Feb 2013 07:19:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5VWsSURrX1W for ; Fri, 22 Feb 2013 07:19:43 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42021F8E4E for ; Fri, 22 Feb 2013 07:19:43 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7078D1200D7A; Fri, 22 Feb 2013 16:19:42 +0100 (CET) Date: Fri, 22 Feb 2013 16:19:41 +0100 (CET) Message-Id: <20130222.161941.453515630.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:19:44 -0000 Ladislav Lhotka wrote: > > On Feb 22, 2013, at 3:55 PM, Jonathan Hansford wrote: > > > > > On 22.02.2013 14:50, Ladislav Lhotka wrote: > > > >> On Feb 22, 2013, at 3:35 PM, Andy Bierman wrote: > >>> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka wrote: On > >>> Feb 22, 2013, at 3:17 PM, Jonathan Hansford wrote: > >>>> On 22.02.2013 14:12, Ladislav Lhotka wrote: > >>>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund wrote: > >>>>>> Andy Bierman wrote: > >>>>>>> Perhaps the spec is ambiguous, but I don't agree adding busy work for > >>>>>>> the YANG module writer is needed. The YANG compiler can easily figure > >>>>>>> out what to do based on the belongs-to-stmt. > >>>>>> No one has suggested this. > >>>>>>> I haven't read anything in this thread that would cause me to change > >>>>>>> any code. The spec supports both implementation plans IMO, and it will > >>>>>>> take a lot more than an errata to change it. > >>>>>> There are three, not two, alternatives: 1. Require the module to list > >>>>>> all submodules (current pyang behavior) 2. Recursively incorporate the > >>>>>> contents from all submodules into the module (current yuma behavior) > >>>>> I wonder what "all" means here. Are the submodules looked up in an > >>>>> implementation-dependent list of search directories, or in the entire > >>>>> universe? > >>>> Surely "all" means all directly or indirectly included submodules. Just > >>>> writing a YANG submodule with a "belongs-to" shouldn't make it part of the > >>>> module unless the module o an included submodule includes it. > >>> I may have misunderstood Andy, but he wrote that it is the "belongs-to" > >>> statement that incorporates the contents of a submodule into the main > >>> module. I am not suggesting that submodules that are not included in any > >>> way are part of the module. They are just bugs. Obviously a YANG compiler > >>> cannot guess that unmentioned submodules exist somewhere. But anytime the > >>> compiler encounters an include or import, it has to process it. > >> OK, so it was indeed a misunderstanding. > >>> It is up to the developer to decide if the submodule organization is an > >>> unmanageable mess or a work or art. Since a module does not need to list > >>> all the nested imports that will occur (mod A imports B which imports C -- > >>> mod A doesn't need to say anything about C), I don't agree this is needed > >>> for submodules either. > >> I now have an impression that the concept of submodules is unnecessarily > >> complicated, perhaps it could work simply as #include in cpp, i. e. the text > >> of a module would be constructed by applying recursively all includes. Then > >> submodules could also directly refer to definitions in the main module. > >> > > Wouldn't that require the submodule to include the module, which is not > > allowed? > > No. I mean that each include would be simply replaced by the contents of the > corresponding submodule (data nodes, rpcs, identities, features etc., but > obviously not metadata). But what about collisions? Compare w/ #ifndef. Anyway, we're not going to completely redesign how submodules work at this point in time. /martin From jonathan@hansfords.net Fri Feb 22 07:30:12 2013 Return-Path: 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 ADEC821F8E2E for ; Fri, 22 Feb 2013 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 P5amZ+aR7vZY for ; Fri, 22 Feb 2013 07:30:11 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4589B21F8E2D for ; Fri, 22 Feb 2013 07:30:10 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 3TW81l00G4CLSd801TW9hK; Fri, 22 Feb 2013 15:30:09 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=xskcdSivAAAA:8 a=u07AKapRAAAA:8 a=fYsXQQw2k1YaSPmHfFwA:9 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=ChEcuLpljosA:10 a=XqebBV1NYWwA:10 a=UtOtmMtFfjQ1QiGWryAA:9 a=_W_S_7VecoQA:10 a=LXiEldR27HnOGSAN:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 22 Feb 2013 15:30:08 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_fa74bf387d29f6b6f9b9a5703d771ecd" Date: Fri, 22 Feb 2013 15:30:08 +0000 From: Jonathan Hansford To: Martin Bjorklund In-Reply-To: <20130222.161941.453515630.mbj@tail-f.com> References: <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> <20130222.161941.453515630.mbj@tail-f.com> Message-ID: <28fa3e7176af28ee9bb21ee077596457@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:30:12 -0000 --=_fa74bf387d29f6b6f9b9a5703d771ecd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 22.02.2013 15:19, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > >> On Feb 22, 2013, at 3:55 PM, Jonathan Hansford wrote: >> >>> On 22.02.2013 14:50, Ladislav Lhotka wrote: >>> >>>> On Feb 22, 2013, at 3:35 PM, Andy Bierman wrote: >>>> >>>>> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka wrote: On Feb 22, 2013, at 3:17 PM, Jonathan Hansford wrote: >>>>> >>>>>> On 22.02.2013 14:12, Ladislav Lhotka wrote: >>>>>> >>>>>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund wrote: >>>>>>> >>>>>>>> Andy Bierman wrote: >>>>>>>> >>>>>>>>> Perhaps the spec is ambiguous, but I don't agree adding busy work for the YANG module writer is needed. The YANG compiler can easily figure out what to do based on the belongs-to-stmt. >>>>>>>> No one has suggested this. >>>>>>>> >>>>>>>>> I haven't read anything in this thread that would cause me to change any code. The spec supports both implementation plans IMO, and it will take a lot more than an errata to change it. >>>>>>>> There are three, not two, alternatives: 1. Require the module to list all submodules (current pyang behavior) 2. Recursively incorporate the contents from all submodules into the module (current yuma behavior) >>>>>>> I wonder what "all" means here. Are the submodules looked up in an implementation-dependent list of search directories, or in the entire universe? >>>>>> Surely "all" means all directly or indirectly included submodules. Just writing a YANG submodule with a "belongs-to" shouldn't make it part of the module unless the module o an included submodule includes it. >>>>> I may have misunderstood Andy, but he wrote that it is the "belongs-to" statement that incorporates the contents of a submodule into the main module. I am not suggesting that submodules that are not included in any way are part of the module. They are just bugs. Obviously a YANG compiler cannot guess that unmentioned submodules exist somewhere. But anytime the compiler encounters an include or import, it has to process it. >>>> OK, so it was indeed a misunderstanding. >>>> >>>>> It is up to the developer to decide if the submodule organization is an unmanageable mess or a work or art. Since a module does not need to list all the nested imports that will occur (mod A imports B which imports C -- mod A doesn't need to say anything about C), I don't agree this is needed for submodules either. >>>> I now have an impression that the concept of submodules is unnecessarily complicated, perhaps it could work simply as #include in cpp, i. e. the text of a module would be constructed by applying recursively all includes. Then submodules could also directly refer to definitions in the main module. >>> Wouldn't that require the submodule to include the module, which is not allowed? >> No. I mean that each include would be simply replaced by the contents of the corresponding submodule (data nodes, rpcs, identities, features etc., but obviously not metadata). > > But what about collisions? Compare w/ #ifndef. > > Anyway, we're not going to completely redesign how submodules work at > this point in time. But we need to agree how to remove ambiguities. Can we afford for two different tools to have different understandings of how "include" should be implemented? Doesn't the current situation undermine YANG? /martin Links: ------ [1] mailto:andy@yumaworks.com [2] mailto:mbj@tail-f.com [3] mailto:lhotka@nic.cz [4] mailto:Jonathan@hansfords.net [5] mailto:andy@yumaworks.com [6] mailto:Jonathan@hansfords.net --=_fa74bf387d29f6b6f9b9a5703d771ecd Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 22.02.2013 15:19, Martin Bjorklund wrote:

Ladislav Lhotka <lhotka@nic.cz=
> wrote:
On Feb 22, 2013, at 3:55 PM, Jonathan= Hansford <Jonathan@hansfords= =2Enet> wrote:
On 22.02.2013 14:50, Ladislav Lhotka = wrote:
On Feb 22, 2013, at 3:35 PM, Andy Bie= rman <andy@yumaworks.com> w= rote:
On Fri, Feb 22, 2013 at 6:24 AM, Ladi= slav Lhotka <lhotka@nic.cz> wrot= e: On Feb 22, 2013, at 3:17 PM, Jonathan Hansford <Jonathan@hansfords.net> wrote:
On 22.02.2013 14:12, Ladislav Lhotka = wrote:
On Feb 22, 2013, at 2:51 PM, Martin B= jorklund <mbj@tail-f.com> wrote= :
Andy Bierman <andy@yumaworks.com> wrote:
Perhaps the spec is ambiguous, but I = don't agree adding busy work for the YANG module writer is needed. The YANG= compiler can easily figure out what to do based on the belongs-to-stmt. No one has suggested this.
I haven't read anything in this threa= d that would cause me to change any code. The spec supports both implementa= tion plans IMO, and it will take a lot more than an errata to change it. There are three, not two, alternatives: 1. Require the module to list all s= ubmodules (current pyang behavior) 2. Recursively incorporate the contents = from all submodules into the module (current yuma behavior)
I wonder what "all" means here. Are the submodules looked up in an implemen= tation-dependent list of search directories, or in the entire universe? Surely "all" means all directly or indirectly included submodules. Just wri= ting a YANG submodule with a "belongs-to" shouldn't make it part of the mod= ule unless the module o an included submodule includes it.
I may have misunderstood Andy, but he wrote that it is the "belongs-to" sta= tement that incorporates the contents of a submodule into the main module= =2E I am not suggesting that submodules that are not included in any way ar= e part of the module. They are just bugs. Obviously a YANG compiler cannot = guess that unmentioned submodules exist somewhere. But anytime the compiler= encounters an include or import, it has to process it.
OK, so it was indeed a misunderstanding.
It is up to the developer to decide i= f the submodule organization is an unmanageable mess or a work or art. Sinc= e a module does not need to list all the nested imports that will occur (mo= d A imports B which imports C -- mod A doesn't need to say anything about C= ), I don't agree this is needed for submodules either.
I now have an impression that the concept of submodules is unnecessarily co= mplicated, perhaps it could work simply as #include in cpp, i. e. the text = of a module would be constructed by applying recursively all includes. Then= submodules could also directly refer to definitions in the main module. Wouldn't that require the submodule to include the module, which is not all= owed?
No. I mean that each include would be simply replaced by the contents of th= e corresponding submodule (data nodes, rpcs, identities, features etc., but= obviously not metadata).
But what about collisions?  Compare w/ #ifndef.

Anyway, we're not going to completely redesign how submodules work at
this point in time.
 
But we need to agree how to remove ambiguities. Can we afford for two =
different tools to have different understandings of how "include" should be=
 implemented? Doesn't the current situation undermine YANG?


/martin
 
--=_fa74bf387d29f6b6f9b9a5703d771ecd-- From andy@yumaworks.com Fri Feb 22 07:31:42 2013 Return-Path: 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 BC3AE21F8E3C for ; Fri, 22 Feb 2013 07:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 qy+6bTIsCxv6 for ; Fri, 22 Feb 2013 07:31:42 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id CEF8C21F8E2D for ; Fri, 22 Feb 2013 07:31:41 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so813922ieb.37 for ; Fri, 22 Feb 2013 07:31:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=aQYLLsX4YI6376jsNxLnXM+ynBI2npT5IZ4biYXJzS8=; b=WBgxc9usF3s+iXurhYtEjVOg81iBU5/7YvIDavV/HrRL6hRPeLGgymN12NJ7UGBQF2 QcLrJWKs9gULHf2e/EoQZ12B53VKqWgUE3rY1/wsNpzDiup4OkPTE5ouva4RIuJxBf// 54vpJn0ZgdkNdTQsoW3rUfeyoQQXnx7wlsmuV6rRBJJfVm4lry11+bVzWf8f2E1ypMiq LFvx/Bj+NIz7Mog6fdYrJqBnJ545Q+0rpV1owggSU5hXoq3yzZO/SLHUIq/FdpYdVxxh 9ZYVVHk2C9r1KiQSvhY6Y91rPriLxHXfJfSzQ8ryZTKdHvyJmcztJyyJgdR05/vhyQ5P XQSg== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr8423975igc.91.1361547101337; Fri, 22 Feb 2013 07:31:41 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 07:31:41 -0800 (PST) In-Reply-To: <20130222.161941.453515630.mbj@tail-f.com> References: <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> <20130222.161941.453515630.mbj@tail-f.com> Date: Fri, 22 Feb 2013 07:31:41 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae934034551f92704d651e3ac X-Gm-Message-State: ALoCoQmmS5KwymAhDJF1+3vNM7nRabqNR9Qg3kYDExMKe+BuBHBW11apgour2e7TI0411QXD1Gj9 Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:31:42 -0000 --14dae934034551f92704d651e3ac Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 7:19 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On Feb 22, 2013, at 3:55 PM, Jonathan Hansford > wrote: > > > > > > > > On 22.02.2013 14:50, Ladislav Lhotka wrote: > > > > > >> On Feb 22, 2013, at 3:35 PM, Andy Bierman wrote: > > >>> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka > wrote: On > > >>> Feb 22, 2013, at 3:17 PM, Jonathan Hansford > wrote: > > >>>> On 22.02.2013 14:12, Ladislav Lhotka wrote: > > >>>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund > wrote: > > >>>>>> Andy Bierman wrote: > > >>>>>>> Perhaps the spec is ambiguous, but I don't agree adding busy > work for > > >>>>>>> the YANG module writer is needed. The YANG compiler can easily > figure > > >>>>>>> out what to do based on the belongs-to-stmt. > > >>>>>> No one has suggested this. > > >>>>>>> I haven't read anything in this thread that would cause me to > change > > >>>>>>> any code. The spec supports both implementation plans IMO, and > it will > > >>>>>>> take a lot more than an errata to change it. > > >>>>>> There are three, not two, alternatives: 1. Require the module to > list > > >>>>>> all submodules (current pyang behavior) 2. Recursively > incorporate the > > >>>>>> contents from all submodules into the module (current yuma > behavior) > > >>>>> I wonder what "all" means here. Are the submodules looked up in an > > >>>>> implementation-dependent list of search directories, or in the > entire > > >>>>> universe? > > >>>> Surely "all" means all directly or indirectly included submodules. > Just > > >>>> writing a YANG submodule with a "belongs-to" shouldn't make it part > of the > > >>>> module unless the module o an included submodule includes it. > > >>> I may have misunderstood Andy, but he wrote that it is the > "belongs-to" > > >>> statement that incorporates the contents of a submodule into the main > > >>> module. I am not suggesting that submodules that are not included in > any > > >>> way are part of the module. They are just bugs. Obviously a YANG > compiler > > >>> cannot guess that unmentioned submodules exist somewhere. But > anytime the > > >>> compiler encounters an include or import, it has to process it. > > >> OK, so it was indeed a misunderstanding. > > >>> It is up to the developer to decide if the submodule organization is > an > > >>> unmanageable mess or a work or art. Since a module does not need to > list > > >>> all the nested imports that will occur (mod A imports B which > imports C -- > > >>> mod A doesn't need to say anything about C), I don't agree this is > needed > > >>> for submodules either. > > >> I now have an impression that the concept of submodules is > unnecessarily > > >> complicated, perhaps it could work simply as #include in cpp, i. e. > the text > > >> of a module would be constructed by applying recursively all > includes. Then > > >> submodules could also directly refer to definitions in the main > module. > > >> > > > Wouldn't that require the submodule to include the module, which is not > > > allowed? > > > > No. I mean that each include would be simply replaced by the contents of > the > > corresponding submodule (data nodes, rpcs, identities, features etc., but > > obviously not metadata). > > But what about collisions? Compare w/ #ifndef. > > Anyway, we're not going to completely redesign how submodules work at > this point in time. > > > No, but we should try to clarify the RFC when it is unclear. Yuma treats submodules as a partitioned namespace, not a hierarchy of submodule namespaces. There is a big difference: module A { include B; include C; } submodule B { include C; leaf x { type a:mystring; } } submodule C { typedef mystring { type string { length 1..max; } } leaf y { type mystring; } } So, is this an error because leaf y is included into the main module twice? Obviously the intent is to just use the typedef from C but all definitions are pulled into the submodule namespace. > /martin > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --14dae934034551f92704d651e3ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 7:19 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> = wrote:
>
> On Feb 22, 2013, at 3:55 PM, Jonathan Hansford <Jonathan@hansfords.net> wrote:
>
> >
> > On 22.02.2013 14:50, Ladislav Lhotka wrote:
> >
> >> On Feb 22, 2013, at 3:35 PM, Andy Bierman <andy@yumaworks.com> wrote:
> >>> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: On
> >>> Feb 22, 2013, at 3:17 PM, Jonathan Hansford <Jonathan@hansfords.net> wrote: > >>>> On 22.02.2013 14:12, Ladislav Lhotka wrote:
> >>>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund <= ;mbj@tail-f.com> wrote:
> >>>>>> Andy Bierman <andy@yumaworks.com> wrote:
> >>>>>>> Perhaps the spec is ambiguous, but I don&= #39;t agree adding busy work for
> >>>>>>> the YANG module writer is needed. The YAN= G compiler can easily figure
> >>>>>>> out what to do based on the belongs-to-st= mt.
> >>>>>> No one has suggested this.
> >>>>>>> I haven't read anything in this threa= d that would cause me to change
> >>>>>>> any code. The spec supports both implemen= tation plans IMO, and it will
> >>>>>>> take a lot more than an errata to change = it.
> >>>>>> There are three, not two, alternatives: 1. Re= quire the module to list
> >>>>>> all submodules (current pyang behavior) 2. Re= cursively incorporate the
> >>>>>> contents from all submodules into the module = (current yuma behavior)
> >>>>> I wonder what "all" means here. Are the= submodules looked up in an
> >>>>> implementation-dependent list of search directori= es, or in the entire
> >>>>> universe?
> >>>> Surely "all" means all directly or indirect= ly included submodules. Just
> >>>> writing a YANG submodule with a "belongs-to"= ; shouldn't make it part of the
> >>>> module unless the module o an included submodule incl= udes it.
> >>> I may have misunderstood Andy, but he wrote that it is th= e "belongs-to"
> >>> statement that incorporates the contents of a submodule i= nto the main
> >>> module. I am not suggesting that submodules that are not = included in any
> >>> way are part of the module. They are just bugs. Obviously= a YANG compiler
> >>> cannot guess that unmentioned submodules exist somewhere.= But anytime the
> >>> compiler encounters an include or import, it has to proce= ss it.
> >> OK, so it was indeed a misunderstanding.
> >>> It is up to the developer to decide if the submodule orga= nization is an
> >>> unmanageable mess or a work or art. Since a module does n= ot need to list
> >>> all the nested imports that will occur (mod A imports B w= hich imports C --
> >>> mod A doesn't need to say anything about C), I don= 9;t agree this is needed
> >>> for submodules either.
> >> I now have an impression that the concept of submodules is un= necessarily
> >> complicated, perhaps it could work simply as #include in cpp,= i. e. the text
> >> of a module would be constructed by applying recursively all = includes. Then
> >> submodules could also directly refer to definitions in the ma= in module.
> >>
> > Wouldn't that require the submodule to include the module, wh= ich is not
> > allowed?
>
> No. I mean that each include would be simply replaced by the contents = of the
> corresponding submodule (data nodes, rpcs, identities, features etc., = but
> obviously not metadata).

But what about collisions? =C2=A0Compare w/ #ifndef.

Anyway, we're not going to completely redesign how submodules work at this point in time.



No, but we should try to clarify the R= FC when it is unclear.

Yuma treats submodules as a= partitioned namespace, not a hierarchy
of submodule namespaces. = =C2=A0There is a big difference:

module A {
=C2=A0 =C2=A0include B;
= =C2=A0 =C2=A0include C;
}

submodule B {<= /div>
=C2=A0 include C;
=C2=A0 leaf x { type a:mystring; }
}

submodule C {
=C2=A0 typedef mystring {=C2=A0
=C2= =A0 =C2=A0 type string { length 1..max; }
=C2=A0 }
=C2= =A0 leaf y { type mystring; }
}

So, is t= his an error because leaf y is included into the main module twice?
Obviously the intent is to just use the typedef from C but all definit= ions are
pulled into the submodule namespace.



=C2=A0
/martin

Andy
=C2=A0
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--14dae934034551f92704d651e3ac-- From mbj@tail-f.com Fri Feb 22 07:36:16 2013 Return-Path: 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 9C65121F8E6C for ; Fri, 22 Feb 2013 07:36:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JihZATWe7+WV for ; Fri, 22 Feb 2013 07:36:16 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 108CD21F8E3C for ; Fri, 22 Feb 2013 07:36:16 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 02D891200A6E; Fri, 22 Feb 2013 16:36:15 +0100 (CET) Date: Fri, 22 Feb 2013 16:36:14 +0100 (CET) Message-Id: <20130222.163614.490562061.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:36:16 -0000 Andy Bierman wrote: > On Fri, Feb 22, 2013 at 7:19 AM, Martin Bjorklund wrote: > > Anyway, we're not going to completely redesign how submodules work at > > this point in time. > > > > > > > No, but we should try to clarify the RFC when it is unclear. Yes. > Yuma treats submodules as a partitioned namespace, not a hierarchy > of submodule namespaces. There is a big difference: > > module A { > include B; > include C; > } > > submodule B { > include C; > leaf x { type a:mystring; } > } > > submodule C { > typedef mystring { > type string { length 1..max; } > } > leaf y { type mystring; } > } > > So, is this an error because leaf y is included into the main module > twice? With the current text, the leaf y is not included twice. When submodule B includes C, it works like an import ("makes the definitions available for reference"). When module A includes C, it "copies" the definitions from C into itself. /martin From mbj@tail-f.com Fri Feb 22 07:45:25 2013 Return-Path: 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 A349321F888B for ; Fri, 22 Feb 2013 07:45:25 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2EeOsyOgmOU for ; Fri, 22 Feb 2013 07:45:25 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2156B21F8480 for ; Fri, 22 Feb 2013 07:45:25 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id ED7BF1200A6E; Fri, 22 Feb 2013 16:45:23 +0100 (CET) Date: Fri, 22 Feb 2013 16:45:23 +0100 (CET) Message-Id: <20130222.164523.316305902.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130222134956.GA63213@elstar.local> References: <20130222133003.GA63107@elstar.local> <20130222.143624.522177974.mbj@tail-f.com> <20130222134956.GA63213@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, dthaler@microsoft.com Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:45:25 -0000 Juergen Schoenwaelder wrote: > On Fri, Feb 22, 2013 at 02:36:24PM +0100, Martin Bjorklund wrote: > > > > > But even so, RFC 4007 talks about "link-local scope" and > > > > "interface-local scope". I assume the "interface-local scope" can be > > > > the interface index, but the link local scope may be something else? > > > > > > With link-local scope, you usually use the interface index/name of the > > > link to identify the zone. > > > > Isn't the difference between link-local scope and interface-local > > scope that there can be more than one interface attached to one link? > > Which interface's number would you use as the link zone identifier? > > In this case, I assume implementations accept any of them as valid > input to identify the zone. Which one do you use as the canonical > output? No clue, likely no RFC ever talks about this. Actually, RFC 4007 indicates that in this case, manual configuration of the link zones should be used: Furthermore, to avoid performing manual configuration in most cases, an implementation should, by default, initially assign zone indices only as follows: o A unique interface index for each interface. o A unique link index for each interface. Then manual configuration would only be necessary for the less common cases of nodes with multiple interfaces to a single link or of those with interfaces to zones of different (multicast-only) scopes. /martin From lhotka@nic.cz Fri Feb 22 08:04:36 2013 Return-Path: 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 3D60121F8F69 for ; Fri, 22 Feb 2013 08:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 XBm0aiSntpX7 for ; Fri, 22 Feb 2013 08:04:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5021F8F68 for ; Fri, 22 Feb 2013 08:04:35 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6D95413F63F; Fri, 22 Feb 2013 17:04:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361549074; bh=Or++cHuL9jnz0jsijgiOh/dZzvm88UjmRTIthFk27jU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sSIkVzrVsaw31efMd1qSg5i4k9Ag5ffy3nlSE0Q81gCKY0HEDjUuPS8q1EOJyYdmS vk/j0yrI+ts2Y2PluE73zOpCiZ3F9zi3YLkR6Q6mRUVkZBCaboD9ZYYBJZ0RELGZeV VFhH+mhHJDBsQUCsjxPeiPFTbYwC6LVOoBFwy4ss= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130222.161941.453515630.mbj@tail-f.com> Date: Fri, 22 Feb 2013 17:04:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> References: <2A29889A-C1DD-4415-B79B-0C75CCB6ABAB@nic.cz> <1b35215cfe79b534186c5cd439bb38be@imap.plus.net> <20130222.161941.453515630.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:04:36 -0000 On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Feb 22, 2013, at 3:55 PM, Jonathan Hansford = wrote: >>=20 >>>=20 >>> On 22.02.2013 14:50, Ladislav Lhotka wrote: >>>=20 >>>> On Feb 22, 2013, at 3:35 PM, Andy Bierman = wrote: >>>>> On Fri, Feb 22, 2013 at 6:24 AM, Ladislav Lhotka = wrote: On >>>>> Feb 22, 2013, at 3:17 PM, Jonathan Hansford = wrote: >>>>>> On 22.02.2013 14:12, Ladislav Lhotka wrote: >>>>>>> On Feb 22, 2013, at 2:51 PM, Martin Bjorklund = wrote: >>>>>>>> Andy Bierman wrote: >>>>>>>>> Perhaps the spec is ambiguous, but I don't agree adding busy = work for >>>>>>>>> the YANG module writer is needed. The YANG compiler can easily = figure >>>>>>>>> out what to do based on the belongs-to-stmt. >>>>>>>> No one has suggested this. >>>>>>>>> I haven't read anything in this thread that would cause me to = change >>>>>>>>> any code. The spec supports both implementation plans IMO, and = it will >>>>>>>>> take a lot more than an errata to change it. >>>>>>>> There are three, not two, alternatives: 1. Require the module = to list >>>>>>>> all submodules (current pyang behavior) 2. Recursively = incorporate the >>>>>>>> contents from all submodules into the module (current yuma = behavior) >>>>>>> I wonder what "all" means here. Are the submodules looked up in = an >>>>>>> implementation-dependent list of search directories, or in the = entire >>>>>>> universe? >>>>>> Surely "all" means all directly or indirectly included = submodules. Just >>>>>> writing a YANG submodule with a "belongs-to" shouldn't make it = part of the >>>>>> module unless the module o an included submodule includes it. >>>>> I may have misunderstood Andy, but he wrote that it is the = "belongs-to" >>>>> statement that incorporates the contents of a submodule into the = main >>>>> module. I am not suggesting that submodules that are not included = in any >>>>> way are part of the module. They are just bugs. Obviously a YANG = compiler >>>>> cannot guess that unmentioned submodules exist somewhere. But = anytime the >>>>> compiler encounters an include or import, it has to process it. >>>> OK, so it was indeed a misunderstanding. >>>>> It is up to the developer to decide if the submodule organization = is an >>>>> unmanageable mess or a work or art. Since a module does not need = to list >>>>> all the nested imports that will occur (mod A imports B which = imports C -- >>>>> mod A doesn't need to say anything about C), I don't agree this is = needed >>>>> for submodules either. >>>> I now have an impression that the concept of submodules is = unnecessarily >>>> complicated, perhaps it could work simply as #include in cpp, i. e. = the text >>>> of a module would be constructed by applying recursively all = includes. Then >>>> submodules could also directly refer to definitions in the main = module. >>>>=20 >>> Wouldn't that require the submodule to include the module, which is = not >>> allowed? >>=20 >> No. I mean that each include would be simply replaced by the contents = of the >> corresponding submodule (data nodes, rpcs, identities, features etc., = but >> obviously not metadata). >=20 > But what about collisions? Compare w/ #ifndef. With transitive inclusions, collisions have to be avoided in any case. = Consider this: module M { include A; =85 } module A { belongs-to A; include B; =85 } module B { belongs-to A; grouping ggg { =85 } =85 } Even if module M doesn't include B, it cannot define its own "ggg" = because an importing module would see both. So from the point of view of collision avoidance, it is irrelevant = whether M includes B or not.=20 >=20 > Anyway, we're not going to completely redesign how submodules work at > this point in time. Well, it seems we will have to do something, so why not get it right? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Feb 22 08:22:59 2013 Return-Path: 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 3036621F8F74 for ; Fri, 22 Feb 2013 08:22:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo1-QMOSlKuI for ; Fri, 22 Feb 2013 08:22:58 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A49BA21F8F72 for ; Fri, 22 Feb 2013 08:22:58 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A53201200AF6; Fri, 22 Feb 2013 17:22:57 +0100 (CET) Date: Fri, 22 Feb 2013 17:22:57 +0100 (CET) Message-Id: <20130222.172257.357766029.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:22:59 -0000 Ladislav Lhotka wrote: > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: > > But what about collisions? Compare w/ #ifndef. > > With transitive inclusions, collisions have to be avoided in any > case. Exactly. But with the current text, collisions are avoided, since it is only the module that "incorporates" the contents of the submodules. /martin From andy@yumaworks.com Fri Feb 22 08:33:14 2013 Return-Path: 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 880D021F8EB5 for ; Fri, 22 Feb 2013 08:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 CwC1nl946sFs for ; Fri, 22 Feb 2013 08:33:13 -0800 (PST) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B451021F8EAD for ; Fri, 22 Feb 2013 08:33:13 -0800 (PST) Received: by mail-ia0-f176.google.com with SMTP id i18so680813iac.35 for ; Fri, 22 Feb 2013 08:33:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2pZSiKiAQtqczRACAYCUbZPFJolSl4klHY/CbiH0paM=; b=e3+k/movExUfTI9bsfeofKY8g02fTJBfEjUE4Rv6mSs+tdlR2mSYNvLBU9FwxTm7PH YgdImB2fpMRlPj2x1m2dqVT3cOToDCNP7jI7SffqLaA/h3ecvhUlxQ2Ep1EEX5KOqRzs Tyy9+p4otGCKGXZHplbJzZ1xN3ojLJ0Qve08hRItyGBNf8+FoX75mypYOieiUkwvJfT0 RV8nGhVWzxBIr1pCSFp37lNIdlvut+2vGNieb/ExMnDow42QIUoG67srHr2KEx2/svi5 meoJXCnoCf/rdryAoOr5iJEKjiCzSyNrjwRpuxIzuMuoirYztCtNzj7AmqvLiuLrdASH xJKg== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr8522093igc.91.1361550789119; Fri, 22 Feb 2013 08:33:09 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 08:33:08 -0800 (PST) In-Reply-To: <20130222.172257.357766029.mbj@tail-f.com> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> Date: Fri, 22 Feb 2013 08:33:08 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=14dae9340345210e2d04d652bf02 X-Gm-Message-State: ALoCoQkegF+1I3WrVBL3exktYwsfsposHDiPhrtfU4iJ+X5Aq7dnXvdNQG8nOMKxC6iLAQ4s14QN Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:33:14 -0000 --14dae9340345210e2d04d652bf02 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: > > > But what about collisions? Compare w/ #ifndef. > > > > With transitive inclusions, collisions have to be avoided in any > > case. > > Exactly. But with the current text, collisions are avoided, since it > is only the module that "incorporates" the contents of the > submodules. > > IMO, for export purposes, submodules are conceptually flat -- they all contribute to the module namespace. The compiler has to detect any naming collisions for the entire module namespace. With your interpretation, how would the following corner-case be handled? module A { include B; typedef X { type string; } } submodule B { include C; leaf a { type a:X; } } submodule C { typedef X { type int32; } } In Yuma this would be a duplicate name error for 'X'. Is that correct or is leaf a an int32 and no problem? (Looks like a problem to me.) > /martin > Andy --14dae9340345210e2d04d652bf02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 8:22 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> = wrote:
>
> On Feb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > But what about collisions? =C2=A0Compare w/ #ifndef.
>
> With transitive inclusions, collisions have to be avoided in any
> case.

Exactly. =C2=A0But with the current text, collisions are avoided, since it<= br> is only the module that "incorporates" the contents of the
submodules.



IMO, for export purpose= s, submodules are conceptually flat -- they all contribute
to the= module namespace. =C2=A0The compiler has to detect any naming collisions f= or the
entire module namespace.

With your interpreta= tion, how would the following corner-case be handled?

<= div>module A {
=C2=A0 include B;
=C2=A0 typedef X { typ= e string; }
}

submodule B {
=C2=A0 include C;
=C2=A0 leaf a { type a:X; }
}

s= ubmodule C {
=C2=A0 typedef X { type int32; }
}

In Yuma this would be a duplicate name error for 'X'.
Is that correct or is leaf a an int32 and no problem?
(Looks li= ke a problem to me.)



/martin

Andy
=C2=A0
--14dae9340345210e2d04d652bf02-- From jonathan@hansfords.net Fri Feb 22 08:39:43 2013 Return-Path: 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 0EA7521F8DFF for ; Fri, 22 Feb 2013 08:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SqZ6CZvZF183 for ; Fri, 22 Feb 2013 08:39:42 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id B6D1721F8DA0 for ; Fri, 22 Feb 2013 08:39:41 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 3Uff1l0074CLSd801Ufg7j; Fri, 22 Feb 2013 16:39:40 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=u07AKapRAAAA:8 a=B8vRTKniNHo3T2B_4HcA:9 a=QEXdDO2ut3YA:10 a=XqebBV1NYWwA:10 a=Fg-OdhKOBuJN-n6hF78A:9 a=_W_S_7VecoQA:10 a=2LeeMTbK7XuNgH_N:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 22 Feb 2013 16:39:39 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6eb762321fdacc413c36c6dee448f3b7" Date: Fri, 22 Feb 2013 16:39:39 +0000 From: Jonathan Hansford To: In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:39:43 -0000 --=_6eb762321fdacc413c36c6dee448f3b7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 22.02.2013 16:33, Andy Bierman wrote: > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >> > >> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >> > > But what about collisions? Compare w/ #ifndef. >> > >> > With transitive inclusions, collisions have to be avoided in any >> > case. >> >> Exactly. But with the current text, collisions are avoided, since it >> is only the module that "incorporates" the contents of the >> submodules. > > IMO, for export purposes, submodules are conceptually flat -- they all contribute > to the module namespace. The compiler has to detect any naming collisions for the > entire module namespace. > With your interpretation, how would the following corner-case be handled? > module A { > include B; > typedef X { type string; } > } > submodule B { > include C; > leaf a { type a:X; } > } > submodule C { > typedef X { type int32; } > } > In Yuma this would be a duplicate name error for 'X'. Does Yuma effectively surround each include with an implicit #ifndef (i.e. the only the first include of a submodule is parsed)? > Is that correct or is leaf a an int32 and no problem? > (Looks like a problem to me.) > >> /martin > > Andy Links: ------ [1] mailto:lhotka@nic.cz [2] mailto:mbj@tail-f.com [3] mailto:mbj@tail-f.com --=_6eb762321fdacc413c36c6dee448f3b7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 22.02.2013 16:33, Andy Bierman wrote:



On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklun= d <mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On F= eb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > But what about collis= ions?  Compare w/ #ifndef.
>
> With transitive inclu= sions, collisions have to be avoided in any
> case.

Ex= actly.  But with the current text, collisions are avoided, since it is only the module that "incorporates" the contents of the
submod= ules.

IMO, for export purposes, submodules are conceptually flat -- they all= contribute
to the module namespace.  The compiler has to detect any naming c= ollisions for the
entire module namespace.
With your interpretation, how would the following corner-case be handl= ed?
module A {
  include B;
  typedef X { type string; }
}
submodule B {
  include C;
  leaf a { type a:X; }
}
submodule C {
  typedef X { type int32; }
}
In Yuma this would be a duplicate name error for 'X'.
Does Yuma effectively surround each include with an implicit #ifndef (= i.e. the only the first include of a submodule is parsed)?
Is that correct or is leaf a an int32 and no problem?
(Looks like a problem to me.)

/martin
Andy
 
--=_6eb762321fdacc413c36c6dee448f3b7-- From lhotka@nic.cz Fri Feb 22 08:40:29 2013 Return-Path: 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 00C6D21F8E0B for ; Fri, 22 Feb 2013 08:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 H+nebz-JvqKH for ; Fri, 22 Feb 2013 08:40:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCC821F8DFF for ; Fri, 22 Feb 2013 08:40:28 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 588CF13F9D2; Fri, 22 Feb 2013 17:40:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361551227; bh=7eaDUtE7/ole0ks3OTvB4gYrJEkK/pbO5JugXjnXc6w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=n+9qMXI/igT69C+k086mOTH/OCKRi5qW+zD3Vy9qdYuGJm6oJH5iGDN6d0dEX7atD bDxC+HR4AooCtZt/wWh/WDCaW0ODwSZNMT7YrzKx5SzR/tdPtMB5CEp/OibOv+0/vn 2dJUYzeQGPpj0VncUOnSncpMgvI55G5daUrKVqOE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20130222.172257.357766029.mbj@tail-f.com> Date: Fri, 22 Feb 2013 17:40:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82AE66C6-3522-42DB-AFD0-99D0BF466CD5@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:40:29 -0000 On Feb 22, 2013, at 5:22 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >>> But what about collisions? Compare w/ #ifndef. >>=20 >> With transitive inclusions, collisions have to be avoided in any >> case. >=20 > Exactly. But with the current text, collisions are avoided, since it > is only the module that "incorporates" the contents of the > submodules. Yes, but that means non-transitive inclusion. It would be worthwhile to = consider pros and cons of all three options. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Fri Feb 22 08:46:30 2013 Return-Path: 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 8F2CF21F85FE for ; Fri, 22 Feb 2013 08:46:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cDQJBNGhXnp for ; Fri, 22 Feb 2013 08:46:30 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1058821F85D0 for ; Fri, 22 Feb 2013 08:46:30 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DFF5D1200AF6; Fri, 22 Feb 2013 17:46:28 +0100 (CET) Date: Fri, 22 Feb 2013 17:46:28 +0100 (CET) Message-Id: <20130222.174628.319070140.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:46:30 -0000 Andy Bierman wrote: > With your interpretation, how would the following corner-case be handled? > > module A { > include B; > typedef X { type string; } > } > > submodule B { > include C; > leaf a { type a:X; } > } > > submodule C { > typedef X { type int32; } > } This would be an error b/c A does not include C. If A included C, it would be a duplicate definition error. /martin From mbj@tail-f.com Fri Feb 22 08:47:44 2013 Return-Path: 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 98B0521F866D for ; Fri, 22 Feb 2013 08:47:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CMMoGY-Lw8s for ; Fri, 22 Feb 2013 08:47:44 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1921F85D0 for ; Fri, 22 Feb 2013 08:47:43 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 227D31200AF6; Fri, 22 Feb 2013 17:47:43 +0100 (CET) Date: Fri, 22 Feb 2013 17:47:42 +0100 (CET) Message-Id: <20130222.174742.373825508.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: <20130222.174628.319070140.mbj@tail-f.com> References: <20130222.172257.357766029.mbj@tail-f.com> <20130222.174628.319070140.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:47:44 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: > > With your interpretation, how would the following corner-case be handled? > > > > module A { > > include B; > > typedef X { type string; } > > } > > > > submodule B { > > include C; > > leaf a { type a:X; } > > } > > > > submodule C { > > typedef X { type int32; } > > } > > This would be an error b/c A does not include C. > > If A included C, it would be a duplicate definition error. Sorry, this was for alternative (1). In alternative (3), this would be legal and type X is exported from A as a string. /martin From lhotka@nic.cz Fri Feb 22 08:50:23 2013 Return-Path: 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 EFF3B21F8E5D for ; Fri, 22 Feb 2013 08:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 Ke14Ynm+wCcx for ; Fri, 22 Feb 2013 08:50:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3EED621F8E45 for ; Fri, 22 Feb 2013 08:50:22 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7BC1613F9D2; Fri, 22 Feb 2013 17:50:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361551821; bh=Olt6QES2jQD2xRjmq/R3gUuuGXUpR5jIkIq8pNjO+yk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Nls/rZbEPcbbrH5hw1tHYpPvaS5TcSjVtfooneJkrLR1bABMzw6jywpp4TTG4vkWY eS7X4xFrknMi6wpYbwBAk71v4zDuLSvdSMmePImVf66slFz7Or/ZKyLP5AfTfGtROO +xzpjiBzZdISxSVWsbsS4lZ9ecDNxaQFPqAn3A3o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 17:50:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:50:23 -0000 On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund = wrote: > > > But what about collisions? Compare w/ #ifndef. > > > > With transitive inclusions, collisions have to be avoided in any > > case. >=20 > Exactly. But with the current text, collisions are avoided, since it > is only the module that "incorporates" the contents of the > submodules. >=20 >=20 >=20 > IMO, for export purposes, submodules are conceptually flat -- they all = contribute > to the module namespace. The compiler has to detect any naming = collisions for the > entire module namespace. >=20 > With your interpretation, how would the following corner-case be = handled? >=20 > module A { > include B; > typedef X { type string; } > } >=20 > submodule B { > include C; > leaf a { type a:X; } > } >=20 > submodule C { > typedef X { type int32; } > } >=20 With scenario (3), leaf "a" would be int32, and for a module importing = A, the X type would be an alias for string. With scenario (1), it is an = error because B includes C but A doesn't. Lada > In Yuma this would be a duplicate name error for 'X'. > Is that correct or is leaf a an int32 and no problem? > (Looks like a problem to me.) >=20 >=20 >=20 > /martin >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Feb 22 08:51:03 2013 Return-Path: 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 8195D21F8E98 for ; Fri, 22 Feb 2013 08:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 xFb8r5jt6aOQ for ; Fri, 22 Feb 2013 08:51:02 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD621F8E3C for ; Fri, 22 Feb 2013 08:51:02 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id 13so954844iea.14 for ; Fri, 22 Feb 2013 08:51:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ZBT4hHNUO+ezpCJy1HWRebx1V0ydEus4V6/jQ8OHWzs=; b=hQ/Qp4hnbzDkTaxGuIxjdWoajgyE8nBe7KJ88QnUb1WJp4wpJkLXRnT+wQSVy6HzYL TBwuaffvW8MnZZbH2JaoqNHF4zjNo3sKl7RYncadIIUoCZHn2/rKG4Pp7yTiuNxoSE9y 3NQETegvaEnm7u0HsdBAPO47lxsfURAiUFsOrdQQxxoj48rC5zXODS/DpbJ0QMKN8FVD 23If7rYj+liPZnFvUPWKzYMGowBSJj+e+63jYh7digj4jfXO2NcbA7NMrOX8PbSkRBeS EKij3H9HPKXYycRwwCOTvQUGMxQ2IDJSpJ9JXMEiHOKY2opFQRteVBcjU0Zd2DrQWTxs kz5Q== MIME-Version: 1.0 X-Received: by 10.50.12.133 with SMTP id y5mr15324769igb.108.1361551862220; Fri, 22 Feb 2013 08:51:02 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 08:51:02 -0800 (PST) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> Date: Fri, 22 Feb 2013 08:51:02 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=14dae9340f1d1747cb04d652ff50 X-Gm-Message-State: ALoCoQmKs6U2kFDopYWyP3N0DVMS5m3bZGwYLkILFJInjjeTa+iJKUbXrlDNFr0MuKcSinPRDlIt Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:51:03 -0000 --14dae9340f1d1747cb04d652ff50 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansford wrote: > ** > > > > On 22.02.2013 16:33, Andy Bierman wrote: > > > > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: > >> Ladislav Lhotka wrote: >> > >> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >> > > But what about collisions? Compare w/ #ifndef. >> > >> > With transitive inclusions, collisions have to be avoided in any >> > case. >> >> Exactly. But with the current text, collisions are avoided, since it >> is only the module that "incorporates" the contents of the >> submodules. >> >> IMO, for export purposes, submodules are conceptually flat -- they all > contribute > to the module namespace. The compiler has to detect any naming collisions > for the > entire module namespace. > With your interpretation, how would the following corner-case be handled? > module A { > include B; > typedef X { type string; } > } > submodule B { > include C; > leaf a { type a:X; } > } > submodule C { > typedef X { type int32; } > } > In Yuma this would be a duplicate name error for 'X'. > > Does Yuma effectively surround each include with an implicit #ifndef > (i.e. the only the first include of a submodule is parsed)? > yes. Since a submodule is only parsed once, it doesn't matter how many includes appear for it (main module or submodules). There is no clear text that says either implementation strategy is right or wrong. IMO, the Yuma approach is more user-friendly but Martin thinks listing all the submodules in the main module is more user-friendly. Is that correct or is leaf a an int32 and no problem? > (Looks like a problem to me.) > >> >> /martin > > Andy > > > Andy --14dae9340f1d1747cb04d652ff50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 8:39 AM, Jonatha= n Hansford <Jonathan@hansfords.net> wrote:

=C2=A0

On 22.02.2013 16:33, Andy Bierman wrote:



On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklun= d <mbj@tail-f.= com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> O= n Feb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > But what about collisions? =C2=A0Compare w/ #ifndef.
> > With transitive inclusions, collisions have to be avoided in any
= > case.

Exactly. =C2=A0But with the current text, collisions ar= e avoided, since it
is only the module that "incorporates" the contents of the
s= ubmodules.

IMO, for export purposes, submodules are conceptually flat -- they all= contribute
to the module namespace. =C2=A0The compiler has to detect any naming c= ollisions for the
entire module namespace.
With your interpretation, how would the following corner-case be handl= ed?
module A {
=C2=A0 include B;
=C2=A0 typedef X { type string; }
}
submodule B {
=C2=A0 include C;
=C2=A0 leaf a { type a:X; }
}
submodule C {
=C2=A0 typedef X { type int32; }
}
In Yuma this would be a duplicate name error for 'X'.
Does Yuma effectively surround each include with an implicit #ifndef (= i.e. the only the first include of a submodule is parsed)?

yes.
Since a submodule is only = parsed once, it doesn't matter how many includes
appear for it (main module or submodules).

Th= ere is no clear text that says either implementation strategy is right or w= rong.
IMO, the Yuma approach is more user-friendly but Martin thi= nks listing all the
submodules in the main module is more user-friendly.

Is that correct or is leaf a an int32 and no problem?
(Looks like a problem to me.)

/martin
Andy
=C2=A0

Andy

=
--14dae9340f1d1747cb04d652ff50-- From lhotka@nic.cz Fri Feb 22 08:58:08 2013 Return-Path: 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 AE19521F8E7B for ; Fri, 22 Feb 2013 08:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 s7HuD8hoQXCS for ; Fri, 22 Feb 2013 08:58:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E458421F8E7A for ; Fri, 22 Feb 2013 08:58:07 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 337FB13F9D2; Fri, 22 Feb 2013 17:58:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361552287; bh=oUm51bkhhBd5YgW67ee0tYpZF2nj8+WOu3lxHozXsYQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sbvPzdWIYXUJDGwSKFQSN/ISeNNpqQLQGNFQ+Q9uwBC7NKr92nqp50ODYO5eRXDoM FncuoysMdTHi6/hwG2XeFQoe3UGmnsb8AkPSmTcNpimYwjHtTrpp4ZXNrfy8frOR5b SHCmbyrHhzG6/x0vpuXVZgQrjQL7sqNt6wwIc/CY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 17:58:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BE79185-5436-4898-876F-AD9B3AF923BC@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:58:08 -0000 On Feb 22, 2013, at 5:51 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansford = wrote: > =20 > On 22.02.2013 16:33, Andy Bierman wrote: >=20 >>=20 >>=20 >> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund = wrote: >> Ladislav Lhotka wrote: >> > >> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund = wrote: >> > > But what about collisions? Compare w/ #ifndef. >> > >> > With transitive inclusions, collisions have to be avoided in any >> > case. >>=20 >> Exactly. But with the current text, collisions are avoided, since it >> is only the module that "incorporates" the contents of the >> submodules. >>=20 >> IMO, for export purposes, submodules are conceptually flat -- they = all contribute >> to the module namespace. The compiler has to detect any naming = collisions for the >> entire module namespace. >> With your interpretation, how would the following corner-case be = handled? >> module A { >> include B; >> typedef X { type string; } >> } >> submodule B { >> include C; >> leaf a { type a:X; } >> } >> submodule C { >> typedef X { type int32; } >> } >> In Yuma this would be a duplicate name error for 'X'. > Does Yuma effectively surround each include with an implicit #ifndef = (i.e. the only the first include of a submodule is parsed)? >=20 > yes. > Since a submodule is only parsed once, it doesn't matter how many = includes > appear for it (main module or submodules). I have one more question. If we have > module A { > include B; > } >=20 > submodule B { > include C; > leaf a { type a:X; } > } >=20 > submodule C { > typedef X { type int32; } > } does Yuma allow to use type X within module A? Lada >=20 > There is no clear text that says either implementation strategy is = right or wrong. > IMO, the Yuma approach is more user-friendly but Martin thinks listing = all the > submodules in the main module is more user-friendly. >=20 >> Is that correct or is leaf a an int32 and no problem? >> (Looks like a problem to me.) >>=20 >> /martin >> Andy > =20 >=20 > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jonathan@hansfords.net Fri Feb 22 09:01:31 2013 Return-Path: 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 6339B21F8E92 for ; Fri, 22 Feb 2013 09:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NuM7NthxcJkN for ; Fri, 22 Feb 2013 09:01:30 -0800 (PST) Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 423EE21F888B for ; Fri, 22 Feb 2013 09:01:30 -0800 (PST) Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id 3V1U1l0034CLSd801V1VtV; Fri, 22 Feb 2013 17:01:29 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.0 cv=b6RsFK6x c=1 sm=1 a=VrPob/PGR4vzCiwW53VWbQ==:17 a=F3ckWTiu8f8A:10 a=fIUNk3G47tUA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=0Bzu9jTXAAAA:8 a=P2dVUpLXpukA:10 a=u07AKapRAAAA:8 a=UwJpJEMxb6_4E4t2FzAA:9 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=XqebBV1NYWwA:10 a=otr6lp3kgbNUDxPgoDYA:9 a=_W_S_7VecoQA:10 a=ptOhJ4T9pZxDgWJ2:21 a=VrPob/PGR4vzCiwW53VWbQ==:117 X-AUTH: hansfords+us:2500 Received: from host81-136-210-13.in-addr.btopenworld.com ([81.136.210.13]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 22 Feb 2013 17:01:28 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c17e5a71548852e41486496d33a77cc9" Date: Fri, 22 Feb 2013 17:01:28 +0000 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> Message-ID: <7c04a3655933e3d5cf305100d7214fd0@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.2 X-Originating-IP: [81.136.210.13] Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:01:31 -0000 --=_c17e5a71548852e41486496d33a77cc9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 22.02.2013 16:51, Andy Bierman wrote: > On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansford wrote: > >> On 22.02.2013 16:33, Andy Bierman wrote: >> >>> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund wrote: >>> >>>> Ladislav Lhotka wrote: >>>> > >>>> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: >>>> > > But what about collisions? Compare w/ #ifndef. >>>> > >>>> > With transitive inclusions, collisions have to be avoided in any >>>> > case. >>>> >>>> Exactly. But with the current text, collisions are avoided, since it >>>> is only the module that "incorporates" the contents of the >>>> submodules. >>> >>> IMO, for export purposes, submodules are conceptually flat -- they all contribute >>> to the module namespace. The compiler has to detect any naming collisions for the >>> entire module namespace. >>> With your interpretation, how would the following corner-case be handled? >>> module A { >>> include B; >>> typedef X { type string; } >>> } >>> submodule B { >>> include C; >>> leaf a { type a:X; } >>> } >>> submodule C { >>> typedef X { type int32; } >>> } >>> In Yuma this would be a duplicate name error for 'X'. >> >> Does Yuma effectively surround each include with an implicit #ifndef (i.e. the only the first include of a submodule is parsed)? > > yes. > Since a submodule is only parsed once, it doesn't matter how many includes > appear for it (main module or submodules). > There is no clear text that says either implementation strategy is right or wrong. > IMO, the Yuma approach is more user-friendly but Martin thinks listing all the > submodules in the main module is more user-friendly. To my mind, if something from a submodule is directly used in the module then it is more "user-friendly" (i.e. intuitive) for that submodule to be included by the module. If a submodule's content is only directly used in another submodule it is more "user-friendly" for that submodule to be included in the submodule. Jonathan >>> Is that correct or is leaf a an int32 and no problem? >>> (Looks like a problem to me.) >>> >>>> /martin >>> >>> Andy > > Andy Links: ------ [1] mailto:lhotka@nic.cz [2] mailto:mbj@tail-f.com [3] mailto:mbj@tail-f.com [4] mailto:Jonathan@hansfords.net --=_c17e5a71548852e41486496d33a77cc9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 22.02.2013 16:51, Andy Bierman wrote:



On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansfo= rd <Jonathan@hansfords= =2Enet> wrote:

On 22.02.2013 16:33, Andy Bierman wrote:



On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklun= d <mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On F= eb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > But what about collis= ions?  Compare w/ #ifndef.
>
> With transitive inclu= sions, collisions have to be avoided in any
> case.

Ex= actly.  But with the current text, collisions are avoided, since it is only the module that "incorporates" the contents of the
submod= ules.

IMO, for export purposes, submodules are conceptually flat -- they all= contribute
to the module namespace.  The compiler has to detect any naming c= ollisions for the
entire module namespace.
With your interpretation, how would the following corner-case be handl= ed?
module A {
  include B;
  typedef X { type string; }
}
submodule B {
  include C;
  leaf a { type a:X; }
}
submodule C {
  typedef X { type int32; }
}
In Yuma this would be a duplicate name error for 'X'.
Does Yuma effectively surround each include with an implicit #ifndef (= i.e. the only the first include of a submodule is parsed)?
yes.
Since a submodule is only parsed once, it doesn't matter how many incl= udes
appear for it (main module or submodules).
There is no clear text that says either implementation strategy is rig= ht or wrong.
IMO, the Yuma approach is more user-friendly but Martin thinks listing= all the
submodules in the main module is more user-friendly.
To my mind, if something from a submodule is directly used in the modu= le then it is more "user-friendly" (i.e. intuitive) for that submodule to b= e included by the module. If a submodule's content is only directly used in= another submodule it is more "user-friendly" for that submodule to be incl= uded in the submodule.
Jonathan
Is that correct or is leaf a an int32 and no problem?
(Looks like a problem to me.)

/martin
Andy
Andy
 
--=_c17e5a71548852e41486496d33a77cc9-- From andy@yumaworks.com Fri Feb 22 09:03:17 2013 Return-Path: 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 9A19921F8ED0 for ; Fri, 22 Feb 2013 09:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 BHqCHzcCBNAI for ; Fri, 22 Feb 2013 09:03:17 -0800 (PST) Received: from mail-ie0-x230.google.com (ie-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB24B21F8EB9 for ; Fri, 22 Feb 2013 09:03:16 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id k13so953940iea.35 for ; Fri, 22 Feb 2013 09:03:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=KpjGYmkRu0652UBVKtWsnBj/Z68SsjZr/msUVWMaBOY=; b=g6w/5662agAxvbuT9Lmdonv8u87hZJyAj5F5k8PSFKVUuPSD57gRMLU/val9lEUjnV 9hHA6lV2c0GBJqXFV2QEASmps7NOu/xPOMGdka5qVQhDXik9rDi711DapRxgc4v5i11C JYpe5HvdoUCOdAQhLrkOSPEWZlFC8WB4/q3d/boGkcTjmRF10I3bQVSBssuoHUxJyB1v hEbuyVGsoKsadCoRgYU/sp06pDAK6lqVEw/SRTrVcYsXy4Cgshk+Qcuqq6VUQH/pPFl1 75UXBqZeUiIJAr8paVCoidnR4v2+JaPYnc8dyCoiQRBbW4heka06j7B1lVQkNDYdOrPT Iy0Q== MIME-Version: 1.0 X-Received: by 10.50.208.40 with SMTP id mb8mr8567904igc.91.1361552596489; Fri, 22 Feb 2013 09:03:16 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 09:03:16 -0800 (PST) In-Reply-To: References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> Date: Fri, 22 Feb 2013 09:03:16 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae9340345db562504d6532a0f X-Gm-Message-State: ALoCoQlPsJ9UhqxsNNw5AwwUoKLFEVlJio6AC8YD0ybFZTU93aOj7QDvkeCPXTSSgmx+mfNoqLy4 Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:03:17 -0000 --14dae9340345db562504d6532a0f Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka wrote: > > On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: > > > > > > > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund > wrote: > > Ladislav Lhotka wrote: > > > > > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: > > > > But what about collisions? Compare w/ #ifndef. > > > > > > With transitive inclusions, collisions have to be avoided in any > > > case. > > > > Exactly. But with the current text, collisions are avoided, since it > > is only the module that "incorporates" the contents of the > > submodules. > > > > > > > > IMO, for export purposes, submodules are conceptually flat -- they all > contribute > > to the module namespace. The compiler has to detect any naming > collisions for the > > entire module namespace. > > > > With your interpretation, how would the following corner-case be handled? > > > > module A { > > include B; > > typedef X { type string; } > > } > > > > submodule B { > > include C; > > leaf a { type a:X; } > > } > > > > submodule C { > > typedef X { type int32; } > > } > > > > With scenario (3), leaf "a" would be int32, and for a module importing A, > the X type would be an alias for string. With scenario (1), it is an error > because B includes C but A doesn't. > > IMO, any compiler should report an error because it has to parse module A in order to get to submodule C. It must include B and then C and then must parse the duplicate typedef. But my example seems to be legal YANG if submodules are treated as separate namespaces. I don't think there is any text that says A MUST include C. If it does there will be a conflict, but if C is only visible to B, and the only typedef X visible to B is int32, the compiler must accept it, and the typedef "X" has a hidden different version within the module. > Lada > Andy > > > In Yuma this would be a duplicate name error for 'X'. > > Is that correct or is leaf a an int32 and no problem? > > (Looks like a problem to me.) > > > > > > > > /martin > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --14dae9340345db562504d6532a0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 8:50 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

>
>
> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
> >
> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > > But what about collisions? =C2=A0Compare w/ #ifndef.
> >
> > With transitive inclusions, collisions have to be avoided in any<= br> > > case.
>
> Exactly. =C2=A0But with the current text, collisions are avoided, sinc= e it
> is only the module that "incorporates" the contents of the > submodules.
>
>
>
> IMO, for export purposes, submodules are conceptually flat -- they all= contribute
> to the module namespace. =C2=A0The compiler has to detect any naming c= ollisions for the
> entire module namespace.
>
> With your interpretation, how would the following corner-case be handl= ed?
>
> module A {
> =C2=A0 include B;
> =C2=A0 typedef X { type string; }
> }
>
> submodule B {
> =C2=A0 include C;
> =C2=A0 leaf a { type a:X; }
> }
>
> submodule C {
> =C2=A0 typedef X { type int32; }
> }
>

With scenario (3), leaf "a" would be int32, and for a module impo= rting A, the X type would be an alias for string. With scenario (1), it is = an error because B includes C but A doesn't.


IMO, any compiler should report an err= or because it has to parse module A
in order to get to submodule = C. =C2=A0It must include B and then C and then
must parse the dup= licate typedef.

But my example seems to be legal YANG if submodules are= treated as separate namespaces.
I don't think there is any t= ext that says A MUST include C.
If it does there will be a confli= ct, but if C is only visible to B,
and the only typedef X visible to B is int32, the compiler must accept= it,
and the typedef "X" has a hidden different version= within the module.

=C2=A0
Lada


Andy
=C2= =A0

> In Yuma this would be a duplicate name error for 'X'.
> Is that correct or is leaf a an int32 and no problem?
> (Looks like a problem to me.)
>
>
>
> /martin
>
> Andy
>

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





--14dae9340345db562504d6532a0f-- From andy@yumaworks.com Fri Feb 22 09:06:20 2013 Return-Path: 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 3B41121F8EB8 for ; Fri, 22 Feb 2013 09:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 72vyhNIvDl3R for ; Fri, 22 Feb 2013 09:06:19 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 70A5421F8E93 for ; Fri, 22 Feb 2013 09:06:19 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so953036ieb.23 for ; Fri, 22 Feb 2013 09:06:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=eY1lB4ukxiKxQzL5oWwd5kzZ9vpLig0SsgDwOywVTfs=; b=ej8ta40c6/HuwpmMY3ROLU9gaiJ3GQFxlE5YX5XLiO60RG186kNZ4IxARtLf3BE9UE iPHKq6Hdh04xgu95sCrdPGLDwAOgUa4xJpC4+y5b1vbe7XRokxQ54XA1HNezikeoAS6o 3k1UI77PMn+FOIakGcTgoOsxN2+rrs/rW+oL1CIklBsVC365aqqDd3rTHGiHrTvMV8ur ym+jbKJBePeWtrRKCyFd1EgilOvR5+3MKGZFd2tblns1bVzbn59/U+pJb9CJ3SlP3rg6 KXrmVHsX62GnCPEtf68dK5lny3Hk3UL+1ZR3cpmqOo/1Z38cP8eItqPIgI27EEP1Dag3 OL6g== MIME-Version: 1.0 X-Received: by 10.50.183.167 with SMTP id en7mr15212011igc.58.1361552779045; Fri, 22 Feb 2013 09:06:19 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 09:06:18 -0800 (PST) In-Reply-To: <8BE79185-5436-4898-876F-AD9B3AF923BC@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <8BE79185-5436-4898-876F-AD9B3AF923BC@nic.cz> Date: Fri, 22 Feb 2013 09:06:18 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=14dae9340ca3bcebbe04d6533519 X-Gm-Message-State: ALoCoQnjD/d9RGn60Rr2LYUMQdkEOeYoB1/nyqrgSzefPvDjyLy12eS0dOzOv6TY7C2xD0SLljq4 Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:06:20 -0000 --14dae9340ca3bcebbe04d6533519 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 8:58 AM, Ladislav Lhotka wrote: > > On Feb 22, 2013, at 5:51 PM, Andy Bierman wrote: > > > > > > > On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansford < > Jonathan@hansfords.net> wrote: > > > > On 22.02.2013 16:33, Andy Bierman wrote: > > > >> > >> > >> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund > wrote: > >> Ladislav Lhotka wrote: > >> > > >> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund wrote: > >> > > But what about collisions? Compare w/ #ifndef. > >> > > >> > With transitive inclusions, collisions have to be avoided in any > >> > case. > >> > >> Exactly. But with the current text, collisions are avoided, since it > >> is only the module that "incorporates" the contents of the > >> submodules. > >> > >> IMO, for export purposes, submodules are conceptually flat -- they all > contribute > >> to the module namespace. The compiler has to detect any naming > collisions for the > >> entire module namespace. > >> With your interpretation, how would the following corner-case be > handled? > >> module A { > >> include B; > >> typedef X { type string; } > >> } > >> submodule B { > >> include C; > >> leaf a { type a:X; } > >> } > >> submodule C { > >> typedef X { type int32; } > >> } > >> In Yuma this would be a duplicate name error for 'X'. > > Does Yuma effectively surround each include with an implicit #ifndef > (i.e. the only the first include of a submodule is parsed)? > > > > yes. > > Since a submodule is only parsed once, it doesn't matter how many > includes > > appear for it (main module or submodules). > > I have one more question. If we have > > > module A { > > include B; > > } > > > > submodule B { > > include C; > > leaf a { type a:X; } > > } > > > > submodule C { > > typedef X { type int32; } > > } > > > does Yuma allow to use type X within module A? > > No -- it would be an unresolved identifier because there is no "include C", which tells the compiler where it is allowed to look for type X. > Lada > > Andy > > > > There is no clear text that says either implementation strategy is right > or wrong. > > IMO, the Yuma approach is more user-friendly but Martin thinks listing > all the > > submodules in the main module is more user-friendly. > > > >> Is that correct or is leaf a an int32 and no problem? > >> (Looks like a problem to me.) > >> > >> /martin > >> Andy > > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --14dae9340ca3bcebbe04d6533519 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 8:58 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

>
>
> On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansford <Jonathan@hansfords.net> wrote:
>
> On 22.02.2013 16:33, Andy Bierman wrote:
>
>>
>>
>> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> >
>> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>> > > But what about collisions? =C2=A0Compare w/ #ifndef.
>> >
>> > With transitive inclusions, collisions have to be avoided in = any
>> > case.
>>
>> Exactly. =C2=A0But with the current text, collisions are avoided, = since it
>> is only the module that "incorporates" the contents of t= he
>> submodules.
>>
>> IMO, for export purposes, submodules are conceptually flat -- they= all contribute
>> to the module namespace. =C2=A0The compiler has to detect any nami= ng collisions for the
>> entire module namespace.
>> With your interpretation, how would the following corner-case be h= andled?
>> module A {
>> =C2=A0 include B;
>> =C2=A0 typedef X { type string; }
>> }
>> submodule B {
>> =C2=A0 include C;
>> =C2=A0 leaf a { type a:X; }
>> }
>> submodule C {
>> =C2=A0 typedef X { type int32; }
>> }
>> In Yuma this would be a duplicate name error for 'X'.
> Does Yuma effectively surround each include with an implicit #ifndef (= i.e. the only the first include of a submodule is parsed)?
>
> yes.
> Since a submodule is only parsed once, it doesn't matter how many = includes
> appear for it (main module or submodules).

I have one more question. If we have

> module A {
> =C2=A0include B;
> }
>
> submodule B {
> =C2=A0include C;
> =C2=A0leaf a { type a:X; }
> }
>
> submodule C {
> =C2=A0typedef X { type int32; }
> }


does Yuma allow to use type X within module A?


No -- it would be an unresolved identi= fier because there is no "include C",
which tells the c= ompiler where it is allowed to look for type X.

=C2=A0
Lada


Andy
=C2=A0
>
> There is no clear text that says either implementation strategy is rig= ht or wrong.
> IMO, the Yuma approach is more user-friendly but Martin thinks listing= all the
> submodules in the main module is more user-friendly.
>
>> Is that correct or is leaf a an int32 and no problem?
>> (Looks like a problem to me.)
>>
>> /martin
>> Andy
>
>
> Andy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--14dae9340ca3bcebbe04d6533519-- From lhotka@nic.cz Fri Feb 22 09:12:26 2013 Return-Path: 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 8583921F8B6B for ; Fri, 22 Feb 2013 09:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 2vIBk6thiV9w for ; Fri, 22 Feb 2013 09:12:25 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id ED4A721F89AE for ; Fri, 22 Feb 2013 09:12:16 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4991713F63F; Fri, 22 Feb 2013 18:12:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361553135; bh=6X0dwDaB9KLhAFXNtizUPrvCvCaV/gXVvBlR/t0JHME=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DzWRnbbNIxOJ4eFl5zRcW3uR6VJDYOWeWNGWvp7YC56wx3JEwKTdsUTVp9UMz0TEk +4i6iTeG7ue8uE79ctJrHK+SxC6smRSFDDkqJE0Hvfq1lSDnepDmiEE3SVindu8vdn BqJK5zCPQbhSOfVTc6izM6JoHzkFIh7Q5HSyWOmk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 18:12:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:12:26 -0000 On Feb 22, 2013, at 6:03 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka = wrote: >=20 > On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: >=20 > > > > > > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund = wrote: > > Ladislav Lhotka wrote: > > > > > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund = wrote: > > > > But what about collisions? Compare w/ #ifndef. > > > > > > With transitive inclusions, collisions have to be avoided in any > > > case. > > > > Exactly. But with the current text, collisions are avoided, since = it > > is only the module that "incorporates" the contents of the > > submodules. > > > > > > > > IMO, for export purposes, submodules are conceptually flat -- they = all contribute > > to the module namespace. The compiler has to detect any naming = collisions for the > > entire module namespace. > > > > With your interpretation, how would the following corner-case be = handled? > > > > module A { > > include B; > > typedef X { type string; } > > } > > > > submodule B { > > include C; > > leaf a { type a:X; } > > } > > > > submodule C { > > typedef X { type int32; } > > } > > >=20 > With scenario (3), leaf "a" would be int32, and for a module importing = A, the X type would be an alias for string. With scenario (1), it is an = error because B includes C but A doesn't. >=20 >=20 > IMO, any compiler should report an error because it has to parse = module A > in order to get to submodule C. It must include B and then C and then > must parse the duplicate typedef. >=20 > But my example seems to be legal YANG if submodules are treated as = separate namespaces. > I don't think there is any text that says A MUST include C. > If it does there will be a conflict, but if C is only visible to B, > and the only typedef X visible to B is int32, the compiler must accept = it, > and the typedef "X" has a hidden different version within the module. Yes, and that is, I think, the essence of (3). It can be useful, for = instance, if one wants to share some definitions among multiple = submodules but doesn't want to expose them to external modules. This is = actually how I stumbled upon this whole issue. Lada >=20 > =20 > Lada >=20 >=20 > Andy > =20 >=20 > > In Yuma this would be a duplicate name error for 'X'. > > Is that correct or is leaf a an int32 and no problem? > > (Looks like a problem to me.) > > > > > > > > /martin > > > > Andy > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Feb 22 09:16:12 2013 Return-Path: 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 0E53721F8BE0 for ; Fri, 22 Feb 2013 09:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 4+8Knffp5BMh for ; Fri, 22 Feb 2013 09:16:11 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1B21F8B6B for ; Fri, 22 Feb 2013 09:16:10 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9FA3A13F63F; Fri, 22 Feb 2013 18:16:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361553369; bh=pVroE2CfLn+VjKdRZAUhfIwyz0CDelDo4dce+v4TA3c=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kaSCMII7417nAgttjSHmR+lzfItOyijHYX3tznLIzW6nAuRYTq4GxmfsOC0ITUv0P CyhSxllHHkDM6tCCvz9hedlk2Y7aOPeNUfw00P7uWoovDiK6YgxLXMt4BGzgk7zJG4 kVfsrTAMDmbZDfhE1thHzGQSGksdOISFYpYjBMX0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 18:16:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5278DA96-FFDB-45FD-A1DE-480A63CDC4B2@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <8BE79185-5436-4898-876F-AD9B3AF923BC@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:16:12 -0000 On Feb 22, 2013, at 6:06 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 8:58 AM, Ladislav Lhotka = wrote: >=20 > On Feb 22, 2013, at 5:51 PM, Andy Bierman wrote: >=20 > > > > > > On Fri, Feb 22, 2013 at 8:39 AM, Jonathan Hansford = wrote: > > > > On 22.02.2013 16:33, Andy Bierman wrote: > > > >> > >> > >> On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund = wrote: > >> Ladislav Lhotka wrote: > >> > > >> > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund = wrote: > >> > > But what about collisions? Compare w/ #ifndef. > >> > > >> > With transitive inclusions, collisions have to be avoided in any > >> > case. > >> > >> Exactly. But with the current text, collisions are avoided, since = it > >> is only the module that "incorporates" the contents of the > >> submodules. > >> > >> IMO, for export purposes, submodules are conceptually flat -- they = all contribute > >> to the module namespace. The compiler has to detect any naming = collisions for the > >> entire module namespace. > >> With your interpretation, how would the following corner-case be = handled? > >> module A { > >> include B; > >> typedef X { type string; } > >> } > >> submodule B { > >> include C; > >> leaf a { type a:X; } > >> } > >> submodule C { > >> typedef X { type int32; } > >> } > >> In Yuma this would be a duplicate name error for 'X'. > > Does Yuma effectively surround each include with an implicit #ifndef = (i.e. the only the first include of a submodule is parsed)? > > > > yes. > > Since a submodule is only parsed once, it doesn't matter how many = includes > > appear for it (main module or submodules). >=20 > I have one more question. If we have >=20 > > module A { > > include B; > > } > > > > submodule B { > > include C; > > leaf a { type a:X; } > > } > > > > submodule C { > > typedef X { type int32; } > > } >=20 >=20 > does Yuma allow to use type X within module A? >=20 >=20 > No -- it would be an unresolved identifier because there is no = "include C", > which tells the compiler where it is allowed to look for type X. But what's the point of requiring this include if there cannot be any = other X anyway? In A, you can just use the same set of top-level = definitions that any importing modules sees, even without that include. Lada >=20 > =20 > Lada >=20 >=20 > Andy > =20 > > > > There is no clear text that says either implementation strategy is = right or wrong. > > IMO, the Yuma approach is more user-friendly but Martin thinks = listing all the > > submodules in the main module is more user-friendly. > > > >> Is that correct or is leaf a an int32 and no problem? > >> (Looks like a problem to me.) > >> > >> /martin > >> Andy > > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Feb 22 09:24:02 2013 Return-Path: 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 6B9F521F880F for ; Fri, 22 Feb 2013 09:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] 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 9xZpPtYPradt for ; Fri, 22 Feb 2013 09:24:01 -0800 (PST) Received: from mail-ie0-x232.google.com (ie-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB2321F8584 for ; Fri, 22 Feb 2013 09:24:01 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so977618ieb.37 for ; Fri, 22 Feb 2013 09:24:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=odbeOq62njw96ZvQ23kTyAU7yNI8Y2b/zV6DnoHbhvA=; b=JCn5JcP8NV5FovIHR8siq0Kne5QWuh2oDsjyhEFCPXpZ4i03FKdO528gcdasE5lMYS 2q2TEx/0XOPV/ZBGuw92ah952OUfwUCcQpAak1FPQSUuFUGQR1RPbT6Iz//Whme/mlgi oDWTCiKUMDvmGCMSQK08vW2C7SJw7YYNSyHGi/Uo6G5YRnOT/+wC2oS2jPtwn1xvRF/A pCyPzZEtM9y/vPcVwi17wmhL4cBr3s9eVAsGdcnutF9u++JvqgQxHShPhh9xcpqhF05B IE4G+mnXda2ohOG28+cPsyHXZWWUPoEbC+BlN5+9Cvh1YhF3/QVVCwUWyeykbsCSfjfV wgWg== MIME-Version: 1.0 X-Received: by 10.50.7.240 with SMTP id m16mr1229794iga.91.1361553840982; Fri, 22 Feb 2013 09:24:00 -0800 (PST) Received: by 10.231.235.201 with HTTP; Fri, 22 Feb 2013 09:24:00 -0800 (PST) In-Reply-To: <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> Date: Fri, 22 Feb 2013 09:24:00 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=f46d0447976d08cb1004d6537536 X-Gm-Message-State: ALoCoQnqoHh0votOd7l/jLV5C5jzfAS1yyLYR5YiKqa3x2DpqpiubV0IKlw8zjxn42EN3Txhx72q Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:24:02 -0000 --f46d0447976d08cb1004d6537536 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 22, 2013 at 9:12 AM, Ladislav Lhotka wrote: > > On Feb 22, 2013, at 6:03 PM, Andy Bierman wrote: > > > > > > > On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka wrote: > > > > On Feb 22, 2013, at 5:33 PM, Andy Bierman wrote: > > > > > > > > > > > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund > wrote: > > > Ladislav Lhotka wrote: > > > > > > > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund > wrote: > > > > > But what about collisions? Compare w/ #ifndef. > > > > > > > > With transitive inclusions, collisions have to be avoided in any > > > > case. > > > > > > Exactly. But with the current text, collisions are avoided, since it > > > is only the module that "incorporates" the contents of the > > > submodules. > > > > > > > > > > > > IMO, for export purposes, submodules are conceptually flat -- they all > contribute > > > to the module namespace. The compiler has to detect any naming > collisions for the > > > entire module namespace. > > > > > > With your interpretation, how would the following corner-case be > handled? > > > > > > module A { > > > include B; > > > typedef X { type string; } > > > } > > > > > > submodule B { > > > include C; > > > leaf a { type a:X; } > > > } > > > > > > submodule C { > > > typedef X { type int32; } > > > } > > > > > > > With scenario (3), leaf "a" would be int32, and for a module importing > A, the X type would be an alias for string. With scenario (1), it is an > error because B includes C but A doesn't. > > > > > > IMO, any compiler should report an error because it has to parse module A > > in order to get to submodule C. It must include B and then C and then > > must parse the duplicate typedef. > > > > But my example seems to be legal YANG if submodules are treated as > separate namespaces. > > I don't think there is any text that says A MUST include C. > > If it does there will be a conflict, but if C is only visible to B, > > and the only typedef X visible to B is int32, the compiler must accept > it, > > and the typedef "X" has a hidden different version within the module. > > Yes, and that is, I think, the essence of (3). It can be useful, for > instance, if one wants to share some definitions among multiple submodules > but doesn't want to expose them to external modules. This is actually how I > stumbled upon this whole issue. > > IMO, (C) is quite dangerous and complicated. 1 namespace per module is plenty. I never liked submodules in the first place and this would make YANG even more complicated. At this point there is absolutely no difference between submodules and modules, and we might as well get rid of them. I much prefer Kent's solution he made last year (I am adapting it): -- get rid of submodules completely and allow modules to contribute to an existing namespace -- remove the restriction of 1 module == 1 XML namespace. That makes YANG way simpler, and there is absolutely no need for submodules whatsoever. But that is kind of radical and we are not working on YANG 2.0. But someday if we do, the issue will come up again. > Lada > Andy > > > > > > > Lada > > > > > > Andy > > > > > > > In Yuma this would be a duplicate name error for 'X'. > > > Is that correct or is leaf a an int32 and no problem? > > > (Looks like a problem to me.) > > > > > > > > > > > > /martin > > > > > > Andy > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --f46d0447976d08cb1004d6537536 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, 2013 at 9:12 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

>
>
> On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On Feb 22, 2013, at 5:33 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > >
> > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > > > But what about collisions? =C2=A0Compare w/ #ifndef. > > >
> > > With transitive inclusions, collisions have to be avoided in= any
> > > case.
> >
> > Exactly. =C2=A0But with the current text, collisions are avoided,= since it
> > is only the module that "incorporates" the contents of = the
> > submodules.
> >
> >
> >
> > IMO, for export purposes, submodules are conceptually flat -- the= y all contribute
> > to the module namespace. =C2=A0The compiler has to detect any nam= ing collisions for the
> > entire module namespace.
> >
> > With your interpretation, how would the following corner-case be = handled?
> >
> > module A {
> > =C2=A0 include B;
> > =C2=A0 typedef X { type string; }
> > }
> >
> > submodule B {
> > =C2=A0 include C;
> > =C2=A0 leaf a { type a:X; }
> > }
> >
> > submodule C {
> > =C2=A0 typedef X { type int32; }
> > }
> >
>
> With scenario (3), leaf "a" would be int32, and for a module= importing A, the X type would be an alias for string. With scenario (1), i= t is an error because B includes C but A doesn't.
>
>
> IMO, any compiler should report an error because it has to parse modul= e A
> in order to get to submodule C. =C2=A0It must include B and then C and= then
> must parse the duplicate typedef.
>
> But my example seems to be legal YANG if submodules are treated as sep= arate namespaces.
> I don't think there is any text that says A MUST include C.
> If it does there will be a conflict, but if C is only visible to B, > and the only typedef X visible to B is int32, the compiler must accept= it,
> and the typedef "X" has a hidden different version within th= e module.

Yes, and that is, I think, the essence of (3). It can be useful, for instan= ce, if one wants to share some definitions among multiple submodules but do= esn't want to expose them to external modules. This is actually how I s= tumbled upon this whole issue.


IMO, (C) is quite dangerous and compli= cated. 1 namespace per module is plenty.
I never liked submodules= in the first place and this would make YANG even more complicated.
At this point there is absolutely no difference between submodules and= modules, and
we might as well get rid of them.

I much prefer Kent's solution he made last year (I am adapting = it):

=C2=A0-- get rid of submodules completely and allow mod= ules to contribute
to an existing namespace -- remove the restric= tion of 1 module =3D=3D 1 XML namespace.
That makes YANG way simp= ler, and there is absolutely no need for submodules
whatsoever.

But that is kind of radical and w= e are not working on YANG 2.0.
But someday if we do, the issue wi= ll come up again.


=C2=A0
Lada

Andy

=C2= =A0

>
>
> Lada
>
>
> Andy
>
>
> > In Yuma this would be a duplicate name error for 'X'.
> > Is that correct or is leaf a an int32 and no problem?
> > (Looks like a problem to me.)
> >
> >
> >
> > /martin
> >
> > Andy
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--f46d0447976d08cb1004d6537536-- From lhotka@nic.cz Fri Feb 22 09:39:43 2013 Return-Path: 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 7779F21F8E63 for ; Fri, 22 Feb 2013 09:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 o+tREdboJ+M1 for ; Fri, 22 Feb 2013 09:39:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D521F8E3A for ; Fri, 22 Feb 2013 09:39:42 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E0BCC13F63F; Fri, 22 Feb 2013 18:39:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1361554782; bh=GCkIqGh6ui/x/QntF1iLytCsfrZe6CMZCFlfaGyWoyo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QghTf6bGWkrmNLyTE3wX3h0zS8+4nMs2OQpulYg7jR84VCby2R9QYKEqA61hDAp48 HwwSZm7+fhOFlZeH/82j2SExzUAsQli3gEZUthjkl/YMHK4sHE6S5qOd30xH2ocet5 gobtJyeqpYID7F1WXqrxgaRBG1N2SgDkhQlRxFX0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 22 Feb 2013 18:39:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <759CBB05-7B5F-45C2-AE4A-A76EA9A20C7F@nic.cz> References: <20130222.161941.453515630.mbj@tail-f.com> <04E80624-7F7E-4265-BB89-C06F104B62E3@nic.cz> <20130222.172257.357766029.mbj@tail-f.com> <11D8A662-9EC4-4488-8345-CC01A9176A3C@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] include X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:39:43 -0000 On Feb 22, 2013, at 6:24 PM, Andy Bierman wrote: >=20 >=20 > On Fri, Feb 22, 2013 at 9:12 AM, Ladislav Lhotka = wrote: >=20 > On Feb 22, 2013, at 6:03 PM, Andy Bierman wrote: >=20 > > > > > > On Fri, Feb 22, 2013 at 8:50 AM, Ladislav Lhotka = wrote: > > > > On Feb 22, 2013, at 5:33 PM, Andy Bierman = wrote: > > > > > > > > > > > On Fri, Feb 22, 2013 at 8:22 AM, Martin Bjorklund = wrote: > > > Ladislav Lhotka wrote: > > > > > > > > On Feb 22, 2013, at 4:19 PM, Martin Bjorklund = wrote: > > > > > But what about collisions? Compare w/ #ifndef. > > > > > > > > With transitive inclusions, collisions have to be avoided in any > > > > case. > > > > > > Exactly. But with the current text, collisions are avoided, since = it > > > is only the module that "incorporates" the contents of the > > > submodules. > > > > > > > > > > > > IMO, for export purposes, submodules are conceptually flat -- they = all contribute > > > to the module namespace. The compiler has to detect any naming = collisions for the > > > entire module namespace. > > > > > > With your interpretation, how would the following corner-case be = handled? > > > > > > module A { > > > include B; > > > typedef X { type string; } > > > } > > > > > > submodule B { > > > include C; > > > leaf a { type a:X; } > > > } > > > > > > submodule C { > > > typedef X { type int32; } > > > } > > > > > > > With scenario (3), leaf "a" would be int32, and for a module = importing A, the X type would be an alias for string. With scenario (1), = it is an error because B includes C but A doesn't. > > > > > > IMO, any compiler should report an error because it has to parse = module A > > in order to get to submodule C. It must include B and then C and = then > > must parse the duplicate typedef. > > > > But my example seems to be legal YANG if submodules are treated as = separate namespaces. > > I don't think there is any text that says A MUST include C. > > If it does there will be a conflict, but if C is only visible to B, > > and the only typedef X visible to B is int32, the compiler must = accept it, > > and the typedef "X" has a hidden different version within the = module. >=20 > Yes, and that is, I think, the essence of (3). It can be useful, for = instance, if one wants to share some definitions among multiple = submodules but doesn't want to expose them to external modules. This is = actually how I stumbled upon this whole issue. >=20 >=20 > IMO, (C) is quite dangerous and complicated. 1 namespace per module is = plenty. > I never liked submodules in the first place and this would make YANG = even more complicated. > At this point there is absolutely no difference between submodules and = modules, and > we might as well get rid of them. >=20 > I much prefer Kent's solution he made last year (I am adapting it): >=20 > -- get rid of submodules completely and allow modules to contribute > to an existing namespace -- remove the restriction of 1 module =3D=3D = 1 XML namespace. > That makes YANG way simpler, and there is absolutely no need for = submodules > whatsoever. >=20 > But that is kind of radical and we are not working on YANG 2.0. > But someday if we do, the issue will come up again. And how about a simple textual include mechanism along the lines of = #include in cpp or rather in XSLT, see http://www.w3.org/TR/1999/REC-xslt-19991116#include Lada >=20 >=20 > =20 > Lada >=20 > Andy >=20 > =20 >=20 > > > > > > Lada > > > > > > Andy > > > > > > > In Yuma this would be a duplicate name error for 'X'. > > > Is that correct or is leaf a an int32 and no problem? > > > (Looks like a problem to me.) > > > > > > > > > > > > /martin > > > > > > Andy > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Fri Feb 22 09:41:17 2013 Return-Path: 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 482C421F8E92 for ; Fri, 22 Feb 2013 09:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.02 X-Spam-Level: X-Spam-Status: No, score=-4.02 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 07oSY2OGF5HY for ; Fri, 22 Feb 2013 09:41:16 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id E25F221F8E4A for ; Fri, 22 Feb 2013 09:41:15 -0800 (PST) Received: from mail11-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Feb 2013 17:41:13 +0000 Received: from mail11-db3 (localhost [127.0.0.1]) by mail11-db3-R.bigfish.com (Postfix) with ESMTP id A4B6AA0205; Fri, 22 Feb 2013 17:41:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh304l1155h) Received: from mail11-db3 (localhost.localdomain [127.0.0.1]) by mail11-db3 (MessageSwitch) id 1361554870830816_3940; Fri, 22 Feb 2013 17:41:10 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.231]) by mail11-db3.bigfish.com (Postfix) with ESMTP id BD6F244001C; Fri, 22 Feb 2013 17:41:10 +0000 (UTC) Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Feb 2013 17:41:10 +0000 Received: from DBXPRD0611HT002.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 22 Feb 2013 17:41:09 +0000 Message-ID: <014301ce1123$533f2da0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Martin Bjorklund References: <20130206175114.GD83997@elstar.local><341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com><20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> Date: Fri, 22 Feb 2013 17:37:34 +0000 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-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com Cc: dthaler@microsoft.com, netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:41:17 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Friday, February 22, 2013 1:10 PM > Hi, > > Juergen Schoenwaelder wrote: > > On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > > Note that zone indexes are properties of an interface, and I'm not seeing > > > them as interface properties in > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > The relevant information is in the definition of generic interfaces, > > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We > > have an interface/name and an interface/if-index for every interface. > > The IP model extends the generic interface model with IP specific > > configuration information. So I think we are fine. > > 6021 (and bis) says: > > For link-local addresses, the zone index will > typically be the interface index number or the name of an > interface. > > First of all it says "typically", which I interpret to mean that it > can also be something else. Second, it is not clear that the > interface index number is the same as ifIndex (I don't think it is the > same in all implementations), and further, ifIndex has an if-feature. Martin, As Juergen will know well, there were lengthy discussions last year about zone index and its representation, triggered in part by Brian Carpenter wanting to include it in a URI and finding that there was widespread variation in how different systems displayed it and that IPv6 was to some degree incompatible with the URI specification. The topic also surfaced in DHCP in address selection. Throughout this, I think that it was assumed to be synonymous with ifIndex. Tom Petch > So it is not clear what the zone index would be. > > But even so, RFC 4007 talks about "link-local scope" and > "interface-local scope". I assume the "interface-local scope" can be > the interface index, but the link local scope may be something else? > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From dthaler@microsoft.com Fri Feb 22 12:56:16 2013 Return-Path: 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 363CB21E8087 for ; Fri, 22 Feb 2013 12:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 CRyze5wVv841 for ; Fri, 22 Feb 2013 12:56:15 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5527421E8085 for ; Fri, 22 Feb 2013 12:56:15 -0800 (PST) Received: from BY2FFO11FD008.protection.gbl (10.1.15.203) by BY2FFO11HUB016.protection.gbl (10.1.14.89) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 22 Feb 2013 20:56:12 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 22 Feb 2013 20:56:12 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 22 Feb 2013 20:55:52 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.12]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0328.011; Fri, 22 Feb 2013 12:55:51 -0800 From: Dave Thaler To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 Thread-Index: AQHOBJL1zzYlWCEWeEyMFqUDipIaQJiFf5uggAC8+oCAADxIAP//+6vg Date: Fri, 22 Feb 2013 20:55:50 +0000 Message-ID: <341064315C6D0D498193B256F238CF973F90A0@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <20130206175114.GD83997@elstar.local> <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> In-Reply-To: <20130222.141014.235169504.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(189002)(24454001)(199002)(377454001)(51704002)(53806001)(77982001)(63696002)(31966008)(55846006)(50986001)(74662001)(15202345001)(47446002)(56816002)(33656001)(20776003)(80022001)(23726001)(66066001)(16406001)(79102001)(74502001)(46102001)(54356001)(44976002)(76482001)(59766001)(47976001)(4396001)(54316002)(50466001)(5343655001)(56776001)(49866001)(65816001)(47776003)(46406002)(47736001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB016; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07658B8EA3 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:56:16 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Friday, February 22, 2013 5:10 AM > To: j.schoenwaelder@jacobs-university.de > Cc: Dave Thaler; netmod@ietf.org > Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf- > netmod-ip-cfg-08 >=20 > Hi, >=20 > Juergen Schoenwaelder wrote: > > On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > > Note that zone indexes are properties of an interface, and I'm not > > > seeing them as interface properties in > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > The relevant information is in the definition of generic interfaces, > > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We > > have an interface/name and an interface/if-index for every interface. > > The IP model extends the generic interface model with IP specific > > configuration information. So I think we are fine. >=20 > 6021 (and bis) says: >=20 > For link-local addresses, the zone index will > typically be the interface index number or the name of an > interface. >=20 > First of all it says "typically", which I interpret to mean that it can a= lso be > something else. Correct. > Second, it is not clear that the interface index number is the > same as ifIndex (I don't think it is the same in all implementations),=20 Yes interface index number and ifIndex are synonyms. > and > further, ifIndex has an if-feature. >=20 > So it is not clear what the zone index would be. >=20 > But even so, RFC 4007 talks about "link-local scope" and "interface-local > scope". I assume the "interface-local scope" can be the interface index,= but > the link local scope may be something else? Correct the link scope zone id and the interface index can be different. -Dave From dthaler@microsoft.com Fri Feb 22 12:57:42 2013 Return-Path: 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 AD96321E8091 for ; Fri, 22 Feb 2013 12:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 2QkNYw36ocVI for ; Fri, 22 Feb 2013 12:57:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id C1D2821E808B for ; Fri, 22 Feb 2013 12:57:41 -0800 (PST) Received: from BY2FFO11FD015.protection.gbl (10.1.15.200) by BY2FFO11HUB007.protection.gbl (10.1.14.165) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 22 Feb 2013 20:57:40 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 22 Feb 2013 20:57:39 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 22 Feb 2013 20:57:13 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 22 Feb 2013 12:57:13 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.12]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0328.011; Fri, 22 Feb 2013 12:57:13 -0800 From: Dave Thaler To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 Thread-Index: AQHOBJL1zzYlWCEWeEyMFqUDipIaQJiFf5uggAC8+oCAADxIAIAABYsA///2f3A= Date: Fri, 22 Feb 2013 20:57:11 +0000 Message-ID: <341064315C6D0D498193B256F238CF973F90C0@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <20130206175114.GD83997@elstar.local> <341064315C6D0D498193B256F238CF973F23E3@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> <20130222133003.GA63107@elstar.local> In-Reply-To: <20130222133003.GA63107@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(199002)(189002)(24454001)(377454001)(13464002)(77982001)(66066001)(54356001)(31966008)(46102001)(49866001)(80022001)(79102001)(76482001)(56816002)(16406001)(55846006)(47976001)(16796002)(47736001)(20776003)(59766001)(51856001)(63696002)(56776001)(47776003)(50986001)(65816001)(44976002)(74662001)(54316002)(46406002)(50466001)(4396001)(33656001)(15202345001)(47446002)(74502001)(53806001)(23726001)(5343655001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB007; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07658B8EA3 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:57:42 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, February 22, 2013 5:30 AM > To: Martin Bjorklund > Cc: Dave Thaler; netmod@ietf.org > Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf- > netmod-ip-cfg-08 >=20 > On Fri, Feb 22, 2013 at 02:10:14PM +0100, Martin Bjorklund wrote: > > Hi, > > > > Juergen Schoenwaelder wrote: > > > On Thu, Feb 21, 2013 at 10:19:41PM +0000, Dave Thaler wrote: > > > > Note that zone indexes are properties of an interface, and I'm not > > > > seeing them as interface properties in > > > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08 > > > > > > The relevant information is in the definition of generic interfaces, > > > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. > > > We have an interface/name and an interface/if-index for every interfa= ce. > > > The IP model extends the generic interface model with IP specific > > > configuration information. So I think we are fine. > > > > 6021 (and bis) says: > > > > For link-local addresses, the zone index will > > typically be the interface index number or the name of an > > interface. > > > > First of all it says "typically", which I interpret to mean that it > > can also be something else. Second, it is not clear that the > > interface index number is the same as ifIndex (I don't think it is the > > same in all implementations), and further, ifIndex has an if-feature. > > > > So it is not clear what the zone index would be. >=20 > I think API implementation often accept both a name and a number and the > number typically is the interface index. RFC 4007 says implementations mu= st > support numbers and should support names as well. In the SMIv2 MIB space, > a zone identifier is always a number. Correct. > > But even so, RFC 4007 talks about "link-local scope" and > > "interface-local scope". I assume the "interface-local scope" can be > > the interface index, but the link local scope may be something else? >=20 > With link-local scope, you usually use the interface index/name of the li= nk to > identify the zone. Not in general, no. It's true that "usually" the value of the link scope = zone id and the value of the interface index are the same. But that's not guarant= eed to be the case and nothing should depend on that being the case. -Dave > Are you suggesting that there should be a separate (mandatory?) zone-id > object? Or are you suggesting we should make ifIndex mandatory? >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From dthaler@microsoft.com Fri Feb 22 13:10:58 2013 Return-Path: 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 6D92821F8EAD for ; Fri, 22 Feb 2013 13:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 O-ZmCBk2nkCr for ; Fri, 22 Feb 2013 13:10:57 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81021F8613 for ; Fri, 22 Feb 2013 13:10:56 -0800 (PST) Received: from BL2FFO11FD009.protection.gbl (10.173.161.203) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 22 Feb 2013 21:10:55 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 22 Feb 2013 21:10:55 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 22 Feb 2013 21:10:23 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 22 Feb 2013 13:10:23 -0800 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.12]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0328.011; Fri, 22 Feb 2013 13:10:22 -0800 From: Dave Thaler To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 Thread-Index: AQHOBJL1zzYlWCEWeEyMFqUDipIaQJiFf5uggAC8+oCAADxIAIAABYsAgAABxQCAAAPIAP//8Xzw Date: Fri, 22 Feb 2013 21:10:21 +0000 Message-ID: <341064315C6D0D498193B256F238CF973F9122@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> <20130222133003.GA63107@elstar.local> <20130222.143624.522177974.mbj@tail-f.com> <20130222134956.GA63213@elstar.local> In-Reply-To: <20130222134956.GA63213@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(24454001)(189002)(199002)(377454001)(51704002)(16406001)(51856001)(80022001)(66066001)(47446002)(20776003)(63696002)(56816002)(55846006)(4396001)(50986001)(65816001)(23726001)(31966008)(74662001)(74502001)(16796002)(44976002)(47976001)(79102001)(50466001)(47736001)(53806001)(49866001)(77982001)(47776003)(54316002)(33656001)(76482001)(5343655001)(56776001)(59766001)(46406002)(46102001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07658B8EA3 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:10:58 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, February 22, 2013 5:50 AM > To: Martin Bjorklund > Cc: Dave Thaler; netmod@ietf.org > Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf- > netmod-ip-cfg-08 >=20 > On Fri, Feb 22, 2013 at 02:36:24PM +0100, Martin Bjorklund wrote: >=20 > > > > But even so, RFC 4007 talks about "link-local scope" and > > > > "interface-local scope". I assume the "interface-local scope" can > > > > be the interface index, but the link local scope may be something e= lse? > > > > > > With link-local scope, you usually use the interface index/name of > > > the link to identify the zone. > > > > Isn't the difference between link-local scope and interface-local > > scope that there can be more than one interface attached to one link? That's correct. In general, each interface has up to 16 zone ids of which only about 13 are= interesting (reference: RFC 4291 section 2.7, see the list of scope levels for multicas= t). Level 1 is interface-local scope for which the zone id =3D=3D the interface= id. Level 14 =3D global for which the zone id is not used. For level 2-13 the zone id can be configurable, and levels 2 (link-local) a= nd 5 (site-local) are the most interesting but for multicast all are relevant = and can be different. So in terms of IP configuration, on platforms that supp= ort all levels of zone id, then you'd need to be able to configure the zone ids= for levels 2 through 13.=20 On Windows, level 2 (link) defaults to the same value as level 1 (i.e. by=20 default it assumes every interface is on a separate link) but can be config= ured otherwise. > > Which interface's number would you use as the link zone identifier? Possibly none of them. The link zone id is a separate numbering space and need not have any relationship to an interface index. Common implementati= ons use the same integer value by default though. So in short: whatever number is configured. > In this case, I assume implementations accept any of them as valid input = to > identify the zone. Which one do you use as the canonical output? No clue, > likely no RFC ever talks about this. No, an interface index identifies an interface, not a link scope zone. A link scope zone id identifies a link scope zone. Some APIs on some platforms might allow constraining the use of a destinati= on address to a smaller set of interfaces than it would be valid on. A commo= n case is sending to a global address (for which all interfaces are in the same global zone) via a specific local interface. I'm not aware of a platform = that allows this more generally though (i.e. constraining to something other tha= n=20 the zone full index or a single interface). But it would be incorrect to ever grab an interface index and simply assume that's the right scope id to use with an address. -Dave >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From internet-drafts@ietf.org Sat Feb 23 12:08:20 2013 Return-Path: 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 B46D721F8519; Sat, 23 Feb 2013 12:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 1K3-UDmO22DR; Sat, 23 Feb 2013 12:08:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493A21F8FA3; Sat, 23 Feb 2013 12:08:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130223200818.30701.25984.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 12:08:18 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 20:08:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for Routing Management Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-09.txt Pages : 69 Date : 2013-02-23 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - router instances, routes, routing tables, routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lhotka@nic.cz Sat Feb 23 12:34:25 2013 Return-Path: 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 34B9621F8840 for ; Sat, 23 Feb 2013 12:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 hecDX3qMAnU0 for ; Sat, 23 Feb 2013 12:34:24 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35B21F872E for ; Sat, 23 Feb 2013 12:34:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CBD4E5405AC for ; Sat, 23 Feb 2013 21:34:20 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZernMkUgvxa for ; Sat, 23 Feb 2013 21:34:11 +0100 (CET) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E825B5401E0 for ; Sat, 23 Feb 2013 21:34:05 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130223200818.30701.25984.idtracker@ietfa.amsl.com> References: <20130223200818.30701.25984.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Sat, 23 Feb 2013 21:34:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-09.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 20:34:25 -0000 Hi, this revision fixes the broken "must" constraint discovered by Martin and a few typos and other minor issues. Lada > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > Title : A YANG Data Model for Routing Management > Author(s) : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-09.txt > Pages : 69 > Date : 2013-02-23 > > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for individual routing protocols and > other related functions. The core routing data model provides common > building blocks for such extensions - router instances, routes, > routing tables, routing protocols and route filters. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wwwrun@rfc-editor.org Sun Feb 24 01:18:31 2013 Return-Path: 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 0666921F8FF7 for ; Sun, 24 Feb 2013 01:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 6yxZmbjEFZkA for ; Sun, 24 Feb 2013 01:18:29 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 89EA421F8BB0 for ; Sun, 24 Feb 2013 01:18:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 71BC5B1E002; Sun, 24 Feb 2013 01:17:22 -0800 (PST) To: mbj@tail-f.com, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20130224091722.71BC5B1E002@rfc-editor.org> Date: Sun, 24 Feb 2013 01:17:22 -0800 (PST) Cc: netmod@ietf.org, jernej.tuljak@mg-soft.com, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 09:18:31 -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=3493 -------------------------------------- Type: Technical Reported by: Jernej Tuljak Section: 12 Original Text ------------- value-stmt = value-keyword sep integer-value stmtend Corrected Text -------------- value-stmt = value-keyword sep integer-value-arg-str stmtend integer-value-arg-str = < a string that matches the rule integer-value-arg > integer-value-arg = integer-value Notes ----- Value statement should follow the rules for specifying YANG statement arguments. Current grammar does not allow a quoted string to appear as an argument to a value-stmt. Published IETF YANG modules exist which assume a quoted string may appear as an argument to this statement (eg. ietf-inet-types). 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 jernej.tuljak@gmail.com Sun Feb 24 02:15:34 2013 Return-Path: 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 8ABA521F9021 for ; Sun, 24 Feb 2013 02:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FDMRhksWbj9d for ; Sun, 24 Feb 2013 02:15:33 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1321F9023 for ; Sun, 24 Feb 2013 02:15:32 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gg13so1569871lbb.30 for ; Sun, 24 Feb 2013 02:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=aim2iAqPb1JoNYnAZQ4GnSuHnG7PSaNxBQvcLR/YFic=; b=ubOsCVSxuGaNjp+oMFdI2FDS8PhNOPlGDjkgrC7JPE7TW+VU+3BhmYJ7Y7n0l8wz3l Wg985kO9GxX7LSDRKsFHSItXntfuskcSCOg83EKtBrnAHz+Fsc6/tqpf4x95yEkKaUFj WE4rifczL4emeRUk1In2EG7lkjysI8vLV6A5EhvH1A9r18JZxr6uAnxsVM6UhF3ZkB+K FIoGWjEMMsH9osm04ku9aGi70RNmlrJ5TyBj5ecKKrpW5CIky/MFlWoVwzuFjwoLda6w yY+DtZkpGCnCyktbw/2bSMLqVHoELnmD5PwMFrJbkHVnlPcX2sFuiVFcJzkuJONH/+S/ sdrg== MIME-Version: 1.0 X-Received: by 10.152.144.202 with SMTP id so10mr6794989lab.9.1361700931665; Sun, 24 Feb 2013 02:15:31 -0800 (PST) Received: by 10.112.117.35 with HTTP; Sun, 24 Feb 2013 02:15:31 -0800 (PST) In-Reply-To: <20130224091722.71BC5B1E002@rfc-editor.org> References: <20130224091722.71BC5B1E002@rfc-editor.org> Date: Sun, 24 Feb 2013 11:15:31 +0100 Message-ID: From: Jernej Tuljak To: netmod@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22bcc352865b04d675b40d Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 10:15:34 -0000 --e89a8f22bcc352865b04d675b40d Content-Type: text/plain; charset=ISO-8859-1 I believe deviate statements also suffer from a similar problem. "add", "replace", "delete" and "not-supported" are defined as grammar keywords and also get used directly in productions instead through , meaning that they also must not be quoted. Was this intentional? As a side note, since it also relates to quoting: I've noticed that some published IETF modules contain statements such as: pattern "[\.0-9]*"; This is an example of illegal quoting. In double quoted strings a backslash ('\') represents a YANG escape sequence. There are only four such sequences possible: \n, \t, \" and \\. Sequence \. is not allowed and in fact the correct way of specifying the above pattern statement would be: pattern "[\\.0-9]*"; That's how I understood "6.1.3 Quoting". You should avoid using double quotes for specifying regular expressions and use single quotes instead (unless the regex contains a single quote character). I've taken the example from draft-ietf-netmod-rfc6021-bis-00 (!). As another side note, the grammar specified by RFC6020 is inherently ambiguous in the definition of refine-stmt. If an implementor were to try to implement a parser based on that ABNF and strictly follow the productions listed in there, she would eventually stumble upon this refine-stmt production. It contains an alternation between refine-container-stmts, refine-leaf-stmts, etc. It is impossible to determine which alternative should be taken by the parser unless you resolve refine-arg-str (a job for a compiler not a parser). Perhaps a comment should be added in there to warn people about it. The reason for ambiguity is the fact that this alternation is supposed to decide between alternatives that contain non-terminals from the same super-set and no terminals that would make the decision between them possible. Jernej 2013/2/24 RFC Errata System > > 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=3493 > > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak > > Section: 12 > > Original Text > ------------- > value-stmt = value-keyword sep integer-value stmtend > > Corrected Text > -------------- > value-stmt = value-keyword sep integer-value-arg-str stmtend > > integer-value-arg-str = < a string that matches the rule > integer-value-arg > > > integer-value-arg = integer-value > > Notes > ----- > Value statement should follow the rules for specifying YANG statement > arguments. Current grammar does not allow a quoted string to appear as an > argument to a value-stmt. Published IETF YANG modules exist which assume a > quoted string may appear as an argument to this statement (eg. > ietf-inet-types). > > 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 > --e89a8f22bcc352865b04d675b40d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe deviate statements also suffer from a similar problem. "add&= quot;, "replace", "delete" and "not-supported"= ; are defined as grammar keywords and also get used directly in productions= instead through <a string that matches...>, meaning that they also m= ust not be quoted. Was this intentional?

As a side note, since it also relates to quoting:

I've notic= ed that some published IETF modules contain statements such as:

pattern "[\.0-9]*";
This is an example of illegal quoti= ng. In double quoted strings a backslash ('\') represents a YANG es= cape sequence. There are only four such sequences possible: \n, \t, \"= and \\. Sequence \. is not allowed and in fact the correct way of specifyi= ng the above pattern statement would be:

pattern "[\\.0-9]*";
That's how I understood "6.1.3 Quoting". You should avoid usi= ng double quotes for specifying regular expressions and use single quotes i= nstead (unless the regex contains a single quote character).

I'v= e taken the example from draft-ietf-netmod-rfc6021-bis-00 (!).

As another side note, the grammar specified by RFC6020 is inherently am= biguous in the definition of refine-stmt. If an implementor were to try to = implement a parser based on that ABNF and strictly follow the productions l= isted in there, she would eventually stumble upon this refine-stmt producti= on. It contains an alternation between refine-container-stmts, refine-leaf-= stmts, etc. It is impossible to determine which alternative should be taken= by the parser unless you resolve refine-arg-str (a job for a compiler not = a parser). Perhaps a comment should be added in there to warn people about = it. The reason for ambiguity is the fact that this alternation is supposed = to decide between alternatives that contain non-terminals from the same sup= er-set and no terminals that would make the decision between them possible.=

Jernej

2013/2/24 RFC Errata System <rfc-editor@rfc-editor.org>

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

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

--------------------------------------
Type: Technical
Reported by: Jernej Tuljak <jernej.tuljak@mg-soft.com>

Section: 12

Original Text
-------------
value-stmt =A0 =A0 =A0 =A0 =A0=3D value-keyword sep integer-value stmtend
Corrected Text
--------------
value-stmt =A0 =A0 =A0 =A0 =A0=3D value-keyword sep integer-value-arg-str s= tmtend

integer-value-arg-str =A0 =3D < a string that matches the rule
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0integer-value-arg &g= t;

integer-value-arg =A0 =A0 =A0 =3D integer-value

Notes
-----
Value statement should follow the rules for specifying YANG statement argum= ents. Current grammar does not allow a quoted string to appear as an argume= nt to a value-stmt. Published IETF YANG modules exist which assume a quoted= string may appear as an argument to this statement (eg. ietf-inet-types).<= br>
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : YANG - A Data Modeling Language for the= Network Configuration Protocol (NETCONF)
Publication Date =A0 =A0: October 2010
Author(s) =A0 =A0 =A0 =A0 =A0 : M. Bjorklund, Ed.
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: NETCONF Data Modeling Language
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Operations and Management
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--e89a8f22bcc352865b04d675b40d-- From j.schoenwaelder@jacobs-university.de Sun Feb 24 02:26:50 2013 Return-Path: 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 AC1CB21F901E for ; Sun, 24 Feb 2013 02:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 vDiTLLP6BX3x for ; Sun, 24 Feb 2013 02:26:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4536421F9018 for ; Sun, 24 Feb 2013 02:26:45 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5150920BF0; Sun, 24 Feb 2013 11:26:44 +0100 (CET) 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 udnxXclzfVDC; Sun, 24 Feb 2013 11:26:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0E7F20BEF; Sun, 24 Feb 2013 11:26:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DF5BF24B84DB; Sun, 24 Feb 2013 11:26:52 +0100 (CET) Date: Sun, 24 Feb 2013 11:26:52 +0100 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20130224102652.GA68666@elstar.local> Mail-Followup-To: Jernej Tuljak , netmod@ietf.org References: <20130224091722.71BC5B1E002@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 10:26:50 -0000 On Sun, Feb 24, 2013 at 11:15:31AM +0100, Jernej Tuljak wrote: > > I've taken the example from draft-ietf-netmod-rfc6021-bis-00 (!). > I have fixed the broken pattern. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Feb 24 11:29:28 2013 Return-Path: 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 D809921F90B8 for ; Sun, 24 Feb 2013 11:29:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7GZWBjh9JVb for ; Sun, 24 Feb 2013 11:29:28 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 509A121F90B4 for ; Sun, 24 Feb 2013 11:29:28 -0800 (PST) Received: from localhost (h-105-26.a226.priv.bahnhof.se [79.136.105.26]) by mail.tail-f.com (Postfix) with ESMTPSA id 2AD5B12008B7; Sun, 24 Feb 2013 20:29:26 +0100 (CET) Date: Sun, 24 Feb 2013 20:29:25 +0100 (CET) Message-Id: <20130224.202925.395084778.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20130224091722.71BC5B1E002@rfc-editor.org> References: <20130224091722.71BC5B1E002@rfc-editor.org> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, rbonica@juniper.net, jernej.tuljak@mg-soft.com Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:29:29 -0000 Hi, I agree that this is a proper correction. /martin RFC Errata System wrote: > > 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=3493 > > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak > > Section: 12 > > Original Text > ------------- > value-stmt = value-keyword sep integer-value stmtend > > Corrected Text > -------------- > value-stmt = value-keyword sep integer-value-arg-str stmtend > > integer-value-arg-str = < a string that matches the rule > integer-value-arg > > > integer-value-arg = integer-value > > Notes > ----- > Value statement should follow the rules for specifying YANG statement > arguments. Current grammar does not allow a quoted string to appear as an > argument to a value-stmt. Published IETF YANG modules exist which assume a > quoted string may appear as an argument to this statement > (eg. ietf-inet-types). > > 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 mbj@tail-f.com Sun Feb 24 11:29:48 2013 Return-Path: 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 D5FED21F90BB for ; Sun, 24 Feb 2013 11:29:48 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WimkWsReGOmF for ; Sun, 24 Feb 2013 11:29:48 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60421F90B8 for ; Sun, 24 Feb 2013 11:29:48 -0800 (PST) Received: from localhost (h-105-26.a226.priv.bahnhof.se [79.136.105.26]) by mail.tail-f.com (Postfix) with ESMTPSA id 45CC712008B7; Sun, 24 Feb 2013 20:29:47 +0100 (CET) Date: Sun, 24 Feb 2013 20:29:47 +0100 (CET) Message-Id: <20130224.202947.389428777.mbj@tail-f.com> To: jernej.tuljak@gmail.com From: Martin Bjorklund In-Reply-To: References: <20130224091722.71BC5B1E002@rfc-editor.org> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 19:29:48 -0000 Jernej Tuljak wrote: > I believe deviate statements also suffer from a similar problem. "add", > "replace", "delete" and "not-supported" are defined as grammar keywords and > also get used directly in productions instead through matches...>, meaning that they also must not be quoted. Was this > intentional? Nope, this is also a bug, /martin From jernej.tuljak@mg-soft.si Mon Feb 25 00:06:50 2013 Return-Path: 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 073DA21F9229 for ; Mon, 25 Feb 2013 00:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.610, 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 57BEEbj9P7j4 for ; Mon, 25 Feb 2013 00:06:49 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E02A021F9221 for ; Mon, 25 Feb 2013 00:06:48 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r1P86gDj001015; Mon, 25 Feb 2013 09:06:42 +0100 Message-ID: <512B1B91.1000607@mg-soft.com> Date: Mon, 25 Feb 2013 09:06:41 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20130224091722.71BC5B1E002@rfc-editor.org> <20130224.202947.389428777.mbj@tail-f.com> In-Reply-To: <20130224.202947.389428777.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org, rbonica@juniper.net, RFC Errata System Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:06:50 -0000 Dne 24.2.2013 20:29, piše Martin Bjorklund: > Jernej Tuljak wrote: >> I believe deviate statements also suffer from a similar problem. "add", >> "replace", "delete" and "not-supported" are defined as grammar keywords and >> also get used directly in productions instead through > matches...>, meaning that they also must not be quoted. Was this >> intentional? > Nope, this is also a bug, There's an existing errata (3087) dealing with deviate-add-stmt, deviate-delete-stmt and deviate-replace-stmt (but not deviate-not-stupported-stmt). I think it would be confusing if we posted another errata which refers to the same text. If possible, 3087 should be edited so it becomes something like this; Old (RFC text, not errata text): deviate-not-supported-stmt = deviate-keyword sep not-supported-keyword optsep (";" / "{" stmtsep "}") deviate-add-stmt = deviate-keyword sep add-keyword optsep (";" / "{" stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") deviate-delete-stmt = deviate-keyword sep delete-keyword optsep (";" / "{" stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] "}") deviate-replace-stmt = deviate-keyword sep replace-keyword optsep (";" / "{" stmtsep [type-stmt stmtsep] [units-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") New: deviate-not-supported-stmt = deviate-keyword sep not-supported-arg-str optsep (";" / "{" stmtsep "}") not-supported-arg-str = < a string that matches the rule not-supported-arg > not-supported-arg = not-supported-keyword deviate-add-stmt = deviate-keyword sep add-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") add-arg-str = < a string that matches the rule add-arg > add-arg = add-keyword deviate-delete-stmt = deviate-keyword sep delete-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [units-stmt stmtsep] *(must-stmt stmtsep) *(unique-stmt stmtsep) [default-stmt stmtsep] "}") delete-arg-str = < a string that matches the rule delete-arg > delete-arg = delete-keyword deviate-replace-stmt = deviate-keyword sep replace-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [type-stmt stmtsep] [units-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") replace-arg-str = < a string that matches the rule replace-arg > replace-arg = replace-keyword Note: The comment "these stmts can appear in any order" is missing from deviate-add-stmt, deviate-delete-stmt and deviate-replace-stmt productions. Deviate statements should follow the rules for specifying YANG statement arguments. Current grammar does not allow a quoted string to appear as an argument to a deviate statement. In addition to the "any order" comment for the latter three statements, there's a for every deviate argument. I checked and none of the new non-terminals I propose clash with existing ones. Jernej > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Mon Feb 25 00:38:39 2013 Return-Path: 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 547A521F9059 for ; Mon, 25 Feb 2013 00:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] 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 NeROvfIO0Toy for ; Mon, 25 Feb 2013 00:38:38 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A21E621F8F69 for ; Mon, 25 Feb 2013 00:38:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6CB7F540526 for ; Mon, 25 Feb 2013 09:38:32 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwMXb5a370sj for ; Mon, 25 Feb 2013 09:38:26 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 74A5C54024C for ; Mon, 25 Feb 2013 09:38:21 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130224091722.71BC5B1E002@rfc-editor.org> User-Agent: Notmuch/0.15.1+15~gd037040 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 25 Feb 2013 09:38:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:38:39 -0000 Jernej Tuljak writes: > As another side note, the grammar specified by RFC6020 is inherently > ambiguous in the definition of refine-stmt. If an implementor were to try > to implement a parser based on that ABNF and strictly follow the > productions listed in there, she would eventually stumble upon this > refine-stmt production. It contains an alternation between > refine-container-stmts, refine-leaf-stmts, etc. It is impossible to > determine which alternative should be taken by the parser unless you > resolve refine-arg-str (a job for a compiler not a parser). Perhaps a > comment should be added in there to warn people about it. The reason for > ambiguity is the fact that this alternation is supposed to decide between > alternatives that contain non-terminals from the same super-set and no > terminals that would make the decision between them possible. > This is a correct observation, the ABNF tries to be too specific here. IMO it would be better to use the same approach as for augment-stmt for which the ABNF allows, for example, to augment a container with a case node - this is of course an error, but a semantic one. The non-ambiguous version would be: refine-stmt = refine-keyword sep refine-arg-str optsep "{" stmtsep ;; these stmts can appear in any order *(must-stmt stmtsep) [presence-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}" Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jernej.tuljak@mg-soft.si Mon Feb 25 00:55:57 2013 Return-Path: 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 855CD21F91CF for ; Mon, 25 Feb 2013 00:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 MtPKfcNVOZ5O for ; Mon, 25 Feb 2013 00:55:57 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id A823221F91C2 for ; Mon, 25 Feb 2013 00:55:56 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id r1P8tsbd001742 for ; Mon, 25 Feb 2013 09:55:55 +0100 Message-ID: <512B271A.9020502@mg-soft.com> Date: Mon, 25 Feb 2013 09:55:54 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20130224091722.71BC5B1E002@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3493) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:55:57 -0000 Dne 25.2.2013 9:38, piše Ladislav Lhotka: > Jernej Tuljak writes: > >> As another side note, the grammar specified by RFC6020 is inherently >> ambiguous in the definition of refine-stmt. If an implementor were to try >> to implement a parser based on that ABNF and strictly follow the >> productions listed in there, she would eventually stumble upon this >> refine-stmt production. It contains an alternation between >> refine-container-stmts, refine-leaf-stmts, etc. It is impossible to >> determine which alternative should be taken by the parser unless you >> resolve refine-arg-str (a job for a compiler not a parser). Perhaps a >> comment should be added in there to warn people about it. The reason for >> ambiguity is the fact that this alternation is supposed to decide between >> alternatives that contain non-terminals from the same super-set and no >> terminals that would make the decision between them possible. >> > This is a correct observation, the ABNF tries to be too specific here. IMO it would be better to use the same approach as for augment-stmt for which the ABNF allows, for example, to augment a container with a case node - this is of course an error, but a semantic one. > > The non-ambiguous version would be: > > refine-stmt = refine-keyword sep refine-arg-str optsep > "{" stmtsep > ;; these stmts can appear in any order > *(must-stmt stmtsep) > [presence-stmt stmtsep] > [default-stmt stmtsep] > [config-stmt stmtsep] > [mandatory-stmt stmtsep] > [min-elements-stmt stmtsep] > [max-elements-stmt stmtsep] > [description-stmt stmtsep] > [reference-stmt stmtsep] > "}" > > > Lada > Yes. This is what I was forced to do while implementing this grammar with JavaCC. The rest of it appears to be non ambiguous or it's ambiguity may be resolved by changing the order of productions and relying on lookahead for choosing correct alternations (there's just one case of this in type-body-stmts if I remember correctly). Jernej From wwwrun@rfc-editor.org Mon Feb 25 01:34:34 2013 Return-Path: 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 9F3FB21F9238 for ; Mon, 25 Feb 2013 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 OWuD8nLsvarf for ; Mon, 25 Feb 2013 01:34:33 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D0C4221F922B for ; Mon, 25 Feb 2013 01:34:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 102C772E114; Mon, 25 Feb 2013 01:33:26 -0800 (PST) To: mbj@tail-f.com, rbonica@juniper.net, bclaise@cisco.com, j.schoenwaelder@jacobs-university.de, david.kessens@nsn.com From: RFC Errata System Message-Id: <20130225093326.102C772E114@rfc-editor.org> Date: Mon, 25 Feb 2013 01:33:26 -0800 (PST) Cc: netmod@ietf.org, jernej.tuljak@mg-soft.com, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6020 (3495) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:34:34 -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=3495 -------------------------------------- Type: Technical Reported by: Jernej Tuljak Section: 12 Original Text ------------- revision-stmt = revision-keyword sep revision-date optsep (";" / "{" stmtsep [description-stmt stmtsep] [reference-stmt stmtsep] "}") Corrected Text -------------- revision-stmt = revision-keyword sep revision-date optsep (";" / "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] "}") Notes ----- The comment "these stmts can appear in any order" is missing from this statement. 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 internet-drafts@ietf.org Mon Feb 25 07:37:31 2013 Return-Path: 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 B138D21F9491; Mon, 25 Feb 2013 07:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 szEAbckgUZ7c; Mon, 25 Feb 2013 07:37:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71F21F94C0; Mon, 25 Feb 2013 07:37:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225153731.16609.23136.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:37:31 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:37:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-05.txt Pages : 32 Date : 2013-02-25 Abstract: This document defines a YANG data model for the configuration and identification of the management system of a device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Mon Feb 25 13:03:54 2013 Return-Path: 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 5E68D21E80E2 for ; Mon, 25 Feb 2013 13:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.197 X-Spam-Level: X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 DIVPV83aSi87 for ; Mon, 25 Feb 2013 13:03:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6399521E80DB for ; Mon, 25 Feb 2013 13:03:50 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E94EA20BFB; Mon, 25 Feb 2013 22:03:48 +0100 (CET) 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 3ZBApxYVvNOb; Mon, 25 Feb 2013 22:03:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A8DB20BF8; Mon, 25 Feb 2013 22:03:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B514624BCA57; Mon, 25 Feb 2013 22:03:57 +0100 (CET) Date: Mon, 25 Feb 2013 22:03:57 +0100 From: Juergen Schoenwaelder To: Dave Thaler Message-ID: <20130225210357.GC73999@elstar.local> Mail-Followup-To: Dave Thaler , Martin Bjorklund , "netmod@ietf.org" References: <20130222093427.GC62099@elstar.local> <20130222.141014.235169504.mbj@tail-f.com> <20130222133003.GA63107@elstar.local> <20130222.143624.522177974.mbj@tail-f.com> <20130222134956.GA63213@elstar.local> <341064315C6D0D498193B256F238CF973F9122@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <341064315C6D0D498193B256F238CF973F9122@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:03:54 -0000 [...] My conclusion from this exchange is that what we have in draft-ietf-netmod-ip-cfg-08 appears to be correct. I do not think there is a need to provide a standard way to configure zones and zone-ids at this point in time - I rather like to get these document out of the door so that we get implementation experience. If someone has a different conclusions, speak up now. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yihuan@cisco.com Tue Feb 26 14:42:43 2013 Return-Path: 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 1CAFB21F857A for ; Tue, 26 Feb 2013 14:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.965 X-Spam-Level: X-Spam-Status: No, score=-7.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] 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 LtgXVJ-vWp1B for ; Tue, 26 Feb 2013 14:42:29 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 117E021F87D3 for ; Tue, 26 Feb 2013 14:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=222480; q=dns/txt; s=iport; t=1361918548; x=1363128148; h=from:to:cc:subject:date:message-id:mime-version; bh=Icc70LcZDnN61zj9f+013NQWqOd/riIOCEDUiAUw/nI=; b=jRcQB1uVt8LN3LecJpDCbJm+Pn9T8y0eNPTjYp443mN+xNfZfpKR8nHY MqbtnjAV26rKtl2nMIpX98YEBnEsY+6RLWMzkKYnaMe8l8jAbJ+FPJZq7 cK0U1ThAA4ND3DFDi185xWDZ9ee/epRrZFQO6tZ3JBu4+iCXaO93xR09i I=; X-Files: draft-huang-netmod-acl-02.txt : 149827 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG45LVGtJXG+/2dsb2JhbAA8CYJDvzeBARZzgiEBBBoBUA4SARgDDyYwJwQOBQgGiAUMr3mQCY1DAQaBEwYGBSEFCQIFglZhA4pghEWDWoRfj0qDCIFqCBce X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; d="txt'?scan'208,217";a="181502553" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2013 22:42:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1QMgOG8014357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 22:42:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 16:42:24 -0600 From: "Lisa Huang (yihuan)" To: "netmod@ietf.org" Thread-Topic: New Version ACL Yang model Thread-Index: AQHOFHKLYUlOp/drhEi4j40pGnJN+g== Date: Tue, 26 Feb 2013 22:42:23 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FCB426A@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.36.115] Content-Type: multipart/mixed; boundary="_004_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_" MIME-Version: 1.0 Subject: [netmod] New Version ACL Yang model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:42:43 -0000 --_004_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_ Content-Type: multipart/alternative; boundary="_000_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_" --_000_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This is a new version of ACL Yang model I-D. Yesterday, we missed the deadl= ine since I did not read the time zone information carefully enough. As Jue= rgen kindly suggested, I attached the new version in email to make it avail= able to the WG. Not much has changed, but we did follow up on the action items from last me= eting, as stated below, and updated the draft accordingly. The action items and follow-up are as follows: 1. Can this model support ACL Chaining? ACL Chain Support section is = added to section 3.3 to illustrate how this ACL model could be extended to support ACL Chain straightforwardly. 2. Are there any compatibility issues related to ACE ordering because a YANG user-order list is used instead of sequence IDs? This item is closely related to bullet item 3, see below. 3. Is an administrative function to test a packet against a specified ACL needed? The server would return an indication of permit or deny, and a leaf-list of the ACE entries that were evaluated. We believe that this addition would be valuable and have incorporated this suggestion into a new "Additional Considerations" section. We expect to move it into the data model in the next revision. 4.Is the model applicable to multiple implementations - can other ACL models be accommodated? We have followed up with Juniper Yang experts, Kent Watsen and Phil Shafer, to review and check for applicability to Junos implementation. The initial feedback from Phil indicates that there do not seem to be any showstoppers and that the model does seem to be applicable. However, he suggested further scrutiny should occur. Kent identified additional Juniper experts to scrutinize the model more closely; so far no further comments have been received. We also followed up regarding whether there are other standardized models of ACLs, for example in conjunction with the Desktop Management Task Force's (DMTF) CIM (Common Information Model). ACL is not covered by the standardized portion of CIM, but there are vendor-specific extensions by vendors. We inspected one such vendor specific model and found that in essence the same design patterns were used as in the model specified in this Internet Draft, with an ACL corresponding to an ordered list of rules with filters or matching criteria, and actions to be taken in response. It appears that mappings between the models can be accommodated in a straightforward manner. Thanks --- Lisa --_000_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <71ACD7E647A23F419A19E5CD57CA9487@cisco.com> Content-Transfer-Encoding: quoted-printable

Hi,


This is a new version of ACL Yang model I-D. Yesterday, we missed the deadl= ine since I did not read the time zone information carefully enough. A= s Juergen kindly suggested, I attached the new version in email to make it = available to the WG.

 

Not much has changed, but we did follow up on the action items from last me= eting, as stated below, and updated the draft accordingly.

 

The action items and follow-up are as follows:

 

     1.  Can this model support ACL Chaining? ACL = Chain Support section is added

     to section 3.3 to illustrate how this ACL model co= uld be extended

     to support ACL Chain straightforwardly.=


     2.  Are there any compatibility issues related to = ACE ordering

      because a YANG user-order list is used inste= ad of sequence IDs?

      This item is closely related to bullet item = 3, see below.

 

      3.  Is an administrative function to test a packe= t against a

      specified ACL needed?  The server would= return an indication of

      permit or deny, and a leaf-list of the ACE e= ntries that were

      evaluated.  We believe that this additi= on would be valuable and

      have incorporated this suggestion into a new= "Additional

      Considerations" section.  We expec= t to move it into the data model

      in the next revision.

 

      4.Is the model applicable to multiple implementations = - can other

      ACL models be accommodated?  We have fo= llowed up with Juniper Yang

      experts, Kent Watsen and Phil Shafer, to rev= iew and check for

      applicability to Junos implementation. = The initial feedback from

      Phil indicates that there do not seem to be = any showstoppers and

      that the model does seem to be applicable.&n= bsp; However, he suggested

      further scrutiny should occur.  Kent id= entified additional Juniper

      experts to scrutinize the model more closely= ; so far no further

      comments have been received.  We also f= ollowed up regarding

      whether there are other standardized models = of ACLs, for example

      in conjunction with the Desktop Management T= ask Force's (DMTF) CIM

      (Common Information Model).  ACL is not= covered by the

     standardized portion of CIM, but there are ve= ndor-specific

      extensions by vendors.  We inspected on= e such vendor specific

      model and found that in essence the same des= ign patterns were used

      as in the model specified in this Internet D= raft, with an ACL

      corresponding to an ordered list of rules wi= th filters or matching

      criteria, and actions to be taken in respons= e.  It appears that

      mappings between the models can be accommoda= ted in a

      straightforward manner.

 

    


Thanks

--- Lisa


--_000_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_-- --_004_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_ Content-Type: text/plain; name="draft-huang-netmod-acl-02.txt" Content-Description: draft-huang-netmod-acl-02.txt Content-Disposition: attachment; filename="draft-huang-netmod-acl-02.txt"; size=149827; creation-date="Tue, 26 Feb 2013 22:42:23 GMT"; modification-date="Tue, 26 Feb 2013 22:42:23 GMT" Content-ID: <6FB95BF5A7F6624396AD7732B41C1451@cisco.com> Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEwuIEh1YW5nCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDbGVtbQpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMKRXhwaXJl czogQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB LiBCaWVybWFuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFl1bWFXb3JrcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjUsIDIwMTMKCgogICAgICAgICBZQU5H IERhdGEgTW9kZWwgZm9yIEFjY2VzcyBDb250cm9sIExpc3QgQ29uZmlndXJhdGlvbgogICAgICAg ICAgICAgICAgICAgICBkcmFmdC1odWFuZy1uZXRtb2QtYWNsLTAyLnR4dAoKQWJzdHJhY3QKCiAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgdGhlIGNvbmZpZ3Vy YXRpb24gb2YKICAgQWNjZXNzIENvbnRyb2wgTGlzdHMgKEFDTHMpIG9uIGEgZGV2aWNlLgoKU3Rh dHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQ IDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiBBdWd1c3QgMjksIDIwMTMuCgpDb3B5cmlnaHQgTm90aWNlCgogICBD b3B5cmlnaHQgKGMpIDIwMTMgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlz IGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2Fs CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0 aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBl eHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVz dCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgoKCgpIdWFuZywgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICAgW1Bh Z2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAg ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICBUaGlzIGRvY3VtZW50IG1heSBjb250YWluIG1h dGVyaWFsIGZyb20gSUVURiBEb2N1bWVudHMgb3IgSUVURgogICBDb250cmlidXRpb25zIHB1Ymxp c2hlZCBvciBtYWRlIHB1YmxpY2x5IGF2YWlsYWJsZSBiZWZvcmUgTm92ZW1iZXIKICAgMTAsIDIw MDguICBUaGUgcGVyc29uKHMpIGNvbnRyb2xsaW5nIHRoZSBjb3B5cmlnaHQgaW4gc29tZSBvZiB0 aGlzCiAgIG1hdGVyaWFsIG1heSBub3QgaGF2ZSBncmFudGVkIHRoZSBJRVRGIFRydXN0IHRoZSBy aWdodCB0byBhbGxvdwogICBtb2RpZmljYXRpb25zIG9mIHN1Y2ggbWF0ZXJpYWwgb3V0c2lkZSB0 aGUgSUVURiBTdGFuZGFyZHMgUHJvY2Vzcy4KICAgV2l0aG91dCBvYnRhaW5pbmcgYW4gYWRlcXVh dGUgbGljZW5zZSBmcm9tIHRoZSBwZXJzb24ocykgY29udHJvbGxpbmcKICAgdGhlIGNvcHlyaWdo dCBpbiBzdWNoIG1hdGVyaWFscywgdGhpcyBkb2N1bWVudCBtYXkgbm90IGJlIG1vZGlmaWVkCiAg IG91dHNpZGUgdGhlIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MsIGFuZCBkZXJpdmF0aXZlIHdvcmtz IG9mIGl0IG1heQogICBub3QgYmUgY3JlYXRlZCBvdXRzaWRlIHRoZSBJRVRGIFN0YW5kYXJkcyBQ cm9jZXNzLCBleGNlcHQgdG8gZm9ybWF0CiAgIGl0IGZvciBwdWJsaWNhdGlvbiBhcyBhbiBSRkMg b3IgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVyCiAgIHRoYW4gRW5nbGlzaC4K CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkh1YW5nLCBldCBhbC4gICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAyXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAg ICAgRmVicnVhcnkgMjAxMwoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAg Mi4gIERlZmluaXRpb25zIGFuZCBBY3JvbnltcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA0CiAgIDMuICBUaGUgRGVzaWduIG9mIHRoZSBBQ0wgRGF0YSBNb2RlbCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICAgIDMuMS4gIE92ZXJhbGwgTW9kZWwgU3Ry dWN0dXJlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAzLjIuICBE YXRhIGhpZXJhcmNoeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA2CiAgICAgMy4zLiAgT3RoZXIgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOQogICAgICAgMy4zLjEuICBFeHRlbnNpYmlsaXR5ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICAgIDMuMy4yLiAgQUNMIENo YWluIFN1cHBvcnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAg ICAzLjMuMy4gIEFDTCBUZXN0IEV4dGVuc2lvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMAogICA0LiAgYWNsIE1vZHVsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICA0LjEuICBGZWF0dXJlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgNC4yLiAgVHlw ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MQogICAgIDQuMy4gIEdyb3VwaW5ncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTIKICAgICA0LjQuICBDb250YWluZXJzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICA0LjQuMS4gIGFjbHMgQ29u dGFpbmVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAg NC40LjIuICBwb3J0LWdyb3VwcyBDb250YWluZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTMKICAgICAgIDQuNC4zLiAgdGltZXJhbmdlLWdyb3VwcyBDb250YWluZXIgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgICAgICA0LjQuNC4gIGlwLWFkZHJlc3MtZ3JvdXBz IENvbnRhaW5lciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICA1LiAgYWNsLWlwIG1v ZHVsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUK ICAgICA1LjEuICBHcm91cGluZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE1CiAgICAgICA1LjEuMS4gIElQLVNPVVJDRS1ORVRXT1JLIGdyb3VwaW5n IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAgNS4xLjIuICBJUC1ERVNUSU5B VElPTi1ORVRXT1JLIGdyb3VwaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICAgIDUu MS4zLiAgRFNDUC1PUi1UT1MgR3JvdXBpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE3CiAgICAgICA1LjEuNC4gIElQLUFDRS1GSUxURVJTIEdyb3VwaW5nICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgIDUuMi4gIGF1Z21lbnQgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjAKICAgICAgIDUuMi4xLiAgZ2xv YmFsLWZyYWdtZW50cyBsZWFmICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwCiAg IDYuICBhY2wtbWFjIG1vZHVsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyMwogICAgIDYuMS4gIE1BQy1TT1VSQ0UtTkVUV09SSyBncm91cGluZyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMKICAgICA2LjIuICBNQUMtREVTVElOQVRJT04t TkVUV09SSyBncm91cGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgICAgNi4zLiAg YXVnbWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNAogICA3LiAgYWNsLWFycCBtb2R1bGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjQKICAgICA3LjEuICBhdWdtZW50ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgIDguICBEYXRhIE1vZGVsIFN0 cnVjdHVyZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQogICA5 LiAgQUNMIEV4YW1wbGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMzMKICAgICA5LjEuICBDb25maWd1cmF0aW9uIEV4YW1wbGUgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMzCiAgIDEwLiBBQ0wgWUFORyBNb2R1bGUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQogICAxMS4gQUNMLUlQ IFlBTkcgTW9kdWxlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDgKICAgMTIuIEFDTC1NQUMgQ29uZmlndXJhdGlvbiBZQU5HIE1vZHVsZSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDYyCiAgIDEzLiBBQ0wtQVJQIENvbmZpZ3VyYXRpb24gWUFORyBNb2R1 bGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2OAogICAxNC4gQ09NTU9OLVRZUEVTIFlB TkcgTW9kdWxlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNzEKICAgMTUu IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDc5CiAgIDE2LiBPcGVuIGl0ZW1zIGZyb20gdGhlIHByZXZpb3VzIHJldmlzaW9uICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA3OQogICAxNy4gQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gODAKICAgMTguIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgw CgoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAg ICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5 YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKMS4gIEludHJvZHVjdGlv bgoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBbUkZDNjAyMF0gZGF0YSBtb2RlbCBm b3IgdGhlCiAgIGNvbmZpZ3VyYXRpb24gb2YgQWNjZXNzIENvbnRyb2wgTGlzdHMgKEFDTHMpLgoK ICAgQW4gQUNMIGlzIGFuIG9yZGVyZWQgc2V0IG9mIHJ1bGVzIHRoYXQgaXMgdXNlZCB0byBmaWx0 ZXIgdHJhZmZpYyBvbiBhCiAgIG5ldHdvcmtpbmcgZGV2aWNlLCBpLmUuIHRvIGRlZmluZSAiZmly ZXdhbGwgcnVsZXMiLiAgRWFjaCBydWxlIGlzCiAgIHJlcHJlc2VudGVkIGJ5IGFuIEFjY2VzcyBD b250cm9sIEVudHJ5IChBQ0UpLiAgQW4gQUNFIGNvbnNpc3RzIG9mIHR3bwogICBwYXJ0czoKCiAg IEZpbHRlcnMgd2l0aCBhIHNldCBvZiBtYXRjaGluZyBjcml0ZXJpYSB0aGF0IGEgcGFja2V0IG11 c3Qgc2F0aXNmeQogICBmb3IgdGhlIHJ1bGUgdG8gYmUgYXBwbGllZC4KCiAgIEFjdGlvbnMgdGhh dCBzcGVjaWZpZXMgd2hhdCB0byBkbyB3aXRoIHRoZSBwYWNrZXQgd2hlbiB0aGUgbWF0Y2hpbmcK ICAgY3JpdGVyaWEgaXMgbWV0LCBmb3IgZXhhbXBsZSwgdG8gZHJvcCB0aGUgcGFja2V0LgoKICAg VGhlcmUgYXJlIGRpZmZlcmVudCB0eXBlcyBvZiBBQ0w6IE1BQyBBQ0wsIElQIEFDTCwgYW5kIEFS UCBBQ0wuCgogICBNQUMgQUNMcyAtIE1BQyBBQ0xzIGFyZSB1c2VkIHRvIGZpbHRlciB0cmFmZmlj IHVzaW5nIHRoZSBpbmZvcm1hdGlvbgogICBpbiB0aGUgTGF5ZXIgMiBoZWFkZXIgb2YgZWFjaCBw YWNrZXQuICBNQUMgQUNMcyBhcmUgYnkgZGVmYXVsdCBvbmx5CiAgIGFwcGxpZWQgdG8gbm9uLUlQ IHRyYWZmaWM7IGhvd2V2ZXIsIExheWVyIDIgaW50ZXJmYWNlcyBjYW4gYmUKICAgY29uZmlndXJl ZCB0byBhcHBseSBNQUMgQUNMcyB0byBhbGwgdHJhZmZpYy4KCiAgIElQIEFDTHM6IElQIEFDTHMg YXJlIG9yZGVyZWQgc2V0cyBvZiBydWxlcyB0aGF0IGNhbiB1c2UgdG8gZmlsdGVyCiAgIHRyYWZm aWMgYmFzZWQgb24gSVAgaW5mb3JtYXRpb24gaW4gdGhlIExheWVyIDMgaGVhZGVyIG9mIHBhY2tl dHMuCiAgIFRoZSBkZXZpY2UgYXBwbGllcyBJUCBBQ0xzIG9ubHkgdG8gSVAgdHJhZmZpYy4gIElQ IEFDTCBjYW4gYmUgSVB2NCBvcgogICBJUHY2LgoKICAgQVJQIEFDTHMgLSBUaGUgZGV2aWNlIGFw cGxpZXMgQVJQIEFDTHMgdG8gSVAgdHJhZmZpYy4KCiAgIE5vdCBldmVyeSBkZXZpY2UgaW1wbGVt ZW50cyBldmVyeSB0eXBlIG9mIEFDTC4gIEluIGFkZGl0aW9uLCBkZXZpY2UKICAgaW1wbGVtZW50 YXRpb25zIG1heSB2YXJ5IGdyZWF0bHkgaW4gdGVybXMgb2YgdGhlIGZpbHRlciBjb25zdHJ1Y3Rz CiAgIHRoYXQgdGhleSBzdXBwb3J0LiAgVGhlcmVmb3JlLCBhY2wgWUFORyBNb2R1bGUgbWFrZXMg ZXh0ZW5zaXZlIHVzZSBvZgogICB0aGUgImZlYXR1cmUiIGNvbnN0cnVjdCB3aGljaCBhbGxvd3Mg aW1wbGVtZW50YXRpb25zIHRvIHN1cHBvcnQgdGhvc2UKICAgQUNMIGNvbmZpZ3VyYXRpb24gZmVh dHVyZXMgdGhhdCBsaWUgd2l0aGluIHRoZWlyIGNhcGFiaWxpdGllcy4KCiAgIEhvdyBBQ0xzIGFy ZSBhcHBsaWVkIGluIGRldmljZSBjb25maWd1cmF0aW9uIHRvIGludGVyZmFjZXMgYW5kIG90aGVy CiAgIGNvbXBvbmVudHMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBtb2RlbC4KCjIuICBE ZWZpbml0aW9ucyBhbmQgQWNyb255bXMKCiAgIEFDRTogQWNjZXNzIENvbnRyb2wgRW50cnkKCiAg IEFDTDogQWNjZXNzIENvbnRyb2wgTGlzdAoKICAgQUZJOiBBZGRyZXNzIEZpZWxkIElkZW50aWZp ZXIKCiAgIEFSUDogQWRkcmVzcyBSZXNvbHV0aW9uIFByb3RvY29sCgoKCkh1YW5nLCBldCBhbC4g ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA0 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAg ICAgICAgRmVicnVhcnkgMjAxMwoKCiAgIENvUzogQ2xhc3Mgb2YgU2VydmljZQoKICAgRFNDUDog RGlmZmVyZW50aWF0ZWQgU2VydmljZXMgQ29kZSBQb2ludAoKICAgSUNNUDogSW50ZXJuZXQgQ29u dHJvbCBNZXNzYWdlIFByb3RvY29sCgogICBJR01QOiBJbnRlcm5ldCBHcm91cCBNYW5hZ2VtZW50 IFByb3RvY29sCgogICBJUDogSW50ZXJuZXQgUHJvdG9jb2wKCiAgIElQdjQ6IEludGVybmV0IFBy b3RvY29sIHZlcnNpb24gNAoKICAgSVB2NjogSW50ZXJuZXQgUHJvdG9jb2wgdmVyc2lvbiA2Cgog ICBNQUM6IE1lZGlhIEFjY2VzcyBDb250cm9sCgogICBRb1M6IFF1YWxpdHkgb2YgU2VydmljZQoK ICAgVENQOiBUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbAoKICAgVG9TOiBUeXBlIG9mIFNl cnZpY2UKCiAgIFRUTDogVGltZSBUbyBMaXZlCgogICBVRFA6IFVzZXIgRGF0YWdyYW0gUHJvdG9j b2wKCiAgIFZMQU46IFZpcnR1YWwgTG9jYWwgQXJlYSBOZXR3b3JrCgogICBWUkY6IFZpcnR1YWwg Um91dGluZyBhbmQgRm9yd2FyZGluZwoKMy4gIFRoZSBEZXNpZ24gb2YgdGhlIEFDTCBEYXRhIE1v ZGVsCgozLjEuICBPdmVyYWxsIE1vZGVsIFN0cnVjdHVyZQoKICAgVGhlIEFDTCBkYXRhIG1vZGVs IGNvbnNpc3RzIG9mIGZpdmUgWUFORyBtb2R1bGVzLiAgVGhlIGZpcnN0IG1vZHVsZSwKICAgImFj bCIsIGRlZmluZXMgZ2VuZXJpYyBBQ0wgYXNwZWN0cyB3aGljaCBhcmUgY29tbW9uIHRvIGFsbCBB Q0xzCiAgIHJlZ2FyZGxlc3Mgb2YgdGhlaXIgdHlwZSwgYXMgd2VsbCBhcyBhIHNldCBvZiBhdXhp bGlhcnkgZGVmaW5pdGlvbnMuCiAgIEluIGVmZmVjdCwgdGhlIG1vZHVsZSBjYW4gYmUgdmlld2Vk IGFzIHByb3ZpZGluZyBhIGdlbmVyaWMgQUNMCiAgICJzdXBlcmNsYXNzIi4KCiAgIFRocmVlIG90 aGVyIG1vZHVsZXMsICJhY2wtaXAiLCAiYWNsLW1hYyIsIGFuZCAiYWNsLWFycCIgLCBhdWdtZW50 IHRoZQogICAiYWNsIiBtb2R1bGUgd2l0aCBkZWZpbml0aW9ucyB0aGF0IGFyZSBzcGVjaWZpYyB0 byBkaWZmZXJlbnQgdHlwZXMgb2YKICAgQUNMcywgc3BlY2lmaWNhbGx5LCBBQ0xzIGZvciBJUCwg TUFDLCBhbmQgQVJQLCByZXNwZWN0aXZlbHkuICBUaGVzZQogICBzcGVjaWZpY3MgYXJlIGZvciB0 aGUgbGFyZ2VzdCBwYXJ0IHJlZmxlY3RlZCBpbiB0aGUgQWNjZXNzIENvbnRyb2wKICAgRW50cmll cywgdGhhdCBpcywgdGhlIHJ1bGVzIHdoaWNoIHNwZWNpZnkgdGhlIGZpbHRlciBjcml0ZXJpYSB0 aGF0IGEKICAgcGFja2V0IG11c3QgbWVldCBmb3IgdGhlIHJ1bGUgdG8gYmUgYXBwbGllZCwgYW5k IHRoZSBhY3Rpb25zIHRoYXQgYXJlCiAgIHRvIGJlIHRha2VuIGluIGNhc2UgdGhlIGZpbHRlciBt YXRjaGVzLiAgS2VlcGluZyB0aGUgbW9kdWxlcyBzZXBhcmF0ZQogICBwcm92aWRlcyBmb3IgYSBt b3JlIG1vZHVsYXIgZGF0YSBtb2RlbCB0aGFuIHdvdWxkIGJlIHRoZSBjYXNlIGlmIGFsbAoKCgpI dWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAg ICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNs ICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICB0eXBlcyB3ZXJlIGNvbWJpbmVk IGludG8gYSBzaW5nbGUgbW9ub2xpdGhpYyBtb2R1bGUuCgogICBGaW5hbGx5LCBtb2R1bGUgImNv bW1vbi10eXBlcyIgZGVmaW5lcyB0eXBlcyB0aGF0IGFyZSB1c2VkIGluIHRoZSBBQ0wKICAgZGF0 YSBtb2RlbCBidXQgYXJlIG5vdCByZWFsbHkgc3BlY2lmaWMgdG8gQUNMcy4gIFRoZXNlIGRlZmlu aXRpb25zCiAgIGNvdWxkIHBvdGVudGlhbGx5IGJlIG9mIGludGVyZXN0IHRvIG90aGVyIG1vZGVs cyBhcyB3ZWxsOyBrZWVwaW5nCiAgIHRoZW0gaW4gYSBzZXBhcmF0ZSBtb2R1bGUgYWxsb3dzIHRv IGltcG9ydCB0aGVzZSBkZWZpbml0aW9ucwogICBpbmRlcGVuZGVudCBvZiB0aGUgc3VwcG9ydCBm b3IgQUNMcy4KCjMuMi4gIERhdGEgaGllcmFyY2h5CgogICBUaGUgZGF0YSBoaWVyYXJjaHkgdGhh dCBpcyBkZWZpbmVkIGJ5IHRoZSBhY2wgbW9kdWxlIGlzIGRlcGljdGVkIGluCiAgIHRoZSBmb2xs b3dpbmcgRmlndXJlIDEsIHdoZXJlIGJyYWNrZXRzIGVuY2xvc2UgbGlzdCBrZXlzLCAicnciIG1l YW5zCiAgIGNvbmZpZ3VyYXRpb24sICJybyIgbWVhbnMgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YSwg YW5kICI/IiBtZWFucwogICBvcHRpb25hbCBub2RlLiAgUGFyZW50aGVzZXMgZW5jbG9zZSBjaG9p Y2UgYW5kIGNhc2Ugbm9kZXMuICBUaGUKICAgc3RydWN0dXJlIGlzIGEgY29sbGFwc2VkIHN0cnVj dHVyZSBhbmQgZG9lcyBub3QgZGVwaWN0IGFsbAogICBkZWZpbml0aW9uczsgaXQgaXMgaW50ZW5k ZWQgdG8gaWxsdXN0cmF0ZSB0aGUgb3ZlcmFsbCBzdHJ1Y3R1cmUuICBBCiAgIGZ1bGx5IGV4cGFu ZGVkIHN0cnVjdHVyZSBjYW4gYmUgZm91bmQgaW4gRGF0YSBNb2RlbCBTdHJ1Y3R1cmUgU2VjdGlv bgogICAoU2VjdGlvbiA4KS4KCiAgICAgICBtb2R1bGU6IGFjbAogICAgICAgICArLS1ydyBhY2xz CiAgICAgICAgICAgICstLXJ3IGFjbCBbbmFtZV0KICAgICAgICAgICAgIHwgICstLXJ3IG5hbWUK ICAgICAgICAgICAgIHwgICstLXJ3IGFjbC10eXBlCiAgICAgICAgICAgICB8ICArLS1ydyBlbmFi bGUtY2FwdHVyZS1nbG9iYWw/CiAgICAgICAgICAgICB8ICArLS1ydyBjYXB0dXJlLXNlc3Npb24t aWQtZ2xvYmFsPwogICAgICAgICAgICAgfCAgKy0tcncgKGVuYWJsZS1tYXRjaC1jb3VudGVyLWNo b2ljZXMpPwogICAgICAgICAgICAgfCAgKy0tcm8gbWF0Y2g/CiAgICAgICAgICAgICB8CiAgICAg ICAgICAgICB8CiAgICAgICAgICAgICstLXJ3IHBvcnQtZ3JvdXBzCiAgICAgICAgICAgICB8ICAr LS1ydyBwb3J0LWdyb3VwIFtuYW1lXQogICAgICAgICAgICAgfCAgICAgKy0tcncgbmFtZQogICAg ICAgICAgICAgfCAgICAgKy0tcncgcG9ydC1ncm91cC1lbnRyeQogICAgICAgICAgICArLS1ydyB0 aW1lcmFuZ2UtZ3JvdXBzCiAgICAgICAgICAgICB8ICArLS1ydyB0aW1lcmFuZ2UtZ3JvdXAgW25h bWVdCiAgICAgICAgICAgICB8ICAgICArLS1ydyBuYW1lCiAgICAgICAgICAgICB8ICAgICArLS1y dyB0aW1lLXJhbmdlCiAgICAgICAgICAgICstLXJ3IGlwLWFkZHJlc3MtZ3JvdXBzCiAgICAgICAg ICAgICB8ICArLS1ydyBpcC1hZGRyZXNzLWdyb3VwIFtuYW1lXQogICAgICAgICAgICAgfCAgICAg Ky0tcncgbmFtZQogICAgICAgICAgICAgfCAgICAgKy0tcncgYWZpPwogICAgICAgICAgICAgfCAg ICAgKy0tcncgaXAtYWRkcmVzcwoKICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEKCiAgIERh dGEgbm9kZXMgaW4gdGhlIGFjbCBtb2R1bGUgYXJlIGNvbnRhaW5lZCB1bmRlciBhIHNpbmdsZSBj b250YWluZXIKICAgbm9kZSwgImFjbHMiLiAgVGhpcyBub2RlIGNvbnRhaW5zIGEgbGlzdCwgImFj bCIuICBFYWNoIEFDTCBpcwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjksIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgog ICByZXByZXNlbnRlZCBieSBhbiBlbGVtZW50IGluIHRoYXQgbGlzdCBhbmQgaWRlbnRpZmllZCBi eSBhIG5hbWUgdGhhdAogICBzZXJ2ZXMgYXMga2V5IHRvIHRoZSBsaXN0LiAgSW50ZXJmYWNlcyAo d2hpY2ggYXJlIG5vdCBwYXJ0IG9mIHRoZQogICBtb2RlbCkgdG8gd2hpY2ggYW4gQUNMIGlzIGFw cGxpZWQgY2FuIHRoZW4gcmVmZXIgdG8gdGhlIEFDTCB1c2luZwogICB0aGF0IG5hbWUuICBFYWNo IGFjbCBsaXN0IGVsZW1lbnQgaGFzIGZ1cnRoZXJtb3JlIGEgdHlwZSwgYXMKICAgaW5kaWNhdGVk IHRocm91Z2ggImFjbC10eXBlIi4gIFRoZSBhY2wtdHlwZSBkZXRlcm1pbmVzIHdoaWNoIHR5cGVz IG9mCiAgIEFDRXMgY2FuIGJlIGNhbiBiZSBjb250YWluZWQgaW4gYW4gQUNMLiAgVGhlIEFDRSBk ZWZpbml0aW9ucwogICB0aGVtc2VsdmVzIGFyZSBwcm92aWRlZCBieSB0aGUgYWNsLWlwLCBhY2wt bWFjLCBhbmQgYWNsLWFycCBtb2R1bGVzLAogICB3aGljaCBhdWdtZW50IHRoZSBhY2wgZGVmaW5p dGlvbiBpbiB0aGUgYWNsIG1vZHVsZSBhY2NvcmRpbmdseS4gIFRoZQogICBzdWJzZXF1ZW50IGRh dGEgbm9kZXMgaW4gdGhlIGFjbCBsaXN0IGFsbG93IHRvIGNvbmZpZ3VyZSB3aGV0aGVyCiAgIHBh Y2tldHMgdGhhdCBtYXRjaCBhbiBBQ0wgc2hvdWxkIGJlIGNhcHR1cmVkIGZvciBmdXJ0aGVyIGFu YWx5c2lzLgogICBGaW5hbGx5LCB0aGUgbGlzdCBjb250YWlucyBhbiBvYmplY3QgdGhhdCBtYWlu dGFpbnMgYSBjb3VudGVyIG9mIHRoZQogICBudW1iZXIgb2YgQUNMIG1hdGNoZXMuCgogICBBdXhp bGlhcnkgb2JqZWN0cyAicG9ydC1ncm91cHMiLCAiaXAtYWRkcmVzcy1ncm91cHMiLCAidGltZXJh bmdlLQogICBncm91cHMiIGFyZSB1c2VkIHRvIGRlZmluZSBncm91cGluZ3Mgb2YgcG9ydHMgYW5k IG9mIElQLWFkZHJlc3NlcyBhcwogICB3ZWxsIGFzIHNjaGVkdWxlIGluZm9ybWF0aW9uLCByZXNw ZWN0aXZlbHkuICBUaGV5IGFyZSBpbiBlZmZlY3QKICAgY29udmVuaWVuY2Ugb2JqZWN0cyB3aGlj aCBhbGxvdyBBQ0VzIHRvIHJlZmVyIHRvIGdyb3VwaW5ncyBhbmQKICAgc2NoZWR1bGVzIGJ5IG5h bWUsIHJhdGhlciB0aGFuIG5lZWRpbmcgdG8gcmUtc3BlY2lmeSB0aGVtIGluIGVhY2ggQUNFCiAg IHdoZXJlIHRoZXkgYXBwbHkuCgogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBkZXBpY3RzIGhvdyBk aWZmZXJlbnQgdHlwZXMgb2YgQUNFcyBhcmUgaW5zZXJ0ZWQKICAgaW50byB0aGF0IHN0cnVjdHVy ZS4gIEFzIGluZGljYXRlZCBlYXJsaWVyLCB0aGUgY29ycmVzcG9uZGluZwogICBkZWZpbml0aW9u cyBhcmUgcHJvdmlkZWQgaW4gc2VwYXJhdGUgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhlIGFjbAog ICBtb2R1bGUuICBJbiB0aGUgZGF0YSBzdHJ1Y3R1cmUsIHRoZSBhdWdtZW50aW5nIG1vZHVsZSBp cyBpbmRpY2F0ZWQgYnkKICAgdGhlIHByZWZpeCBvZiB0aGUgY29ycmVzcG9uZGluZyBkYXRhIG5v ZGVzOiAiYWNsLWlwIiwgImFjbC1tYWMiLCBhbmQKICAgImFjbC1hcnAiLCByZXNwZWN0aXZlbHku ICBBQ0VzIGZvciBJUHY0IGFuZCBmb3IgSVB2NiBhcmUgYm90aCBkZWZpbmVkCiAgIGluIHRoZSBz YW1lIG1vZHVsZSwgYWNsLWlwLiAgV2hpbGUgaXQgd291bGQgaGF2ZSBiZWVuIHBvc3NpYmxlIHRv CiAgIGRlZmluZSBlYWNoIGluIGl0cyBvd24gc2VwYXJhdGUgbW9kdWxlLCBpdCB3YXMgYSBkZXNp Z24gZGVjaXNpb24gdG8KICAgY29tYmluZSB0aGVtLCBhcyB0aGV5IHNoYXJlIGVub3VnaCBjb21t b25hbGl0eSB0aGF0IGEgc2VwYXJhdGlvbgogICB3b3VsZCBoYXZlIHJlc3VsdGVkIGluIGEgY29u c2lkZXJhYmxlIGFtb3VudCBvZiBkZWZpbml0aW9uCiAgIHJlZHVuZGFuY3kuCgogICBUaGUgZmln dXJlIGRvZXMgbm90IGRlcGljdCBvYmplY3RzIG5vdCBwZXJ0aW5lbnQgdG8gdGhhdCBzdHJ1Y3R1 cmUsCiAgIHN1Y2ggYXMgb2JqZWN0cyBpbnRlbmRlZCB0byBtYWtlIHRoZSBkZWZpbml0aW9uIG9m IHBvcnQgZ3JvdXBzCiAgICgicG9ydC1ncm91cHMiKSwgdGltZXJhbmdlcyAoInRpbWUtcmFuZ2Ut Z3JvdXBzIiksIGFuZCBJUCBhZGRyZXNzCiAgIGdyb3VwcyAoImlwLWFkZHJlc3MtZ3JvdXBzIikg cmV1c2FibGUsIGFzIHdlbGwgYXMgb2JqZWN0cyB0aGF0IGFyZQogICBjb250YWluZWQgaW4gYWNs IGxpc3QgZWxlbWVudHMsIHN1Y2ggYXMgIm5hbWUiIGFuZCAiZW5hYmxlLWNhcHR1cmUtCiAgIGds b2JhbCIuCgogICAgbW9kdWxlOiBhY2wKICAgICAgICstLXJ3IGFjbHMKICAgICAgICAgKy0tcncg YWNsIFtuYW1lXQogICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6YWZpCiAgICAgICAgICAgIHwg ICstLXJ3IGFjbC1pcDppcHY2LWFjZXMKICAgICAgICAgICAgfCAgfCAgKy0tcncgYWNsLWlwOmlw djYtYWNlIFtuYW1lXQogICAgICAgICAgICB8ICB8ICAgICstLXJ3IGFjbC1pcDpuYW1lCiAgICAg ICAgICAgIHwgIHwgICAgKy0tcncgKHJlbWFyay1vci1pcHY2LWNhc2UpPwogICAgICAgICAgICB8 ICB8ICAgICAgICArLS06KHJlbWFyaykKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAy MDEzCgoKICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgICstLXJ3IGFjbC1pcDpyZW1hcmsKICAg ICAgICAgICAgfCAgfCAgICAgICAgKy0tOihpcHY2LWFjZSkKICAgICAgICAgICAgfCAgfCAgICAg ICAgfCAgICstLXJ3IGFjbC1pcDpmaWx0ZXJzCiAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICAg ICAgKy0tIGZpbHRlciBwYXJhbWV0ZXJzCiAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICArLS1y dyBhY2wtaXA6YWN0aW9ucwogICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgICAgICstLSBhY3Rp b24gcGFyYW1ldGVycwogICAgICAgICAgICB8ICB8ICAgICAgICArLS0gcm8gYWNsLWlwOm1hdGNo CgoKICAgbW9kdWxlOiBhY2wKICAgICAgKy0tcncgYWNscwogICAgICAgICAgKy0tcncgYWNsIFtu YW1lXQogICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6YWZpCiAgICAgICAgICAgIHwgICstLXJ3 IGFjbC1pcDppcHY0LWFjZXMKICAgICAgICAgICAgfCAgfCAgKy0tcncgYWNsLWlwOmlwdjQtYWNl IFtuYW1lXQogICAgICAgICAgICB8ICB8ICAgICArLS1ydyBhY2wtaXA6bmFtZQogICAgICAgICAg ICB8ICB8ICAgICArLS1ydyAocmVtYXJrLW9yLWlwdjQtYWNlKT8KICAgICAgICAgICAgfCAgfCAg ICAgICAgKy0tOihyZW1hcmspCiAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICArLS1ydyBhY2wt aXA6cmVtYXJrCiAgICAgICAgICAgIHwgIHwgICAgICAgICstLTooaXB2NC1hY2UpCiAgICAgICAg ICAgIHwgIHwgICAgICAgIHwgICArLS1ydyBhY2wtaXA6ZmlsdGVycwogICAgICAgICAgICB8ICB8 ICAgICAgICB8ICAgICAgICstLSBmaWx0ZXIgcGFyYW1ldGVycwogICAgICAgICAgICB8ICB8ICAg ICAgICB8ICAgKy0tcncgYWNsLWlwOmFjdGlvbnMKICAgICAgICAgICAgfCAgfCAgICAgICAgfCAg ICAgICArLS0gYWN0aW9uIHBhcmFtZXRlcnMKICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tIHJv IGFjbC1pcDptYXRjaAoKCiAgIG1vZHVsZTogYWNsCiAgICAgICArLS1ydyBhY2xzCiAgICAgICAg ICAgKy0tcncgYWNsIFtuYW1lXQogICAgICAgICAgICB8ICArLS1ydyBhY2wtbWFjOm1hYy1hY2Vz CiAgICAgICAgICAgIHwgIHwgICstLXJ3IGFjbC1tYWM6bWFjLWFjZSBbbmFtZV0KICAgICAgICAg ICAgfCAgfCAgICAgKy0tcncgYWNsLW1hYzpuYW1lCiAgICAgICAgICAgIHwgIHwgICAgICstLXJ3 IChyZW1hcmstb3ItbWFjLWFjZSk/CiAgICAgICAgICAgIHwgIHwgICAgICAgICstLToocmVtYXJr KQogICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgKy0tcncgYWNsLW1hYzpyZW1hcmsKICAgICAg ICAgICAgfCAgfCAgICAgICAgKy0tOihtYWMtYWNlKQogICAgICAgICAgICB8ICB8ICAgICAgICB8 ICAgKy0tcncgYWNsLW1hYzpmaWx0ZXJzCiAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICAgICAg Ky0tIGZpbHRlciBwYXJhbWV0ZXJzCiAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICArLS1ydyBh Y2wtbWFjOmFjdGlvbnMKICAgICAgICAgICAgfCAgfCAgICAgICAgfCAgICAgICArLS0gYWN0aW9u IHBhcmFtZXRlcnMKICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tIHJvIGFjbC1tYWM6bWF0Y2gK CiAgIG1vZHVsZTogYWNsCiAgICAgICArLS1ydyBhY2xzCiAgICAgICAgICAgKy0tcncgYWNsIFtu YW1lXQogICAgICAgICAgICB8ICArLS1ydyBhY2wtYXJwOmFycC1hY2VzCiAgICAgICAgICAgIHwg IHwgICstLXJ3IGFjbC1hcnA6YXJwLWFjZSBbbmFtZV0KCgoKSHVhbmcsIGV0IGFsLiAgICAgICAg ICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBG ZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgfCAgfCAgICAgKy0tcncgYWNsLWFycDpuYW1lCiAg ICAgICAgICAgIHwgIHwgICAgICstLXJ3IChyZW1hcmstb3ItYXJwLWFjZSk/CiAgICAgICAgICAg IHwgIHwgICAgICAgICstLToocmVtYXJrKQogICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgKy0t cncgYWNsLWFycDpyZW1hcmsKICAgICAgICAgICAgfCAgfCAgICAgICAgKy0tOihhcnAtYWNlKQog ICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgKy0tcncgYWNsLWFycDpmaWx0ZXJzCiAgICAgICAg ICAgIHwgIHwgICAgICAgIHwgICAgICAgKy0tIGZpbHRlciBwYXJhbWV0ZXJzCiAgICAgICAgICAg IHwgIHwgICAgICAgIHwgICArLS1ydyBhY2wtYXJwOmFjdGlvbnMKICAgICAgICAgICAgfCAgfCAg ICAgICAgfCAgICAgICArLS0gYWN0aW9uIHBhcmFtZXRlcnMKICAgICAgICAgICAgfCAgfCAgICAg ICAgKy0tIHJvIGFjbC1hcnA6bWF0Y2gKCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAy CgogICBBcyBpcyBldmlkZW50IGZyb20gRmlndXJlIDIsIHRoZSBzYW1lIGdlbmVyaWMgZGVzaWdu IHBhdHRlcm4gaXMKICAgcmVmbGVjdGVkIGluIGV2ZXJ5IEFDTCB0eXBlLiAgRWFjaCBBQ0wgY29u dGFpbnMgYSBsaXN0IG9mIEFDRXMsCiAgIGlkZW50aWZpZWQgYnkgYSBuYW1lIGJ5IHdoaWNoIEFD RXMgaW4gdGhlIGxpc3QgYXJlIG9yZGVyZWQuICBFYWNoIEFDRQogICBjb25zaXN0cyBlaXRoZXIg b2YgYSByZW1hcmsgb3Igb2YgYW4gYWN0dWFsIGFjY2VzcyBjb250cm9sIHJ1bGUuCiAgIFJlbWFy a3MgYXJlIGluIGVmZmVjdCBjb21tZW50IGxpbmVzIGluc2lkZSBhbiBBQ0wgdGhhdCBhcmUgaW50 ZW5kZWQKICAgZm9yIGh1bWFuIG9yIGFkbWluaXN0cmF0b3IgY29uc3VtcHRpb24uICBUaGV5IGFy ZSBpbmNsdWRlZCBpbiB0aGUKICAgWUFORyBtb2R1bGUgdG8gbWFpbnRhaW4gY29uc2lzdGVuY3kg d2l0aCBDTEkuICBBY2Nlc3MgY29udHJvbCBydWxlcywKICAgb24gdGhlIG90aGVyIGhhbmQsIGNv bnNpc3Qgb2YgYSBsZWZ0IGhhbmQgc2lkZSAoImZpbHRlcnMiKSB0aGF0CiAgIHNwZWNpZmllcyBh IHNldCBvZiBtYXRjaGluZyBjcml0ZXJpYSBhbmQgYSByaWdodCBoYW5kIHNpZGUKICAgKCJhY3Rp b25zIikgdGhhdCBzcGVjaWZpZXMgdGhlIGFjdGlvbiB0byB0YWtlIHdoZW4gbWF0Y2hpbmcgY3Jp dGVyaWEKICAgYXJlIG1ldC4gIEFuIG92ZXJ2aWV3IG9mIHRoZSBmdWxsIGxpc3Qgb2YgZmlsdGVy IGFuZCBwYXJhbWV0ZXJzIGlzCiAgIGdpdmVuIGluIFNlY3Rpb24gOC4KCiAgIFNpbmNlIHRoZSBk ZXNpZ24gcGF0dGVybiBmb3IgZWFjaCBBQ0wgdHlwZSBpcyB0aGUgc2FtZSwgYW4KICAgYWx0ZXJu YXRpdmUgZGVzaWduIHRvIHRoZSBZQU5HIG1vZHVsZXMgd291bGQgaGF2ZSBiZWVuIHRvIGV4dGVu ZCB0aGUKICAgImFjbCIgbW9kdWxlIHRvIGluY2x1ZGUgdGhlIGRhdGEgbm9kZXMgdXAgdG8gdGhl IGxldmVsIGRlcGljdGVkIGluCiAgIEZpZ3VyZSAyLCBhcyB0aGUgcmVhbCBkaXN0aW5jdGlvbiBv Y2N1cnMgaW4gdGhlIGZpbHRlciBhbmQgYWN0aW9uCiAgIHBhcmFtZXRlcnMgdGhhdCBvY2N1ciBi ZWxvdyBpdC4gIEluIHRoYXQgY2FzZSwgaG93ZXZlciwgdGhlCiAgIGNvcnJlc3BvbmRpbmcgZGF0 YSBub2RlcyB3b3VsZCBoYXZlIGhhZCB0byBjb250ZW5kIHdpdGggbW9yZSBjb21wbGV4CiAgIGNv bmRpdGlvbnMuICBUaGUgbW9kdWxlcyBkZWZpbmVkIGhlcmUgYWltIGF0IGtlZXBpbmcgY29tcGxl eGl0eSBvZgogICBkZWZpbml0aW9ucyB3aXRoaW4gdGhlIG1vZHVsZXMgYXMgbG93IGFzIHBvc3Np YmxlLCBhdCB0aGUgcHJpY2Ugb2YKICAgcmVwZWF0aW5nIGEgZmV3IGRhdGEgbm9kZXMgdGhhdCBw cm92aWRlIHRoZSBvdmVyYWxsIHRvcCBsZXZlbAogICBzdHJ1Y3R1cmUuCgozLjMuICBPdGhlciBD b25zaWRlcmF0aW9ucwoKMy4zLjEuICBFeHRlbnNpYmlsaXR5CgogICBJZiBuZWVkZWQsIHRoZSBt b2RlbCBjYW4gYmUgZXh0ZW5kZWQgZm9yIG90aGVyIHR5cGVzIG9mIEFDTHMgaW4KICAgc3RyYWln aHRmb3J3YXJkIG1hbm5lci4gIE5ldyB0eXBlcyBvZiBBQ0xzIGNhbiBiZSBkZWZpbmVkIGluCiAg IGFkZGl0aW9uYWwgWUFORyBtb2R1bGVzIHRoYXQgYXBwbHkgdGhlIHNhbWUgZGVzaWduIHBhdHRl cm5zIG11Y2ggaW4KICAgdGhlIHNhbWUgd2F5IGFzIGluIHRoZSBjYXNlIG9mIElQLCBNQUMsIGFu ZCBBUlAgQUNMcy4KCgoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDI5LCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKMy4z LjIuICBBQ0wgQ2hhaW4gU3VwcG9ydAoKICAgQUNMIGNoYWlucyBhcmUgdXNlZCBpbiBzb21lIGFw cGxpY2F0aW9uIGRvbWFpbnMuICBBQ0wgY2hhaW5zIGFyZSBub3QKICAgaW5jbHVkZWQgaW4gdGhl IGRhdGEgbW9kZWwsIGJ1dCBjb3VsZCBiZSBhY2NvbW1vZGF0ZWQgaW4gdGhlIG1vZGVsCiAgIHRo cm91Z2ggZXh0ZW5zaW9ucyBpbiBhIHN0cmFpZ2h0Zm9yd2FyZCB3YXkuCgogICBBQ0wgY2hhaW5z IHdvcmsgcm91Z2hseSBhcyBmb2xsb3dzLiAgSW4gYW4gQUNMIGNoYWluLCBhcyBhbgogICBhbHRl cm5hdGl2ZSB0byBhbiBhY3Rpb24sIGFuIEFDRSBjYW4gcG9pbnQgdG8gYW5vdGhlciBBQ0wuICBJ ZiBhCiAgIHBhY2tldCBtYXRjaGVzIHRoZSBmaWx0ZXIgY29uZGl0aW9uLCBpdCBpcyBzdWJqZWN0 ZWQgdG8gdGhlIG90aGVyCiAgIEFDTC4gIElmIHRoZSBvdGhlciBBQ0wgY29udGFpbnMgYW4gQUNF IHRoYXQgbWF0Y2hlcywgdGhhdCBhY3Rpb24gaXMKICAgZXhlY3V0ZWQuICBJZiB0aGVyZSBpcyBu byBtYXRjaCwgcHJvY2Vzc2luZyBpcyByZXR1cm5lZCB0byB0aGUgZmlyc3QKICAgQUNMIGFuZCBw cm9jZXNzaW5nIGNvbnRpbnVlcyB3aXRoIHRoZSBzdWJzZXF1ZW50IEFDRXMgdW50aWwgYSBtYXRj aAogICBpcyBmb3VuZC4gIFRoaXMgd2F5LCBjaGFpbmVkIEFDTHMgY2FuIGJlIGNvbnNpZGVyZWQg YXMgYSBzcGVjaWFsIGZvcm0KICAgb2YgIkFDTCBzdWJyb3V0aW5lIi4KCiAgIEFuIGV4YW1wbGUg b2YgYW4gQUNMIGNoYWluIG1pZ2h0IGJlIGEgcnVsZSB0aGF0IGNvbnRhaW5zIGEgZmlsdGVyIGZv cgogICBhIHNwZWNpZmljIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIGluIGFuIElQIHBhY2tldCwg dGhlbiBpbnZva2VzCiAgIGFub3RoZXIgQUNMIHRoYXQgY29udGFpbnMgYSBzcGVjaWZpYyBzZXQg b2YgZmlyZXdhbGwgcnVsZXMgZm9yCiAgIHRyYWZmaWMgZGlyZWN0ZWQgYXQgdGhhdCBwYXJ0aWN1 bGFyIHBvcnQuICBFdmVuIHRob3VnaCB0aGUgZGF0YSBtb2RlbAogICBmb3IgQUNMIHByZXNlbnRl ZCBpbiB0aGlzIGRvY3VtZW50IHVzZXMgYSBmbGF0IGxpc3Qgb2YgQUNFIGluIGVhY2gKICAgQUNM LCB0aGUgYWN0aW9ucyBpbiB0aGUgbW9kZWwgY2FuIGJlIGF1Z21lbnRlZCB0byBzdXBwb3J0IEFD TCBjaGFpbnMuCgogICBUaGUgbW9kZWwgY2FuIGJlIGV4dGVuZGVkIHdpdGggQUNMIGNoYWlucyBy b3VnaGx5IGFzIGZvbGxvd3M6IEEgbmV3CiAgIGFjbC1jaGFpbmluZyBhY3Rpb24gaXMgaW50cm9k dWNlZCwgcmVwcmVzZW50ZWQgYXMgYSBsZWFmIHdob3NlIHZhbHVlCiAgIGNvbnRhaW5zIGEgcmVm ZXJlbmNlIHRvIGFuIEFDTCBhcyBhIHBhcmFtZXRlci4gIEZvciBBQ0xzIHRoYXQgYXJlCiAgIGV4 cGVjdGVkIHRvIG5vdCB0ZXJtaW5hdGUgd2hlbiBubyBBQ0UgbWF0Y2hlcywgYnV0IHJldHVybiBw cm9jZXNzaW5nCiAgIHRvIHRoZSBpbnZva2luZyBBQ0wsIGFuIG9wdGlvbmFsIEFDTCBwYXJhbWV0 ZXIgY2FuIGJlIGludHJvZHVjZWQgdGhhdAogICBpbmRpY2F0ZXMgZm9yIGNoYWluZWQgQUNMcyB3 aGljaCBjaGFpbmluZyBiZWhhdmlvciBzaG91bGQgYXBwbHkuCiAgIEJlbG93IGlzIGFuIGV4YW1w bGUgb2YgaG93IHRoZSBhY2wtaXAgbW9kZWwgY291bGQgYmUgZXh0ZW5kZWQgdG8KICAgc3VwcG9y dCBBQ0wgY2hhaW5zIGZvciBpcC12NDoKCiAgYXVnbWVudCAiL2FjbDphY2xzL2FjbDphY2wvYWNs LWlwOmlwdjQtYWNlcyIgKwogICAgICAiL2FjbC1pcDppcHY0LWFjZS9hY2wtaXA6YWN0aW9ucyIg ewoKICAgICAgbGVhZiBjaGFpbiB7CiAgICAgICAgICB0eXBlIGFjbC1yZWYgOwogICAgICAgICAg ZGVzY3JpcHRpb24gIlJlZmVyZW5jZSB0byBhbm90aGVyIEFDTCBuYW1lIHRvIGNoYWluIHRoZSBB Q0VzIjsKICAgICAgfQogIH0KCgozLjMuMy4gIEFDTCBUZXN0IEV4dGVuc2lvbnMKCiAgIEdpdmVu IHRoZSBjb21wbGV4aXR5IG9mIEFDTHMgaW4gbWFueSBkZXBsb3ltZW50cywgZGVidWdnaW5nIEFD THMgYW5kCiAgIGFzc2Vzc2luZyB3aGV0aGVyIGFuIEFDTCBoYXMgdGhlIGFjdHVhbCBkZXNpcmVk IGVmZmVjdCBjYW4gYmUgYQogICBjaGFsbGVuZ2UuICBJbiBvcmRlciB0byBmYWNpbGl0YXRlIHRo b3NlIHRhc2tzIGFuZCBhbGxvdyB0byBjaGVjawogICB3aGV0aGVyIGFuIEFDTCBoYXMgaW5kZWVk IHRoZSBpbnRlbmRlZCBlZmZlY3QsIGFuIGFkZGl0aW9uYWwKICAgYWRtaW5pc3RyYXRpdmUgZnVu Y3Rpb24gdGhhdCBhbGxvd3MgYXBwbGljYXRpb25zIGFuZCB1c2VycyB0byB0ZXN0IGEKCgoKSHVh bmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAg ICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAg ICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgcGFja2V0IGFnYWluc3QgdGhlIEFD TCBjYW4gYmUgaW50cm9kdWNlZC4gIFRoZSBmdW5jdGlvbiBjYW4gdGFrZSB0aGUKICAgZm9ybSBv ZiBhbiBSUEMgd2hpY2ggdGFrZXMgYXMgaW5wdXQgcGFyYW1ldGVyIGEgbGVhZiB3aXRoIHRoZQog ICByZWZlcmVuY2UgdG8gdGhlIEFDTCB0aGF0IGlzIHRvIGJlIHRlc3RlZCwgYW5kIGEgbGVhZiB3 aXRoIGEgcGFja2V0LgogICBUaGUgb3V0cHV0IHBhcmFtZXRlciBpbmNsdWRlcyBhIGxlYWYgaW5k aWNhdGluZyB0aGUgYWN0aW9uIHRoYXQgaXMKICAgdGFrZW4gYXMgYSByZXN1bHQsIGFzIHdlbGwg YXMgYSBsZWFmIHdpdGggdGhlIHJlZmVyZW5jZSB0byB0aGUKICAgbWF0Y2hpbmcgQUNFLgoKNC4g IGFjbCBNb2R1bGUKCiAgIE1vZHVsZSAiYWNsIiBpcyBhIHRvcCBjb250YWluZXIgbW9kdWxlIGZv ciBhbGwgQUNMcy4gIEl0IGNvbnRhaW5zIGEKICAgY29udGFpbmVyICJhY2xzIiB3aXRoIGEgbGlz dCAiYWNsIiBvZiBuYW1lZCBBQ0xzLiAgTW9kdWxlcyAiYWNsLWlwIiwKICAgImFjbC1tYWMiLCBh bmQgImFjbC1hcnAiIGF1Z21lbnQgdGhpcyBsaXN0IHdpdGggdGhlIG9iamVjdHMgdGhhdCBhcmUK ICAgc3BlY2lmaWMgdG8gZWFjaCByZXNwZWN0aXZlIHR5cGUgb2YgQUNMLiAgSW4gYWRkaXRpb24s IG1vZHVsZSAiYWNsIgogICBhbHNvIGRlZmluZXMgYSBzZXQgb2YgZmVhdHVyZXMsIHJldXNhYmxl IHR5cGVzLCBhbmQgcmV1c2FibGUKICAgZ3JvdXBpbmdzLgoKNC4xLiAgRmVhdHVyZXMKCiAgIFdo ZW4gaXQgY29tZXMgdG8gQUNMIGltcGxlbWVudGF0aW9ucywgYSB3aWRlIHJhbmdlIG9mIGRpZmZl cmVudAogICBjYXBhYmlsaXRpZXMgZXhpc3RzIGFjcm9zcyBkZXZpY2VzLiAgRm9yIGV4YW1wbGUs IG5vdCBldmVyeSBkZXZpY2UKICAgaW1wbGVtZW50cyBldmVyeSB0eXBlIG9mIEFDTC4gIFNvbWUg ZGV2aWNlcyBtYXkgc3VwcG9ydCB0aW1lLWJhc2VkCiAgIEFDTHMgdGhhdCBhcmUgb25seSBpbiBl ZmZlY3QgZHVyaW5nIHNwZWNpZmllZCB0aW1lcywgb3RoZXJzIG1heSBub3QuCgogICBJbiBvcmRl ciB0byBhY2NvbW1vZGF0ZSB0aGlzIHdpZGUgcmFuZ2Ugb2YgY2FwYWJpbGl0aWVzLCB0aGlzIGRh dGEKICAgbW9kZWwgbWFrZXMgZXh0ZW5zaXZlIHVzZSBvZiB0aGUgImZlYXR1cmUiIGNvbnN0cnVj dC4gIFRoZSBkZWZpbmVkCiAgIGZlYXR1cmVzIGFsbG93IGltcGxlbWVudGF0aW9ucyB0byBkZWNs YXJlIHdoaWNoIGNhcGFiaWxpdGllcyB0aGV5CiAgIHN1cHBvcnQsIGFuZCBvbmx5IHN1cHBvcnQg dGhlIGNvcnJlc3BvbmRpbmcgcG9ydGlvbnMgb2YgdGhlIGRhdGEKICAgbW9kZWwuCgo0LjIuICBU eXBlcwoKICAgVGhlIGRlZmluaXRpb24gb2YgQUNMcyByZXF1aXJlcyBhIG51bWJlciBvZiBuZXcg ZGF0YSB0eXBlcyBpbnRyb2R1Y2VkCiAgIGluIHRoaXMgZGF0YSBtb2RlbC4gIFRhYmxlIDEgZGVw aWN0cyBkYXRhIHR5cGVzIHRoYXQgYXJlIHVuaXF1ZSB0bwogICBBQ0xzLiAgVGFibGUgMiBkZXBp Y3RzIGRhdGEgdHlwZXMgdGhhdCBhcmUgcmVxdWlyZWQgYnkgQUNMcywgYnV0IG5vdAogICBzcGVj aWZpYyB0byB0aGVtLCBhbmQgdGhhdCBtYXkgaGVuY2UgYmUgcmV1c2VkIGJ5IG90aGVyIG1vZGVs cy4KICAgVGhvc2UgZGF0YSB0eXBlcyBhcmUgZGVmaW5lZCBpbiBtb2R1bGUgImNvbW1vbi10eXBl cyIuICBGb3IgZGV0YWlscwogICBvZiBlYWNoIHR5cGUsIHBsZWFzZSByZWZlciB0byB0aGUgY29y cmVzcG9uZGluZyB0eXBlZGVmIGRlc2NyaXB0aW9ucwogICBhbmQgcmVmZXJlbmNlcyBpbiB0aGUg bW9kZWwuCgoKCgoKCgoKCgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgog ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKwogICAgICAgfCBZQU5HIHR5cGUgICAgICAgICAgICB8IGJhc2UgdHlwZSAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwogICAgICAgfCBhY2wtY29tcGFyYXRvciAgICAgICB8IGVudW1lcmF0 aW9uICAgICAgICAgICAgICAgICAgfAogICAgICAgfCBhY2wtYWN0aW9uICAgICAgICAgICB8IGVu dW1lcmF0aW9uICAgICAgICAgICAgICAgICAgfAogICAgICAgfCBhY2wtcmVtYXJrICAgICAgICAg ICB8IHN0cmluZyAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgfCBhY2wtdHlwZS1yZWYg ICAgICAgICB8IGlkZW50aXR5cmVmICAgICAgICAgICAgICAgICAgfAogICAgICAgfCBhY2wtcmVm ICAgICAgICAgICAgICB8IGxlYWZyZWYgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgfCBw b3J0LWdyb3VwLXJlZiAgICAgICB8IGxlYWZyZWYgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgfCBpcC1hZGRyZXNzLWdyb3VwLXJlZiB8IGxlYWZyZWYgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgfCB0aW1lLXJhbmdlLVJlZiAgICAgICB8IGxlYWZyZWYgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgfCB3ZWVrZGF5cyAgICAgICAgICAgICB8IGJpdHMgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgfCBhY2wtbmFtZS1zdHJpbmcgICAgICB8IHN0cmluZyAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRh YmxlIDEKCiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rCiAgICAgICB8IFlBTkcgdHlwZSAgICAgICAgICAgIHwgYmFzZSB0eXBlICAg ICAgICAgICAgICAgICAgICB8CiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICB8IGNvcyAgICAgICAgICAgICAgICAgIHwg dWludDggICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IHRvcyAgICAgICAgICAgICAg ICAgIHwgdWludDggICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IHByZWNlZGVuY2Ug ICAgICAgICAgIHwgdWludDggICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IHRjcC1m bGFnLXR5cGUgICAgICAgIHwgZW51bWVyYXRpb24gICAgICAgICAgICAgICAgICB8CiAgICAgICB8 IGV0aGVyLXR5cGUgICAgICAgICAgIHwgc3RyaW5nICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICAgICB8IGlwLXByb3RvY29sICAgICAgICAgIHwgdWludDggICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICB8IGlnbXAtY29kZSAgICAgICAgICAgIHwgdWludDggICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICB8IGljbXAtdHlwZSAgICAgICAgICAgIHwgdWludDMyICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICB8IGljbXAtY29kZSAgICAgICAgICAgIHwgdWludDMyICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IHZsYW4taWRlbnRpZmllciAgICAgIHwgdWlu dDE2ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICB8IHRpbWUtdG8tbGl2ZSAgICAgICAg IHwgdWludDMyICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgogICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGFibGUgMgoKNC4zLiAgR3JvdXBpbmdzCgogICBUaGUgZGF0YSBtb2RlbCBk ZWZpbmVzIHR3byBncm91cGluZ3MsIEFDRS1DT01NT04gYW5kIEZJTFRFUi1DT01NT04uCgogICBv ICBBQ0UtQ09NTU9OIGlzIGEgY29sbGVjdGlvbiBvZiBub2RlcyB0aGF0IHNob3VsZCBiZSBhZGRl ZCB0byBldmVyeQogICAgICBBQ0UgbGlzdCBlbnRyeS4gIEFDRS1DT01NT04gY29udGFpbnMgdGhl IGFjdGlvbnMgY29udGFpbmVyIGFuZCBhCiAgICAgIHJlYWQtb25seSBtYXRjaCBsZWFmLiAgVGhl IGFjdGlvbnMgY29udGFpbmVyIGNvbnRhaW5zIHR3byBsZWF2ZXMuCgogICAgICAqICBBbiAiYWN0 aW9uIiBsZWFmIHRoYXQgc3BlY2lmaWVzIHdoYXQgdG8gZG8gd2l0aCB0aGUgcGFja2V0IHdoZW4K ICAgICAgICAgdGhlIG1hdGNoaW5nIGNyaXRlcmlhIGlzIG1ldCwgZm9yIGV4YW1wbGUsIHRvIGRy b3AgdGhlIHBhY2tldC4KCiAgICAgICogIEEgImxvZyIgbGVhZiB0aGF0IGluZGljYXRlcyB3aGV0 aGVyIHRvIGNyZWF0ZSBhIGxvZyBlbnRyeSB3aGVuCiAgICAgICAgIGFuIGFjZSBmaWx0ZXIgbWF0 Y2hlcy4gIChTb21lIGRldmljZXMgbWF5IG5vdCBzdXBwb3J0IGEgbG9nCgoKCkh1YW5nLCBldCBh bC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdl IDEyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAg ICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgIGNhcGFiaWxpdHkuICBIZW5jZSBzdXBw b3J0IG9mIHRoaXMgbGVhZiBpcyBjb25kaXRpb25hbCBvbgogICAgICAgICBkZWNsYXJhdGlvbiBv ZiBhIGNvcnJlc3BvbmRpbmcgZmVhdHVyZSwgYXMgaW5kaWNhdGVkIGJ5IHVzZSBvZgogICAgICAg ICB0aGUgImlmLWZlYXR1cmUiIGNvbnN0cnVjdC4pCgogICBvICBGSUxURVItQ09NTU9OIGlzIGEg Y29sbGVjdGlvbiBvZiBub2RlcyB0aGF0IHNob3VsZCBiZSBhZGRlZCB0bwogICAgICBldmVyeSAn ZmlsdGVycycgY29udGFpbmVyIHdpdGhpbiBlYWNoIEFDRSBsaXN0IGVudHJ5LgoKNC40LiAgQ29u dGFpbmVycwoKNC40LjEuICBhY2xzIENvbnRhaW5lcgoKICAgQ29udGFpbmVyICJhY2xzIiBjb250 YWlucyBhIGxpc3QgImFjbCIgb2YgbmFtZWQgQUNMcy4gIEVhY2ggbGlzdAogICBlbGVlbWVudCAi YWNsIiBjb250YWlucyB0aGUgZm9sbG93aW5nIGdsb2JhbCBsZWF2ZXMuICBUaGUgbGlzdAogICBl bGVtZW50cyBhcmUgYXVnbWVudGVkIHdpdGggYWRkaXRpb25hbCBkYXRhIG5vZGVzIGRlZmluZWQg aW4gbW9kdWxlcwogICAiYWNsLWFycCIsICJhY2wtbWFjIiwgYW5kICJhY2wtaXAiLgoKICAgbyAg bmFtZQoKICAgbyAgYWNsLXR5cGUKCiAgIG8gIGVuYWJsZS1jYXB0dXJlLWdsb2JhbAoKICAgbyAg Y2FwdHVyZS1zZXNzaW9uLWlkLWdsb2JhbAoKICAgbyAgZW5hYmxlLW1hdGNoLWNvdW50ZXItY2hv aWNlczogVGhlIGRpZmZlcmVuY2Ugb2YgdGhlc2UgdHdvIGNob2ljZXMKICAgICAgaXMgdGhhdCAi ZW5hYmxlLW1hdGNoLWNvdW50ZXIiIGluZGljYXRlcyB0byBjb2xsZWN0IHRvdGFsIG1hdGNoCiAg ICAgIHN0YXRpc3RpY3MgZm9yIGFsbCBhY2VzLCB3aGVyZWFzICJlbmFibGUtcGVyLWVudHJ5LW1h dGNoLWNvdW50ZXIiCiAgICAgIGluZGljYXRlcyB0byBjb2xsZWN0IG1hdGNoIHN0YXRpc3RpY3Mg Zm9yIGVhY2ggQUNFLgoKICAgbyAgbWF0Y2gKCjQuNC4yLiAgcG9ydC1ncm91cHMgQ29udGFpbmVy CgogICBDb250YWluZXIgInBvcnQtZ3JvdXBzIiBhbGxvd3MgdG8gY2xhc3NpZnlpbmcgcHJvdG9j b2wgcG9ydCBpbnRvCiAgIGdyb3Vwcy4gIEl0IGNvbnRhaW5zIGEgc2VxdWVuY2Ugb2YgInBvcnQt Z3JvdXAiIGRhdGEgbm9kZXMuICBFYWNoCiAgICJwb3J0LWdyb3VwIiBkZWZpbmVzIGEgcmFuZ2Ug b2YgcG9ydHMgYW5kIGNhbiBiZSByZWZlcnJlZCB0byBieSBuYW1lLgogICBNdWx0aXBsZSBBQ0Vz IGNhbiByZWZlciB0byB0aGUgc2FtZSBwb3J0IGdyb3VwLiAgVGhlIGZvbGxvd2luZyBpcyBhCiAg IE5ldGNvbmYgWE1MIGV4YW1wbGUgb2YgcG9ydC1ncm91cHMgYW5kIGhvdyBpdCBpcyByZWZlcnJl ZCB0byBmcm9tIGFuCiAgIEFDRS4KCgoKCgoKCgoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJy dWFyeSAyMDEzCgoKICAgPHNyYy1wb3J0LWdyb3VwLW5hbWU+CiAgIDxwb3J0LWdyb3VwLW5hbWU+ cG9ydC10dW5uZWwxPC9wb3J0LWdyb3VwPgogICA8L3NyYy1wb3J0LWdyb3VwLW5hbWU+CgogICA8 cG9ydC1ncm91cHM+CiAgICAgPHBvcnQtZ3JvdXA+CiAgICAgICA8bmFtZT5wb3J0LXR1bm5lbDE8 L25hbWU+CiAgICAgICA8cG9ydC1ncm91cC1lbnRyeT4KICAgICAgICAgPG5hbWU+aHR0cC1wcm94 eTwvbmFtZT4KICAgICAgICAgPHBvcnQtbG93ZXI+MjE8L3BvcnQtbG93ZXI+CiAgICAgICAgIDxw b3J0LXVwcGVyPiAyMjwvcG9ydC11cHBlcj4KICAgICAgICA8L3BvcnQtZ3JvdXAtZW50cnk+CiAg ICAgPC9wb3J0LWdyb3VwPgogICA8L3BvcnQtZ3JvdXBzPgoKCjQuNC4zLiAgdGltZXJhbmdlLWdy b3VwcyBDb250YWluZXIKCiAgIENvbnRhaW5lciAidGltZXJhbmdlLWdyb3VwcyIgY29udGFpbmVy IGNvbnRhaW5zIGEgbGlzdCwgInRpbWVyYW5nZS0KICAgZ3JvdXAiLiAgRWVhY2ggb2YgaXRzIGVs ZW1lbnRzIGRlZmluZXMgYSBzZXF1ZW5jZSBvZiB0aW1lIHJhbmdlcywKICAgInRpbWUtcmFuZ2Ui LiAgRWFjaCB0aW1lLXJhbmdlIG9iamVjdCBjb25zaXN0cyBvZiBlaXRoZXIgYSByZW1hcmsKICAg KGNvbW1lbnRzIGZvciB0aGUgdGltZSByYW5nZSksIG9yIG9mIGFuIGFic29sdXRlIHRpbWUgZm9y IHN0YXJ0IG9yCiAgIGVuZCAob3IgYm90aCkgb2YgdGhlIHRpbWUgcmFuZ2UsIG9yIGEgcGVyaW9k aWMgdGltZSBmb3Igc3RhcnQgb3IgZW5kCiAgIG9yIGJvdGguICBPYmplY3QgInJlbWFyayIgY29u dGFpbnMgYWRtaW5pc3RyYXRvci1wcm92aWRlZCBjb21tZW50cwogICBmb3IgdGhlIHRpbWUtcmFu Z2UgdGhhdCB3aWxsIGJlIGtlcHQgaW4gdGhlIGRldmljZS4gIExpa2Ugd2l0aCBwb3J0CiAgIGdy b3VwcywgdGhlIHNhbWUgdGltZS1yYW5nZSBjYW4gYmUgcmV1c2VkIGJ5IGRpZmZlcmVudCBBQ0Vz LiAgVGhlCiAgIGZvbGxvd2luZyBpcyBhIE5ldGNvbmYgWE1MIGV4YW1wbGUgb2YgYSB0aW1lcmFu Z2UgZ3JvdXAgdGhhdCBjb250YWlucwogICBhIHJlbWFyayBhbmQgYSBzaW5nbGUgdGltZSByYW5n ZS4KCiAgIDx0aW1lcmFuZ2UtZ3JvdXBzPgogICAgIDx0aW1lcmFuZ2UtZ3JvdXA+CiAgICAgICA8 bmFtZT53ZWVrZGF5PC9uYW1lPgogICAgICAgPHRpbWUtcmFuZ2U+CiAgICAgICAgIDxuYW1lPjEw PC9uYW1lPgogICAgICAgICA8cmVtYXJrPiBlbWFpbCBzZXJ2ZXIgbWFpbnRlbmFuY2U8L3JlbWFy az4KICAgICAgIDwvdGltZS1yYW5nZT4KICAgICAgIDx0aW1lLXJhbmdlPgogICAgICAgICA8bmFt ZT4yMDwvbmFtZT4KICAgICAgICAgPHBlcmlvZGljPgogICAgICAgICAgIDx3ZWVrZGF5PgogICAg ICAgICAgICAgTW9uZGF5IFR1ZXNkYXkgV2VkbmVzZGF5IFRodXJzZGF5IEZyaWRheQogICAgICAg ICAgIDwvd2Vla2RheT4KICAgICAgICAgICAgIDxzdGFydD4gMjE6MDA6MDA8L3N0YXJ0PgogICAg ICAgICAgIDxlbmQ+IDI0OjAwOjAwPC9lbmQ+CiAgICAgICAgICA8L3BlcmlvZGljPgogICAgICAg IDwvdGltZS1yYW5nZT4KICAgICA8L3RpbWVyYW5nZS1ncm91cD4KICAgPC90aW1lcmFuZ2UtZ3Jv dXBzPgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMg ICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg IHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgo0LjQuNC4gIGlwLWFk ZHJlc3MtZ3JvdXBzIENvbnRhaW5lcgoKICAgQ29udGFpbmVyICJpcC1hZGRyZXNzLWdyb3VwcyIg Y29udGFpbnMgaXMgbGlzdCAiaXAtYWRkcmVzcy1ncm91cCIgb2YKICAgbmFtZWQgSVAgYWRkcmVz cyBncm91cHMuICBFYWNoIElQIGFkZHJlc3MgZ3JvdXAgaXMgYSBzZXF1ZW5jZSBvZgogICBwYWly cyAiaXAtYWRkcmVzcyIgYW5kICJtYXNrIiwgb3IgYSBwYWlyIG9mICJob3N0IiBhbmQgImhvc3Qt CiAgIGFkZHJlc3MiLiAgRWFjaCBJUCBhZGRyZXNzIGdyb3VwIGNhbiBiZSByZWZlcnJlZCBmcm9t IGFuIEFDRSBieSBuYW1lLgogICBUaGUgZm9sbG93aW5nIGlzIGEgTmV0Y29uZiBYTUwgZXhhbXBs ZSBvZiBhbiBJUCBhZGRyZXNzIGdyb3VwIGFuZCBob3cKICAgaXQgaXMgcmVmZXJyZWQgdG8gZnJv bSBhbiBBQ0UuCgogICA8aXAtYWRkcmVzcy1ncm91cHM+CgogICAgIDxpcC1hZGRyZXNzLWdyb3Vw PgogICAgICAgPG5hbWU+RW1haWwtU2VydmVyLUlQVjQ8L25hbWU+CiAgICAgICA8aXAtYWRkcmVz c2VzPgogICAgICAgICA8aXAtYWRkcmVzcz4KICAgICAgICAgICA8bmFtZT4xMDwvbmFtZT4KICAg ICAgICAgICA8aXAtYWRkcmVzcz4xMjguMTA3LjAsMDwvaXAtYWRkcmVzcz4KICAgICAgICAgICA8 aXAtbWFzaz4yNTUuMjU1LjAuMDwvaXAtbWFzaz4KICAgICAgICAgPC9pcC1hZGRyZXNzPgogICAg ICAgICA8aXAtYWRkcmVzcz4KICAgICAgICAgICA8bmFtZT4yMDwvbmFtZT4KICAgICAgICAgICA8 aXAtYWRkcmVzcz4xMzkuMjA3LjAuMDwvaXAtYWRkcmVzcz4KICAgICAgICAgICA8aXAtbWFzaz4y NTUuMjU1LjAuMDwvaXAtbWFzaz4KICAgICAgICAgPC9pcC1hZGRyZXNzPgogICAgICAgPC9pcC1h ZGRyZXNzZXM+CiAgICAgPC9pcC1hZGRyZXNzLWdyb3VwPgogICA8L2lwLWFkZHJlc3MtZ3JvdXBz PgoKICAgPGlwLWFjZT4KICAgICA8bmFtZT4xMDA8L25hbWU+CiAgICAgPGFmaT5pcHY0PC9hZmk+ CiAgICAgPGFjdGlvbnM+cGVybWl0PC9hY3Rpb25zPgogICAgIDxmaWx0ZXJzPgogICAgICAgPGlw LXNvdXJjZS1ncm91cD5FbWFpbC1TZXJ2ZXItSVBWNDwvaXAtc291cmNlLWdyb3VwPgogICAgICAg PGlwLWRlc3QtYW55Lz4KICAgICA8L2ZpbHRlcnM+CiAgIDwvaXAtYWNlPgoKNS4gIGFjbC1pcCBt b2R1bGUKCiAgIGFjbC1pcCBpcyB0aGUgbW9kdWxlIHRoYXQgZGVmaW5lcyBJUC1BQ0wuICBJdCBh dWdtZW50cyBhY2wgbGlzdCBpbgogICBhY2wgbW9kdWxlLgoKNS4xLiAgR3JvdXBpbmdzCgoKCgoK CgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAg ICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmct YWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgo1LjEuMS4gIElQLVNPVVJDRS1O RVRXT1JLIGdyb3VwaW5nCgogICAgIElQLVNPVVJDRS1ORVRXT1JLCiAgICAgICAgKy0tcncgKHNv dXJjZS1hZGRyZXNzLWhvc3QtZ3JvdXApPwogICAgICAgICAgKy0tOihzb3VyY2UtaXApCiAgICAg ICAgICAgfCAgKy0tcncgaXAtc291cmNlLWFkZHJlc3MgICAgICAgaW5ldDppcC1hZGRyZXNzCiAg ICAgICAgICAgfCAgKy0tcncgaXAtc291cmNlLW1hc2sgICAgICAgaW5ldDppcC1hZGRyZXNzCiAg ICAgICAgICArLS06KGlwLXNvdXJjZS1hbnkpCiAgICAgICAgICAgfCAgKy0tcncgaXAtc291cmNl LWFueSAgICBlbXB0eQogICAgICAgICAgKy0tOihzb3VyY2UtaG9zdCkKICAgICAgICAgICB8ICAr LS06KGlwLXNyYy1ob3N0LWFkZHJlc3Mtb3ItbmFtZSkKICAgICAgICAgICB8ICAgICAgICstLToo aXAtc291cmNlLWhvc3QtYWRkcmVzcykKICAgICAgICAgICB8ICAgICAgICAgICAgKy0tcncgaXAt c291cmNlLWhvc3QtYWRkcmVzcyAgICAgaW5ldDppcC1hZGRyZXNzCiAgICAgICAgICAgfCAgICAg ICArLS06KGlwLXNvdXJjZS1ob3N0LW5hbWUpCiAgICAgICAgICAgfCAgICAgICAgICAgICstLXJ3 IGlwLXNvdXJjZS1ob3N0LW5hbWUgICAgIGluZXQ6ZG9tYWluLW5hbWUKICAgICAgICAgICstLToo c291cmNlLWdyb3VwKQogICAgICAgICAgICAgKy0tcncgaXAtc291cmNlLWdyb3VwPyAgICAgIGlw LWFkZHJlc3MtZ3JvdXAtcmVmCgogICBJUC1TT1VSQ0UtTkVUV09SSyBpcyBhIHJldXNhYmxlIGdy b3VwaW5nLiAgSXQgYWxsb3dzIGZpdmUgd2F5cyB0bwogICBzcGVjaWZ5IGEgbmV0d29yazogaXAg d2l0aCBtYXNrLCBhbnkgbmV0d29yaywgaG9zdC1uYW1lIG9yIGhvc3QKICAgYWRkcmVzcywgcmVm ZXJlbmNlIHRvIGEgcHJlZGVmaW5lZCBpcCBhZGRyZXNzIGdyb3VwLiAgSGVyZSBhcmUgdmFsaWQK ICAgZXhhbXBsZSBpbnN0YW5jZXM6CgogICBvICBpcCB3aXRoIG1hc2s6CgoKICAgICAgIDxpcC1z b3VyY2UtYWRkcmVzcz4xOTIuMTY4LjEuMDwvaXAtc291cmNlLWFkZHJlc3M+CiAgICAgICA8aXAt c291cmNlLW1hc2s+MjU1LjI1NS4yNTUuMDwvaXAtc291cmNlLW1hc2s+CgogICBvICBhbnkgbmV0 d29yazoKCgogICAgICAgPGlwLXNvdXJjZS1hbnkvPgoKICAgbyAgaG9zdC1uYW1lOgoKCiAgICAg ICA8aXAtc291cmNlLWhvc3QtbmFtZT5zd2l0Y2gxPC9pcC1zb3VyY2UtaG9zdC1uYW1lPgoKICAg byAgaG9zdC1hZGRyZXNzOgoKCiAgICAgICA8aXAtc291cmNlLWhvc3QtYWRkcmVzcz4xOTIuMTY4 LjEuMjwvaXAtc291cmNlLWhvc3QtYWRkcmVzcz4KCiAgIG8gIHJlZmVyZW5jZSB0byBhIHByZWRl ZmluZWQgaXAgYWRkcmVzcyBncm91cCAoRW1haWwtU2VydmVyLUlQVjQgaXMKICAgICAgZGVmaW5l ZCBpbiBTZWN0aW9uIDQuNC40ICk6CgoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAy MDEzCgoKICAgICAgIDxpcC1zb3VyY2UtZ3JvdXA+RW1haWwtU2VydmVyLUlQVjQ8L2lwLXNvdXJj ZS1ncm91cD4KCjUuMS4yLiAgSVAtREVTVElOQVRJT04tTkVUV09SSyBncm91cGluZwoKICAgICAg IElQLURFU1RJTkFUSU9OLU5FVFdPUksKICAgICAgICAgICstLXJ3IChkZXN0LWFkZHJlc3MtaG9z dC1ncm91cCk/CiAgICAgICAgICAgICstLTooZGVzdC1pcCkKICAgICAgICAgICAgIHwgICstLXJ3 IGlwLWRlc3QtYWRkcmVzcyAgICAgICBpbmV0OmlwLWFkZHJlc3MKICAgICAgICAgICAgIHwgICst LXJ3IGlwLWRlc3QtbWFzaz8gICAgICAgaW5ldDppcC1hZGRyZXNzCiAgICAgICAgICAgICArLS06 KGlwLWRlc3QtYW55KQogICAgICAgICAgICAgfCAgKy0tcncgaXAtZGVzdC1hbnkgICAgZW1wdHkK ICAgICAgICAgICAgICstLTooZGVzdC1ob3N0KQogICAgICAgICAgICAgfCAgKy0tOihpcC1kZXN0 LWhvc3QtYWRkcmVzcy1vci1uYW1lKQogICAgICAgICAgICAgfCAgICAgICArLS06KGlwLWRlc3Qt aG9zdC1hZGRyZXNzKQogICAgICAgICAgICAgfCAgICAgICAgICAgICstLXJ3IGlwLWRlc3QtaG9z dC1hZGRyZXNzICAgICBpbmV0OmlwLWFkZHJlc3MKICAgICAgICAgICAgIHwgICAgICAgKy0tOihp cC1kZXN0LWhvc3QtbmFtZSkKICAgICAgICAgICAgIHwgICAgICAgICAgICArLS1ydyBpcC1kZXN0 LWhvc3QtbmFtZSAgICAgaW5ldDpkb21haW4tbmFtZQogICAgICAgICAgICArLS06KGdyb3VwKQog ICAgICAgICAgICAgICArLS1ydyBpcC1kZXN0LWdyb3VwPyAgICAgIGlwLWFkZHJlc3MtZ3JvdXAt cmVmCgogICBJUC1ERVNUSU5BVElPTi1BRERSRVNTIGlzIGEgcmV1c2FibGUgZ3JvdXBpbmcuICBJ dHMgc3RydWN0dXJlIGlzCiAgIHNpbWlsYXIgdG8gSVAtU09VUkNFLU5FVFdPUksuICBUaGUgcmVh c29uIHRvIGhhdmUgYm90aCBJUC1TT1VSQ0UtCiAgIE5FVFdPUksgYW5kIElQLURFU1RJTkFUSU9O LU5FVFdPUksgZ3JvdXBpbmdzIGlzIHRvIGFsbG93ICJpcC1zb3VyY2UtCiAgIGFkZHJlc3MiIGFu ZCAiaXAtZGVzdGluYXRpb24tYWRkcmVzcyIgbGVhdmVzIHRvIGFwcGVhciBpbiB0aGUgc2FtZQog ICBjb250YWluZXIuICBGb3IgZXhhbXBsZToKCiAgICAgICA8ZmlsdGVycz4KICAgICAgICAgPGlw LXNvdXJjZS1hZGRyZXNzPjE5Mi4xNjguMS4wPC9pcC1zb3VyY2UtYWRkcmVzcz4KICAgICAgICAg PGlwLXNvdXJjZS1tYXNrPjI1NS4yNTUuMjU1LjA8L2lwLXNvdXJjZS1tYXNrPgogICAgICAgICA8 aXAtZGVzdC1hZGRyZXNzPmFueTwvaXAtZGVzdC1hZGRyZXNzPgogICAgICAgPC9maWx0ZXJzPgoK NS4xLjMuICBEU0NQLU9SLVRPUyBHcm91cGluZwoKICAgRFNDUC1PUi1UT1MgZ3JvdXBpbmcgZGVm aW5lcyBhIGNob2ljZSwgImRzY3Atb3ItdG9zIi4gIEl0IGFsbG93cyB0d28KICAgd2F5cyB0byBm aWx0ZXIgZm9yIGEgUW9TIHBhY2tldDoKCiAgIG8gIGRzY3A6IE1hdGNoIHBhY2tldCBvbiBEU0NQ IHZhbHVlLgoKICAgbyAgdG9zOiBNYXRjaCBwYWNrZXQgb24gVE9TIGFuZCBwcmVjZWRlbmNlIHZh bHVlLgoKICAgVGhlIHR5cGVkZWYgZm9yICJ0b3MiIGFuZCAicHJlY2VkZW5jZSIgaXMgZGVmaW5l ZCBpbiBtb2R1bGUgImNvbW1vbi0KICAgdHlwZXMiLCB3aGljaCBjb3VsZCBiZSBkZXByZWNhdGVk IHNob3VsZCBJRVRGIGRlZmluZSBhIHNlcGFyYXRlIHNldAogICBvZiBkZWZpbml0aW9ucy4KCgoK CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAg ICAgICAgICAgIFtQYWdlIDE3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFu Zy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCjUuMS40LiAgSVAtQUNFLUZJ TFRFUlMgR3JvdXBpbmcKCgogICAgICAgSVAtQUNFLUZJTFRFUlMKICAgICAgICAgKy0tcncgcHJv dG9jb2w/ICAgICAgICAgICAgICAgICAgIGMtdHlwZXM6aXAtcHJvdG9jb2wKICAgICAgICAgKy0t YWNsOkZJTFRFUi1DT01NT04KICAgICAgICAgKy0tcncgZnJhZ21lbnRzPyAgICAgICAgICAgICAg ICAgIGVtcHR5CiAgICAgICAgICstLXJ3IHRpbWUtcmFuZ2U/ICAgICAgICAgICAgICAgICBhY2w6 VGltZS1SYW5nZS1SZWYKICAgICAgICAgKy0tIChzcmMtcG9ydHMpPwogICAgICAgICAgfCAgKy0t cncgKHBvcnQtbnVtYmVyLW9yLXJhbmdlKT8KICAgICAgICAgIHwgIHwgICAgICstLToocG9ydC1u dW1iZXItcmFuZ2UpCiAgICAgICAgICB8ICB8ICAgICB8ICArLS1ydyBzcmMtcG9ydC1sb3dlcj8g ICAgICAgIGluZXQ6cG9ydC1udW1iZXIKICAgICAgICAgIHwgIHwgICAgIHwgICstLXJ3IHNyYy1w b3J0LXVwcGVyPyAgICAgICAgaW5ldDpwb3J0LW51bWJlcgogICAgICAgICAgfCAgKy0tOihwb3J0 LW51bWJlcikKICAgICAgICAgIHwgIHwgICAgICAgICstLXJ3IHNyYy1jb21wYXJhdG9yICAgICAg ICAgY29tcGFyYXRvcgogICAgICAgICAgfCAgfCAgICAgICAgKy0tcncgc3JjLXBvcnQ/ICAgICAg ICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCiAgICAgICAgICB8ICstLSA6KHBvcnQtZ3JvdXAtcmVm KQogICAgICAgICAgfCAgICArLS1zcmMtcG9ydC1ncm91cC1uYW1lCiAgICAgICAgICstLSAoZGVz LXBvcnRzKT8KICAgICAgICAgIHwgKy0tcncgKHBvcnQtbnVtYmVyLW9yLXJhbmdlKT8KICAgICAg ICAgIHwgIHwgICAgICstLToocG9ydC1udW1iZXItcmFuZ2UpCiAgICAgICAgICB8ICB8ICAgICB8 ICArLS1ydyBkZXMtcG9ydC1sb3dlcj8gICAgICAgIGluZXQ6cG9ydC1udW1iZXIKICAgICAgICAg IHwgIHwgICAgIHwgICstLXJ3IGRlcy1wb3J0LXVwcGVyPyAgICAgICAgaW5ldDpwb3J0LW51bWJl cgogICAgICAgICAgfCAgKy0tOihwb3J0LW51bWJlcikKICAgICAgICAgIHwgIHwgICAgICAgICst LXJ3IGRlcy1jb21wYXJhdG9yICAgICAgICAgY29tcGFyYXRvcgogICAgICAgICAgfCAgfCAgICAg ICAgKy0tcncgZGVzLXBvcnQ/ICAgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCiAgICAgICAg ICB8ICstLSA6KGJ5LW5hbWUpCiAgICAgICAgICB8ICAgICstLSBkZXMtcG9ydC1ncm91cC1uYW1l CiAgICAgICAgICstLXJ3IGljbXAtdHlwZT8gICAgICAgICAgICAgYy10eXBlczppY21wLXR5cGUK ICAgICAgICAgKy0tcncgaWNtcC1jb2RlPyAgICAgICAgICAgICBjLXR5cGVzOmljbXAtdHlwZQog ICAgICAgICArLS1ydyAocGFja2V0LWxlbmd0aC1vci1yYW5nZSk/CiAgICAgICAgICB8ICArLS06 KGxlbmd0aCkKICAgICAgICAgIHwgIHwgICstLXJ3IHBhY2tldC1sZW5ndGgtY29tcGFyYXRvciAg ICBhY2w6Q29tcGFyYXRvcgogICAgICAgICAgfCAgfCAgKy0tcncgcGFja2V0LWxlbmd0aCAgICAg ICAgICAgICAgIHVpbnQzMgogICAgICAgICAgfCAgKy0tOihyYW5nZSkKICAgICAgICAgIHwgICAg ICstLXJ3IHBhY2tldC1sZW5ndGgtdXBwZXIgICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAg ICstLXJ3IHBhY2tldC1sZW5ndGgtbG93ZXIgICAgICAgICB1aW50MzIKICAgICAgICAgKy0tcncg dGNwLWZsYWctdmFsdWU/ICAgICAgICAgICAgIGMtdHlwZXM6dGNwLWZsYWctdHlwZQogICAgICAg ICArLS1ydyB0Y3AtZmxhZy1tYXNrPyAgICAgICAgICAgICAgYy10eXBlczp0Y3AtZmxhZy10eXBl CiAgICAgICAgICstLXJ3IHRjcC1mbGFnLW9wZXJhdGlvbj8gICAgICAgICBlbnVtZXJhdGlvbgog ICAgICAgICArLS1ydyAodHRsLXZhbHVlLW9yLXJhbmdlKT8KICAgICAgICAgICAgKy0tOih2YWx1 ZSkKICAgICAgICAgICAgIHwgICstLXJ3IHR0bC1jb21wYXJhdG9yPyAgICAgICAgICAgICBhY2w6 YWNsLWNvbXBhcmF0b3IKICAgICAgICAgICAgIHwgICstLXJ3IHR0bC12YWx1ZT8gICAgICAgICAg ICAgICAgICBjLXR5cGVzOlRpbWUtdG8tTGl2ZQogICAgICAgICAgICArLS06KHJhbmdlKQogICAg ICAgICAgICAgICAgKy0tcncgdHRsLXZhbHVlLWxvd2VyPyAgICAgICAgICAgIGMtdHlwZXM6VGlt ZS10by1MaXZlCiAgICAgICAgICAgICAgICArLS1ydyA6dHRsLXZhbHVlLS11cHBlcj8gICAgICAg ICAgIGMtdHlwZXM6VGltZS10by1MaXZlCgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTMKCgogICBJUC1BQ0UtRklMVEVSUyBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgbGVhdmVzIHRo YXQgYXJlIHVzZWQgYnkgYm90aCBieQogICBJUHY0IGFuZCBJUHY2IEFDRXM6CgogICBvICBwcm90 b2NvbAoKICAgbyAgYWNsOkZJTFRFUi1DT01NT046IHNlZSBTZWN0aW9uIDQuMwoKICAgbyAgZnJh Z21lbnRzOiBXaGVuIHByZXNlbnQsIGl0IG1hdGNoZXMgdGhlIG5vbi1pbml0aWFsIGZyYWdtZW50 LgoKICAgbyAgdGltZS1yYW5nZTogRW5hYmxlIHBhY2tldCBjYXB0dXJlIG9uIHRoaXMgZmlsdGVy IGZvciBhIHRpbWVyYW5nZS0KICAgICAgZ3JvdXAgYnkgbmFtZS4gdGltZS1yYW5nZSBpcyBUaW1l LVJhbmdlLVJlZiB0eXBlIHdoaWNoIGlzIGEKICAgICAgbGVhZnJlZi4KCiAgIG8gIHNyYy1wb3J0 cyBjaG9pY2U6IEFsbG93cyB0aGUgZm9sbG93aW5nIHRocmVlIHdheXMgdG8gZGVmaW5lIGEKICAg ICAgZ3JvdXAgb2YgcG9ydHMuCgogICAgICAqICBwb3J0LW51bWJlci1yYW5nZTogVXNlICJzcmMt cG9ydC1sb3dlciIgYW5kICJzcmMtcG9ydC11cHBlciIKICAgICAgICAgbGVhdmVzIHRvIHNwZWNp ZnkgYSBwb3J0IHJhbmdlLiAgVGhlIHZhbHVlIG9mICJzcmMtcG9ydC1sb3dlciIKICAgICAgICAg aGFzIHRvIGJlIGxlc3MgdGhhbiBvciBlcXVhbCB0aGUgdmFsdWUgb2YgInNyYy1wb3J0LXVwcGVy Ii4KCiAgICAgICogIHBvcnQtbnVtYmVyOiBVc2UgImNvbXBhcmF0b3IiIGFuZCAic3JjLXBvcnQi IGxlYXZlcyB0byBzcGVjaWZ5CiAgICAgICAgIGEgcG9ydCByYW5nZS4gIFNlZSBDb21wYXJhdG9y IHR5cGVkZWYgaW4gdGhlIG1vZGVsIGZvciB0aGUKICAgICAgICAgcG9zc2libGUgdmFsdWVzIHRo ZSAiY29tcGFyYXRvciIgbGVhZi4KCiAgICAgICogIHBvcnQgcmFuZ2UgcmVmOiBSZWZlciB0byBh IG5hbWVkIHBvcnQgZ3JvdXAgdGhhdCBpcyBkZWZpbmVkCiAgICAgICAgIHVzaW5nIHBvcnQtZ3Jv dXBzLiAgRm9yIGV4YW1wbGU6CgoKICAgICAgICAgICA8cG9ydC1ncm91cC1uYW1lPnBvcnQtdHVu bmVsMTwvcG9ydC1ncm91cC1uYW1lPgoKICAgbyAgZGVzdC1wb3J0cyBjaG9pY2U6IEFuYWxvZ291 cyB0byAic3JjLXBvcnRzIi4KCiAgIG8gIHBhY2tldC1sZW5ndGgtb3ItcmFuZ2U6IEFsbG93cyB0 d28gd2F5cyB0byBzcGVjaWZ5IHBhY2tldCBsZW5ndGgKICAgICAgcmFuZ2UuCgogICAgICAqICBj YXNlIGxlbmd0aDogVXNlIGNvbXBhcmF0b3IgYW5kIGEgc2luZ2xlIHBhY2tldC1sZW5ndGggdG8K ICAgICAgICAgc3BlY2lmeSB0aGUgcmFuZ2UuCgogICAgICAqICBjYXNlIHJhbmdlOiBVc2UgcGFj a2V0LWxlbmd0aC1sb3dlciBhbmQgcGFja2V0LWxlbmd0aC11cHBlciB0bwogICAgICAgICBzcGVj aWZ5IGEgcmFuZ2UuICBUaGUgdmFsdWUgb2YgcGFja2V0LWxlbmd0aC1sb3dlciBtdXN0IGJlCiAg ICAgICAgIGxvd2VyIHRoYW4gb3IgZXF1YWwgdG8gdGhlIHZhbHVlIG9mIHBhY2tldC1sZW5ndGgt dXBwZXIuCgogICBvICBpY21wLXR5cGUKCiAgIG8gIGljbXAtY29kZQoKICAgbyAgcGFja2V0LWxl bmd0aC1vci1yYW5nZSBjaG9pY2UKCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAx MwoKCiAgIG8gIHRjcC1mbGFnLXZhbHVlOiB0Y3AtZmxhZy12YWx1ZSwgdGNwLWZsYWctbWFzayBh bmQgdGNwLWZsYWctCiAgICAgIG9wZXJhdGlvbiBhbGxvdyB0byBtYXRjaCBhbnkgY29tYmluYXRp b24gb2YgcGFja2V0IHRjcCBmbGFnCiAgICAgIHZhbHVlcy4KCgogICBUaGUgZm9sbG93aW5nIGV4 YW1wbGUgaXMgdG8gbWF0Y2ggdGhlIHBhY2tldAogICB0Y3AgZmxhZyBhY2s9MSwgc3luPTEsIGFu ZCBmaW49MDsKCiAgICAgPHRjcC1mbGFnLXZhbHVlPiBhY2sgc3luIDx0Y3AtZmxhZy12YWx1ZT4K ICAgICA8dGNwLWZsYWctbWFzaz5hY2sgc3luIGZpbjwvdGNwLWZsYWctbWFzaz4KICAgICA8dGNw LWZsYWctb3BlcmF0aW9uPm1hdGNoLWFsbDwvdGNwLWZsYWctb3BlcmF0aW9uPgoKICAgbyAgdGNw LWZsYWctbWFzawoKICAgbyAgdGNwLWZsYWctb3BlcmF0aW9uCgogICBvICB0dGwtdmFsdWUtb3It cmFuZ2UKCjUuMi4gIGF1Z21lbnQKCiAgIFRoZSBtb2R1bGUgImFjbC1pcCIgYXVnbWVudHMgdGhl IGRlZmluaXRpb24gb2YgZGF0YSBub2RlICIvYWNsOmFjbHMvCiAgIGFjbDphY2wiIHdpdGggYWRk aXRpb25hbCBsZWF2ZXMgYW5kIHN1YmNvbXBvbmVudHMuCgogICBvICBhZmkKCiAgIG8gIGlwdjYt YWNlczogSXQgY29udGFpbnMgYSBsaXN0IG9mIGlwdjYtYWNlLiAgRWFjaCBpcHY2LWFjZSBpcwog ICAgICBlaXRoZXIgYSByZW1hcmsgb3IgYSByZWFsIGFjY2VzcyBjb250cm9sIGZpbHRlcnMuICBU aGUgY2FzZSBpcHY2LQogICAgICBhY2UgZGVmaW5lcyB0aGUgZmlsdGVycyBhbmQgYWN0aW9ucyBm b3IgaXB2Ni1hY2UuICBUaGUgYWNlIHVzZXMKICAgICAgZmlsdGVycyBkZWZpbmVkIGluIGdyb3Vw aW5nIElQLVNPVVJDRS1ORVRXT1JLLCBJUC1ERVNUSU5BVElPTi0KICAgICAgTkVUV09SSywgSVAt QUNFLUZJTFRFUlMsIERTQ1AtT1ItVE9TLiAgSW4gYWRkaXRpb24sIGl0IGFsc28gYWxsb3dzCiAg ICAgIGZpbHRlciBvbiBpZ21wLXR5cGUgYW5kIGZsb3ctbGFiZWwsCgogICBvICBpcHY0LWFjZXM6 IGlwdjQtYWNlIGhhcyBzaW1pbGFyIHN0cnVjdHVyZSB0byBpcHY2LWFjZXMuCgogICBvICBnbG9i YWwtZnJhZ21lbnRzCgo1LjIuMS4gIGdsb2JhbC1mcmFnbWVudHMgbGVhZgoKICAgZ2xvYmFsLWZy YWdtZW50cyBpcyBhbiBvcHRpb25hbCBsZWFmLiAgSXQgaGFzIGFuIGVudW1lcmF0aW9uIHZhbHVl IG9mCiAgIG5vdC1zZXQsIHBlcm1pdC1hbGwsIGRlbnktYWxsLiBub3Qtc2V0IGlzIHRoZSBkZWZh dWx0IHZhbHVlLiAgV2hlbgogICB0aGUgZ2xvYmFsLWZyYWdtZW50cyBpcyBwZXJtaXQtYWxsIG9y IGRlbnktYWxsLCBpdCBpcyB0byBwZXJtaXQgb3IKICAgZGVueSB0aGUgaW1wbGljaXQgYWNlIGZy YWdtZW50IGZpbHRlci4gIEhlcmUgaXMgYW4gZXhhbXBsZSBvZgogICBpbXBsaWNpdCBhY2UgYW5k IGhvdyB0aGUgaW1wbGljaXQgYWNlIGlzIGFmZmVjdGVkIHdoZW4gZ2xvYmFsLQogICBmcmFnbWVu dHMgaXMgc2V0LgoKICAgRXhhbXBsZSAxOiBUaGUgYWNsIGNvbmZpZ3VyYXRpb24gZnJvbSB0aGUg bWFuYWdlbWVudCBpbnRlcmZhY2Ugd2l0aAogICBnbG9iYWwtZnJhZ21lbnRzIGlzIGFic2VudC4K CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAg ICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFu Zy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgICBZQU5HIGlu c3RhbmNlIG9mIHRoaXMgY2xpIGNvbmZpZ3VyYXRpb246CiAgICAgICAgICA8YWNscz4KICAgICAg ICAgICAgPGFjbD4KICAgICAgICAgICAgICA8bmFtZT5mcmFnbWVudF90ZXN0MTwvbmFtZT4KICAg ICAgICAgICAgICA8YWZpPmlwdjQ8L2FmaT4KICAgICAgICAgICAgICA8YWNsLXR5cGU+aXAtYWNs PC9hY2wtdHlwZT4KICAgICAgICAgICAgICA8aXAtYWNlcz4KICAgICAgICAgICAgICAgICAgPG5h bWU+MTA8L25hbWU+CiAgICAgICAgICAgICAgICAgIDxhY3Rpb25zPgogICAgICAgICAgICAgICAg ICAgICAgPGFjdGlvbj5wZXJtaXQ8L2FjdGlvbj4KICAgICAgICAgICAgICAgICAgPC9hY3Rpb25z PgogICAgICAgICAgICAgICAgICA8ZmlsdGVycz4KICAgICAgICAgICAgICAgICAgICAgIDxpcC1z b3VyY2UtYWRkcmVzcz4xOTIuMTY4LjUuMDwvaXAtc291cmNlLWFkZHJlc3M+CiAgICAgICAgICAg ICAgICAgICAgICA8aXAtc291cmNlLW1hc2s+MjU1LjI1NS4yNTUuMDwvaXAtc291cmNlLW1hc2s+ CiAgICAgICAgICAgICAgICAgICAgICA8aXAtZGVzdC1hZGRyZXNzPmFueTwvaXAtZGVzdC1hZGRy ZXNzPgogICAgICAgICAgICAgICAgICA8L2ZpbHRlcnM+CiAgICAgICAgICAgICAgPC9pcC1hY2Vz PgogICAgICAgICAgICAgIDxpcC1hY2VzPgogICAgICAgICAgICAgICAgICA8bmFtZT4yMDwvbmFt ZT4KICAgICAgICAgICAgICAgICAgPGFjdGlvbnM+CiAgICAgICAgICAgICAgICAgICAgICA8YWN0 aW9uPnBlcm1pdDwvYWN0aW9uPgogICAgICAgICAgICAgICAgICA8L2FjdGlvbnM+CiAgICAgICAg ICAgICAgICAgIDxmaWx0ZXJzPgogICAgICAgICAgICAgICAgICAgICAgPGlwLXNvdXJjZS1hZGRy ZXNzPjE4OS4xNjguMC4wPC9pcC1zb3VyY2UtYWRkcmVzcz4KICAgICAgICAgICAgICAgICAgICAg IDxpcC1zb3VyY2UtbWFzaz4yNTUuMjU1LjAuMDwvaXAtc291cmNlLW1hc2s+CiAgICAgICAgICAg ICAgICAgICAgICA8aXAtZGVzdC1hZGRyZXNzPmFueTwvaXAtZGVzdC1hZGRyZXNzPgogICAgICAg ICAgICAgICAgICAgICAgIDxmcmFnbWVudHMvPgogICAgICAgICAgICAgICAgICA8L2ZpbHRlcnM+ CiAgICAgICAgICAgICAgPC9pcC1hY2VzPgogICAgICAgICAgICA8L2FjbD4KICAgICAgICAgIDwv YWNscz4KCiAgIEJ5IHRha2luZyBhbGwgdGhlIHRhZ3Mgb3V0LCB0aGUgYWJvdmUgeWFuZyBjYW4g YmUgZXhwcmVzcyBpbiBhCiAgIHN1bW1hcnkgb2YgY2xpIGZvcm1hdCBsaWtlIHRoZSBmb2xsb3dp bmc6CgoKICAgICAgICAgICBmcmFnbWVudF90ZXN0MSBpcC1hY2wgaXB2NAogICAgICAgICAgIDEw IHBlcm1pdCBpcCAxOTIuMTY4LjUuMCAyNTUuMjU1LjI1NS4wIGFueQogICAgICAgICAgIDIwIHBl cm1pdCBpcCAxODkuMTY4LjAuMCAyNTUuMjU1LjAuMCBhbnkgZnJhZ21lbnQuCgoKICAgVGhlIGFj bCBjb25maWd1cmF0aW9uIHRvZ2V0aGVyIHdpdGggaW1wbGljaXQgYWNlIGluIHRoZSBkZXZpY2Ug d2lsbAogICBiZToKCgoKCgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgog ICAgICAgICAgIGZyYWdtZW50X3Rlc3QxIGlwLWFjbCBpcHY0CiAgICAgICAgICAgMTAgcGVybWl0 IGlwIDE5Mi4xNjguNS4wIDI1NS4yNTUuMjU1LjAgYW55CiAgICAgICAgICAgMTEgcGVybWl0IGlw IDE5Mi4xNjguNS4wIDI1NS4yNTUuMjU1LjAgYW55IGZyYWdtZW50CiAgICAgICAgICAgMjAgcGVy bWl0IGlwMTg5LjE2OC4wLjAgMjU1LjI1NS4wLjAgYW55IGZyYWdtZW50LgogICAgICAgICAgIDEw MCBkZW55IGFueSBhbnkKICAgICAgICAgICAxMTAgZGVueSBhbnkgYW55IGZyYWdtZW50CgogICBO b3RpY2UgdGhyZWUgbGluZXMgb2YgY29uZmlndXJhdGlvbi4gMTEsIDEwMCBhbmQgMTEwLCBhcmUg aW1wbGljaXQuCgogICBFeGFtcGxlIDI6IFRoZSBhY2wgY29uZmlndXJhdGlvbiBmcm9tIHRoZSBt YW5hZ2VtZW50IGludGVyZmFjZSB3aXRoCiAgIGdsb2JhbC1mcmFnbWVudHMKCgogICAgICAgICAg PGFjbHM+CiAgICAgICAgICAgIDxhY2w+CiAgICAgICAgICAgICAgPG5hbWU+ZnJhZ21lbnRfdGVz dDI8L25hbWU+CiAgICAgICAgICAgICAgPGFjbC10eXBlPmlwLWFjbDwvYWNsLXR5cGU+CiAgICAg ICAgICAgICAgPGdsb2JhbC1mcmFnbWVudHM+ZGVueS1hbGw8L2dsb2JhbC1mcmFnbWVudHM+CiAg ICAgICAgICAgICAgPGFmaT5pcHY0PC9hZmk+CiAgICAgICAgICAgICAgPGlwLWFjZXM+CiAgICAg ICAgICAgICAgICAgIDxuYW1lPjEwPC9uYW1lPgogICAgICAgICAgICAgICAgICA8YWN0aW9ucz4K ICAgICAgICAgICAgICAgICAgICAgIDxhY3Rpb24+cGVybWl0PC9hY3Rpb24+CiAgICAgICAgICAg ICAgICAgIDwvYWN0aW9ucz4KICAgICAgICAgICAgICAgICAgPGZpbHRlcnM+CiAgICAgICAgICAg ICAgICAgICAgICA8aXAtc291cmNlLWFkZHJlc3M+MTkyLjE2OC41LjA8L2lwLXNvdXJjZS1hZGRy ZXNzPgogICAgICAgICAgICAgICAgICAgICAgPGlwLXNvdXJjZS1tYXNrPjI1NS4yNTUuMjU1LjA8 L2lwLXNvdXJjZS1tYXNrPgogICAgICAgICAgICAgICAgICAgICAgPGlwLWRlc3QtYWRkcmVzcz5h bnk8L2lwLWRlc3QtYWRkcmVzcz4KICAgICAgICAgICAgICAgICAgPC9maWx0ZXJzPgogICAgICAg ICAgICAgIDwvaXAtYWNlcz4KICAgICAgICAgICAgICA8aXAtYWNlcz4KICAgICAgICAgICAgICAg ICAgPG5hbWU+MjA8L25hbWU+CiAgICAgICAgICAgICAgICAgIDxhY3Rpb25zPgogICAgICAgICAg ICAgICAgICAgICAgPGFjdGlvbj5wZXJtaXQ8L2FjdGlvbj4KICAgICAgICAgICAgICAgICAgPC9h Y3Rpb25zPgogICAgICAgICAgICAgICAgICA8ZmlsdGVycz4KICAgICAgICAgICAgICAgICAgICAg IDxpcC1zb3VyY2UtYWRkcmVzcz4xODkuMTY4LjAuMDwvaXAtc291cmNlLWFkZHJlc3M+CiAgICAg ICAgICAgICAgICAgICAgICA8aXAtc291cmNlLW1hc2s+MjU1LjI1NS4wLjA8L2lwLXNvdXJjZS1t YXNrPgogICAgICAgICAgICAgICAgICAgICAgPGlwLWRlc3QtYWRkcmVzcz5hbnk8L2lwLWRlc3Qt YWRkcmVzcz4KICAgICAgICAgICAgICAgICAgICAgICA8ZnJhZ21lbnRzLz4KICAgICAgICAgICAg ICAgICAgPC9maWx0ZXJzPgogICAgICAgICAgICAgIDwvaXAtYWNlcz4KICAgICAgICAgICAgPC9h Y2w+CiAgICAgICAgICA8L2FjbHM+CgogICBUaGUgYWNsIGNvbmZpZ3VyYXRpb24gaW4gdGhlIGRl dmljZSB3aXRoIGltcGxpY2l0IGFjZXMuICBUaGUgZGVueS1hbGwKICAgdm9pZCAiMTEgcGVybWl0 IGlwIDEuMS4xLjEvMTYgYW55IGZyYWdtZW50IiBhY2UgaW4gcHJldmlvdXMgZXhhbXBsZS4KCgoK Ckh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAg ICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1h Y2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgIEJ5IHRha2luZyBhbGwgdGhl IHRhZ3Mgb3V0LCB0aGUgYWJvdmUgeWFuZyBjYW4gYmUgZXhwcmVzcyBpbiBhCiAgIHN1bW1hcnkg b2YgY2xpIGZvcm1hdCBsaWtlIHRoZSBmb2xsb3dpbmc6CgoKICAgICAgICAgICBmcmFnbWVudF90 ZXN0MiBpcC1hY2wgaXB2NCBkZW55LWFsbAogICAgICAgICAgIDEwIHBlcm1pdCBpcCAxOTIuMTY4 LjUuMCAyNTUuMjU1LjI1NS4wIGFueQogICAgICAgICAgIDIwIHBlcm1pdCBpcCAxODkuMTY4LjAu MCAyNTUuMjU1LjAuMCBhbnkgZnJhZ21lbnQuCgogICBUaGUgYWNsIGNvbmZpZ3VyYXRpb24gdG9n ZXRoZXIgd2l0aCBpbXBsaWNpdCBhY2UgaW4gdGhlIGRldmljZSB3aWxsCiAgIGJlOgoKCiAgICAg ICAgICAgZnJhZ21lbnRfdGVzdDIgaXAtYWNsIGlwdjQKICAgICAgICAgICAxMCBwZXJtaXQgaXAg MTkyLjE2OC41LjAgMjU1LjI1NS4yNTUuMCBhbnkKICAgICAgICAgICAyMCBwZXJtaXQgaXAgMTg5 LjE2OC4wLjAgMjU1LjI1NS4wLjAgYW55IGZyYWdtZW50LgogICAgICAgICAgIDEwMCBkZW55IGFu eSBhbnkKICAgICAgICAgICAxMTAgZGVueSBhbnkgYW55IGZyYWdtZW50Cgo2LiAgYWNsLW1hYyBt b2R1bGUKCjYuMS4gIE1BQy1TT1VSQ0UtTkVUV09SSyBncm91cGluZwoKICAgICAgIE1BQy1TT1VS Q0UtTkVUV09SSwogICAgICAgICArLS1ydyAoc291cmNlLW5ldHdvcmspPwogICAgICAgICAgKy0t Oihzb3VyY2UtbWFjKQogICAgICAgICAgfCAgKy0tcncgc291cmNlLWFkZHJlc3MgICAgICAgICAg ICAgIHlhbmc6bWFjLWFkZHJlc3MKICAgICAgICAgIHwgICstLXJ3IHNvdXJjZS1hZGRyZXNzLW1h c2sgICAgICAgICB5YW5nOm1hYy1hZGRyZXNzCiAgICAgICAgICArLS06KHNvdXJjZS1hbnkpCiAg ICAgICAgICB8ICAgKy0tcncgc291cmNlLWFueSAgICAgICAgIGVtcHR5CiAgICAgICAgICArLS06 KHNvdXJjZS1ob3N0KQogICAgICAgICAgICAgKy0tcncgYWNsLW1hYzpzb3VyY2UtaG9zdC1uYW1l ICAgICAgICAgICAgICAgIGluZXQ6aG9zdAoKICAgTUFDLVNPVVJDRS1BRERSRVNTIGlzIGEgcmV1 c2FibGUgZ3JvdXBpbmcuICBJdCBhbGxvd3MgdG8gZXhwcmVzcyB0aGUKICAgdGhyZWUga2luZHMg bmV0d29yay4KCiAgIGFueSBuZXR3b3JrOiB1c2Ugc291cmNlLWFueSB0byBleHByZXNzIGFueSBu ZXR3b3JrLgoKICAgICAgIDxtYWMtc291cmNlLWtpbmQ+YW55PC9tYWMtc291cmNlLWtpbmQ+Cgog ICBzaW5nbGUgaG9zdCBuZXR3b3JrLgoKICAgICAgIDxzb3VyY2UtaG9zdC1uYW1lPm15LWhvc3Q8 L3NvdXJjZS1ob3N0LW5hbWU+CgogICBob3N0IGFkZHJlc3Mgd2l0aCBhIG1hc2suCgogICAgICAg PHNvdXJjZS1hZGRyZXNzPjAxODAuYzIwMC4wMDA8L3NvdXJjZS1hZGRyZXNzPgogICAgICAgPHNv dXJjZS1hZGRyZXNzLW1hc2s+MDAwMC4wMDAwLjAwMDA8L3NvdXJjZS1hZGRyZXNzLW1hc2s+CgoK CgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAg ICAgICAgICBbUGFnZSAyM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmct YWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgo2LjIuICBNQUMtREVTVElOQVRJ T04tTkVUV09SSyBncm91cGluZwoKICAgTUFDLURFU1RJTkFUSU9OLU5FVFdPUksKICAgICAgICAg Ky0tcncgKGRlc3QtbmV0d29yayk/CiAgICAgICAgICArLS06KGFkZHJlc3MpCiAgICAgICAgICB8 ICArLS1ydyBkZXN0LWFkZHJlc3MgICAgICAgICAgICAgIHlhbmc6bWFjLWFkZHJlc3MKICAgICAg ICAgIHwgICstLXJ3IGRlc3QtYWRkcmVzcy1tYXNrICAgICAgICAgeWFuZzptYWMtYWRkcmVzcwog ICAgICAgICAgKy0tOihkZXN0LWFueSkKICAgICAgICAgIHwgICArLS1ydyBkZXN0LWFueSAgICAg ICAgIGVtcHR5CiAgICAgICAgICArLS06KGhvc3QpCiAgICAgICAgICAgICArLS1ydyBhY2wtbWFj OmRlc3QtaG9zdC1uYW1lICAgICAgICAgICAgICAgIGluZXQ6aG9zdAoKCiAgIE1BQy1ERVNUSU5B VElPTi1BRERSRVNTIGlzIGEgcmV1c2FibGUgZ3JvdXBpbmcgc2ltaWxhciB0byBNQUMtU09VUkNF LQogICBBRERSRVNTLiAgVGhlIHJlYXNvbiB0byBoYXZlIGJvdGggTUFDLVNPVVJDRS1BRERSRVNT IGFuZCBNQUMtCiAgIERFU1RJTkFUSU9OLUFERFJFU1MgZ3JvdXBpbmcgaXMgdG8gYWxsb3cgc291 cmNlLWFkZHJlc3MgYW5kCiAgIGRlc3RpbmF0aW9uLWFkZHJlc3MgbGVhdmVzIGFwcGVhciBpbiB0 aGUgc2FtZSBjb250YWluZXIuICBGb3IKICAgZXhhbXBsZToKCiAgICAgICA8ZmlsdGVycz4KICAg ICAgICAgPHNvdXJjZS1hZGRyZXNzPjAxODAuYzIwMC4wMDA8L3NvdXJjZS1hZGRyZXNzPgogICAg ICAgICA8c291cmNlLWFkZHJlc3MtbWFzaz4wMDAwLjAwMDAuMDAwMDwvc291cmNlLWFkZHJlc3Mt bWFzaz4KICAgICAgICAgPGRlc3QtYW55Lz4KICAgICAgIDwvZmlsdGVycz4KCjYuMy4gIGF1Z21l bnQKCiAgIFRoZSBtb2R1bGUgImFjbC1tYWMiIGF1Z21lbnRzIHRoZSBkZWZpbml0aW9uIG9mIGRh dGEgbm9kZSAiL2FjbDphY2xzLwogICBhY2w6YWNsIiB3aXRoIGFkZGl0aW9uYWwgbGVhdmVzIGFu ZCBzdWJjb21wb25lbnRzLiBhY2wtbWFjIGhhcwogICBzaW1pbGFyIHN0cnVjdHVyZSBhcyBhY2wt aXB2NCBhbmQgYWNsLWlwdjYgZXhjZXB0IHRoZSBmaWx0ZXJzIGFyZQogICBkaWZmZXJlbnQuIG1h Yy1hY2UgaGFzIGZpbHRlcnMgZGVmaW5lZCBpbiBncm91cGluZyBNQUMtU09VQ0UtTkVUV09SSywK ICAgTUFDLURFU1RJTkFUSU9OLU5FVFdPUkssIGFjbDpGSUxURVItQ09NTU9OLCBldGhlcnR5cGUt bWFzaywgY29zLAogICB0aW1lLXJhbmdlLCBhbmQgdmxhbi4KCjcuICBhY2wtYXJwIG1vZHVsZQoK Ny4xLiAgYXVnbWVudAoKICAgVGhlIG1vZHVsZSAiYWNsLWFycCIgYXVnbWVudHMgdGhlIGRlZmlu aXRpb24gb2YgZGF0YSBub2RlICIvYWNsOmFjbHMvCiAgIGFjbDphY2wiIHdpdGggYWRkaXRpb25h bCBsZWF2ZXMgYW5kIHN1YmNvbXBvbmVudHMuCgoKCgoKCgoKCgoKSHVhbmcsIGV0IGFsLiAgICAg ICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMjRdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAg ICBGZWJydWFyeSAyMDEzCgoKICAgICAgIGF1Z21lbnQgIi9hY2w6YWNscy9hY2w6YWNsIgogICAg ICAgICstLXJ3IGFjbC1hcnA6YXJwLWFjZXMKICAgICAgICAgICArLS1ydyBhY2wtYXJwOmFycC1h Y2UgW25hbWVdCiAgICAgICAgICAgICAgICstLXJ3IGFjbC1hcnA6bmFtZSAgICAgICBhY2w6YWNs LW5hbWUtc3RyaW5nCiAgICAgICAgICAgICAgICstLXJ3IChyZW1hcmstb3ItYXJwLWFjZSk/CiAg ICAgICAgICAgICAgICAgICstLToocmVtYXJrKQogICAgICAgICAgICAgICAgICB8ICArLS1ydyBh Y2wtYXJwOnJlbWFyaz8gICAgYWNsOmFjbC1yZW1hcmsKICAgICAgICAgICAgICAgICAgKy0tOihh cnAtYWNlKQogICAgICAgICAgICAgICAgICAgICArLS1ydyBmaWx0ZXJzCiAgICAgICAgICAgICAg ICAgICAgIHwgICstLXJ3IGRpcmVjdGlvbj8gICAgICAgICAgICAgICAgZW51bWVyYXRpb24KICAg ICAgICAgICAgICAgICAgICAgfCAgKy0tYWNsLWlwOklQLVNPVVJDRS1ORVRXT1JLCiAgICAgICAg ICAgICAgICAgICAgIHwgICstLWFjbC1pcDpJUC1ERVNUSU5BVElPTi1ORVRXT1JLCiAgICAgICAg ICAgICAgICAgICAgIHwgICstLWFjbC1tYWM6TUFDLVNPVVJDRS1ORVRXT1JLCiAgICAgICAgICAg ICAgICAgICAgIHwgICstLWFjbC1tYWM6TUFDLURFU1RJTkFUSU9OLU5FVFdPUksKICAgICAgICAg ICAgICAgICAgICAgfCAgKy0tYWNsOkZJTFRFUi1DT01NT04KICAgICAgICAgICAgICAgICAgICAg K2FjbDpBQ0UtQ09NTU9OCgoKOC4gIERhdGEgTW9kZWwgU3RydWN0dXJlCgogICBUaGUgY29tYmlu ZWQgZGF0YSBtb2RlbCBmb3IgQUNMIGNvbmZpZ3VyYXRpb24gaXMgc3RydWN0dXJlZCBhcwogICBm b2xsb3dzLiAiYWNsIiBkZWZpbmVzIHRoZSBnZW5lcmljIGNvbXBvbmVudHMgb2YgYW4gYWNsIHN5 c3RlbS4KICAgImFjbC1pcCIsICJhY2wtbWFjIiwgImFjbC1hcnAiIGF1Z21lbnQgdGhlICJhY2wi IG1vZHVsZSB3aXRoCiAgIGFkZGl0aW9uYWwgZGF0YSBub2RlcyB0aGF0IGFyZSBuZWVkZWQgZm9y IGlwLCBtYWMsIGFuZCBhcnAgYWNsCiAgIHJlc3BlY3RpdmVseS4KCiBtb2R1bGU6IGFjbAogICAg Ky0tcncgYWNscwogICAgICAgKy0tcncgYWNsIFtuYW1lXQogICAgICAgfCAgKy0tcncgbmFtZQog ICAgICAgfCAgKy0tcncgYWNsLXR5cGUKICAgICAgIHwgICstLXJ3IGVuYWJsZS1jYXB0dXJlLWds b2JhbD8KICAgICAgIHwgICstLXJ3IGNhcHR1cmUtc2Vzc2lvbi1pZC1nbG9iYWw/CiAgICAgICB8 ICArLS1ydyAoZW5hYmxlLW1hdGNoLWNvdW50ZXItY2hvaWNlcyk/CiAgICAgICB8ICB8ICArLS06 KG1hdGNoKQogICAgICAgfCAgfCAgfCAgKy0tcncgZW5hYmxlLW1hdGNoLWNvdW50ZXI/CiAgICAg ICB8ICB8ICArLS06KHBlci1lbnRyeS1tYXRjaCkKICAgICAgIHwgIHwgICAgICstLXJ3IGVuYWJs ZS1wZXItZW50cnktbWF0Y2gtY291bnRlcj8KICAgICAgIHwgICstLXJvIG1hdGNoPwogICAgICAg fCAgKy0tcncgYWNsLWlwOmFmaT8KICAgICAgIHwgICstLXJ3IGFjbC1pcDppcHY2LWFjZXMKICAg ICAgIHwgIHwgICstLXJ3IGFjbC1pcDppcHY2LWFjZSBbbmFtZV0KICAgICAgIHwgIHwgICAgICst LXJ3IGFjbC1pcDpuYW1lICAgICAgIGFjbDphY2wtbmFtZS1zdHJpbmcKICAgICAgIHwgIHwgICAg ICstLXJ3IChyZW1hcmstb3ItaXB2Ni1jYXNlKT8KICAgICAgIHwgIHwgICAgICAgICstLToocmVt YXJrKQogICAgICAgfCAgfCAgICAgICAgfCAgKy0tcncgYWNsLWlwOnJlbWFyaz8gICAgYWNsOmFj bC1yZW1hcmsKICAgICAgIHwgIHwgICAgICAgICstLTooaXB2Ni1hY2UpCiAgICAgICB8ICB8ICAg ICAgICAgICArLS1ydyBhY2wtaXA6ZmlsdGVycwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1 YXJ5IDIwMTMKCgogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgKHNvdXJjZS1hZGRyZXNz LWhvc3QtZ3JvdXApCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KHNvdXJjZS1pcCkK ICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDppcC1zb3VyY2UtYWRk cmVzcwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOmlwLXNvdXJj ZS1tYXNrCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KGlwLXNvdXJjZS1hbnkpCiAg ICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6aXAtc291cmNlLWFueT8K ICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLTooc291cmNlLWhvc3QpCiAgICAgICB8ICB8 ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyAoaXAtc3JjLWFkZHJlc3Mtb3ItbmFtZSkKICAgICAg IHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgICstLTooaXAtc291cmNlLWhvc3QtYWRkcmVzcykK ICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgIHwgKy0tcncgYWNsLWlwOmlwLXNvdXJj ZS1ob3N0LWFkZHJlc3M/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAgICArLS06KGlw LXNvdXJjZS1ob3N0LW5hbWUpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAgICAgICAr LS1ydyBhY2wtaXA6aXAtc291cmNlLWhvc3QtbmFtZT8KICAgICAgIHwgIHwgICAgICAgICAgIHwg IHwgICstLTooc291cmNlLWdyb3VwKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgKy0t cncgYWNsLWlwOmlwLXNvdXJjZS1ncm91cD8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3 IChkZXN0LWFkZHJlc3MtaG9zdC1ncm91cCkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICst LTooZGVzdC1pcCkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDpp cC1kZXN0LWFkZHJlc3MKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1p cDppcC1kZXN0LW1hc2sKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLTooaXAtZGVzdC1h bnkpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6aXAtZGVzdC1h bnk/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KGRlc3QtaG9zdCkKICAgICAgIHwg IHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IChpcC1kZXN0LWFkZHJlc3Mtb3ItbmFtZSkKICAg ICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgICstLTooaXAtZGVzdC1ob3N0LWFkZHJlc3Mp CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAgICB8ICArLS1ydyBhY2wtaXA6aXAtZGVz dC1ob3N0LWFkZHJlc3M/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAgICArLS06KGlw LWRlc3QtaG9zdC1uYW1lKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgICAgICAgKy0t cncgYWNsLWlwOmlwLWRlc3QtaG9zdC1uYW1lPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAg Ky0tOihkZXN0LWdyb3VwKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgKy0tcncgYWNs LWlwOmlwLWRlc3QtZ3JvdXA/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6 cHJvdG9jb2w/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6ZW5hYmxlLWNh cHR1cmU/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6Y2FwdHVyZS1zZXNz aW9uLWlkPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlwOmZyYWdtZW50cz8K ICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDp0aW1lLXJhbmdlPwogICAgICAg fCAgfCAgICAgICAgICAgfCAgKy0tcncgKHNyYy1wb3J0cyk/CiAgICAgICB8ICB8ICAgICAgICAg ICB8ICB8ICArLS06KHBvcnQtbnVtYmVyLXJhbmdlKQogICAgICAgfCAgfCAgICAgICAgICAgfCAg fCAgfCAgKy0tcncgYWNsLWlwOnNyYy1wb3J0LWxvd2VyCiAgICAgICB8ICB8ICAgICAgICAgICB8 ICB8ICB8ICArLS1ydyBhY2wtaXA6c3JjLXBvcnQtdXBwZXIKICAgICAgIHwgIHwgICAgICAgICAg IHwgIHwgICstLToocG9ydC1udW1iZXIpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAr LS1ydyBhY2wtaXA6c3JjLWNvbXBhcmF0b3IKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwg ICstLXJ3IGFjbC1pcDpzcmMtcG9ydAogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihw b3J0LWdyb3VwLXJlZikKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICAgICstLXJ3IGFjbC1p cDpzcmMtcG9ydC1ncm91cC1uYW1lCiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyAoZGVz dC1wb3J0cyk/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KHBvcnQtbnVtYmVyLXJh bmdlKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOmRlcy1wb3J0 LWxvd2VyCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6ZGVzLXBv cnQtdXBwZXIKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLToocG9ydC1udW1iZXIpCiAg ICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6ZGVzLWNvbXBhcmF0b3IK CgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAg ICAgICAgICAgW1BhZ2UgMjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5n LWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgIHwgIHwgICAgICAg ICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDpkZXMtcG9ydAogICAgICAgfCAgfCAgICAgICAgICAg fCAgfCAgKy0tOihwb3J0LWdyb3VwLXJlZikKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICAg ICstLXJ3IGFjbC1pcDpkZXMtcG9ydC1ncm91cC1uYW1lCiAgICAgICB8ICB8ICAgICAgICAgICB8 ICArLS1ydyBhY2wtaXA6aWNtcC10eXBlPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncg YWNsLWlwOmljbXAtY29kZT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IChwYWNrZXQt bGVuZ3RoLW9yLXJhbmdlKT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLToobGVuZ3Ro KQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOnBhY2tldC1sZW5n dGgtY29tcGFyYXRvcgogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlw OnBhY2tldC1sZW5ndGgKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLToocmFuZ2UpCiAg ICAgICB8ICB8ICAgICAgICAgICB8ICB8ICAgICArLS1ydyBhY2wtaXA6cGFja2V0LWxlbmd0aC11 cHBlcgogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgKy0tcncgYWNsLWlwOnBhY2tldC1s ZW5ndGgtbG93ZXIKICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDp0Y3AtZmxh Zy12YWx1ZT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDp0Y3AtZmxhZy1t YXNrPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlwOnRjcC1mbGFnLW9wZXJh dGlvbj8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3ICh0dGwtdmFsdWUtb3ItcmFuZ2Up PwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOih2YWx1ZSkKICAgICAgIHwgIHwgICAg ICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDp0dGwtY29tcGFyYXRvcj8KICAgICAgIHwgIHwg ICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDp0dGwtdmFsdWU/CiAgICAgICB8ICB8ICAg ICAgICAgICB8ICB8ICArLS06KHJhbmdlKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAg Ky0tcncgYWNsLWlwOnR0bC12YWx1ZS1sb3dlcj8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwg ICAgICstLXJ3IGFjbC1pcDp0dGwtdmFsdWUtLXVwcGVyPwogICAgICAgfCAgfCAgICAgICAgICAg fCAgKy0tcncgKGRzY3Atb3ItdG9zKT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLToo ZHNjcCkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDpkc2NwPwog ICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOih0b3MpCiAgICAgICB8ICB8ICAgICAgICAg ICB8ICB8ICAgICArLS1ydyBhY2wtaXA6dG9zPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAg ICAgKy0tcncgYWNsLWlwOnByZWNlZGVuY2U/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1y dyBhY2wtaXA6aWdtcC10eXBlPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlw OmZsb3ctbGFiZWw/CiAgICAgICB8ICB8ICAgICAgICAgICArLS1ydyBhY2wtaXA6YWN0aW9ucwog ICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlwOmFjdGlvbgogICAgICAgfCAgfCAg ICAgICAgICAgfCAgKy0tcncgYWNsLWlwOmxvZz8KICAgICAgIHwgIHwgICAgICAgICAgICstLXJv IGFjbC1pcDptYXRjaD8KICAgICAgIHwgICstLXJ3IGFjbC1pcDppcHY0LWFjZXMKICAgICAgIHwg IHwgICstLXJ3IGFjbC1pcDppcHY0LWFjZSBbbmFtZV0KICAgICAgIHwgIHwgICAgICstLXJ3IGFj bC1pcDpuYW1lICAgICAgIGFjbDphY2wtbmFtZS1zdHJpbmcKICAgICAgIHwgIHwgICAgICstLXJ3 IChyZW1hcmstb3ItaXB2NC1hY2UpPwogICAgICAgfCAgfCAgICAgICAgKy0tOihyZW1hcmspCiAg ICAgICB8ICB8ICAgICAgICB8ICArLS1ydyBhY2wtaXA6cmVtYXJrPyAgICBhY2w6YWNsLXJlbWFy awogICAgICAgfCAgfCAgICAgICAgKy0tOihpcHY0LWFjZSkKICAgICAgIHwgIHwgICAgICAgICAg ICstLXJ3IGFjbC1pcDpmaWx0ZXJzCiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyAoc291 cmNlLWFkZHJlc3MtaG9zdC1ncm91cCkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLToo c291cmNlLWlwKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOmlw LXNvdXJjZS1hZGRyZXNzCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wt aXA6aXAtc291cmNlLW1hc2sKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLTooaXAtc291 cmNlLWFueSkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDppcC1z b3VyY2UtYW55PwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjks IDIwMTMgICAgICAgICAgICAgICBbUGFnZSAyN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAg fCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihzb3VyY2UtaG9zdCkKICAgICAgIHwgIHwgICAgICAg ICAgIHwgIHwgIHwgICstLXJ3IChpcC1zcmMtYWRkcmVzcy1vci1uYW1lKQogICAgICAgfCAgfCAg ICAgICAgICAgfCAgfCAgfCAgICAgKy0tOihpcC1zb3VyY2UtaG9zdC1hZGRyZXNzKQogICAgICAg fCAgfCAgICAgICAgICAgfCAgfCAgfCAgICAgfCArLS1ydyBhY2wtaXA6aXAtc291cmNlLWhvc3Qt YWRkcmVzcz8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgICstLTooaXAtc291cmNl LWhvc3QtbmFtZSkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgICAgICstLXJ3IGFj bC1pcDppcC1zb3VyY2UtaG9zdC1uYW1lPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0t Oihzb3VyY2UtZ3JvdXApCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICAgICArLS1ydyBhY2wt aXA6aXAtc291cmNlLWdyb3VwPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgKGRlc3Qt YWRkcmVzcy1ob3N0LWdyb3VwKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihkZXN0 LWlwKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOmlwLWRlc3Qt YWRkcmVzcwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOmlwLWRl c3QtbWFzawogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihpcC1kZXN0LWFueSkKICAg ICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDppcC1kZXN0LWFueT8KICAg ICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLTooZGVzdC1ob3N0KQogICAgICAgfCAgfCAgICAg ICAgICAgfCAgfCAgfCAgKy0tcncgKGlwLWRlc3QtYWRkcmVzcy1vci1uYW1lKQogICAgICAgfCAg fCAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tOihpcC1kZXN0LWhvc3QtYWRkcmVzcykKICAgICAg IHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgIHwgICstLXJ3IGFjbC1pcDppcC1kZXN0LWhvc3Qt YWRkcmVzcz8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICAgICstLTooaXAtZGVzdC1o b3N0LW5hbWUpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAgICAgICArLS1ydyBhY2wt aXA6aXAtZGVzdC1ob3N0LW5hbWU/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KGRl c3QtZ3JvdXApCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICAgICArLS1ydyBhY2wtaXA6aXAt ZGVzdC1ncm91cD8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDpwcm90b2Nv bD8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDplbmFibGUtY2FwdHVyZT8K ICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDpjYXB0dXJlLXNlc3Npb24taWQ/ CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6ZnJhZ21lbnRzPwogICAgICAg fCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlwOnRpbWUtcmFuZ2U/CiAgICAgICB8ICB8ICAg ICAgICAgICB8ICArLS1ydyAoc3JjLXBvcnRzKT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwg ICstLToocG9ydC1udW1iZXItcmFuZ2UpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICAr LS1ydyBhY2wtaXA6c3JjLXBvcnQtbG93ZXIKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwg ICstLXJ3IGFjbC1pcDpzcmMtcG9ydC11cHBlcgogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAg Ky0tOihwb3J0LW51bWJlcikKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFj bC1pcDpzcmMtY29tcGFyYXRvcgogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncg YWNsLWlwOnNyYy1wb3J0CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KHBvcnQtZ3Jv dXAtcmVmKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgKy0tcncgYWNsLWlwOnNyYy1w b3J0LWdyb3VwLW5hbWUKICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IChkZXN0LXBvcnRz KT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLToocG9ydC1udW1iZXItcmFuZ2UpCiAg ICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6ZGVzLXBvcnQtbG93ZXIK ICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDpkZXMtcG9ydC11cHBl cgogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihwb3J0LW51bWJlcikKICAgICAgIHwg IHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1pcDpkZXMtY29tcGFyYXRvcgogICAgICAg fCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOmRlcy1wb3J0CiAgICAgICB8ICB8 ICAgICAgICAgICB8ICB8ICArLS06KHBvcnQtZ3JvdXAtcmVmKQogICAgICAgfCAgfCAgICAgICAg ICAgfCAgfCAgICAgKy0tcncgYWNsLWlwOmRlcy1wb3J0LWdyb3VwLW5hbWUKICAgICAgIHwgIHwg ICAgICAgICAgIHwgICstLXJ3IGFjbC1pcDppY21wLXR5cGU/CiAgICAgICB8ICB8ICAgICAgICAg ICB8ICArLS1ydyBhY2wtaXA6aWNtcC1jb2RlPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0t cncgKHBhY2tldC1sZW5ndGgtb3ItcmFuZ2UpPwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAyOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1 YXJ5IDIwMTMKCgogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihsZW5ndGgpCiAgICAg ICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6cGFja2V0LWxlbmd0aC1jb21w YXJhdG9yCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtaXA6cGFja2V0 LWxlbmd0aAogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihyYW5nZSkKICAgICAgIHwg IHwgICAgICAgICAgIHwgIHwgICAgICstLXJ3IGFjbC1pcDpwYWNrZXQtbGVuZ3RoLXVwcGVyCiAg ICAgICB8ICB8ICAgICAgICAgICB8ICB8ICAgICArLS1ydyBhY2wtaXA6cGFja2V0LWxlbmd0aC1s b3dlcgogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlwOnRjcC1mbGFnLXZhbHVl PwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWlwOnRjcC1mbGFnLW1hc2s/CiAg ICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6dGNwLWZsYWctb3BlcmF0aW9uPwog ICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncgKHR0bC12YWx1ZS1vci1yYW5nZSk/CiAgICAg ICB8ICB8ICAgICAgICAgICB8ICB8ICArLS06KHZhbHVlKQogICAgICAgfCAgfCAgICAgICAgICAg fCAgfCAgfCAgKy0tcncgYWNsLWlwOnR0bC1jb21wYXJhdG9yPwogICAgICAgfCAgfCAgICAgICAg ICAgfCAgfCAgfCAgKy0tcncgYWNsLWlwOnR0bC12YWx1ZT8KICAgICAgIHwgIHwgICAgICAgICAg IHwgIHwgICstLToocmFuZ2UpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICAgICArLS1ydyBh Y2wtaXA6dHRsLXZhbHVlLWxvd2VyPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgKy0t cncgYWNsLWlwOnR0bC12YWx1ZS0tdXBwZXI/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1y dyAoZHNjcC1vci10b3MpPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgICAgKy0tOihkc2NwKQog ICAgICAgfCAgfCAgICAgICAgICAgfCAgICAgfCAgKy0tcncgYWNsLWlwOmRzY3A/CiAgICAgICB8 ICB8ICAgICAgICAgICB8ICAgICArLS06KHRvcykKICAgICAgIHwgIHwgICAgICAgICAgIHwgICAg ICAgICstLXJ3IGFjbC1pcDp0b3M/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICAgICAgICArLS1y dyBhY2wtaXA6cHJlY2VkZW5jZT8KICAgICAgIHwgIHwgICAgICAgICAgICstLXJ3IGFjbC1pcDph Y3Rpb25zCiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6YWN0aW9uICAgIGFj bDphY2wtYWN0aW9uCiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtaXA6bG9nPyAg ICAgIGVtcHR5CiAgICAgICB8ICB8ICAgICAgICAgICArLS1ybyBhY2wtaXA6bWF0Y2g/ICAgICB5 YW5nOmNvdW50ZXI2NAogICAgICAgfCAgKy0tcncgYWNsLWlwOmdsb2JhbC1mcmFnbWVudHM/ICAg ICAgICAgIGVudW1lcmF0aW9uCiAgICAgICB8ICArLS1ydyBhY2wtbWFjOm1hYy1hY2VzCiAgICAg ICB8ICB8ICArLS1ydyBhY2wtbWFjOm1hYy1hY2UgW25hbWVdCiAgICAgICB8ICB8ICAgICArLS1y dyBhY2wtbWFjOm5hbWUgICAgICAgYWNsOmFjbC1uYW1lLXN0cmluZwogICAgICAgfCAgfCAgICAg Ky0tcncgKHJlbWFyay1vci1tYWMtYWNlKT8KICAgICAgIHwgIHwgICAgICAgICstLToocmVtYXJr KQogICAgICAgfCAgfCAgICAgICAgfCAgKy0tcncgYWNsLW1hYzpyZW1hcms/ICAgIGFjbDphY2wt cmVtYXJrCiAgICAgICB8ICB8ICAgICAgICArLS06KG1hYy1hY2UpCiAgICAgICB8ICB8ICAgICAg ICAgICArLS1ydyBhY2wtbWFjOmZpbHRlcnMKICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3 IChzb3VyY2UtbmV0d29yaykKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLTooc291cmNl LW1hYykKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1tYWM6c291cmNl LWFkZHJlc3MKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1tYWM6c291 cmNlLWFkZHJlc3MtbWFzawogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihzb3VyY2Ut YW55KQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLW1hYzpzb3VyY2Ut YW55PwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgKy0tOihzb3VyY2UtaG9zdCkKICAgICAg IHwgIHwgICAgICAgICAgIHwgIHwgICAgICstLXJ3IChzcmMtYWRkcmVzcy1vci1uYW1lKQogICAg ICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgICAgKy0tOihzb3VyY2UtaG9zdC1hZGRyZXNzKQog ICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgICAgfCAgKy0tcncgYWNsLW1hYzpzb3VyY2Ut aG9zdC1hZGRyZXNzPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgICAgKy0tOihzb3Vy Y2UtaG9zdC1uYW1lKQogICAgICAgfCAgfCAgICAgICAgICAgfCAgfCAgICAgICAgICAgKy0tcncg YWNsLW1hYzpzb3VyY2UtaG9zdC1uYW1lPwogICAgICAgfCAgfCAgICAgICAgICAgfCAgKy0tcncg KGRlc3QtbmV0d29yaykKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMjldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAg ICAgIHwgIHwgICAgICAgICAgIHwgIHwgICstLTooZGVzdC1tYWMpCiAgICAgICB8ICB8ICAgICAg ICAgICB8ICB8ICB8ICArLS1ydyBhY2wtbWFjOmRlc3QtYWRkcmVzcwogICAgICAgfCAgfCAgICAg ICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLW1hYzpkZXN0LWFkZHJlc3MtbWFzawogICAgICAgfCAg fCAgICAgICAgICAgfCAgfCAgKy0tOihkZXN0LWFueSkKICAgICAgIHwgIHwgICAgICAgICAgIHwg IHwgIHwgICstLXJ3IGFjbC1tYWM6ZGVzdC1hbnk/CiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8 ICArLS06KGRlc3QtaG9zdCkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICAgICstLXJ3IChk ZXN0LWFkZHJlc3Mtb3ItbmFtZSkKICAgICAgIHwgIHwgICAgICAgICAgIHwgIHwgICAgICAgICst LTooZGVzdC1ob3N0LWFkZHJlc3MpCiAgICAgICB8ICB8ICAgICAgICAgICB8ICB8ICAgICAgICB8 ICArLS1ydyBhY2wtbWFjOmRlc3QtaG9zdC1hZGRyZXNzPwogICAgICAgfCAgfCAgICAgICAgICAg fCAgfCAgICAgICAgKy0tOihkZXN0LWhvc3QtbmFtZSkKICAgICAgIHwgIHwgICAgICAgICAgIHwg IHwgICAgICAgICAgICstLXJ3IGFjbC1tYWM6ZGVzdC1ob3N0LW5hbWU/CiAgICAgICB8ICB8ICAg ICAgICAgICB8ICArLS1ydyBhY2wtbWFjOmV0aGVydHlwZT8KICAgICAgIHwgIHwgICAgICAgICAg IHwgICstLXJ3IGFjbC1tYWM6ZXRoZXJ0eXBlLW1hc2s/CiAgICAgICB8ICB8ICAgICAgICAgICB8 ICArLS1ydyBhY2wtbWFjOmNvcz8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1t YWM6dGltZS1yYW5nZT8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1tYWM6dmxh bj8KICAgICAgIHwgIHwgICAgICAgICAgIHwgICstLXJ3IGFjbC1tYWM6ZW5hYmxlLWNhcHR1cmU/ CiAgICAgICB8ICB8ICAgICAgICAgICB8ICArLS1ydyBhY2wtbWFjOmNhcHR1cmUtc2Vzc2lvbi1p ZD8KICAgICAgIHwgIHwgICAgICAgICAgICstLXJ3IGFjbC1tYWM6YWN0aW9ucwogICAgICAgfCAg fCAgICAgICAgICAgfCAgKy0tcncgYWNsLW1hYzphY3Rpb24KICAgICAgIHwgIHwgICAgICAgICAg IHwgICstLXJ3IGFjbC1tYWM6bG9nPwogICAgICAgfCAgfCAgICAgICAgICAgKy0tcm8gYWNsLW1h YzptYXRjaD8KICAgICAgIHwgICstLXJ3IGFjbC1hcnA6YXJwLWFjZXMKICAgICAgIHwgICAgICst LXJ3IGFjbC1hcnA6YXJwLWFjZSBbbmFtZV0KICAgICAgIHwgICAgICAgICstLXJ3IGFjbC1hcnA6 bmFtZQogICAgICAgfCAgICAgICAgKy0tcncgKHJlbWFyay1vci1hcnAtYWNlKT8KICAgICAgIHwg ICAgICAgICAgICstLToocmVtYXJrKQogICAgICAgfCAgICAgICAgICAgfCAgKy0tcncgYWNsLWFy cDpyZW1hcms/CiAgICAgICB8ICAgICAgICAgICArLS06KGFycC1hY2UpCiAgICAgICB8ICAgICAg ICAgICAgICArLS1ydyBhY2wtYXJwOmZpbHRlcnMKICAgICAgIHwgICAgICAgICAgICAgIHwgICst LXJ3IGFjbC1hcnA6ZGlyZWN0aW9uPwogICAgICAgfCAgICAgICAgICAgICAgfCAgKy0tcncgKHNv dXJjZS1hZGRyZXNzLWhvc3QtZ3JvdXApCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICArLS06 KHNvdXJjZS1pcCkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1hcnA6 aXAtc291cmNlLWFkZHJlc3MKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFj bC1hcnA6aXAtc291cmNlLW1hc2sKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICstLTooaXAt c291cmNlLWFueSkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1hcnA6 aXAtc291cmNlLWFueT8KICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICstLTooc291cmNlLWhv c3QpCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyAoaXAtc3JjLWFkZHJlc3Mt b3ItbmFtZSkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICAgKy0tOihpcC1zb3VyY2Ut aG9zdC1hZGRyZXNzKQogICAgICAgfCAgICAgICAgICAgICAgfCAgfCAgfCAgICB8ICstLXJ3IGFj bC1hcnA6aXAtc291cmNlLWhvc3QtYWRkcmVzcz8KICAgICAgIHwgICAgICAgICAgICAgIHwgIHwg IHwgICAgKy0tOihpcC1zb3VyY2UtaG9zdC1uYW1lKQogICAgICAgfCAgICAgICAgICAgICAgfCAg fCAgfCAgICAgICAgKy0tcncgYWNsLWFycDppcC1zb3VyY2UtaG9zdC1uYW1lPwogICAgICAgfCAg ICAgICAgICAgICAgfCAgfCAgKy0tOihzb3VyY2UtZ3JvdXApCiAgICAgICB8ICAgICAgICAgICAg ICB8ICB8ICAgICArLS1ydyBhY2wtYXJwOmlwLXNvdXJjZS1ncm91cD8KICAgICAgIHwgICAgICAg ICAgICAgIHwgICstLXJ3IChkZXN0LWFkZHJlc3MtaG9zdC1ncm91cCkKICAgICAgIHwgICAgICAg ICAgICAgIHwgIHwgICstLTooZGVzdC1pcCkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwg ICstLXJ3IGFjbC1hcnA6aXAtZGVzdC1hZGRyZXNzCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDMwXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVi cnVhcnkgMjAxMwoKCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtYXJw OmlwLWRlc3QtbWFzawogICAgICAgfCAgICAgICAgICAgICAgfCAgfCAgKy0tOihpcC1kZXN0LWFu eSkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1hcnA6aXAtZGVzdC1h bnk/CiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICArLS06KGRlc3QtaG9zdCkKICAgICAgIHwg ICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IChpcC1kZXN0LWFkZHJlc3Mtb3ItbmFtZSkKICAg ICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICAgICstLTooaXAtZGVzdC1ob3N0LWFkZHJlc3Mp CiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICB8ICAgICB8ICArLS1ydyBhY2wtYXJwOmlwLWRl c3QtaG9zdC1hZGRyZXNzPwogICAgICAgfCAgICAgICAgICAgICAgfCAgfCAgfCAgICAgKy0tOihp cC1kZXN0LWhvc3QtbmFtZSkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICAgICAgICst LXJ3IGFjbC1hcnA6aXAtZGVzdC1ob3N0LW5hbWU/CiAgICAgICB8ICAgICAgICAgICAgICB8ICB8 ICArLS06KGRlc3QtZ3JvdXApCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICAgICArLS1ydyBh Y2wtYXJwOmlwLWRlc3QtZ3JvdXA/CiAgICAgICB8ICAgICAgICAgICAgICB8ICArLS1ydyAoc291 cmNlLW5ldHdvcmspCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICArLS06KHNvdXJjZS1tYWMp CiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtYXJwOnNvdXJjZS1hZGRy ZXNzCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtYXJwOnNvdXJjZS1h ZGRyZXNzLW1hc2sKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICstLTooc291cmNlLWFueSkK ICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1hcnA6c291cmNlLWFueT8K ICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICstLTooc291cmNlLWhvc3QpCiAgICAgICB8ICAg ICAgICAgICAgICB8ICB8ICAgICArLS1ydyAoc3JjLWFkZHJlc3Mtb3ItbmFtZSkKICAgICAgIHwg ICAgICAgICAgICAgIHwgIHwgICAgICAgICstLTooc291cmNlLWhvc3QtYWRkcmVzcykKICAgICAg IHwgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICstLXJ3IGFjbC1hcnA6c291cmNlLWhvc3Qt YWRkcmVzcz8KICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICAgICAgICstLTooc291cmNlLWhv c3QtbmFtZSkKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICstLXJ3IGFjbC1h cnA6c291cmNlLWhvc3QtbmFtZT8KICAgICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IChkZXN0 LW5ldHdvcmspCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8ICArLS06KGRlc3QtbWFjKQogICAg ICAgfCAgICAgICAgICAgICAgfCAgfCAgfCAgKy0tcncgYWNsLWFycDpkZXN0LWFkZHJlc3MKICAg ICAgIHwgICAgICAgICAgICAgIHwgIHwgIHwgICstLXJ3IGFjbC1hcnA6ZGVzdC1hZGRyZXNzLW1h c2sKICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICstLTooZGVzdC1hbnkpCiAgICAgICB8ICAg ICAgICAgICAgICB8ICB8ICB8ICArLS1ydyBhY2wtYXJwOmRlc3QtYW55PwogICAgICAgfCAgICAg ICAgICAgICAgfCAgfCAgKy0tOihkZXN0LWhvc3QpCiAgICAgICB8ICAgICAgICAgICAgICB8ICB8 ICAgICArLS1ydyAoZGVzdC1hZGRyZXNzLW9yLW5hbWUpCiAgICAgICB8ICAgICAgICAgICAgICB8 ICB8ICAgICAgICArLS06KGRlc3QtaG9zdC1hZGRyZXNzKQogICAgICAgfCAgICAgICAgICAgICAg fCAgfCAgICAgICAgfCAgKy0tcncgYWNsLWFycDpkZXN0LWhvc3QtYWRkcmVzcz8KICAgICAgIHwg ICAgICAgICAgICAgIHwgIHwgICAgICAgICstLTooZGVzdC1ob3N0LW5hbWUpCiAgICAgICB8ICAg ICAgICAgICAgICB8ICB8ICAgICAgICAgICArLS1ydyBhY2wtYXJwOmRlc3QtaG9zdC1uYW1lPwog ICAgICAgfCAgICAgICAgICAgICAgfCAgKy0tcncgYWNsLWFycDplbmFibGUtY2FwdHVyZT8KICAg ICAgIHwgICAgICAgICAgICAgIHwgICstLXJ3IGFjbC1hcnA6Y2FwdHVyZS1zZXNzaW9uLWlkPwog ICAgICAgfCAgICAgICAgICAgICAgKy0tcncgYWNsLWFycDphY3Rpb25zCiAgICAgICB8ICAgICAg ICAgICAgICB8ICArLS1ydyBhY2wtYXJwOmFjdGlvbgogICAgICAgfCAgICAgICAgICAgICAgfCAg Ky0tcncgYWNsLWFycDpsb2c/CiAgICAgICB8ICAgICAgICAgICAgICArLS1ybyBhY2wtYXJwOm1h dGNoPwogICAgICAgKy0tcncgcG9ydC1ncm91cHMKICAgICAgIHwgICstLXJ3IHBvcnQtZ3JvdXAg W25hbWVdCiAgICAgICB8ICAgICArLS1ydyBuYW1lCiAgICAgICB8ICAgICArLS1ydyBwb3J0LWdy b3VwLWVudHJ5IFtuYW1lXQogICAgICAgfCAgICAgICAgKy0tcncgbmFtZQogICAgICAgfCAgICAg ICAgKy0tcncgKHBvcnQtbnVtYmVyLW9yLXJhbmdlKT8KICAgICAgIHwgICAgICAgICAgICstLToo cG9ydC1udW1iZXItcmFuZ2UpCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDMxXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoK CiAgICAgICB8ICAgICAgICAgICB8ICArLS1ydyBwb3J0LWxvd2VyCiAgICAgICB8ICAgICAgICAg ICB8ICArLS1ydyBwb3J0LXVwcGVyCiAgICAgICB8ICAgICAgICAgICArLS06KHBvcnQtbnVtYmVy KQogICAgICAgfCAgICAgICAgICAgICAgKy0tcncgY29tcGFyYXRvcgogICAgICAgfCAgICAgICAg ICAgICAgKy0tcncgcG9ydAogICAgICAgKy0tcncgdGltZXJhbmdlLWdyb3VwcwogICAgICAgfCAg Ky0tcncgdGltZXJhbmdlLWdyb3VwIFtuYW1lXQogICAgICAgfCAgICAgKy0tcncgbmFtZQogICAg ICAgfCAgICAgKy0tcncgdGltZS1yYW5nZSBbbmFtZV0KICAgICAgIHwgICAgICAgICstLXJ3IG5h bWUKICAgICAgIHwgICAgICAgICstLXJ3IHJlbWFyaz8KICAgICAgIHwgICAgICAgICstLXJ3IChy YW5nZS10eXBlKT8KICAgICAgIHwgICAgICAgICAgICstLTooYWJzb2x1dGUpCiAgICAgICB8ICAg ICAgICAgICB8ICArLS1ydyBhYnNvbHV0ZQogICAgICAgfCAgICAgICAgICAgfCAgICAgKy0tcncg c3RhcnQ/CiAgICAgICB8ICAgICAgICAgICB8ICAgICArLS1ydyBlbmQ/CiAgICAgICB8ICAgICAg ICAgICArLS06KHBlcmlvZGljKQogICAgICAgfCAgICAgICAgICAgICAgKy0tcncgcGVyaW9kaWMK ICAgICAgIHwgICAgICAgICAgICAgICAgICstLXJ3IHdlZWtkYXlzPwogICAgICAgfCAgICAgICAg ICAgICAgICAgKy0tcncgc3RhcnQ/CiAgICAgICB8ICAgICAgICAgICAgICAgICArLS1ydyBlbmQ/ CiAgICAgICArLS1ydyBpcC1hZGRyZXNzLWdyb3VwcwogICAgICAgICAgKy0tcncgaXAtYWRkcmVz cy1ncm91cCBbbmFtZV0KICAgICAgICAgICAgICstLXJ3IG5hbWUKICAgICAgICAgICAgICstLXJ3 IGFmaT8KICAgICAgICAgICAgICstLXJ3IGlwLWFkZHJlc3MgW25hbWVdCiAgICAgICAgICAgICAg ICArLS1ydyBuYW1lCiAgICAgICAgICAgICAgICArLS1ydyAoaXAtbmV0d29yay1raW5kKQogICAg ICAgICAgICAgICAgICAgKy0tOihpcCkKICAgICAgICAgICAgICAgICAgIHwgICstLXJ3IGlwLWFk ZHJlc3M/CiAgICAgICAgICAgICAgICAgICB8ICArLS1ydyBpcC1tYXNrCiAgICAgICAgICAgICAg ICAgICArLS06KGlwLWFueSkKICAgICAgICAgICAgICAgICAgIHwgICstLXJ3IGlwLWFueT8KICAg ICAgICAgICAgICAgICAgICstLTooaG9zdCkKICAgICAgICAgICAgICAgICAgICAgICstLXJ3IChh ZGRyZXNzLW9yLW5hbWUpCiAgICAgICAgICAgICAgICAgICAgICAgICArLS06KGlwLWhvc3QtYWRk cmVzcykKICAgICAgICAgICAgICAgICAgICAgICAgIHwgICstLXJ3IGlwLWhvc3QtYWRkcmVzcz8K ICAgICAgICAgICAgICAgICAgICAgICAgICstLTooaXAtaG9zdC1uYW1lKQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tcncgaXAtaG9zdC1uYW1lPwogbW9kdWxlOiBhY2wtaXAKIG1vZHVs ZTogYWNsLW1hYwogbW9kdWxlOiBhY2wtYXJwCgoKCiAgICAgICAgICAgICAgICAgICAgICBGaWd1 cmUgMwoKCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAx MyAgICAgICAgICAgICAgIFtQYWdlIDMyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCjkuICBBQ0wgRXhh bXBsZXMKCjkuMS4gIENvbmZpZ3VyYXRpb24gRXhhbXBsZQoKICAgUmVxdWlyZW1lbnQ6IERlbmll cyBURUxORVQgdHJhZmZpYyBmcm9tIDE0LjMuNi4yMzQgYm91bmQgZm9yIGhvc3QKICAgNi41LjQu MSBmcm9tIGxlYXZpbmcuICBEZW5pZXMgYWxsIFRGVFAgdHJhZmZpYyBib3VuZCBmb3IgVEZUUAog ICBzZXJ2ZXJzLiAgUGVybWl0cyBhbGwgb3RoZXIgSVAgdHJhZmZpYy4KCiAgIEluIG9yZGVyIHRv IGFjaGlldmUgdGhlIHJlcXVpcmVtZW50LCBhbiBuYW1lIGFjY2VzcyBjb250cm9sIGxpc3QgaXMK ICAgbmVlZGVkLiAgSW4gdGhlIGFjbCwgd2UgbmVlZCB0aHJlZSBhY2VzLiAgVGhlIGFjbCBhbmQg YWNlcyBjYW4gYmUKICAgZGVzY3JpYmVkIGluIENMSTogYXMgdGhlIGZvbGxvd2luZzoKCiAgIGFj Y2Vzcy1saXN0IGlwIGlhY2wKCiAgICAgIGRlbnkgdGNwIDE0LjMuNi4yMzQgMC4wLjAuMCBob3N0 IDYuNS40LjEgZXEgMjMKICAgICAgZGVueSB1ZHAgYW55IGFueSBlcSB0ZnRwCiAgICAgIHBlcm1p dCBpcCBhbnkgYW55CgogICBIZXJlIGlzIHRoZSBleGFtcGxlIGFjbCBjb25maWd1cmF0aW9uIHht bDoKCjxycGMgbWVzc2FnZS1pZD0iMTAxIgogICAgICB4bWxuczpuYz0idXJuOmNpc2NvOnBhcmFt czp4bWw6bnM6eWFuZzphY2w6MS4wIgogIHhtbG5zOmFjbC1pcD0idXJuOmNpc2NvOnBhcmFtczp4 bWw6bnM6eWFuZzphY2wtaXAiCiAgIC8vIHJlcGxhY2Ugd2l0aCBJQU5BIG5hbWVzcGFjZSB3aGVu IGFzc2lnbmVkCiAgPGVkaXQtY29uZmlnPgogICAgPHRhcmdldD4KICAgICAgPHJ1bm5pbmcvPgog ICAgPC90YXJnZXQ+CiAgICA8Y29uZmlnPgogICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBs ZS5jb20vc2NoZW1hLzEuMi9jb25maWciPgoKICAgICAgICA8YWNscz4KICAgICAgICAgIDxhY2wg PgogICAgICAgICAgICA8bmFtZT5zYW1wbGUtaXAtYWNsPC9uYW1lPgogICAgICAgICAgICA8YWNs LXR5cGU+aXAtYWNsPC9hY2wtdHlwZT4KICAgICAgICAgICAgPGVuYWJsZS1tYXRjaC1jb3VudGVy PmZhbHNlPC9lbmFibGUtbWF0Y2gtY291bnRlcj4KICAgICAgICAgICAgPGFjbC1pcDphZmk+aXB2 NDwvYWNsLWlwOmFmaT4KICAgICAgICAgICAgPGFjbC1pcDppcHY0LWFjZXM+CgogICAgICAgICAg ICAgIDxhY2wtaXA6aXB2NC1hY2U+CiAgICAgICAgICAgICAgICA8YWNsLWlwOm5hbWU+YWNlMTA8 L2FjbC1pcDpuYW1lPgogICAgICAgICAgICAgICAgPGFjbC1pcDpmaWx0ZXJzPgogICAgICAgICAg ICAgICAgICA8YWNsLWlwOnByb3RvY29sPjY8L2FjbC1pcDpwcm90b2NvbD4KICAgICAgICAgICAg ICAgICAgPGFjbC1pcDppcC1zb3VyY2UtYWRkcmVzcz4KICAgICAgICAgICAgICAgICAgICAxNC4z LjYuMjM0CiAgICAgICAgICAgICAgICAgIDwvYWNsLWlwOmlwLXNvdXJjZS1hZGRyZXNzPgogICAg ICAgICAgICAgICAgICA8YWNsLWlwOmlwLXNvdXJjZS1tYXNrPjAuMC4wLjA8L2FjbC1pcDppcC1z b3VyY2UtbWFzaz4KICAgICAgICAgICAgICAgICAgPGFjbC1pcDppcC1kZXN0LWhvc3QtYWRkcmVz cz4KCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgMzNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5 YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAg ICAgICA2LjUuNC4xCiAgICAgICAgICAgICAgICAgIDwvYWNsLWlwOmlwLWRlc3QtaG9zdC1hZGRy ZXNzPgogICAgICAgICAgICAgICAgICA8YWNsLWlwOmRlcy1jb21wYXJhdG9yPmVxPC9hY2wtaXA6 ZGVzLWNvbXBhcmF0b3I+CiAgICAgICAgICAgICAgICAgIDxhY2wtaXA6ZGVzLXBvcnQ+MjM8L2Fj bC1pcDpkZXMtcG9ydD4KICAgICAgICAgICAgICAgIDwvYWNsLWlwOmZpbHRlcnM+CiAgICAgICAg ICAgICAgICA8YWNsLWlwOmFjdGlvbnM+CiAgICAgICAgICAgICAgICAgIDxhY2wtaXA6YWN0aW9u PmRlbnk8L2FjbC1pcDphY3Rpb24+CiAgICAgICAgICAgICAgICA8L2FjbC1pcDphY3Rpb25zPgog ICAgICAgICAgICAgIDwvYWNsLWlwOmlwdjQtYWNlPgoKICAgICAgICAgICAgICA8YWNsLWlwOmlw djQtYWNlPgogICAgICAgICAgICAgICAgPGFjbC1pcDpuYW1lPmFjZTIwPC9hY2wtaXA6bmFtZT4K ICAgICAgICAgICAgICAgIDxhY2wtaXA6ZmlsdGVycz4KICAgICAgICAgICAgICAgICAgPGFjbC1p cDpwcm90b2NvbD4xNzwvYWNsLWlwOnByb3RvY29sPgogICAgICAgICAgICAgICAgICA8YWNsLWlw OmlwLXNvdXJjZS1hbnkvPgogICAgICAgICAgICAgICAgICA8YWNsLWlwOmlwLWRlc3QtYW55Lz4K ICAgICAgICAgICAgICAgICAgPGFjbC1pcDpkZXMtY29tcGFyYXRvcj5lcTwvYWNsLWlwOmRlcy1j b21wYXJhdG9yPgogICAgICAgICAgICAgICAgICA8YWNsLWlwOmRlcy1wb3J0PjY5PC9hY2wtaXA6 ZGVzLXBvcnQ+CiAgICAgICAgICAgICAgICA8L2FjbC1pcDpmaWx0ZXJzPgogICAgICAgICAgICAg ICAgPGFjbC1pcDphY3Rpb25zPgogICAgICAgICAgICAgICAgICA8YWNsLWlwOmFjdGlvbj5kZW55 PC9hY2wtaXA6YWN0aW9uPgogICAgICAgICAgICAgICAgPC9hY2wtaXA6YWN0aW9ucz4KICAgICAg ICAgICAgICA8L2FjbC1pcDppcHY0LWFjZT4KCiAgICAgICAgICAgICAgPGFjbC1pcDppcHY0LWFj ZT4KICAgICAgICAgICAgICAgIDxhY2wtaXA6bmFtZT5hY2UzMDwvYWNsLWlwOm5hbWU+CiAgICAg ICAgICAgICAgICA8YWNsLWlwOmZpbHRlcnM+CiAgICAgICAgICAgICAgICAgIDxhY2wtaXA6aXAt c291cmNlLWFueS8+CiAgICAgICAgICAgICAgICAgIDxhY2wtaXA6aXAtZGVzdC1hbnkvPgogICAg ICAgICAgICAgICAgPC9hY2wtaXA6ZmlsdGVycz4KICAgICAgICAgICAgICAgIDxhY2wtaXA6YWN0 aW9ucz4KICAgICAgICAgICAgICAgICAgPGFjbC1pcDphY3Rpb24+cGVybWl0PC9hY2wtaXA6YWN0 aW9uPgogICAgICAgICAgICAgICAgPC9hY2wtaXA6YWN0aW9ucz4KICAgICAgICAgICAgICA8L2Fj bC1pcDppcHY0LWFjZT4KICAgICAgICAgICAgPC9hY2wtaXA6aXB2NC1hY2VzPgoKICAgICAgICAg IDwvYWNsPgogICAgICAgIDwvYWNscz4KCiAgICAgIDwvdG9wPgogICAgPC9jb25maWc+CiAgPC9l ZGl0LWNvbmZpZz4KPC9ycGM+CgoKCgoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMzRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAy MDEzCgoKMTAuICBBQ0wgWUFORyBNb2R1bGUKCiAgIFRoaXMgbW9kdWxlIGltcG9ydHMgdHlwZSBk ZWZpbml0aW9ucyBmcm9tIFtSRkM2MDIxXS4KCiA8Q09ERSBCRUdJTlM+IGZpbGUgImFjbEAyMDEy LTEwLTEyLnlhbmciCiBtb2R1bGUgYWNsIHsKICAgICBuYW1lc3BhY2UgInVybjpjaXNjbzpwYXJh bXM6eG1sOm5zOnlhbmc6YWNsIjsKICAgICAvLyByZXBsYWNlIHdpdGggSUFOQSBuYW1lc3BhY2Ug d2hlbiBhc3NpZ25lZAogICAgIHByZWZpeCBhY2w7CgogICAgIGltcG9ydCBpZXRmLWluZXQtdHlw ZXMgewogICAgICAgICBwcmVmaXggImluZXQiOwogICAgIH0KCiAgICAgaW1wb3J0IGlldGYteWFu Zy10eXBlcyB7CiAgICAgICAgIHByZWZpeCAieWFuZyI7CiAgICAgfQoKICAgICBvcmdhbml6YXRp b24KICAgICAgICAiSUVURiBORVRNT0QgKE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSkg V29ya2luZyBHcm91cCI7CgogICAgIGNvbnRhY3QKICAgICAgICAgICJXRyBXZWI6IGh0dHA6Ly90 b29scy5pZXRmLm9yZy93Zy9uZXRtb2QvCiAgICAgICAgIFdHIExpc3Q6IG5ldG1vZEBpZXRmLm9y ZwoKICAgICAgICAgV0cgQ2hhaXI6IERhdmlkIEtlc3NlbnMKICAgICAgICAgZGF2aWQua2Vzc2Vu c0Buc24uY29tCgogICAgICAgICBXRyBDaGFpcjogSnVlcmdlbiBTY2hvZW53YWVsZGVyCiAgICAg ICAgIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZQoKICAgICAgICAgRWRpdG9y OiBMaXNhIEh1YW5nCiAgICAgICAgIHlpaHVhbkBjaXNjby5jb20KCiAgICAgICAgIEVkaXRvcjog QWxleGFuZGVyIENsZW1tCiAgICAgICAgIGFsZXhAY2lzY28uY29tCgogICAgICAgICBFZGl0b3I6 IEFuZHkgQmllcm1hbgogICAgICAgICBhbmR5QHl1bWF3b3Jrcy5jb20iOwoKICAgICBkZXNjcmlw dGlvbgogICAgICAgICAiVGhpcyBZQU5HIG1vZHVsZSBkZWZpbmVzIGEgY29tcG9uZW50IHRoYXQg ZGVzY3JpYmluZyB0aGUKICAgICAgICAgY29uZmlndXJhdGlvbiBvZiBBY2Nlc3MgQ29udHJvbCBM aXN0cyAoQUNMcykuCgogICAgICAgICBBbiBBQ0wgaXMgYW4gb3JkZXJlZCBzZXQgb2YgcnVsZXMg YW5kIGFjdGlvbnMgdXNlZCB0byBmaWx0ZXIKICAgICAgICAgdHJhZmZpYy4gIEVhY2ggc2V0IG9m IHJ1bGVzIGFuZCBhY3Rpb25zIGlzIHJlcHJlc2VudGVkCiAgICAgICAgIGFzIGFuIEFjY2VzcyBD b250cm9sIEVudHJpZXMgKEFDRSkuIEVhY2ggQUNFIGlzIGV2YWx1YXRlZAogICAgICAgICBzZXF1 ZW50aWFsbHkuIFdoZW4gdGhlIHJ1bGUgbWF0Y2hlcyB0aGVuIGFjdGlvbiBmb3IgdGhhdAoKCgpI dWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAg ICAgICBbUGFnZSAzNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNs ICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAgICBydWxlIGlzIGFwcGxp ZWQgdG8gdGhlIHBhY2tldC4KCiAgICAgICAgIFRoZXJlIGFyZSB0aHJlZSB0eXBlcyBvZiBBQ0wu CgogICAgICAgICBJUCBBQ0xzIC0gSVAgQUNMcyBhcmUgb3JkZXJlZCBzZXRzIG9mIHJ1bGVzIHRo YXQgY2FuIHVzZSB0bwogICAgICAgICAgICAgZmlsdGVyIHRyYWZmaWMgYmFzZWQgb24gSVAgaW5m b3JtYXRpb24gaW4gdGhlIExheWVyIDMKICAgICAgICAgICAgIGhlYWRlciBvZiBwYWNrZXRzLgog ICAgICAgICAgICAgVGhlIGRldmljZSBhcHBsaWVzIElQIEFDTHMgb25seSB0byBJUCB0cmFmZmlj LiBJUCBBQ0wKICAgICAgICAgICAgIGNhbiBiZSBJUHY0IG9yIElQdjYuCiAgICAgICAgIE1BQyBB Q0xzIC0gTUFDIEFDTHMgYXJlIHVzZWQgdG8gZmlsdGVyIHRyYWZmaWMgdXNpbmcgdGhlCiAgICAg ICAgICAgICBpbmZvcm1hdGlvbiBpbiB0aGUgTGF5ZXIgMiBoZWFkZXIgb2YgZWFjaCBwYWNrZXQu CiAgICAgICAgICAgICBNQUMgQUNMcyBhcmUgYnkgZGVmYXVsdCBvbmx5IGFwcGxpZWQgdG8gbm9u LUlQCiAgICAgICAgICAgICB0cmFmZmljOyBob3dldmVyLCBMYXllciAyIGludGVyZmFjZXMgY2Fu IGJlIGNvbmZpZ3VyZWQKICAgICAgICAgICAgIHRvIGFwcGx5IE1BQyBBQ0xzIHRvIGFsbCB0cmFm ZmljLgogICAgICAgICBBUlAgQUNMcyAtIFRoZSBkZXZpY2UgYXBwbGllcyBBUlAgQUNMcyB0byBJ UCB0cmFmZmljLgoKCiAgICAgICAgIFRoaXMgbW9kdWxlIHNob3VsZCBiZSB1c2VkIHdpdGggYWNs LWlwLCBhY2wtYXJwLCBvciBhY2wtbWFjCiAgICAgICAgIGRlcGVuZHMgb24gd2hhdCBmZWF0dXJl IHRoZSBkZXZpY2Ugc3VwcG9ydHMuCgogICAgICAgICBUaGlzIFlBTkcgbW9kdWxlIGFsc28gaW5j bHVkZXMgYXV4aWxpYXJ5IGRlZmluaXRpb25zIHRoYXQKICAgICAgICAgYXJlIG5lZWRlZCBpbiBj b25qdW5jdGlvbiB3aXRoIGNvbmZpZ3VyYXRpb24gb2YgQUNMcywgc3VjaCBhcwogICAgICAgICBy ZXVzYWJsZSBjb250YWluZXJzIGFuZCByZWZlcmVuY2VzIGZvciBwb3J0cyBhbmQgSVAuCgogICAg ICAgICBUZXJtcyBhbmQgQWNyb255bXMKICAgICAgICAgIEFDRSAoYWNlKTogQWNjZXNzIENvbnRy b2wgRW50cnkKCiAgICAgICAgICBBQ0wgKGFjbCk6IEFjY2VzcyBDb250cm9sIExpc3QKCiAgICAg ICAgICBBRkkgKGFmaSk6IEF1dGhvcml0eSBhbmQgRm9ybWF0IElkZW50aWZpZXIgKEFkZHJlc3MK ICAgICAgICAgICAgICBGaWVsZCBJZGVudGlmaWVyKQoKICAgICAgICAgIEFSUCAoYXJwKTogQWRk cmVzcyBSZXNvbHV0aW9uIFByb3RvY29sCgogICAgICAgICAgSVAgKGlwKTogSW50ZXJuZXQgUHJv dG9jb2wKCiAgICAgICAgICBJUHY0IChpcHY0KTpJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9uIDQK CiAgICAgICAgICBJUHY2IChpcHY2KTogSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2CgogICAg ICAgICAgTUFDOiBNZWRpYSBBY2Nlc3MgQ29udHJvbAoKICAgICAgICAgIFRDUCAodGNwKTogVHJh bnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wKCiAgICAgICAgICBUVEwgKHR0bCk6IFRpbWUgdG8g TGl2ZQoKICAgICAgICAgIFZMQU4gKHZsYW4pOiBWaXJ0dWFsIExvY2FsIEFyZWEgTmV0d29yawog ICAgICAgICI7CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwg MjAxMyAgICAgICAgICAgICAgIFtQYWdlIDM2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgcmVm ZXJlbmNlCiAgICAgICAgICJBY2Nlc3MgTGlzdCBDb21tYW5kcyBvbiBDaXNjbyBJT1MgWFIgU29m dHdhcmUsCiAgICAgICAgIENpc2NvIE5leHVzIDcwMDAgU2VyaWVzIE5YLU9TIFNlY3VyaXR5IENv bmZpZ3VyYXRpb24gR3VpZGUsCiAgICAgICAgIENhdGFseXN0IDY1MDAgUmVsZWFzZSAxMi4yU1gg U29mdHdhcmUgQ29uZmlndXJhdGlvbiBHdWlkZSwKICAgICAgICAgQUNMIFRDUCBGbGFncyBGaWx0 ZXJpbmciOwoKICAgICByZXZpc2lvbiAyMDEyLTEwLTEyIHsKICAgICAgICAgZGVzY3JpcHRpb24g IkluaXRpYWwgcmV2aXNpb24uICI7CiAgICAgfQoKICAgICAvKiBGZWF0dXJlcyAqLwoKICAgICBm ZWF0dXJlIGNhcHR1cmUtc2Vzc2lvbi1pZCB7CiAgICAgICAgIGlmLWZlYXR1cmUgcGFja2V0LWNh cHR1cmU7CiAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAiVGhlIGFiaWxpdHkgdG8g Y29uZmlndXJlIEFDTCBjYXB0dXJlIGluIG9yZGVyIHRvCiAgICAgICAgICAgICBzZWxlY3RpdmVs eSBtb25pdG9yIHRyYWZmaWMgb24gYW4gaW50ZXJmYWNlIG9yIFZMQU4uCiAgICAgICAgICAgICBX aGVuIHRoZSBjYXB0dXJlIG9wdGlvbiBmb3IgYW4gQUNMIHJ1bGUKICAgICAgICAgICAgIGlzIGVu YWJsZWQsIHBhY2tldHMgdGhhdCBtYXRjaCB0aGlzIHJ1bGUgYXJlCiAgICAgICAgICAgICBlaXRo ZXIgZm9yd2FyZGVkIG9yIGRyb3BwZWQgYmFzZWQgb24gdGhlIHNwZWNpZmllZCBwZXJtaXQKICAg ICAgICAgICAgIG9yIGRlbnkgYWN0aW9uIGFuZCBtYXkgYWxzbyBiZSBjb3BpZWQgdG8gYW4gYWx0 ZXJuYXRlCiAgICAgICAgICAgICBkZXN0aW5hdGlvbiBwb3J0IGZvciBmdXJ0aGVyIGFuYWx5c2lz LgogICAgICAgICAgICAgQW4gQUNMIHJ1bGUgd2l0aCB0aGUgY2FwdHVyZSBvcHRpb24gY2FuIGJl IGFwcGxpZWQKICAgICAgICAgICAgIGFzIGZvbGxvd3M6CiAgICAgICAgICAgICAgICAgT24gYSBW TEFOCiAgICAgICAgICAgICAgICAgSW4gdGhlIGluZ3Jlc3MgZGlyZWN0aW9uIG9uIGFsbCBpbnRl cmZhY2VzCiAgICAgICAgICAgICAgICAgSW4gdGhlIGVncmVzcyBkaXJlY3Rpb24gb24gYWxsIExh eWVyIDMgaW50ZXJmYWNlcwogICAgICAgICAgICAgVGhlIHN0YXRpc3RpY3MgZGF0YSBmb3IgdGhl IGNhcHR1cmUtc2Vzc2lvbiBhcmUgY2FwdHVyZQogICAgICAgICAgICAgaW4gdGhlIGRldmljZSB3 aGVyZSB0aGUgQUNMIHJ1bGUgYXBwbGllZCB0by4iOwogICAgIH0KCiAgICAgZmVhdHVyZSBob3N0 LWJ5LW5hbWUgewogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgIlRoZSBjYXBhYmls aXR5IHRvIHJlZmVyZW5jZSBhIGhvc3QgYnkgRE5TIG5hbWUuIjsKICAgICB9CgogICAgIGZlYXR1 cmUgaXAtYWRkcmVzcy1ncm91cHMgewogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAg IlRoZSBhYmlsaXR5IHRvIGRlZmluZSBuYW1lZCBncm91cHMgZm9yIGxpc3RzIG9mCiAgICAgICAg ICAgICBpcCBhZGRyZXNzZXMuICI7CiAgICAgfQoKICAgICBmZWF0dXJlIGxvZ2dpbmcgewogICAg ICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgIlRoZSBhYmlsaXR5IHRvIGxvZyBtZXNzYWdl cyB1cG9uIHRoZSBtYXRjaGluZyBvZiBBQ0xzLiI7CiAgICAgfQoKICAgICBmZWF0dXJlIG1hdGNo LWNvdW50ZXIgewoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjks IDIwMTMgICAgICAgICAgICAgICBbUGFnZSAzN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAg ICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgIlRoZSBhYmlsaXR5IHRvIG1haW50YWluIGdsb2Jh bCBvciBsb2NhbCBtYXRjaCBzdGF0aXN0aWNzCiAgICAgICAgICAgICBmb3IgZWFjaCBBQ0wgcnVs ZXMuIjsKICAgICB9CgogICAgIGZlYXR1cmUgcGFja2V0LWNhcHR1cmUgewogICAgICAgICBkZXNj cmlwdGlvbiAiVGhlIGFiaWxpdHkgdG8gY2FwdHVyZSBwYWNrZXRzIHRoYXQKICAgICAgICAgICBt YXRjaCB0aGUgZmlsdGVyLiI7CiAgICAgfQoKICAgICBmZWF0dXJlIHBhY2tldC1sZW5ndGggewog ICAgICAgICBkZXNjcmlwdGlvbiAiVGhlIGFiaWxpdHkgdG8gZmlsdGVyIHBhY2tldHMgYnkgcGFj a2V0IGxlbmd0aCI7CiAgICAgfQoKICAgICBmZWF0dXJlIHBvcnQtZ3JvdXBzIHsKICAgICAgICAg ZGVzY3JpcHRpb24KICAgICAgICAgICAgICJUaGUgYWJpbGl0eSB0byBkZWZpbmUgbmFtZWQgZ3Jv dXBzIGZvciBsaXN0cyBvZiBwb3J0cy4gIjsKICAgICB9CgoKICAgICAvKiBJZGVudGl0aWVzICov CgogICAgIGlkZW50aXR5IGFjbC10eXBlIHsKICAgICAgICAgZGVzY3JpcHRpb24gIkJhc2UgYWNs IHR5cGUgZm9yIGFsbCBBQ0wgdHlwZSBpZGVudGlmaWVycy4iOwogICAgIH0KCgogICAgIC8qIFR5 cGVzICovCgogICAgIHR5cGVkZWYgYWNsLWNvbXBhcmF0b3IgewogICAgICAgICBkZXNjcmlwdGlv biAiQSBkYXRhIHR5cGUgdXNlZCB0byBleHByZXNzIGNvbXBhcmF0b3Igc3RyaW5nIjsKICAgICAg ICAgdHlwZSBlbnVtZXJhdGlvbiB7CiAgICAgICAgICAgICBlbnVtICJlcSIgewogICAgICAgICAg ICAgICAgIHZhbHVlIDA7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIm1hdGNoIG9ubHkg ZXF1YWwgdG8gYW55IGdpdmluZyBudW1iZXIuIjsKICAgICAgICAgICAgIH0KICAgICAgICAgICAg IGVudW0gImd0IiB7CiAgICAgICAgICAgICAgICAgdmFsdWUgMTsKICAgICAgICAgICAgICAgICBk ZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAibWF0Y2ggb25seSBncmVhdGVyIHRoYW4g YW55IGdpdmluZyBudW1iZXIuIjsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGVudW0gImx0 IiB7CiAgICAgICAgICAgICAgICAgdmFsdWUgMjsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlv bgogICAgICAgICAgICAgICAgICAgICAibWF0Y2ggb25seSBsb3dlciB0aGFuIGFueSBnaXZpbmcg bnVtYmVyLiI7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBlbnVtICJuZXEiIHsKICAgICAg ICAgICAgICAgICB2YWx1ZSAzOwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBB dWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSAzOF0KDApJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMK CgogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgICAgICJtYXRj aCBvbmx5IG5vdCBlcXVhbCB0byBhbnkgZ2l2aW5nIG51bWJlciI7CiAgICAgICAgICAgICB9CiAg ICAgICAgIH0KICAgICB9CgogICAgIHR5cGVkZWYgYWNsLWFjdGlvbiB7CiAgICAgICAgIGRlc2Ny aXB0aW9uICJBbiBlbnVtZXJhdGlvbiBkYXRhIHR5cGUgdG8gZXhwcmVzcyBhY2wKICAgICAgICAg ICAgIGFjdGlvbiB3aGVuIG1hdGNoLiI7CiAgICAgICAgIHR5cGUgZW51bWVyYXRpb24gewogICAg ICAgICAgICAgZW51bSBkZW55IHsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiQXBwbHkg ZGVueSBhY3Rpb24gdG8gdGhlIHRyYWZmaWMiOwogICAgICAgICAgICAgfQogICAgICAgICAgICAg ZW51bSBwZXJtaXQgewogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJBcHBseSBwZXJtaXQg YWN0aW9uIHRvIHRoZSB0cmFmZmljIjsKICAgICAgICAgICAgIH0KCiAgICAgICAgIH0KCiAgICAg fQoKICAgICB0eXBlZGVmIGFjbC1yZW1hcmsgewogICAgICAgICB0eXBlIHN0cmluZyB7CiAgICAg ICAgICAgICBsZW5ndGggIjAuLjEwMCI7CiAgICAgICAgIH0KICAgICAgICAgZGVzY3JpcHRpb24K ICAgICAgICAgICAiQSByZW1hcmsgaXMgYSBjb21tZW50IHRoYXQgY2FuIGJlCiAgICAgICAgICAg IGFzc29jaWF0ZWQgd2l0aCBhbiBBQ0UgaW4gb3JkZXIgdG8gbWFrZQogICAgICAgICAgICB0aGUg YWNjZXNzIGxpc3QgZWFzaWVyIGZvciB0aGUgbmV0d29yawogICAgICAgICAgICBhZG1pbmlzdHJh dG9yIHRvIHVuZGVyc3RhbmQuCiAgICAgICAgICAgIEl0IGlzIHJldGFpbmVkIHRvIGZhY2lsaXRh dGUKICAgICAgICAgICAgY28tZXhpc3RlbmNlIHdpdGggQ0xJLiI7CiAgICAgfQoKICAgICB0eXBl ZGVmIGFjbC10eXBlLXJlZiB7CiAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAiVGhp cyB0eXBlIGlzIHVzZWQgdG8gcmVmZXIgdG8gYW4gQWNjZXNzIENvbnRyb2wgTGlzdAogICAgICAg ICAgICAgKEFDTCkgdHlwZSI7CiAgICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgewogICAgICAgICAg ICAgYmFzZSAiYWNsLXR5cGUiOwogICAgICAgICB9CiAgICAgfQoKICAgICB0eXBlZGVmIGFjbC1y ZWYgewogICAgICAgICBkZXNjcmlwdGlvbiAiVGhpcyB0eXBlIHJlZmVycyB0byBhbiBBQ0wuIjsK ICAgICAgICAgdHlwZSBsZWFmcmVmIHsKICAgICAgICAgICAgIHBhdGggICIvYWNsOmFjbHMvYWNs OmFjbC9hY2w6bmFtZSI7CiAgICAgICAgIH0KCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMzldCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFy eSAyMDEzCgoKICAgICB9CgogICAgIHR5cGVkZWYgcG9ydC1ncm91cC1yZWYgewogICAgICAgICBk ZXNjcmlwdGlvbgogICAgICAgICAgICAgIlRoaXMgdHlwZSBpcyB1c2VkIHRvIHJlZmVyIHRvIGEg UG9ydGdyb3VwIG9iamVjdC4iOwogICAgICAgICB0eXBlIGxlYWZyZWYgewogICAgICAgICAgICAg cGF0aCAiL2FjbHMvcG9ydC1ncm91cHMvcG9ydC1ncm91cC9uYW1lIjsKICAgICAgICAgfQoKICAg ICB9CgogICAgIHR5cGVkZWYgaXAtYWRkcmVzcy1ncm91cC1yZWYgewogICAgICAgICBkZXNjcmlw dGlvbgogICAgICAgICAgICAgIlRoaXMgdHlwZSBpcyB1c2VkIHRvIHJlZmVyIHRvIGEgdGltZSBy YW5nZSBvYmplY3QuIjsKICAgICAgICAgdHlwZSBsZWFmcmVmIHsKICAgICAgICAgICAgIHBhdGgg Ii9hY2xzL2lwLWFkZHJlc3MtZ3JvdXBzL2lwLWFkZHJlc3MtZ3JvdXAvbmFtZSI7CiAgICAgICAg IH0KICAgICB9CgogICAgIHR5cGVkZWYgdGltZS1yYW5nZS1yZWYgewogICAgICAgICBkZXNjcmlw dGlvbgogICAgICAgICAgICAgIlRoaXMgdHlwZSBpcyB1c2VkIHRvIHJlZmVyIHRvIGEgdGltZSBy YW5nZSBvYmplY3QuIjsKICAgICAgICAgdHlwZSBsZWFmcmVmIHsKICAgICAgICAgICAgIHBhdGgg Ii9hY2xzL3RpbWVyYW5nZS1ncm91cHMvdGltZXJhbmdlLWdyb3VwL25hbWUiOwogICAgICAgICB9 CgogICAgIH0KCiAgICAgdHlwZWRlZiB3ZWVrZGF5cyB7CiAgICAgICB0eXBlIGJpdHMgewogICAg ICAgICBiaXQgU3VuZGF5IHsKICAgICAgICAgICBwb3NpdGlvbiAwOwogICAgICAgICB9CiAgICAg ICAgIGJpdCBNb25kYXkgewogICAgICAgICAgIHBvc2l0aW9uIDE7CiAgICAgICAgIH0KICAgICAg ICAgYml0IFR1ZXNkYXkgewogICAgICAgICAgIHBvc2l0aW9uIDI7CiAgICAgICAgIH0KICAgICAg ICAgYml0IFdlZG5lc2RheSB7CiAgICAgICAgICAgcG9zaXRpb24gMzsKICAgICAgICAgfQogICAg ICAgICBiaXQgVGh1cnNkYXkgewogICAgICAgICAgIHBvc2l0aW9uIDQ7CiAgICAgICAgIH0KICAg ICAgICAgYml0IEZyaWRheSB7CiAgICAgICAgICAgcG9zaXRpb24gNTsKICAgICAgICAgfQoKCgpI dWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAg ICAgICBbUGFnZSA0MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNs ICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAgICBiaXQgU2F0dXJkYXkg ewogICAgICAgICAgIHBvc2l0aW9uIDY7CiAgICAgICAgIH0KICAgICAgIH0KICAgICB9CgogICAg IHR5cGVkZWYgYWNsLW5hbWUtc3RyaW5nIHsKICAgICAgIHR5cGUgc3RyaW5nIHsKICAgICAgICAg bGVuZ3RoICIxIC4uIDY0IjsKICAgICAgIH0KICAgICB9CgogICAgIC8qIEdyb3VwaW5ncyAqLwoK ICAgICBncm91cGluZyBBQ0UtQ09NTU9OIHsKICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAg ICAiQSBjb2xsZWN0aW9uIG9mIG5vZGVzIHRoYXQgc2hvdWxkIGJlIGFkZGVkIHRvCiAgICAgICAg ICAgIGV2ZXJ5IEFDRSBsaXN0IGVudHJ5IjsKCiAgICAgICAgIGNvbnRhaW5lciBhY3Rpb25zIHsK ICAgICAgICAgICBsZWFmIGFjdGlvbiB7CiAgICAgICAgICAgICB0eXBlIGFjbDphY2wtYWN0aW9u OwogICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICBkZXNjcmlwdGlvbiAi UGVybWl0L2RlbnkgYWN0aW9uLiI7CiAgICAgICAgICAgfQoKICAgICAgICAgICBsZWFmIGxvZyB7 CiAgICAgICAgICAgIGlmLWZlYXR1cmUgYWNsOmxvZ2dpbmc7CiAgICAgICAgICAgIHR5cGUgZW1w dHk7CiAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgIkNhdXNlcyBhbiBpbmZv cm1hdGlvbmFsIGxvZ2dpbmcgbWVzc2FnZSBhYm91dCB0aGUKICAgICAgICAgICAgICAgcGFja2V0 IHRoYXQgbWF0Y2hlcyB0aGUgZW50cnkgdG8gYmUgc2VudCB0byB0aGUKICAgICAgICAgICAgICAg Y29uc29sZS4iOwogICAgICAgICAgIH0KICAgICAgICAgfQoKICAgICAgICAgbGVhZiBtYXRjaCB7 CiAgICAgICAgICAgaWYtZmVhdHVyZSBhY2w6bWF0Y2gtY291bnRlcjsKICAgICAgICAgICBjb25m aWcgZmFsc2U7CiAgICAgICAgICAgdHlwZSB5YW5nOmNvdW50ZXI2NDsKICAgICAgICAgICBkZXNj cmlwdGlvbgogICAgICAgICAgICAgIlRoZSB0b3RhbCBwYWNrZXQgdGhhdCBoYXZlIG1hdGNoZWQg Zm9yIHRoZQogICAgICAgICAgICAgIHBhcnRpY3VsYXIgQUNFIjsKICAgICAgICAgfQogICAgIH0K CiAgICAgZ3JvdXBpbmcgRklMVEVSLUNPTU1PTiB7CiAgICAgICAgIGRlc2NyaXB0aW9uCgoKCkh1 YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAg ICAgIFtQYWdlIDQxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wg ICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgICAgIkEgY29sbGVjdGlv biBvZiBub2RlcyB0aGF0IHNob3VsZCBiZSBhZGRlZCB0bwogICAgICAgICAgICBldmVyeSAnZmls dGVycycgY29udGFpbmVyIHdpdGhpbiBlYWNoCiAgICAgICAgICAgIEFDRSBsaXN0IGVudHJ5IjsK CiAgICAgICAgIGxlYWYgZW5hYmxlLWNhcHR1cmUgewogICAgICAgICAgICAgaWYtZmVhdHVyZSBh Y2w6cGFja2V0LWNhcHR1cmU7CiAgICAgICAgICAgICB0eXBlIGJvb2xlYW47CiAgICAgICAgICAg ICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAiRW5hYmxlIHBhY2tldCBjYXB0dXJlIG9uIHRo aXMgZmlsdGVyCiAgICAgICAgICAgICAgICBmb3IgdGhpcyBzZXNzaW9uLiI7CiAgICAgICAgIH0K CiAgICAgICAgIGxlYWYgY2FwdHVyZS1zZXNzaW9uLWlkIHsKICAgICAgICAgICAgIGlmLWZlYXR1 cmUgYWNsOmNhcHR1cmUtc2Vzc2lvbi1pZDsKICAgICAgICAgICAgIHdoZW4gIi4uL2VuYWJsZS1j YXB0dXJlID0gJ3RydWUnIjsKICAgICAgICAgICAgIHR5cGUgdWludDMyIHsKICAgICAgICAgICAg ICAgICByYW5nZSAiMS4uNDgiOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgZGVzY3JpcHRp b24KICAgICAgICAgICAgICAgICAiRW5hYmxlIHBhY2tldCBjYXB0dXJlIG9uIHRoaXMgZmlsdGVy CiAgICAgICAgICAgICAgICAgZm9yIHRoaXMgc2Vzc2lvbiBpZC4iOwogICAgICAgICB9CiAgICAg fQoKICAgICAvKiBEYXRhIE5vZGVzICovCgogICAgIGNvbnRhaW5lciBhY2xzIHsKICAgICAgICAg ZGVzY3JpcHRpb24KICAgICAgICAgICAgICJUaGlzIGlzIHRoZSB0b3AgY29udGFpbmVyIHRoYXQg Y29udGFpbnMgYSBsaXN0IG9mCiAgICAgICAgICAgICBuYW1lZCBBQ0wgYW5kIHJldXNhYmxlIGFj bCBvYmplY3QgZ3JvdXBzLiI7CiAgICAgICAgIGxpc3QgYWNsIHsKICAgICAgICAgICAgIGtleSBu YW1lOwogICAgICAgICAgICAgbGVhZiBuYW1lIHsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlv biAiQUNML2FjY2VzcyBncm91cCBuYW1lLiI7CiAgICAgICAgICAgICAgICAgdHlwZSBhY2wtbmFt ZS1zdHJpbmc7CiAgICAgICAgICAgICB9CgogICAgICAgICAgICAgbGVhZiBhY2wtdHlwZSB7CiAg ICAgICAgICAgICAgICAgdHlwZSBhY2wtdHlwZS1yZWY7CiAgICAgICAgICAgICAgICAgZGVzY3Jp cHRpb24gIlR5cGUgb2YgQUNMIjsKICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAg ICAgICAgICAgIH0KICAgICAgICAgICAgIGxlYWYgZW5hYmxlLWNhcHR1cmUtZ2xvYmFsIHsKICAg ICAgICAgICAgICAgICBpZi1mZWF0dXJlIHBhY2tldC1jYXB0dXJlOwogICAgICAgICAgICAgICAg IHR5cGUgYm9vbGVhbjsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiRW5hYmxlIHBhY2tl dCBjYXB0dXJlIG9uIHRoaXMgZmlsdGVyCiAgICAgICAgICAgICAgICAgICAgIGZvciB0aGlzIHNl c3Npb24uIFNlc3Npb24gSUQgcmFuZ2UgaXMgMSB0byA0OCI7CiAgICAgICAgICAgICAgICAgZGVm YXVsdCAiZmFsc2UiOwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA0Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAg ICAgICAgICAgfQogICAgICAgICAgICAgbGVhZiBjYXB0dXJlLXNlc3Npb24taWQtZ2xvYmFsIHsK ICAgICAgICAgICAgICAgICBpZi1mZWF0dXJlIGNhcHR1cmUtc2Vzc2lvbi1pZDsKICAgICAgICAg ICAgICAgICB3aGVuICIuLi9lbmFibGUtY2FwdHVyZS1nbG9iYWwgPSAndHJ1ZSciOwogICAgICAg ICAgICAgICAgIHR5cGUgdWludDMyIHsKICAgICAgICAgICAgICAgICAgICAgcmFuZ2UgIjEuLjQ4 IjsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkVuYWJs ZSBwYWNrZXQgY2FwdHVyZSBvbiB0aGlzIGZpbHRlcgogICAgICAgICAgICAgICAgICAgICBmb3Ig dGhpcyBzZXNzaW9uLiBTZXNzaW9uIElEIHJhbmdlIGlzIDEgdG8gNDgiOwogICAgICAgICAgICAg fQogICAgICAgICAgICAgY2hvaWNlIGVuYWJsZS1tYXRjaC1jb3VudGVyLWNob2ljZXMgewogICAg ICAgICAgICAgICAgIGlmLWZlYXR1cmUgbWF0Y2gtY291bnRlcjsKICAgICAgICAgICAgICAgICBj YXNlIG1hdGNoIHsKICAgICAgICAgICAgICAgICAgICAgbGVhZiBlbmFibGUtbWF0Y2gtY291bnRl ciB7CiAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIGJvb2xlYW47CiAgICAgICAgICAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICJFbmFi bGUgdG8gY29sbGVjdCBzdGF0aXN0aWNzIGZvciB0aGUgQUNMIjsKICAgICAgICAgICAgICAgICAg ICAgICAgIGRlZmF1bHQgZmFsc2U7CiAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAg ICAgICB9CiAgICAgICAgICAgICAgICAgY2FzZSBwZXItZW50cnktbWF0Y2ggewogICAgICAgICAg ICAgICAgICAgICBsZWFmIGVuYWJsZS1wZXItZW50cnktbWF0Y2gtY291bnRlciB7CiAgICAgICAg ICAgICAgICAgICAgICAgICB0eXBlIGJvb2xlYW47CiAgICAgICAgICAgICAgICAgICAgICAgICBk ZXNjcmlwdGlvbiAiRW5hYmxlIHRvIGNvbGxlY3QgbWF0Y2gKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdGF0aXN0aWNzIGZvciBlYWNoIEFDTCBlbnRyeShBQ0UpLiI7CiAgICAgICAgICAg ICAgICAgICAgICAgICBkZWZhdWx0IGZhbHNlOwogICAgICAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICAgICAgfQogICAgICAgICAgICAgfQoKICAgICAgICAgICAgIGxlYWYgbWF0Y2ggewog ICAgICAgICAgICAgICAgIGlmLWZlYXR1cmUgbWF0Y2gtY291bnRlcjsKICAgICAgICAgICAgICAg ICBjb25maWcgZmFsc2U7CiAgICAgICAgICAgICAgICAgdHlwZSB5YW5nOmNvdW50ZXI2NDsKICAg ICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAiVGhlIHRvdGFs IHBhY2tldCB0aGF0IGhhdmUgbWF0Y2hlZCBmb3IgdGhlCiAgICAgICAgICAgICAgICAgICAgIHBh cnRpY3VsYXIgYWNjZXNzIGxpc3QiOwogICAgICAgICAgICAgfQoKICAgICAgICAgfQoKICAgICAg ICAgY29udGFpbmVyIHBvcnQtZ3JvdXBzIHsKICAgICAgICAgICAgIGlmLWZlYXR1cmUgcG9ydC1n cm91cHM7CiAgICAgICAgICAgICBsaXN0IHBvcnQtZ3JvdXAgewogICAgICAgICAgICAgICAgIGtl eSAibmFtZSI7CiAgICAgICAgICAgICAgICAgbGVhZiBuYW1lIHsKICAgICAgICAgICAgICAgICAg ICAgdHlwZSBhY2wtbmFtZS1zdHJpbmc7CiAgICAgICAgICAgICAgICAgfQoKCgpIdWFuZywgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFn ZSA0M10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAg ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAgICAgICAgICAgIGxpc3QgcG9ydC1ncm91 cC1lbnRyeSB7CiAgICAgICAgICAgICAgICAgICAga2V5ICJuYW1lIjsKICAgICAgICAgICAgICAg ICAgICBvcmRlcmVkLWJ5IHVzZXI7CiAgICAgICAgICAgICAgICAgICAgbGVhZiBuYW1lIHsKICAg ICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsLW5hbWUtc3RyaW5nOwogICAgICAgICAgICAgICAg ICAgICB9CiAgICAgICAgICAgICAgICAgICAgIC8vdW5pcXVlICJjb21wYXJhdG9yIHBvcnQtbnVt YmVyCiAgICAgICAgICAgICAgICAgICAgIC8vcG9ydC1sb3dlciBwb3J0LXVwcGVyIjsKCiAgICAg ICAgICAgICAgICAgICAgIGNob2ljZSBwb3J0LW51bWJlci1vci1yYW5nZSB7CiAgICAgICAgICAg ICAgICAgICAgICAgY2FzZSBwb3J0LW51bWJlci1yYW5nZSB7CiAgICAgICAgICAgICAgICAgICAg ICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICJQb3J0IGdyb3VwIGlu Y2x1ZGVzIGFsbCBwb3J0cyBiZXR3ZWVuCiAgICAgICAgICAgICAgICAgICAgICAgICAgcG9ydC1s b3dlcmFuZCBwb3J0LXVwcGVyIChpbmNsdWRpbmcgdGhvc2UpIjsKICAgICAgICAgICAgICAgICAg ICAgICAgIGxlYWYgcG9ydC1sb3dlciB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUg aW5ldDpwb3J0LW51bWJlcjsKICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24g Ikxvd2VyIFBvcnQgbnVtYmVyLiI7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9y eSB0cnVlOwogICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICAg ICAgbGVhZiBwb3J0LXVwcGVyIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBpbmV0 OnBvcnQtbnVtYmVyOwogICAgICAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiVXBw ZXIgUG9ydCBudW1iZXIuIjsKICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRy dWU7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIG11c3QgIi4uL3BvcnQtbG93ZXIgPD0gLi4v cG9ydC11cHBlciI7CiAgICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAg ICAgICAgfQogICAgICAgICAgICAgICAgICAgICAgIGNhc2UgcG9ydC1udW1iZXIgewogICAgICAg ICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgIlBv cnQgZ3JvdXAgaW5jbHVkZXMgYWxsIHBvcnRzIHRoYXQgYXJlIGdyZWF0ZXIKICAgICAgICAgICAg ICAgICAgICAgICAgICB0aGFuLCBncmVhdGVyIG9yIGVxdWFsLCBsZXNzIHRoYW4sIGxlc3Mgb3IK ICAgICAgICAgICAgICAgICAgICAgICAgICBlcXVhbCwgb3Igbm90IGVxdWFsIHRoZSBwb3J0LCBw ZXIgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgaW5kaWNhdGVkIGNvbXBhcmF0b3IuCiAg ICAgICAgICAgICAgICAgICAgICAgICAgSXQgaXMgcG9zc2libGUgZm9yIHRoZSBwb3J0IGdyb3Vw IHRvIGJlIGVtcHR5CiAgICAgICAgICAgICAgICAgICAgICAgICAgKGZvciBleGFtcGxlLCBpbiBj YXNlIGEgcG9ydCBncm91cCB0aGF0CiAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgbGVzcyB0 aGFuIHRoZSBtaW5pbXVtIHBvcnQgbnVtYmVyIGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAg c3BlY2lmaWVkKS4iOwogICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGNvbXBhcmF0b3Igewog ICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsLWNvbXBhcmF0b3I7CiAgICAgICAgICAg ICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgICAgICAgIH0K ICAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBwb3J0IHsKICAgICAgICAgICAgICAgICAgICAg ICAgICB0eXBlIGluZXQ6cG9ydC1udW1iZXI7CiAgICAgICAgICAgICAgICAgICAgICAgICAgZGVz Y3JpcHRpb24gIlBvcnQgbnVtYmVyLiI7CiAgICAgICAgICAgICAgICAgICAgICAgICAgbWFuZGF0 b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAg IH0KICAgICAgICAgICAgICAgICAgICB9IC8vIGNob2ljZSBwb3J0LW51bWJlci1vci1yYW5nZQog ICAgICAgICAgICAgICAgICB9ICAvLyBsaXN0IHBvcnQtZ3JvdXAtZW50cnkKCgoKSHVhbmcsIGV0 IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1Bh Z2UgNDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAg ICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgIH0gIC8vIGxpc3QgcG9ydC1n cm91cAogICAgICAgICB9ICAvLyBjb250YWluZXIgcG9ydC1ncm91cHMKCiAgICAgICAgIGNvbnRh aW5lciB0aW1lcmFuZ2UtZ3JvdXBzIHsKICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJEZWZpbmUg dGltZSByYW5nZSBlbnRyaWVzIHRvIHJlc3RyaWN0CiAgICAgICAgICAgICAgICAgdGhlIGFjY2Vz cy4gVGhlIHRpbWUgcmFuZ2UgaXMgaWRlbnRpZmllZCBieSBhIG5hbWUKICAgICAgICAgICAgICAg ICBhbmQgdGhlbiByZWZlcmVuY2VkIGJ5IGEgZnVuY3Rpb24sIHNvIHRoYXQgdGhvc2UKICAgICAg ICAgICAgICAgICB0aW1lIHJlc3RyaWN0aW9ucyBhcmUgaW1wb3NlZCBvbiB0aGUgZnVuY3Rpb24g aXRzZWxmLiI7CiAgICAgICAgICAgICBsaXN0IHRpbWVyYW5nZS1ncm91cCB7CiAgICAgICAgICAg ICAgICAga2V5ICJuYW1lIjsKICAgICAgICAgICAgICAgICBsZWFmIG5hbWUgewogICAgICAgICAg ICAgICAgICAgICB0eXBlIGFjbC1uYW1lLXN0cmluZzsKICAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICAgICAgbGlzdCB0aW1lLXJhbmdlIHsKICAgICAgICAgICAgICAgICAgIGtleSAibmFt ZSI7CiAgICAgICAgICAgICAgICAgICBvcmRlcmVkLWJ5IHVzZXI7CiAgICAgICAgICAgICAgICAg ICBsZWFmIG5hbWUgewogICAgICAgICAgICAgICAgICAgICB0eXBlIGFjbC1uYW1lLXN0cmluZzsK ICAgICAgICAgICAgICAgICAgIH0KCiAgICAgICAgICAgICAgICAgICBsZWFmIHJlbWFyayB7CiAg ICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsLXJlbWFyazsKICAgICAgICAgICAgICAgICAgIH0K CiAgICAgICAgICAgICAgICAgICBjaG9pY2UgcmFuZ2UtdHlwZSB7CiAgICAgICAgICAgICAgICAg ICAgIC8vIGFib3NvbHV0ZSBvciBwZXJpb2RpYyB0aW1lIHJhbmdlCiAgICAgICAgICAgICAgICAg ICAgIGNvbnRhaW5lciBhYnNvbHV0ZSB7CiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9u CiAgICAgICAgICAgICAgICAgICAgICAgIkFic29sdXRlIHRpbWUgYW5kIGRhdGUgdGhhdAogICAg ICAgICAgICAgICAgICAgICAgICB0aGUgYXNzb2NpYXRlZCBmdW5jdGlvbiBzdGFydHMKICAgICAg ICAgICAgICAgICAgICAgICAgZ29pbmcgaW50byBlZmZlY3QuIjsKICAgICAgICAgICAgICAgICAg ICAgbGVhZiBzdGFydCB7CiAgICAgICAgICAgICAgICAgICAgICAgdHlwZSB5YW5nOmRhdGUtYW5k LXRpbWU7CiAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAg ICAgICAgICAgICJBYnNvbHV0ZSBzdGFydCB0aW1lIGFuZCBkYXRlIjsKICAgICAgICAgICAgICAg ICAgICAgfQogICAgICAgICAgICAgICAgICAgICBsZWFmIGVuZCB7CiAgICAgICAgICAgICAgICAg ICAgICAgdHlwZSB5YW5nOmRhdGUtYW5kLXRpbWU7CiAgICAgICAgICAgICAgICAgICAgICAgZGVz Y3JpcHRpb24gIkFic29sdXRlIGVuZCB0aW1lIGFuZCBkYXRlIjsKICAgICAgICAgICAgICAgICAg ICAgfQogICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgY29udGFpbmVyIHBl cmlvZGljIHsKICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAg ICAgICAgICAiVG8gc3BlY2lmeSBhIHBlcmlvZGljIHRpbWUgYW5kIGRhdGUuIjsKICAgICAgICAg ICAgICAgICAgICAgbGVhZiB3ZWVrZGF5cyB7CiAgICAgICAgICAgICAgICAgICAgICAgdHlwZSB3 ZWVrZGF5czsKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICBsZWFm IHN0YXJ0IHsKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAy MDEzICAgICAgICAgICAgICAgW1BhZ2UgNDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAg ICAgICAgICAgICAgICB0eXBlIHlhbmc6dGltZXN0YW1wOwogICAgICAgICAgICAgICAgICAgICAg IGRlc2NyaXB0aW9uICJTdGFydCB0aW1lIjsKICAgICAgICAgICAgICAgICAgICAgfQogICAgICAg ICAgICAgICAgICAgICBsZWFmIGVuZCB7CiAgICAgICAgICAgICAgICAgICAgICAgdHlwZSB5YW5n OnRpbWVzdGFtcDsKICAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiRW5kIHRpbWUi OwogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAg ICAgICAgfSAvLyBjaG9pY2UgcmFuZ2UtdHlwZQogICAgICAgICAgICAgICB9IC8vIGxpc3QgdGlt ZS1yYW5nZQogICAgICAgICAgICAgfSAvLyBsaXN0IHRpbWVyYW5nZS1ncm91cAogICAgICAgICB9 ICAvLyBjb250YWluZXIgdGltZXJhbmdlLWdyb3VwcwoKICAgICAgICAgY29udGFpbmVyIGlwLWFk ZHJlc3MtZ3JvdXBzIHsKICAgICAgICAgICAgIGlmLWZlYXR1cmUgaXAtYWRkcmVzcy1ncm91cHM7 CiAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICJUaGlzIGNvbnRhaW5z IGEgbGlzdCBvZiBuYW1lZCBpcCBhZGRyZXNzIGdyb3VwLiBFYWNoCiAgICAgICAgICAgICAgICAg Z3JvdXAgZGVmaW5lcyBhIHJhbmdlIG9mIGFkZHJlc3MgYW5kIG1hc2sgcGFpci4iOwogICAgICAg ICAgICAgbGlzdCBpcC1hZGRyZXNzLWdyb3VwIHsKICAgICAgICAgICAgICAgICBrZXkgIm5hbWUi OwogICAgICAgICAgICAgICAgIGxlYWYgbmFtZSB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUg YWNsLW5hbWUtc3RyaW5nOwogICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBsZWFm IGFmaSB7CiAgICAgICAgICAgICAgICAgICAgIGRlZmF1bHQgImlwdjQiOwogICAgICAgICAgICAg ICAgICAgICB0eXBlIGluZXQ6aXAtdmVyc2lvbjsKICAgICAgICAgICAgICAgICAgICAgZGVzY3Jp cHRpb24gIkFkZHJlc3MgRmllbGQgSWRlbnRpZmllciAoQUZJKS4iOwogICAgICAgICAgICAgICAg IH0KICAgICAgICAgICAgICAgICBsaXN0IGlwLWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAg a2V5ICJuYW1lIjsKICAgICAgICAgICAgICAgICAgIG9yZGVyZWQtYnkgdXNlcjsKICAgICAgICAg ICAgICAgICAgIGxlYWYgbmFtZSB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsLW5hbWUt c3RyaW5nOwogICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgLy91bmlxdWUg ImlwLWFkZHJlc3MgaXAtbWFzayI7CiAgICAgICAgICAgICAgICAgICAvL3VuaXF1ZSAiaXAtaG9z dC1hZGRyZXNzIjsKCiAgICAgICAgICAgICAgICAgICBncm91cGluZyBJUC1IT1NUIHsKICAgICAg ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAgICAgICAiQ2hvaWNl IHdpdGhpbiBhIGNhc2Ugbm90IGFsbG93ZWQgc28gbmVlZAogICAgICAgICAgICAgICAgICAgICAg ICB0aGlzIGdyb3VwaW5nLiI7CiAgICAgICAgICAgICAgICAgICAgIGNob2ljZSBhZGRyZXNzLW9y LW5hbWUgewogICAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAg ICAgICAgICAgICAgIGxlYWYgaXAtaG9zdC1hZGRyZXNzIHsKICAgICAgICAgICAgICAgICAgICAg ICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOwogICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgICAgICAgICBsZWFmIGlwLWhvc3QtbmFtZSB7CiAgICAgICAgICAgICAgICAgICAg ICAgICBpZi1mZWF0dXJlIGFjbDpob3N0LWJ5LW5hbWU7CgoKCkh1YW5nLCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDQ2XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAg RmVicnVhcnkgMjAxMwoKCiAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIGluZXQ6ZG9tYWlu LW5hbWU7CiAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgICAgICB9CiAg ICAgICAgICAgICAgICAgICB9CgogICAgICAgICAgICAgICAgICAgY2hvaWNlIGlwLW5ldHdvcmst a2luZCB7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwoKICAgICAgICAgICAg ICAgICAgICAgY2FzZSBpcCB7CiAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBpcC1hZGRyZXNz IHsKICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOwogICAgICAg ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGlwLW1hc2sgewog ICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBpbmV0OmlwLXByZWZpeDsKICAgICAgICAgICAg ICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgICAgICAgICAgICAgICB9CiAg ICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgbGVhZiBpcC1hbnkgewog ICAgICAgICAgICAgICAgICAgICAgIHR5cGUgZW1wdHk7CiAgICAgICAgICAgICAgICAgICAgICAg ZGVzY3JpcHRpb24gIlRvIGV4cHJlc3MgQW55IG5ldHdvcmsgb3IgYWRkcmVzcy4KICAgICAgICAg ICAgICAgICAgICAgICAgIFVzZSB0aGUgYW55IGtleXdvcmQgYXMgYW4gYWJicmV2aWF0aW9uCiAg ICAgICAgICAgICAgICAgICAgICAgICBmb3IgYW4gYWRkcmVzcyBhbmQgYSBtYXNrIG9mIDAuMC4w LjAKICAgICAgICAgICAgICAgICAgICAgICAgIDI1NS4yNTUuMjU1LjI1NS4gRm9yIGV4YW1wbGU6 CiAgICAgICAgICAgICAgICAgICAgICAgICAwLjAuMC4wLzI1NS4yNTUuMjU1LjI1NSBtZWFucyAn YW55JyI7CiAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgY2FzZSBo b3N0IHsKICAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAg ICAgICAgICAgIlVzZSB0aGUgaG9zdCBhZGRyZXNzIGNvbWJpbmF0aW9uIGFzIGFuCiAgICAgICAg ICAgICAgICAgICAgICAgICAgYWJicmV2aWF0aW9uIGZvciBhbiBhZGRyZXNzIGFuZCB3aWxkY2Fy ZAogICAgICAgICAgICAgICAgICAgICAgICAgIG9mIGFkZHJlc3MgMC4wLjAuMCI7CgogICAgICAg ICAgICAgICAgICAgICAgIHVzZXMgSVAtSE9TVDsKICAgICAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgICAgICAgICAvLyBjYXNlIGdyb3VwIG5vdCBhbGxvd2VkIGhlcmUhCiAgICAgICAg ICAgICAgICAgICB9CgogICAgICAgICAgICAgICAgIH0gIC8vIGxpc3QgaXAtYWRkcmVzcwogICAg ICAgICAgICAgfSAgLy8gbGlzdCBpcC1hZGRyZXNzLWdyb3VwCiAgICAgICAgIH0gLy8gY29udGFp bmVyIGlwLWFkZHJlc3MtZ3JvdXBzCiAgICAgfSAvLyBjb250YWluZXIgYWNscwoKIH0KIDxDT0RF IEVORFM+CgoKCgoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5 LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKMTEuICBB Q0wtSVAgWUFORyBNb2R1bGUKCiAgIFRoaXMgbW9kdWxlIGltcG9ydHMgdHlwZSBkZWZpbml0aW9u cyBmcm9tIFtSRkM2MDIxXSBhbmQgY29tbW9uLXR5cGVzCiAgIHlhbmcgZGVmaW5lZCB3aXRoIGFj bCBtb2RlbC4KCiA8Q09ERSBCRUdJTlM+IGZpbGUgImFjbC1pcEAyMDEyLTEwLTEyLnlhbmciCiBt b2R1bGUgYWNsLWlwIHsKICAgICBuYW1lc3BhY2UgInVybjpjaXNjbzpwYXJhbXM6eG1sOm5zOnlh bmc6YWNsLWlwIjsKICAgICAvLyByZXBsYWNlIHdpdGggSUFOQSBuYW1lc3BhY2Ugd2hlbiBhc3Np Z25lZAogICAgIHByZWZpeCBhY2wtaXA7CgogICAgIGltcG9ydCBhY2wgewogICAgICAgICBwcmVm aXggYWNsOwogICAgIH0KICAgICBpbXBvcnQgaWV0Zi1pbmV0LXR5cGVzIHsKICAgICAgICAgcHJl Zml4ICJpbmV0IjsKICAgICB9CiAgICAgaW1wb3J0IGNvbW1vbi10eXBlcyB7CiAgICAgICAgIHBy ZWZpeCAiYy10eXBlcyI7CiAgICAgfQoKICAgICBvcmdhbml6YXRpb24KICAgICAgICAiSUVURiBO RVRNT0QgKE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSkgV29ya2luZyBHcm91cCI7Cgog ICAgIGNvbnRhY3QKICAgICAgICAgICJXRyBXZWI6IGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9u ZXRtb2QvCiAgICAgICAgIFdHIExpc3Q6IG5ldG1vZEBpZXRmLm9yZwoKICAgICAgICAgV0cgQ2hh aXI6IERhdmlkIEtlc3NlbnMKICAgICAgICAgZGF2aWQua2Vzc2Vuc0Buc24uY29tCgogICAgICAg ICBXRyBDaGFpcjogSnVlcmdlbiBTY2hvZW53YWVsZGVyCiAgICAgICAgIGouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZQoKICAgICAgICAgRWRpdG9yOiBMaXNhIEh1YW5nCiAgICAg ICAgIHlpaHVhbkBjaXNjby5jb20KCiAgICAgICAgIEVkaXRvcjogQWxleGFuZGVyIENsZW1tCiAg ICAgICAgIGFsZXhAY2lzY28uY29tCgogICAgICAgICBFZGl0b3I6IEFuZHkgQmllcm1hbgogICAg ICAgICBhbmR5QHl1bWF3b3Jrcy5jb20iOwoKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgIlRo aXMgWUFORyBtb2R1bGUgYXVnbWVudHMgdGhlICdhY2wnIG1vZHVsZSB3aXRoIGNvbmZpZ3VyYXRp b24KICAgICAgICAgYW5kIG9wZXJhdGlvbmFsIGRhdGEgZm9yIElQdjQgYW5kIElQdjYgYWNjZXNz IGNvbnRyb2wgbGlzdC4KCiAgICAgICAgIEFuIEFDTCBpcyBhbiBvcmRlcmVkIHNldCBvZiBydWxl cyBhbmQgYWN0aW9ucyB1c2VkIHRvIGZpbHRlcgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA0OF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1 YXJ5IDIwMTMKCgogICAgICAgICB0cmFmZmljLgogICAgICAgICBFYWNoIHNldCBvZiBydWxlcyBh bmQgYWN0aW9ucyBpcyByZXByZXNlbnRlZCBhcyBhbiBBY2Nlc3MKICAgICAgICAgQ29udHJvbCBF bnRyaWVzIChBQ0UpLiBFYWNoIEFDRSBpcyBldmFsdWF0ZWQgc2VxdWVudGlhbGx5LgogICAgICAg ICBXaGVuIHRoZSBydWxlIG1hdGNoZXMgdGhlbiBhY3Rpb24gZm9yIHRoYXQgcnVsZSBpcyBhcHBs aWVkCiAgICAgICAgIHRvIHRoZSBwYWNrZXQuCgogICAgICAgICBJUCBBQ0xzIGFyZSBvcmRlcmVk IHNldHMgb2YgcnVsZXMgdGhhdCBjYW4gdXNlIHRvCiAgICAgICAgIGZpbHRlciB0cmFmZmljIGJh c2VkIG9uIElQIGluZm9ybWF0aW9uIGluIHRoZSBMYXllciAzIGhlYWRlcgogICAgICAgICBvZiBw YWNrZXRzLgogICAgICAgICBUaGUgZGV2aWNlIGFwcGxpZXMgSVAgQUNMcyBvbmx5IHRvIElQIHRy YWZmaWMuIElQIEFDTAogICAgICAgICBjYW4gYmUgSVB2NCBvciBJUHY2LgoKICAgICAgICAgVGVy bXMgYW5kIEFjcm9ueW1zCiAgICAgICAgICBBQ0UgKGFjZSk6IEFjY2VzcyBDb250cm9sIEVudHJ5 CgogICAgICAgICAgQUNMIChhY2wpOiBBY2Nlc3MgQ29udHJvbCBMaXN0CgogICAgICAgICAgQUZJ IChhZmkpOiBBdXRob3JpdHkgYW5kIEZvcm1hdCBJZGVudGlmaWVyIChBZGRyZXNzIEZpZWxkCiAg ICAgICAgICAgICAgSWRlbnRpZmllcikKCiAgICAgICAgICBEU0NQIChkc2NwKTogRGlmZmVyZW50 aWF0ZWQgU2VydmljZXMgQ29kZSBQb2ludAoKICAgICAgICAgIElDTVAgKGljbXApOiBJbnRlcm5l dCBDb250cm9sIE1lc3NhZ2UgUHJvdG9jb2wKCiAgICAgICAgICBJR01QIChpZ21wKTogSW50ZXJu ZXQgR3JvdXAgTWFuYWdlbWVudCBQcm90b2NvbAoKICAgICAgICAgIElQIChpcCk6IEludGVybmV0 IFByb3RvY29sCgogICAgICAgICAgSVB2NCAoaXB2NCk6SW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lv biA0CgogICAgICAgICAgSVB2NiAoaXB2Nik6IEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNgoK ICAgICAgICAgIFFvUzogUXVhbGl0eSBvZiBTZXJ2aWNlCgogICAgICAgICAgVENQICh0Y3ApOiBU cmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbAoKICAgICAgICAgIFRvUyAodG9zKTogVHlwZSBv ZiBTZXJ2aWNlCgogICAgICAgICAgVFRMICh0dGwpOiBUaW1lIHRvIExpdmUKCiAgICAgICAgICBV RFAgKHVkcCk6IFVzZXIgRGF0YWdyYW0gUHJvdG9jb2wKCiAgICAgICAgICBWTEFOICh2bGFuKTog VmlydHVhbCBMb2NhbCBBcmVhIE5ldHdvcmsKCiAgICAgICAgICBWUkYodnJmKSA6IFZpcnR1YWwg Um91dGluZyBhbmQgRm9yd2FyZGluZwogICAgICAgICI7CiAgICAgcmVmZXJlbmNlCiAgICAgICAg ICJBY2Nlc3MgTGlzdCBDb21tYW5kcyBvbiBDaXNjbyBJT1MgWFIgU29mdHdhcmUsCgoKCkh1YW5n LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAg IFtQYWdlIDQ5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAg ICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgIENpc2NvIE5leHVzIDcwMDAg U2VyaWVzIE5YLU9TIFNlY3VyaXR5IENvbmZpZ3VyYXRpb24gR3VpZGUsCiAgICAgICAgIENhdGFs eXN0IDY1MDAgUmVsZWFzZSAxMi4yU1ggU29mdHdhcmUgQ29uZmlndXJhdGlvbiBHdWlkZSwKICAg ICAgICAgQUNMIFRDUCBGbGFncyBGaWx0ZXJpbmciOwoKICAgICByZXZpc2lvbiAyMDEyLTEwLTEy IHsKICAgICAgICAgZGVzY3JpcHRpb24gIkluaXRpYWwgcmV2aXNpb24uICI7CiAgICAgfQoKICAg ICAvKiBGZWF0dXJlcyAqLwoKICAgICBmZWF0dXJlIHRpbWUtdG8tbGl2ZSB7CiAgICAgICAgIGRl c2NyaXB0aW9uICJUaGUgYWJpbGl0eSB0byBmaWx0ZXIgcGFja2V0cyBiYXNlZCBvbiB0aGVpcgog ICAgICAgICB0aW1lLXRvLWxpdmUgKFRUTCkgdmFsdWUgKDAgdG8gMjU1KSI7CiAgICAgICAgIHJl ZmVyZW5jZSAiQUNMIFN1cHBvcnQgZm9yIEZpbHRlcmluZyBvbiBUVEwgVmFsdWUiOwogICAgIH0K CiAgICAgZmVhdHVyZSBmbG93LWxhYmVsIHsKICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAg ICAgICJUaGUgYWJpbGl0eSB0byBmaWx0ZXIgcGFja2V0cyBiYXNlZCBvbiBmbG93IGxhYmxlLgog ICAgICAgICAgICAgVGhlIDIwLWJpdCBGbG93IExhYmVsIGZpZWxkIGluIHRoZSBJUHY2IGhlYWRl cgogICAgICAgICAgICAgaXMgdXNlZCBieSBhIHNvdXJjZSB0byBsYWJlbCBwYWNrZXRzCiAgICAg ICAgICAgICBvZiBhIGZsb3cuIFRoaXMgaXMgYW4gSVB2NiBBQ0VzIG9wdGlvbi4iOwogICAgICAg ICByZWZlcmVuY2UgIlJGQyAzNjk3IElQdjYgRmxvdyBMYWJlbCBTcGVjaWZpY2F0aW9uIjsKICAg ICB9CgoKICAgICAvKiBJZGVudGl0aWVzICovCgogICAgIGlkZW50aXR5IGlwLWFjbCB7CiAgICAg ICAgIGJhc2UgImFjbDphY2wtdHlwZSI7CiAgICAgICAgIGRlc2NyaXB0aW9uICJsYXllciAzIEFD TCB0eXBlIjsKICAgICB9CgogICAgIC8qIEdyb3VwaW5ncyAqLwoKICAgICBncm91cGluZyBJUC1T T1VSQ0UtTkVUV09SSyB7CiAgICAgICAgIGRlc2NyaXB0aW9uICJSZXVzYWJsZSBJUCBhZGRyZXNz IGFuZCBtYXNrIHBhaXIuIjsKCiAgICAgICAgIGdyb3VwaW5nIElQLVNPVVJDRS1IT1NUIHsKICAg ICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICJDaG9pY2Ugd2l0aGluIGEgY2Fz ZSBub3QgYWxsb3dlZCBzbyBuZWVkCiAgICAgICAgICAgICAgICB0aGlzIGdyb3VwaW5nLiI7CiAg ICAgICAgICAgICBjaG9pY2UgaXAtc3JjLWFkZHJlc3Mtb3ItbmFtZSB7CiAgICAgICAgICAgICAg ICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgbGVhZiBpcC1zb3VyY2UtaG9zdC1h ZGRyZXNzIHsKICAgICAgICAgICAgICAgICAgICB0eXBlIGluZXQ6aXAtYWRkcmVzczsKICAgICAg ICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgbGVhZiBpcC1zb3VyY2UtaG9zdC1uYW1lIHsK CgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAg ICAgICAgICAgW1BhZ2UgNTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5n LWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAgICAg ICBpZi1mZWF0dXJlIGFjbDpob3N0LWJ5LW5hbWU7CiAgICAgICAgICAgICAgICAgICAgdHlwZSBp bmV0OmRvbWFpbi1uYW1lOwogICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgIH0KICAgICAg ICAgfQoKICAgICAgICAgY2hvaWNlIHNvdXJjZS1hZGRyZXNzLWhvc3QtZ3JvdXAgewogICAgICAg ICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICBjYXNlIHNvdXJjZS1pcCB7CiAgICAg ICAgICAgICAgICAgZGVzY3JpcHRpb24gIlVzZWQgd2l0aCBhZGRyZXNzIGFuZCBtYXNrIGNvdXBs ZQogICAgICAgICAgICAgICAgICAgICB0byBleHByZXNzIG5ldHdvcmsuIjsKCiAgICAgICAgICAg ICAgICAgbGVhZiBpcC1zb3VyY2UtYWRkcmVzcyB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUg aW5ldDppcC1hZGRyZXNzOwogICAgICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAg ICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgbGVhZiBpcC1zb3VyY2UtbWFzayB7CiAg ICAgICAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOwogICAgICAgICAgICAgICAg ICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICB9CiAg ICAgICAgICAgICBsZWFmIGlwLXNvdXJjZS1hbnkgewogICAgICAgICAgICAgICAgIHR5cGUgZW1w dHk7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIlRvIGV4cHJlc3MgQW55IG5ldHdvcmsg b3IgYWRkcmVzcy4KICAgICAgICAgICAgICAgICAgICAgVXNlIHRoZSBhbnkga2V5d29yZCBhcyBh biBhYmJyZXZpYXRpb24KICAgICAgICAgICAgICAgICAgICAgZm9yIGFuIGFkZHJlc3MgYW5kIGEg bWFzayBvZiAwLjAuMC4wCiAgICAgICAgICAgICAgICAgICAgIDI1NS4yNTUuMjU1LjI1NS4gRm9y IGV4YW1wbGU6CiAgICAgICAgICAgICAgICAgICAgIDAuMC4wLjAvMjU1LjI1NS4yNTUuMjU1IG1l YW5zICdhbnknIjsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGNhc2Ugc291cmNlLWhvc3Qg ewogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJVc2VkIHdpdGggaG9zdCBhZGRyZXNzIHRv IGV4cHJlc3MgYQogICAgICAgICAgICAgICAgICAgICBzaW5nbGUgaG9zdAogICAgICAgICAgICAg ICAgICAgICBVc2UgdGhlIGhvc3QgYWRkcmVzcyhvciBuYW1lKQogICAgICAgICAgICAgICAgICAg ICBjb21iaW5hdGlvbiBpcyB0aGUgc2FtZSBhcyBhbiBhZGRyZXNzCiAgICAgICAgICAgICAgICAg ICAgIGFuZCBtYXNrIG9mIGFkZHJlc3MgMC4wLjAuMC4KICAgICAgICAgICAgICAgICAgICAgRm9y IGV4YW1wbGU6ICcxMC4xLjEuMi8wLjAuMC4wJyBpcyB0aGUgc2FtZQogICAgICAgICAgICAgICAg ICAgICBhcyAnaG9zdCAxMC4xLjEuMiciOwogICAgICAgICAgICAgICAgIHVzZXMgSVAtU09VUkNF LUhPU1Q7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBjYXNlIHNvdXJjZS1ncm91cCB7CiAg ICAgICAgICAgICAgICAgaWYtZmVhdHVyZSBhY2w6aXAtYWRkcmVzcy1ncm91cHM7CiAgICAgICAg ICAgICAgICAgbGVhZiBpcC1zb3VyY2UtZ3JvdXAgIHsKICAgICAgICAgICAgICAgICAgICAgdHlw ZSBhY2w6aXAtYWRkcmVzcy1ncm91cC1yZWY7CiAgICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgfQogICAgICAgICB9CiAgICAgfQoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGly ZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNTFdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAy MDEzCgoKICAgICBncm91cGluZyBJUC1ERVNUSU5BVElPTi1ORVRXT1JLIHsKICAgICAgICAgZGVz Y3JpcHRpb24KICAgICAgICAgICAgICJSZXVzYWJsZSBJUCBhZGRyZXNzIGFuZCBtYXNrIHBhaXIg Zm9yIGRlc3RpbmF0aW9uLiI7CgogICAgICAgICBncm91cGluZyBJUC1ERVNUSU5BVElPTi1IT1NU IHsKICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICJDaG9pY2Ugd2l0aGlu IGEgY2FzZSBub3QgYWxsb3dlZCBzbyBuZWVkCiAgICAgICAgICAgICAgICB0aGlzIGdyb3VwaW5n LiI7CiAgICAgICAgICAgICBjaG9pY2UgaXAtZGVzdC1hZGRyZXNzLW9yLW5hbWUgewogICAgICAg ICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgICAgIGxlYWYgaXAtZGVzdC1o b3N0LWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOwog ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBsZWFmIGlwLWRlc3QtaG9zdC1uYW1l IHsKICAgICAgICAgICAgICAgICAgICBpZi1mZWF0dXJlIGFjbDpob3N0LWJ5LW5hbWU7CiAgICAg ICAgICAgICAgICAgICAgdHlwZSBpbmV0OmRvbWFpbi1uYW1lOwogICAgICAgICAgICAgICAgIH0K ICAgICAgICAgICAgIH0KICAgICAgICAgfQoKICAgICAgICAgY2hvaWNlIGRlc3QtYWRkcmVzcy1o b3N0LWdyb3VwIHsKICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgY2Fz ZSBkZXN0LWlwIHsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiVXNlZCB3aXRoIGFkZHJl c3MgYW5kIG1hc2sgY291cGxlCiAgICAgICAgICAgICAgICAgICAgIHRvIGV4cHJlc3MgbmV0d29y ay4iOwogICAgICAgICAgICAgICAgIGxlYWYgaXAtZGVzdC1hZGRyZXNzIHsKICAgICAgICAgICAg ICAgICAgICAgdHlwZSBpbmV0OmlwLWFkZHJlc3M7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRh dG9yeSB0cnVlOwogICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBsZWFmIGlwLWRl c3QtbWFzayB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRyZXNzOwogICAg ICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICB9CiAgICAgICAgICAgICBsZWFmIGlwLWRlc3QtYW55IHsKICAgICAgICAgICAgICAg ICB0eXBlIGVtcHR5OwogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUbyBleHByZXNzIEFu eSBuZXR3b3JrIG9yIGFkZHJlc3MuCiAgICAgICAgICAgICAgICAgICAgIFVzZSB0aGUgYW55IGtl eXdvcmQgYXMgYW4gYWJicmV2aWF0aW9uCiAgICAgICAgICAgICAgICAgICAgIGZvciBhbiBhZGRy ZXNzIGFuZCBhIG1hc2sgb2YgMC4wLjAuMAogICAgICAgICAgICAgICAgICAgICAyNTUuMjU1LjI1 NS4yNTUuIEZvciBleGFtcGxlOgogICAgICAgICAgICAgICAgICAgICAwLjAuMC4wLzI1NS4yNTUu MjU1LjI1NSBtZWFucyAnYW55JyI7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBjYXNlIGRl c3QtaG9zdCB7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIlVzZWQgd2l0aCBob3N0IGFk ZHJlc3MgdG8gZXhwcmVzcyBhCiAgICAgICAgICAgICAgICAgICAgIHNpbmdsZSBob3N0CiAgICAg ICAgICAgICAgICAgICAgIFVzZSB0aGUgaG9zdCBhZGRyZXNzKG9yIG5hbWUpCiAgICAgICAgICAg ICAgICAgICAgIGNvbWJpbmF0aW9uIGlzIHRoZSBzYW1lIGFzIGFuIGFkZHJlc3MKICAgICAgICAg ICAgICAgICAgICAgYW5kIG1hc2sgb2YgYWRkcmVzcyAwLjAuMC4wLgoKCgpIdWFuZywgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA1 Ml0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAg ICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAgICAgICAgICAgICAgICBGb3IgZXhhbXBsZTog JzEwLjEuMS4yLzAuMC4wLjAnIGlzIHRoZSBzYW1lCiAgICAgICAgICAgICAgICAgICAgIGFzICdo b3N0IDEwLjEuMS4yJyI7CgogICAgICAgICAgICAgICAgIHVzZXMgSVAtREVTVElOQVRJT04tSE9T VDsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGNhc2UgZGVzdC1ncm91cCB7CiAgICAgICAg ICAgICAgICAgaWYtZmVhdHVyZSBhY2w6aXAtYWRkcmVzcy1ncm91cHM7CiAgICAgICAgICAgICAg ICAgZGVzY3JpcHRpb24gIlVzZSB0aGUgZ3JvdXAga2V5d29yZCBhbmQgZ3JvdXAgbmFtZQogICAg ICAgICAgICAgICAgICAgIHRvIHJlZmVyIHRvIGEgcHJlLWRlZmluZWQgYWRkcmVzcyBvYmplY3Qg Z3JvdXAKICAgICAgICAgICAgICAgICAgICB3aGljaCBpcyBhIGxpc3Qgb2YgYWRkcmVzcyBhbmQg bWFzay4iOwoKICAgICAgICAgICAgICAgICBsZWFmIGlwLWRlc3QtZ3JvdXAgewogICAgICAgICAg ICAgICAgICAgICB0eXBlIGFjbDppcC1hZGRyZXNzLWdyb3VwLXJlZjsKICAgICAgICAgICAgICAg ICB9CiAgICAgICAgICAgICB9CiAgICAgICAgIH0KICAgICB9CgogICAgIGdyb3VwaW5nIERTQ1At T1ItVE9TIHsKICAgICAgIGNob2ljZSBkc2NwLW9yLXRvcyB7CiAgICAgICAgIGxlYWYgZHNjcCB7 CiAgICAgICAgICAgdHlwZSBpbmV0OmRzY3A7CiAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAg ICAgICAgICJNYXRjaCBwYWNrZXRzIHdpdGggZ2l2ZW4gZHNjcCB2YWx1ZSI7CiAgICAgICAgIH0K CiAgICAgICAgIGNhc2UgdG9zIHsKICAgICAgICAgICBsZWFmIHRvcyB7CiAgICAgICAgICAgICB0 eXBlIGMtdHlwZXM6dG9zOwogICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAi TWF0Y2ggcGFja2V0cyB3aXRoIGdpdmVuIFRPUyB2YWx1ZSI7CiAgICAgICAgICAgfQogICAgICAg ICAgIGxlYWYgcHJlY2VkZW5jZSB7CiAgICAgICAgICAgICB3aGVuICJib29sZWFuKC4uL3Rvcyki IDsKICAgICAgICAgICAgIHR5cGUgYy10eXBlczpwcmVjZWRlbmNlOwogICAgICAgICAgICAgZGVz Y3JpcHRpb24KICAgICAgICAgICAgICAgIk1hdGNoIHBhY2tldHMgd2l0aCBnaXZlbiBwcmVjZWRl bmNlIHZhbHVlIjsKICAgICAgICAgICB9CiAgICAgICAgIH0KICAgICAgIH0KICAgICB9CgogICAg IGdyb3VwaW5nIElQLUFDRS1GSUxURVJTIHsKICAgICAgICAgbGVhZiBwcm90b2NvbCB7CiAgICAg ICAgICAgICB0eXBlIGMtdHlwZXM6aXAtcHJvdG9jb2w7CiAgICAgICAgICAgICBkZXNjcmlwdGlv biAiSVAgcHJvdG9jb2wgbnVtYmVyLiI7CiAgICAgICAgIH0KCgoKCkh1YW5nLCBldCBhbC4gICAg ICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDUzXQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAg ICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgIHVzZXMgYWNsOkZJTFRFUi1DT01NT047CgogICAg ICAgICBsZWFmIGZyYWdtZW50cyB7CiAgICAgICAgICAgICB0eXBlIGVtcHR5OwogICAgICAgICAg ICAgZGVzY3JpcHRpb24gIkNoZWNrIG5vbi1pbml0aWFsIGZyYWdtZW50cyI7CiAgICAgICAgIH0K CiAgICAgICAgIGxlYWYgdGltZS1yYW5nZSB7CiAgICAgICAgICAgICB0eXBlIGFjbDp0aW1lLXJh bmdlLXJlZjsKICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgIlJlZmVy IGEgdGltZSByYW5nZSBvYmplY3QgYnkKICAgICAgICAgICAgICAgICBuYW1lIChNYXggU2l6ZSA2 NCkuIjsKICAgICAgICAgfQoKICAgICAgICAgY2hvaWNlIHNyYy1wb3J0cyB7CiAgICAgICAgICAg IHdoZW4gInByb3RvY29sID0gJzYnIG9yIHByb3RvY29sID0gJzE3JyBvciAiICsKICAgICAgICAg ICAgICAgICAicHJvdG9jb2wgPSAnMTMyJyI7CgogICAgICAgICAgICAgZGVzY3JpcHRpb24KICAg ICAgICAgICAgICAgIkFwcGx5IG9ubHkgd2hlbiB0aGUgcHJvdG9jb2wgaXMgVENQLAogICAgICAg ICAgICAgICBVRFAgb3IgU0NUUC4iOwoKICAgICAgICAgICAgIGNhc2UgcG9ydC1udW1iZXItcmFu Z2UgewogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgICAgICJQ b3J0IGdyb3VwIGluY2x1ZGVzIGFsbCBwb3J0cyBiZXR3ZWVuIHBvcnQtbG93ZXIKICAgICAgICAg ICAgICAgICAgICAgYW5kIHBvcnQtdXBwZXIgKGluY2x1ZGluZyB0aG9zZSkiOwogICAgICAgICAg ICAgICAgIGxlYWYgc3JjLXBvcnQtbG93ZXIgewogICAgICAgICAgICAgICAgICAgICB0eXBlIGlu ZXQ6cG9ydC1udW1iZXI7CiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJMb3dlciBQ b3J0IG51bWJlci4iOwogICAgICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAg ICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgbGVhZiBzcmMtcG9ydC11cHBlciB7CiAgICAg ICAgICAgICAgICAgICAgIHR5cGUgaW5ldDpwb3J0LW51bWJlcjsKICAgICAgICAgICAgICAgICAg ICAgZGVzY3JpcHRpb24gIlVwcGVyIFBvcnQgbnVtYmVyLiI7CiAgICAgICAgICAgICAgICAgICAg IG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgICAgICAgICBtdXN0ICIuLi9zcmMtcG9ydC1s b3dlciA8PSAuLi9zcmMtcG9ydC11cHBlciI7CiAgICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgfQogICAgICAgICAgICAgY2FzZSBwb3J0LW51bWJlciB7CiAgICAgICAgICAgICAgICAgZGVz Y3JpcHRpb24KICAgICAgICAgICAgICAgICAgICAgIlBvcnQgZ3JvdXAgaW5jbHVkZXMgYWxsIHBv cnRzIHRoYXQgYXJlIGdyZWF0ZXIKICAgICAgICAgICAgICAgICAgICAgdGhhbiwgZ3JlYXRlciBv ciBlcXVhbCwgbGVzcyB0aGFuLCBsZXNzIG9yIGVxdWFsLAogICAgICAgICAgICAgICAgICAgICBv ciBub3QgZXF1YWwgdGhlIHBvcnQsIHBlciB0aGUgaW5kaWNhdGVkCiAgICAgICAgICAgICAgICAg ICAgIGNvbXBhcmF0b3IuICBJdCBpcyBwb3NzaWJsZSBmb3IgdGhlIHBvcnQgZ3JvdXAKICAgICAg ICAgICAgICAgICAgICAgdG8gYmUgZW1wdHkgKGZvciBleGFtcGxlLCBpbiBjYXNlIGEgcG9ydCBn cm91cAogICAgICAgICAgICAgICAgICAgICB0aGF0IGlzIGxlc3MgdGhhbiB0aGUgbWluaW11bSBw b3J0IG51bWJlciBpcwogICAgICAgICAgICAgICAgICAgICBzcGVjaWZpZWQpLiI7CiAgICAgICAg ICAgICAgICAgbGVhZiBzcmMtY29tcGFyYXRvciB7CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAg ICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDU0XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVi cnVhcnkgMjAxMwoKCiAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsOmFjbC1jb21wYXJhdG9y OwogICAgICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICAgICAgbGVhZiBzcmMtcG9ydCB7CiAgICAgICAgICAgICAgICAgICAgIHR5 cGUgaW5ldDpwb3J0LW51bWJlcjsKICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIlBv cnQgbnVtYmVyLiI7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAg ICAgICAgICAgIH0KICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGNhc2UgcG9ydC1ncm91cC1y ZWYgewogICAgICAgICAgICAgICAgIGlmLWZlYXR1cmUgYWNsOnBvcnQtZ3JvdXBzOwogICAgICAg ICAgICAgICAgIGxlYWYgc3JjLXBvcnQtZ3JvdXAtbmFtZSB7CiAgICAgICAgICAgICAgICAgICAg IHR5cGUgYWNsOnBvcnQtZ3JvdXAtcmVmOwogICAgICAgICAgICAgICAgICAgICBtYW5kYXRvcnkg dHJ1ZTsKICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAg ICAgICAgICJSZWZlcmVuY2UgYSBwb3J0IGdyb3VwIGJ5IHRoZSBQb3J0CiAgICAgICAgICAgICAg ICAgICAgICAgICBHcm91cCBuYW1lLiI7CiAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAg fQogICAgICAgICB9ICAvLyBjaG9pY2Ugc3JjLXBvcnRzCgogICAgICAgICBjaG9pY2UgZGVzdC1w b3J0cyB7CiAgICAgICAgICAgICB3aGVuICJwcm90b2NvbCA9ICc2JyBvciBwcm90b2NvbCA9ICcx Nycgb3IgIiArCiAgICAgICAgICAgICAgICAgICJwcm90b2NvbCA9ICcxMzInIjsKICAgICAgICAg ICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgIkFwcGx5IG9ubHkgd2hlbiB0aGUgcHJv dG9jb2wgaXMgVENQLAogICAgICAgICAgICAgICAgIFVEUCBvciBTQ1RQLiI7CgogICAgICAgICAg ICAgY2FzZSBwb3J0LW51bWJlci1yYW5nZSB7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24g IlBvcnQgZ3JvdXAgaW5jbHVkZXMgYWxsIHBvcnRzIGJldHdlZW4KICAgICAgICAgICAgICAgICAg ICAgcG9ydC1sb3dlciBhbmQgcG9ydC11cHBlciAoaW5jbHVkaW5nIHRob3NlKSI7CiAgICAgICAg ICAgICAgICAgbGVhZiBkZXMtcG9ydC1sb3dlciB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUg aW5ldDpwb3J0LW51bWJlcjsKICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkxvd2Vy IFBvcnQgbnVtYmVyLiI7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAg ICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBsZWFmIGRlcy1wb3J0LXVwcGVyIHsKICAg ICAgICAgICAgICAgICAgICAgdHlwZSBpbmV0OnBvcnQtbnVtYmVyOwogICAgICAgICAgICAgICAg ICAgICBkZXNjcmlwdGlvbiAiVXBwZXIgUG9ydCBudW1iZXIuIjsKICAgICAgICAgICAgICAgICAg ICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgICAgIG11c3QgIi4uL2Rlcy1wb3J0 LWxvd2VyIDw9IC4uL2Rlcy1wb3J0LXVwcGVyIjsKICAgICAgICAgICAgICAgICB9CiAgICAgICAg ICAgICB9CiAgICAgICAgICAgICBjYXNlIHBvcnQtbnVtYmVyIHsKICAgICAgICAgICAgICAgICBk ZXNjcmlwdGlvbiAiUG9ydCBncm91cCBpbmNsdWRlcyBhbGwgcG9ydHMgdGhhdAogICAgICAgICAg ICAgICAgICAgICBhcmUgZ3JlYXRlciB0aGFuLCBncmVhdGVyIG9yIGVxdWFsLCBsZXNzIHRoYW4s CiAgICAgICAgICAgICAgICAgICAgIGxlc3Mgb3IgZXF1YWwsIG9yIG5vdCBlcXVhbCB0aGUgcG9y dCwgcGVyIHRoZQogICAgICAgICAgICAgICAgICAgICBpbmRpY2F0ZWQgY29tcGFyYXRvci4gIEl0 IGlzIHBvc3NpYmxlIGZvciB0aGUKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNTVdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEz CgoKICAgICAgICAgICAgICAgICAgICAgcG9ydCBncm91cCB0byBiZSBlbXB0eSAoZm9yIGV4YW1w bGUsIGluIGNhc2UgYQogICAgICAgICAgICAgICAgICAgICBwb3J0IGdyb3VwIHRoYXQgaXMgbGVz cyB0aGFuIHRoZSBtaW5pbXVtIHBvcnQKICAgICAgICAgICAgICAgICAgICAgbnVtYmVyIGlzIHNw ZWNpZmllZCkuIjsKICAgICAgICAgICAgICAgICBsZWFmIGRlcy1jb21wYXJhdG9yIHsKICAgICAg ICAgICAgICAgICAgICAgdHlwZSBhY2w6YWNsLWNvbXBhcmF0b3I7CiAgICAgICAgICAgICAgICAg ICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBs ZWFmIGRlcy1wb3J0IHsKICAgICAgICAgICAgICAgICAgICAgdHlwZSBpbmV0OnBvcnQtbnVtYmVy OwogICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiUG9ydCBudW1iZXIuIjsKICAgICAg ICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgfQogICAgICAg ICAgICAgfQogICAgICAgICAgICAgY2FzZSBwb3J0LWdyb3VwLXJlZiB7CiAgICAgICAgICAgICAg ICAgaWYtZmVhdHVyZSBhY2w6cG9ydC1ncm91cHM7CiAgICAgICAgICAgICAgICAgbGVhZiBkZXMt cG9ydC1ncm91cC1uYW1lIHsKICAgICAgICAgICAgICAgICAgICAgdHlwZSBhY2w6cG9ydC1ncm91 cC1yZWY7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAg ICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAiUmVmZXJlbmNlIGEgcG9y dCBncm91cCBieSB0aGUgUG9ydCBHcm91cCBuYW1lLiI7CiAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgfQogICAgICAgICB9ICAvLyBjaG9pY2UgZGVzdC1wb3J0cwoKICAgICAgICAgbGVh ZiBpY21wLXR5cGUgewogICAgICAgICAgICAgd2hlbiAiLi4vcHJvdG9jb2wgPSAnMSciOwogICAg ICAgICAgICAgdHlwZSBjLXR5cGVzOmljbXAtdHlwZTsKICAgICAgICAgICAgIGRlc2NyaXB0aW9u CiAgICAgICAgICAgICAgICAgIklDTVAgbWVzc2FnZSB0eXBlIG51bWJlci4KICAgICAgICAgICAg ICAgICBBcHBseSBvbmx5IHdoZW4gdGhlIHByb3RvY29sIGlzIGljbXAiOwogICAgICAgICB9Cgog ICAgICAgICBsZWFmIGljbXAtY29kZSB7CiAgICAgICAgICAgICB3aGVuICJib29sZWFuKC4uL2lj bXAtdHlwZSkgIjsKICAgICAgICAgICAgIHR5cGUgYy10eXBlczppY21wLWNvZGU7CiAgICAgICAg ICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgIklDTVAgc3VidHlwZSBmb3IgYSBnaXZlbiBp Y21wIHR5cGUuIjsKICAgICAgICAgfQoKICAgICAgICAgY2hvaWNlIHBhY2tldC1sZW5ndGgtb3It cmFuZ2UgewogICAgICAgICAgICAgaWYtZmVhdHVyZSBhY2w6cGFja2V0LWxlbmd0aDsKICAgICAg ICAgICAgIGNhc2UgbGVuZ3RoIHsKICAgICAgICAgICAgICAgICBsZWFmIHBhY2tldC1sZW5ndGgt Y29tcGFyYXRvciB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsOmFjbC1jb21wYXJhdG9y OwogICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAg ICAgIk9wZXJhbnQgdGhhdCBjb21wYXJlIHRoZSBwYWNrZXQKICAgICAgICAgICAgICAgICAgICAg ICAgIGxlbmd0aC4gT3BlcmFuZHMgYXJlIGx0IChsZXNzIHRoYW4pLAogICAgICAgICAgICAgICAg ICAgICAgICAgZ3QgKGdyZWF0ZXIgdGhhbiksIGVxIChlcXVhbCksIGFuZCBuZXEKCgoKSHVhbmcs IGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAg W1BhZ2UgNTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAg ICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAgICAgICAgICAgIChu b3QgZXF1YWwpLiI7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAg ICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBsZWFmIHBhY2tldC1sZW5ndGggewogICAgICAg ICAgICAgICAgICAgICB0eXBlIHVpbnQzMiB7CiAgICAgICAgICAgICAgICAgICAgICAgICByYW5n ZSAiMjAuLjkyMTAiOwogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAg IGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAiUGFja2V0IGxlbmd0aCB2YWx1 ZSBmb3IKICAgICAgICAgICAgICAgICAgICAgICAgIG9wZXJhdGlvbiBndCwgZXEsIGV0Yywgb3Ro ZXIKICAgICAgICAgICAgICAgICAgICAgICAgIHRoYW4gcmFuZ2UiOwogICAgICAgICAgICAgICAg ICAgICAgICAgLy9UT0RPIG5lZWQgdG8gZmluZCBvdXQgd2h5IHBhY2thZ2UgaXMKICAgICAgICAg ICAgICAgICAgICAgICAgIC8vIGxlc3MgdGhhbiA5MjEwCiAgICAgICAgICAgICAgICAgICAgIG1h bmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgIH0KICAgICAgICAg ICAgIGNhc2UgcmFuZ2UgewogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAg ICAgICAgICAgICJQYWNrZXQgb3BlcmF0b3IgJ3JhbmdlJyB0YWtlcwogICAgICAgICAgICAgICAg ICAgICBib3RoIGxvd2VyIGFuZCB1cHBlciB2YWx1ZS4iOwoKICAgICAgICAgICAgICAgICBsZWFm IHBhY2tldC1sZW5ndGgtdXBwZXIgewogICAgICAgICAgICAgICAgICAgICB0eXBlIHVpbnQzMiB7 CiAgICAgICAgICAgICAgICAgICAgICAgICByYW5nZSAiMjAuLjkyMTAiOwogICAgICAgICAgICAg ICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbiAiVXBwZXIgUGFja2V0IGxlbmd0aCI7CiAgICAgICAgICAg ICAgICAgfQoKICAgICAgICAgICAgICAgICBsZWFmIHBhY2tldC1sZW5ndGgtbG93ZXIgewogICAg ICAgICAgICAgICAgICAgICB0eXBlIHVpbnQzMiB7CiAgICAgICAgICAgICAgICAgICAgICAgICBy YW5nZSAiMjAuLjkyMTAiOwogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAg ICAgIG11c3QgIm51bWJlciguLi9wYWNrZXQtbGVuZ3RoLWxvd2VyKSA8PSAiICsKICAgICAgICAg ICAgICAgICAgICAgICAgICAibnVtYmVyKC4uL3BhY2tldC1sZW5ndGgtdXBwZXIpIjsKICAgICAg ICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgICAgIGRlc2Ny aXB0aW9uICJMb3dlciBwYWNrZXQgbGVuZ3RoIjsKICAgICAgICAgICAgICAgICB9CiAgICAgICAg ICAgICB9CiAgICAgICAgIH0KCiAgICAgICAgIGxlYWYgdGNwLWZsYWctdmFsdWUgewogICAgICAg ICAgICAgdHlwZSBjLXR5cGVzOnRjcC1mbGFnLXR5cGUgOwogICAgICAgICAgICAgZGVzY3JpcHRp b24gIlRDUCBmbGFnIGJpdHMgdGhhdCBuZWVkcyB0byBiZSBjaGVja2VkIjsKICAgICAgICAgfQoK ICAgICAgICAgbGVhZiB0Y3AtZmxhZy1tYXNrIHsKICAgICAgICAgICAgIHdoZW4gImJvb2xlYW4o Li4vdGNwLWZsYWctdmFsdWUpIiA7CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVz IEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDU3XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAx MwoKCiAgICAgICAgICAgICB0eXBlIGMtdHlwZXM6dGNwLWZsYWctdHlwZSA7CiAgICAgICAgICAg ICBkZXNjcmlwdGlvbiAiVENQIGZsYWcgYml0IHRoYXQgbmVlZHMgdG8gYmUgY2hlY2tlZCI7CiAg ICAgICAgIH0KCiAgICAgICAgIGxlYWYgdGNwLWZsYWctb3BlcmF0aW9uIHsKICAgICAgICAgICAg IHdoZW4gImJvb2xlYW4oLi4vdGNwLWZsYWctdmFsdWUpIiA7CiAgICAgICAgICAgICBkZXNjcmlw dGlvbgogICAgICAgICAgICAgICAgICJUQ1AgZmxhZyBNYXRjaCBvcHRpb24uCiAgICAgICAgICAg ICAgICAgQSBtYXRjaCBvY2N1cnMgaWYgdGhlIFRDUAogICAgICAgICAgICAgICAgIGRhdGFncmFt IGhhcyBjZXJ0YWluIFRDUCBmbGFncwogICAgICAgICAgICAgICAgIHNldCBvciBub3Qgc2V0LiBZ b3UgdXNlIHRoZQogICAgICAgICAgICAgICAgIG1hdGNoLWFueSBrZXl3b3JkIHRvIGFsbG93IGEg bWF0Y2gKICAgICAgICAgICAgICAgICB0byBvY2N1ciBpZiBhbnkgb2YgdGhlIHNwZWNpZmllZAog ICAgICAgICAgICAgICAgIFRDUCBmbGFncyBhcmUgcHJlc2VudCwgb3IgeW91IGNhbgogICAgICAg ICAgICAgICAgIHVzZSB0aGUgbWF0Y2gtYWxsIGtleXdvcmQgdG8gYWxsb3cKICAgICAgICAgICAg ICAgICBhIG1hdGNoIHRvIG9jY3VyIG9ubHkgaWYgYWxsIG9mCiAgICAgICAgICAgICAgICAgdGhl IHNwZWNpZmllZCBUQ1AgZmxhZ3MgYXJlCiAgICAgICAgICAgICAgICAgcHJlc2VudC4gWW91IG11 c3QgZm9sbG93IHRoZQogICAgICAgICAgICAgICAgIG1hdGNoLWFueSBhbmQgbWF0Y2gtYWxsIGtl eXdvcmRzCiAgICAgICAgICAgICAgICAgd2l0aCB0aGUgKyBvciAtIGtleXdvcmQgYW5kIHRoZQog ICAgICAgICAgICAgICAgIGZsYWctbmFtZSBhcmd1bWVudCB0byBtYXRjaCBvbgogICAgICAgICAg ICAgICAgIG9uZSBvciBtb3JlIFRDUCBmbGFncy4gIjsKICAgICAgICAgICAgIGRlZmF1bHQgbWF0 Y2gtYW55OwogICAgICAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7CiAgICAgICAgICAgICAgICAg ZW51bSBtYXRjaC1hbnkgewogICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAibWF0Y2gg YW55IjsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgZW51bSBtYXRjaC1hbGwg ewogICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAibWF0Y2ggYWxsIjsKICAgICAgICAg ICAgICAgICB9CiAgICAgICAgICAgICB9CiAgICAgICAgIH0KCiAgICAgICAgIGNob2ljZSB0dGwt dmFsdWUtb3ItcmFuZ2UgewogICAgICAgICAgICAgaWYtZmVhdHVyZSB0aW1lLXRvLWxpdmU7CiAg ICAgICAgICAgICBjYXNlIHZhbHVlIHsKICAgICAgICAgICAgICAgICBsZWFmIHR0bC1jb21wYXJh dG9yIHsKICAgICAgICAgICAgICAgICAgICAgdHlwZSBhY2w6YWNsLWNvbXBhcmF0b3I7CgogICAg ICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgIkNv bXBhcmVzIHRoZSBUVEwgdmFsdWUgaW4gdGhlIHBhY2tldAogICAgICAgICAgICAgICAgICAgICAg ICAgdG8gdGhlIFRUTCB2YWx1ZSBzcGVjaWZpZWQgaW4gdGhpcwogICAgICAgICAgICAgICAgICAg ICAgICAgQUNFIHN0YXRlbWVudC4gT3BlcmFuZHMgYXJlIGx0IChsZXNzCiAgICAgICAgICAgICAg ICAgICAgICAgICB0aGFuKSwgZ3QgKGdyZWF0ZXIgdGhhbiksIGFuZCBlcQogICAgICAgICAgICAg ICAgICAgICAgICAgKGVxdWFsKSwgIG5lcSAobm90IGVxdWFsKS4iOwogICAgICAgICAgICAgICAg IH0KICAgICAgICAgICAgICAgICBsZWFmIHR0bC12YWx1ZSB7CiAgICAgICAgICAgICAgICAgICAg IHR5cGUgYy10eXBlczp0aW1lLXRvLWxpdmU7CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDU4XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVh cnkgMjAxMwoKCiAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgfQogICAgICAgICAgICAg Y2FzZSByYW5nZSB7CiAgICAgICAgICAgICAgICAgbGVhZiB0dGwtdmFsdWUtbG93ZXIgewogICAg ICAgICAgICAgICAgICAgICB0eXBlIGMtdHlwZXM6dGltZS10by1saXZlOwogICAgICAgICAgICAg ICAgICAgICBkZXNjcmlwdGlvbiAiTG93ZXIgdHRsIG51bWJlci4iOwogICAgICAgICAgICAgICAg IH0KICAgICAgICAgICAgICAgICBsZWFmIHR0bC12YWx1ZS0tdXBwZXIgewogICAgICAgICAgICAg ICAgICAgICB0eXBlIGMtdHlwZXM6dGltZS10by1saXZlOwogICAgICAgICAgICAgICAgICAgICBk ZXNjcmlwdGlvbiAiVXBwZXIgdHRsIG51bWJlci4iOwoKICAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICB9CiAgICAgICAgIH0KICAgICB9CgogICAgIC8qIERhdGEgTm9kZXMgKi8KCiAgICAg YXVnbWVudCAiL2FjbDphY2xzL2FjbDphY2wiIHsKICAgICAgICAgd2hlbiAiYWNsOmFjbC10eXBl ID0gJ2lwLWFjbCciOwoKICAgICAgICAgbGVhZiBhZmkgewogICAgICAgICAgICAgdHlwZSBpbmV0 OmlwLXZlcnNpb24gOwogICAgICAgICAgICAgZGVmYXVsdCAiaXB2NCI7CiAgICAgICAgIH0KCiAg ICAgICAgIGNvbnRhaW5lciBpcHY2LWFjZXMgewogICAgICAgICAgICAgd2hlbiAiLi4vYWZpID0g J2lwdjYnIiA7CgogICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAiIFRo ZSBpcC1hY2VzIGNvbnRhaW5lciBjb250YWlucyBhIGxpc3Qgb2YgaXAtYWNlLgogICAgICAgICAg ICAgICAgIEVhY2ggaXAtYWNlIGlzIG1hZGUgb2YgYSB1bmlxdWUgSUQsIGFuIG9wdGlvbmFsCiAg ICAgICAgICAgICAgICAgcmVtYXJrIChjb21tZW50KSwgYW5kIGEgZmlsdGVyLiBUaGUgZmlsdGVy CiAgICAgICAgICAgICAgICAgcmVxdWlyZXMgYSBtYW5kYXRvcnkgYWN0aW9uIChwZXJtaXQvZGVu eSkgYW5kIG9uZSBvcgogICAgICAgICAgICAgICAgIG1vcmUgb3B0aW9ucyBzdWNoIGFzIHNvdXJj ZS1hZGRyZXNzIHdpdGggbWFzayx0dGwgZXRjIjsKCiAgICAgICAgICAgICBsaXN0IGlwdjYtYWNl IHsKICAgICAgICAgICAgICAgICBrZXkgIm5hbWUiOwogICAgICAgICAgICAgICAgIG9yZGVyZWQt YnkgdXNlcjsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiTGF5ZXIgMyBBY2Nlc3MgQ29u dHJvbCBFbGVtZW50IChBQ0UpIjsKCiAgICAgICAgICAgICAgICAgbGVhZiBuYW1lIHsKICAgICAg ICAgICAgICAgICAgICAgdHlwZSBhY2w6YWNsLW5hbWUtc3RyaW5nOwogICAgICAgICAgICAgICAg ICAgICBkZXNjcmlwdGlvbiAiVW5pcXVlIEFDRSBpZGVudGlmaWVyLiI7CiAgICAgICAgICAgICAg ICAgfQoKICAgICAgICAgICAgICAgICBjaG9pY2UgcmVtYXJrLW9yLWlwdjYtY2FzZSB7CiAgICAg ICAgICAgICAgICAgICBsZWFmIHJlbWFyayB7CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDU5XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVh cnkgMjAxMwoKCiAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsOmFjbC1yZW1hcms7CiAgICAg ICAgICAgICAgICAgICAgIC8vIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgICAgICAgfQog ICAgICAgICAgICAgICAgICAgY2FzZSBpcHY2LWFjZSB7CiAgICAgICAgICAgICAgICAgICAgIGNv bnRhaW5lciBmaWx0ZXJzIHsKCiAgICAgICAgICAgICAgICAgICAgICAgdXNlcyBJUC1TT1VSQ0Ut TkVUV09SSzsKICAgICAgICAgICAgICAgICAgICAgICB1c2VzIElQLURFU1RJTkFUSU9OLU5FVFdP Uks7CiAgICAgICAgICAgICAgICAgICAgICAgdXNlcyBJUC1BQ0UtRklMVEVSUzsKICAgICAgICAg ICAgICAgICAgICAgICB1c2VzIERTQ1AtT1ItVE9TOwoKICAgICAgICAgICAgICAgICAgICAgICBs ZWFmIGlnbXAtdHlwZSB7CiAgICAgICAgICAgICAgICAgICAgICAgICB3aGVuICIuLi9wcm90b2Nv bCA9ICcyJyAiOwogICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBjLXR5cGVzOmlnbXAtY29k ZTsKICAgICAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICJJR01QIG1lc3NhZ2UgdHlwZSAoMCB0byAxNSkgZm9yCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBmaWx0ZXJpbmcgSUdNUCBwYWNrZXRzLiBBcHBseSBvbmx5CiAgICAgICAg ICAgICAgICAgICAgICAgICAgICB3aGVuIHRoZSBwcm90b2NvbCBpcyBpZ21wIGluIGlwdjQiOwog ICAgICAgICAgICAgICAgICAgICAgIH0KCiAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBmbG93 LWxhYmVsIHsKICAgICAgICAgICAgICAgICAgICAgICAgIGlmLWZlYXR1cmUgZmxvdy1sYWJlbDsK ICAgICAgICAgICAgICAgICAgICAgICAgIHdoZW4gIi4uL3Byb3RvY29sID0gJzE3JyI7CiAgICAg ICAgICAgICAgICAgICAgICAgICB0eXBlIHVpbnQ2NCB7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHJhbmdlICIwLi4xMDQ4NTc1IjsKICAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICJGbG93IGxhYmVsIHZhbHVlLiBBcHBseSBvbmx5IHdoZW4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBwcm90b2NvbCBpcyBVRFAgaW4gaXB2Ni4iOwogICAgICAgICAgICAgICAgICAg ICAgICAgcmVmZXJlbmNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICJSRkMzNjk3IElQdjYg RmxvdyBMYWJlbCBTcGVjaWZpY2F0aW9uIjsKICAgICAgICAgICAgICAgICAgICAgICB9CiAgICAg ICAgICAgICAgICAgICAgIH0gIC8vIGNvbnRhaW5lciBmaWx0ZXJzCgogICAgICAgICAgICAgICAg ICAgICB1c2VzIGFjbDpBQ0UtQ09NTU9OOwogICAgICAgICAgICAgICAgICAgfSAgLy8gY2FzZSBp cHY2LWFjZQogICAgICAgICAgICAgICAgIH0gIC8vIGNob2ljZSByZW1hcmstb3ItaXB2Ni1hY2UK ICAgICAgICAgICAgIH0gIC8vIGxpc3QgaXB2Ni1hY2UKICAgICAgICAgfSAgLy8gY29udGFpbmVy IGlwdjYtYWNlcwoKICAgICAgICAgY29udGFpbmVyIGlwdjQtYWNlcyB7CiAgICAgICAgICAgICB3 aGVuICIuLi9hZmkgPSAnaXB2NCciIDsKCiAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAg ICAgICAgICAgICJUaGUgaXAtYWNlcyBjb250YWluZXIgY29udGFpbnMgYSBsaXN0IG9mIGlwLWFj ZS4KICAgICAgICAgICAgICAgICBFYWNoIGlwLWFjZSBpcyBtYWRlIG9mIGEgdW5pcXVlIElELCBh biBvcHRpb25hbAogICAgICAgICAgICAgICAgIHJlbWFyayAoY29tbWVudCksIGFuZCBhIGZpbHRl ci4gVGhlIGZpbHRlciByZXF1aXJlcyBhCiAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IGFjdGlv biAocGVybWl0L2RlbnkpIGFuZCBvbmUgb3IgbW9yZSBvcHRpb25zCgoKCkh1YW5nLCBldCBhbC4g ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDYw XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAg ICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgICAgICAgICAgc3VjaCBhcyBzb3VyY2UtYWRk cmVzcyB3aXRoIG1hc2ssdHRsIGV0YyI7CgogICAgICAgICAgICAgbGlzdCBpcHY0LWFjZSB7CiAg ICAgICAgICAgICAgICAga2V5ICJuYW1lIjsKICAgICAgICAgICAgICAgICBvcmRlcmVkLWJ5IHVz ZXI7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkxheWVyIDMgQWNjZXNzIENvbnRyb2wg RWxlbWVudCAoQUNFKSI7CgogICAgICAgICAgICAgICAgIGxlYWYgbmFtZSB7CiAgICAgICAgICAg ICAgICAgICAgIHR5cGUgYWNsOmFjbC1uYW1lLXN0cmluZzsKICAgICAgICAgICAgICAgICAgICAg ZGVzY3JpcHRpb24gIlVuaXF1ZSBBQ0UgaWRlbnRpZmllciI7CiAgICAgICAgICAgICAgICAgfQoK ICAgICAgICAgICAgICAgICBjaG9pY2UgcmVtYXJrLW9yLWlwdjQtYWNlIHsKICAgICAgICAgICAg ICAgICAgICAgbGVhZiByZW1hcmsgewogICAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsOmFj bC1yZW1hcms7CiAgICAgICAgICAgICAgICAgICAgICAgLy8gbWFuZGF0b3J5IHRydWU7CiAgICAg ICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICAgY2FzZSBpcHY0LWFjZSB7CiAg ICAgICAgICAgICAgICAgICAgICAgICBjb250YWluZXIgZmlsdGVycyB7CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdXNlcyBJUC1TT1VSQ0UtTkVUV09SSzsKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1c2VzIElQLURFU1RJTkFUSU9OLU5FVFdPUks7CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdXNlcyBJUC1BQ0UtRklMVEVSUzsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1c2VzIERTQ1AtT1ItVE9TOwogICAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAg ICAgICAgICAgICAgICAgICAgICB1c2VzIGFjbDpBQ0UtQ09NTU9OOwogICAgICAgICAgICAgICAg ICAgICB9ICAvLyBjYXNlIGlwdjQtYWNlCiAgICAgICAgICAgICAgICAgfSAgLy8gY2hvaWNlIHJl bWFyay1vci1pcHY0LWFjZQogICAgICAgICAgICAgfSAgLy8gbGlzdCBpcHY0LWFjZQogICAgICAg ICB9ICAvLyBjb250YWluZXIgaXB2NC1hY2VzCgogICAgICAgICBsZWFmIGdsb2JhbC1mcmFnbWVu dHMgewogICAgICAgICAgICAgZGVmYXVsdCAibm90LXNldCI7CiAgICAgICAgICAgICB0eXBlIGVu dW1lcmF0aW9uIHsKICAgICAgICAgICAgICAgICBlbnVtIG5vdC1zZXQ7CiAgICAgICAgICAgICAg ICAgZW51bSBwZXJtaXQtYWxsIHsKICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkFs bG93IGFsbCBmcmFnbWVudHMiOwogICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICBl bnVtIGRlbnktYWxsIHsKICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIkRyb3AgYWxs IGZyYWdtZW50cyI7CiAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgfQogICAgICAgICAg ICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAiT3B0aW1pemVzIGZyYWdtZW50IGhhbmRs aW5nIGZvciBub25pbml0aWFsIGZyYWdtZW50cy4KICAgICAgICAgICAgICAgICBXaGVuIHRoaXMg bGVhZiBpcyBzZXQgdG8gJ3Blcm1pdC1hbGwnLCBub25pbml0aWFsCiAgICAgICAgICAgICAgICAg ZnJhZ21lbnRzIHdpbGwgYmUgcGVybWl0dGVkIHVubGVzcyBleHBsaWNpdGx5IGRlbmllZC4KICAg ICAgICAgICAgICAgICBXaGVuIHRoaXMgbGVhZiBpcyBzZXQgdG8gJ2RlbnktYWxsJywgbm9uaW5p dGlhbAogICAgICAgICAgICAgICAgIGZyYWdtZW50cyB3aWxsIGJlIGRlbmllZCB1bmxlc3MgZXhw bGljaXRseQogICAgICAgICAgICAgICAgIHBlcm1pdHRlZC4gIjsKCgoKSHVhbmcsIGV0IGFsLiAg ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNjFd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAg ICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgfQogICAgIH0KCiB9CgogPC9DT0RFIEVORFM+ CgoxMi4gIEFDTC1NQUMgQ29uZmlndXJhdGlvbiBZQU5HIE1vZHVsZQoKICAgVGhpcyBtb2R1bGUg aW1wb3J0cyB0eXBlIGRlZmluaXRpb25zIGZyb20gY29tbW9uLXR5cGVzIFlBTkcgZGVmaW5lZAog ICBpbiB0aGlzIG1vZGVsLgoKIDxDT0RFIEJFR0lOUz4gZmlsZSAiYWNsLW1hY0AyMDEyLTEwLTEy LnlhbmciCgogbW9kdWxlIGFjbC1tYWMgewogICAgIG5hbWVzcGFjZSAidXJuOmNpc2NvOnBhcmFt czp4bWw6bnM6eWFuZzphY2wtbWFjIjsKICAgICAvLyByZXBsYWNlIHdpdGggSUFOQSBuYW1lc3Bh Y2Ugd2hlbiBhc3NpZ25lZAogICAgIHByZWZpeCBhY2wtbWFjOwoKICAgICBpbXBvcnQgYWNsIHsg cHJlZml4IGFjbDsgIH0KCiAgICAgaW1wb3J0IGNvbW1vbi10eXBlcyB7CiAgICAgICAgIHByZWZp eCAiYy10eXBlcyI7CiAgICAgfQoKICAgICBpbXBvcnQgaWV0Zi1pbmV0LXR5cGVzIHsKICAgICAg ICAgcHJlZml4ICJpbmV0IjsKICAgICB9CgogICAgIGltcG9ydCBpZXRmLXlhbmctdHlwZXMgewog ICAgICAgICBwcmVmaXggInlhbmciOwogICAgIH0KCiAgICAgb3JnYW5pemF0aW9uCiAgICAgICAg IklFVEYgTkVUTU9EIChORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UpIFdvcmtpbmcgR3Jv dXAiOwoKICAgICBjb250YWN0CiAgICAgICAgICAiV0cgV2ViOiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvd2cvbmV0bW9kLwogICAgICAgICBXRyBMaXN0OiBuZXRtb2RAaWV0Zi5vcmcKCiAgICAgICAg IFdHIENoYWlyOiBEYXZpZCBLZXNzZW5zCiAgICAgICAgIGRhdmlkLmtlc3NlbnNAbnNuLmNvbQoK ICAgICAgICAgV0cgQ2hhaXI6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcgogICAgICAgICBqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUKCiAgICAgICAgIEVkaXRvcjogTGlzYSBIdWFu ZwogICAgICAgICB5aWh1YW5AY2lzY28uY29tCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBF eHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDYyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVh cnkgMjAxMwoKCiAgICAgICAgIEVkaXRvcjogQWxleGFuZGVyIENsZW1tCiAgICAgICAgIGFsZXhA Y2lzY28uY29tCgogICAgICAgICBFZGl0b3I6IEFuZHkgQmllcm1hbgogICAgICAgICBhbmR5QHl1 bWF3b3Jrcy5jb20iOwoKICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgIlRoaXMgWUFORyBtb2R1 bGUgYXVnbWVudHMgdGhlICdhY2wnIG1vZHVsZSB3aXRoCiAgICAgICAgIGNvbmZpZ3VyYXRpb24g YW5kIG9wZXJhdGlvbmFsIGRhdGEgZm9yIE1BQyBhY2Nlc3MgY29udHJvbCBsaXN0CgogICAgICAg ICBBbiBBQ0wgaXMgYW4gb3JkZXJlZCBzZXQgb2YgcnVsZXMgYW5kIGFjdGlvbnMgdXNlZCB0bwog ICAgICAgICBmaWx0ZXIgdHJhZmZpYy4KICAgICAgICAgRWFjaCBzZXQgb2YgcnVsZXMgYW5kIGFj dGlvbnMgaXMgcmVwcmVzZW50ZWQgYXMgYW4gQWNjZXNzCiAgICAgICAgIENvbnRyb2wgRW50cmll cyAoQUNFKS4gRWFjaCBBQ0UgaXMgZXZhbHVhdGVkIHNlcXVlbnRpYWxseS4KICAgICAgICAgV2hl biB0aGUgcnVsZSBtYXRjaGVzIHRoZW4gYWN0aW9uIGZvciB0aGF0IHJ1bGUgaXMgYXBwbGllZAog ICAgICAgICB0byB0aGUgcGFja2V0LgoKICAgICAgICAgTUFDIEFDTHMgLSBNQUMgQUNMcyBhcmUg dXNlZCB0byBmaWx0ZXIgdHJhZmZpYyB1c2luZyB0aGUKICAgICAgICAgICAgIGluZm9ybWF0aW9u IGluIHRoZSBMYXllciAyIGhlYWRlciBvZiBlYWNoIHBhY2tldC4KICAgICAgICAgICAgIE1BQyBB Q0xzIGFyZSBieSBkZWZhdWx0IG9ubHkgYXBwbGllZCB0byBub24tSVAKICAgICAgICAgICAgIHRy YWZmaWM7IGhvd2V2ZXIsIExheWVyIDIgaW50ZXJmYWNlcyBjYW4gYmUgY29uZmlndXJlZCB0bwog ICAgICAgICAgICAgYXBwbHkgTUFDIEFDTHMgdG8gYWxsIHRyYWZmaWMuCgogICAgICAgICBUZXJt cyBhbmQgQWNyb255bXMKICAgICAgICAgIEFDRSAoYWNlKTogQWNjZXNzIENvbnRyb2wgRW50cnkK CiAgICAgICAgICBBQ0wgKGFjbCk6IEFjY2VzcyBDb250cm9sIExpc3QKCiAgICAgICAgICBBRkkg KGFmaSk6IEF1dGhvcml0eSBhbmQgRm9ybWF0IElkZW50aWZpZXIgKEFkZHJlc3MgRmllbGQKICAg ICAgICAgICAgICBJZGVudGlmaWVyKQoKICAgICAgICAgIENvUyAoY29zKTogQ2xhc3Mgb2YgU2Vy dmljZQoKICAgICAgICAgIE1BQzogTWVkaWEgQWNjZXNzIENvbnRyb2wKCiAgICAgICAgICBUVEwg KHR0bCk6IFRpbWUgdG8gTGl2ZQoKICAgICAgICAgIFZMQU4gKHZsYW4pOiBWaXJ0dWFsIExvY2Fs IEFyZWEgTmV0d29yawoKICAgICAgICAgIFZSRih2cmYpIDogVmlydHVhbCBSb3V0aW5nIGFuZCBG b3J3YXJkaW5nCiAgICAgICAgIjsKICAgICByZWZlcmVuY2UKICAgICAgICAgIkFjY2VzcyBMaXN0 IENvbW1hbmRzIG9uIENpc2NvIElPUyBYUiBTb2Z0d2FyZSwKICAgICAgICAgQ2lzY28gTmV4dXMg NzAwMCBTZXJpZXMgTlgtT1MgU2VjdXJpdHkgQ29uZmlndXJhdGlvbiBHdWlkZSwKICAgICAgICAg Q2F0YWx5c3QgNjUwMCBSZWxlYXNlIDEyLjJTWCBTb2Z0d2FyZSBDb25maWd1cmF0aW9uIEd1aWRl IjsKCiAgICAgcmV2aXNpb24gMjAxMi0xMC0xMiB7CiAgICAgICAgIGRlc2NyaXB0aW9uICJJbml0 aWFsIHJldmlzaW9uLiAiOwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA2M10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgog ICAgIH0KCiAgICAgLyogRmVhdHVyZXMgKi8KCiAgICAgZmVhdHVyZSBldGhlcnR5cGUtbWFzayB7 CiAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAiVGhlIGFiaWxpdHkgdG8gZml0ZXIg cGFja2V0cyBiYXNlZCBvbiBldGhlci10eXBlIG1hc2sKICAgICAgICAgICAgIGluIGhleCAweDAt MHhGRkZGLiI7CiAgICAgfQoKICAgICAvKiBJZGVudGl0aWVzICovCgogICAgIGlkZW50aXR5IG1h Yy1hY2wgewogICAgICAgICBiYXNlIGFjbDphY2wtdHlwZTsKICAgICAgICAgZGVzY3JpcHRpb24g ImxheWVyIDIgQUNMIHR5cGUiOwogICAgIH0KCiAgICAgLyogR3JvdXBpbmdzICovCgogICAgIGdy b3VwaW5nIE1BQy1TT1VSQ0UtTkVUV09SSyB7CiAgICAgICAgIGRlc2NyaXB0aW9uICJNQUMgYWRk cmVzcyBhbmQgbWFzayBwYWlyIGZvciBzb3VyY2UuIjsKCiAgICAgICAgIGdyb3VwaW5nIE1BQy1T T1VSQ0UtSE9TVCB7CiAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAiQ2hv aWNlIHdpdGhpbiBhIGNhc2Ugbm90IGFsbG93ZWQgc28gbmVlZAogICAgICAgICAgICAgICAgdGhp cyBncm91cGluZy4iOwogICAgICAgICAgICAgY2hvaWNlIHNyYy1hZGRyZXNzLW9yLW5hbWUgewog ICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwogICAgICAgICAgICAgICAgIGxlYWYgc291 cmNlLWhvc3QtYWRkcmVzcyB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUgaW5ldDppcC1hZGRy ZXNzOwogICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAg ICAgICAiVXNlIHRoZSBob3N0IGFkZHJlc3MgY29tYmluYXRpb24gYXMgYW4KICAgICAgICAgICAg ICAgICAgICAgICAgIGFiYnJldmlhdGlvbiBmb3IgYW4gYWRkcmVzcyBhbmQgd2lsZGNhcmQKICAg ICAgICAgICAgICAgICAgICAgICAgIG9mIGFkZHJlc3MgMC4wLjAuMCI7CiAgICAgICAgICAgICAg ICAgfQogICAgICAgICAgICAgICAgIGxlYWYgc291cmNlLWhvc3QtbmFtZSB7CiAgICAgICAgICAg ICAgICAgICAgaWYtZmVhdHVyZSBhY2w6aG9zdC1ieS1uYW1lOwogICAgICAgICAgICAgICAgICAg IHR5cGUgaW5ldDpkb21haW4tbmFtZTsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICB9 CiAgICAgICAgIH0KCiAgICAgICAgIGNob2ljZSBzb3VyY2UtbmV0d29yayB7CiAgICAgICAgICAg ICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgICAgIGNhc2Ugc291cmNlLW1hYyB7CiAgICAgICAg ICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAgICJVc2VkIHdpdGggYWRkcmVz cyBhbmQgbWFzayBjb3VwbGUgdG8KICAgICAgICAgICAgICAgICAgICBleHByZXNzIG5ldHdvcmsu IjsKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgNjRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5 YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAg ICBsZWFmIHNvdXJjZS1hZGRyZXNzIHsKICAgICAgICAgICAgICAgICAgICAgdHlwZSB5YW5nOm1h Yy1hZGRyZXNzOwogICAgICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAg ICAgICAgICAgICAgZGVzY3JpcHRpb24gIkEgc291cmNlIE1BQyBhZGRyZXNzLiI7CiAgICAgICAg ICAgICAgICAgfQogICAgICAgICAgICAgICAgIGxlYWYgc291cmNlLWFkZHJlc3MtbWFzayB7CiAg ICAgICAgICAgICAgICAgICAgIHR5cGUgeWFuZzptYWMtYWRkcmVzczsKICAgICAgICAgICAgICAg ICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJB IHNvdXJjZSBNQUMgYWRkcmVzcyBtYXNrLiI7CiAgICAgICAgICAgICAgICAgfQogICAgICAgICAg ICAgfQogICAgICAgICAgICAgbGVhZiBzb3VyY2UtYW55IHsKICAgICAgICAgICAgICAgICB0eXBl IGVtcHR5OwogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJUbyBleHByZXNzIEFueSBuZXR3 b3JrIG9yIGFkZHJlc3MiOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgY2FzZSBzb3VyY2Ut aG9zdCB7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAgICJV c2UgdGhlIGhvc3QgYWRkcmVzcyBjb21iaW5hdGlvbiBhcyBhbgogICAgICAgICAgICAgICAgICAg IGFiYnJldmlhdGlvbiBmb3IgYW4gYWRkcmVzcyBhbmQgd2lsZGNhcmQKICAgICAgICAgICAgICAg ICAgICBvZiBhZGRyZXNzIDAuMC4wLjAiOwogICAgICAgICAgICAgICAgIHVzZXMgTUFDLVNPVVJD RS1IT1NUOwogICAgICAgICAgICAgfQogICAgICAgICB9CiAgICAgfQoKICAgICBncm91cGluZyBN QUMtREVTVElOQVRJT04tTkVUV09SSyB7CiAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAg Ik1BQyBhZGRyZXNzIGFuZCBtYXNrIHBhaXIgZm9yIGRlc3RpbmF0aW9uLiI7CgogICAgICAgICBn cm91cGluZyBNQUMtREVTVElOQVRJT04tSE9TVCB7CiAgICAgICAgICAgICBkZXNjcmlwdGlvbgog ICAgICAgICAgICAgICAiQ2hvaWNlIHdpdGhpbiBhIGNhc2Ugbm90IGFsbG93ZWQgc28gbmVlZAog ICAgICAgICAgICAgICAgdGhpcyBncm91cGluZy4iOwogICAgICAgICAgICAgY2hvaWNlIGRlc3Qt YWRkcmVzcy1vci1uYW1lIHsKICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsKICAgICAg ICAgICAgICAgICBsZWFmIGRlc3QtaG9zdC1hZGRyZXNzIHsKICAgICAgICAgICAgICAgICAgICAg dHlwZSBpbmV0OmlwLWFkZHJlc3M7CiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uCiAg ICAgICAgICAgICAgICAgICAgICAgICJVc2UgdGhlIGhvc3QgYWRkcmVzcyBjb21iaW5hdGlvbiBh cyBhbgogICAgICAgICAgICAgICAgICAgICAgICAgYWJicmV2aWF0aW9uIGZvciBhbiBhZGRyZXNz IGFuZCB3aWxkY2FyZAogICAgICAgICAgICAgICAgICAgICAgICAgb2YgYWRkcmVzcyAwLjAuMC4w IjsKICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgbGVhZiBkZXN0LWhvc3QtbmFt ZSB7CiAgICAgICAgICAgICAgICAgICAgaWYtZmVhdHVyZSBhY2w6aG9zdC1ieS1uYW1lOwogICAg ICAgICAgICAgICAgICAgIHR5cGUgaW5ldDpkb21haW4tbmFtZTsKICAgICAgICAgICAgICAgICB9 CiAgICAgICAgICAgICB9CiAgICAgICAgIH0KCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4 cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNjVdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFy eSAyMDEzCgoKICAgICAgICAgY2hvaWNlIGRlc3QtbmV0d29yayB7CiAgICAgICAgICAgICBtYW5k YXRvcnkgdHJ1ZTsKICAgICAgICAgICAgIGNhc2UgZGVzdC1tYWMgewogICAgICAgICAgICAgICAg IGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgICAiVXNlZCB3aXRoIGFkZHJlc3MgYW5kIG1h c2sgY291cGxlIHRvCiAgICAgICAgICAgICAgICAgICAgZXhwcmVzcyBuZXR3b3JrLiI7CiAgICAg ICAgICAgICAgICAgbGVhZiBkZXN0LWFkZHJlc3MgewogICAgICAgICAgICAgICAgICAgICB0eXBl IHlhbmc6bWFjLWFkZHJlc3M7CiAgICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOwog ICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiQSBzb3VyY2UgTUFDIGFkZHJlc3MuIjsK ICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgbGVhZiBkZXN0LWFkZHJlc3MtbWFz ayB7CiAgICAgICAgICAgICAgICAgICAgIHR5cGUgeWFuZzptYWMtYWRkcmVzczsKICAgICAgICAg ICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uICJBIHNvdXJjZSBNQUMgYWRkcmVzcyBtYXNrLiI7CiAgICAgICAgICAgICAgICAgfQogICAg ICAgICAgICAgfQogICAgICAgICAgICAgbGVhZiBkZXN0LWFueSB7CiAgICAgICAgICAgICAgICAg dHlwZSBlbXB0eTsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiVG8gZXhwcmVzcyBBbnkg bmV0d29yayBvciBhZGRyZXNzIjsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGNhc2UgZGVz dC1ob3N0IHsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgICAgICAg IlVzZSB0aGUgaG9zdCBhZGRyZXNzIGNvbWJpbmF0aW9uIGFzIGFuCiAgICAgICAgICAgICAgICAg ICAgYWJicmV2aWF0aW9uIGZvciBhbiBhZGRyZXNzIGFuZCB3aWxkY2FyZAogICAgICAgICAgICAg ICAgICAgIG9mIGFkZHJlc3MgMC4wLjAuMCI7CiAgICAgICAgICAgICAgICAgdXNlcyBNQUMtREVT VElOQVRJT04tSE9TVDsKICAgICAgICAgICAgIH0KICAgICAgICAgfQogICAgIH0KCiAgICAgLyog TGF5ZXIgMiBBQ0wgKi8KCiAgICAgYXVnbWVudCAiL2FjbDphY2xzL2FjbDphY2wiIHsKICAgICAg ICAgd2hlbiAiYWNsOmFjbC10eXBlID0gJ21hYy1hY2wnIjsKICAgICAgICAgZGVzY3JpcHRpb24K ICAgICAgICAgICAgICJMYXllciAyIEFjY2VzcyBDb250cm9sIEVudHJ5IChBQ0UpLiBUaGUgbWFj LWFjZXMKICAgICAgICAgICAgIGNvbnRhaW5lciBjb250YWlucyBhIGxpc3Qgb2YgbWFjLWFjZS4g RWFjaCBtYWMtYWNlIGlzCiAgICAgICAgICAgICBjb21wcmlzZWQgb2YgYSBuYW1lLCBhbiBvcHRp b25hbCByZW1hcmsKICAgICAgICAgICAgIGFuZCBhIHJ1bGUuCiAgICAgICAgICAgICBBIHJ1bGUg aXMgcmVmZXJyZWQgdG8gYXMgJ3BhY2tldC1maWx0ZXInLCBhbHRob3VnaCBpdAogICAgICAgICAg ICAgY29udGFpbnMgYm90aCBhIGZpbHRlciBhbmQgYW4gYWN0aW9uLgogICAgICAgICAgICAgVGhl IHBhY2tldC1maWx0ZXIgcmVxdWlyZXMgYSBtYW5kYXRvcnkgYWN0aW9uIChwZXJtaXQvZGVueSkK ICAgICAgICAgICAgIGFuZCBvbmUgb3IgbW9yZSBvcHRpb25zIHN1Y2ggYXMgc291cmNlLWFkZHJl c3Mgd2l0aCBtYXNrLAogICAgICAgICAgICAgZXRoZXJ0eXBlLCB2bGFuIGV0Yy4iOwogICAgICAg ICBjb250YWluZXIgbWFjLWFjZXMgewogICAgICAgICAgICAgbGlzdCBtYWMtYWNlIHsKICAgICAg ICAgICAgICAga2V5IG5hbWU7CgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDY2XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoK CiAgICAgICAgICAgICAgIG9yZGVyZWQtYnkgdXNlcjsKCiAgICAgICAgICAgICAgIGxlYWYgbmFt ZSB7CiAgICAgICAgICAgICAgICAgdHlwZSBhY2w6YWNsLW5hbWUtc3RyaW5nOwogICAgICAgICAg ICAgICAgIGRlc2NyaXB0aW9uICJVbmlxdWUgQUNFIGlkZW50aWZpZXIiOwogICAgICAgICAgICAg ICB9CgogICAgICAgICAgICAgICBjaG9pY2UgcmVtYXJrLW9yLW1hYy1hY2UgewogICAgICAgICAg ICAgICAgIGxlYWYgcmVtYXJrIHsKICAgICAgICAgICAgICAgICAgICAgdHlwZSBhY2w6YWNsLXJl bWFyazsKICAgICAgICAgICAgICAgICAgICAgLy8gbWFuZGF0b3J5IHRydWU7CiAgICAgICAgICAg ICAgICAgfQogICAgICAgICAgICAgICAgIGNhc2UgbWFjLWFjZSB7CiAgICAgICAgICAgICAgICAg ICBjb250YWluZXIgZmlsdGVycyB7CiAgICAgICAgICAgICAgICAgICAgIHVzZXMgTUFDLVNPVVJD RS1ORVRXT1JLOwogICAgICAgICAgICAgICAgICAgICB1c2VzIE1BQy1ERVNUSU5BVElPTi1ORVRX T1JLOwoKICAgICAgICAgICAgICAgICAgICAgbGVhZiBldGhlcnR5cGUgewogICAgICAgICAgICAg ICAgICAgICAgIHR5cGUgYy10eXBlczpldGhlci10eXBlOwogICAgICAgICAgICAgICAgICAgICAg IGRlc2NyaXB0aW9uICJldGhlci10eXBlIChhbHNvIGtub3duIGFzCiAgICAgICAgICAgICAgICAg ICAgICAgICAgcHJvdG9jb2wpIGluIGhleCAweDAtMHhmZmZmIjsKICAgICAgICAgICAgICAgICAg ICAgfQoKICAgICAgICAgICAgICAgICAgICAgbGVhZiBldGhlcnR5cGUtbWFzayB7CiAgICAgICAg ICAgICAgICAgICAgICAgaWYtZmVhdHVyZSBldGhlcnR5cGUtbWFzazsKICAgICAgICAgICAgICAg ICAgICAgICB3aGVuICJib29sZWFuKC4uL2V0aGVydHlwZSkiOwogICAgICAgICAgICAgICAgICAg ICAgIHR5cGUgYy10eXBlczpldGhlci10eXBlOwogICAgICAgICAgICAgICAgICAgICAgIGRlZmF1 bHQgIjB4MDAwMCI7CiAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAg ICAgICAgICAgICAgICAgICJFdGhlci10eXBlIG1hc2sgaW4gaGV4IDB4MC0weEZGRkYuCiAgICAg ICAgICAgICAgICAgICAgICAgICAgMHgwIGlzIGV4YWN0bHkgbWF0Y2ggb2YgdGhlIEV0aGVydHlw ZS4uIjsKICAgICAgICAgICAgICAgICAgICAgfQoKICAgICAgICAgICAgICAgICAgICAgbGVhZiBj b3MgewogICAgICAgICAgICAgICAgICAgICAgIHR5cGUgYy10eXBlczpjb3M7CiAgICAgICAgICAg ICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJDb1MgdmFsdWUgPDAtNz4iOwogICAgICAgICAgICAg ICAgICAgICB9CgogICAgICAgICAgICAgICAgICAgICBsZWFmIHRpbWUtcmFuZ2UgewogICAgICAg ICAgICAgICAgICAgICAgIHR5cGUgYWNsOnRpbWUtcmFuZ2UtcmVmOwogICAgICAgICAgICAgICAg ICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAiRW5hYmxlIHBhY2tl dCBjYXB0dXJlIG9uIHRoaXMKICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXIgZm9yIGEg c3BlY2lmeSAgdGltZSByYW5nZQogICAgICAgICAgICAgICAgICAgICAgICAgIGJ5IG5hbWUuIjsK ICAgICAgICAgICAgICAgICAgICAgICB9CgogICAgICAgICAgICAgICAgICAgICAgIGxlYWYgdmxh biB7CiAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBjLXR5cGVzOnZsYW4taWRlbnRpZmll cjsKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgNjddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5 YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAg ICAgICAgICAgICBkZXNjcmlwdGlvbiAiVkxBTiBudW1iZXIiOwogICAgICAgICAgICAgICAgICAg ICAgIH0KCiAgICAgICAgICAgICAgICAgICAgICAgdXNlcyBhY2w6RklMVEVSLUNPTU1PTjsKCiAg ICAgICAgICAgICAgICAgfSAgLy8gY29udGFpbmVyIGZpbHRlcnMKCiAgICAgICAgICAgICAgICAg dXNlcyBhY2w6QUNFLUNPTU1PTjsKCiAgICAgICAgICAgICAgIH0gLy8gY2FzZSBtYWMtYWNlCiAg ICAgICAgICAgICB9IC8vIGNob2ljZSByZW1hcmstb3ItYWNlCiAgICAgICAgICAgfSAgLy8gbGlz dCBtYWMtYWNlCiAgICAgICAgIH0gIC8vIGNvbnRhaW5lciBtYWMtYWNlcwogICAgIH0gIC8vIGF1 Z21lbnQKCiB9CgoKIDwvQ09ERSBFTkRTPgoKMTMuICBBQ0wtQVJQIENvbmZpZ3VyYXRpb24gWUFO RyBNb2R1bGUKCiAgPENPREUgQkVHSU5TPiBmaWxlICJhY2wtYXJwQDIwMTItMTAtMTIueWFuZyIK CiAgbW9kdWxlIGFjbC1hcnAgewogICAgICBuYW1lc3BhY2UgInVybjpjaXNjbzpwYXJhbXM6eG1s Om5zOnlhbmc6YWNsLWFycCI7CiAgICAgIC8vIHJlcGxhY2Ugd2l0aCBJQU5BIG5hbWVzcGFjZSB3 aGVuIGFzc2lnbmVkCiAgICAgIHByZWZpeCBhY2wtYXJwOwoKICAgICAgaW1wb3J0IGFjbCB7IHBy ZWZpeCBhY2w7IH0KICAgICAgaW1wb3J0IGFjbC1pcCB7IHByZWZpeCBhY2wtaXA7IH0KICAgICAg aW1wb3J0IGFjbC1tYWMgeyBwcmVmaXggYWNsLW1hYzsgfQoKICAgICAgb3JnYW5pemF0aW9uCiAg ICAgICAgICJJRVRGIE5FVE1PRCAoTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExhbmd1YWdlKSBXb3Jr aW5nIEdyb3VwIjsKCiAgICAgIGNvbnRhY3QKICAgICAgICAgICAiV0cgV2ViOiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvd2cvbmV0bW9kLwogICAgICAgICAgV0cgTGlzdDogbmV0bW9kQGlldGYub3Jn CgogICAgICAgICAgV0cgQ2hhaXI6IERhdmlkIEtlc3NlbnMKICAgICAgICAgIGRhdmlkLmtlc3Nl bnNAbnNuLmNvbQoKICAgICAgICAgIFdHIENoYWlyOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIKICAg ICAgICAgIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZQoKICAgICAgICAgIEVk aXRvcjogTGlzYSBIdWFuZwogICAgICAgICAgeWlodWFuQGNpc2NvLmNvbQoKCgpIdWFuZywgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFn ZSA2OF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAg ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgogICAgICAgICAgRWRpdG9yOiBBbGV4YW5kZXIgQ2xl bW0KICAgICAgICAgIGFsZXhAY2lzY28uY29tCgogICAgICAgICAgRWRpdG9yOiBBbmR5IEJpZXJt YW4KICAgICAgICAgIGFuZHlAeXVtYXdvcmtzLmNvbSI7CiAgICAgIGRlc2NyaXB0aW9uCiAgICAg ICAgICAiVGhpcyBZQU5HIG1vZHVsZSBhdWdtZW50cyB0aGUgJ2FjbCcgbW9kdWxlIHdpdGgKICAg ICAgICAgIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIGRhdGEgZm9yIEFSUCBhY2Nlc3Mg Y29udHJvbCBsaXN0CgogICAgICAgICAgQW4gQUNMIGlzIGFuIG9yZGVyZWQgc2V0IG9mIHJ1bGVz IGFuZCBhY3Rpb25zIHVzZWQgdG8gZmlsdGVyCiAgICAgICAgICB0cmFmZmljLgogICAgICAgICAg RWFjaCBzZXQgb2YgcnVsZXMgYW5kIGFjdGlvbnMgaXMgcmVwcmVzZW50ZWQgYXMgYW4gQWNjZXNz CiAgICAgICAgICBDb250cm9sIEVudHJpZXMgKEFDRSkuIEVhY2ggQUNFIGlzIGV2YWx1YXRlZCBz ZXF1ZW50aWFsbHkuCiAgICAgICAgICBXaGVuIHRoZSBydWxlIG1hdGNoZXMgdGhlbiBhY3Rpb24g Zm9yIHRoYXQgcnVsZSBpcyBhcHBsaWVkCiAgICAgICAgICB0byB0aGUgcGFja2V0LgoKICAgICAg ICAgIEFSUCBBQ0xzIC0gVGhlIGRldmljZSBhcHBsaWVzIEFSUCBBQ0xzIHRvIElQIHRyYWZmaWMu CgogICAgICAgICAgVGVybXMgYW5kIEFjcm9ueW1zCiAgICAgICAgICAgQUNFIChhY2UpOiBBY2Nl c3MgQ29udHJvbCBFbnRyeQoKICAgICAgICAgICBBQ0wgKGFjbCk6IEFjY2VzcyBDb250cm9sIExp c3QKCiAgICAgICAgICAgQVJQIChhcnApOiBBZGRyZXNzIFJlc29sdXRpb24gUHJvdG9jb2wKCiAg ICAgICAgICAgSVAgKGlwKTogSW50ZXJuZXQgUHJvdG9jb2wKCiAgICAgICAgICAgTUFDOiBNZWRp YSBBY2Nlc3MgQ29udHJvbAoKICAgICAgICAgICBWTEFOICh2bGFuKTogVmlydHVhbCBMb2NhbCBB cmVhIE5ldHdvcmsKICAgICAgICAgIjsKICAgICAgcmVmZXJlbmNlCiAgICAgICAgICAiQWNjZXNz IExpc3QgQ29tbWFuZHMgb24gQ2lzY28gSU9TIFhSIFNvZnR3YXJlLAogICAgICAgICAgQ2lzY28g TmV4dXMgNzAwMCBTZXJpZXMgTlgtT1MgU2VjdXJpdHkgQ29uZmlndXJhdGlvbiBHdWlkZSwKICAg ICAgICAgIENhdGFseXN0IDY1MDAgUmVsZWFzZSAxMi4yU1ggU29mdHdhcmUgQ29uZmlndXJhdGlv biBHdWlkZSwKICAgICAgICAgIEFDTCBUQ1AgRmxhZ3MgRmlsdGVyaW5nIjsKCiAgICAgIHJldmlz aW9uIDIwMTItMTAtMTIgewogICAgICAgICAgZGVzY3JpcHRpb24gIkluaXRpYWwgcmV2aXNpb24u ICI7CiAgICAgIH0KCiAgICAgIC8qIElkZW50aXRpZXMgKi8KCiAgICAgIGlkZW50aXR5IGFycC1h Y2wgewogICAgICAgICAgYmFzZSAiYWNsOmFjbC10eXBlIjsKICAgICAgICAgIGRlc2NyaXB0aW9u ICJBUlAgQUNMIHR5cGUiOwogICAgICB9CgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA2OV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTMKCgogICAgICAvKiBEYXRhIE5vZGVzICovCgogICAgICBhdWdtZW50ICIvYWNsOmFjbHMv YWNsOmFjbCIgewogICAgICAgICAgd2hlbiAiYWNsOmFjbC10eXBlID0gJ2FycC1hY2wnIjsKCiAg ICAgICAgICBkZXNjcmlwdGlvbiAiQVJQIEFjY2VzcyBDb250cm9sIEVudHJ5IChBQ0UpLiI7CiAg ICAgICAgICBjb250YWluZXIgYXJwLWFjZXMgewogICAgICAgICAgICAgIGxpc3QgYXJwLWFjZSB7 CiAgICAgICAgICAgICAgICBrZXkgIm5hbWUiOwogICAgICAgICAgICAgICAgb3JkZXJlZC1ieSB1 c2VyOwoKICAgICAgICAgICAgICAgIGxlYWYgbmFtZSB7CiAgICAgICAgICAgICAgICAgICAgdHlw ZSBhY2w6YWNsLW5hbWUtc3RyaW5nOwogICAgICAgICAgICAgICAgfQoKICAgICAgICAgICAgICAg IGNob2ljZSByZW1hcmstb3ItYXJwLWFjZSB7CiAgICAgICAgICAgICAgICAgIGxlYWYgcmVtYXJr IHsKICAgICAgICAgICAgICAgICAgICAgIHR5cGUgYWNsOmFjbC1yZW1hcms7CiAgICAgICAgICAg ICAgICAgICAgICAvLyBtYW5kYXRvcnkgdHJ1ZTsKICAgICAgICAgICAgICAgICAgfQogICAgICAg ICAgICAgICAgICBjYXNlIGFycC1hY2UgewogICAgICAgICAgICAgICAgICAgIGNvbnRhaW5lciBm aWx0ZXJzIHsKICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGRpcmVjdGlvbiB7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgZGVmYXVsdCAiYmktZGlyZWN0aW9uIjsKICAgICAgICAgICAgICAg ICAgICAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBlbnVtIGJpLWRpcmVjdGlvbjsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnVtIHJl cXVlc3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW51bSByZXNwb25zZTsKICAgICAg ICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRp b24gIkFSUCByZXF1ZXN0L3Jlc3BvbnNlLiI7CiAgICAgICAgICAgICAgICAgICAgICAgfQoKICAg ICAgICAgICAgICAgICAgICAgICB1c2VzIGFjbC1pcDpJUC1TT1VSQ0UtTkVUV09SSzsKICAgICAg ICAgICAgICAgICAgICAgICB1c2VzIGFjbC1pcDpJUC1ERVNUSU5BVElPTi1ORVRXT1JLIHsKICAg ICAgICAgICAgICAgICAgICAgICAgIHdoZW4gIi4uL2RpcmVjdGlvbiA9ICdyZXNwb25zZSciOwog ICAgICAgICAgICAgICAgICAgICAgIH0KCiAgICAgICAgICAgICAgICAgICAgICAgdXNlcyBhY2wt bWFjOk1BQy1TT1VSQ0UtTkVUV09SSzsKICAgICAgICAgICAgICAgICAgICAgICB1c2VzIGFjbC1t YWM6TUFDLURFU1RJTkFUSU9OLU5FVFdPUksgewogICAgICAgICAgICAgICAgICAgICAgICAgd2hl biAiLi4vZGlyZWN0aW9uID0gJ3Jlc3BvbnNlJyI7CiAgICAgICAgICAgICAgICAgICAgICAgfQoK ICAgICAgICAgICAgICAgICAgICAgICB1c2VzIGFjbDpGSUxURVItQ09NTU9OOwoKICAgICAgICAg ICAgICAgICAgICB9ICAvLyBjb250YWluZXIgZmlsdGVycwoKICAgICAgICAgICAgICAgICAgICB1 c2VzIGFjbDpBQ0UtQ09NTU9OOwoKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMg QXVndXN0IDI5LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgNzBdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEz CgoKICAgICAgICAgICAgICAgICAgfSAvLyBjYXNlIGFycC1hY2UKICAgICAgICAgICAgICAgIH0g IC8vIGNob2ljZSByZW1hcmstb3ItYXJwLWFjZQogICAgICAgICAgICAgIH0gIC8vIGxpc3QgYXJw LWFjZQogICAgICAgICAgfSAvLyBjb250YWluZXIgYXJwLWFjZXMKICAgICAgfSAvLyBhdWdtZW50 CgogIH0KCiAgPC9DT0RFIEVORFM+CgoxNC4gIENPTU1PTi1UWVBFUyBZQU5HIE1vZHVsZQoKIDxD T0RFIEJFR0lOUz4gZmlsZSAiY29tbW9uLXR5cGVzQDIwMTItMTAtMTIueWFuZyIKCiBtb2R1bGUg Y29tbW9uLXR5cGVzIHsKICAgICBuYW1lc3BhY2UgInVybjpjaXNjbzpwYXJhbXM6eG1sOm5zOnlh bmc6Y29tbW9uLXR5cGVzIjsKICAgICAvLyByZXBsYWNlIHdpdGggSUFOQSBuYW1lc3BhY2Ugd2hl biBhc3NpZ25lZAogICAgIHByZWZpeCBjLXR5cGVzOwoKCiAgICAgb3JnYW5pemF0aW9uCiAgICAg ICAgIklFVEYgTkVUTU9EIChORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UpIFdvcmtpbmcg R3JvdXAiOwoKICAgICBjb250YWN0CiAgICAgICAgICJXRyBXZWI6IGh0dHA6Ly90b29scy5pZXRm Lm9yZy93Zy9uZXRtb2QvCiAgICAgICAgIFdHIExpc3Q6IG5ldG1vZEBpZXRmLm9yZwoKICAgICAg ICAgV0cgQ2hhaXI6IERhdmlkIEtlc3NlbnMKICAgICAgICAgZGF2aWQua2Vzc2Vuc0Buc24uY29t CgogICAgICAgICBXRyBDaGFpcjogSnVlcmdlbiBTY2hvZW53YWVsZGVyCiAgICAgICAgIGouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZQoKICAgICAgICAgRWRpdG9yOiBMaXNhIEh1 YW5nCiAgICAgICAgIHlpaHVhbkBjaXNjby5jb20KCiAgICAgICAgIEVkaXRvcjogQWxleGFuZGVy IENsZW1tCiAgICAgICAgIGFsZXhAY2lzY28uY29tCgogICAgICAgICBFZGl0b3I6IEFuZHkgQmll cm1hbgogICAgICAgICBhbmR5QHl1bWF3b3Jrcy5jb20iOwoKICAgICAgZGVzY3JpcHRpb24KICAg ICAgICAgIlRoaXMgbW9kdWxlIGNvbnRhaW5zIGEgY29sbGVjdGlvbiBvZiBnZW5lcmFsbHkgdXNl ZnVsCiAgICAgICAgIFlBTkcgdHlwZXMgY291bGQgYmUgcmVmZXJyZWQgZnJvbSBtdWx0aXBsZSBz cGVjaWFsaXR5CiAgICAgICAgIGNvbXBvbmVudHMuCgogICAgICAgICBUZXJtcyBhbmQgQWNyb255 bXMKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgNzFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5 YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgIENvUyAo Y29zKTogQ2xhc3Mgb2YgU2VydmljZQoKICAgICAgICAgIElDTVAgKGljbXApOiBJbnRlcm5ldCBD b250cm9sIE1lc3NhZ2UgUHJvdG9jb2wKCiAgICAgICAgICBJR01QIChpZ21wKTogSW50ZXJuZXQg R3JvdXAgTWFuYWdlbWVudCBQcm90b2NvbAoKICAgICAgICAgIElQIChpcCk6IEludGVybmV0IFBy b3RvY29sCgogICAgICAgICAgSVB2NCAoaXB2NCk6SW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA0 CgogICAgICAgICAgSVB2NiAoaXB2Nik6IEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNgoKICAg ICAgICAgIFRDUCAodGNwKTogVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wKCiAgICAgICAg ICBUb1MgKHRvcyk6IFR5cGUgb2YgU2VydmljZQoKICAgICAgICAgIFRUTCAodHRsKTogVGltZSB0 byBMaXZlCgogICAgICAgICAgVURQICh1ZHApOiBVc2VyIERhdGFncmFtIFByb3RvY29sCgogICAg ICAgICAgVkxBTiAodmxhbik6IFZpcnR1YWwgTG9jYWwgQXJlYSBOZXR3b3JrCiAgICAgICAgICAi OwogICAgIHJldmlzaW9uIDIwMTItMTAtMTIgewogICAgICAgICBkZXNjcmlwdGlvbiAiSW5pdGlh bCByZXZpc2lvbi4gIjsKICAgICB9CgogICAgIC8qIFR5cGVkZWZzICovCgogICAgIHR5cGVkZWYg IGNvcyB7CiAgICAgICAgIHR5cGUgdWludDggewogICAgICAgICAgICAgcmFuZ2UgIjAuLjciOwog ICAgICAgICB9CiAgICAgICAgIGRlc2NyaXB0aW9uCiAgICAgICAgICAgICAiQ2xhc3Mgb2YgU2Vy dmljZS4KICAgICAgICAgICAgIEFuIGludGVnZXIgdGhhdCBpcyBpbiB0aGUgcmFuZ2Ugb2YgdGhl IGxheWVyIDIgQ29TIHZhbHVlcy4KICAgICAgICAgICAgIFRoaXMgY29ycmVzcG9uZHMgdG8gdGhl IDgwMi4xcCBhbmQgSVNMIENvUyB2YWx1ZXMuIjsKICAgICAgICAgcmVmZXJlbmNlICJJRUVFIDgw Mi4xcCI7CiAgICAgfQoKICAgICB0eXBlZGVmIHRvcyB7CiAgICAgICAgIHR5cGUgdWludDggewog ICAgICAgICAgICAgcmFuZ2UgIjAuLjE1IjsKICAgICAgICAgfQogICAgICAgICBkZXNjcmlwdGlv bgogICAgICAgICAgICAgInRvcyBzdGFuZHMgZm9yIFR5cGUgb2Ygc2VydmljZSAuCiAgICAgICAg ICAgICBUaGUgdG9zIGZpZWxkIGFyZSBmaXZlIGJpdHMgaW4gdGhlIElQdjQgaGVhZGVyLgogICAg ICAgICAgICAgSXQgY291bGQgc3BlY2lmeSBhIGRhdGFncmFtcyBwcmlvcml0eSBhbmQKICAgICAg ICAgICAgIHJlcXVlc3QgYSByb3V0ZSBmb3IgbG93LWRlbGF5LCBoaWdoLXRocm91Z2hwdXQsCgoK Ckh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAg ICAgICAgIFtQYWdlIDcyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1h Y2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgICAgICBvciBoaWdo bHktcmVsaWFibGUgc2VydmljZS4KCiAgICAgICAgICAgICBCYXNlZCBvbiB0aGVzZSBUT1MgdmFs dWVzLCBhIHBhY2tldCB3b3VsZCBiZSBwbGFjZWQgaW4KICAgICAgICAgICAgIGFuIHByaW9yaXRp emVkIG91dGdvaW5nIHF1ZXVlLCBvciB0YWtlIGEgcm91dGUgd2l0aAogICAgICAgICAgICAgYXBw cm9wcmlhdGUgbGF0ZW5jeSwgdGhyb3VnaHB1dCwgb3IgcmVsaWFiaWxpdHkuCiAgICAgICAgICAg ICBUaGUgZm9sbG93aW5nIGFyZSBUT1MgZmllbGQgdmFsdWVzIChleHByZXNzZWQgYXMKICAgICAg ICAgICAgIGJpbmFyeSBudW1iZXJzKToKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTAw MCAgIC0tICAgbWluaW1pemUgZGVsYXkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwMTAw ICAgLS0gICBtYXhpbWl6ZSB0aHJvdWdocHV0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MDAxMCAgIC0tICAgbWF4aW1pemUgcmVsaWFiaWxpdHkKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAwMDAxICAgLS0gICBtaW5pbWl6ZSBtb25ldGFyeSBjb3N0CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMDAwMCAgIC0tICAgbm9ybWFsIHNlcnZpY2UKCiAgICAgICAgICAgIC4iOwoK ICAgICAgICAgcmVmZXJlbmNlCiAgICAgICAgICAgICAgIlJGQyA3OTEgSW50ZXJuZXQgUHJvdG9j b2wKICAgICAgICAgICAgICAgICBQcm90b2NvbCBTcGVjaWZpY2F0aW9uCiAgICAgICAgICAgICAg UkZDIDExMjIgUmVxdWlyZW1lbnRzIGZvciBJbnRlcm5ldCBIb3N0cyAtLQogICAgICAgICAgICAg ICAgIENvbW11bmljYXRpb24gTGF5ZXJzCiAgICAgICAgICAgICAgUkZDIDEzNDkgVHlwZSBvZiBT ZXJ2aWNlIGluIHRoZSBJbnRlcm5ldCBQcm90b2NvbAogICAgICAgICAgICAgICAgIFN1aXRlCiAg ICAgICAgICAgICAgUkZDIDI0NzQgRGVmaW5pdGlvbiBvZiB0aGUgRGlmZmVyZW50aWF0ZWQgU2Vy dmljZXMKICAgICAgICAgICAgICAgICBGaWVsZCAoRFMgRmllbGQpCiAgICAgICAgICAgICAgICAg ICAgICAgaW4gdGhlIElQdjQgYW5kIElQdjYgSGVhZGVycwogICAgICAgICAgICAgIFJGQyAzMTY4 IFRoZSBBZGRpdGlvbiBvZiBFeHBsaWNpdCBDb25nZXN0aW9uCiAgICAgICAgICAgICAgICAgTm90 aWZpY2F0aW9uIChFQ04pIHRvIElQCiAgICAgICAgICAgICAgIjsKICAgICB9CgogICAgIHR5cGVk ZWYgIHByZWNlZGVuY2UgewogICAgICAgICB0eXBlIHVpbnQ4IHsKICAgICAgICAgICAgIHJhbmdl ICIwLi43IjsKICAgICAgICAgfQogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgIklu ZGljYXRlcyB0aGUgSVAgcHJlY2VkZW5jZS4KICAgICAgICAgICAgIFByZWNlZGVuY2UgaXMgdGhy ZWUgYml0cyBpbiBJUCBoZWFkZXIuCgogICAgICAgICAgICAgVmFsdWUgICAgICAgRGVzY3JpcHRp b24KICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgICAgICAgIDAwMCAoMCkg ICAgIFJvdXRpbmUgb3IgQmVzdCBFZmZvcnQKICAgICAgICAgICAgIDAwMSAoMSkgICAgIFByaW9y aXR5CiAgICAgICAgICAgICAwMTAgKDIpICAgICBJbW1lZGlhdGUKICAgICAgICAgICAgIDAxMSAo MykgICAgIEZsYXNoIC0gbWFpbmx5IHVzZWQgZm9yIFZvaWNlIFNpZ25hbGluZwogICAgICAgICAg ICAgICAgICAgICAgICAgb3IgZm9yIFZpZGVvLgogICAgICAgICAgICAgMTAwICg0KSAgICAgRmxh c2ggT3ZlcnJpZGUKICAgICAgICAgICAgIDEwMSAoNSkgICAgIENyaXRpY2FsIC1tYWlubHkgdXNl ZCBmb3IgVm9pY2UgUlRQLgoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBBdWd1 c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA3M10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTMKCgog ICAgICAgICAgICAgMTEwICg2KSAgICAgSW50ZXJuZXQKICAgICAgICAgICAgIDExMSAoNykgICAg IE5ldHdvcmsiOwoKICAgICAgICAgcmVmZXJlbmNlCiAgICAgICAgICAgICAiUkZDIDc5MSBJbnRl cm5ldCBQcm90b2NvbCBDaGFwdGVyIDMuMQogICAgICAgICAgICAgUHJvdG9jb2wgU3BlY2lmaWNh dGlvbiI7CiAgICAgfQoKICAgICB0eXBlZGVmIHRjcC1mbGFnLXR5cGUgewogICAgICAgICB0eXBl IGJpdHMgewogICAgICAgICAgICAgYml0IGZpbiB7CiAgICAgICAgICAgICAgICAgcG9zaXRpb24g MDsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiTm8gbW9yZSBkYXRhIGZyb20gc2VuZGVy IjsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIGJpdCBzeW4gewogICAgICAgICAgICAgICAg IHBvc2l0aW9uIDE7CiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24gIlN5bmNocm9uaXplIHNl cXVlbmNlIG51bWJlcnMiOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgYml0IHJzdCB7CiAg ICAgICAgICAgICAgICAgcG9zaXRpb24gMjsKICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAi UmVzZXQgdGhlIGNvbm5lY3Rpb24iOwogICAgICAgICAgICAgfQogICAgICAgICAgICAgYml0IHBz aCB7CiAgICAgICAgICAgICAgICAgcG9zaXRpb24gMzsKICAgICAgICAgICAgICAgICBkZXNjcmlw dGlvbiAiUHVzaCBGdW5jdGlvbiI7CiAgICAgICAgICAgICB9CiAgICAgICAgICAgICBiaXQgYWNr IHsKICAgICAgICAgICAgICAgICBwb3NpdGlvbiA0OwogICAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uICJBY2tub3dsZWRnbWVudCBmaWVsZCBzaWduaWZpY2FudCI7CiAgICAgICAgICAgICB9CiAg ICAgICAgICAgICBiaXQgdXJnIHsKICAgICAgICAgICAgICAgICBwb3NpdGlvbiA1OwogICAgICAg ICAgICAgICAgIGRlc2NyaXB0aW9uICJVcmdlbnQgUG9pbnRlciBmaWVsZCBzaWduaWZpY2FudCI7 CiAgICAgICAgICAgICB9CiAgICAgICAgIH0KICAgICAgICAgZGVzY3JpcHRpb24gIlRDUCBmbGFn IHR5cGUiOwogICAgICAgICByZWZlcmVuY2UgIlJGQyA3OTMgVFJBTlNNSVNTSU9OIENPTlRST0wg UFJPVE9DT0wiOwogICAgIH0KCiAgICAgdHlwZWRlZiBldGhlci10eXBlIHsKICAgICAgICAgdHlw ZSBzdHJpbmcgewogICAgICAgICAgICAgcGF0dGVybiAnMHhbMC05YS1mQS1GXXs0fSc7CiAgICAg ICAgIH0KICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICAgICAiZXRoZXItdHlwZSBp cyAweDAtMHhmZmZmLiBUaGUgcHJvdG9jb2wgbnVtYmVyCiAgICAgICAgICAgICAgICAgaXMgYSBm b3VyLWJ5dGUgaGV4YWRlY2ltYWwgbnVtYmVyIHByZWZpeGVkIHdpdGggMHguCiAgICAgICAgICAg ICAgICAgVmFsaWQgcHJvdG9jb2wgbnVtYmVycyBhcmUgZnJvbSAweDAgdG8gMHhmZmZmLgoKCgoK SHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAgICAg ICAgICAgW1BhZ2UgNzRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5nLWFj bCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAgICBUaGlz IGxpc3Qgc2hvd3MgdGhlIEV0aGVyVHlwZSB2YWx1ZXMgYW5kIHRoZWlyCiAgICAgICAgICAgICAg ICAgY29ycmVzcG9uZGluZyBwcm90b2NvbCBrZXl3b3JkczoKCiAgICAgICAgICAgICAgICAgMHgw NjAwIHhucy1pZHAgWGVyb3ggWE5TIElEUAoKICAgICAgICAgICAgICAgICAweDBCQUQgdmluZXMt aXAgQmFueWFuIFZJTkVTIElQCgogICAgICAgICAgICAgICAgIDB4MGJhZiB2aW5lcy1lY2hvIEJh bnlhbiBWSU5FUyBFY2hvCgogICAgICAgICAgICAgICAgIDB4NjAwMCBldHlwZS02MDAwIERFQyB1 bmFzc2lnbmVkLCBleHBlcmltZW50YWwKCiAgICAgICAgICAgICAgICAgMHg2MDAxIG1vcC1kdW1w IERFQyBNYWludGVuYW5jZSBPcGVyYXRpb24gUHJvdG9jb2wKICAgICAgICAgICAgICAgICAgICAg KE1PUCkgRHVtcC9Mb2FkIEFzc2lzdGFuY2UKCiAgICAgICAgICAgICAgICAgMHg2MDAyIG1vcC1j b25zb2xlIERFQyBNT1AgUmVtb3RlIENvbnNvbGUKCiAgICAgICAgICAgICAgICAgMHg2MDAzIGRl Y25ldC1pdiBERUMgREVDbmV0IFBoYXNlIElWIFJvdXRlCgogICAgICAgICAgICAgICAgIDB4NjAw NCBsYXQgREVDIExvY2FsIEFyZWEgVHJhbnNwb3J0IChMQVQpCgogICAgICAgICAgICAgICAgIDB4 NjAwNSBkaWFnbm9zdGljIERFQyBERUNuZXQgRGlhZ25vc3RpY3MKCiAgICAgICAgICAgICAgICAg MHg2MDA3IGxhdmMtc2NhIERFQyBMb2NhbC1BcmVhIFZBWCBDbHVzdGVyIChMQVZDKSwgU0NBCgog ICAgICAgICAgICAgICAgIDB4NjAwOCBhbWJlciBERUMgQU1CRVIKCiAgICAgICAgICAgICAgICAg MHg2MDA5IG11bXBzIERFQyBNVU1QUwoKICAgICAgICAgICAgICAgICAweDA4MDAgaXAgTWFsZm9y bWVkLCBpbnZhbGlkLCBvciBkZWxpYmVyYXRlbHkgY29ycnVwdAogICAgICAgICAgICAgICAgICAg ICBJUCBmcmFtZXMKCiAgICAgICAgICAgICAgICAgMHg4MDM4IGRlYy1zcGFubmluZyBERUMgTEFO QnJpZGdlIE1hbmFnZW1lbnQKCiAgICAgICAgICAgICAgICAgMHg4MDM5IGRzbSBERUMgRFNNL0RE UAoKICAgICAgICAgICAgICAgICAweDgwNDAgbmV0YmlvcyBERUMgUEFUSFdPUktTIERFQ25ldCBO RVRCSU9TIEVtdWxhdGlvbgoKICAgICAgICAgICAgICAgICAweDgwNDEgbXNkb3MgREVDIExvY2Fs IEFyZWEgU3lzdGVtIFRyYW5zcG9ydAoKICAgICAgICAgICAgICAgICAweDgwNDIgZXR5cGUtODA0 MiBERUMgdW5hc3NpZ25lZAoKICAgICAgICAgICAgICAgICAweDgwOUIgYXBwbGV0YWxrIEtpbmV0 aWNzIEV0aGVyVGFsayAoQXBwbGVUYWxrIG92ZXIKICAgICAgICAgICAgICAgICAgICAgRXRoZXJu ZXQpCgogICAgICAgICAgICAgICAgIDB4ODBGMyBhYXJwIEtpbmV0aWNzIEFwcGxlVGFsayBBZGRy ZXNzIFJlc29sdXRpb24KICAgICAgICAgICAgICAgICAgICAgUHJvdG9jb2wgKEFBUlApCgogICAg ICAgICAgICAgICAgIGJwZHUtc2FwICAgICAgQlBEVSBTQVAgZW5jYXBzdWxhdGVkIHBhY2tldHMK CgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAyMDEzICAgICAg ICAgICAgICAgW1BhZ2UgNzVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICB5YW5n LWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICAgICAgICAgICAgICBi cGR1LXNuYXAgICAgIEJQRFUgU05BUCBlbmNhcHN1bGF0ZWQgcGFja2V0cwogICAgICAgICAgICAg ICAgIGlweC1hcnBhICAgICAgSVBYIEFkdmFuY2VkIFJlc2VhcmNoIFByb2plY3RzIEFnZW5jeQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChBUlBBKQogICAgICAgICAgICAgICAgIGlweC1u b24tYXJwYSAgSVBYIG5vbiBhcnBhCiAgICAgICAgICAgICAgICAgbGFjcCAgICAgICAgICBMaW5r IEFnZ3JlZ2F0aW9uIENvbnRyb2wgUHJvdG9jb2woTEFDUCkKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBlbmNhcHN1bGF0ZWQgcGFja2V0cwogICAgICAgICAgICAgICAgIHBhZ3AgICAgICAg ICAgUG9ydCBBZ2dyZWdhdGlvbiBQcm90b2NvbChQQUdQKQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGVuY2Fwc3VsYXRlZCBwYWNrZXRzCiAgICAgICAgICAgICAgICAgdnRwICAgICAgICAg ICBWVFAgcGFja2V0cwogICAgICAgICAgICAgICAgICI7CiAgICAgfQoKICAgICB0eXBlZGVmIGlw LXByb3RvY29sIHsKICAgICAgICAgdHlwZSB1aW50OHsKICAgICAgICAgICAgcmFuZ2UgIjAuLjI1 NSI7CiAgICAgICAgIH0KICAgICAgICAgZGVzY3JpcHRpb24KICAgICAgICAgICAgICJUaGUgSW50 ZXJuZXQgUHJvdG9jb2wgKElQKSBpcyB0aGUgcHJpbmNpcGFsIGNvbW11bmljYXRpb25zCiAgICAg ICAgICAgICBwcm90b2NvbCB1c2VkIGZvciByZWxheWluZyBkYXRhZ3JhbXMgKGFsc28ga25vd24g YXMgbmV0d29yawogICAgICAgICAgICAgcGFja2V0cykgYWNyb3NzIGFuIGludGVybmV0d29yayB1 c2luZyB0aGUgSW50ZXJuZXQgUHJvdG9jb2wKICAgICAgICAgICAgIFN1aXRlLgoKICAgICAgICAg ICAgIElQIHByb3RvY29sIG51bWJlciB2YWx1ZSBpcyAwIHRvIDI1NS4gSXQgaXMgYW4gOCBiaXQg ZmllbGQKICAgICAgICAgICAgIGluIHRoZSBwYWNrZXQgaGVhZGVyIjsKICAgICAgICAgcmVmZXJl bmNlCiAgICAgICAgICAgICAiSUFOQSBQcm90b2NvbCBOdW1iZXJzCiAgICAgICAgICAgICBSRkM1 MjM3IElBTkEgQWxsb2NhdGlvbiBHdWlkZWxpbmVzIGZvciB0aGUgUHJvdG9jb2wgRmllbGQiOwog ICAgIH0KCiAgICAgdHlwZWRlZiBpZ21wLWNvZGUgewogICAgICAgICAvL1RPRE86IG5lZWQgbW9y ZSB3b3JrLiBJbiBOeE9zLCByYW5nZSBpcyAwLi4xNS4KICAgICAgICAgLy8gQ291bGQgbm90IG1h dGNoIHRoZSBJR01QIHdpdGggMC4uMTUKICAgICAgICAgdHlwZSB1aW50OCA7LyogewogICAgICAg ICAgICAgcmFuZ2UgIjAuLjE1IjsKICAgICAgICAgfSovCiAgICAgICAgIC8vSUdNUCB2MSA0IGJp dHMgMC0xNQogICAgICAgICAvL0lHTVAgdjIgOGJpdHMuIDAtCiAgICAgICAgIC8vTlhPUyBvbmx5 IHN1cHBvcnQgdjEsIGJ1dCBYUiBzdXBwb3J0IHYyLgogICAgICAgICAvLwoKICAgICAgICAgZGVz Y3JpcHRpb24KICAgICAgICAgICAgICJNYW55IG9mIHRoZXNlIElHTVAgdHlwZXMgaGF2ZSBhICdj b2RlJyBmaWVsZC4gIEhlcmUgaXMKICAgICAgICAgICAgIHRoZSBsaXN0IG9mIHRoZSB0eXBlcyBh Z2FpbiB3aXRoIHRoZWlyIGFzc2lnbmVkCiAgICAgICAgICAgICBjb2RlIGZpZWxkcy4KCiAgICAg ICAgICAgICBUeXBlICAgICAgIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UmVmZXJlbmNlCiAgICAgICAgICAgICAtLS0tLS0tLS0gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSAgLS0tLS0tLS0tCiAgICAgICAgICAgICAweDExICAgICAgIElHTVAgTWVt YmVyc2hpcCBRdWVyeSAgICAgICAgICAgICAgICAgW1JGQzExMTJdCgoKCkh1YW5nLCBldCBhbC4g ICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDc2 XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgeWFuZy1hY2wgICAgICAgICAgICAg ICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgICAgICAweDEyICAgICAgIElHTVB2MSBNZW1i ZXJzaGlwIFJlcG9ydCAgICAgICAgICAgICAgW1JGQzExMTJdCiAgICAgICAgICAgICAweDEzICAg ICAgIERWTVJQICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1JGQ0RWTVJQXQogICAg ICAgICAgICAgMHgxNCAgICAgICBQSU0gdmVyc2lvbiAxICAgICAgICAgICAgICAgICAgICAgICAg IFtQSU12MV0KICAgICAgICAgICAgIDB4MTUgICAgICAgQ2lzY28gVHJhY2UgTWVzc2FnZXMKICAg ICAgICAgICAgIDB4MTYgICAgICAgSUdNUHYyIE1lbWJlcnNoaXAgUmVwb3J0ICAgICAgICAgICAg ICBbUkZDMjIzNl0KICAgICAgICAgICAgIDB4MTcgICAgICAgSUdNUHYyIExlYXZlIEdyb3VwICAg ICAgICAgICAgICAgICAgICBbUkZDMjIzNl0KICAgICAgICAgICAgIDB4MWUgICAgICAgTXVsdGlj YXN0IFRyYWNlcm91dGUgUmVzcG9uc2UgICAgICAgICBbRmVubmVyXQogICAgICAgICAgICAgMHgx ZiAgICAgICBNdWx0aWNhc3QgVHJhY2Vyb3V0ZSAgICAgICAgICAgICAgICAgIFtGZW5uZXJdCiAg ICAgICAgICAgICAweDIyICAgICAgIElHTVB2MyBNZW1iZXJzaGlwIFJlcG9ydCAgICAgICAgICAg ICAgW1JGQzMzNzZdCiAgICAgICAgICAgICAiOwogICAgICAgICByZWZlcmVuY2UKICAgICAgICAg ICAgICJJQU5BIEludGVybmV0IEdyb3VwIE1hbmFnZW1lbnQgUHJvdG9jb2wgKElHTVApIFR5cGUK ICAgICAgICAgICAgIE51bWJlcnMiOwogICAgIH0KCiAgICAgdHlwZWRlZiBpY21wLXR5cGUgewog ICAgICAgICB0eXBlIHVpbnQzMiB7CiAgICAgICAgICAgICByYW5nZSAiMC4uMjU1IjsKICAgICAg ICAgfQogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgICAgImljbXAtdHlwZSBpcyB0aGUg SW50ZXJuZXQgQ29udHJvbCBNZXNzYWdlIFByb3RvY29sIChJQ01QKQogICAgICAgICAgICAgJ3R5 cGUnIGZpZWxkLgogICAgICAgICAgICAgVGhlIElDTVAgaGVhZGVyIHN0YXJ0cyBhZnRlciB0aGUg SVB2NCBoZWFkZXIuIEFsbCBJQ01QCiAgICAgICAgICAgICBwYWNrZXRzIHdpbGwgaGF2ZSBhbiA4 LWJ5dGUgaGVhZGVyIGFuZCB2YXJpYWJsZS1zaXplZAogICAgICAgICAgICAgZGF0YSBzZWN0aW9u LgogICAgICAgICAgICAgVGhlIGZpcnN0IDQgYnl0ZXMgb2YgdGhlIGhlYWRlciB3aWxsIGJlIGNv bnNpc3RlbnQuCiAgICAgICAgICAgICBUaGUgZmlyc3QgYnl0ZSBpcyBmb3IgdGhlIElDTVAgdHlw ZS4gVGhlIHNlY29uZCBieXRlIGlzCiAgICAgICAgICAgICBmb3IgdGhlIElDTVAgY29kZS4KICAg ICAgICAgICAgIElDTVAgdHlwZSBpcyBzcGVjaWZpZWQgYmVsb3cKCiAgICAgICAgICAgICBUeXBl ICAgIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UKICAg ICAgICAgICAgIC0tLS0gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAg IC0tLS0tLS0tLQogICAgICAgICAgICAgICAwICAgICBFY2hvIFJlcGx5ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtSRkM3OTJdCiAgICAgICAgICAgICAgIDEgICAgIFVuYXNzaWduZWQg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW0pCUF0KICAgICAgICAgICAgICAgMiAg ICAgVW5hc3NpZ25lZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbSkJQXQogICAg ICAgICAgICAgICAzICAgICBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSAgICAgICAgICAgICAgICAg IFtSRkM3OTJdCiAgICAgICAgICAgICAgIDQgICAgIFNvdXJjZSBRdWVuY2ggICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1JGQzc5Ml0KICAgICAgICAgICAgICAgNSAgICAgUmVkaXJlY3QgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUkZDNzkyXQogICAgICAgICAgICAgICA2ICAg ICBBbHRlcm5hdGUgSG9zdCBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgIFtKQlBdCiAgICAg ICAgICAgICAgIDcgICAgIFVuYXNzaWduZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW0pCUF0KICAgICAgICAgICAgICAgOCAgICAgRWNobyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbUkZDNzkyXQogICAgICAgICAgICAgICA5ICAgICBSb3V0ZXIgQWR2ZXJ0 aXNlbWVudCAgICAgICAgICAgICAgICAgICAgW1JGQzEyNTZdCiAgICAgICAgICAgICAgMTAgICAg IFJvdXRlciBTZWxlY3Rpb24gICAgICAgICAgICAgICAgICAgICAgICBbUkZDMTI1Nl0KICAgICAg ICAgICAgICAxMSAgICAgVGltZSBFeGNlZWRlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UkZDNzkyXQogICAgICAgICAgICAgIDEyICAgICBQYXJhbWV0ZXIgUHJvYmxlbSAgICAgICAgICAg ICAgICAgICAgICAgIFtSRkM3OTJdCiAgICAgICAgICAgICAgMTMgICAgIFRpbWVzdGFtcCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1JGQzc5Ml0KICAgICAgICAgICAgICAxNCAgICAg VGltZXN0YW1wIFJlcGx5ICAgICAgICAgICAgICAgICAgICAgICAgICBbUkZDNzkyXQogICAgICAg ICAgICAgIDE1ICAgICBJbmZvcm1hdGlvbiBSZXF1ZXN0ICAgICAgICAgICAgICAgICAgICAgIFtS RkM3OTJdCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwgMjAx MyAgICAgICAgICAgICAgIFtQYWdlIDc3XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgeWFuZy1hY2wgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAxMwoKCiAgICAgICAgICAg ICAgMTYgICAgIEluZm9ybWF0aW9uIFJlcGx5ICAgICAgICAgICAgICAgICAgICAgICAgW1JGQzc5 Ml0KICAgICAgICAgICAgICAxNyAgICAgQWRkcmVzcyBNYXNrIFJlcXVlc3QgICAgICAgICAgICAg ICAgICAgICBbUkZDOTUwXQogICAgICAgICAgICAgIDE4ICAgICBBZGRyZXNzIE1hc2sgUmVwbHkg ICAgICAgICAgICAgICAgICAgICAgIFtSRkM5NTBdCiAgICAgICAgICAgICAgMTkgICAgIFJlc2Vy dmVkIChmb3IgU2VjdXJpdHkpICAgICAgICAgICAgICAgICAgICBbU29sb10KICAgICAgICAgICAg ICAyMC0yOSAgUmVzZXJ2ZWQgKGZvciBSb2J1c3RuZXNzIEV4cGVyaW1lbnQpICAgICAgICBbWlN1 XQogICAgICAgICAgICAgIDMwICAgICBUcmFjZXJvdXRlICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1JGQzEzOTNdCiAgICAgICAgICAgICAgMzEgICAgIERhdGFncmFtIENvbnZlcnNpb24g RXJyb3IgICAgICAgICAgICAgICBbUkZDMTQ3NV0KICAgICAgICAgICAgICAzMiAgICAgTW9iaWxl IEhvc3QgUmVkaXJlY3QgICAgICAgICAgICAgIFtEYXZpZCBKb2huc29uXQogICAgICAgICAgICAg IDMzICAgICBJUHY2IFdoZXJlLUFyZS1Zb3UgICAgICAgICAgICAgICAgIFtCaWxsIFNpbXBzb25d CiAgICAgICAgICAgICAgMzQgICAgIElQdjYgSS1BbS1IZXJlICAgICAgICAgICAgICAgICAgICAg W0JpbGwgU2ltcHNvbl0KICAgICAgICAgICAgICAzNSAgICAgTW9iaWxlIFJlZ2lzdHJhdGlvbiBS ZXF1ZXN0ICAgICAgICBbQmlsbCBTaW1wc29uXQogICAgICAgICAgICAgIDM2ICAgICBNb2JpbGUg UmVnaXN0cmF0aW9uIFJlcGx5ICAgICAgICAgIFtCaWxsIFNpbXBzb25dCiAgICAgICAgICAgICAg MzctMjU1IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW0pCUF0i OwogICAgICAgICByZWZlcmVuY2UKICAgICAgICAgICAgICJSRkMxNzAwIEFTU0lHTkVEIE5VTUJF UlMKICAgICAgICAgICAgIFJGQzc5MiBJbnRlcm5ldCBDb250cm9sIE1lc3NhZ2UgUHJvdG9jb2wK ICAgICAgICAgICAgIFJGQzQ0NDMgSW50ZXJuZXQgQ29udHJvbCBNZXNzYWdlIFByb3RvY29sIChJ Q01QdjYpCiAgICAgICAgICAgICAgICAgZm9yIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBWZXJzaW9u IDYgKElQdjYpCiAgICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbgogICAgICAgICAgICAgUkZD Mjc4MCBJQU5BIEFsbG9jYXRpb24gR3VpZGVsaW5lcyBGb3IgVmFsdWVzIEluCiAgICAgICAgICAg ICAgICAgdGhlIEludGVybmV0IFByb3RvY29sIGFuZCBSZWxhdGVkIEhlYWRlcnMiOwogICAgIH0K CiAgICAgdHlwZWRlZiBpY21wLWNvZGUgewogICAgICAgICB0eXBlIHVpbnQzMiB7CiAgICAgICAg ICAgICByYW5nZSAiMC4uMjU1IjsKICAgICAgICAgfQogICAgICAgICBkZXNjcmlwdGlvbgogICAg ICAgICAgICAgIklDTVAgc3VidHlwZSB0byB0aGUgZ2l2ZW4gdHlwZS4KICAgICAgICAgICAgIFRo ZSBJQ01QIGhlYWRlciBzdGFydHMgYWZ0ZXIgdGhlIElQdjQgaGVhZGVyLiBBbGwgSUNNUAogICAg ICAgICAgICAgcGFja2V0cyB3aWxsIGhhdmUgYW4gOC1ieXRlIGhlYWRlciBhbmQgdmFyaWFibGUt c2l6ZWQKICAgICAgICAgICAgIGRhdGEgc2VjdGlvbi4KICAgICAgICAgICAgIFRoZSBmaXJzdCA0 IGJ5dGVzIG9mIHRoZSBoZWFkZXIgd2lsbCBiZSBjb25zaXN0ZW50LgogICAgICAgICAgICAgVGhl IGZpcnN0IGJ5dGUgaXMgZm9yIHRoZSBJQ01QIHR5cGUuIFRoZSBzZWNvbmQgYnl0ZQogICAgICAg ICAgICAgaXMgZm9yIHRoZSBJQ01QIGNvZGUuICI7CiAgICAgICAgIHJlZmVyZW5jZSAiUkZDMiBJ TlRFUk5FVCBDT05UUk9MIE1FU1NBR0UgUFJPVE9DT0wiOwogICAgIH0KCiAgICAgdHlwZWRlZiB2 bGFuLWlkZW50aWZpZXIgewogICAgICAgICB0eXBlIHVpbnQxNiB7CiAgICAgICAgICAgICByYW5n ZSAiMSAuLiA0MDk1IjsKICAgICAgICAgfQogICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAg ICAgICAgICJUaGlzIHR5cGUgZGVub3RlcyBhIFZMQU4gdGFnLiAgIjsKICAgICAgICAgcmVmZXJl bmNlCiAgICAgICAgICAgICAiUkZDMzA2OSBWTEFOIEFnZ3JlZ2F0aW9uIGZvciBFZmZpY2llbnQg SVAgQWRkcmVzcwogICAgICAgICAgICAgICAgIEFsbG9jYXRpb24KICAgICAgICAgICAgIElFRUUg ODAyLjFRIjsKCgoKSHVhbmcsIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI5LCAy MDEzICAgICAgICAgICAgICAgW1BhZ2UgNzhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICB5YW5nLWFjbCAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDEzCgoKICAgICB9Cgog ICAgIHR5cGVkZWYgdGltZS10by1saXZlIHsKICAgICAgICAgdHlwZSB1aW50OCB7CiAgICAgICAg ICAgICByYW5nZSAiMC4uMjU1IjsKICAgICAgICAgfQogICAgICAgICBkZXNjcmlwdGlvbiAiVGhl IFRUTCBpcyBhbiA4LWJpdCBmaWVsZCBpbiBJUCBoZWFkZXIuCiAgICAgICAgICAgICBUaGUgbWF4 aW11bSBUVEwgdmFsdWUgaXMgMjU1LiI7CiAgICAgfQogfQoKIDwvQ09ERSBFTkRTPgoKMTUuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgLgoKMTYuICBPcGVuIGl0ZW1zIGZyb20gdGhlIHBy ZXZpb3VzIHJldmlzaW9uCgogICAgICAxLiAgQXJlIHRoZXJlIGFueSBjb21wYXRpYmlsaXR5IGlz c3VlcyByZWxhdGVkIHRvIEFDRSBvcmRlcmluZwogICAgICBiZWNhdXNlIGEgWUFORyB1c2VyLW9y ZGVyIGxpc3QgaXMgdXNlZCBpbnN0ZWFkIG9mIHNlcXVlbmNlIElEcz8KICAgICAgVGhpcyBpdGVt IGlzIGNsb3NlbHkgcmVsYXRlZCB0byBidWxsZXQgaXRlbSAzLCBzZWUgYmVsb3cuCgogICAgICAy LiAgSXMgYW4gYWRtaW5pc3RyYXRpdmUgZnVuY3Rpb24gdG8gdGVzdCBhIHBhY2tldCBhZ2FpbnN0 IGEKICAgICAgc3BlY2lmaWVkIEFDTCBuZWVkZWQ/ICBUaGUgc2VydmVyIHdvdWxkIHJldHVybiBh biBpbmRpY2F0aW9uIG9mCiAgICAgIHBlcm1pdCBvciBkZW55LCBhbmQgYSBsZWFmLWxpc3Qgb2Yg dGhlIEFDRSBlbnRyaWVzIHRoYXQgd2VyZQogICAgICBldmFsdWF0ZWQuICBXZSBiZWxpZXZlIHRo YXQgdGhpcyBhZGRpdGlvbiB3b3VsZCBiZSB2YWx1YWJsZSBhbmQKICAgICAgaGF2ZSBpbmNvcnBv cmF0ZWQgdGhpcyBzdWdnZXN0aW9uIGludG8gdGhlICJBZGRpdGlvbmFsCiAgICAgIENvbnNpZGVy YXRpb25zIiBzZWN0aW9uLiAgV2UgZXhwZWN0IHRvIG1vdmUgaXQgaW50byB0aGUgZGF0YSBtb2Rl bAogICAgICBpbiB0aGUgbmV4dCByZXZpc2lvbi4KCiAgICAgIDMuSXMgdGhlIG1vZGVsIGFwcGxp Y2FibGUgdG8gbXVsdGlwbGUgaW1wbGVtZW50YXRpb25zIC0gY2FuIG90aGVyCiAgICAgIEFDTCBt b2RlbHMgYmUgYWNjb21tb2RhdGVkPyAgV2UgaGF2ZSBmb2xsb3dlZCB1cCB3aXRoIEp1bmlwZXIg WWFuZwogICAgICBleHBlcnRzLCBLZW50IFdhdHNlbiBhbmQgUGhpbCBTaGFmZXIsIHRvIHJldmll dyBhbmQgY2hlY2sgZm9yCiAgICAgIGFwcGxpY2FiaWxpdHkgdG8gSnVub3MgaW1wbGVtZW50YXRp b24uICBUaGUgaW5pdGlhbCBmZWVkYmFjayBmcm9tCiAgICAgIFBoaWwgaW5kaWNhdGVzIHRoYXQg dGhlcmUgZG8gbm90IHNlZW0gdG8gYmUgYW55IHNob3dzdG9wcGVycyBhbmQKICAgICAgdGhhdCB0 aGUgbW9kZWwgZG9lcyBzZWVtIHRvIGJlIGFwcGxpY2FibGUuICBIb3dldmVyLCBoZSBzdWdnZXN0 ZWQKICAgICAgZnVydGhlciBzY3J1dGlueSBzaG91bGQgb2NjdXIuICBLZW50IGlkZW50aWZpZWQg YWRkaXRpb25hbCBKdW5pcGVyCiAgICAgIGV4cGVydHMgdG8gc2NydXRpbml6ZSB0aGUgbW9kZWwg bW9yZSBjbG9zZWx5OyBzbyBmYXIgbm8gZnVydGhlcgogICAgICBjb21tZW50cyBoYXZlIGJlZW4g cmVjZWl2ZWQuICBXZSBhbHNvIGZvbGxvd2VkIHVwIHJlZ2FyZGluZwogICAgICB3aGV0aGVyIHRo ZXJlIGFyZSBvdGhlciBzdGFuZGFyZGl6ZWQgbW9kZWxzIG9mIEFDTHMsIGZvciBleGFtcGxlCiAg ICAgIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIERlc2t0b3AgTWFuYWdlbWVudCBUYXNrIEZvcmNl J3MgKERNVEYpIENJTQogICAgICAoQ29tbW9uIEluZm9ybWF0aW9uIE1vZGVsKS4gIEFDTCBpcyBu b3QgY292ZXJlZCBieSB0aGUKICAgICAgc3RhbmRhcmRpemVkIHBvcnRpb24gb2YgQ0lNLCBidXQg dGhlcmUgYXJlIHZlbmRvci1zcGVjaWZpYwogICAgICBleHRlbnNpb25zIGJ5IHZlbmRvcnMuICBX ZSBpbnNwZWN0ZWQgb25lIHN1Y2ggdmVuZG9yIHNwZWNpZmljCiAgICAgIG1vZGVsIGFuZCBmb3Vu ZCB0aGF0IGluIGVzc2VuY2UgdGhlIHNhbWUgZGVzaWduIHBhdHRlcm5zIHdlcmUgdXNlZAogICAg ICBhcyBpbiB0aGUgbW9kZWwgc3BlY2lmaWVkIGluIHRoaXMgSW50ZXJuZXQgRHJhZnQsIHdpdGgg YW4gQUNMCiAgICAgIGNvcnJlc3BvbmRpbmcgdG8gYW4gb3JkZXJlZCBsaXN0IG9mIHJ1bGVzIHdp dGggZmlsdGVycyBvciBtYXRjaGluZwoKCgpIdWFuZywgZXQgYWwuICAgICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMjksIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA3OV0KDApJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgIHlhbmctYWNsICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDIw MTMKCgogICAgICBjcml0ZXJpYSwgYW5kIGFjdGlvbnMgdG8gYmUgdGFrZW4gaW4gcmVzcG9uc2Uu ICBJdCBhcHBlYXJzIHRoYXQKICAgICAgbWFwcGluZ3MgYmV0d2VlbiB0aGUgbW9kZWxzIGNhbiBi ZSBhY2NvbW1vZGF0ZWQgaW4gYQogICAgICBzdHJhaWdodGZvcndhcmQgbWFubmVyLgoKMTcuICBB Y2tub3dsZWRnZW1lbnRzCgogICBXZSB3aXNoIHRvIGFja25vd2xlZGdlIHRoZSBoZWxwZnVsIGNv bnRyaWJ1dGlvbnMsIGNvbW1lbnRzLCBhbmQKICAgc3VnZ2VzdGlvbnMgdGhhdCB3ZXJlIHJlY2Vp dmVkIGZyb20gTG91aXMgRm91cmllLCBEYW5hIEJsYWlyLCBUdWxhCiAgIEtyYWlzZXIsIFBhdHJp Y2sgR2lsaSwgR2VvcmdlIFNlcnBhLCBNYXJ0aW4gQmpvcmtsdW5kLCBLZW50IFdhdHNlbiwKICAg YW5kIFBoaWwgU2hhZmVyLgoKMTguICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzYwMjBd ICBCam9ya2x1bmQsIE0uLCAiWUFORyAtIEEgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSBmb3IgdGhl CiAgICAgICAgICAgICAgTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sIChORVRDT05GKSIs IFJGQyA2MDIwLAogICAgICAgICAgICAgIE9jdG9iZXIgMjAxMC4KCiAgIFtSRkM2MDIxXSAgU2No b2Vud2FlbGRlciwgSi4sICJDb21tb24gWUFORyBEYXRhIFR5cGVzIiwgUkZDIDYwMjEsCiAgICAg ICAgICAgICAgT2N0b2JlciAyMDEwLgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBMaXNhIEh1YW5n CiAgIENpc2NvIFN5c3RlbXMKCiAgIEVNYWlsOiB5aWh1YW5AY2lzY28uY29tCgoKICAgQWxleGFu ZGVyIENsZW1tCiAgIENpc2NvIFN5c3RlbXMKCiAgIEVNYWlsOiBhbGV4QGNpc2NvLmNvbQoKCiAg IEFuZHkgQmllcm1hbgogICBZdW1hV29ya3MKCiAgIEVNYWlsOiBhbmR5QHl1bWF3b3Jrcy5jb20K CgoKCgoKCgoKCgoKCkh1YW5nLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyOSwg MjAxMyAgICAgICAgICAgICAgIFtQYWdlIDgwXQoMCg== --_004_559E176269AD64429F1582D4EB94F86FCB426Axmbalnx03ciscocom_-- From j.schoenwaelder@jacobs-university.de Wed Feb 27 09:13:50 2013 Return-Path: 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 C7BD721F853C for ; Wed, 27 Feb 2013 09:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 wD12gI55B9Q9 for ; Wed, 27 Feb 2013 09:13:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B4AA721F84B9 for ; Wed, 27 Feb 2013 09:13:49 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25BED20BD6; Wed, 27 Feb 2013 18:13:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qN6AZmodyCxY; Wed, 27 Feb 2013 18:13:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B86A02095C; Wed, 27 Feb 2013 18:13:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 79FFA24C3065; Wed, 27 Feb 2013 18:13:56 +0100 (CET) Date: Wed, 27 Feb 2013 18:13:56 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130227171356.GC82136@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] draft agenda for orlando X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:13:51 -0000 Hi, I have posted a first draft of an agenda: http://tools.ietf.org/wg/netmod/agenda As you can see, we are likely not short of time since our chartered documents have stabilized and quite a few of them are ready to be delivered to Benoit. Since YANG is popping up in other contexts (i2rs WG, lmap BOF, unfortunately both taking place later during the week), it might be useful to see whether we already know any requirements coming from those activities. Perhaps we need an agenda item "YANG usage in the IETF" or something like that. (Thinking loud for the moment.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From balazs.lengyel@ericsson.com Wed Feb 27 09:37:01 2013 Return-Path: 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 AA3BC21F859A for ; Wed, 27 Feb 2013 09:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 zOMOAEi4qs7p for ; Wed, 27 Feb 2013 09:37:01 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E40D621F84E6 for ; Wed, 27 Feb 2013 09:37:00 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-5e-512e443b2afa Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F8.82.32353.B344E215; Wed, 27 Feb 2013 18:37:00 +0100 (CET) Received: from [159.107.198.117] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 27 Feb 2013 18:36:59 +0100 Message-ID: <512E443A.2070106@ericsson.com> Date: Wed, 27 Feb 2013 18:36:58 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: netmod@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvja6Ni16gwcrVjBbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY9fjP+wFe9gq3nUdZ25gfMbSxcjJISFgIjF9USsrhC0mceHe erYuRi4OIYGTjBL3Ly1lhXDWMkq8ub0ZrIpXQFvixPcf7CA2i4CqxPFbjYwgNpuAkcTU/vNA Uzk4RAWiJK7ss4QoF5Q4OfMJ2DIRAWGJic3vwMYwA5Xfe98IZgsLKEs03ZnKDBG3lbgw5zoL hC0vsf3tHLC4kICGxMMLf1knMPLPQjJ2FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAyng1t+G+xg 3HRf7BCjNAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M63Ua3V9t+fTNkPOQ nSbX9jmB7HlbN3ydGzbzWVG5Wvd0ycyTrowGO8LlX/9ncJ1d9+3r+Z4XsalSx0uf/5tiXJL4 L5mFs/6ze7Qds0Nx4Env6Nawfye2rC18530lQb/5VzZ/d/e/5JzGC2w/Apuddp6rORRwbGat +tRlf7ceVP0ez7Rtya90JZbijERDLeai4kQAZ9HEdPUBAAA= Cc: Robert Ottinger Subject: [netmod] Deprecated in Netconf/YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:37:01 -0000 Hello, As an OSS implementer can I assume that model elements marked as deprecated in a YANG module are still available to the OSS? The standard says: "deprecated" indicates an obsolete definition, but it permits new/ continued implementation in order to foster interoperability with older/existing implementations. This does not state whether as an OSS I can assume the deprecated element is still part of the interface contract or not. I think the RFC should declare whether a deprecated element MUST be or just MAY be there. What do your implementations do? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From j.schoenwaelder@jacobs-university.de Wed Feb 27 09:47:42 2013 Return-Path: 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 A50E721F8845 for ; Wed, 27 Feb 2013 09:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 IeX7s13Xb88t for ; Wed, 27 Feb 2013 09:47:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B260C21F8853 for ; Wed, 27 Feb 2013 09:47:41 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA8620BD7; Wed, 27 Feb 2013 18:47:41 +0100 (CET) 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 hFatcc9msh_b; Wed, 27 Feb 2013 18:47:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A833A20BD6; Wed, 27 Feb 2013 18:47:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2328524C324E; Wed, 27 Feb 2013 18:47:51 +0100 (CET) Date: Wed, 27 Feb 2013 18:47:51 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20130227174751.GA82388@elstar.local> Mail-Followup-To: Balazs Lengyel , netmod@ietf.org, Robert Ottinger References: <512E443A.2070106@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512E443A.2070106@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Ottinger , netmod@ietf.org Subject: Re: [netmod] Deprecated in Netconf/YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:47:42 -0000 On Wed, Feb 27, 2013 at 06:36:58PM +0100, Balazs Lengyel wrote: > Hello, > As an OSS implementer can I assume that model elements marked as > deprecated in a YANG module are still available to the OSS? > The standard says: > > "deprecated" indicates an obsolete definition, but it permits new/ > continued implementation in order to foster interoperability with > older/existing implementations. > > This does not state whether as an OSS I can assume the deprecated element is still part of the interface contract or not. > I think the RFC should declare whether a deprecated element MUST be or just MAY be there. > Since this language has been borrowed from the SMIv2 world, the semantics are a MAY if you interact with a revision of a YANG module where the definition is 'obsolete'. The OSS should not count on this being present. The text says "it permits new/continued implementation", it does not say it requires implementation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From B.Hedstrom@CableLabs.com Wed Feb 27 12:13:33 2013 Return-Path: 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 02BC721F88AC for ; Wed, 27 Feb 2013 12:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 kIA-9A515Tqd for ; Wed, 27 Feb 2013 12:13:32 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 25B8321F8887 for ; Wed, 27 Feb 2013 12:13:27 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r1RKDPYc028628; Wed, 27 Feb 2013 13:13:26 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 27 Feb 2013 13:13:25 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Wed, 27 Feb 2013 13:13:25 -0700 From: Brian Hedstrom To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] draft agenda for orlando Thread-Index: AQHOFQ3cD67XPpl4jEmmyOxT+cdxZJiOI7YA Date: Wed, 27 Feb 2013 20:13:24 +0000 Message-ID: <686B406F73B0F245AB30195F4E80E2D517F1AE86@EXCHANGE.cablelabs.com> In-Reply-To: <20130227171356.GC82136@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.4.10.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B35F9A11785C24C8F2D9B2D01588FD9@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [netmod] draft agenda for orlando X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:13:33 -0000 What if I would like to create a new Internet-Draft for a YANG Module to configure an IPDR Exporter ("YANG usage in the TMForum")? How would I proceed? I will be at the IETF. Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 Google+: brian.hedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com =20 On 2/27/13 10:13 AM, "Juergen Schoenwaelder" wrote: >Hi, > >I have posted a first draft of an agenda: > > http://tools.ietf.org/wg/netmod/agenda > >As you can see, we are likely not short of time since our chartered >documents have stabilized and quite a few of them are ready to be >delivered to Benoit. > >Since YANG is popping up in other contexts (i2rs WG, lmap BOF, >unfortunately both taking place later during the week), it might be >useful to see whether we already know any requirements coming from >those activities. Perhaps we need an agenda item "YANG usage in the >IETF" or something like that. (Thinking loud for the moment.) > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Wed Feb 27 12:50:29 2013 Return-Path: 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 5D5B521F8841 for ; Wed, 27 Feb 2013 12:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 0NTjhoXe121T for ; Wed, 27 Feb 2013 12:50:27 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 48BAC21F8802 for ; Wed, 27 Feb 2013 12:50:27 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CFA220BE6; Wed, 27 Feb 2013 21:50:26 +0100 (CET) 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 L73-29aePGRu; Wed, 27 Feb 2013 21:50:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0256E20BE3; Wed, 27 Feb 2013 21:50:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CA59524C37B6; Wed, 27 Feb 2013 21:50:35 +0100 (CET) Date: Wed, 27 Feb 2013 21:50:35 +0100 From: Juergen Schoenwaelder To: Brian Hedstrom Message-ID: <20130227205035.GD82746@elstar.local> Mail-Followup-To: Brian Hedstrom , "netmod@ietf.org" References: <20130227171356.GC82136@elstar.local> <686B406F73B0F245AB30195F4E80E2D517F1AE86@EXCHANGE.cablelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <686B406F73B0F245AB30195F4E80E2D517F1AE86@EXCHANGE.cablelabs.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] draft agenda for orlando X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:50:29 -0000 On Wed, Feb 27, 2013 at 08:13:24PM +0000, Brian Hedstrom wrote: > What if I would like to create a new Internet-Draft for a YANG Module to > configure an IPDR Exporter ("YANG usage in the TMForum")? > How would I proceed? I will be at the IETF. The short answer is: You simply write one. The longer answer depends on how familiar you are with the process of writing an Internet-Draft (there are various ways to do this, the most popular likely is xml2rfc at this point in time). Check out the IETF tutorials for newcomers and in particular: http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF83/83-ToolsForCreatingIDs-Hagens.pdf?format=raw Once you have settled on the tool, you start writing and you finally post an individual I-D. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Feb 28 12:03:09 2013 Return-Path: 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 5E06121F8996 for ; Thu, 28 Feb 2013 12:03:09 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8zbAW2qtMvv for ; Thu, 28 Feb 2013 12:03:08 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1221F8991 for ; Thu, 28 Feb 2013 12:03:08 -0800 (PST) Received: from localhost (h-105-26.a226.priv.bahnhof.se [79.136.105.26]) by mail.tail-f.com (Postfix) with ESMTPSA id D29C81200D7C; Thu, 28 Feb 2013 21:03:06 +0100 (CET) Date: Thu, 28 Feb 2013 21:03:06 +0100 (CET) Message-Id: <20130228.210306.149858406.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20130225093326.102C772E114@rfc-editor.org> References: <20130225093326.102C772E114@rfc-editor.org> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, rbonica@juniper.net, jernej.tuljak@mg-soft.com Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3495) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 20:03:09 -0000 Hi, This is a proper correction. /martin RFC Errata System wrote: > > 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=3495 > > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak > > Section: 12 > > Original Text > ------------- > revision-stmt = revision-keyword sep revision-date optsep > (";" / > "{" stmtsep > [description-stmt stmtsep] > [reference-stmt stmtsep] > "}") > > Corrected Text > -------------- > revision-stmt = revision-keyword sep revision-date optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [description-stmt stmtsep] > [reference-stmt stmtsep] > "}") > > Notes > ----- > The comment "these stmts can appear in any order" is missing from this > statement. > > 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 >