From nobody Tue Jan 5 12:05:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483971B2D76 for ; Tue, 5 Jan 2016 12:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2KyKL023Ib2 for ; Tue, 5 Jan 2016 12:05:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323A41B2D65 for ; Tue, 5 Jan 2016 12:05:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE44E12E0 for ; Tue, 5 Jan 2016 21:05:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id B2JcJwkml6GQ for ; Tue, 5 Jan 2016 21:05:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 5 Jan 2016 21:05:27 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 830C820056 for ; Tue, 5 Jan 2016 21:05:27 +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 jqdCuuKaTCVH; Tue, 5 Jan 2016 21:05: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 D3A4A20055; Tue, 5 Jan 2016 21:05:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B3E73397C675; Tue, 5 Jan 2016 21:05:24 +0100 (CET) Date: Tue, 5 Jan 2016 21:05:23 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20160105200521.GA24317@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:05:33 -0000 Hi, here is my review of draft-ietf-netconf-yang-library-03. a) p2: What are "YANG-based data abstractions"? Do we need this new term? Why not simply say "a server that implements YANG data models"? b) p3: I think it follows from the first bullet that it is illegal or impossible to implement two different revisions of a certain module within a single server. c) p3: I suggest to delete sections titles 1.1.1 and 1.1.2 and 1.1.3 - I do not think they actually add value - its all about Terminology, so fits nicely into section 1.1. d) p4: With c), I would turn 1.1.4 into 1.2 (since tree diagrams are not really terminology). e) Should the YANG protocol identities be managed by IANA? We likely do not want to touch the YANG library for the next protocol to come and it might be confusing to have some identities registered in the YANG library model itself but others in different places. I know, technically this is all fine if we manage to properly keep track of things. An IANA managed module with these identity registrations might make that keeping track part a bit easier since there is a single place for all the IETF protocols transporting YANG data and using the YANG library. The obvious alternative is to allocate the identities in the protocol definitions but then we should do this for restconf already now. (The downside with this approach is that this identity registration in protocol documents likely causes a normative dependency on YANG library, which is not nice; the IANA option works around that.) f) Should there be RFC editor instructions to replace the reference to draft-ietf-netconf-restconf in the restconf1.0 identity definition with the RESTCONF RFC number? (BTW, I personally prefer to have a hyphen between the protocol name and the version number, i.e., restconf-1.0 instead of restconf1.0.) g) I prefer 'zero-length string' over 'empty string'. h) Turn the leaf-list feature into a list feature { key name; leaf name } so that the feature list can be augmented in the future if ever needed? i) Features can be defined in submodules, yet they are exposed in the YANG library as features of the enclosing module. Is this by intention? This should be technically OK but it is not a simple 1:1 mapping of the definitions and hence my question whether this is by intention. And if it is by intention, perhaps clarify that this list includes all module features independently from where they are defined. j) There are MUST statements concerning YANG 1.1 modules but there is not even a reference to YANG 1.1. I think a reference needs to be added to YANG 1.1 and it is likely a normative reference (which means YANG 1.1 and YANG Library have a circular dependency). k) I am not sure I understand For YANG 1.0 modules, there SHOULD NOT be more than one module entry for a particular module name."; in the description of the 'implement' enum for the conformance leaf. l) Is 'restricted-protocol' a good name for the leaf? It actually means 'not-supported-by-protocol' - is 'excluded-protocol' a better name? So essentially we have a set of modules and exceptions - if I have to add a protocol specific module, I need to add it to the global set and then setup proper exceptions. I assume the assumption here is that these are rare corner cases. Or should there also be the other alternative, an 'included-protocol' for adding things to the common set so both operations are available when needed? m) Does it make sense to discuss somewhere a bit what a server is? There will be servers that support multiple protocols but use a common backend server. There will also be deployments where different protocols do not use a common backend; in this case the protocol servers would report rather different instantiations of the YANG library. Should there be text discussing this? Should there be advice that a YANG library retrieved via protocol X should not be assumed to work with protocol Y unless the module-set-id has been verified via protocol Y? n) Should yang-protocol be turned into a list instead of a leaf-list to allow future augmentations? o) Should we keep in mind that eventually modules are also configured into servers? That is, we are really defining the 'modules-state' tree and not the 'modules' tree (if we follow the foo and foo-state convention). [I expect to get grilled on this one.] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 5 19:44:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F40D1A8F40 for ; Tue, 5 Jan 2016 19:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTA9ySEJUJA7 for ; Tue, 5 Jan 2016 19:44:42 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5B31A8F3F for ; Tue, 5 Jan 2016 19:44:42 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id pv2so200357484lbb.1 for ; Tue, 05 Jan 2016 19:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TfcjZKMJGwyb6kEu0/YeR/q6aLw/syA3NBwNlMrQgr8=; b=ManFDqbnpa21dD9/2YhNQy4UHBYi8V/rEEXEptW2S8Gcjmj3vdwjo7aJ73Y/5QqubO kDTErbLQ7RJSMGmPWxSvv2Oz26AYhgfC41D+BkNJUzTTogPuVo4HAfRu9A9cwwzKYa+D EmvS8jGjlwSWJhQSOitOYSfExStQbvmzKDX10ZgRlaB8Md2IeHKDXxGyTlcIfKtMIbGj 2K7RShYq/Gcx33ODC6wVs6nCWYWUShZ7NSiifH6+CotkG/Ku0wuOa2DCWQn523MDYDvx i2+Cf0q2izmMfrkT99kq8udq+ISfavCz0P39Zjn79BKLsr8RHCZxQFGHgjETOFpVwbDr /26A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TfcjZKMJGwyb6kEu0/YeR/q6aLw/syA3NBwNlMrQgr8=; b=FB0H98cbT9dNT4ryfieSqIgDS0PWMOaCjzkz9CYbXKnsg3INtmcTjcQgAg2OnKz5eK DwChsWLaKOnRMYnI+HuGDZRbAOTZDzKdSiL2uylgQQ2ef8WrppRjCwN1KB8A8CrOpoDu cg+yXbWNtWhc7Vd9mO0cEBJkpi9JuAeFv/GCr8GwBQWfosYs810VaM9zMkovOyqu66By QFsxG/zbsbrm6NfjexkCi81xOWZ0pidOnB+/rOiu7fy7O6550VtudmPhOlKwUJvVzYnE WTYMkv0kiIV/IufGdcgyesTVdIyDAzIbfvyYL0R253tHxI8ixiwRlHtdsCvRUXUmqrRP x7ig== X-Gm-Message-State: ALoCoQnILwohfaF7hYnNztnFZZmjCw3ItZnU138Id04qZd+ruDuytg6Kah7NUNvwMJ+E8WgTrprVa1NjJ3hnl7TlLFvNss//dQ== MIME-Version: 1.0 X-Received: by 10.112.199.41 with SMTP id jh9mr27462707lbc.119.1452051880257; Tue, 05 Jan 2016 19:44:40 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 5 Jan 2016 19:44:40 -0800 (PST) In-Reply-To: <20160105200521.GA24317@elstar.local> References: <20160105200521.GA24317@elstar.local> Date: Tue, 5 Jan 2016 19:44:40 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Netconf Content-Type: multipart/alternative; boundary=001a11c2368284c4c90528a22cbb Archived-At: Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 03:44:45 -0000 --001a11c2368284c4c90528a22cbb Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > here is my review of draft-ietf-netconf-yang-library-03. > > a) p2: What are "YANG-based data abstractions"? Do we need this new > term? Why not simply say "a server that implements YANG data > models"? > OK > > b) p3: I think it follows from the first bullet that it is illegal or > impossible to implement two different revisions of a certain module > within a single server. > No -- this text should be clarified. It is meant to convey that the name "foo" cannot represent 2 different module names. It does not mean there can only be 1 entry in the module list for each module name. > > c) p3: I suggest to delete sections titles 1.1.1 and 1.1.2 and 1.1.3 - > I do not think they actually add value - its all about Terminology, > so fits nicely into section 1.1. > OK > > d) p4: With c), I would turn 1.1.4 into 1.2 (since tree diagrams are > not really terminology). > > OK e) Should the YANG protocol identities be managed by IANA? We likely > do not want to touch the YANG library for the next protocol to come > and it might be confusing to have some identities registered in the > YANG library model itself but others in different places. I know, > technically this is all fine if we manage to properly keep track of > things. An IANA managed module with these identity registrations > might make that keeping track part a bit easier since there is a > single place for all the IETF protocols transporting YANG data and > using the YANG library. The obvious alternative is to allocate the > identities in the protocol definitions but then we should do this > for restconf already now. (The downside with this approach is that > this identity registration in protocol documents likely causes a > normative dependency on YANG library, which is not nice; the IANA > option works around that.) > IMO, IANA has enough to do. This is just another YANG identity. Vendors and other SDOs should not need to register identityrefs with IANA to use their protocol with the YANG library. > f) Should there be RFC editor instructions to replace the reference to > draft-ietf-netconf-restconf in the restconf1.0 identity definition > with the RESTCONF RFC number? (BTW, I personally prefer to have a > hyphen between the protocol name and the version number, i.e., > restconf-1.0 instead of restconf1.0.) > IMO the current strings are OK, but I don't care if the WG wants to change them > > g) I prefer 'zero-length string' over 'empty string'. > > OK > h) Turn the leaf-list feature into a list feature { key name; leaf > name } so that the feature list can be augmented in the future if > ever needed? > > IMO this is overkill. Other tables can use a leafref to this leaf-list instead > i) Features can be defined in submodules, yet they are exposed in the > YANG library as features of the enclosing module. Is this by > intention? This should be technically OK but it is not a simple 1:1 > mapping of the definitions and hence my question whether this is by > intention. And if it is by intention, perhaps clarify that this > list includes all module features independently from where they are > defined. > YANG features apply to the module. Submodules do not partition the module namespace. There can only be 1 "foo" feature in a the module and it doesn't matter what submodule contains it. All submodules must be included into the main module in YANG 1.1 Any include statements in a submodule get ignored in YANG 1.1. The confusion remains in the YANG statements, but it is clarified in the draft. > j) There are MUST statements concerning YANG 1.1 modules but there is > not even a reference to YANG 1.1. I think a reference needs to be > added to YANG 1.1 and it is likely a normative reference (which > means YANG 1.1 and YANG Library have a circular dependency). > > maybe these MUST statements should be moved to YANG 1.1 > k) I am not sure I understand > > For YANG 1.0 modules, there SHOULD NOT be more than > one module entry for a particular module name."; > > in the description of the 'implement' enum for the conformance > leaf. > This rule of "implement 1 revision" did not apply to YANG 1.0 so it is just a SHOULD NOT. IMO it would be OK to move YANG conformance text to YANG 1.1 > > l) Is 'restricted-protocol' a good name for the leaf? It actually > means 'not-supported-by-protocol' - is 'excluded-protocol' a better > name? So essentially we have a set of modules and exceptions - if I > have to add a protocol specific module, I need to add it to the > global set and then setup proper exceptions. I assume the > assumption here is that these are rare corner cases. Or should > there also be the other alternative, an 'included-protocol' for > adding things to the common set so both operations are available > when needed? > > If a YANG protocol uses the library at all, it is listed in yang-protocol. If any module entry in the library does not apply to this protocol, then the exception entry is needed in each unsupported module. > m) Does it make sense to discuss somewhere a bit what a server is? > There will be servers that support multiple protocols but use a > common backend server. There will also be deployments where > different protocols do not use a common backend; in this case the > protocol servers would report rather different instantiations of > the YANG library. Should there be text discussing this? Should > there be advice that a YANG library retrieved via protocol X should > not be assumed to work with protocol Y unless the module-set-id has > been verified via protocol Y? > IMO so -- this draft defines a library, not a server. The module-set-id is an opaque string with no semantics at all. IMO there is no reason to discuss implementation details. > > n) Should yang-protocol be turned into a list instead of a leaf-list > to allow future augmentations? > no -- use a leafref to point to the leaf-list > > o) Should we keep in mind that eventually modules are also configured > into servers? That is, we are really defining the 'modules-state' > tree and not the 'modules' tree (if we follow the foo and foo-state > convention). [I expect to get grilled on this one.] > > that is why module is defined in a grouping that can be used in a config=true container > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c2368284c4c90528a22cbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

here is my review of draft-ietf-netconf-yang-library-03.

a) p2: What are "YANG-based data abstractions"? Do we need this n= ew
=C2=A0 =C2=A0term?=C2=A0 Why not simply say "a server that implements = YANG data
=C2=A0 =C2=A0models"?


OK

=C2=A0

b) p3: I think it follows from the first bullet that it is illegal or
=C2=A0 =C2=A0impossible to implement two different revisions of a certain m= odule
=C2=A0 =C2=A0within a single server.

No -- this text should be clarified.
It is meant to = convey that the name "foo" cannot represent
2 different= module names.=C2=A0 It does not mean there can
only be 1 entry i= n the module list for each module name.

=C2=A0

c) p3: I suggest to delete sections titles 1.1.1 and 1.1.2 and 1.1.3 -
=C2=A0 =C2=A0I do not think they actually add value - its all about Termino= logy,
=C2=A0 =C2=A0so fits nicely into section 1.1.

OK

=C2=A0

d) p4: With c), I would turn 1.1.4 into 1.2 (since tree diagrams are
=C2=A0 =C2=A0not really terminology).

OK


e) Should the YANG protocol identities be managed by IANA? We likely
=C2=A0 =C2=A0do not want to touch the YANG library for the next protocol to= come
=C2=A0 =C2=A0and it might be confusing to have some identities registered i= n the
=C2=A0 =C2=A0YANG library model itself but others in different places. I kn= ow,
=C2=A0 =C2=A0technically this is all fine if we manage to properly keep tra= ck of
=C2=A0 =C2=A0things. An IANA managed module with these identity registratio= ns
=C2=A0 =C2=A0might make that keeping track part a bit easier since there is= a
=C2=A0 =C2=A0single place for all the IETF protocols transporting YANG data= and
=C2=A0 =C2=A0using the YANG library. The obvious alternative is to allocate= the
=C2=A0 =C2=A0identities in the protocol definitions but then we should do t= his
=C2=A0 =C2=A0for restconf already now. (The downside with this approach is = that
=C2=A0 =C2=A0this identity registration in protocol documents likely causes= a
=C2=A0 =C2=A0normative dependency on YANG library, which is not nice; the I= ANA
=C2=A0 =C2=A0option works around that.)

IMO, IANA has enough to do. This is just another YANG identity.
= Vendors and other SDOs should not need to register identityrefs with IANA
to use their protocol with the YANG library.=C2=A0

<= /div>

f) Should there be RFC editor instructions to replace the reference to
=C2=A0 =C2=A0draft-ietf-netconf-restconf in the restconf1.0 identity defini= tion
=C2=A0 =C2=A0with the RESTCONF RFC number?=C2=A0 (BTW, I personally prefer = to have a
=C2=A0 =C2=A0hyphen between the protocol name and the version number, i.e.,=
=C2=A0 =C2=A0restconf-1.0 instead of restconf1.0.)
=C2= =A0

IMO the current strings are OK, but I don'= t care if the WG wants to change them

=C2=A0
=

g) I prefer 'zero-length string' over 'empty string'.


OK
=C2=A0
h) Turn the leaf-list feature into a list feature { key name; leaf
=C2=A0 name } so that the feature list can be augmented in the future if =C2=A0 ever needed?


IMO this is overkill.=C2=A0 Other tabl= es can use a leafref to this leaf-list instead

=C2= =A0
i) Features can be defined in submodules, yet they are exposed in the
=C2=A0 =C2=A0YANG library as features of the enclosing module. Is this by =C2=A0 =C2=A0intention? This should be technically OK but it is not a simpl= e 1:1
=C2=A0 =C2=A0mapping of the definitions and hence my question whether this = is by
=C2=A0 =C2=A0intention. And if it is by intention, perhaps clarify that thi= s
=C2=A0 =C2=A0list includes all module features independently from where the= y are
=C2=A0 =C2=A0defined.

YANG features app= ly to the module.
Submodules do not partition the module namespac= e.
There can only be 1 "foo" feature in a the module an= d it doesn't matter what submodule
contains it.=C2=A0 All sub= modules must be included into the main module in YANG 1.1
Any inc= lude statements in a submodule get ignored in YANG 1.1. The confusion remai= ns
in the YANG statements, but it is clarified in the draft.


j) There are MUST statements concerning YANG 1.1 modules but there is
=C2=A0 =C2=A0not even a reference to YANG 1.1. I think a reference needs to= be
=C2=A0 =C2=A0added to YANG 1.1 and it is likely a normative reference (whic= h
=C2=A0 =C2=A0means YANG 1.1 and YANG Library have a circular dependency).

maybe these MUST statements should be = moved to YANG 1.1

=C2=A0
k) I am not sure I understand

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For YANG 1.0 modules, there= SHOULD NOT be more than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one module entry for a part= icular module name.";

=C2=A0 =C2=A0in the description of the 'implement' enum for the con= formance
=C2=A0 =C2=A0leaf.


This = rule of "implement 1 revision" did not apply to YANG 1.0
so it is just a SHOULD NOT.=C2=A0 IMO it would be OK to move YANG
conformance text to YANG 1.1
=C2=A0

l) Is 'restricted-protocol' a good name for the leaf? It actually =C2=A0 =C2=A0means 'not-supported-by-protocol' - is 'excluded-p= rotocol' a better
=C2=A0 =C2=A0name? So essentially we have a set of modules and exceptions -= if I
=C2=A0 =C2=A0have to add a protocol specific module, I need to add it to th= e
=C2=A0 =C2=A0global set and then setup proper exceptions. I assume the
=C2=A0 =C2=A0assumption here is that these are rare corner cases. Or should=
=C2=A0 =C2=A0there also be the other alternative, an 'included-protocol= ' for
=C2=A0 =C2=A0adding things to the common set so both operations are availab= le
=C2=A0 =C2=A0when needed?



If a YANG protocol uses= the library at all, it is listed in yang-protocol.

If any module entry in the library does not apply to this protocol,
=
then the exception entry is needed in each unsupported module.


=C2=A0
m) Does it make sense to discuss somewhere a bit what a server is?
=C2=A0 =C2=A0There will be servers that support multiple protocols but use = a
=C2=A0 =C2=A0common backend server. There will also be deployments where =C2=A0 =C2=A0different protocols do not use a common backend; in this case = the
=C2=A0 =C2=A0protocol servers would report rather different instantiations = of
=C2=A0 =C2=A0the YANG library. Should there be text discussing this? Should=
=C2=A0 =C2=A0there be advice that a YANG library retrieved via protocol X s= hould
=C2=A0 =C2=A0not be assumed to work with protocol Y unless the module-set-i= d has
=C2=A0 =C2=A0been verified via protocol Y?

<= div>IMO so -- this draft defines a library, not a server.

The module-set-id is an opaque string with no semantics at all.

IMO there is no reason to discuss implementation deta= ils.


=C2=A0

n) Should yang-protocol be turned into a list instead of a leaf-list
=C2=A0 =C2=A0to allow future augmentations?

=

no -- use a leafref to point to the leaf-list

=C2=A0

o) Should we keep in mind that eventually modules are also configured
=C2=A0 =C2=A0into servers? That is, we are really defining the 'modules= -state'
=C2=A0 =C2=A0tree and not the 'modules' tree (if we follow the foo = and foo-state
=C2=A0 =C2=A0convention). [I expect to get grilled on this one.]


that is why module is defined in a grouping that can= be used in a config=3Dtrue container

=C2=A0
=
/js

Andy

=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a11c2368284c4c90528a22cbb-- From nobody Tue Jan 5 23:39:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E988D1AC3C1 for ; Tue, 5 Jan 2016 23:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNSUHzcvmrHN for ; Tue, 5 Jan 2016 23:39:07 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B24D71AC3BC for ; Tue, 5 Jan 2016 23:39:05 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id CBF6D1CC01AB; Wed, 6 Jan 2016 08:39:06 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Netconf In-Reply-To: References: <20160105200521.GA24317@elstar.local> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 06 Jan 2016 08:39:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 07:39:09 -0000 Andy Bierman writes: > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Hi, >> >> here is my review of draft-ietf-netconf-yang-library-03. >> >> a) p2: What are "YANG-based data abstractions"? Do we need this new >> term? Why not simply say "a server that implements YANG data >> models"? >> > > > OK > > > >> >> b) p3: I think it follows from the first bullet that it is illegal or >> impossible to implement two different revisions of a certain module >> within a single server. >> > > > No -- this text should be clarified. > It is meant to convey that the name "foo" cannot represent > 2 different module names. It does not mean there can > only be 1 entry in the module list for each module name. I don't understand: 1. Could there ever be two revisions of a module of the "implement" type? 2. If there are multiple revisions of a module of the "import" type, then I think it breaks the main purpose of having such modules in the list - if such a module is imported without revision, how can a client determine which revision the server actually uses? ... >> >> l) Is 'restricted-protocol' a good name for the leaf? It actually >> means 'not-supported-by-protocol' - is 'excluded-protocol' a better >> name? So essentially we have a set of modules and exceptions - if I >> have to add a protocol specific module, I need to add it to the >> global set and then setup proper exceptions. I assume the >> assumption here is that these are rare corner cases. Or should >> there also be the other alternative, an 'included-protocol' for >> adding things to the common set so both operations are available >> when needed? >> >> > > If a YANG protocol uses the library at all, it is listed in yang-protocol. > > If any module entry in the library does not apply to this protocol, > then the exception entry is needed in each unsupported module. > IMO yang-library shouldn't deal with this protocol stuff at all (and bother IANA with it or whatever). If a module is protocol-specific, then it shouldn't be included in yang-library information sent to other protocols. I believe it is also a security issue - why should clients of all protocols know modules that are used by other protocols? BTW, the term yang-library is perhaps somewhat unfortunate. Most people would think it is a software library, and there are already several YANG libraries being worked on. Lada > > > >> m) Does it make sense to discuss somewhere a bit what a server is? >> There will be servers that support multiple protocols but use a >> common backend server. There will also be deployments where >> different protocols do not use a common backend; in this case the >> protocol servers would report rather different instantiations of >> the YANG library. Should there be text discussing this? Should >> there be advice that a YANG library retrieved via protocol X should >> not be assumed to work with protocol Y unless the module-set-id has >> been verified via protocol Y? >> > > IMO so -- this draft defines a library, not a server. > > The module-set-id is an opaque string with no semantics at all. > > IMO there is no reason to discuss implementation details. > > > > >> >> n) Should yang-protocol be turned into a list instead of a leaf-list >> to allow future augmentations? >> > > > no -- use a leafref to point to the leaf-list > > > >> >> o) Should we keep in mind that eventually modules are also configured >> into servers? That is, we are really defining the 'modules-state' >> tree and not the 'modules' tree (if we follow the foo and foo-state >> convention). [I expect to get grilled on this one.] >> >> > that is why module is defined in a grouping that can be used in a > config=true container > > > >> /js >> > > Andy > > > >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 6 10:16:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C51A008E for ; Wed, 6 Jan 2016 10:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nia7-4iUdktp for ; Wed, 6 Jan 2016 10:16:14 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E6B1A008A for ; Wed, 6 Jan 2016 10:16:13 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id sv6so187882739lbb.0 for ; Wed, 06 Jan 2016 10:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LFbnx//R6FFhH2dOgDjYyCA5mmN3HvJo63QXZ14Zcqg=; b=ZHc9M6jvL25c8Nitc9gkes6b/isObi8EPlerqbAyrH80GibWyjqnTJtqHaWTSMy0zX gX2xlAFZxnSA2PQvw05fBdDcrybdWaw0VAYBXFzjgf3tZwhpft6YLCdb+SZSD0/VnkJ/ gPI2FK4bx05yq3n31bwHwZYnLaZdoxrGZx35g81VcqJKqMnBKjQSS2ot/nCCySymBCpI jPLURq6xYH9cWt/rY1YnjQdpLfS1XfyvRe8fm7Ms114b5aifkKf/o1J7z6c59GoK1WP5 +jV5vdb98ZmK3kvfLdYNfhDoAt+ebXXAUf2SV9rOaLx4Bfg2SiThvginE6hLV6kl/vgf SMtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LFbnx//R6FFhH2dOgDjYyCA5mmN3HvJo63QXZ14Zcqg=; b=DCj3z8IzM2DtgFKJvzDjisL5TubesLBxzG4a5F95zb5W2MFYemjxv44eXqPh27V9hU 6s1seRQdkXNEQPUDZw8M8G4EpnnAUChOaWxUP6y8GA0MyDYpxOq7p4PQRDNLPCzGsrZF qeOLbvFq0hTCEjREakeSIvbkaax4q+K1v86UZTroO9pFy6eg049nMPGm2P9TtXEAzD8w 0QoOGo5sdEvdBDRxA0rfHykZPoY+I+59NcUbjGVEd6bVziFnDAXpw0RSQOcRrW8+dqic P9bW2w8L/1MYUP76LaQ1SlO/X1GGK0XPtPyuBEoRiSxPvQWZhK4aFz1QvtdQKQ9q0lM0 VeIA== X-Gm-Message-State: ALoCoQmTCct1SESmYQrHlqvBFbY4EIQB4qLXoW0KNhaTlTc642YhLgFecvmbMNpopFJXQHqlfJfnC950ztFRbv74V0oSBaH6Xg== MIME-Version: 1.0 X-Received: by 10.112.141.70 with SMTP id rm6mr28944502lbb.94.1452104171970; Wed, 06 Jan 2016 10:16:11 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 6 Jan 2016 10:16:11 -0800 (PST) In-Reply-To: References: <20160105200521.GA24317@elstar.local> Date: Wed, 6 Jan 2016 10:16:11 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3819c58faee0528ae59dc Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:16:17 -0000 --001a11c3819c58faee0528ae59dc Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> Hi, > >> > >> here is my review of draft-ietf-netconf-yang-library-03. > >> > >> a) p2: What are "YANG-based data abstractions"? Do we need this new > >> term? Why not simply say "a server that implements YANG data > >> models"? > >> > > > > > > OK > > > > > > > >> > >> b) p3: I think it follows from the first bullet that it is illegal or > >> impossible to implement two different revisions of a certain module > >> within a single server. > >> > > > > > > No -- this text should be clarified. > > It is meant to convey that the name "foo" cannot represent > > 2 different module names. It does not mean there can > > only be 1 entry in the module list for each module name. > > I don't understand: > > 1. Could there ever be two revisions of a module of the "implement" > type? > > This is not explicitly prohibited in YANG 1.0 and we cannot make any rules now for YANG 1.0, just YANG 1.1. > 2. If there are multiple revisions of a module of the "import" type, > then I think it breaks the main purpose of having such modules in the > list - if such a module is imported without revision, how can a > client determine which revision the server actually uses? > > The most recent revision listed in the library is used for YANG 1.1. We cannot fix this issue for YANG 1.0, just YANG 1.1. > ... > > >> > >> l) Is 'restricted-protocol' a good name for the leaf? It actually > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a better > >> name? So essentially we have a set of modules and exceptions - if I > >> have to add a protocol specific module, I need to add it to the > >> global set and then setup proper exceptions. I assume the > >> assumption here is that these are rare corner cases. Or should > >> there also be the other alternative, an 'included-protocol' for > >> adding things to the common set so both operations are available > >> when needed? > >> > >> > > > > If a YANG protocol uses the library at all, it is listed in > yang-protocol. > > > > If any module entry in the library does not apply to this protocol, > > then the exception entry is needed in each unsupported module. > > > > IMO yang-library shouldn't deal with this protocol stuff at all (and > bother IANA with it or whatever). If a module is protocol-specific, then > it shouldn't be included in yang-library information sent to other > protocols. > > I believe it is also a security issue - why should clients of all > protocols know modules that are used by other protocols? > > BTW, the term yang-library is perhaps somewhat unfortunate. Most people > would think it is a software library, and there are already several YANG > libraries being worked on. > > I think people can read the description-stmts and know the difference between a YANG library and a software library. I don't agree it is a risk to list the protocols using YANG modules on the device. I don't mind removing all mention of protocols. If a client attempts to use a module that is not supported by a protocol, they will get an error back. This is not really important data. > Lada > > Andy > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server is? > >> There will be servers that support multiple protocols but use a > >> common backend server. There will also be deployments where > >> different protocols do not use a common backend; in this case the > >> protocol servers would report rather different instantiations of > >> the YANG library. Should there be text discussing this? Should > >> there be advice that a YANG library retrieved via protocol X should > >> not be assumed to work with protocol Y unless the module-set-id has > >> been verified via protocol Y? > >> > > > > IMO so -- this draft defines a library, not a server. > > > > The module-set-id is an opaque string with no semantics at all. > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > >> > >> n) Should yang-protocol be turned into a list instead of a leaf-list > >> to allow future augmentations? > >> > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > >> > >> o) Should we keep in mind that eventually modules are also configured > >> into servers? That is, we are really defining the 'modules-state' > >> tree and not the 'modules' tree (if we follow the foo and foo-state > >> convention). [I expect to get grilled on this one.] > >> > >> > > that is why module is defined in a grouping that can be used in a > > config=true container > > > > > > > >> /js > >> > > > > Andy > > > > > > > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c3819c58faee0528ae59dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
>> Hi,
>>
>> here is my review of draft-ietf-netconf-yang-library-03.
>>
>> a) p2: What are "YANG-based data abstractions"? Do we ne= ed this new
>>=C2=A0 =C2=A0 term?=C2=A0 Why not simply say "a server that im= plements YANG data
>>=C2=A0 =C2=A0 models"?
>>
>
>
> OK
>
>
>
>>
>> b) p3: I think it follows from the first bullet that it is illegal= or
>>=C2=A0 =C2=A0 impossible to implement two different revisions of a = certain module
>>=C2=A0 =C2=A0 within a single server.
>>
>
>
> No -- this text should be clarified.
> It is meant to convey that the name "foo" cannot represent > 2 different module names.=C2=A0 It does not mean there can
> only be 1 entry in the module list for each module name.

I don't understand:

1. Could there ever be two revisions of a module of the "implement&quo= t;
=C2=A0 =C2=A0type?


This is not explicitly prohibited in Y= ANG 1.0 and we cannot
make any rules now for YANG 1.0, just YANG = 1.1.


=C2=A0
2. If there are multiple revisions of a module of the "import" ty= pe,
=C2=A0 =C2=A0then I think it breaks the main purpose of having such modules= in the
=C2=A0 =C2=A0list - if such a module is imported without revision, how can = a
=C2=A0 =C2=A0client determine which revision the server actually uses?



The most recent revisio= n listed in the library is used for YANG 1.1.

We c= annot fix this issue for YANG 1.0, just YANG 1.1.

=

=C2=A0
...

>>
>> l) Is 'restricted-protocol' a good name for the leaf? It a= ctually
>>=C2=A0 =C2=A0 means 'not-supported-by-protocol' - is 'e= xcluded-protocol' a better
>>=C2=A0 =C2=A0 name? So essentially we have a set of modules and exc= eptions - if I
>>=C2=A0 =C2=A0 have to add a protocol specific module, I need to add= it to the
>>=C2=A0 =C2=A0 global set and then setup proper exceptions. I assume= the
>>=C2=A0 =C2=A0 assumption here is that these are rare corner cases. = Or should
>>=C2=A0 =C2=A0 there also be the other alternative, an 'included= -protocol' for
>>=C2=A0 =C2=A0 adding things to the common set so both operations ar= e available
>>=C2=A0 =C2=A0 when needed?
>>
>>
>
> If a YANG protocol uses the library at all, it is listed in yang-proto= col.
>
> If any module entry in the library does not apply to this protocol, > then the exception entry is needed in each unsupported module.
>

IMO yang-library shouldn't deal with this protocol stuff at all (and bother IANA with it or whatever). If a module is protocol-specific, then it shouldn't be included in yang-library information sent to other
protocols.

I believe it is also a security issue - why should clients of all
protocols know modules that are used by other protocols?

BTW, the term yang-library is perhaps somewhat unfortunate. Most people
would think it is a software library, and there are already several YANG libraries being worked on.

I think people can read the description-stmts and kno= w the difference
between a YANG library and a software library.

I don't agree it is a risk to list the protocol= s using YANG modules on the device.

I don't mi= nd removing all mention of protocols.
If a client attempts to use= a module that is not supported
by a protocol, they will get an e= rror back.
This is not really important data.




=C2=A0
Lada


Andy
=C2=A0
>
>
>
>> m) Does it make sense to discuss somewhere a bit what a server is?=
>>=C2=A0 =C2=A0 There will be servers that support multiple protocols= but use a
>>=C2=A0 =C2=A0 common backend server. There will also be deployments= where
>>=C2=A0 =C2=A0 different protocols do not use a common backend; in t= his case the
>>=C2=A0 =C2=A0 protocol servers would report rather different instan= tiations of
>>=C2=A0 =C2=A0 the YANG library. Should there be text discussing thi= s? Should
>>=C2=A0 =C2=A0 there be advice that a YANG library retrieved via pro= tocol X should
>>=C2=A0 =C2=A0 not be assumed to work with protocol Y unless the mod= ule-set-id has
>>=C2=A0 =C2=A0 been verified via protocol Y?
>>
>
> IMO so -- this draft defines a library, not a server.
>
> The module-set-id is an opaque string with no semantics at all.
>
> IMO there is no reason to discuss implementation details.
>
>
>
>
>>
>> n) Should yang-protocol be turned into a list instead of a leaf-li= st
>>=C2=A0 =C2=A0 to allow future augmentations?
>>
>
>
> no -- use a leafref to point to the leaf-list
>
>
>
>>
>> o) Should we keep in mind that eventually modules are also configu= red
>>=C2=A0 =C2=A0 into servers? That is, we are really defining the = 9;modules-state'
>>=C2=A0 =C2=A0 tree and not the 'modules' tree (if we follow= the foo and foo-state
>>=C2=A0 =C2=A0 convention). [I expect to get grilled on this one.] >>
>>
> that is why module is defined in a grouping that can be used in a
> config=3Dtrue container
>
>
>
>> /js
>>
>
> Andy
>
>
>
>>
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf<= /a>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a11c3819c58faee0528ae59dc-- From nobody Wed Jan 6 10:45:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3193F1A00DA for ; Wed, 6 Jan 2016 10:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-x87KdBckzM for ; Wed, 6 Jan 2016 10:45:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6BB1A00DC for ; Wed, 6 Jan 2016 10:45:16 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 5D054180BD8; Wed, 6 Jan 2016 19:45:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452105915; bh=i5l5nlxoxwB8pjqlGV3/ATBm+de/r2ubtjuUPhIbfaY=; h=From:Date:To; b=sFz1Ru8cuNuAInwGXR4hVxX8xvSR+/ucRfg/mBo+Tw6HNQ/rO0KHup6gJ4MCeJboS QWR5TB3AOOgsSC5f5O/oENOAeruHp8zPjW2JF6x98TwnQ5Cy/QpfbOVVGRLtmxqh0J TYDoZCVwPzncLbnDSDuxVKWbCWiQWkDRXltTT+eI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 6 Jan 2016 19:45:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160105200521.GA24317@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:45:19 -0000 > On 06 Jan 2016, at 19:16, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > >> Hi, > >> > >> here is my review of draft-ietf-netconf-yang-library-03. > >> > >> a) p2: What are "YANG-based data abstractions"? Do we need this new > >> term? Why not simply say "a server that implements YANG data > >> models"? > >> > > > > > > OK > > > > > > > >> > >> b) p3: I think it follows from the first bullet that it is illegal = or > >> impossible to implement two different revisions of a certain = module > >> within a single server. > >> > > > > > > No -- this text should be clarified. > > It is meant to convey that the name "foo" cannot represent > > 2 different module names. It does not mean there can > > only be 1 entry in the module list for each module name. >=20 > I don't understand: >=20 > 1. Could there ever be two revisions of a module of the "implement" > type? >=20 >=20 > This is not explicitly prohibited in YANG 1.0 and we cannot > make any rules now for YANG 1.0, just YANG 1.1. YANG 1.0 has had no yang-libary so there are no backward compatibility = concerns affecting this document. >=20 >=20 > =20 > 2. If there are multiple revisions of a module of the "import" type, > then I think it breaks the main purpose of having such modules in = the > list - if such a module is imported without revision, how can a > client determine which revision the server actually uses? >=20 >=20 >=20 > The most recent revision listed in the library is used for YANG 1.1. If module A imports C with revision YYYY-MM-DD, and B imports C without = revision, then with this rule it wouldn't be possible for a server = implementor to choose any revision less than YYYY-MM-DD to be used with = B. I think this restriction isn't necessary. Listing module revisions = that are imported always with revision is redundant. I would propose that no more that one revision of each module be listed = in yang-library, and those of "import" type will be used exclusively for = resolving imports without revision.=20 >=20 > We cannot fix this issue for YANG 1.0, just YANG 1.1. >=20 >=20 >=20 > =20 > ... >=20 > >> > >> l) Is 'restricted-protocol' a good name for the leaf? It actually > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a = better > >> name? So essentially we have a set of modules and exceptions - = if I > >> have to add a protocol specific module, I need to add it to the > >> global set and then setup proper exceptions. I assume the > >> assumption here is that these are rare corner cases. Or should > >> there also be the other alternative, an 'included-protocol' for > >> adding things to the common set so both operations are available > >> when needed? > >> > >> > > > > If a YANG protocol uses the library at all, it is listed in = yang-protocol. > > > > If any module entry in the library does not apply to this protocol, > > then the exception entry is needed in each unsupported module. > > >=20 > IMO yang-library shouldn't deal with this protocol stuff at all (and > bother IANA with it or whatever). If a module is protocol-specific, = then > it shouldn't be included in yang-library information sent to other > protocols. >=20 > I believe it is also a security issue - why should clients of all > protocols know modules that are used by other protocols? >=20 > BTW, the term yang-library is perhaps somewhat unfortunate. Most = people > would think it is a software library, and there are already several = YANG > libraries being worked on. >=20 > I think people can read the description-stmts and know the difference > between a YANG library and a software library. >=20 > I don't agree it is a risk to list the protocols using YANG modules on = the device. >=20 > I don't mind removing all mention of protocols. > If a client attempts to use a module that is not supported > by a protocol, they will get an error back. > This is not really important data. I think this would be better. A similar error could be a consequence of = NACM rules. In any case, returning protocol-specific (and also user-specific) = yang-library contents should IMO be possible. Lada=20 >=20 >=20 >=20 >=20 > =20 > Lada >=20 >=20 > Andy > =20 > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server is? > >> There will be servers that support multiple protocols but use a > >> common backend server. There will also be deployments where > >> different protocols do not use a common backend; in this case = the > >> protocol servers would report rather different instantiations of > >> the YANG library. Should there be text discussing this? Should > >> there be advice that a YANG library retrieved via protocol X = should > >> not be assumed to work with protocol Y unless the module-set-id = has > >> been verified via protocol Y? > >> > > > > IMO so -- this draft defines a library, not a server. > > > > The module-set-id is an opaque string with no semantics at all. > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > >> > >> n) Should yang-protocol be turned into a list instead of a = leaf-list > >> to allow future augmentations? > >> > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > >> > >> o) Should we keep in mind that eventually modules are also = configured > >> into servers? That is, we are really defining the = 'modules-state' > >> tree and not the 'modules' tree (if we follow the foo and = foo-state > >> convention). [I expect to get grilled on this one.] > >> > >> > > that is why module is defined in a grouping that can be used in a > > config=3Dtrue container > > > > > > > >> /js > >> > > > > Andy > > > > > > > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 6 10:52:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BACC1A00E1 for ; Wed, 6 Jan 2016 10:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8uaoEfx6GJs for ; Wed, 6 Jan 2016 10:52:14 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CD31A00DC for ; Wed, 6 Jan 2016 10:52:13 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id sv6so188368991lbb.0 for ; Wed, 06 Jan 2016 10:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2kg8gZ4l3IfbNjnD20DhkKd5PbxoOhTPX/0pElFUgdk=; b=ORasZdJVAvXIvPIZIfGAf9yRvHz+/6iJEK1DFwLLkNybG3V1D87R4eGR7j7DFxDUmx nIaHTUii4uqt8ht2m/vZw5YnfeDE+hlcZTJKGvHQr00B+9V/ldI1khASr8UzqsinHaK6 4g/DAIvGlJenzTy435ffQ5yl4+L53TGh2hYp8jvEEq8tNMVWr7EIAW7+xdohf6XSAFq1 0Pd8jkaCf3h+2JRmxhCsBRd8Akh2Tl035huFF30Q3JmS5xIMEIj3WXJREOJuWhDlaWK1 W6VCWQk5m4pRpt2Ciu/O3smi0MTPNCirOgGAUx7Q3p0yej0mCowBoIZqu4s+av79ewHx BcAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2kg8gZ4l3IfbNjnD20DhkKd5PbxoOhTPX/0pElFUgdk=; b=anx/Mm4O5QfDWE9fPGFhW+lPpUOV5n+PhTek+DW0AGXdvcuE0JjCoqcT7tULaVwWQI flQ6P/P6Ks2Su7k6BcNAZq5anIq0hgL2506z01D0+ckGuiATX5TrxnY5E9dF3+50rRAs s32qc+5rE+hdGjO/xDzDuldZALJL+YWFLQfG0cbCr3FcOmXpf2Bigxz50dAhvJUhNJT+ A+cWNZMjn/VAmbFfIkxHfed4fRfcpVBInirWWggZi3IhODTlu+lwYt55GB9RshtjAETa ZB6elgeIrIk1aDre09yNMvUaZwy3ukxiYB29/GRvvMo5eMdyej98xgjFnXCaoo5LTnq5 CFhg== X-Gm-Message-State: ALoCoQmM0lBsUS9gs+Ag0J0xGCyI9wL3ghp7XXfl9EfxtEL9+8v7FRCTScdoOfVJe4RxzN826K1ukxfmlsPfNQWIGTW/bPl/kA== MIME-Version: 1.0 X-Received: by 10.112.202.101 with SMTP id kh5mr35879756lbc.66.1452106331887; Wed, 06 Jan 2016 10:52:11 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 6 Jan 2016 10:52:11 -0800 (PST) In-Reply-To: References: <20160105200521.GA24317@elstar.local> Date: Wed, 6 Jan 2016 10:52:11 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3724c16b8c90528aeda19 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:52:17 -0000 --001a11c3724c16b8c90528aeda19 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka wrote: > > > On 06 Jan 2016, at 19:16, Andy Bierman wrote: > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> Hi, > > >> > > >> here is my review of draft-ietf-netconf-yang-library-03. > > >> > > >> a) p2: What are "YANG-based data abstractions"? Do we need this new > > >> term? Why not simply say "a server that implements YANG data > > >> models"? > > >> > > > > > > > > > OK > > > > > > > > > > > >> > > >> b) p3: I think it follows from the first bullet that it is illegal or > > >> impossible to implement two different revisions of a certain module > > >> within a single server. > > >> > > > > > > > > > No -- this text should be clarified. > > > It is meant to convey that the name "foo" cannot represent > > > 2 different module names. It does not mean there can > > > only be 1 entry in the module list for each module name. > > > > I don't understand: > > > > 1. Could there ever be two revisions of a module of the "implement" > > type? > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > make any rules now for YANG 1.0, just YANG 1.1. > > YANG 1.0 has had no yang-libary so there are no backward compatibility > concerns affecting this document. > > > > > > > > 2. If there are multiple revisions of a module of the "import" type, > > then I think it breaks the main purpose of having such modules in the > > list - if such a module is imported without revision, how can a > > client determine which revision the server actually uses? > > > > > > > > The most recent revision listed in the library is used for YANG 1.1. > > If module A imports C with revision YYYY-MM-DD, and B imports C without > revision, then with this rule it wouldn't be possible for a server > implementor to choose any revision less than YYYY-MM-DD to be used with B. > I think this restriction isn't necessary. Listing module revisions that are > imported always with revision is redundant. > > I would propose that no more that one revision of each module be listed in > yang-library, and those of "import" type will be used exclusively for > resolving imports without revision. > > The WG has already discussed this issue several times. The YANG library lists all the YANG modules being used. The client needs to be able to retrieve this list without needing to parse the modules to find this information. For YANG 1.1 the rules are clearly specified. Andy > > > > We cannot fix this issue for YANG 1.0, just YANG 1.1. > > > > > > > > > > ... > > > > >> > > >> l) Is 'restricted-protocol' a good name for the leaf? It actually > > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a better > > >> name? So essentially we have a set of modules and exceptions - if I > > >> have to add a protocol specific module, I need to add it to the > > >> global set and then setup proper exceptions. I assume the > > >> assumption here is that these are rare corner cases. Or should > > >> there also be the other alternative, an 'included-protocol' for > > >> adding things to the common set so both operations are available > > >> when needed? > > >> > > >> > > > > > > If a YANG protocol uses the library at all, it is listed in > yang-protocol. > > > > > > If any module entry in the library does not apply to this protocol, > > > then the exception entry is needed in each unsupported module. > > > > > > > IMO yang-library shouldn't deal with this protocol stuff at all (and > > bother IANA with it or whatever). If a module is protocol-specific, then > > it shouldn't be included in yang-library information sent to other > > protocols. > > > > I believe it is also a security issue - why should clients of all > > protocols know modules that are used by other protocols? > > > > BTW, the term yang-library is perhaps somewhat unfortunate. Most people > > would think it is a software library, and there are already several YANG > > libraries being worked on. > > > > I think people can read the description-stmts and know the difference > > between a YANG library and a software library. > > > > I don't agree it is a risk to list the protocols using YANG modules on > the device. > > > > I don't mind removing all mention of protocols. > > If a client attempts to use a module that is not supported > > by a protocol, they will get an error back. > > This is not really important data. > > I think this would be better. A similar error could be a consequence of > NACM rules. > > In any case, returning protocol-specific (and also user-specific) > yang-library contents should IMO be possible. > > Lada > > > > > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server is? > > >> There will be servers that support multiple protocols but use a > > >> common backend server. There will also be deployments where > > >> different protocols do not use a common backend; in this case the > > >> protocol servers would report rather different instantiations of > > >> the YANG library. Should there be text discussing this? Should > > >> there be advice that a YANG library retrieved via protocol X should > > >> not be assumed to work with protocol Y unless the module-set-id has > > >> been verified via protocol Y? > > >> > > > > > > IMO so -- this draft defines a library, not a server. > > > > > > The module-set-id is an opaque string with no semantics at all. > > > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > > > > > > >> > > >> n) Should yang-protocol be turned into a list instead of a leaf-list > > >> to allow future augmentations? > > >> > > > > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > > > > > >> > > >> o) Should we keep in mind that eventually modules are also configured > > >> into servers? That is, we are really defining the 'modules-state' > > >> tree and not the 'modules' tree (if we follow the foo and foo-state > > >> convention). [I expect to get grilled on this one.] > > >> > > >> > > > that is why module is defined in a grouping that can be used in a > > > config=true container > > > > > > > > > > > >> /js > > >> > > > > > > Andy > > > > > > > > > > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > >> Fax: +49 421 200 3103 > > >> > > >> _______________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netconf > > >> > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c3724c16b8c90528aeda19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 06 Jan 2016, at 19:16, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder <
> > j.schoenw= aelder@jacobs-university.de> wrote:
> >
> >> Hi,
> >>
> >> here is my review of draft-ietf-netconf-yang-library-03.
> >>
> >> a) p2: What are "YANG-based data abstractions"? Do = we need this new
> >>=C2=A0 =C2=A0 term?=C2=A0 Why not simply say "a server th= at implements YANG data
> >>=C2=A0 =C2=A0 models"?
> >>
> >
> >
> > OK
> >
> >
> >
> >>
> >> b) p3: I think it follows from the first bullet that it is il= legal or
> >>=C2=A0 =C2=A0 impossible to implement two different revisions = of a certain module
> >>=C2=A0 =C2=A0 within a single server.
> >>
> >
> >
> > No -- this text should be clarified.
> > It is meant to convey that the name "foo" cannot repres= ent
> > 2 different module names.=C2=A0 It does not mean there can
> > only be 1 entry in the module list for each module name.
>
> I don't understand:
>
> 1. Could there ever be two revisions of a module of the "implemen= t"
>=C2=A0 =C2=A0 type?
>
>
> This is not explicitly prohibited in YANG 1.0 and we cannot
> make any rules now for YANG 1.0, just YANG 1.1.

YANG 1.0 has had no yang-libary so there are no backward compatibility conc= erns affecting this document.=C2=A0
>
>
>
> 2. If there are multiple revisions of a module of the "import&quo= t; type,
>=C2=A0 =C2=A0 then I think it breaks the main purpose of having such mo= dules in the
>=C2=A0 =C2=A0 list - if such a module is imported without revision, how= can a
>=C2=A0 =C2=A0 client determine which revision the server actually uses?=
>
>
>
> The most recent revision listed in the library is used for YANG 1.1.
If module A imports C with revision YYYY-MM-DD, and B imports C without rev= ision, then with this rule it wouldn't be possible for a server impleme= ntor to choose any revision less than YYYY-MM-DD to be used with B. I think= this restriction isn't necessary. Listing module revisions that are im= ported always with revision is redundant.

I would propose that no more that one revision of each module be listed in = yang-library, and those of "import" type will be used exclusively= for resolving imports without revision.



The WG has already disc= ussed this issue several times.
The YANG library lists all the YA= NG modules being used.
The client needs to be able to retrieve th= is list without
needing to parse the modules to find this informa= tion.

For YANG 1.1 the rules are clearly specified= .



Andy
=C2=A0
>
> We cannot fix this issue for YANG 1.0, just YANG 1.1.
>
>
>
>
> ...
>
> >>
> >> l) Is 'restricted-protocol' a good name for the leaf?= It actually
> >>=C2=A0 =C2=A0 means 'not-supported-by-protocol' - is &= #39;excluded-protocol' a better
> >>=C2=A0 =C2=A0 name? So essentially we have a set of modules an= d exceptions - if I
> >>=C2=A0 =C2=A0 have to add a protocol specific module, I need t= o add it to the
> >>=C2=A0 =C2=A0 global set and then setup proper exceptions. I a= ssume the
> >>=C2=A0 =C2=A0 assumption here is that these are rare corner ca= ses. Or should
> >>=C2=A0 =C2=A0 there also be the other alternative, an 'inc= luded-protocol' for
> >>=C2=A0 =C2=A0 adding things to the common set so both operatio= ns are available
> >>=C2=A0 =C2=A0 when needed?
> >>
> >>
> >
> > If a YANG protocol uses the library at all, it is listed in yang-= protocol.
> >
> > If any module entry in the library does not apply to this protoco= l,
> > then the exception entry is needed in each unsupported module. > >
>
> IMO yang-library shouldn't deal with this protocol stuff at all (a= nd
> bother IANA with it or whatever). If a module is protocol-specific, th= en
> it shouldn't be included in yang-library information sent to other=
> protocols.
>
> I believe it is also a security issue - why should clients of all
> protocols know modules that are used by other protocols?
>
> BTW, the term yang-library is perhaps somewhat unfortunate. Most peopl= e
> would think it is a software library, and there are already several YA= NG
> libraries being worked on.
>
> I think people can read the description-stmts and know the difference<= br> > between a YANG library and a software library.
>
> I don't agree it is a risk to list the protocols using YANG module= s on the device.
>
> I don't mind removing all mention of protocols.
> If a client attempts to use a module that is not supported
> by a protocol, they will get an error back.
> This is not really important data.

I think this would be better. A similar error could be a consequence of NAC= M rules.

In any case, returning protocol-specific (and also user-specific) yang-libr= ary contents should IMO be possible.

Lada

>
>
>
>
>
> Lada
>
>
> Andy
>
> >
> >
> >
> >> m) Does it make sense to discuss somewhere a bit what a serve= r is?
> >>=C2=A0 =C2=A0 There will be servers that support multiple prot= ocols but use a
> >>=C2=A0 =C2=A0 common backend server. There will also be deploy= ments where
> >>=C2=A0 =C2=A0 different protocols do not use a common backend;= in this case the
> >>=C2=A0 =C2=A0 protocol servers would report rather different i= nstantiations of
> >>=C2=A0 =C2=A0 the YANG library. Should there be text discussin= g this? Should
> >>=C2=A0 =C2=A0 there be advice that a YANG library retrieved vi= a protocol X should
> >>=C2=A0 =C2=A0 not be assumed to work with protocol Y unless th= e module-set-id has
> >>=C2=A0 =C2=A0 been verified via protocol Y?
> >>
> >
> > IMO so -- this draft defines a library, not a server.
> >
> > The module-set-id is an opaque string with no semantics at all. > >
> > IMO there is no reason to discuss implementation details.
> >
> >
> >
> >
> >>
> >> n) Should yang-protocol be turned into a list instead of a le= af-list
> >>=C2=A0 =C2=A0 to allow future augmentations?
> >>
> >
> >
> > no -- use a leafref to point to the leaf-list
> >
> >
> >
> >>
> >> o) Should we keep in mind that eventually modules are also co= nfigured
> >>=C2=A0 =C2=A0 into servers? That is, we are really defining th= e 'modules-state'
> >>=C2=A0 =C2=A0 tree and not the 'modules' tree (if we f= ollow the foo and foo-state
> >>=C2=A0 =C2=A0 convention). [I expect to get grilled on this on= e.]
> >>
> >>
> > that is why module is defined in a grouping that can be used in a=
> > config=3Dtrue container
> >
> >
> >
> >> /js
> >>
> >
> > Andy
> >
> >
> >
> >>
> >> --
> >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
> >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= conf
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a11c3724c16b8c90528aeda19-- From nobody Wed Jan 6 11:10:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42881A0103 for ; Wed, 6 Jan 2016 11:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd9AumCo3mAm for ; Wed, 6 Jan 2016 11:10:18 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065351A00F6 for ; Wed, 6 Jan 2016 11:10:18 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 787BD18168A; Wed, 6 Jan 2016 20:10:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452107416; bh=MOcasso3uWBQncz/kyoKBHJ1QSFGd4YntjWCnRp4Nr8=; h=From:Date:To; b=btBZ1oTq1+/iuS3JvYc6Cv+M1JM6OZP5LgW4VFmDgM9SCBYOycbPjtqgNCZ/JcrFn BknykcJOw6p8AszUVuy7gR7eEbm/FmrRk9TU4JMOdOnbhlQtY3BGwknl7UHTCbQfir lbiYI0tQnLmpoZ/UfAAsycHEULN3dzOyMk7UEL/4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 6 Jan 2016 20:10:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160105200521.GA24317@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:10:20 -0000 > On 06 Jan 2016, at 19:52, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka = wrote: >=20 > > On 06 Jan 2016, at 19:16, Andy Bierman wrote: > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka = wrote: > > Andy Bierman writes: > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > >> Hi, > > >> > > >> here is my review of draft-ietf-netconf-yang-library-03. > > >> > > >> a) p2: What are "YANG-based data abstractions"? Do we need this = new > > >> term? Why not simply say "a server that implements YANG data > > >> models"? > > >> > > > > > > > > > OK > > > > > > > > > > > >> > > >> b) p3: I think it follows from the first bullet that it is = illegal or > > >> impossible to implement two different revisions of a certain = module > > >> within a single server. > > >> > > > > > > > > > No -- this text should be clarified. > > > It is meant to convey that the name "foo" cannot represent > > > 2 different module names. It does not mean there can > > > only be 1 entry in the module list for each module name. > > > > I don't understand: > > > > 1. Could there ever be two revisions of a module of the "implement" > > type? > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > make any rules now for YANG 1.0, just YANG 1.1. >=20 > YANG 1.0 has had no yang-libary so there are no backward compatibility = concerns affecting this document.=20 > > > > > > > > 2. If there are multiple revisions of a module of the "import" type, > > then I think it breaks the main purpose of having such modules in = the > > list - if such a module is imported without revision, how can a > > client determine which revision the server actually uses? > > > > > > > > The most recent revision listed in the library is used for YANG 1.1. >=20 > If module A imports C with revision YYYY-MM-DD, and B imports C = without revision, then with this rule it wouldn't be possible for a = server implementor to choose any revision less than YYYY-MM-DD to be = used with B. I think this restriction isn't necessary. Listing module = revisions that are imported always with revision is redundant. >=20 > I would propose that no more that one revision of each module be = listed in yang-library, and those of "import" type will be used = exclusively for resolving imports without revision. >=20 >=20 >=20 > The WG has already discussed this issue several times. > The YANG library lists all the YANG modules being used. > The client needs to be able to retrieve this list without > needing to parse the modules to find this information. My position here is exactly the resolution accepted for Y45 (Y45-04), = and I think we should stick to it. >=20 > For YANG 1.1 the rules are clearly specified. Exactly, and this is what 6020bis says: If a server implements a module A that imports a module C without specifying the revision date of module C, and the server does not implement C (e.g., if C only defines some typedefs), the server MUST list module C in the "/modules/module" list from "ietf-yang-library" [I-D.ietf-netconf-yang-library], and it MUST set the leaf "conformance" to "import" for this module. It doesn't say that modules imported with revision must be listed. Lada >=20 >=20 >=20 > Andy >=20 > =20 > > > > We cannot fix this issue for YANG 1.0, just YANG 1.1. > > > > > > > > > > ... > > > > >> > > >> l) Is 'restricted-protocol' a good name for the leaf? It actually > > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a = better > > >> name? So essentially we have a set of modules and exceptions - = if I > > >> have to add a protocol specific module, I need to add it to = the > > >> global set and then setup proper exceptions. I assume the > > >> assumption here is that these are rare corner cases. Or should > > >> there also be the other alternative, an 'included-protocol' = for > > >> adding things to the common set so both operations are = available > > >> when needed? > > >> > > >> > > > > > > If a YANG protocol uses the library at all, it is listed in = yang-protocol. > > > > > > If any module entry in the library does not apply to this = protocol, > > > then the exception entry is needed in each unsupported module. > > > > > > > IMO yang-library shouldn't deal with this protocol stuff at all (and > > bother IANA with it or whatever). If a module is protocol-specific, = then > > it shouldn't be included in yang-library information sent to other > > protocols. > > > > I believe it is also a security issue - why should clients of all > > protocols know modules that are used by other protocols? > > > > BTW, the term yang-library is perhaps somewhat unfortunate. Most = people > > would think it is a software library, and there are already several = YANG > > libraries being worked on. > > > > I think people can read the description-stmts and know the = difference > > between a YANG library and a software library. > > > > I don't agree it is a risk to list the protocols using YANG modules = on the device. > > > > I don't mind removing all mention of protocols. > > If a client attempts to use a module that is not supported > > by a protocol, they will get an error back. > > This is not really important data. >=20 > I think this would be better. A similar error could be a consequence = of NACM rules. >=20 > In any case, returning protocol-specific (and also user-specific) = yang-library contents should IMO be possible. >=20 > Lada >=20 > > > > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server = is? > > >> There will be servers that support multiple protocols but use = a > > >> common backend server. There will also be deployments where > > >> different protocols do not use a common backend; in this case = the > > >> protocol servers would report rather different instantiations = of > > >> the YANG library. Should there be text discussing this? Should > > >> there be advice that a YANG library retrieved via protocol X = should > > >> not be assumed to work with protocol Y unless the = module-set-id has > > >> been verified via protocol Y? > > >> > > > > > > IMO so -- this draft defines a library, not a server. > > > > > > The module-set-id is an opaque string with no semantics at all. > > > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > > > > > > >> > > >> n) Should yang-protocol be turned into a list instead of a = leaf-list > > >> to allow future augmentations? > > >> > > > > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > > > > > >> > > >> o) Should we keep in mind that eventually modules are also = configured > > >> into servers? That is, we are really defining the = 'modules-state' > > >> tree and not the 'modules' tree (if we follow the foo and = foo-state > > >> convention). [I expect to get grilled on this one.] > > >> > > >> > > > that is why module is defined in a grouping that can be used in a > > > config=3Dtrue container > > > > > > > > > > > >> /js > > >> > > > > > > Andy > > > > > > > > > > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > >> Fax: +49 421 200 3103 = > > >> > > >> _______________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netconf > > >> > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 6 11:16:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B771A010F for ; Wed, 6 Jan 2016 11:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVMaT1vUh4au for ; Wed, 6 Jan 2016 11:16:55 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B3B1A011C for ; Wed, 6 Jan 2016 11:16:54 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id y184so318816622lfc.1 for ; Wed, 06 Jan 2016 11:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ldKlyYmfXmvrrfC79oRBe0EXdwIoDawJTrUAwBTyF+Q=; b=gfcLKaWfBr0zHfHXd64ySBQKLfaivTCjHlM8x28cbZsn1PyAY3bkg0fDcVdewV6BOh PBnaAkim16J8LFAUgVLwf87PAJqM1k/xznJVri5aAD5JSzfHBAZOFkcrJaw5yDyGW86z z0t3ROUQQ9NUKMj6DNP0yF7oZf76utpHYkOYExWgs1gAu4qk4lVmJG/XE697Q4+RKAzM cv9c1AFpwYKAOTQfZk8txXBYay0cN7E9yMjuPYylDsS4cciy7KiPVvZ0EtdRkc39dCvs XsYvoHhkpnCdPCKnTB69jo1iZPDNOdeo8iQ6q21trULfgD5/KLbncep7axIAWZriTDyR VrNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ldKlyYmfXmvrrfC79oRBe0EXdwIoDawJTrUAwBTyF+Q=; b=HcWnVoywAY0F8DnJ1NQuG+S2MYfxskz8XzSNdu2cEUjMyurjUv6yiO5pDTm7/kvsYf ZT3lwJ9IPNUUlFBdyjZ2TYrhix76e7QwkUc1b3Yy89AzXT1Dh06uZ+1Vao/qpveoI/VH qN7DaWBhHQ0VETpkZloWN9kx+fhvCUdk62mmGE7swEQy1q6FriH8lVj90AHfYGqDQMFc 6MfZwrE8iyfWXW0RnwXOj5P07bJHhb0HICfcVnAeEsrCsKkkmsDROT06hCzwmqjN++eZ A9bB/sfZGByKEBfZTLWBYpOtp24hacgAj8GqG8EVXRGFMwz22KjOsIuEN3HgC2/oZfkQ ZEAQ== X-Gm-Message-State: ALoCoQljjOAPxfkYoulz4WMOe18TnTyg5fd85t+u6+KlrS8JcDPReviqZhDaY4e4YSiVCYtCFs/R4OMljo8qUKKYRTnAbYvkhQ== MIME-Version: 1.0 X-Received: by 10.25.64.9 with SMTP id n9mr36149945lfa.13.1452107812522; Wed, 06 Jan 2016 11:16:52 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 6 Jan 2016 11:16:52 -0800 (PST) In-Reply-To: References: <20160105200521.GA24317@elstar.local> Date: Wed, 6 Jan 2016 11:16:52 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113ea4f65767810528af321d Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:16:58 -0000 --001a113ea4f65767810528af321d Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka wrote: > > > On 06 Jan 2016, at 19:52, Andy Bierman wrote: > > > > > > > > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka wrote: > > > > > On 06 Jan 2016, at 19:16, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka > wrote: > > > Andy Bierman writes: > > > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > >> Hi, > > > >> > > > >> here is my review of draft-ietf-netconf-yang-library-03. > > > >> > > > >> a) p2: What are "YANG-based data abstractions"? Do we need this new > > > >> term? Why not simply say "a server that implements YANG data > > > >> models"? > > > >> > > > > > > > > > > > > OK > > > > > > > > > > > > > > > >> > > > >> b) p3: I think it follows from the first bullet that it is illegal > or > > > >> impossible to implement two different revisions of a certain > module > > > >> within a single server. > > > >> > > > > > > > > > > > > No -- this text should be clarified. > > > > It is meant to convey that the name "foo" cannot represent > > > > 2 different module names. It does not mean there can > > > > only be 1 entry in the module list for each module name. > > > > > > I don't understand: > > > > > > 1. Could there ever be two revisions of a module of the "implement" > > > type? > > > > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > > make any rules now for YANG 1.0, just YANG 1.1. > > > > YANG 1.0 has had no yang-libary so there are no backward compatibility > concerns affecting this document. > > > > > > > > > > > > 2. If there are multiple revisions of a module of the "import" type, > > > then I think it breaks the main purpose of having such modules in > the > > > list - if such a module is imported without revision, how can a > > > client determine which revision the server actually uses? > > > > > > > > > > > > The most recent revision listed in the library is used for YANG 1.1. > > > > If module A imports C with revision YYYY-MM-DD, and B imports C without > revision, then with this rule it wouldn't be possible for a server > implementor to choose any revision less than YYYY-MM-DD to be used with B. > I think this restriction isn't necessary. Listing module revisions that are > imported always with revision is redundant. > > > > I would propose that no more that one revision of each module be listed > in yang-library, and those of "import" type will be used exclusively for > resolving imports without revision. > > > > > > > > The WG has already discussed this issue several times. > > The YANG library lists all the YANG modules being used. > > The client needs to be able to retrieve this list without > > needing to parse the modules to find this information. > > My position here is exactly the resolution accepted for Y45 (Y45-04), and > I think we should stick to it. > > This has nothing to do with Y45. The YANG library lists all the YANG modules. That is what is operationally useful. Andy > > > > For YANG 1.1 the rules are clearly specified. > > Exactly, and this is what 6020bis says: > > If a server implements a module A that imports a module C without > specifying the revision date of module C, and the server does not > implement C (e.g., if C only defines some typedefs), the server MUST > list module C in the "/modules/module" list from "ietf-yang-library" > [I-D.ietf-netconf-yang-library], and it MUST set the leaf > "conformance" to "import" for this module. > > It doesn't say that modules imported with revision must be listed. > > Lada > > > > > > > > > Andy > > > > > > > > > > We cannot fix this issue for YANG 1.0, just YANG 1.1. > > > > > > > > > > > > > > > ... > > > > > > >> > > > >> l) Is 'restricted-protocol' a good name for the leaf? It actually > > > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a > better > > > >> name? So essentially we have a set of modules and exceptions - > if I > > > >> have to add a protocol specific module, I need to add it to the > > > >> global set and then setup proper exceptions. I assume the > > > >> assumption here is that these are rare corner cases. Or should > > > >> there also be the other alternative, an 'included-protocol' for > > > >> adding things to the common set so both operations are available > > > >> when needed? > > > >> > > > >> > > > > > > > > If a YANG protocol uses the library at all, it is listed in > yang-protocol. > > > > > > > > If any module entry in the library does not apply to this protocol, > > > > then the exception entry is needed in each unsupported module. > > > > > > > > > > IMO yang-library shouldn't deal with this protocol stuff at all (and > > > bother IANA with it or whatever). If a module is protocol-specific, > then > > > it shouldn't be included in yang-library information sent to other > > > protocols. > > > > > > I believe it is also a security issue - why should clients of all > > > protocols know modules that are used by other protocols? > > > > > > BTW, the term yang-library is perhaps somewhat unfortunate. Most people > > > would think it is a software library, and there are already several > YANG > > > libraries being worked on. > > > > > > I think people can read the description-stmts and know the difference > > > between a YANG library and a software library. > > > > > > I don't agree it is a risk to list the protocols using YANG modules on > the device. > > > > > > I don't mind removing all mention of protocols. > > > If a client attempts to use a module that is not supported > > > by a protocol, they will get an error back. > > > This is not really important data. > > > > I think this would be better. A similar error could be a consequence of > NACM rules. > > > > In any case, returning protocol-specific (and also user-specific) > yang-library contents should IMO be possible. > > > > Lada > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server is? > > > >> There will be servers that support multiple protocols but use a > > > >> common backend server. There will also be deployments where > > > >> different protocols do not use a common backend; in this case the > > > >> protocol servers would report rather different instantiations of > > > >> the YANG library. Should there be text discussing this? Should > > > >> there be advice that a YANG library retrieved via protocol X > should > > > >> not be assumed to work with protocol Y unless the module-set-id > has > > > >> been verified via protocol Y? > > > >> > > > > > > > > IMO so -- this draft defines a library, not a server. > > > > > > > > The module-set-id is an opaque string with no semantics at all. > > > > > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > > > > > > > > > > > >> > > > >> n) Should yang-protocol be turned into a list instead of a leaf-list > > > >> to allow future augmentations? > > > >> > > > > > > > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > > > > > > > > > >> > > > >> o) Should we keep in mind that eventually modules are also > configured > > > >> into servers? That is, we are really defining the 'modules-state' > > > >> tree and not the 'modules' tree (if we follow the foo and > foo-state > > > >> convention). [I expect to get grilled on this one.] > > > >> > > > >> > > > > that is why module is defined in a grouping that can be used in a > > > > config=true container > > > > > > > > > > > > > > > >> /js > > > >> > > > > > > > > Andy > > > > > > > > > > > > > > > >> > > > >> -- > > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > >> Fax: +49 421 200 3103 > > > >> > > > >> _______________________________________________ > > > >> Netconf mailing list > > > >> Netconf@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/netconf > > > >> > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > > 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 > > > > > --001a113ea4f65767810528af321d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 06 Jan 2016, at 19:52, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 06 Jan 2016, at 19:16, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaw= orks.com> writes:
> >
> > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > >> Hi,
> > >>
> > >> here is my review of draft-ietf-netconf-yang-library-03.=
> > >>
> > >> a) p2: What are "YANG-based data abstractions"= ? Do we need this new
> > >>=C2=A0 =C2=A0 term?=C2=A0 Why not simply say "a serv= er that implements YANG data
> > >>=C2=A0 =C2=A0 models"?
> > >>
> > >
> > >
> > > OK
> > >
> > >
> > >
> > >>
> > >> b) p3: I think it follows from the first bullet that it = is illegal or
> > >>=C2=A0 =C2=A0 impossible to implement two different revis= ions of a certain module
> > >>=C2=A0 =C2=A0 within a single server.
> > >>
> > >
> > >
> > > No -- this text should be clarified.
> > > It is meant to convey that the name "foo" cannot r= epresent
> > > 2 different module names.=C2=A0 It does not mean there can > > > only be 1 entry in the module list for each module name.
> >
> > I don't understand:
> >
> > 1. Could there ever be two revisions of a module of the "imp= lement"
> >=C2=A0 =C2=A0 type?
> >
> >
> > This is not explicitly prohibited in YANG 1.0 and we cannot
> > make any rules now for YANG 1.0, just YANG 1.1.
>
> YANG 1.0 has had no yang-libary so there are no backward compatibility= concerns affecting this document.
> >
> >
> >
> > 2. If there are multiple revisions of a module of the "impor= t" type,
> >=C2=A0 =C2=A0 then I think it breaks the main purpose of having su= ch modules in the
> >=C2=A0 =C2=A0 list - if such a module is imported without revision= , how can a
> >=C2=A0 =C2=A0 client determine which revision the server actually = uses?
> >
> >
> >
> > The most recent revision listed in the library is used for YANG 1= .1.
>
> If module A imports C with revision YYYY-MM-DD, and B imports C withou= t revision, then with this rule it wouldn't be possible for a server im= plementor to choose any revision less than YYYY-MM-DD to be used with B. I = think this restriction isn't necessary. Listing module revisions that a= re imported always with revision is redundant.
>
> I would propose that no more that one revision of each module be liste= d in yang-library, and those of "import" type will be used exclus= ively for resolving imports without revision.
>
>
>
> The WG has already discussed this issue several times.
> The YANG library lists all the YANG modules being used.
> The client needs to be able to retrieve this list without
> needing to parse the modules to find this information.

My position here is exactly the resolution accepted for Y45 (Y45-04), and I= think we should stick to it.




This has= nothing to do with Y45.
The YANG library lists all the YANG modu= les.
That is what is operationally useful.


Andy
=C2=A0
>
> For YANG 1.1 the rules are clearly specified.

Exactly, and this is what 6020bis says:

=C2=A0 =C2=A0If a server implements a module A that imports a module C with= out
=C2=A0 =C2=A0specifying the revision date of module C, and the server does = not
=C2=A0 =C2=A0implement C (e.g., if C only defines some typedefs), the serve= r MUST
=C2=A0 =C2=A0list module C in the "/modules/module" list from &qu= ot;ietf-yang-library"
=C2=A0 =C2=A0[I-D.ietf-netconf-yang-library], and it MUST set the leaf
=C2=A0 =C2=A0"conformance" to "import" for this module.=

It doesn't say that modules imported with revision must be listed.

Lada

>
>
>
> Andy
>
>
> >
> > We cannot fix this issue for YANG 1.0, just YANG 1.1.
> >
> >
> >
> >
> > ...
> >
> > >>
> > >> l) Is 'restricted-protocol' a good name for the = leaf? It actually
> > >>=C2=A0 =C2=A0 means 'not-supported-by-protocol' -= is 'excluded-protocol' a better
> > >>=C2=A0 =C2=A0 name? So essentially we have a set of modul= es and exceptions - if I
> > >>=C2=A0 =C2=A0 have to add a protocol specific module, I n= eed to add it to the
> > >>=C2=A0 =C2=A0 global set and then setup proper exceptions= . I assume the
> > >>=C2=A0 =C2=A0 assumption here is that these are rare corn= er cases. Or should
> > >>=C2=A0 =C2=A0 there also be the other alternative, an = 9;included-protocol' for
> > >>=C2=A0 =C2=A0 adding things to the common set so both ope= rations are available
> > >>=C2=A0 =C2=A0 when needed?
> > >>
> > >>
> > >
> > > If a YANG protocol uses the library at all, it is listed in = yang-protocol.
> > >
> > > If any module entry in the library does not apply to this pr= otocol,
> > > then the exception entry is needed in each unsupported modul= e.
> > >
> >
> > IMO yang-library shouldn't deal with this protocol stuff at a= ll (and
> > bother IANA with it or whatever). If a module is protocol-specifi= c, then
> > it shouldn't be included in yang-library information sent to = other
> > protocols.
> >
> > I believe it is also a security issue - why should clients of all=
> > protocols know modules that are used by other protocols?
> >
> > BTW, the term yang-library is perhaps somewhat unfortunate. Most = people
> > would think it is a software library, and there are already sever= al YANG
> > libraries being worked on.
> >
> > I think people can read the description-stmts and know the differ= ence
> > between a YANG library and a software library.
> >
> > I don't agree it is a risk to list the protocols using YANG m= odules on the device.
> >
> > I don't mind removing all mention of protocols.
> > If a client attempts to use a module that is not supported
> > by a protocol, they will get an error back.
> > This is not really important data.
>
> I think this would be better. A similar error could be a consequence o= f NACM rules.
>
> In any case, returning protocol-specific (and also user-specific) yang= -library contents should IMO be possible.
>
> Lada
>
> >
> >
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > >
> > >
> > >
> > >> m) Does it make sense to discuss somewhere a bit what a = server is?
> > >>=C2=A0 =C2=A0 There will be servers that support multiple= protocols but use a
> > >>=C2=A0 =C2=A0 common backend server. There will also be d= eployments where
> > >>=C2=A0 =C2=A0 different protocols do not use a common bac= kend; in this case the
> > >>=C2=A0 =C2=A0 protocol servers would report rather differ= ent instantiations of
> > >>=C2=A0 =C2=A0 the YANG library. Should there be text disc= ussing this? Should
> > >>=C2=A0 =C2=A0 there be advice that a YANG library retriev= ed via protocol X should
> > >>=C2=A0 =C2=A0 not be assumed to work with protocol Y unle= ss the module-set-id has
> > >>=C2=A0 =C2=A0 been verified via protocol Y?
> > >>
> > >
> > > IMO so -- this draft defines a library, not a server.
> > >
> > > The module-set-id is an opaque string with no semantics at a= ll.
> > >
> > > IMO there is no reason to discuss implementation details. > > >
> > >
> > >
> > >
> > >>
> > >> n) Should yang-protocol be turned into a list instead of= a leaf-list
> > >>=C2=A0 =C2=A0 to allow future augmentations?
> > >>
> > >
> > >
> > > no -- use a leafref to point to the leaf-list
> > >
> > >
> > >
> > >>
> > >> o) Should we keep in mind that eventually modules are al= so configured
> > >>=C2=A0 =C2=A0 into servers? That is, we are really defini= ng the 'modules-state'
> > >>=C2=A0 =C2=A0 tree and not the 'modules' tree (if= we follow the foo and foo-state
> > >>=C2=A0 =C2=A0 convention). [I expect to get grilled on th= is one.]
> > >>
> > >>
> > > that is why module is defined in a grouping that can be used= in a
> > > config=3Dtrue container
> > >
> > >
> > >
> > >> /js
> > >>
> > >
> > > Andy
> > >
> > >
> > >
> > >>
> > >> --
> > >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<http://www.jacobs-university.de/>
> > >>
> > >> _______________________________________________
> > >> Netconf mailing list
> > >> Netconf@ietf.org=
> > >> https://www.ietf.org/mailman/listinf= o/netconf
> > >>
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ne= tconf
> >
> > --
> > 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





--001a113ea4f65767810528af321d-- From nobody Wed Jan 6 11:34:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60E1A0158 for ; Wed, 6 Jan 2016 11:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXEvFJxkeLkd for ; Wed, 6 Jan 2016 11:34:50 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBAE1A0155 for ; Wed, 6 Jan 2016 11:34:50 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 5D759181486; Wed, 6 Jan 2016 20:34:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452108888; bh=PHkeaXg1m1Lt7OLG6dHERsubX9oybA73ObvcEALS3zA=; h=From:Date:To; b=Fl/n9tJK5boBlNAjYkkZvotKIYJyu5NreiQE4L2vvAmDUzGXpWLTgM7wLlQqrrUal q9zbRhyJhMjsW2UetTxjrcIQOXAPxWdtvTcQYKgpBRuFYoKAUMvgH/IoPGTmFb15vz adRChnXZe6x9NYa3h6ep0Aukt5+v8Y8BnHb2/Xs4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 6 Jan 2016 20:34:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <69694EA3-8400-466F-BED9-134CAAAF99CC@nic.cz> References: <20160105200521.GA24317@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:34:54 -0000 > On 06 Jan 2016, at 20:16, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka = wrote: >=20 > > On 06 Jan 2016, at 19:52, Andy Bierman wrote: > > > > > > > > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka = wrote: > > > > > On 06 Jan 2016, at 19:16, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka = wrote: > > > Andy Bierman writes: > > > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > >> Hi, > > > >> > > > >> here is my review of draft-ietf-netconf-yang-library-03. > > > >> > > > >> a) p2: What are "YANG-based data abstractions"? Do we need this = new > > > >> term? Why not simply say "a server that implements YANG = data > > > >> models"? > > > >> > > > > > > > > > > > > OK > > > > > > > > > > > > > > > >> > > > >> b) p3: I think it follows from the first bullet that it is = illegal or > > > >> impossible to implement two different revisions of a certain = module > > > >> within a single server. > > > >> > > > > > > > > > > > > No -- this text should be clarified. > > > > It is meant to convey that the name "foo" cannot represent > > > > 2 different module names. It does not mean there can > > > > only be 1 entry in the module list for each module name. > > > > > > I don't understand: > > > > > > 1. Could there ever be two revisions of a module of the = "implement" > > > type? > > > > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > > make any rules now for YANG 1.0, just YANG 1.1. > > > > YANG 1.0 has had no yang-libary so there are no backward = compatibility concerns affecting this document. > > > > > > > > > > > > 2. If there are multiple revisions of a module of the "import" = type, > > > then I think it breaks the main purpose of having such modules = in the > > > list - if such a module is imported without revision, how can a > > > client determine which revision the server actually uses? > > > > > > > > > > > > The most recent revision listed in the library is used for YANG = 1.1. > > > > If module A imports C with revision YYYY-MM-DD, and B imports C = without revision, then with this rule it wouldn't be possible for a = server implementor to choose any revision less than YYYY-MM-DD to be = used with B. I think this restriction isn't necessary. Listing module = revisions that are imported always with revision is redundant. > > > > I would propose that no more that one revision of each module be = listed in yang-library, and those of "import" type will be used = exclusively for resolving imports without revision. > > > > > > > > The WG has already discussed this issue several times. > > The YANG library lists all the YANG modules being used. > > The client needs to be able to retrieve this list without > > needing to parse the modules to find this information. >=20 > My position here is exactly the resolution accepted for Y45 (Y45-04), = and I think we should stick to it. >=20 >=20 >=20 >=20 > This has nothing to do with Y45. Come on, so what is Y45 about? 6020bis explicitly refers to yang-library = draft, so there is a strong connection. > The YANG library lists all the YANG modules. > That is what is operationally useful. How do you measure operational usefulness? All protocols could easily = work even if modules imported with revision aren't listed. Lada >=20 >=20 > Andy > =20 > > > > For YANG 1.1 the rules are clearly specified. >=20 > Exactly, and this is what 6020bis says: >=20 > If a server implements a module A that imports a module C without > specifying the revision date of module C, and the server does not > implement C (e.g., if C only defines some typedefs), the server = MUST > list module C in the "/modules/module" list from = "ietf-yang-library" > [I-D.ietf-netconf-yang-library], and it MUST set the leaf > "conformance" to "import" for this module. >=20 > It doesn't say that modules imported with revision must be listed. >=20 > Lada >=20 > > > > > > > > Andy > > > > > > > > > > We cannot fix this issue for YANG 1.0, just YANG 1.1. > > > > > > > > > > > > > > > ... > > > > > > >> > > > >> l) Is 'restricted-protocol' a good name for the leaf? It = actually > > > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a = better > > > >> name? So essentially we have a set of modules and exceptions = - if I > > > >> have to add a protocol specific module, I need to add it to = the > > > >> global set and then setup proper exceptions. I assume the > > > >> assumption here is that these are rare corner cases. Or = should > > > >> there also be the other alternative, an 'included-protocol' = for > > > >> adding things to the common set so both operations are = available > > > >> when needed? > > > >> > > > >> > > > > > > > > If a YANG protocol uses the library at all, it is listed in = yang-protocol. > > > > > > > > If any module entry in the library does not apply to this = protocol, > > > > then the exception entry is needed in each unsupported module. > > > > > > > > > > IMO yang-library shouldn't deal with this protocol stuff at all = (and > > > bother IANA with it or whatever). If a module is = protocol-specific, then > > > it shouldn't be included in yang-library information sent to other > > > protocols. > > > > > > I believe it is also a security issue - why should clients of all > > > protocols know modules that are used by other protocols? > > > > > > BTW, the term yang-library is perhaps somewhat unfortunate. Most = people > > > would think it is a software library, and there are already = several YANG > > > libraries being worked on. > > > > > > I think people can read the description-stmts and know the = difference > > > between a YANG library and a software library. > > > > > > I don't agree it is a risk to list the protocols using YANG = modules on the device. > > > > > > I don't mind removing all mention of protocols. > > > If a client attempts to use a module that is not supported > > > by a protocol, they will get an error back. > > > This is not really important data. > > > > I think this would be better. A similar error could be a consequence = of NACM rules. > > > > In any case, returning protocol-specific (and also user-specific) = yang-library contents should IMO be possible. > > > > Lada > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server = is? > > > >> There will be servers that support multiple protocols but = use a > > > >> common backend server. There will also be deployments where > > > >> different protocols do not use a common backend; in this = case the > > > >> protocol servers would report rather different = instantiations of > > > >> the YANG library. Should there be text discussing this? = Should > > > >> there be advice that a YANG library retrieved via protocol X = should > > > >> not be assumed to work with protocol Y unless the = module-set-id has > > > >> been verified via protocol Y? > > > >> > > > > > > > > IMO so -- this draft defines a library, not a server. > > > > > > > > The module-set-id is an opaque string with no semantics at all. > > > > > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > > > > > > > > > > > >> > > > >> n) Should yang-protocol be turned into a list instead of a = leaf-list > > > >> to allow future augmentations? > > > >> > > > > > > > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > > > > > > > > > >> > > > >> o) Should we keep in mind that eventually modules are also = configured > > > >> into servers? That is, we are really defining the = 'modules-state' > > > >> tree and not the 'modules' tree (if we follow the foo and = foo-state > > > >> convention). [I expect to get grilled on this one.] > > > >> > > > >> > > > > that is why module is defined in a grouping that can be used in = a > > > > config=3Dtrue container > > > > > > > > > > > > > > > >> /js > > > >> > > > > > > > > Andy > > > > > > > > > > > > > > > >> > > > >> -- > > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > > >> Fax: +49 421 200 3103 = > > > >> > > > >> _______________________________________________ > > > >> Netconf mailing list > > > >> Netconf@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/netconf > > > >> > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 6 11:49:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDAD1A01A1 for ; Wed, 6 Jan 2016 11:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8g1uKo923wA for ; Wed, 6 Jan 2016 11:49:14 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F831A0196 for ; Wed, 6 Jan 2016 11:49:13 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id sv6so189142074lbb.0 for ; Wed, 06 Jan 2016 11:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TirV4kh9uHciGQ41y/mTzImcraUDIiFYqijKHZg3GxE=; b=bGTxHqIL5YLzXziFKMiTxrjnlYko3hPihIbYMiog0eLPGvmvcCgrfo7rhojpEHhXmI +pumAytuUdpxFODuX1xkaYanv2gZE4OT52wpgjcXJJn9EyOPaUDRbt5DXZUMC5Ckhe3s 9G+sr+4uLi38s6QTswA+zmNV1rqScLCvgeJ8TNh/QdMJ8Si3fBtR704iTFD0l/4aIvQG Tn/Eqhxi3z9HUHk8aw54Fa9iFXcReJkDmZ/gACTsHac0YpPwYpBzpfdiBhDrVqzgGQhE SGIytV6VG0bN3aNNliVOqM1UoiDHks5q2XPe/MvyAKW764S3AWpK/9GTK5kFt6ZttzTy GavA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TirV4kh9uHciGQ41y/mTzImcraUDIiFYqijKHZg3GxE=; b=isGyBZ/42XHrMjfsZjAnMSO49ZTjX7liGKfrkvICV+zHMQ3M20m9Ap2Li8n9Lny+Qh RLwKeeXlp4OrrDLSuyjybrNfzJ24xkKzcqt5ZDiGZ/I59+poRBW+1417nbTfbXYQ8kVE BtEaGQP86alcS+iOobP9NhRMiB+mEZC3R/58jBLPyzoPHFITP2M2JI/xog09N5dMJ2Oo Zro98QGhqP/2JVxKxxTbiRLj1wV2sFrqavg/UXz99QFSPOS5SYPuRCCB+OfWAaa5A/cN qreXewGUHSNmeSUVhIkdxJyrw5qqcSK+W9ai1qG255NtmfVpLQz5dqDWH9EnoWbaVYtZ uH4A== X-Gm-Message-State: ALoCoQmkGliz5IXmZmmRdwISB+bSpZB3PVlYhaT8f0/Tjj8zQ5TqojaCBYW/Nuc5TFiefPFPE4fPhQXp1x9n1v1Bw9bqlrvgYQ== MIME-Version: 1.0 X-Received: by 10.112.199.41 with SMTP id jh9mr28758365lbc.119.1452109751526; Wed, 06 Jan 2016 11:49:11 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 6 Jan 2016 11:49:11 -0800 (PST) In-Reply-To: <69694EA3-8400-466F-BED9-134CAAAF99CC@nic.cz> References: <20160105200521.GA24317@elstar.local> <69694EA3-8400-466F-BED9-134CAAAF99CC@nic.cz> Date: Wed, 6 Jan 2016 11:49:11 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c23682ea54f80528afa596 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:49:17 -0000 --001a11c23682ea54f80528afa596 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 11:34 AM, Ladislav Lhotka wrote: > > > On 06 Jan 2016, at 20:16, Andy Bierman wrote: > > > > > > > > On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka wrote: > > > > > On 06 Jan 2016, at 19:52, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka > wrote: > > > > > > > On 06 Jan 2016, at 19:16, Andy Bierman wrote: > > > > > > > > > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka > wrote: > > > > Andy Bierman writes: > > > > > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> here is my review of draft-ietf-netconf-yang-library-03. > > > > >> > > > > >> a) p2: What are "YANG-based data abstractions"? Do we need this > new > > > > >> term? Why not simply say "a server that implements YANG data > > > > >> models"? > > > > >> > > > > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > >> > > > > >> b) p3: I think it follows from the first bullet that it is > illegal or > > > > >> impossible to implement two different revisions of a certain > module > > > > >> within a single server. > > > > >> > > > > > > > > > > > > > > > No -- this text should be clarified. > > > > > It is meant to convey that the name "foo" cannot represent > > > > > 2 different module names. It does not mean there can > > > > > only be 1 entry in the module list for each module name. > > > > > > > > I don't understand: > > > > > > > > 1. Could there ever be two revisions of a module of the "implement" > > > > type? > > > > > > > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > > > make any rules now for YANG 1.0, just YANG 1.1. > > > > > > YANG 1.0 has had no yang-libary so there are no backward compatibility > concerns affecting this document. > > > > > > > > > > > > > > > > 2. If there are multiple revisions of a module of the "import" type, > > > > then I think it breaks the main purpose of having such modules in > the > > > > list - if such a module is imported without revision, how can a > > > > client determine which revision the server actually uses? > > > > > > > > > > > > > > > > The most recent revision listed in the library is used for YANG 1.1. > > > > > > If module A imports C with revision YYYY-MM-DD, and B imports C > without revision, then with this rule it wouldn't be possible for a server > implementor to choose any revision less than YYYY-MM-DD to be used with B. > I think this restriction isn't necessary. Listing module revisions that are > imported always with revision is redundant. > > > > > > I would propose that no more that one revision of each module be > listed in yang-library, and those of "import" type will be used exclusively > for resolving imports without revision. > > > > > > > > > > > > The WG has already discussed this issue several times. > > > The YANG library lists all the YANG modules being used. > > > The client needs to be able to retrieve this list without > > > needing to parse the modules to find this information. > > > > My position here is exactly the resolution accepted for Y45 (Y45-04), > and I think we should stick to it. > > > > > > > > > > This has nothing to do with Y45. > > Come on, so what is Y45 about? 6020bis explicitly refers to yang-library > draft, so there is a strong connection. > Y45 does not have anything to say about how YANG modules should be retrieved for parsing. > > > The YANG library lists all the YANG modules. > > That is what is operationally useful. > > How do you measure operational usefulness? All protocols could easily work > even if modules imported with revision aren't listed. > > It is useful to get the list of modules and then retrieve them. This is much simpler than parsing YANG modules and retrieving them as import-stmts are parsed. Your implementation strategy requires the YANG compiler to be tightly coupled to the retrieval of YANG modules. > Lada > > > > Andy > > > > Andy > > > > > > > > For YANG 1.1 the rules are clearly specified. > > > > Exactly, and this is what 6020bis says: > > > > If a server implements a module A that imports a module C without > > specifying the revision date of module C, and the server does not > > implement C (e.g., if C only defines some typedefs), the server MUST > > list module C in the "/modules/module" list from "ietf-yang-library" > > [I-D.ietf-netconf-yang-library], and it MUST set the leaf > > "conformance" to "import" for this module. > > > > It doesn't say that modules imported with revision must be listed. > > > > Lada > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > We cannot fix this issue for YANG 1.0, just YANG 1.1. > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > >> > > > > >> l) Is 'restricted-protocol' a good name for the leaf? It actually > > > > >> means 'not-supported-by-protocol' - is 'excluded-protocol' a > better > > > > >> name? So essentially we have a set of modules and exceptions - > if I > > > > >> have to add a protocol specific module, I need to add it to the > > > > >> global set and then setup proper exceptions. I assume the > > > > >> assumption here is that these are rare corner cases. Or should > > > > >> there also be the other alternative, an 'included-protocol' for > > > > >> adding things to the common set so both operations are > available > > > > >> when needed? > > > > >> > > > > >> > > > > > > > > > > If a YANG protocol uses the library at all, it is listed in > yang-protocol. > > > > > > > > > > If any module entry in the library does not apply to this protocol, > > > > > then the exception entry is needed in each unsupported module. > > > > > > > > > > > > > IMO yang-library shouldn't deal with this protocol stuff at all (and > > > > bother IANA with it or whatever). If a module is protocol-specific, > then > > > > it shouldn't be included in yang-library information sent to other > > > > protocols. > > > > > > > > I believe it is also a security issue - why should clients of all > > > > protocols know modules that are used by other protocols? > > > > > > > > BTW, the term yang-library is perhaps somewhat unfortunate. Most > people > > > > would think it is a software library, and there are already several > YANG > > > > libraries being worked on. > > > > > > > > I think people can read the description-stmts and know the difference > > > > between a YANG library and a software library. > > > > > > > > I don't agree it is a risk to list the protocols using YANG modules > on the device. > > > > > > > > I don't mind removing all mention of protocols. > > > > If a client attempts to use a module that is not supported > > > > by a protocol, they will get an error back. > > > > This is not really important data. > > > > > > I think this would be better. A similar error could be a consequence > of NACM rules. > > > > > > In any case, returning protocol-specific (and also user-specific) > yang-library contents should IMO be possible. > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a server is? > > > > >> There will be servers that support multiple protocols but use a > > > > >> common backend server. There will also be deployments where > > > > >> different protocols do not use a common backend; in this case > the > > > > >> protocol servers would report rather different instantiations > of > > > > >> the YANG library. Should there be text discussing this? Should > > > > >> there be advice that a YANG library retrieved via protocol X > should > > > > >> not be assumed to work with protocol Y unless the > module-set-id has > > > > >> been verified via protocol Y? > > > > >> > > > > > > > > > > IMO so -- this draft defines a library, not a server. > > > > > > > > > > The module-set-id is an opaque string with no semantics at all. > > > > > > > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > >> n) Should yang-protocol be turned into a list instead of a > leaf-list > > > > >> to allow future augmentations? > > > > >> > > > > > > > > > > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > > > > > > > > > > > > > >> > > > > >> o) Should we keep in mind that eventually modules are also > configured > > > > >> into servers? That is, we are really defining the > 'modules-state' > > > > >> tree and not the 'modules' tree (if we follow the foo and > foo-state > > > > >> convention). [I expect to get grilled on this one.] > > > > >> > > > > >> > > > > > that is why module is defined in a grouping that can be used in a > > > > > config=true container > > > > > > > > > > > > > > > > > > > >> /js > > > > >> > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > >> > > > > >> -- > > > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > >> Fax: +49 421 200 3103 > > > > > >> > > > > >> _______________________________________________ > > > > >> Netconf mailing list > > > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/netconf > > > > >> > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c23682ea54f80528afa596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 6, 2016 at 11:34 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 06 Jan 2016, at 20:16, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 06 Jan 2016, at 19:52, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 06 Jan 2016, at 19:16, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > >
> > >
> > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Andy Bierman <andy@= yumaworks.com> writes:
> > >
> > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder = <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> here is my review of draft-ietf-netconf-yang-librar= y-03.
> > > >>
> > > >> a) p2: What are "YANG-based data abstractions&= quot;? Do we need this new
> > > >>=C2=A0 =C2=A0 term?=C2=A0 Why not simply say "a= server that implements YANG data
> > > >>=C2=A0 =C2=A0 models"?
> > > >>
> > > >
> > > >
> > > > OK
> > > >
> > > >
> > > >
> > > >>
> > > >> b) p3: I think it follows from the first bullet tha= t it is illegal or
> > > >>=C2=A0 =C2=A0 impossible to implement two different = revisions of a certain module
> > > >>=C2=A0 =C2=A0 within a single server.
> > > >>
> > > >
> > > >
> > > > No -- this text should be clarified.
> > > > It is meant to convey that the name "foo" can= not represent
> > > > 2 different module names.=C2=A0 It does not mean there = can
> > > > only be 1 entry in the module list for each module name= .
> > >
> > > I don't understand:
> > >
> > > 1. Could there ever be two revisions of a module of the &quo= t;implement"
> > >=C2=A0 =C2=A0 type?
> > >
> > >
> > > This is not explicitly prohibited in YANG 1.0 and we cannot<= br> > > > make any rules now for YANG 1.0, just YANG 1.1.
> >
> > YANG 1.0 has had no yang-libary so there are no backward compatib= ility concerns affecting this document.
> > >
> > >
> > >
> > > 2. If there are multiple revisions of a module of the "= import" type,
> > >=C2=A0 =C2=A0 then I think it breaks the main purpose of havi= ng such modules in the
> > >=C2=A0 =C2=A0 list - if such a module is imported without rev= ision, how can a
> > >=C2=A0 =C2=A0 client determine which revision the server actu= ally uses?
> > >
> > >
> > >
> > > The most recent revision listed in the library is used for Y= ANG 1.1.
> >
> > If module A imports C with revision YYYY-MM-DD, and B imports C w= ithout revision, then with this rule it wouldn't be possible for a serv= er implementor to choose any revision less than YYYY-MM-DD to be used with = B. I think this restriction isn't necessary. Listing module revisions t= hat are imported always with revision is redundant.
> >
> > I would propose that no more that one revision of each module be = listed in yang-library, and those of "import" type will be used e= xclusively for resolving imports without revision.
> >
> >
> >
> > The WG has already discussed this issue several times.
> > The YANG library lists all the YANG modules being used.
> > The client needs to be able to retrieve this list without
> > needing to parse the modules to find this information.
>
> My position here is exactly the resolution accepted for Y45 (Y45-04), = and I think we should stick to it.
>
>
>
>
> This has nothing to do with Y45.

Come on, so what is Y45 about? 6020bis explicitly refers to yang-library dr= aft, so there is a strong connection.

<= br>
Y45 does not have anything to say about how YANG modules shou= ld
be retrieved for parsing.

=C2=A0

> The YANG library lists all the YANG modules.
> That is what is operationally useful.

How do you measure operational usefulness? All protocols could easily work = even if modules imported with revision aren't listed.



It is useful to get the= list of modules and then retrieve them.
This is much simpler tha= n parsing YANG modules and retrieving
them as import-stmts are pa= rsed. Your implementation strategy
requires the YANG compiler to = be tightly coupled to the retrieval
of YANG modules.
=C2=A0
Lada

>


Andy

=
=C2=A0
>
> Andy
>
> >
> > For YANG 1.1 the rules are clearly specified.
>
> Exactly, and this is what 6020bis says:
>
>=C2=A0 =C2=A0 If a server implements a module A that imports a module C= without
>=C2=A0 =C2=A0 specifying the revision date of module C, and the server = does not
>=C2=A0 =C2=A0 implement C (e.g., if C only defines some typedefs), the = server MUST
>=C2=A0 =C2=A0 list module C in the "/modules/module" list fro= m "ietf-yang-library"
>=C2=A0 =C2=A0 [I-D.ietf-netconf-yang-library], and it MUST set the leaf=
>=C2=A0 =C2=A0 "conformance" to "import" for this mo= dule.
>
> It doesn't say that modules imported with revision must be listed.=
>
> Lada
>
> >
> >
> >
> > Andy
> >
> >
> > >
> > > We cannot fix this issue for YANG 1.0, just YANG 1.1.
> > >
> > >
> > >
> > >
> > > ...
> > >
> > > >>
> > > >> l) Is 'restricted-protocol' a good name for= the leaf? It actually
> > > >>=C2=A0 =C2=A0 means 'not-supported-by-protocol&#= 39; - is 'excluded-protocol' a better
> > > >>=C2=A0 =C2=A0 name? So essentially we have a set of = modules and exceptions - if I
> > > >>=C2=A0 =C2=A0 have to add a protocol specific module= , I need to add it to the
> > > >>=C2=A0 =C2=A0 global set and then setup proper excep= tions. I assume the
> > > >>=C2=A0 =C2=A0 assumption here is that these are rare= corner cases. Or should
> > > >>=C2=A0 =C2=A0 there also be the other alternative, a= n 'included-protocol' for
> > > >>=C2=A0 =C2=A0 adding things to the common set so bot= h operations are available
> > > >>=C2=A0 =C2=A0 when needed?
> > > >>
> > > >>
> > > >
> > > > If a YANG protocol uses the library at all, it is liste= d in yang-protocol.
> > > >
> > > > If any module entry in the library does not apply to th= is protocol,
> > > > then the exception entry is needed in each unsupported = module.
> > > >
> > >
> > > IMO yang-library shouldn't deal with this protocol stuff= at all (and
> > > bother IANA with it or whatever). If a module is protocol-sp= ecific, then
> > > it shouldn't be included in yang-library information sen= t to other
> > > protocols.
> > >
> > > I believe it is also a security issue - why should clients o= f all
> > > protocols know modules that are used by other protocols?
> > >
> > > BTW, the term yang-library is perhaps somewhat unfortunate. = Most people
> > > would think it is a software library, and there are already = several YANG
> > > libraries being worked on.
> > >
> > > I think people can read the description-stmts and know the d= ifference
> > > between a YANG library and a software library.
> > >
> > > I don't agree it is a risk to list the protocols using Y= ANG modules on the device.
> > >
> > > I don't mind removing all mention of protocols.
> > > If a client attempts to use a module that is not supported > > > by a protocol, they will get an error back.
> > > This is not really important data.
> >
> > I think this would be better. A similar error could be a conseque= nce of NACM rules.
> >
> > In any case, returning protocol-specific (and also user-specific)= yang-library contents should IMO be possible.
> >
> > Lada
> >
> > >
> > >
> > >
> > >
> > >
> > > Lada
> > >
> > >
> > > Andy
> > >
> > > >
> > > >
> > > >
> > > >> m) Does it make sense to discuss somewhere a bit wh= at a server is?
> > > >>=C2=A0 =C2=A0 There will be servers that support mul= tiple protocols but use a
> > > >>=C2=A0 =C2=A0 common backend server. There will also= be deployments where
> > > >>=C2=A0 =C2=A0 different protocols do not use a commo= n backend; in this case the
> > > >>=C2=A0 =C2=A0 protocol servers would report rather d= ifferent instantiations of
> > > >>=C2=A0 =C2=A0 the YANG library. Should there be text= discussing this? Should
> > > >>=C2=A0 =C2=A0 there be advice that a YANG library re= trieved via protocol X should
> > > >>=C2=A0 =C2=A0 not be assumed to work with protocol Y= unless the module-set-id has
> > > >>=C2=A0 =C2=A0 been verified via protocol Y?
> > > >>
> > > >
> > > > IMO so -- this draft defines a library, not a server. > > > >
> > > > The module-set-id is an opaque string with no semantics= at all.
> > > >
> > > > IMO there is no reason to discuss implementation detail= s.
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >> n) Should yang-protocol be turned into a list inste= ad of a leaf-list
> > > >>=C2=A0 =C2=A0 to allow future augmentations?
> > > >>
> > > >
> > > >
> > > > no -- use a leafref to point to the leaf-list
> > > >
> > > >
> > > >
> > > >>
> > > >> o) Should we keep in mind that eventually modules a= re also configured
> > > >>=C2=A0 =C2=A0 into servers? That is, we are really d= efining the 'modules-state'
> > > >>=C2=A0 =C2=A0 tree and not the 'modules' tre= e (if we follow the foo and foo-state
> > > >>=C2=A0 =C2=A0 convention). [I expect to get grilled = on this one.]
> > > >>
> > > >>
> > > > that is why module is defined in a grouping that can be= used in a
> > > > config=3Dtrue container
> > > >
> > > >
> > > >
> > > >> /js
> > > >>
> > > >
> > > > Andy
> > > >
> > > >
> > > >
> > > >>
> > > >> --
> > > >> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> > > >> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> > > >> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
> > > >>
> > > >> _______________________________________________
> > > >> Netconf mailing list
> > > >> Netconf@ietf.or= g
> > > >> https://www.ietf.org/mailman/li= stinfo/netconf
> > > >>
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listin= fo/netconf
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a11c23682ea54f80528afa596-- From nobody Wed Jan 6 12:10:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DEF1A01CB for ; Wed, 6 Jan 2016 12:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR_rPJ-0fncw for ; Wed, 6 Jan 2016 12:10:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0CA1A01AE for ; Wed, 6 Jan 2016 12:10:20 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 727B0181752; Wed, 6 Jan 2016 21:10:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452111019; bh=lsfonLPq6MH8UevwS3N5Q+gdIcCKKVL1uiZEFf23g0A=; h=From:Date:To; b=KeGh2xhaDkh9qZApUO2qagnzRiaDGODtY5taWCUGNYKCZA+Pe5+IDu9FWAiwu0ABS o3bakNZj9AgV7bxbWZdQUK8pQWZd8ouzNvCUPbzonpbeAgH1WFriWk1QveVj5I81bP E0OqoKo+qBXPamCHJ7NA86lv8x04hOEoJwVp/aAw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 6 Jan 2016 21:10:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160105200521.GA24317@elstar.local> <69694EA3-8400-466F-BED9-134CAAAF99CC@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:10:24 -0000 > On 06 Jan 2016, at 20:49, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jan 6, 2016 at 11:34 AM, Ladislav Lhotka = wrote: >=20 > > On 06 Jan 2016, at 20:16, Andy Bierman wrote: > > > > > > > > On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka = wrote: > > > > > On 06 Jan 2016, at 19:52, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka = wrote: > > > > > > > On 06 Jan 2016, at 19:16, Andy Bierman = wrote: > > > > > > > > > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka = wrote: > > > > Andy Bierman writes: > > > > > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> here is my review of draft-ietf-netconf-yang-library-03. > > > > >> > > > > >> a) p2: What are "YANG-based data abstractions"? Do we need = this new > > > > >> term? Why not simply say "a server that implements YANG = data > > > > >> models"? > > > > >> > > > > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > >> > > > > >> b) p3: I think it follows from the first bullet that it is = illegal or > > > > >> impossible to implement two different revisions of a = certain module > > > > >> within a single server. > > > > >> > > > > > > > > > > > > > > > No -- this text should be clarified. > > > > > It is meant to convey that the name "foo" cannot represent > > > > > 2 different module names. It does not mean there can > > > > > only be 1 entry in the module list for each module name. > > > > > > > > I don't understand: > > > > > > > > 1. Could there ever be two revisions of a module of the = "implement" > > > > type? > > > > > > > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > > > make any rules now for YANG 1.0, just YANG 1.1. > > > > > > YANG 1.0 has had no yang-libary so there are no backward = compatibility concerns affecting this document. > > > > > > > > > > > > > > > > 2. If there are multiple revisions of a module of the "import" = type, > > > > then I think it breaks the main purpose of having such = modules in the > > > > list - if such a module is imported without revision, how can = a > > > > client determine which revision the server actually uses? > > > > > > > > > > > > > > > > The most recent revision listed in the library is used for YANG = 1.1. > > > > > > If module A imports C with revision YYYY-MM-DD, and B imports C = without revision, then with this rule it wouldn't be possible for a = server implementor to choose any revision less than YYYY-MM-DD to be = used with B. I think this restriction isn't necessary. Listing module = revisions that are imported always with revision is redundant. > > > > > > I would propose that no more that one revision of each module be = listed in yang-library, and those of "import" type will be used = exclusively for resolving imports without revision. > > > > > > > > > > > > The WG has already discussed this issue several times. > > > The YANG library lists all the YANG modules being used. > > > The client needs to be able to retrieve this list without > > > needing to parse the modules to find this information. > > > > My position here is exactly the resolution accepted for Y45 = (Y45-04), and I think we should stick to it. > > > > > > > > > > This has nothing to do with Y45. >=20 > Come on, so what is Y45 about? 6020bis explicitly refers to = yang-library draft, so there is a strong connection. >=20 >=20 > Y45 does not have anything to say about how YANG modules should > be retrieved for parsing. >=20 > =20 >=20 > > The YANG library lists all the YANG modules. > > That is what is operationally useful. >=20 > How do you measure operational usefulness? All protocols could easily = work even if modules imported with revision aren't listed. >=20 >=20 >=20 > It is useful to get the list of modules and then retrieve them. > This is much simpler than parsing YANG modules and retrieving > them as import-stmts are parsed. Your implementation strategy > requires the YANG compiler to be tightly coupled to the retrieval > of YANG modules. This is an implementation detail. The problem I have with listing = imported modules multiple times is that it effectively annihilates the = idea of Y45-04, which is that "import" modules in yang-library are used = for resolving imports without revision. An alternative would be to add another flag to yang-library = ("default-revision"?) saying "this is the revision that is to be used = for imports without revision". Lada=20 >=20 > =20 > Lada >=20 > > >=20 >=20 > Andy >=20 > =20 > > > > Andy > > > > > > > > For YANG 1.1 the rules are clearly specified. > > > > Exactly, and this is what 6020bis says: > > > > If a server implements a module A that imports a module C without > > specifying the revision date of module C, and the server does not > > implement C (e.g., if C only defines some typedefs), the server = MUST > > list module C in the "/modules/module" list from = "ietf-yang-library" > > [I-D.ietf-netconf-yang-library], and it MUST set the leaf > > "conformance" to "import" for this module. > > > > It doesn't say that modules imported with revision must be listed. > > > > Lada > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > We cannot fix this issue for YANG 1.0, just YANG 1.1. > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > >> > > > > >> l) Is 'restricted-protocol' a good name for the leaf? It = actually > > > > >> means 'not-supported-by-protocol' - is 'excluded-protocol' = a better > > > > >> name? So essentially we have a set of modules and = exceptions - if I > > > > >> have to add a protocol specific module, I need to add it = to the > > > > >> global set and then setup proper exceptions. I assume the > > > > >> assumption here is that these are rare corner cases. Or = should > > > > >> there also be the other alternative, an = 'included-protocol' for > > > > >> adding things to the common set so both operations are = available > > > > >> when needed? > > > > >> > > > > >> > > > > > > > > > > If a YANG protocol uses the library at all, it is listed in = yang-protocol. > > > > > > > > > > If any module entry in the library does not apply to this = protocol, > > > > > then the exception entry is needed in each unsupported module. > > > > > > > > > > > > > IMO yang-library shouldn't deal with this protocol stuff at all = (and > > > > bother IANA with it or whatever). If a module is = protocol-specific, then > > > > it shouldn't be included in yang-library information sent to = other > > > > protocols. > > > > > > > > I believe it is also a security issue - why should clients of = all > > > > protocols know modules that are used by other protocols? > > > > > > > > BTW, the term yang-library is perhaps somewhat unfortunate. Most = people > > > > would think it is a software library, and there are already = several YANG > > > > libraries being worked on. > > > > > > > > I think people can read the description-stmts and know the = difference > > > > between a YANG library and a software library. > > > > > > > > I don't agree it is a risk to list the protocols using YANG = modules on the device. > > > > > > > > I don't mind removing all mention of protocols. > > > > If a client attempts to use a module that is not supported > > > > by a protocol, they will get an error back. > > > > This is not really important data. > > > > > > I think this would be better. A similar error could be a = consequence of NACM rules. > > > > > > In any case, returning protocol-specific (and also user-specific) = yang-library contents should IMO be possible. > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > >> m) Does it make sense to discuss somewhere a bit what a = server is? > > > > >> There will be servers that support multiple protocols but = use a > > > > >> common backend server. There will also be deployments = where > > > > >> different protocols do not use a common backend; in this = case the > > > > >> protocol servers would report rather different = instantiations of > > > > >> the YANG library. Should there be text discussing this? = Should > > > > >> there be advice that a YANG library retrieved via protocol = X should > > > > >> not be assumed to work with protocol Y unless the = module-set-id has > > > > >> been verified via protocol Y? > > > > >> > > > > > > > > > > IMO so -- this draft defines a library, not a server. > > > > > > > > > > The module-set-id is an opaque string with no semantics at = all. > > > > > > > > > > IMO there is no reason to discuss implementation details. > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > >> n) Should yang-protocol be turned into a list instead of a = leaf-list > > > > >> to allow future augmentations? > > > > >> > > > > > > > > > > > > > > > no -- use a leafref to point to the leaf-list > > > > > > > > > > > > > > > > > > > >> > > > > >> o) Should we keep in mind that eventually modules are also = configured > > > > >> into servers? That is, we are really defining the = 'modules-state' > > > > >> tree and not the 'modules' tree (if we follow the foo and = foo-state > > > > >> convention). [I expect to get grilled on this one.] > > > > >> > > > > >> > > > > > that is why module is defined in a grouping that can be used = in a > > > > > config=3Dtrue container > > > > > > > > > > > > > > > > > > > >> /js > > > > >> > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > >> > > > > >> -- > > > > >> Juergen Schoenwaelder Jacobs University Bremen = gGmbH > > > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen = | Germany > > > > >> Fax: +49 421 200 3103 = > > > > >> > > > > >> _______________________________________________ > > > > >> Netconf mailing list > > > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/netconf > > > > >> > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -- > > > > 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 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 7 12:23:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667F81A0060 for ; Thu, 7 Jan 2016 12:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ios0ECmgmDIk for ; Thu, 7 Jan 2016 12:23:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908A21A0064 for ; Thu, 7 Jan 2016 12:23:16 -0800 (PST) Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 7 Jan 2016 20:22:54 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0361.006; Thu, 7 Jan 2016 20:22:54 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [IANA #886439] Protocol Action: 'NETCONF Call Home and RESTCONF Call Home' to Proposed Standard (draft-ietf-netconf-call-home-17.txt) Thread-Index: AQHRSYe690+YVA13/U6p5X+MIIPgqJ7wK30A Date: Thu, 7 Jan 2016 20:22:54 +0000 Message-ID: References: <20151228144238.6667.34139.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 5:Y7SWurmvt6KfC7GvVp0Jii/bHRaAdYuKmMoM/k+z1D3n8LPDn8azzOFub02KqJzxUUxpiMUcW5IljIqCwor2JpEE8d42VylXkh2nJWbQBrViwD+07hVDUxx+4VlzC0/04QidP72qExYG+EcD10sUCQ==; 24:Maf2mUgGA3iDzkWpHePUG/rSIGRGF+EmMxxlGkqPp0K+CEDfaX17vYStVfR2Awfsb+Xa48ayogKzM3mSnJkK3b2UfIfu06eCfm5SjojP+o8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450; x-ms-office365-filtering-correlation-id: 308c0c64-91a2-49a5-75d4-08d317a0530c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(479174004)(478694002)(199003)(377454003)(5004730100002)(450100001)(5008740100001)(50986999)(2351001)(76176999)(54356999)(586003)(83716003)(10400500002)(1730700002)(36756003)(5002640100001)(2906002)(1220700001)(66066001)(3846002)(6116002)(102836003)(1096002)(92566002)(4001350100001)(2900100001)(11100500001)(189998001)(97736004)(19580405001)(81156007)(19580395003)(2950100001)(77096005)(87936001)(33656002)(105586002)(107886002)(5001960100002)(106116001)(83506001)(40100003)(561944003)(230783001)(99286002)(106356001)(82746002)(101416001)(2501003)(110136002)(86362001)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6835CD4E730CBC4690C72EF97EF371C9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2016 20:22:54.3809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Subject: [Netconf] FW: [IANA #886439] Protocol Action: 'NETCONF Call Home and RESTCONF Call Home' to Proposed Standard (draft-ietf-netconf-call-home-17.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 20:23:20 -0000 DQpBbnkgdGhvdWdodHMgb24gdGhpcz8gIC0gSSBjYW7igJl0IHRoaW5rIG9mIGEgcmVhc29uIHRv IGRpc2FncmVlIHdpdGggdGhlIHByb3Bvc2FsLi4uDQoNCktlbnQNCg0KDQoNCg0KT24gMS83LzE2 LCAzOjEyIFBNLCAiQW1hbmRhIEJhYmVyIHZpYSBSVCIgPGRyYWZ0cy1hcHByb3ZhbEBpYW5hLm9y Zz4gd3JvdGU6DQoNCj5EZWFyIEF1dGhvcnMsDQo+DQo+QmVmb3JlIHdlIGFzc2lnbiBwb3J0IG51 bWJlcnMgZm9yIHRoaXMgZG9jdW1lbnQsIHdlJ2QgbGlrZSB0byBtYWtlIHN1cmUgeW91J3JlIE9L IHdpdGggdGhlIHByb3Bvc2VkIHZhbHVlcy4gV291bGQgNDMzNCwgNDMzNSwgYW5kIDQzMzYgYmUg YWNjZXB0YWJsZT8gIA0KPg0KPnRoYW5rcywNCj4NCj5BbWFuZGEgQmFiZXINCj5JQU5BIFNlbmlv ciBTcGVjaWFsaXN0DQo+SUNBTk4NCg== From nobody Thu Jan 7 12:28:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2139B1A007C for ; Thu, 7 Jan 2016 12:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulFlk65vEbqu for ; Thu, 7 Jan 2016 12:28:15 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A7F1A0078 for ; Thu, 7 Jan 2016 12:28:15 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u07KSDT6003376 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Jan 2016 20:28:13 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id u07KSCFV000504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 21:28:12 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.48]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0248.002; Thu, 7 Jan 2016 21:28:12 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Kent Watsen , "netconf@ietf.org" Thread-Topic: [IANA #886439] Protocol Action: 'NETCONF Call Home and RESTCONF Call Home' to Proposed Standard (draft-ietf-netconf-call-home-17.txt) Thread-Index: AQHRSYe6VyfjtmT9WE+N/xtCbpnVpZ7wbo0AgAASIFA= Date: Thu, 7 Jan 2016 20:28:11 +0000 Message-ID: References: <20151228144238.6667.34139.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: 1254 X-purgate-ID: 151667::1452198493-00002C61-77971CB9/0/0 Archived-At: Subject: Re: [Netconf] [IANA #886439] Protocol Action: 'NETCONF Call Home and RESTCONF Call Home' to Proposed Standard (draft-ietf-netconf-call-home-17.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 20:28:18 -0000 TmVpdGhlciBkbyBJLg0KDQpNZWhtZXQgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRVhUIEtlbnQgV2F0c2VuDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNywgMjAxNiAyMToy Mw0KVG86IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFtOZXRjb25mXSBGVzogW0lBTkEgIzg4 NjQzOV0gUHJvdG9jb2wgQWN0aW9uOiAnTkVUQ09ORiBDYWxsIEhvbWUgYW5kIFJFU1RDT05GIENh bGwgSG9tZScgdG8gUHJvcG9zZWQgU3RhbmRhcmQgKGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhv bWUtMTcudHh0KQ0KDQoNCkFueSB0aG91Z2h0cyBvbiB0aGlzPyAgLSBJIGNhbuKAmXQgdGhpbmsg b2YgYSByZWFzb24gdG8gZGlzYWdyZWUgd2l0aCB0aGUgcHJvcG9zYWwuLi4NCg0KS2VudA0KDQoN Cg0KDQpPbiAxLzcvMTYsIDM6MTIgUE0sICJBbWFuZGEgQmFiZXIgdmlhIFJUIiA8ZHJhZnRzLWFw cHJvdmFsQGlhbmEub3JnPiB3cm90ZToNCg0KPkRlYXIgQXV0aG9ycywNCj4NCj5CZWZvcmUgd2Ug YXNzaWduIHBvcnQgbnVtYmVycyBmb3IgdGhpcyBkb2N1bWVudCwgd2UnZCBsaWtlIHRvIG1ha2Ug c3VyZSB5b3UncmUgT0sgd2l0aCB0aGUgcHJvcG9zZWQgdmFsdWVzLiBXb3VsZCA0MzM0LCA0MzM1 LCBhbmQgNDMzNiBiZSBhY2NlcHRhYmxlPyAgDQo+DQo+dGhhbmtzLA0KPg0KPkFtYW5kYSBCYWJl cg0KPklBTkEgU2VuaW9yIFNwZWNpYWxpc3QNCj5JQ0FOTg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25m QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cg== From nobody Fri Jan 8 00:55:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028401ACED1 for ; Fri, 8 Jan 2016 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZX2qJvH-9BF for ; Fri, 8 Jan 2016 00:55:38 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C82D1ACED3 for ; Fri, 8 Jan 2016 00:55:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5A57B13FD; Fri, 8 Jan 2016 09:55:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AFYlsEbusImG; Fri, 8 Jan 2016 09:55:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Jan 2016 09:55:35 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7EEA20056; Fri, 8 Jan 2016 09:55:35 +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 oqMDe2zcWPpN; Fri, 8 Jan 2016 09:55:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3ADD220055; Fri, 8 Jan 2016 09:55:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81227397DB41; Fri, 8 Jan 2016 09:55:32 +0100 (CET) Date: Fri, 8 Jan 2016 09:55:31 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160108085531.GB29486@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20160105200521.GA24317@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:55:41 -0000 On Tue, Jan 05, 2016 at 07:44:40PM -0800, Andy Bierman wrote: > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > e) Should the YANG protocol identities be managed by IANA? We likely > > do not want to touch the YANG library for the next protocol to come > > and it might be confusing to have some identities registered in the > > YANG library model itself but others in different places. I know, > > technically this is all fine if we manage to properly keep track of > > things. An IANA managed module with these identity registrations > > might make that keeping track part a bit easier since there is a > > single place for all the IETF protocols transporting YANG data and > > using the YANG library. The obvious alternative is to allocate the > > identities in the protocol definitions but then we should do this > > for restconf already now. (The downside with this approach is that > > this identity registration in protocol documents likely causes a > > normative dependency on YANG library, which is not nice; the IANA > > option works around that.) > > IMO, IANA has enough to do. This is just another YANG identity. > Vendors and other SDOs should not need to register identityrefs with IANA > to use their protocol with the YANG library. > The question was about how we organize the registration of protocol identities within the IETF. It does not matter how busy IANA is. If the direction is that it does not matter where these identities are defined, why do we define the RESTCONF identity here instead of the RESTCONF document (and thereby creating another dependency)? > > f) Should there be RFC editor instructions to replace the reference to > > draft-ietf-netconf-restconf in the restconf1.0 identity definition > > with the RESTCONF RFC number? (BTW, I personally prefer to have a > > hyphen between the protocol name and the version number, i.e., > > restconf-1.0 instead of restconf1.0.) > > IMO the current strings are OK, but I don't care if the WG wants to change > them > What about the suggested RFC editor instruction? Or can we get rid of the dependency altogether, see above? > > h) Turn the leaf-list feature into a list feature { key name; leaf > > name } so that the feature list can be augmented in the future if > > ever needed? > > > IMO this is overkill. Other tables can use a leafref to this leaf-list > instead > I am just asking to double check because I had to turn leaf-lists into lists in other contexts... > > i) Features can be defined in submodules, yet they are exposed in the > > YANG library as features of the enclosing module. Is this by > > intention? This should be technically OK but it is not a simple 1:1 > > mapping of the definitions and hence my question whether this is by > > intention. And if it is by intention, perhaps clarify that this > > list includes all module features independently from where they are > > defined. > > YANG features apply to the module. > Submodules do not partition the module namespace. > There can only be 1 "foo" feature in a the module and it doesn't matter > what submodule > contains it. All submodules must be included into the main module in YANG > 1.1 > Any include statements in a submodule get ignored in YANG 1.1. The > confusion remains > in the YANG statements, but it is clarified in the draft. OK. So this seems to be by intention. I think it might help implementors to indicate in the description statement that it does not matter whether the features are defined in the module or any included submodule, e.g. "List of YANG feature names from this module that are supported by the server, regardless whether they are defined in the module or any included submodule."; > > j) There are MUST statements concerning YANG 1.1 modules but there is > > not even a reference to YANG 1.1. I think a reference needs to be > > added to YANG 1.1 and it is likely a normative reference (which > > means YANG 1.1 and YANG Library have a circular dependency). > > > maybe these MUST statements should be moved to YANG 1.1 > Can you send a proposal what should be moved where to the NETMOD WG list so we can track this and resolve this? > > l) Is 'restricted-protocol' a good name for the leaf? It actually > > means 'not-supported-by-protocol' - is 'excluded-protocol' a better > > name? So essentially we have a set of modules and exceptions - if I > > have to add a protocol specific module, I need to add it to the > > global set and then setup proper exceptions. I assume the > > assumption here is that these are rare corner cases. Or should > > there also be the other alternative, an 'included-protocol' for > > adding things to the common set so both operations are available > > when needed? > > If a YANG protocol uses the library at all, it is listed in yang-protocol. > > If any module entry in the library does not apply to this protocol, > then the exception entry is needed in each unsupported module. > > > m) Does it make sense to discuss somewhere a bit what a server is? > > There will be servers that support multiple protocols but use a > > common backend server. There will also be deployments where > > different protocols do not use a common backend; in this case the > > protocol servers would report rather different instantiations of > > the YANG library. Should there be text discussing this? Should > > there be advice that a YANG library retrieved via protocol X should > > not be assumed to work with protocol Y unless the module-set-id has > > been verified via protocol Y? > > > > IMO so -- this draft defines a library, not a server. > > The module-set-id is an opaque string with no semantics at all. > > IMO there is no reason to discuss implementation details. > I think it is important to define the 'scope' of the content of the yang-library since the model allows to report information for different protocols. Hence, client implementors may assume that the yang library content received via protocol X also applies to protocol Y. This may be true for some deployments but not in general. The more I think about it, I tend to think that exposing information for multiple protocols including differences is not a good idea. While certain implementations use a common backend, this is just one out of many implementation and deployment options. While the current module may provide an efficiency gain for implementations with a common backend (which is IMHO minor), I think it is way cleaner from the client's perspective to simply get yang library content specific to the protocol used to access the yang library data model. > > n) Should yang-protocol be turned into a list instead of a leaf-list > > to allow future augmentations? > > no -- use a leafref to point to the leaf-list > See above. I am just double checking that we are sure we will never need additional information in place. > > o) Should we keep in mind that eventually modules are also configured > > into servers? That is, we are really defining the 'modules-state' > > tree and not the 'modules' tree (if we follow the foo and foo-state > > convention). [I expect to get grilled on this one.] > > > > > that is why module is defined in a grouping that can be used in a > config=true container > I expected a response like 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 nobody Fri Jan 8 01:38:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830521ACEF7 for ; Fri, 8 Jan 2016 01:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGq8K6GHiB19 for ; Fri, 8 Jan 2016 01:38:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD5E1A87DB for ; Fri, 8 Jan 2016 01:38:24 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E6DE1AE047A; Fri, 8 Jan 2016 10:38:23 +0100 (CET) Date: Fri, 08 Jan 2016 10:38:37 +0100 (CET) Message-Id: <20160108.103837.630719318619521198.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <69694EA3-8400-466F-BED9-134CAAAF99CC@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 09:38:26 -0000 Ladislav Lhotka wrote: > > > On 06 Jan 2016, at 20:49, Andy Bierman wrote: > > > > > > > > On Wed, Jan 6, 2016 at 11:34 AM, Ladislav Lhotka > > wrote: > > > > > On 06 Jan 2016, at 20:16, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka > > > wrote: > > > > > > > On 06 Jan 2016, at 19:52, Andy Bierman wrote: > > > > > > > > > > > > > > > > On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka > > > > wrote: > > > > > > > > > On 06 Jan 2016, at 19:16, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka > > > > > wrote: > > > > > Andy Bierman writes: > > > > > > > > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > > > >> Hi, > > > > > >> > > > > > >> here is my review of draft-ietf-netconf-yang-library-03. > > > > > >> > > > > > >> a) p2: What are "YANG-based data abstractions"? Do we need this new > > > > > >> term? Why not simply say "a server that implements YANG data > > > > > >> models"? > > > > > >> > > > > > > > > > > > > > > > > > > OK > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > >> b) p3: I think it follows from the first bullet that it is illegal > > > > > >> or > > > > > >> impossible to implement two different revisions of a certain > > > > > >> module > > > > > >> within a single server. > > > > > >> > > > > > > > > > > > > > > > > > > No -- this text should be clarified. > > > > > > It is meant to convey that the name "foo" cannot represent > > > > > > 2 different module names. It does not mean there can > > > > > > only be 1 entry in the module list for each module name. > > > > > > > > > > I don't understand: > > > > > > > > > > 1. Could there ever be two revisions of a module of the "implement" > > > > > type? > > > > > > > > > > > > > > > This is not explicitly prohibited in YANG 1.0 and we cannot > > > > > make any rules now for YANG 1.0, just YANG 1.1. > > > > > > > > YANG 1.0 has had no yang-libary so there are no backward compatibility > > > > concerns affecting this document. > > > > > > > > > > > > > > > > > > > > 2. If there are multiple revisions of a module of the "import" type, > > > > > then I think it breaks the main purpose of having such modules in > > > > > the > > > > > list - if such a module is imported without revision, how can a > > > > > client determine which revision the server actually uses? > > > > > > > > > > > > > > > > > > > > The most recent revision listed in the library is used for YANG 1.1. > > > > > > > > If module A imports C with revision YYYY-MM-DD, and B imports C > > > > without revision, then with this rule it wouldn't be possible for a > > > > server implementor to choose any revision less than YYYY-MM-DD to be > > > > used with B. I think this restriction isn't necessary. Listing module > > > > revisions that are imported always with revision is redundant. > > > > > > > > I would propose that no more that one revision of each module be > > > > listed in yang-library, and those of "import" type will be used > > > > exclusively for resolving imports without revision. > > > > > > > > > > > > > > > > The WG has already discussed this issue several times. > > > > The YANG library lists all the YANG modules being used. > > > > The client needs to be able to retrieve this list without > > > > needing to parse the modules to find this information. > > > > > > My position here is exactly the resolution accepted for Y45 (Y45-04), > > > and I think we should stick to it. > > > > > > > > > > > > > > > This has nothing to do with Y45. > > > > Come on, so what is Y45 about? 6020bis explicitly refers to > > yang-library draft, so there is a strong connection. > > > > > > Y45 does not have anything to say about how YANG modules should > > be retrieved for parsing. > > > > > > > > > The YANG library lists all the YANG modules. > > > That is what is operationally useful. > > > > How do you measure operational usefulness? All protocols could easily > > work even if modules imported with revision aren't listed. > > > > > > > > It is useful to get the list of modules and then retrieve them. > > This is much simpler than parsing YANG modules and retrieving > > them as import-stmts are parsed. Your implementation strategy > > requires the YANG compiler to be tightly coupled to the retrieval > > of YANG modules. > > This is an implementation detail. The problem I have with listing > imported modules multiple times is that it effectively annihilates the > idea of Y45-04, which is that "import" modules in yang-library are > used for resolving imports without revision. I agree with Lada. It is clear that Y45-04 - for which we have (rough?) consensus - does NOT "advertise" modules that are only imported by revision. However, I also agree w/ Andy that listing all modules is useful, b/c a client can easily get the complete, consistent, set of modules that the server implements. This said, we have in the past discussed two solutions to this problem. One is what you propose below, to indicate the default-revision with a new leaf, and the other is to make the latest advertised revision be the (implicit) default revision. I thought we agreed on the latter, but the current text makes this a SHOULD. So I think that either we make this a MUST (simpler), or add a new leaf (more flexible, and possibly more clear). > An alternative would be to add another flag to yang-library > ("default-revision"?) saying "this is the revision that is to be used > for imports without revision". /martin From nobody Fri Jan 8 02:00:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961451ACF55 for ; Fri, 8 Jan 2016 02:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6b24by0ysGb for ; Fri, 8 Jan 2016 02:00:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3811ACF24 for ; Fri, 8 Jan 2016 02:00:12 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665] (unknown [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665]) by mail.nic.cz (Postfix) with ESMTPSA id AAE161813EF; Fri, 8 Jan 2016 11:00:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452247210; bh=A6g7NO8Rgm8dTlX1n6FYLnwOueTKwtZd2MSyFxQfZU8=; h=From:Date:To; b=gaSBIY60iiclsp4uvQjCKSoKcHEc9MyJ0EbjjvFWscb7fzPFOJK7+yOKWcBOVDSat mxz85jRv+OEKSK59c8PMDewfbc8u1DyoXsY1l192LlXWg+kGAF+3e6ts9rgmYMNFXz mpn+rJeIBaYCg3JDDWDPxTcoenxAZsSxmtK1XKf0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160108.103837.630719318619521198.mbj@tail-f.com> Date: Fri, 8 Jan 2016 11:00:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69694EA3-8400-466F-BED9-134CAAAF99CC@nic.cz> <20160108.103837.630719318619521198.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:00:13 -0000 > On 08 Jan 2016, at 10:38, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 06 Jan 2016, at 20:49, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Wed, Jan 6, 2016 at 11:34 AM, Ladislav Lhotka >>> wrote: >>>=20 >>>> On 06 Jan 2016, at 20:16, Andy Bierman wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka >>>> wrote: >>>>=20 >>>>> On 06 Jan 2016, at 19:52, Andy Bierman wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka >>>>> wrote: >>>>>=20 >>>>>> On 06 Jan 2016, at 19:16, Andy Bierman = wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Jan 5, 2016 at 11:39 PM, Ladislav Lhotka >>>>>> wrote: >>>>>> Andy Bierman writes: >>>>>>=20 >>>>>>> On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < >>>>>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> here is my review of draft-ietf-netconf-yang-library-03. >>>>>>>>=20 >>>>>>>> a) p2: What are "YANG-based data abstractions"? Do we need this = new >>>>>>>> term? Why not simply say "a server that implements YANG data >>>>>>>> models"? >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> OK >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> b) p3: I think it follows from the first bullet that it is = illegal >>>>>>>> or >>>>>>>> impossible to implement two different revisions of a certain >>>>>>>> module >>>>>>>> within a single server. >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> No -- this text should be clarified. >>>>>>> It is meant to convey that the name "foo" cannot represent >>>>>>> 2 different module names. It does not mean there can >>>>>>> only be 1 entry in the module list for each module name. >>>>>>=20 >>>>>> I don't understand: >>>>>>=20 >>>>>> 1. Could there ever be two revisions of a module of the = "implement" >>>>>> type? >>>>>>=20 >>>>>>=20 >>>>>> This is not explicitly prohibited in YANG 1.0 and we cannot >>>>>> make any rules now for YANG 1.0, just YANG 1.1. >>>>>=20 >>>>> YANG 1.0 has had no yang-libary so there are no backward = compatibility >>>>> concerns affecting this document. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 2. If there are multiple revisions of a module of the "import" = type, >>>>>> then I think it breaks the main purpose of having such modules = in >>>>>> the >>>>>> list - if such a module is imported without revision, how can a >>>>>> client determine which revision the server actually uses? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The most recent revision listed in the library is used for YANG = 1.1. >>>>>=20 >>>>> If module A imports C with revision YYYY-MM-DD, and B imports C >>>>> without revision, then with this rule it wouldn't be possible for = a >>>>> server implementor to choose any revision less than YYYY-MM-DD to = be >>>>> used with B. I think this restriction isn't necessary. Listing = module >>>>> revisions that are imported always with revision is redundant. >>>>>=20 >>>>> I would propose that no more that one revision of each module be >>>>> listed in yang-library, and those of "import" type will be used >>>>> exclusively for resolving imports without revision. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The WG has already discussed this issue several times. >>>>> The YANG library lists all the YANG modules being used. >>>>> The client needs to be able to retrieve this list without >>>>> needing to parse the modules to find this information. >>>>=20 >>>> My position here is exactly the resolution accepted for Y45 = (Y45-04), >>>> and I think we should stick to it. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> This has nothing to do with Y45. >>>=20 >>> Come on, so what is Y45 about? 6020bis explicitly refers to >>> yang-library draft, so there is a strong connection. >>>=20 >>>=20 >>> Y45 does not have anything to say about how YANG modules should >>> be retrieved for parsing. >>>=20 >>>=20 >>>=20 >>>> The YANG library lists all the YANG modules. >>>> That is what is operationally useful. >>>=20 >>> How do you measure operational usefulness? All protocols could = easily >>> work even if modules imported with revision aren't listed. >>>=20 >>>=20 >>>=20 >>> It is useful to get the list of modules and then retrieve them. >>> This is much simpler than parsing YANG modules and retrieving >>> them as import-stmts are parsed. Your implementation strategy >>> requires the YANG compiler to be tightly coupled to the retrieval >>> of YANG modules. >>=20 >> This is an implementation detail. The problem I have with listing >> imported modules multiple times is that it effectively annihilates = the >> idea of Y45-04, which is that "import" modules in yang-library are >> used for resolving imports without revision. >=20 > I agree with Lada. It is clear that Y45-04 - for which we have > (rough?) consensus - does NOT "advertise" modules that are only > imported by revision. >=20 > However, I also agree w/ Andy that listing all modules is useful, b/c > a client can easily get the complete, consistent, set of modules that > the server implements. Yes, I agree. >=20 > This said, we have in the past discussed two solutions to this > problem. One is what you propose below, to indicate the > default-revision with a new leaf, and the other is to make the latest > advertised revision be the (implicit) default revision. Consider this situation: module A imports B without revision, so an = implementor chooses rev. X of B. Then later module C needs to be added, = but it imports B with revision Y > X. If revision Y appears in = yang-library, then it forces module A to be upgraded to use revision Y, = too. This may IMO be a problem.=20 >=20 > I thought we agreed on the latter, but the current text makes this a > SHOULD. So I think that either we make this a MUST (simpler), or add > a new leaf (more flexible, and possibly more clear). I'd prefer the latter. Lada >=20 >> An alternative would be to add another flag to yang-library >> ("default-revision"?) saying "this is the revision that is to be used >> for imports without revision". >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 02:06:24 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC41AD01E for ; Fri, 8 Jan 2016 02:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uceXK9jCea-t for ; Fri, 8 Jan 2016 02:06:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 462EB1ACF5E for ; Fri, 8 Jan 2016 02:06:20 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id E728A1AE047A; Fri, 8 Jan 2016 11:06:18 +0100 (CET) Date: Fri, 08 Jan 2016 11:06:33 +0100 (CET) Message-Id: <20160108.110633.1793241211777947336.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160108085531.GB29486@elstar.local> References: <20160105200521.GA24317@elstar.local> <20160108085531.GB29486@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:06:22 -0000 Juergen Schoenwaelder wrote: > On Tue, Jan 05, 2016 at 07:44:40PM -0800, Andy Bierman wrote: > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > e) Should the YANG protocol identities be managed by IANA? We likely > > > do not want to touch the YANG library for the next protocol to come > > > and it might be confusing to have some identities registered in the > > > YANG library model itself but others in different places. I know, > > > technically this is all fine if we manage to properly keep track of > > > things. An IANA managed module with these identity registrations > > > might make that keeping track part a bit easier since there is a > > > single place for all the IETF protocols transporting YANG data and > > > using the YANG library. The obvious alternative is to allocate the > > > identities in the protocol definitions but then we should do this > > > for restconf already now. (The downside with this approach is that > > > this identity registration in protocol documents likely causes a > > > normative dependency on YANG library, which is not nice; the IANA > > > option works around that.) > > > > IMO, IANA has enough to do. This is just another YANG identity. > > Vendors and other SDOs should not need to register identityrefs with IANA > > to use their protocol with the YANG library. > > > > The question was about how we organize the registration of protocol > identities within the IETF. It does not matter how busy IANA is. If > the direction is that it does not matter where these identities are > defined, why do we define the RESTCONF identity here instead of the > RESTCONF document (and thereby creating another dependency)? I think the idea was to define a new module, let's say iana-yang-protocols (in this document), which defines the identities "yang-protocol", "netconf-1.0", "netconf-1.1", and "restconf-1.0". This IANA policy would be "RFC Required" or maybe "Standards Action", so vendors and other SDOs would NOT ask IANA to add to the registry. The purpose of this registry would be to have a single definition for IETF-defined YANG protocols. Juergen, did I get this right? > > > f) Should there be RFC editor instructions to replace the reference to > > > draft-ietf-netconf-restconf in the restconf1.0 identity definition > > > with the RESTCONF RFC number? (BTW, I personally prefer to have a > > > hyphen between the protocol name and the version number, i.e., > > > restconf-1.0 instead of restconf1.0.) > > > > IMO the current strings are OK, but I don't care if the WG wants to change > > them I prefer the hyphened version; "netconf-1.1" etc. > What about the suggested RFC editor instruction? Or can we get rid of > the dependency altogether, see above? We would just move the dependency to another module, defined in the same document. So the RFC editor instruction should be added in either case. > > > h) Turn the leaf-list feature into a list feature { key name; leaf > > > name } so that the feature list can be augmented in the future if > > > ever needed? > > > > > IMO this is overkill. Other tables can use a leafref to this leaf-list > > instead > > > > I am just asking to double check because I had to turn leaf-lists into > lists in other contexts... > > > > i) Features can be defined in submodules, yet they are exposed in the > > > YANG library as features of the enclosing module. Is this by > > > intention? This should be technically OK but it is not a simple 1:1 > > > mapping of the definitions and hence my question whether this is by > > > intention. And if it is by intention, perhaps clarify that this > > > list includes all module features independently from where they are > > > defined. > > > > YANG features apply to the module. > > Submodules do not partition the module namespace. > > There can only be 1 "foo" feature in a the module and it doesn't matter > > what submodule > > contains it. All submodules must be included into the main module in YANG > > 1.1 > > Any include statements in a submodule get ignored in YANG 1.1. The > > confusion remains > > in the YANG statements, but it is clarified in the draft. > > OK. So this seems to be by intention. I think it might help > implementors to indicate in the description statement that it does not > matter whether the features are defined in the module or any included > submodule, e.g. > > "List of YANG feature names from this module that are > supported by the server, regardless whether they are > defined in the module or any included submodule."; > > > > j) There are MUST statements concerning YANG 1.1 modules but there is > > > not even a reference to YANG 1.1. I think a reference needs to be > > > added to YANG 1.1 and it is likely a normative reference (which > > > means YANG 1.1 and YANG Library have a circular dependency). > > > > > maybe these MUST statements should be moved to YANG 1.1 > > > > Can you send a proposal what should be moved where to the NETMOD WG > list so we can track this and resolve this? There are two MUST statements in yang library related to YANG 1.1. The first one is: For YANG 1.1 modules, there MUST NOT be more than one module entry with conformance 'implement' for a particular module name. This one is not necessary, since 6020bis says: A server MUST NOT implement more than one revision of a module. The second one is: For YANG 1.1 modules that use the import statement without specifying a revision date, the implemented revision of the imported module MUST be used. If the imported module is not implemented, then the most recent revision of the imported module used by the server (and contained in the module list) MUST be used. The fate of this paragraph depends on whether we add a 'defualt-revision' leaf or not. > > > l) Is 'restricted-protocol' a good name for the leaf? It actually > > > means 'not-supported-by-protocol' - is 'excluded-protocol' a better > > > name? So essentially we have a set of modules and exceptions - if I > > > have to add a protocol specific module, I need to add it to the > > > global set and then setup proper exceptions. I assume the > > > assumption here is that these are rare corner cases. Or should > > > there also be the other alternative, an 'included-protocol' for > > > adding things to the common set so both operations are available > > > when needed? > > > > If a YANG protocol uses the library at all, it is listed in yang-protocol. > > > > If any module entry in the library does not apply to this protocol, > > then the exception entry is needed in each unsupported module. > > > > > m) Does it make sense to discuss somewhere a bit what a server is? > > > There will be servers that support multiple protocols but use a > > > common backend server. There will also be deployments where > > > different protocols do not use a common backend; in this case the > > > protocol servers would report rather different instantiations of > > > the YANG library. Should there be text discussing this? Should > > > there be advice that a YANG library retrieved via protocol X should > > > not be assumed to work with protocol Y unless the module-set-id has > > > been verified via protocol Y? > > > > > > > IMO so -- this draft defines a library, not a server. > > > > The module-set-id is an opaque string with no semantics at all. > > > > IMO there is no reason to discuss implementation details. > > > > I think it is important to define the 'scope' of the content of the > yang-library since the model allows to report information for > different protocols. Hence, client implementors may assume that the > yang library content received via protocol X also applies to protocol > Y. This may be true for some deployments but not in general. The more > I think about it, I tend to think that exposing information for > multiple protocols including differences is not a good idea. While > certain implementations use a common backend, this is just one out of > many implementation and deployment options. While the current module > may provide an efficiency gain for implementations with a common > backend (which is IMHO minor), I think it is way cleaner from the > client's perspective to simply get yang library content specific to > the protocol used to access the yang library data model. I don't have a strong opinion, but I do agree that it is easier for the client to not have to do any filtering in order to figure out which modules applies to the protocol in use. Also, I don't think it is a big deal for a multi-protocol server to have multiple instantiations of this list. > > > o) Should we keep in mind that eventually modules are also configured > > > into servers? That is, we are really defining the 'modules-state' > > > tree and not the 'modules' tree (if we follow the foo and foo-state > > > convention). [I expect to get grilled on this one.] > > > > > > > > that is why module is defined in a grouping that can be used in a > > config=true container > > > > I expected a response like this. ;-) It is even explicitly stated in the description of the grouping. /martin From nobody Fri Jan 8 02:35:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ACD1AD09C for ; Fri, 8 Jan 2016 02:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYLUqA78E-s1 for ; Fri, 8 Jan 2016 02:35:11 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6320E1AD094 for ; Fri, 8 Jan 2016 02:35:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2D71072D; Fri, 8 Jan 2016 11:35:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wPbMgReEjSEj; Fri, 8 Jan 2016 11:35:08 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Jan 2016 11:35:08 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4DE720056; Fri, 8 Jan 2016 11:35:08 +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 mJjF1tfpfjRd; Fri, 8 Jan 2016 11:35:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28CC320055; Fri, 8 Jan 2016 11:35:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DC8B6397DC0C; Fri, 8 Jan 2016 11:35:05 +0100 (CET) Date: Fri, 8 Jan 2016 11:35:05 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160108103505.GA29774@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <20160105200521.GA24317@elstar.local> <20160108085531.GB29486@elstar.local> <20160108.110633.1793241211777947336.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160108.110633.1793241211777947336.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:35:13 -0000 On Fri, Jan 08, 2016 at 11:06:33AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 05, 2016 at 07:44:40PM -0800, Andy Bierman wrote: > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > e) Should the YANG protocol identities be managed by IANA? We likely > > > > do not want to touch the YANG library for the next protocol to come > > > > and it might be confusing to have some identities registered in the > > > > YANG library model itself but others in different places. I know, > > > > technically this is all fine if we manage to properly keep track of > > > > things. An IANA managed module with these identity registrations > > > > might make that keeping track part a bit easier since there is a > > > > single place for all the IETF protocols transporting YANG data and > > > > using the YANG library. The obvious alternative is to allocate the > > > > identities in the protocol definitions but then we should do this > > > > for restconf already now. (The downside with this approach is that > > > > this identity registration in protocol documents likely causes a > > > > normative dependency on YANG library, which is not nice; the IANA > > > > option works around that.) > > > > > > IMO, IANA has enough to do. This is just another YANG identity. > > > Vendors and other SDOs should not need to register identityrefs with IANA > > > to use their protocol with the YANG library. > > > > > > > The question was about how we organize the registration of protocol > > identities within the IETF. It does not matter how busy IANA is. If > > the direction is that it does not matter where these identities are > > defined, why do we define the RESTCONF identity here instead of the > > RESTCONF document (and thereby creating another dependency)? > > I think the idea was to define a new module, let's say > iana-yang-protocols (in this document), which defines the identities > "yang-protocol", "netconf-1.0", "netconf-1.1", and "restconf-1.0". > > This IANA policy would be "RFC Required" or maybe "Standards Action", > so vendors and other SDOs would NOT ask IANA to add to the registry. > > The purpose of this registry would be to have a single definition for > IETF-defined YANG protocols. > > Juergen, did I get this right? Yes. Andy seems to think this is overkill (this is how I read his IANA is to busy claim). My take is that an IANA module is a clean way of achieving a loose coupling - even if it is some effort to set it up. > > > > o) Should we keep in mind that eventually modules are also configured > > > > into servers? That is, we are really defining the 'modules-state' > > > > tree and not the 'modules' tree (if we follow the foo and foo-state > > > > convention). [I expect to get grilled on this one.] > > > > > > > > > > > that is why module is defined in a grouping that can be used in a > > > config=true container > > > > > > > I expected a response like this. ;-) > > It is even explicitly stated in the description of the grouping. > The question really was not about the grouping but more whether /modules should be /modules-state but yeah I expected that people won't get excited about such a proposal... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 8 03:12:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9221AD0B2 for ; Fri, 8 Jan 2016 03:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lzSoff567rm for ; Fri, 8 Jan 2016 03:12:25 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7C51AD0AD for ; Fri, 8 Jan 2016 03:12:25 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 50DEF1AE047A; Fri, 8 Jan 2016 12:12:23 +0100 (CET) Date: Fri, 08 Jan 2016 12:12:38 +0100 (CET) Message-Id: <20160108.121238.2214876153143901798.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF and confirmed-commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 11:12:27 -0000 Hi, Andy Bierman wrote: > Hi, > > Sec. 1.3 in RESTCONF-09 does not mention confirmed-commit at all. > I just finished implementing confirmed-commit for RESTCONF > and some details should be mentioned in this section. > > 1) persist-id > > A normal NETCONF commit will fail if a confirmed-commit is running > with a 'persist-id' lock, and the session does not provide the correct > value. > Since standard RESTCONF has no way of passing a 'persist-id' > parameter to the edit or commit, any RESTCONF edit must fail > if this parameter is expected by the server. > > If no 'persist-id' is expected, then the RESTCONF edit will > be processed by the server, and it will act as the confirming commit. This seems pretty scary at first sight, but consistent with NETCONF. If the NETCONF client want's to avoid that someone else performs the confirming commit, it should grab a lock. > 2) shared candidate > > This section does not mention that any edits in the candidate at > the time of the RESTCONF edit will also be part of the commit. Ok. > I propose that new text be added to sec. 1.3 similar to the text above. Ok. An alternative to both these could be to reject any RESTCONF request with 409 if (1) there is an ongoing confirmed commit, or (2) the candidate contains uncommitted changes. /martin From nobody Fri Jan 8 03:21:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818451AD0D3 for ; Fri, 8 Jan 2016 03:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEuaOJsdDL3B for ; Fri, 8 Jan 2016 03:21:57 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD1D1ACDBD for ; Fri, 8 Jan 2016 03:21:57 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 4AAEC1AE047A; Fri, 8 Jan 2016 12:21:56 +0100 (CET) Date: Fri, 08 Jan 2016 12:22:11 +0100 (CET) Message-Id: <20160108.122211.286894587579856645.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160108103505.GA29774@elstar.local> References: <20160108085531.GB29486@elstar.local> <20160108.110633.1793241211777947336.mbj@tail-f.com> <20160108103505.GA29774@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 11:21:58 -0000 Juergen Schoenwaelder wrote: > On Fri, Jan 08, 2016 at 11:06:33AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Jan 05, 2016 at 07:44:40PM -0800, Andy Bierman wrote: > > > > On Tue, Jan 5, 2016 at 12:05 PM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > e) Should the YANG protocol identities be managed by IANA? We likely > > > > > do not want to touch the YANG library for the next protocol to come > > > > > and it might be confusing to have some identities registered in the > > > > > YANG library model itself but others in different places. I know, > > > > > technically this is all fine if we manage to properly keep track of > > > > > things. An IANA managed module with these identity registrations > > > > > might make that keeping track part a bit easier since there is a > > > > > single place for all the IETF protocols transporting YANG data and > > > > > using the YANG library. The obvious alternative is to allocate the > > > > > identities in the protocol definitions but then we should do this > > > > > for restconf already now. (The downside with this approach is that > > > > > this identity registration in protocol documents likely causes a > > > > > normative dependency on YANG library, which is not nice; the IANA > > > > > option works around that.) > > > > > > > > IMO, IANA has enough to do. This is just another YANG identity. > > > > Vendors and other SDOs should not need to register identityrefs with IANA > > > > to use their protocol with the YANG library. > > > > > > > > > > The question was about how we organize the registration of protocol > > > identities within the IETF. It does not matter how busy IANA is. If > > > the direction is that it does not matter where these identities are > > > defined, why do we define the RESTCONF identity here instead of the > > > RESTCONF document (and thereby creating another dependency)? > > > > I think the idea was to define a new module, let's say > > iana-yang-protocols (in this document), which defines the identities > > "yang-protocol", "netconf-1.0", "netconf-1.1", and "restconf-1.0". > > > > This IANA policy would be "RFC Required" or maybe "Standards Action", > > so vendors and other SDOs would NOT ask IANA to add to the registry. > > > > The purpose of this registry would be to have a single definition for > > IETF-defined YANG protocols. > > > > Juergen, did I get this right? > > Yes. Andy seems to think this is overkill (this is how I read his IANA > is to busy claim). My take is that an IANA module is a clean way of > achieving a loose coupling - even if it is some effort to set it up. I agree with you, but I can also see that this might be an issue if this pattern is common, which it seems to be. If all modules that want to provide extensibility via identities also define an IANA module, it might be problem. The nice thing w/ identities is that a central registry isn't needed. In this particular case, the "issue" is that there is no natural place to put "netconf-1.0" and "netconf-1.1". But then, if we agree to let each protocol have it's own instatiation of /modules, the entire problem goes away. > > > > > o) Should we keep in mind that eventually modules are also configured > > > > > into servers? That is, we are really defining the 'modules-state' > > > > > tree and not the 'modules' tree (if we follow the foo and foo-state > > > > > convention). [I expect to get grilled on this one.] > > > > > > > > > > > > > > that is why module is defined in a grouping that can be used in a > > > > config=true container > > > > > > > > > > I expected a response like this. ;-) > > > > It is even explicitly stated in the description of the grouping. > > > > The question really was not about the grouping but more whether > /modules should be /modules-state but yeah I expected that people > won't get excited about such a proposal... Aha, ok. I don't have a strong opinion on this one. /martin From nobody Fri Jan 8 06:39:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682E51A8A03 for ; Fri, 8 Jan 2016 06:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUSgn5c9ugLg for ; Fri, 8 Jan 2016 06:39:55 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50311A89FD for ; Fri, 8 Jan 2016 06:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TxeemfOSi6ItrvRLVZ++I0r9c83Ke8bTx2STnhvCWBo=; b=ZoBrg8Orm+LMCXwBCnSL44kXziGC93b6QyeLLr8EbPtZGgE4yOlZ6GFI8x8TXFFR3aWmHaHdoFtMs+cSpendpHmEv4yT0qJsLIQycL8zPOYF32flCsvg+ndUUNCAc44/vKavrK21GtaAW+5ZtSu9DKCVGc86/zbX+1xe66OeyGE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 8 Jan 2016 14:39:36 +0000 Message-ID: <004101d14a22$0c14faa0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , References: <20151228144238.6667.34139.idtracker@ietfa.amsl.com> Date: Fri, 8 Jan 2016 14:36:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0001.eurprd02.prod.outlook.com (25.163.180.11) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB057; 2:/yBQsYyErWJ/ZZLBVLpms3kkR9/p8Xkzb+e7JtR3Gx8UdAYoOvpU4GpswNGALx5TJStFdb1xAB2uEe4AHu0GZQoEZD/XiS1C/zLmj3AwvbQwuXJ4FvPvkGrq4Pnzocwhze3VE/bJPCqOkoH8U/PQYA==; 3:GiTMpI3o0JfVmjKTrtuuEsfwyEInlufbiUiDDxM6ppzSGAfnDklCdiy+Lb3zUffsX4297H+aW558QnK+M6krHecGGuUGyIWXe22T4Rw4s/V/tzaEWrqWghGlpIGWufX9; 25:o6xomdH6y/6N3J5+rUhY9SgVDKAoRLXB7Gw8LCrcUmeVcvajS0p3RwWfW2KVp5rWTqwBv7lA3Gacze3wxU6B4STZ4mWNh4OYYxZaRp4s5rD/WdzWyK82QOvh/aYPl5LA4FOTDFyVoRbximM4jPgyGkeGgGOh5xn/GMb+pEzqe1amF35eH4yTSQlLLSFmdnmHQ3R/PIsOTsrA82iooyel7uAvAZHWrhpWGPTApdc8D/2qEDgSx+S2Jt3v8JmejE2j X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-MS-Office365-Filtering-Correlation-Id: c73b847f-d7e5-403a-da5a-08d318398808 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:DB3PR07MB057; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB057; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB057; 4:XKOIVg/CbQtTI0Z+A/+lVbNtQHybzqTRr0xXcPL7eu5t3OBsb3RvkbxEJyRf/mOu04Yx2CdM49wIWbTqNuu09nD4zlBjz7PpbvVzpbbhgK2UUhhqkVfdINH0xUH5sEb3H0DX6uifXXEZQfK/5p5NIGpEM8Eojp/p4KEl0r7saCSGWz7lkqkyEOJwm0DSK+tLxISryIEQUgZXToRpnAyYjd3hmSew4yunxfGv+5FRSyE36HcKM4mazGk496Qw7elraSV+EHtsfw4KRhR09G/OPqRyoxY1bGuI7yki9TX4iYNVcns1Qe52GcaDR4wS+8nyiJgTvImaLh76ISexEDU/8zToQ6cSL0cVA2yVL4AdCTmq3B2CJyBxOM2Cx1GVnRp4NVC02Zs0dg050ieQavKCgCYYje16lQ57Nk98UEBvb8GSWnbz00y/WjYvpv616OvY X-Forefront-PRVS: 0815F8251E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(478694002)(199003)(24454002)(13464003)(479174004)(101416001)(40100003)(50986999)(5008740100001)(97736004)(230783001)(122386002)(5001960100002)(23676002)(47776003)(50226001)(92566002)(106356001)(1941001)(2906002)(61296003)(84392002)(44736004)(1556002)(19580405001)(189998001)(62236002)(44716002)(86362001)(76176999)(33646002)(14496001)(81686999)(19580395003)(81816999)(1096002)(42186005)(105586002)(3846002)(6116002)(107886002)(93886004)(5001770100001)(66066001)(1456003)(77096005)(586003)(15975445007)(50466002)(81156007)(561944003)(87976001)(116806002)(5004730100002)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNTc7MjM6Q2lwRjY2NjVoTHRMUytZaXVYbkpkY0U2eTRD?= =?utf-8?B?ODRuaTUvQnhrbWhIdlpqcDJyaFBmdUN2ZS9RY2xrMDNzdm85T2dtc2dJYm9o?= =?utf-8?B?SkxlbHNEdXNHTlpQYUQza2NZcStrSjRYSjROK3N4Y3NRZXVjbWFnbGdZWnFG?= =?utf-8?B?cFY3c2xjVjdHQStDMmZtbVlRQjd3b1dLT1R1dG1vVmRsdUVvbWtsTU5IR0V3?= =?utf-8?B?RFphQ2taU0F0YUZNTEM2OVEvcldXRDQ1UEk1SExhYzh3NDUyZlp3OGF5R3dL?= =?utf-8?B?TUxNUlNhSk5NaEJOLzdjVGczd0tSNWcyaTMwUVNzdENnY3B6dkJTUzVRdkpP?= =?utf-8?B?SDVEV0lnRFpMSXo5NUNhVE1CQ3VXMDl0RUJjTkQvNDQrTk5JYzlseUVzZm5r?= =?utf-8?B?YlV5eiswSFdPdUgwYVlOZGlPdzdMdFB4WWJhYkNiK29vMlhRTmg4VnJHelNN?= =?utf-8?B?NEY0ZFhadVdlZ2w0clpGcXpVNjdEYkpwU2JTY1FyamplQUx1a1g4Yzgzc3lE?= =?utf-8?B?WVVQTUs5aVJ2ZlM5UlEyM1c0T0Rndkd4OUd3TCthYmR6eWhKUkRnUm1WOENn?= =?utf-8?B?Ty9XYUZRTVZhRFVldndtYWhob1JHSWJEbDl6OVlGUU5KaHpoaXJzU2FXYWVn?= =?utf-8?B?eWxWSkt5c2tvWHZQY2ZUalkvbkhxRzA1L2w4ZnZtUlFtUFZhWUVoWi9qd3NB?= =?utf-8?B?bHNZcXpXeGFQZHhqSDRad2tkTnFhRmpUNFFCUVluOFQvMVNVOEZnSjdmL21r?= =?utf-8?B?ZnN6UDFkTHlLQXM4L0R6RnY3cWhDdlJGR1lDUWlSTFBXOXdtTHFna0pMcGFR?= =?utf-8?B?ZHJOTTYxNHBaWVBzVURrYTRnblhaOTZHTGduNjNhRWxvMlEyVjUyZG84N2ph?= =?utf-8?B?dE1DeUJPZmtLWU9mYXB0dzNHNDdkMyt5SWRPUHBHOWdjVEJTejk3RkVoZm1t?= =?utf-8?B?Wi9EdHJLMDFCMzFNU21EUkFSbmlsVFozOERNTVBkVlcrRjBOdmdzR0huZ2Nu?= =?utf-8?B?RC9ObDVTMDc2WmJvb0xGV3EycHRGMW1pMks0NG9seVJpdjgvL0txYlhrT2RD?= =?utf-8?B?TmhQcUJha1BrbWJaN1k4L2VIU1dialRQQmFiYm43TDBzbGdIWHAwaTl2akVX?= =?utf-8?B?eUxTYVN5c2JUKytMdy8xKytpNCtZeUcwSEoyY3NFOXhVRmovcE9OcGV1dmlX?= =?utf-8?B?aldhQW5VSDRNc2FObUVNSGsvS0xUWFBuODFuSXpNMDJqRDVEYk9WR2toQzEv?= =?utf-8?B?S1Jhby9GNHQ4Qk9SYjlEZ3Vzd1UyUFVCR0U1MWI1Z1A5U2ZxK1hUV1lYOVU4?= =?utf-8?B?YVBzK3d2a3lTbEdqZGZaS1V1VldZQzJacTl4LytRTmRxT1lXSWRTOUQ4VVFw?= =?utf-8?B?NHIxTkJsOWwyVEUrZkQweXJjcGlNbW95Z3A5dzAzWHBIcFRVdE5DL3luRWtP?= =?utf-8?B?d000Wkk1ZXhybGQ4elJrcTIrejFpTll4eVpGVmlLODdsZFRsTFBMdkxCUGFM?= =?utf-8?B?eE5DaWF5VU1EdXNQN2pDeU1SSEZxZnJpOXZ1anBuNW0yOTlzQWpxNDFzY3JY?= =?utf-8?B?cmFZV1ZjNHZ0VXQ4YmV4MVNEMG1tYURVNkRiUGppWS9vY1dOaE90aG9oTUJo?= =?utf-8?B?OVVsRFd0RlJkT0JLZkFTaHgvVWVZUWg1SmltdWlwajJaamVjamVBQlAxbWhU?= =?utf-8?B?ZzlKNEk1VVlWcWhrd0VTOVJESVNZY01sZ1VpVXRsbzdOQ0QzUDNyYjIybTRz?= =?utf-8?B?VXQyTHkvT0JRRUVuSysyYlNxWkNiSjFtb0NuSlJtb3pXRXlqWkFrbzlmdTZk?= =?utf-8?B?RHdsa2Q5RmVuRkxDTTNZVHg1dlhPVWczRGtUVHJPWTNHb2dwVU9QRkxVVGNk?= =?utf-8?B?a3g4TTZLRllLRGk4aVBVaXRQQzlZY1VGQVV1VFU1SFRvMjRFNjYxTXZMTUMy?= =?utf-8?B?TnE4MDZVbnN3d1FkY3BpMU0zMFZSaG9DN01iWDF3UHI5SmU4a1FUZWthd2Zq?= =?utf-8?B?bnBHVlpuMGJ3QXFQVmt1ZHJteEFNNGdPVzVBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB057; 5:le2wWckQstts1O0cQ9m5naMTaYtM0PbxNCM+xaNpVpXEMQDmEJp9jpHIPkkIyyBT+eMSLaeUNDblvl7iyzaRKDYKD82Cb95/28HOzV/UhfOoUHM75X6bPEC/ZkZujGjiRPI1PAqTgJOt7qtQA4y5Ug==; 24:KVcargnDHPFRJqQQbOsD4NvHovqNWHUkNGzua7q/Y2zkM8cbTKKyk4m9GDlYmq8mrR4ZPCfAY6x0UWuXWwdAK7c+hU7e+PavuaMizrXoN2Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2016 14:39:36.1671 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057 Archived-At: Subject: Re: [Netconf] FW: [IANA #886439] Protocol Action: 'NETCONF Call Home and RESTCONF Call Home' to Proposed Standard (draft-ietf-netconf-call-home-17.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 14:39:57 -0000 ----- Original Message ----- From: "Kent Watsen" To: Sent: Thursday, January 07, 2016 8:22 PM > Any thoughts on this? - I can’t think of a reason to disagree with the proposal... Nor me. But I do get curious. These numbers fall into a crack in the current sequence so I wonder why the crack is there. And I look for a way to make the new numbers relate to the current NETCONF ones, like a 1000 or 2000 greater, but that does not fit either. So yes, looks ok (but I will still wonder why:-) Tom Petch > > Kent > > > > > On 1/7/16, 3:12 PM, "Amanda Baber via RT" wrote: > > >Dear Authors, > > > >Before we assign port numbers for this document, we'd like to make sure you're OK with the proposed values. Would 4334, 4335, and 4336 be acceptable? > > > >thanks, > > > >Amanda Baber > >IANA Senior Specialist > >ICANN > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Jan 8 11:10:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6CB1B2B20 for ; Fri, 8 Jan 2016 11:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkj3UsZS8kaM for ; Fri, 8 Jan 2016 11:10:26 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6D91AC39E for ; Fri, 8 Jan 2016 11:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2382; q=dns/txt; s=iport; t=1452280225; x=1453489825; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=jTWHykdzegX7KgwyZZLj0jaegjSrG4zrCib6Ev6zF+g=; b=Z1LQTIHFHCnax8v1ZhGBX3C9iyuA134yXFxLuNbZ0OAnteD4dJZnJjfQ 81R5gXTH2ap+0d9jYjqqSmpbzssZd0KvEH5flKF4Rh4C5KAhXfVueXmVO frKHB0dpg9F0Bx6/TAMy1Fo24i0b4eB6ByMH7gNma3/hwr60S0uqfkH2c o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgCVCJBW/5FdJa1egzpSiUazSAENg?= =?us-ascii?q?WSHLzgUAQEBAQEBAX8LhF4VQDYCBRYLAgsDAgECAUsNCAEBiCuhXY9vkCkBAQE?= =?us-ascii?q?HAgEggQGFVYR/hD6DNYFJBYdZhlc9iCCBD4xJgVyHSiOFMopbg3MgAQFChCggh?= =?us-ascii?q?hUBAQE?= X-IronPort-AV: E=Sophos;i="5.20,540,1444694400"; d="scan'208";a="225511728" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2016 19:10:24 +0000 Received: from [10.150.55.111] (dhcp-10-150-55-111.cisco.com [10.150.55.111]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u08JAOcG028126 for ; Fri, 8 Jan 2016 19:10:25 GMT To: "netconf@ietf.org" From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <569009A0.7010402@cisco.com> Date: Fri, 8 Jan 2016 14:10:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] Review of draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 19:10:32 -0000 I wanted to give a review of my read-through of draft-ietf-netconf-restconf-09. In general, I found no major issues, but the number of forward references was a bit distracting. Below are my specific comments. Section 2.1: It is stated that RESTCONF requires a secure transport layer. It does not, however, explicitly state RESTCONF can or cannot be run over "http". My assumption is, "no," but should this explicitly be stated? Section 3.7: You provide an example of how to retrieve schema. In the schema fetch case, you specify the HTTP headers the client might send, but you do not specify the headers the server will respond with. This is out of sync with your other examples, and here I think the headers are important as it shows the content type. Sections 4.X: Where it talks about authorization, it states that the server can either reply with 403 or 404. I personally don't like this. There is no guidance as to which to use where, and I think 403 should be used universally if there is an access issue. It confuses a developer and could ultimately confuse an end-user if a 404 Not Found is returned for a a given target resource when it does, in fact, exist. At the very least, I think some guidance should be offered about when to use which error code. Section 4.8.9: I think the description for "explicit" is wrong here. If you look further down the draft, the correct description is seen, which jives with the NETCONF definition. OLD TEXT: Data nodes set by the client are not reported NEW TEXT: Data nodes set to the YANG default by the client are reported Section 5.1: Nit: Add a leading '/' for ".well-known" OLD TEXT: entry: the root of the RESTCONF API configured on this HTTP server, discovered by getting the ".well-known/host-meta" resource, as described in Section 3.1. NEW TEXT: entry: the root of the RESTCONF API configured on this HTTP server, discovered by getting the "/.well-known/host-meta" resource, as described in Section 3.1. Section 7: Error code 404 is not mapped to anything, so going back to my comments about 403/404 above should we be suggesting one returns 404 for access denied? Based on this, I think not. I also assume 404 is not used for thinks like unknown-element as the NETCONF error-info for this points to bad-element? Joe From nobody Fri Jan 8 18:44:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC501A00FE for ; Fri, 8 Jan 2016 18:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qkvg77U9iRd for ; Fri, 8 Jan 2016 18:44:39 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2024C1A00E9 for ; Fri, 8 Jan 2016 18:44:39 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id d17so21259195lfb.1 for ; Fri, 08 Jan 2016 18:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l3hE0Q1wjOl8MIp1sPOVkFUwfB3jhxM5Cd9zDZiZISk=; b=sC8unilqy3oIExcmlpHBelkXt8loCaeZoX6v592169syqsJC5pmwyAcw1VefiHtKBT TQ+SeGmUtnejtxIjZeL7hhw1Dp0EtDK4W1vtilk8clZt74WHFZzFEyICydESLP9RkSFm lkjPXRVeXCPRXgWE2JziNqLk2AGP/48iXLpxaJM34qYTwTnhcs6KbrrpzMv/LdgDNKld +p/B6ROXePX5OXQP8Z34inoZMuO3IXPWGjyiicsS9SVA5dLge+c776/qUZnFDsLm2OUK dSYNP/7IK6TX7KnAfr70ZlizULXoLionOQGKqYIt3UPY/P08SM0xzbqlKatgBhRfFLLP eTzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l3hE0Q1wjOl8MIp1sPOVkFUwfB3jhxM5Cd9zDZiZISk=; b=iFedUgFhW1ww87kT29LeidzmzvWowGlGaFAYIj/UeSxYKl8ECrSOYY2p7jJkMsNJJa i4tVgLeHNoSt5JqlNuDzEZS4ZTpPI2Ms9bJHfxtDzNvoW+QWQdJkVr4vf/GECzC2YpVh dMidECr96on/wPPi8MN17DrGEJ6TGD4uLxfvyBP8szyjCzYty+9nUH+qts99cBlE3Swl fK+r5O5ERMZy66nGPfvWiDQLsxtTe+TOhs1aAN75owI8W9yjYSLTv0NAmfR7jv36xlZk y0pMWZjhFjcnGVdxmoyl7XEU32YayRTdBm5mKgvT3Hi9kvd+rM5fRy+2C+qG6WBU2KEP 4egw== X-Gm-Message-State: ALoCoQkEyb6dvkRot4xM8Z6xo8wxTl9qMX6a5M/Ins0kUN0AnYV6wfh2Yq+alSK8IlXbC/hsXk1rO+ZhjUsYcYLDLbIi1tAg0g== MIME-Version: 1.0 X-Received: by 10.25.218.9 with SMTP id r9mr42477335lfg.138.1452307477393; Fri, 08 Jan 2016 18:44:37 -0800 (PST) Received: by 10.112.144.36 with HTTP; Fri, 8 Jan 2016 18:44:37 -0800 (PST) In-Reply-To: <20160108.121238.2214876153143901798.mbj@tail-f.com> References: <20160108.121238.2214876153143901798.mbj@tail-f.com> Date: Fri, 8 Jan 2016 18:44:37 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114026004b8b320528ddaf12 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF and confirmed-commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 02:44:41 -0000 --001a114026004b8b320528ddaf12 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 3:12 AM, Martin Bjorklund wrote: > Hi, > > > Andy Bierman wrote: > > Hi, > > > > Sec. 1.3 in RESTCONF-09 does not mention confirmed-commit at all. > > I just finished implementing confirmed-commit for RESTCONF > > and some details should be mentioned in this section. > > > > 1) persist-id > > > > A normal NETCONF commit will fail if a confirmed-commit is running > > with a 'persist-id' lock, and the session does not provide the correct > > value. > > Since standard RESTCONF has no way of passing a 'persist-id' > > parameter to the edit or commit, any RESTCONF edit must fail > > if this parameter is expected by the server. > > > > If no 'persist-id' is expected, then the RESTCONF edit will > > be processed by the server, and it will act as the confirming commit. > > This seems pretty scary at first sight, but consistent with NETCONF. > If the NETCONF client want's to avoid that someone else performs the > confirming commit, it should grab a lock. > > Actually, it was quite straight-forward to implement the confirmed, confirm-timeout, persist, and persist-id query parameters. We implemented full access to all RPCs (XML anyway) even though some ietf-netconf operations don't really work because a RESTCONF "session" is 1 request. But "commit" and "cancel-commit" work fine. The RESTCONF client MUST provide a "persist" parameter, or else the server will cancel the confirmed-commit when the initiating session terminates (after this 1 request). IMO the entire NETCONF locking and shared candidate design needs to be tossed in the dumpster and replaced with a concurrent transaction model, but that is another topic, out of scope for now. > > 2) shared candidate > > > > This section does not mention that any edits in the candidate at > > the time of the RESTCONF edit will also be part of the commit. > > Ok. > > > I propose that new text be added to sec. 1.3 similar to the text above. > > Ok. > > An alternative to both these could be to reject any RESTCONF request > with 409 if (1) there is an ongoing confirmed commit, or (2) the > candidate contains uncommitted changes. > I thought of that but IMO being consistent with NETCONF would be better. We may update NETCONF someday, and then we can decide how to fix this (perhaps with private candidates). > > > /martin > Andy --001a114026004b8b320528ddaf12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 8, 2016 at 3:12 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Hi,


Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> Sec. 1.3 in RESTCONF-09 does not mention confirmed-commit at all.
> I just finished implementing confirmed-commit for RESTCONF
> and some details should be mentioned in this section.
>
> 1) persist-id
>
> A normal NETCONF commit will fail if a confirmed-commit is running
> with a 'persist-id' lock, and the session does not provide the= correct
> value.
> Since standard RESTCONF has no way of passing a 'persist-id' > parameter to the edit or commit, any RESTCONF edit must fail
> if this parameter is expected by the server.
>
> If no 'persist-id' is expected, then the RESTCONF edit will > be processed by the server, and it will act as the confirming commit.<= br>
This seems pretty scary at first sight, but consistent with NETCONF.
If the NETCONF client want's to avoid that someone else performs the confirming commit, it should grab a lock.








=C2=A0
> 2) shared candidate
>
> This section does not mention that any edits in the candidate at
> the time of the RESTCONF edit will also be part of the commit.

Ok.

> I propose that new text be added to sec. 1.3 similar to the text above= .

Ok.

An alternative to both these could be to reject any RESTCONF request
with 409 if (1) there is an ongoing confirmed commit, or (2) the
candidate contains uncommitted changes.




/martin

Andy<= /div>

--001a114026004b8b320528ddaf12-- From nobody Sun Jan 10 05:40:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019F91ACD41 for ; Sun, 10 Jan 2016 05:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92fPVrh5bttD for ; Sun, 10 Jan 2016 05:40:26 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC3F1ACD3F for ; Sun, 10 Jan 2016 05:40:25 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id 4DgM1s00A3vXPcr01DgNzy; Sun, 10 Jan 2016 14:40:23 +0100 To: Netconf From: "Bert Wijnen (IETF)" Message-ID: <56925F45.1090709@bwijnen.net> Date: Sun, 10 Jan 2016 14:40:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] my review of draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 13:40:28 -0000 Basically I think this document is ready. Questions/concerns: - section 4.3: The server MUST NOT return any data resources for which the user does not have read privileges. If the user is not authorized to read the target resource, an error response containing a "403 Forbidden" or "404 Not Found" status-line is returned to the client. So is it an implementation decision as to which of these 2 errors is returned? Same question to a few more occurrences later in the document. - section 6.1 s/not required/NOT REQUIRED/ ?? Not 100% sure, but to me it seems this defines compliance, and so upper case probably applies? NITS: - in section 1.3 (page 7), you use {+restconf} before it is actually defined you may want to add a reference to section 3.3 where it is defined and explained? - page 10: media type "text/event-stream", as defined by the HTML5 you might want to add a reference to HTML5 - page 34, 2nd para: Plain patch can used to create or update, but not delete, a child s/can used/can be used/ I guess - last para in section 5.3 If is not specified, the request input encoding format is used. s/If is/is/ I guess for my own records (no worries): - Maybe I do not understand, But, section 3.6.3 has: -33 Going down for system maintenance en-US Whereas at the bottom of page 23, delay is defined as an uint32, so how can you pass a negative 33 value? Ah... I see, it is to show that an error gets returned. peace. I have not reviewed the examples in the appendices. Bert From nobody Mon Jan 11 02:35:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6020A1A88E2 for ; Mon, 11 Jan 2016 02:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHubIznA7eXE for ; Mon, 11 Jan 2016 02:35:37 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CEA651A88D7 for ; Mon, 11 Jan 2016 02:35:36 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 196521CC0230 for ; Mon, 11 Jan 2016 11:35:39 +0100 (CET) From: Ladislav Lhotka To: Netconf User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 11 Jan 2016 11:35:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Netconf] LL review of restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 10:35:39 -0000 Hi, I have read the document and my comments are below. Overall, I think the document is in a good shape, and I support its publication. My company is working on an open-source implementation. Lada *** General comments - RESTCONF separates the specification of the target node (in Request-URI) from new data (in the message body). This allows for a more flexible handling of lists and their entries, but I am not sure whether the following operations are permitted: 1. DELETE an entire list by specifying it as the target resource; 2. GET all list entries; 3. create multiple list entries in one operation; 4. change a list key (e.g. via PATCH), for example: PATCH /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: b8389233a4c Content-Type: application/yang.data+xml Something Else *** Specific comments **** Sec. 1 - s/operational data/state data/ (also in several other places in the text). - JSON reference should be RFC 7159, 7158 is obsoleted by it. **** Sec. 1.2 - HATEOAS acronym should be expanded at the first occurence **** Sec. 3.3.1 - shouldn't the example have as the document element? **** Sec. 3.5 - first paragraph: leaf-list entries aren't data resources? And shouldn't it in fact be "Every instance of a container, ..."? **** Sec. 3.5.1 - 6th bullet: how can a key be missing? **** Sec. 3.6 - last two paragraphs: what does "successfully invoked" mean? **** Sec. 3.7 - It is a bit weird that the response has date "25 Apr 2012", but the returned revision is "2015-06-04". **** Sec. 4 - table: POST also corresponds to invoking an operation **** Sec. 4.4.1 - second paragraph: s/YANG definition/"ietf-restconf" module/ **** Sec. 4.5 - What happens if the list key specified in the Request-URI isn't the same as the key specified in the message body? **** Sec. 4.8.1 - I don't understand what the default is: does "requested data nodes" mean the target resource? I would expect "all" to be the default. **** Sec. 4.8.2 - I don't understand how "depth" interacts with "fields": if "album" is the target resource, what is returned with "depth=1&fields=genre;year"? **** Sec. 4.8.3 - Is this legal: "fields=jukebox(library/artist;playlist)/name"? **** Sec. 5.3 (also in 7.1) - "Response output content encoding format is identified with the Accept header in the request. If is not specified, the request input encoding format is used." This deviates from the semantics of HTTP Accept header. RFC 7231: "A request without any Accept header field implies that the user agent will accept any media type in response." **** Sec. 6.4 - example-mod should have "prefix" statement *** Typos etc. - sec. 2.5, last paragraph: s/For when/When/ - sec. 4: The table is numbered (Table 1), other tables in the document aren't - the titles of sections 4.8.7-9 contain non-breaking hyphen (U+2011) which is not rendered in the table of contents -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 04:52:24 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119671A8A04 for ; Mon, 11 Jan 2016 04:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xr52jcSFf87F for ; Mon, 11 Jan 2016 04:52:22 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD761A8A07 for ; Mon, 11 Jan 2016 04:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6882; q=dns/txt; s=iport; t=1452516742; x=1453726342; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=oG3xtJqk6N4pXRFAoPtOa134wTpStkfJjqJTgR8webs=; b=eOMF+diMyF/QzS1kfaOmdNlUJIcsfNqyyyjAez4rvZfVRnEehCG2oBOQ gsTaJ41glr6c6GtDXKiJc2pvDXepJ1bTBwURBdxIiczvyF9A6HIaug2+g WeCBZ8v8U9bxtaxKovA0F6gOZCnXKV7nXtcqmg3qRSlv9OBcePFmp2Ank g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBACApJNW/xbLJq1egm6BHm2IWaNYk?= =?us-ascii?q?XqGDwKBbgEBAQEBAYELhDQBAQEEIwRSEBwDAQIKIQICDwI8AggGDQYCAQGIFQM?= =?us-ascii?q?SrmuPfgEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVoR/gk+BbwI3gnyBSQWTEIQDi?= =?us-ascii?q?2KBd4Feh0qFVYZyg2yDc2SECz00AYRdgUoBAQE?= X-IronPort-AV: E=Sophos;i="5.20,552,1444694400"; d="scan'208,217";a="624419866" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 12:52:20 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0BCqJ9N008036; Mon, 11 Jan 2016 12:52:19 GMT References: To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: Message-ID: <5693A582.70207@cisco.com> Date: Mon, 11 Jan 2016 13:52:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040905090002070408090804" Archived-At: Cc: zhang_dacheng@hotmail.com Subject: [Netconf] Fwd: Secdir review of draft-ietf-netconf-yang-patch-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 12:52:24 -0000 This is a multi-part message in MIME format. --------------040905090002070408090804 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: Secdir review of draft-ietf-netconf-yang-patch-07 Resent-Date: Mon, 11 Jan 2016 04:14:44 -0800 Resent-From: zhang_dacheng@hotmail.com Resent-To: draft-ietf-netconf-yang-patch.all@ietf.org Date: Mon, 11 Jan 2016 20:14:16 +0800 From: Dacheng To: secdir@ietf.org CC: draft-ietf-netconf-yang-patch.all@tools.ietf.org I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a media type for a YANG-based editing mechanism that can be used with the HTTP PATCH method. I agree that this mechanism does not introduce any new security issues, beyond what is described in [I-D.ietf-netconf-restconf]. So, this draft is almost ready for publication. A question: In Section 2.6 you mentioned 'The server will save the running datastore to non-volatile storage' . Do you assume the severs supporting your mechanism always have non-volatile storage? An editorial comment: page 15: The 'value' node will contain one instance of foo:-> The 'value' node contains one instance of foo: Cheers Dacheng --------------040905090002070408090804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: Secdir review of draft-ietf-netconf-yang-patch-07
Resent-Date: Mon, 11 Jan 2016 04:14:44 -0800
Resent-From: zhang_dacheng@hotmail.com
Resent-To: draft-ietf-netconf-yang-patch.all@ietf.org
Date: Mon, 11 Jan 2016 20:14:16 +0800
From: Dacheng <zhang_dacheng@hotmail.com>
To: secdir@ietf.org
CC: draft-ietf-netconf-yang-patch.all@tools.ietf.org


I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines a media type for a YANG-based editing mechanism that can be used with the HTTP PATCH method.

I agree that this mechanism does not introduce any new security issues, beyond what is described in [I-D.ietf-netconf-restconf]. So, this draft is almost ready for publication. 

A question:

In Section 2.6  you mentioned 'The server will save the running datastore to non-volatile storage' . Do you assume the severs supporting your mechanism always have non-volatile storage?

An editorial comment:
page 15:
The 'value' node will contain one instance of foo:-> The 'value' node contains one instance of foo:

Cheers

Dacheng


--------------040905090002070408090804-- From nobody Mon Jan 11 11:59:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB9D1A90B6 for ; Mon, 11 Jan 2016 11:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK0STn69MI5p for ; Mon, 11 Jan 2016 11:59:26 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F0B1A90BA for ; Mon, 11 Jan 2016 11:59:26 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id c192so220941061lfe.2 for ; Mon, 11 Jan 2016 11:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=ePCG24rMirQ5+0cqAWbESjaMMLGtq+8Jx+qvUe9B4y4=; b=kICEsHpI04NOeAwDxSwx2HcLC00VgbbhA1ywyYBV3y0hdgxqgjMTBBkIHle+tKNQwj /JbGoHeKeezHYiSGLxOCNTei2eaG8ETsQSO1RZ6X8NQ1ItcI/jNIzWf4o2N8zPX/WGFK vuEdb/gmjoNeg3E+lbzDyNrFjO+kjk48kWSVZb5kyzf0fEVvR7APwTCRQj8BnIKJaG6Z eqFQM69+yM7zF+Pg5mioaHaBRS3g3eMK2HbFJ0Mv7QUjzY4e+94dethZwss3NAYzDLqk LXjsZoTRiaKR/41YXxMGNzPZyCY9iyeXO7yIsHOEJaL1/gZmQ6zCQAtogvadUMuLpphu 2EeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ePCG24rMirQ5+0cqAWbESjaMMLGtq+8Jx+qvUe9B4y4=; b=LbgGEJV0oxQSRTCr5VfdbkhkF25JnY9BKU+FLs+m24XcJ3pb5CKmusHqz7TRkMU8t2 RQjQ+B5vHI3RLmouwpc8JKzqqbtVcW3pXvw5QWvaQW0FmsEufB6LNYeuKlgRfTk716qg kGphSKPf4zuBW55PQ0yGIWn95BBOLq4Fhi/5dpC9rpREyVWBrNqwf2IxjCz9dirV7vJC CRL1Yy7tqaeb4MfaOToYO8Ten3zPrEW2be3DV6JkTxoEugxhjePWh+bDoA/bGHUmtHNT K2vFQq3eWjMB9yWu7dg/PfFfGnAmwaWEl+qUfB1MJc3HasoEGljqMujsmtHiQliSH98d aStA== X-Gm-Message-State: ALoCoQm+i9qf6hAJpghzzJw78d3YeolJ6iKBlNXffSzb4qQXQAob2Audcy49f3BQBp4bVOSeybV1AVwaJ4CSG/wXjPoLMfpFMw== MIME-Version: 1.0 X-Received: by 10.25.64.9 with SMTP id n9mr47136118lfa.13.1452542364721; Mon, 11 Jan 2016 11:59:24 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 11 Jan 2016 11:59:24 -0800 (PST) Date: Mon, 11 Jan 2016 11:59:24 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a113ea4f6abd01f0529145f2f Archived-At: Subject: [Netconf] RESTCONF fields-expr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:59:28 -0000 --001a113ea4f6abd01f0529145f2f Content-Type: text/plain; charset=UTF-8 Hi, I think the fields-expr is too complicated and provides too many ways to do the same thing. fields-expr = path '(' fields-expr ')' / path ';' fields-expr / path path = api-identifier [ '/' path ] fields=foo/bar is exactly the same as fields=foo(bar) I propose the following syntax change: OLD: path = api-identifier [ '/' path ] NEW: path = api-identifier Andy --001a113ea4f6abd01f0529145f2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think the fields-expr is too comp= licated and
provides too many ways to do the same thing.


=C2=A0 =C2=A0fields-expr =3D path '= ;(' fields-expr ')' /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path ';' fields-expr /
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path
= =C2=A0 =C2=A0path =3D api-identifier [ '/' path ]
<= br>


=C2=A0 =C2=A0fields=3Dfoo/bar i= s exactly the same as fields=3Dfoo(bar)

I propose = the following syntax change:

OLD:

=C2=A0path =3D api-identifier [ '/' path ]


NEW:

=C2=A0 pa= th =3D api-identifier


Andy


--001a113ea4f6abd01f0529145f2f-- From nobody Mon Jan 11 14:30:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D171A19F2 for ; Mon, 11 Jan 2016 14:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knRn9rA3IptX for ; Mon, 11 Jan 2016 14:30:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C721A0A85 for ; Mon, 11 Jan 2016 14:30:43 -0800 (PST) Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 22:30:26 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.195]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.19]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 22:30:26 +0000 From: Rodney Cummings To: "netconf@ietf.org" Thread-Topic: Review of draft-ietf-netconf-restconf-09 Thread-Index: AdFMuDXVo1vckLhER9GDOWpeWO8MUw== Date: Mon, 11 Jan 2016 22:30:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.33] x-microsoft-exchange-diagnostics: 1; BN1PR04MB424; 5:H182A9DcVz6eIXkJ+9M/67wiFqOX1I4h2d0UZ67KqMh1c9DvWuFLKB/Q7Tc7oTrZ0fq38Pi48AbwPIHezGDrkhxy/27PX14IYe7bK9WNdO/Ep++atR3OHVsa1zUMqWUDU7elykV+3qtgr27U65fg8Q==; 24:JYJQpUCTVwg4cfZHv2+QNuVfMKy3gk5x1o1YMNTDXdgPJEkM6i98UEt6YOqkeedTBu4U4Ipty67wSbir4TjUUS7Nf/l9EyQwLv6PAEDs8AA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB424; x-ms-office365-filtering-correlation-id: 544f585d-7dee-46f0-8c34-08d31ad6cdce x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BN1PR04MB424; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB424; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(450100001)(5003600100002)(92566002)(1730700002)(87936001)(3846002)(11100500001)(1096002)(2351001)(122556002)(86362001)(76576001)(6116002)(5001960100002)(1220700001)(189998001)(110136002)(5008740100001)(40100003)(81156007)(54356999)(586003)(99286002)(102836003)(50986999)(101416001)(107886002)(106356001)(2501003)(105586002)(97736004)(229853001)(5004730100002)(10400500002)(74316001)(230783001)(5002640100001)(2906002)(33656002)(2900100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB424; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 22:30:26.6313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB424 Archived-At: Subject: [Netconf] Review of draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 22:30:46 -0000 Hello, I have read and reviewed the restconf-09 document and my comments are below= . I have no major objections to the content, and I support its publication.= My affiliated company has definitive plans for a JSON-only server implemen= tation in the future, and we are considering a client implementation. Questions/concerns: --- - Section 3.4.1.1: This section has "SHOULD maintain last-modified timestam= ps for descendant resources", and section 3.5 (data resource) has "the serv= er MAY maintain a last-modified timestamp for the resource". I assume that = a descendant resource is a data resource, so the MAY/SHOULD are somewhat co= ntradictory. One solution would be to remove the conformance requirement fo= r descendants from 3.4.1.1, and change 3.5 to a SHOULD. The same issue appl= ies to entity tag. - Section 3.7: Since support for YANG module retrieval is optional, should = we provide a capability for it? - Section 4.8.1: This has "The default value is determined by the "config" = statement value of the requested data nodes." What if the requested data no= de is a container with a mixture of "config false" leafs and "config true" = leafs? It seems like this could be replaced with "The default value is "all= "." - Sections 4.8.4 and 4.8.5: What if my server only supports modules that us= e the default ordering exclusively (system order)? If so, mandating "insert= " and "point" is cumbersome. I tend to think that these should be grouped i= nto a capability like other query parameters. If there is concern about thi= s, we could state that "If the server implements a module with data nodes t= hat specify user ordering, then the server MUST support this capability." Typos/nits: --- - Section 3, last paragraph: The first sentence states "The RESTCONF protoc= ol does not include a resource discovery mechanism.", but the next section = 3.1 specifies a resource discovery mechanism for the root. I know what you = mean (i.e. RESTCONF doesn't discover YANG data nodes), but this threw me a = bit when I first read it. For clarity I think you could remove this sentenc= e, and the "Instead, " of the following sentence, and merge that that sente= nce into the preceding paragraph. - Section 3.5.1: Change "If there are multiple key leaf values, the value o= f each leaf" to "If there are multiple key leaf values, the path segment is= constructed by having the list name followed by an "=3D" followed by the l= eaf values. The value of each leaf". In other words, clarify that the "=3D"= applies for both. - Section 3.7: This has "The server can optionally support retrieval of the= YANG modules it supports, using the "ietf-yang-library" module, defined in= [I-D.ietf-netconf-yang-library]. To retrieve a YANG module, a client first= needs to get the URL for retrieving the schema." On first read this sounds= like ietf-yang-library is optional (which it isn't, Section 10). Another w= ording: "The server can optionally support retrieval of the YANG modules it= supports. To retrieve a YANG module, a client first needs to get the URL f= or retrieving the schema using the "ietf-yang-library" module (Section 10).= " - Section 4: In "The PATCH method is equivalent to a "merge" operation when= using a plain patch (see Section 4.6.1), other media-types may provide mor= e granular control.", replace the comma with a semicolon. - Section 4.4.1: In "The data-model for the child tree is the subtree is de= fined by YANG for the child resource.", replace the 2nd "is" with "as". - Section 4.4.1: This has "The "insert" and "point" query parameters are su= pported by the POST method for datastore and data resource types, as specif= ied in the YANG definition in Section 8.". The reference to Section 8 seems= out of place. Should this be phrased like section 4.5 (PUT), with "The "in= sert" (Section 4.8.4) and "point" (Section 4.8.5) query parameters are supp= orted by the POST method for for datastore and data resource types."? - Section 5.3: In "If there was no request input, then the default output e= ncoding is XML or JSON, depending or server preference.", replace the 2nd "= or" with "on". Rodney From nobody Mon Jan 11 17:52:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B01ACD09 for ; Mon, 11 Jan 2016 17:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.891 X-Spam-Level: X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2RD57doIByw for ; Mon, 11 Jan 2016 17:52:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E57A1ACD04 for ; Mon, 11 Jan 2016 17:52:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCU19206; Tue, 12 Jan 2016 01:52:21 +0000 (GMT) Received: from SZXEMI411-HUB.china.huawei.com (10.86.210.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 01:52:20 +0000 Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.48]) by szxemi411-hub.china.huawei.com ([10.86.210.34]) with mapi id 14.03.0235.001; Tue, 12 Jan 2016 09:52:15 +0800 From: "fengchong (C)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF fields-expr Thread-Index: AQHRTKqbam1E+k4/okOE/hNjzRN9qZ73FZ3g Date: Tue, 12 Jan 2016 01:52:15 +0000 Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D0833386@SZXEMI506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/related; boundary="_004_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56945C56.00A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.48, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 580bba1537a6254512f562f8acd36c1b Archived-At: Subject: [Netconf] =?utf-8?b?562U5aSNOiAgUkVTVENPTkYgZmllbGRzLWV4cHI=?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 01:52:29 -0000 --_004_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_ Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_" --_000_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KV2h5IG5vdCB1c2UgOg0KDQogICBmaWVsZHMtZXhwciA9IOKAmCjigJgoZmllbGQt ZXhwcinigJkp4oCZLw0KICAgICAgICAgICAgICAgICAgICDigJgo4oCYKihmaWVsZC1leHBy4oCZ O+KAmSlmaWVsZC1leHBy4oCZKeKAmQ0KICAgICBmaWVsZC1leHByID0gcGF0aCAvDQogICAgICAg ICAgICAgICAgICBwYXRo4oCZL+KAmWZpZWxkcy1leHByDQogICAgIHBhdGggPSBhcGktaWRlbnRp ZmllciBbICcvJyBwYXRoIF0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K 5Yav5YayDQrljY7kuLrmioDmnK/mnInpmZDlhazlj7ggSHVhd2VpIFRlY2hub2xvZ2llcyBDby4s IEx0ZC4NCltDb21wYW55X2xvZ29dDQoNClBob25lOg0KRmF4Og0KTW9iaWxlOiAxODUxOTExNzMx Ng0KRW1haWw6IGZyYW5rLmZlbmdjaG9uZ0BodWF3ZWkuY29tDQrlnLDlnYDvvJrljZfkuqzluILo va/ku7blpKfpgZMxMDHlj7fljY7kuLrljZfkuqzln7rlnLAg6YKu57yW77yaMjEwMDAxDQpIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQrmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInl jY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDl nYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoENCuatouS7u+S9leWFtuS7luS6uuS7 peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWc sOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4rQ0K55qE5L+h5oGv44CC 5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu2 6YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBDQpUaGlzIGUtbWFpbCBhbmQgaXRz IGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJ LCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2Ug YWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0 b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRp b24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRl IGl0IQ0K5Y+R5Lu25Lq6OiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn XSDku6PooaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMTblubQx5pyIMTLml6UgMzo1 OQ0K5pS25Lu25Lq6OiBOZXRjb25mDQrkuLvpopg6IFtOZXRjb25mXSBSRVNUQ09ORiBmaWVsZHMt ZXhwcg0KDQpIaSwNCg0KSSB0aGluayB0aGUgZmllbGRzLWV4cHIgaXMgdG9vIGNvbXBsaWNhdGVk IGFuZA0KcHJvdmlkZXMgdG9vIG1hbnkgd2F5cyB0byBkbyB0aGUgc2FtZSB0aGluZy4NCg0KDQog ICBmaWVsZHMtZXhwciA9IHBhdGggJygnIGZpZWxkcy1leHByICcpJyAvDQogICAgICAgICAgICAg ICAgIHBhdGggJzsnIGZpZWxkcy1leHByIC8NCiAgICAgICAgICAgICAgICAgcGF0aA0KICAgcGF0 aCA9IGFwaS1pZGVudGlmaWVyIFsgJy8nIHBhdGggXQ0KDQoNCg0KICAgZmllbGRzPWZvby9iYXIg aXMgZXhhY3RseSB0aGUgc2FtZSBhcyBmaWVsZHM9Zm9vKGJhcikNCg0KSSBwcm9wb3NlIHRoZSBm b2xsb3dpbmcgc3ludGF4IGNoYW5nZToNCg0KT0xEOg0KDQogcGF0aCA9IGFwaS1pZGVudGlmaWVy IFsgJy8nIHBhdGggXQ0KDQoNCk5FVzoNCg0KICBwYXRoID0gYXBpLWlkZW50aWZpZXINCg0KDQpB bmR5DQoNCg0K --_000_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L 5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk65Y2O5paH57uG6buROw0KCXBhbm9zZS0xOjIgMSA2IDAgNCAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDljY7mlofnu4bpu5EiOw0KCXBhbm9zZS0xOjIg MSA2IDAgNCAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjIwNTAi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i WkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+V2h5IG5vdCB1c2UgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtmaWVsZHMtZXhwciA9IOKAmCjigJgoZmllbGQt ZXhwcinigJkp4oCZLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCYKOKAmCooZmllbGQtZXhwcuKAmTvigJkpZmllbGQtZXhw cuKAmSnigJk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZpZWxkLWV4cHIgPSBwYXRo IC88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBh dGjigJkv4oCZZmllbGRzLWV4cHI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhdGgg PSBhcGktaWRlbnRpZmllciBbICcvJyBwYXRoIF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9y OmJsYWNrIj7lhq/lhrI8c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPuWNjuS4uuaKgOac r+aciemZkOWFrOWPuDxzcGFuIGxhbmc9IkVOLVVTIj4gSHVhd2VpIFRlY2hub2xvZ2llcyBDby4s IEx0ZC48YnI+DQo8L3NwYW4+PC9zcGFuPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZXR5cGUg aWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiIG86c3B0PSI3NSIgbzpwcmVm ZXJyZWxhdGl2ZT0idCIgcGF0aD0ibUA0QDVsQDRAMTFAOUAxMUA5QDV4ZSIgZmlsbGVkPSJmIiBz dHJva2VkPSJmIj4NCjx2OnN0cm9rZSBqb2luc3R5bGU9Im1pdGVyIiAvPg0KPHY6Zm9ybXVsYXM+ DQo8djpmIGVxbj0iaWYgbGluZURyYXduIHBpeGVsTGluZVdpZHRoIDAiIC8+DQo8djpmIGVxbj0i c3VtIEAwIDEgMCIgLz4NCjx2OmYgZXFuPSJzdW0gMCAwIEAxIiAvPg0KPHY6ZiBlcW49InByb2Qg QDIgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxXaWR0aCIgLz4NCjx2OmYg ZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsSGVpZ2h0IiAvPg0KPHY6ZiBlcW49InN1bSBAMCAwIDEi IC8+DQo8djpmIGVxbj0icHJvZCBANiAxIDIiIC8+DQo8djpmIGVxbj0icHJvZCBANyAyMTYwMCBw aXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49InN1bSBAOCAyMTYwMCAwIiAvPg0KPHY6ZiBlcW49InBy b2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQiIC8+DQo8djpmIGVxbj0ic3VtIEAxMCAyMTYwMCAwIiAv Pg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBl b2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3QiIC8+DQo8bzpsb2NrIHY6ZXh0PSJlZGl0IiBhc3Bl Y3RyYXRpbz0idCIgLz4NCjwvdjpzaGFwZXR5cGU+PHY6c2hhcGUgaWQ9InJpZEltZyIgbzpzcGlk PSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBhbHQ9IkNvbXBhbnlfbG9nbyIgc3R5 bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDowO3dpZHRoOjc2 LjVwdDtoZWlnaHQ6MjRwdDt6LWluZGV4OjE7dmlzaWJpbGl0eTp2aXNpYmxlO21zby13cmFwLXN0 eWxlOnNxdWFyZTttc28td3JhcC1kaXN0YW5jZS1sZWZ0OjA7bXNvLXdyYXAtZGlzdGFuY2UtdG9w OjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6MDttc28td3JhcC1kaXN0YW5jZS1ib3R0b206MDtt c28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0O21zby1wb3NpdGlvbi1ob3Jpem9udGFsLXJlbGF0 aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2FsOmFic29sdXRlO21zby1wb3NpdGlvbi12ZXJ0 aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3ZlcmxhcD0iZiI+DQo8djppbWFnZWRhdGEgc3Jj PSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDE0RDFFLkU5QzQ5RkYwIiBvOmhyZWY9ImZpbGU6Ly8vQzpc VXNlcnNcZjAwMzYwMjE4XEFwcGxpY2F0aW9uJTIwRGF0YVxNaWNyb3NvZnRcU2lnbmF0dXJlc1xj b21wYW55X2xvZ28uanBnIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiIGFuY2hvcnk9ImxpbmUi Lz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48aW1nIHdpZHRoPSIxMDIiIGhl aWdodD0iMzIiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQxNEQxRS5FOUM0OUZGMCIgYWxpZ249 ImxlZnQiIGFsdD0iQ29tcGFueV9sb2dvIiB2OnNoYXBlcz0icmlkSW1nIj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWNjuaW h+e7hum7kTtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KUGhvbmU6IDxicj4NCkZheDogPGJyPg0K TW9iaWxlOiAxODUxOTExNzMxNjxicj4NCkVtYWlsOiBmcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNv bTxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrl jY7mlofnu4bpu5E7Y29sb3I6YmxhY2siPuWcsOWdgO+8muWNl+S6rOW4gui9r+S7tuWkp+mBkzxz cGFuIGxhbmc9IkVOLVVTIj4xMDE8L3NwYW4+5Y+35Y2O5Li65Y2X5Lqs5Z+65ZywIOmCrue8lu+8 mjxzcGFuIGxhbmc9IkVOLVVTIj4yMTAwMDE8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwg THRkLjxicj4NCjxicj4NCmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4gPG86cD4NCjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjxo ciBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij7mnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInl jY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDl nYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoE8c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KPC9zcGFuPuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaL rOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WP ke+8ieacrOmCruS7tuS4rTxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+55qE5L+h5oGv 44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu 5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBPHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KPGJyPg0KaXMgaW50ZW5k ZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQg YWJvdmUuIEFueSB1c2Ugb2YgdGhlDQo8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0 aWFsDQo8YnI+DQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5 IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgPGJyPg0KcmVjaXBpZW50KHMpIGlzIHBy b2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYnkNCjxicj4NCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBk ZWxldGUgaXQhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gTmV0Y29uZiBbbWFpbHRv Om5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5BbmR5IEJpZXJtYW48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4g MjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0i RU4tVVMiPjE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjEyPC9zcGFuPuaXpTxzcGFuIGxh bmc9IkVOLVVTIj4gMzo1OTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBOZXRjb25mPGJyPg0KPC9zcGFuPjxi PuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IFtOZXRjb25mXSBSRVNUQ09ORiBmaWVsZHMtZXhwcjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgdGhpbmsgdGhlIGZpZWxkcy1leHByIGlzIHRvbyBjb21wbGljYXRlZCBhbmQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+cHJvdmlkZXMgdG9vIG1hbnkgd2F5cyB0byBkbyB0aGUgc2FtZSB0aGlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2ZpZWxkcy1leHByID0g cGF0aCAnKCcgZmllbGRzLWV4cHIgJyknIC88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwYXRo ICc7JyBmaWVsZHMtZXhwciAvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF0aDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7cGF0aCA9IGFwaS1pZGVudGlmaWVyIFsgJy8nIHBh dGggXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDtmaWVsZHM9Zm9vL2JhciBpcyBleGFjdGx5IHRoZSBzYW1lIGFzIGZp ZWxkcz1mb28oYmFyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgc3ludGF4IGNoYW5nZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9MRDo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDtwYXRoID0gYXBp LWlkZW50aWZpZXIgWyAnLycgcGF0aCBdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg cGF0aCA9IGFwaS1pZGVudGlmaWVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_-- --_004_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Tue, 12 Jan 2016 01:52:15 GMT"; modification-date="Tue, 12 Jan 2016 01:52:15 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_5756FB984666AD4BB8E1D63E2E3AA3D0833386SZXEMI506MBSchina_-- From nobody Tue Jan 12 00:36:57 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9781A1EFD for ; Tue, 12 Jan 2016 00:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGJEYndNl92l for ; Tue, 12 Jan 2016 00:36:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4024E1A1EF5 for ; Tue, 12 Jan 2016 00:36:53 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894] (unknown [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894]) by mail.nic.cz (Postfix) with ESMTPSA id ABBB0181B8A; Tue, 12 Jan 2016 09:36:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452587811; bh=/fft54W3qCcXcz9ZeBK10K15OzEBhS4iAFdUoz0EmiE=; h=From:Date:To; b=tqdt49S48P7jZ775jCUBGrOZ6CdN+rRcImYwiJM7+NYii5KTEDBLQi/940OEGB70M NXntiPaehLdG8BixFo/xEjTnPnVmzL7hjjDkgawpRzYq88fp0EzbGxc7kp7M5MQGLc c9zGkNfobF7YJru/Q0M3OJM1TSmvE1mg65QakSzM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 12 Jan 2016 09:36:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93BCF9A0-5572-4C2A-BC3F-AEB11FCC6C53@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF fields-expr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 08:36:56 -0000 > On 11 Jan 2016, at 20:59, Andy Bierman wrote: >=20 > Hi, >=20 > I think the fields-expr is too complicated and > provides too many ways to do the same thing. I sort of agree, see the example in my review. Perhaps it would be = possible to use (a subset of) XPath in order to avoid introducing a new = query language, at the cost of some extra escaping. It was discussed = here: http://news.oreilly.com/2008/08/can-a-url-contain-an-xpath.html Lada >=20 >=20 > fields-expr =3D path '(' fields-expr ')' / > path ';' fields-expr / > path > path =3D api-identifier [ '/' path ] >=20 >=20 >=20 > fields=3Dfoo/bar is exactly the same as fields=3Dfoo(bar) >=20 > I propose the following syntax change: >=20 > OLD: >=20 > path =3D api-identifier [ '/' path ] >=20 >=20 > NEW: >=20 > path =3D api-identifier >=20 >=20 > Andy >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 00:44:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5E51A21AE for ; Tue, 12 Jan 2016 00:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpuxs9NyBv_n for ; Tue, 12 Jan 2016 00:44:29 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B0F491A21AB for ; Tue, 12 Jan 2016 00:44:29 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E9721AE049A; Tue, 12 Jan 2016 09:44:28 +0100 (CET) Date: Tue, 12 Jan 2016 09:44:30 +0100 (CET) Message-Id: <20160112.094430.433027909901683692.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <93BCF9A0-5572-4C2A-BC3F-AEB11FCC6C53@nic.cz> References: <93BCF9A0-5572-4C2A-BC3F-AEB11FCC6C53@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF fields-expr X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 08:44:31 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2016, at 20:59, Andy Bierman wrote: > > > > Hi, > > > > I think the fields-expr is too complicated and > > provides too many ways to do the same thing. > > I sort of agree, see the example in my review. The syntax is used in some google REST apis, see e.g. https://developers.google.com/custom-search/json-api/v1/performance#fields-syntax /martin From nobody Tue Jan 12 02:09:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499C81A6FF9 for ; Tue, 12 Jan 2016 02:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFaYvUQ--R_7 for ; Tue, 12 Jan 2016 02:08:59 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BB31A6FEF for ; Tue, 12 Jan 2016 02:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14222; q=dns/txt; s=iport; t=1452593338; x=1453802938; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=CUNClnz7fOZgEBVwCLSSEolmBIkkXOVM2Oa8EUo2jJQ=; b=D1iM0/b0E1WHChQ/GvUmq9GG306u1AjoSJ1B23OTIKVDOoPPrInjlZbv 2fsOJ5lPrlIJr64a8cj/o03lBmrwnQNOGE9SGtLZz8WlzOymu9Z8RZo1O AHPCdjJXmzPNhF1SnCxXGRVeNZnNLkXMTxTbvo6sHoWYaElSaCkZ13ya3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDXz5RW/xbLJq1egm6BHm2IWbMvA?= =?us-ascii?q?Q2BZoYPAoFbFAEBAQEBAQGBCoQ0AQEBBC1LARAcAwECChYPCQMCAQIBOwIIBg0?= =?us-ascii?q?GAgEBiCq/XwEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVoR/hBwiOYRGBYdmiyqDQ?= =?us-ascii?q?UKNWYFehEODB4VUimCDcyABAUKECz00AYRugUIBAQE?= X-IronPort-AV: E=Sophos;i="5.20,556,1444694400"; d="scan'208,217";a="648439877" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 10:08:56 +0000 Received: from [10.61.101.248] (dhcp-10-61-101-248.cisco.com [10.61.101.248]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0CA8uDs027367; Tue, 12 Jan 2016 10:08:56 GMT References: To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: Message-ID: <5694D0B7.9050004@cisco.com> Date: Tue, 12 Jan 2016 11:08:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000903070702010605070403" Archived-At: Cc: "Xialiang \(Frank\)" Subject: [Netconf] Fwd: Secdir review of draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:09:01 -0000 This is a multi-part message in MIME format. --------------000903070702010605070403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. The early security directorate review Regards, Benoit -------- Forwarded Message -------- Subject: Secdir review of draft-ietf-netconf-restconf-09 Date: Tue, 12 Jan 2016 08:27:53 +0000 From: Xialiang (Frank) To: draft-ietf-netconf-restconf.all@tools.ietf.org CC: Tobias Gondrom , iesg@ietf.org , secdir@ietf.org Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The document appears in reasonably good shape. In general, the RESTCONF is an application protocol layered on the HTTP protocol. As mentioned in the document, just using the HTTPS (with TLS) can address most of the security issues such as confidentiality, integrity, etc. In other words, RESTCONF is designed inherently based on a good security foundation. But there are still several security issues (TBDs) missing in the document that need to be addressed before publication. Below is a series of my comments, questions for your consideration. Discussion: Section 2 Since this section is all about the security requirements to the RESTCONF transport protocol, is it appropriate to combine it into the security consideration section directly? Questions: Section 4.3 What is the error handling if GET method is used to retrieve the operational resources? Section 4.5 What is the error handing if PUT method does not include the message body? Generally, the similar problems like the above two appear several times in the document, please double check them. Comments: Section 12 In the security considerations section, there are still some serious security issues not mentioned: 1. DDoS attack: One RESTCONF client is possible to communicate with a lot of RESTCONF servers, which potentially leads to the situation of DDoS attack to itself or its link. How to avoid or mitigate it? 2. Replay attack: the attacker records a sequence of messages off the wire and plays them back to the RESTCONF server/client. To protect against it, the common methods include using timestamp or sequence id. Questions: Section 12 1. "Security considerations for the content manipulated by RESTCONF can be found in the documents defining data models.": which documents are mentioned in this sentence for defining data models? 2. nits: "Implementors SHOULD provide a comprehensive authorization scheme with...". Here, should "authorization" be "authentication"? Thank you. B.R. Frank --------------000903070702010605070403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit FYI. The early security directorate review

Regards, Benoit


-------- Forwarded Message --------
Subject: Secdir review of draft-ietf-netconf-restconf-09
Date: Tue, 12 Jan 2016 08:27:53 +0000
From: Xialiang (Frank) <frank.xialiang@huawei.com>
To: draft-ietf-netconf-restconf.all@tools.ietf.org <draft-ietf-netconf-restconf.all@tools.ietf.org>
CC: Tobias Gondrom <tobias.gondrom@gondrom.org>, iesg@ietf.org <iesg@ietf.org>, secdir@ietf.org <secdir@ietf.org>


Hello,

 

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

 

This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF.

 

 

The document appears in reasonably good shape.

 

In general, the RESTCONF is an application protocol layered on the HTTP protocol. As mentioned in the document, just using the HTTPS (with TLS) can address most of the security issues such as confidentiality, integrity, etc. In other words, RESTCONF is designed inherently based on a good security foundation.

 

But there are still several security issues (TBDs) missing in the document that need to be addressed before publication.

 

 

Below is a series of my comments, questions for your consideration.

 

 

Discussion: Section 2

Since this section is all about the security requirements to the RESTCONF transport protocol, is it appropriate to combine it into the security consideration section directly?

 

 

Questions:

Section 4.3

What is the error handling if GET method is used to retrieve the operational resources?

 

Section 4.5

What is the error handing if PUT method does not include the message body?

 

Generally, the similar problems like the above two appear several times in the document, please double check them.

 

 

Comments: Section 12

In the security considerations section, there are still some serious security issues not mentioned:

1. DDoS attack: One RESTCONF client is possible to communicate with a lot of RESTCONF servers, which potentially leads to the situation of DDoS attack to itself or its link. How to avoid or mitigate it?

2. Replay attack: the attacker records a sequence of messages off the wire and plays them back to the RESTCONF server/client. To protect against it, the common methods include using timestamp or sequence id.

 

 

Questions: Section 12

1. "Security considerations for the content manipulated by RESTCONF can be found in the documents defining data models.": which documents are mentioned in this sentence for defining data models?

2. nits: "Implementors SHOULD provide a comprehensive authorization scheme with...". Here, should "authorization" be "authentication"?

 

 

Thank you.

 

B.R.

Frank

 



--------------000903070702010605070403-- From nobody Tue Jan 12 03:53:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CD31AD065 for ; Tue, 12 Jan 2016 03:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Blo6tc8ShRUm for ; Tue, 12 Jan 2016 03:53:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A01AD061 for ; Tue, 12 Jan 2016 03:53:12 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 2ABDF1AE049A for ; Tue, 12 Jan 2016 12:53:10 +0100 (CET) Date: Tue, 12 Jan 2016 12:53:12 +0100 (CET) Message-Id: <20160112.125312.2159654377039539388.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20160108.103837.630719318619521198.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 11:53:13 -0000 Ladislav Lhotka wrote: > > > On 08 Jan 2016, at 10:38, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >> On 06 Jan 2016, at 20:49, Andy Bierman wrote: [...] > >>> It is useful to get the list of modules and then retrieve them. > >>> This is much simpler than parsing YANG modules and retrieving > >>> them as import-stmts are parsed. Your implementation strategy > >>> requires the YANG compiler to be tightly coupled to the retrieval > >>> of YANG modules. > >> > >> This is an implementation detail. The problem I have with listing > >> imported modules multiple times is that it effectively annihilates the > >> idea of Y45-04, which is that "import" modules in yang-library are > >> used for resolving imports without revision. > > > > I agree with Lada. It is clear that Y45-04 - for which we have > > (rough?) consensus - does NOT "advertise" modules that are only > > imported by revision. > > > > However, I also agree w/ Andy that listing all modules is useful, b/c > > a client can easily get the complete, consistent, set of modules that > > the server implements. > > Yes, I agree. > > > > > This said, we have in the past discussed two solutions to this > > problem. One is what you propose below, to indicate the > > default-revision with a new leaf, and the other is to make the latest > > advertised revision be the (implicit) default revision. > > Consider this situation: module A imports B without revision, so an > implementor chooses rev. X of B. Then later module C needs to be > added, but it imports B with revision Y > X. If revision Y > appears in yang-library, then it forces module A to be upgraded > to use revision Y, too. This may IMO be a problem. > > > > > I thought we agreed on the latter, but the current text makes this a > > SHOULD. So I think that either we make this a MUST (simpler), or add > > a new leaf (more flexible, and possibly more clear). > > I'd prefer the latter. We need to decide what to do with this one. The problem: If module A is imported w/o revision by another module that the server implements, the server MUST somehow inform the client which revision of A is used. Solution 1: Reported implicitly - the server lists all revisions of A that it uses, and the most recent one is the one that is used to resolve import w/o revision. Solution 2: Reported explicitly - the server lists all revisions of A that it uses, and the the one that is used to resolve import w/o revision is marked by setting a leaf "default-revision". The current draft has 1 (but it needs to be clarified). Lada prefers 2. What do others think? /martin From nobody Tue Jan 12 04:30:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40CB1AD0A4 for ; Tue, 12 Jan 2016 04:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wm2NRiZoQU9 for ; Tue, 12 Jan 2016 04:30:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B6F1A8992 for ; Tue, 12 Jan 2016 04:30:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E3C3D764; Tue, 12 Jan 2016 13:30:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mQmMmbtPxP15; Tue, 12 Jan 2016 13:30:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 12 Jan 2016 13:30:44 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDECB2002C; Tue, 12 Jan 2016 13:30:43 +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 2mmWM2QgdHVg; Tue, 12 Jan 2016 13:30:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8940320013; Tue, 12 Jan 2016 13:30:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3AC073982A7E; Tue, 12 Jan 2016 13:30:38 +0100 (CET) Date: Tue, 12 Jan 2016 13:30:38 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160112123038.GA4392@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20160108.103837.630719318619521198.mbj@tail-f.com> <20160112.125312.2159654377039539388.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160112.125312.2159654377039539388.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 12:30:49 -0000 On Tue, Jan 12, 2016 at 12:53:12PM +0100, Martin Bjorklund wrote: > > We need to decide what to do with this one. > > The problem: > > If module A is imported w/o revision by another module that the > server implements, the server MUST somehow inform the client which > revision of A is used. > > Solution 1: > > Reported implicitly - the server lists all revisions of A that it > uses, and the most recent one is the one that is used to resolve > import w/o revision. > > Solution 2: > > Reported explicitly - the server lists all revisions of A that it > uses, and the the one that is used to resolve import w/o revision is > marked by setting a leaf "default-revision". > > The current draft has 1 (but it needs to be clarified). Lada prefers > 2. What do others think? The assumption seems to be that all imports without a revision for a certain module resolve to a particular revision of that module. Are we all find with this? If yes, the question is whether the assumption holds that the revision of a module used to resolve imports without a revision is always the most recent revision. If yes, we do can hardwire this and we do not have to report this via an explicit leaf. If not, we need a leaf "default-revision". If not, then we have a bigger problem to solve. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 12 05:10:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE7F1AD190 for ; Tue, 12 Jan 2016 05:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex25aFqyymkk for ; Tue, 12 Jan 2016 05:09:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C847C1AD16B for ; Tue, 12 Jan 2016 05:09:56 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894] (unknown [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894]) by mail.nic.cz (Postfix) with ESMTPSA id 4D97A181A6D; Tue, 12 Jan 2016 14:09:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452604194; bh=EHAX9a768l29iCAm0Jm6Sk5PF+VAMEt6icLWHfw472U=; h=From:Date:To; b=XlZbTWatUARZoWSDFfbBQQ76BKLNlwt/KClIoWW7fjToz/U0Afl2xTh8bDxNAksbU 69l3N1si/MVy1VvuLQtAW8EDpfe1/E1/mt08NOPYqE7zzALdPiqU+P25DaZMqTSz76 yxu61BHzDvJ480byUqJuPl/fnT2PuGW/ZRwuY4yw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160112123038.GA4392@elstar.local> Date: Tue, 12 Jan 2016 14:09:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160108.103837.630719318619521198.mbj@tail-f.com> <20160112.125312.2159654377039539388.mbj@tail-f.com> <20160112123038.GA4392@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:10:00 -0000 > On 12 Jan 2016, at 13:30, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 12, 2016 at 12:53:12PM +0100, Martin Bjorklund wrote: >>=20 >> We need to decide what to do with this one. >>=20 >> The problem: >>=20 >> If module A is imported w/o revision by another module that the >> server implements, the server MUST somehow inform the client which >> revision of A is used. >>=20 >> Solution 1: >>=20 >> Reported implicitly - the server lists all revisions of A that it >> uses, and the most recent one is the one that is used to resolve >> import w/o revision. >>=20 >> Solution 2: >>=20 >> Reported explicitly - the server lists all revisions of A that it >> uses, and the the one that is used to resolve import w/o revision is >> marked by setting a leaf "default-revision". >>=20 >> The current draft has 1 (but it needs to be clarified). Lada prefers >> 2. What do others think? >=20 > The assumption seems to be that all imports without a revision for a > certain module resolve to a particular revision of that module. Are we > all find with this? For the sake of (ever) finishing YANG 1.1, I'd prefer to accept this = limitation for now - it is IMO still an improvement compared to 1.0. Lada >=20 > If yes, the question is whether the assumption holds that the > revision of a module used to resolve imports without a revision is > always the most recent revision. >=20 > If yes, we do can hardwire this and we do not have to report = this > via an explicit leaf. >=20 > If not, we need a leaf "default-revision". >=20 > If not, then we have a bigger problem to solve. >=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 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 05:30:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F251AD28D for ; Tue, 12 Jan 2016 05:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPjU-ql5t9YW for ; Tue, 12 Jan 2016 05:30:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3E21AD289 for ; Tue, 12 Jan 2016 05:30:32 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id D39C11AE049A; Tue, 12 Jan 2016 14:30:30 +0100 (CET) Date: Tue, 12 Jan 2016 14:30:33 +0100 (CET) Message-Id: <20160112.143033.2065421491426290785.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20160112.125312.2159654377039539388.mbj@tail-f.com> <20160112123038.GA4392@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:30:33 -0000 Ladislav Lhotka wrote: > > > On 12 Jan 2016, at 13:30, Juergen Schoenwaelder > > wrote: > > > > On Tue, Jan 12, 2016 at 12:53:12PM +0100, Martin Bjorklund wrote: > >> > >> We need to decide what to do with this one. > >> > >> The problem: > >> > >> If module A is imported w/o revision by another module that the > >> server implements, the server MUST somehow inform the client which > >> revision of A is used. > >> > >> Solution 1: > >> > >> Reported implicitly - the server lists all revisions of A that it > >> uses, and the most recent one is the one that is used to resolve > >> import w/o revision. > >> > >> Solution 2: > >> > >> Reported explicitly - the server lists all revisions of A that it > >> uses, and the the one that is used to resolve import w/o revision is > >> marked by setting a leaf "default-revision". > >> > >> The current draft has 1 (but it needs to be clarified). Lada prefers > >> 2. What do others think? > > > > The assumption seems to be that all imports without a revision for a > > certain module resolve to a particular revision of that module. Are we > > all find with this? > > For the sake of (ever) finishing YANG 1.1, I'd prefer to accept this > limitation for now - it is IMO still an improvement compared to 1.0. +1 And in order to solve this completely generically, the server would have to report the complete set of (modulename,revision) of all imported modules (recursively) *for every module*. For example: module a { ... import x; } module b { ... import x; } module x { ... import y; } The server might report: a: (x,rev1), (y,rev2) b: (x,rev1), (y,rev3) This gets very complicated. > > If yes, the question is whether the assumption holds that the > > revision of a module used to resolve imports without a revision is > > always the most recent revision. > > > > If yes, we do can hardwire this and we do not have to report this > > via an explicit leaf. FWIW, this is what our code (and pyang) does. > > If not, we need a leaf "default-revision". > > > > If not, then we have a bigger problem to solve. /martin From nobody Tue Jan 12 05:32:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E82A1AD289 for ; Tue, 12 Jan 2016 05:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIE64bnKZR0G for ; Tue, 12 Jan 2016 05:31:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B021AD28D for ; Tue, 12 Jan 2016 05:31:59 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894] (unknown [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894]) by mail.nic.cz (Postfix) with ESMTPSA id 55D6B181755; Tue, 12 Jan 2016 14:31:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452605518; bh=/D8H64Hl7dLwwMn6viul6whjPewPBel4y67psVFUuVY=; h=From:Date:To; b=XZlRhOxNY7UEF7Sb+J3JcIj/M5TZCEXzBBC6U39FIiaznGCjnpbW03ia5/ZV+Vncl E9wk1gn5eELBavZ4OlIjDhGSUDTalEp275ySdMzgJZ1U7f0bv+WhsjL8NnXAYUY2ce woHxGNJ1gNAsZrV79kuYL5DabPimVhb7Qe6fwgN0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160112.143033.2065421491426290785.mbj@tail-f.com> Date: Tue, 12 Jan 2016 14:31:58 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20160112.125312.2159654377039539388.mbj@tail-f.com> <20160112123038.GA4392@elstar.local> <20160112.143033.2065421491426290785.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:32:01 -0000 > On 12 Jan 2016, at 14:30, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: >> >>> On 12 Jan 2016, at 13:30, Juergen Schoenwaelder >>> wrote: >>> >>> On Tue, Jan 12, 2016 at 12:53:12PM +0100, Martin Bjorklund wrote: >>>> >>>> We need to decide what to do with this one. >>>> >>>> The problem: >>>> >>>> If module A is imported w/o revision by another module that the >>>> server implements, the server MUST somehow inform the client which >>>> revision of A is used. >>>> >>>> Solution 1: >>>> >>>> Reported implicitly - the server lists all revisions of A that it >>>> uses, and the most recent one is the one that is used to resolve >>>> import w/o revision. >>>> >>>> Solution 2: >>>> >>>> Reported explicitly - the server lists all revisions of A that it >>>> uses, and the the one that is used to resolve import w/o revision is >>>> marked by setting a leaf "default-revision". >>>> >>>> The current draft has 1 (but it needs to be clarified). Lada prefers >>>> 2. What do others think? >>> >>> The assumption seems to be that all imports without a revision for a >>> certain module resolve to a particular revision of that module. Are we >>> all find with this? >> >> For the sake of (ever) finishing YANG 1.1, I'd prefer to accept this >> limitation for now - it is IMO still an improvement compared to 1.0. > > +1 > > And in order to solve this completely generically, the server would > have to report the complete set of (modulename,revision) of all > imported modules (recursively) *for every module*. > > For example: > > module a { ... import x; } > module b { ... import x; } > module x { ... import y; } > > The server might report: > > a: (x,rev1), (y,rev2) > b: (x,rev1), (y,rev3) > > > This gets very complicated. > >>> If yes, the question is whether the assumption holds that the >>> revision of a module used to resolve imports without a revision is >>> always the most recent revision. >>> >>> If yes, we do can hardwire this and we do not have to report this >>> via an explicit leaf. > > FWIW, this is what our code (and pyang) does. What about my example? Do you think it is a non-issue? Lada > >>> If not, we need a leaf "default-revision". >>> >>> If not, then we have a bigger problem to solve. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 05:40:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67EE1AD351 for ; Tue, 12 Jan 2016 05:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYW1NMah7Mqm for ; Tue, 12 Jan 2016 05:40:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2221AD17F for ; Tue, 12 Jan 2016 05:40:49 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 311EF1AE049A; Tue, 12 Jan 2016 14:40:48 +0100 (CET) Date: Tue, 12 Jan 2016 14:40:50 +0100 (CET) Message-Id: <20160112.144050.1782790623001856895.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20160112.143033.2065421491426290785.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:40:51 -0000 Ladislav Lhotka wrote: > > > On 12 Jan 2016, at 14:30, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 12 Jan 2016, at 13:30, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Tue, Jan 12, 2016 at 12:53:12PM +0100, Martin Bjorklund wrote: > >>>> > >>>> We need to decide what to do with this one. > >>>> > >>>> The problem: > >>>> > >>>> If module A is imported w/o revision by another module that the > >>>> server implements, the server MUST somehow inform the client which > >>>> revision of A is used. > >>>> > >>>> Solution 1: > >>>> > >>>> Reported implicitly - the server lists all revisions of A that it > >>>> uses, and the most recent one is the one that is used to resolve > >>>> import w/o revision. > >>>> > >>>> Solution 2: > >>>> > >>>> Reported explicitly - the server lists all revisions of A that it > >>>> uses, and the the one that is used to resolve import w/o revision is > >>>> marked by setting a leaf "default-revision". > >>>> > >>>> The current draft has 1 (but it needs to be clarified). Lada prefers > >>>> 2. What do others think? > >>> > >>> The assumption seems to be that all imports without a revision for a > >>> certain module resolve to a particular revision of that module. Are we > >>> all find with this? > >> > >> For the sake of (ever) finishing YANG 1.1, I'd prefer to accept this > >> limitation for now - it is IMO still an improvement compared to 1.0. > > > > +1 > > > > And in order to solve this completely generically, the server would > > have to report the complete set of (modulename,revision) of all > > imported modules (recursively) *for every module*. > > > > For example: > > > > module a { ... import x; } > > module b { ... import x; } > > module x { ... import y; } > > > > The server might report: > > > > a: (x,rev1), (y,rev2) > > b: (x,rev1), (y,rev3) > > > > > > This gets very complicated. > > > >>> If yes, the question is whether the assumption holds that the > >>> revision of a module used to resolve imports without a revision is > >>> always the most recent revision. > >>> > >>> If yes, we do can hardwire this and we do not have to report this > >>> via an explicit leaf. > > > > FWIW, this is what our code (and pyang) does. > > What about my example? Do you think it is a non-issue? I am just saying that it is a non-issue in our code. /martin From nobody Tue Jan 12 06:12:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236EF1B2A30 for ; Tue, 12 Jan 2016 06:12:31 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU1GVAM6YelO for ; Tue, 12 Jan 2016 06:12:29 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7F41B2A2C for ; Tue, 12 Jan 2016 06:12:29 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id 52CR1s00D3vXPcr012CSqm; Tue, 12 Jan 2016 15:12:27 +0100 To: Netconf From: "Bert Wijnen (IETF)" Message-ID: <569509C9.4050609@bwijnen.net> Date: Tue, 12 Jan 2016 15:12:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] my review of draft-ietf-netconf-yang-patch-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:12:31 -0000 I have read and reviewed this document. It seems in good shape to me and ready for publication. Bert From nobody Tue Jan 12 06:31:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969051B2A46 for ; Tue, 12 Jan 2016 06:31:40 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g4fDw3bCvUv for ; Tue, 12 Jan 2016 06:31:36 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D049C1B2A69 for ; Tue, 12 Jan 2016 06:31:35 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud2.xs4all.net with ESMTP id 52XY1s00a3vXPcr012Xaww; Tue, 12 Jan 2016 15:31:34 +0100 To: Netconf From: "Bert Wijnen (IETF)" Message-ID: <56950E44.5030501@bwijnen.net> Date: Tue, 12 Jan 2016 15:31:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] my review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:31:40 -0000 i have read and reviewed this document. I am supportive of this document and I think it is in good shape for publication. I have one question, about the Security Considerations section, which states: The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. Mmmm I guess that YNAG modules are (these days) designed to be accessed by (at least) NETCONF and RESTCONF, no? Not sure if the text/template needs updating. I can live with it. But since I was reviewing this after I have reviewed the restconf document, I wondered if the text above is 100% correct and (if not) if we worry about that or not. Bert From nobody Tue Jan 12 07:30:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FFF1B2A9C for ; Tue, 12 Jan 2016 07:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO3-Gonu0OK6 for ; Tue, 12 Jan 2016 07:30:47 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E3E1A0187 for ; Tue, 12 Jan 2016 07:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6415; q=dns/txt; s=iport; t=1452612647; x=1453822247; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=a4bPM/cqYMh3cbE03SY4N8Z/gX3Fnqd8HZNjTbqCpQQ=; b=OTZSVkQ86nf1bYy8STbUasXq/hoHLPNYSsY51LE3VJIF3PXwaXjakIEH OoEzqX/FnDM3CXL9nNVJ6c/jg2wPEODzuNknCa1t7R2Dk3obSZB9aBys/ 6SVU1VUozZl3YDgIiGunSV3SkST/Gjvc/WQAN/A1k0NFk/0daFnnpL/MZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgA/G5VW/40NJK1egzpSbYhZsRCCE?= =?us-ascii?q?wENgWYihW0CgSU4FAEBAQEBAQGBCoQ0AQEBBG4KERwDAQIKFgQLCQMCAQIBOwI?= =?us-ascii?q?IBg0GAgEBiCoOv2oBAQEBAQEBAwEBAQEBAQEYBIZWhH+Ed4RGBZMQhAOFQ4gWg?= =?us-ascii?q?V6HSoVUhWWIbiABAUKCSoFBPTSGMQEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,558,1444694400"; d="scan'208,217"; a="62727880" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2016 15:29:45 +0000 Received: from [10.24.150.212] ([10.24.150.212]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0CFTbIW021742 for ; Tue, 12 Jan 2016 15:29:41 GMT References: <20160112033615.23217.71278.idtracker@ietfa.amsl.com> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <20160112033615.23217.71278.idtracker@ietfa.amsl.com> Message-ID: <56951A77.7090707@cisco.com> Date: Tue, 12 Jan 2016 16:23:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160112033615.23217.71278.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050101000809030600070909" Archived-At: Subject: [Netconf] Fwd: Protocol Action: 'Changing the Registration Policy for the NETCONF Capability URNs Registry' to Best Current Practice (draft-leiba-netmod-regpolicy-update-02.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:30:49 -0000 This is a multi-part message in MIME format. --------------050101000809030600070909 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: Protocol Action: 'Changing the Registration Policy for the NETCONF Capability URNs Registry' to Best Current Practice (draft-leiba-netmod-regpolicy-update-02.txt) Date: Mon, 11 Jan 2016 19:36:15 -0800 From: The IESG To: IETF-Announce CC: Barry Leiba , draft-leiba-netmod-regpolicy-update@ietf.org, bclaise@cisco.com, The IESG , barryleiba@computer.org, rfc-editor@rfc-editor.org The IESG has approved the following document: - 'Changing the Registration Policy for the NETCONF Capability URNs Registry' (draft-leiba-netmod-regpolicy-update-02.txt) as Best Current Practice This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ Technical Summary The registration policy for the NETCONF Capability URNs registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from Experimental or Informational RFCs, in addition to Standards Track RFCs. This document is proposed as a BCP, which is suitable for an IANA registration policy update. Review and Consensus This document was prompted by IESG review of an Experimental document that asked the IESG for an exception to the registry's policy for new registrations. The result of discussion of that request was to recommend that the policy be changed. This document makes that change. The document has been discussed and reviewed in the NETCONF WG, mentioned both during the IETF 94 and over the mailing list. There was support for the change, and not a single voice against. Personnel Barry Leiba is the Document Shepherd. Beno??t Claise is the responsible Area Director. . --------------050101000809030600070909 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: Protocol Action: 'Changing the Registration Policy for the NETCONF Capability URNs Registry' to Best Current Practice (draft-leiba-netmod-regpolicy-update-02.txt)
Date: Mon, 11 Jan 2016 19:36:15 -0800
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: Barry Leiba <barryleiba@computer.org>, draft-leiba-netmod-regpolicy-update@ietf.org, bclaise@cisco.com, The IESG <iesg@ietf.org>, barryleiba@computer.org, rfc-editor@rfc-editor.org 


The IESG has approved the following document:
- 'Changing the Registration Policy for the NETCONF Capability URNs
   Registry'
  (draft-leiba-netmod-regpolicy-update-02.txt) as Best Current Practice

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/




Technical Summary

The registration policy for the NETCONF Capability URNs registry,
set up by RFC 6241, has turned out to be unnecessarily strict.
This document changes that registration policy to "IETF Review",
allowing registrations from Experimental or Informational RFCs,
in addition to Standards Track RFCs.
   
This document is proposed as a BCP, which is suitable for an IANA
registration policy update.

Review and Consensus

This document was prompted by IESG review of an Experimental
document that asked the IESG for an exception to the registry's
policy for new registrations.  The result of discussion of that
request was to recommend that the policy be changed.  This document
makes that change.

The document has been discussed and reviewed in the NETCONF
WG, mentioned both during the IETF 94 and over the mailing list.
There was support for the change, and not a single voice against.

Personnel
Barry Leiba is the Document Shepherd.
Beno??t Claise is the responsible Area Director.
.


--------------050101000809030600070909-- From nobody Tue Jan 12 11:24:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0961A872A for ; Tue, 12 Jan 2016 11:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHF0S8qKs5NK for ; Tue, 12 Jan 2016 11:24:15 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 486901A8729 for ; Tue, 12 Jan 2016 11:24:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JQxIPQaN3sHuOCmoFqWkkFda1tWSYfUOmLtBee3EyQureGudbGeDrc2bXA06wQKL; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aJ4Y0-0000Sq-OC for netconf@ietf.org; Tue, 12 Jan 2016 14:24:04 -0500 Received: from 76.254.54.14 by webmail.earthlink.net with HTTP; Tue, 12 Jan 2016 14:24:04 -0500 Message-ID: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Tue, 12 Jan 2016 11:24:04 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc7b9388b687e491d60c81c58503c0d097350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 19:24:16 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 12, 2016 3:53 AM >To: netconf@ietf.org >Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 ... >The problem: > > If module A is imported w/o revision by another module that the > server implements, the server MUST somehow inform the client which > revision of A is used. > >Solution 1: > > Reported implicitly - the server lists all revisions of A that it > uses, and the most recent one is the one that is used to resolve > import w/o revision. > >Solution 2: > > Reported explicitly - the server lists all revisions of A that it > uses, and the the one that is used to resolve import w/o revision is > marked by setting a leaf "default-revision". > > >The current draft has 1 (but it needs to be clarified). Lada prefers >2. What do others think? Solution 1 is sufficient if the underlying implementations of all the importing modules in a system strictly play by the current rules. I think solution 2 would be *slightly* more robust, particularly in systems supporting dynamic component updates or components from multiple vendors. If we ever get to the realistic state of being able to support multiple revisions of a particular kind of component concurrently through a single server, both are inadequate. Randy From nobody Tue Jan 12 12:02:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD601A8823 for ; Tue, 12 Jan 2016 12:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6HeQdPld3cN for ; Tue, 12 Jan 2016 12:02:49 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BC51A8822 for ; Tue, 12 Jan 2016 12:02:48 -0800 (PST) Received: by mail-lb0-x22e.google.com with SMTP id x4so22069651lbm.0 for ; Tue, 12 Jan 2016 12:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hva/IPlbjqOTTggGvWq/Fp5bmmc4uCPPFlUZrchk2NE=; b=BkO4zrb7yGtonTEm2Ri8bEJ8uS1w3hGXeI4INbvCXbsnwvIrKJykFbHaMZ18WiRwlj dVPNij2fj6/g8Mnw0a/yVMRnhg60vFcijR16IMfobB011FFoB8ZkOUQjOsQd1dD8SA9G Fs/DBpJ+UjaqvoKsbE33wpbVuE4JKLODA3x/Su+m45G3q7TY786NNEdDLxr/0VcevC0B MZ6/bF8RNvWs5sxXPhC3C06Wq1/tCXCs4Q72xrLI+UQYDvu8ClgGpa1RHBuGEVmbJ8aI 5TRN0nJG4AyWSvLT21lfS8cJ+U5lKyovVcEDCGMXN5ZyxmyU689tQMfwXXaTbCXxWwSH JlSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hva/IPlbjqOTTggGvWq/Fp5bmmc4uCPPFlUZrchk2NE=; b=MO+ly3YlPHar+oYpLA4174/6cLat+uHQlv2XiBgDZpL2czFCMZD4oQcYhRqSLGtqp7 BXaCO5NRDzUgt+9dFzcYB3O7t7ABKFmaeiP8iyTqir2XMW7rDWxdryKN82b7lRca5Ytp hkSnci/PrAA+Udnm1io9wbMBpQoCG95hnfCv8DsmJ+Vmx1DfSu7Q7RZWooxepdH2/X/B H/3Cr04oHBoWmdIZ1ojVFkaKHzIDktBi7pmpHuVIWfIxaxNUd2wkWb9+zicV8Bnljccc 7jazmPS3c8h1JATIumRlpmsSmnv1cPab0xmXZnVnHKiRZW0yswCWRwAyE5qERpJUp0oU lHIg== X-Gm-Message-State: ALoCoQnGjYW0hrCy02LMBDE0DanFYlOmmfD3x/5lyf7xkLhRmnu9It7tBT6AwzaobU9yeeAXoWvBlSpNGaw+3fl2ZTrDZofnWA== MIME-Version: 1.0 X-Received: by 10.112.141.70 with SMTP id rm6mr40053764lbb.94.1452628966777; Tue, 12 Jan 2016 12:02:46 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 12 Jan 2016 12:02:46 -0800 (PST) In-Reply-To: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Tue, 12 Jan 2016 12:02:46 -0800 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=001a11c3819c8e3dab0529288946 Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 20:02:50 -0000 --001a11c3819c8e3dab0529288946 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Jan 12, 2016 3:53 AM > >To: netconf@ietf.org > >Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 > ... > >The problem: > > > > If module A is imported w/o revision by another module that the > > server implements, the server MUST somehow inform the client which > > revision of A is used. > > > >Solution 1: > > > > Reported implicitly - the server lists all revisions of A that it > > uses, and the most recent one is the one that is used to resolve > > import w/o revision. > > > >Solution 2: > > > > Reported explicitly - the server lists all revisions of A that it > > uses, and the the one that is used to resolve import w/o revision is > > marked by setting a leaf "default-revision". > > > > > >The current draft has 1 (but it needs to be clarified). Lada prefers > >2. What do others think? > > Solution 1 is sufficient if the underlying implementations of all > the importing modules in a system strictly play by the current rules. > I think solution 2 would be *slightly* more robust, particularly in > systems supporting dynamic component updates or components from > multiple vendors. If we ever get to the realistic state of being > able to support multiple revisions of a particular kind of component > concurrently through a single server, both are inadequate. > > IMO, solution 1 is appropriate because IMO nobody is going to write complex client apps to analyze revision-date trees, so they can be applied to all the import-stmts without revision found nested in all the server YANG modules. We also implemented solution 1 many years ago, and it has been working fine. Nobody has ever asked to use multiple revisions for the default import. > Randy > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c3819c8e3dab0529288946 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn <<= a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres= uhn@mindspring.com> wrote:
= Hi -

>From: Martin Bjorklund <mbj@tail-f= .com>
>Sent: Jan 12, 2016 3:53 AM
>To: netconf@ietf.org
>Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03
...
>The problem:
>
>=C2=A0 If module A is imported w/o revision by another module that the<= br> >=C2=A0 server implements, the server MUST somehow inform the client whi= ch
>=C2=A0 revision of A is used.
>
>Solution 1:
>
>=C2=A0 Reported implicitly - the server lists all revisions of A that i= t
>=C2=A0 uses, and the most recent one is the one that is used to resolve=
>=C2=A0 import w/o revision.
>
>Solution 2:
>
>=C2=A0 Reported explicitly - the server lists all revisions of A that i= t
>=C2=A0 uses, and the the one that is used to resolve import w/o revisio= n is
>=C2=A0 marked by setting a leaf "default-revision".
>
>
>The current draft has 1 (but it needs to be clarified).=C2=A0 Lada pref= ers
>2.=C2=A0 What do others think?

Solution 1 is sufficient if the underlying implementations of all
the importing modules in a system strictly play by the current rules.
I think solution 2 would be *slightly* more robust, particularly in
systems supporting dynamic component updates or components from
multiple vendors.=C2=A0 If we ever get to the realistic state of being
able to support multiple revisions of a particular kind of component
concurrently through a single server, both are inadequate.


IMO, solution 1 is appropriate because= IMO nobody is going to
write complex client apps to analyze revi= sion-date trees, so they
can be applied to all the import-stmts w= ithout revision found nested
in all the server YANG modules.

We also implemented solution 1 many years ago, and it<= /div>
has been working fine.=C2=A0 Nobody has ever asked to
u= se multiple revisions for the default import.

=C2= =A0
Randy


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

--001a11c3819c8e3dab0529288946-- From nobody Wed Jan 13 01:18:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A911A3BA4 for ; Wed, 13 Jan 2016 01:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG8AcEP7gEvY for ; Wed, 13 Jan 2016 01:18:05 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2A1A1C06 for ; Wed, 13 Jan 2016 01:18:05 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 057441CC0337; Wed, 13 Jan 2016 10:18:09 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Randy Presuhn In-Reply-To: References: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 13 Jan 2016 10:18:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:18:08 -0000 Andy Bierman writes: > On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > randy_presuhn@mindspring.com> wrote: > >> Hi - >> >> >From: Martin Bjorklund >> >Sent: Jan 12, 2016 3:53 AM >> >To: netconf@ietf.org >> >Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 >> ... >> >The problem: >> > >> > If module A is imported w/o revision by another module that the >> > server implements, the server MUST somehow inform the client which >> > revision of A is used. >> > >> >Solution 1: >> > >> > Reported implicitly - the server lists all revisions of A that it >> > uses, and the most recent one is the one that is used to resolve >> > import w/o revision. >> > >> >Solution 2: >> > >> > Reported explicitly - the server lists all revisions of A that it >> > uses, and the the one that is used to resolve import w/o revision is >> > marked by setting a leaf "default-revision". >> > >> > >> >The current draft has 1 (but it needs to be clarified). Lada prefers >> >2. What do others think? >> >> Solution 1 is sufficient if the underlying implementations of all >> the importing modules in a system strictly play by the current rules. >> I think solution 2 would be *slightly* more robust, particularly in >> systems supporting dynamic component updates or components from >> multiple vendors. If we ever get to the realistic state of being >> able to support multiple revisions of a particular kind of component >> concurrently through a single server, both are inadequate. >> >> > IMO, solution 1 is appropriate because IMO nobody is going to > write complex client apps to analyze revision-date trees, so they > can be applied to all the import-stmts without revision found nested > in all the server YANG modules. Solutions 1 and 2 don't differ on this: all revisions of all modules used by the server will be listed in yang-library. > > We also implemented solution 1 many years ago, and it > has been working fine. Nobody has ever asked to > use multiple revisions for the default import. Also, neither solution 1 nor 2 proposes this. There will be only one revision available for imports without revision. The real difference is that solution 1 may force an upgrade in a module that imports another module without revision as a side effect of extending the data model, because the maximum revision can change. Lada > > > >> Randy >> >> > Andy > > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 02:28:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4481A1A59 for ; Wed, 13 Jan 2016 02:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV-NBGXgIgX5 for ; Wed, 13 Jan 2016 02:28:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40E971A1A58 for ; Wed, 13 Jan 2016 02:28:38 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id B2ADF1AE0A47; Wed, 13 Jan 2016 11:28:36 +0100 (CET) Date: Wed, 13 Jan 2016 11:28:43 +0100 (CET) Message-Id: <20160113.112843.1618780489460806431.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 10:28:40 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > > randy_presuhn@mindspring.com> wrote: > > > >> Hi - > >> > >> >From: Martin Bjorklund > >> >Sent: Jan 12, 2016 3:53 AM > >> >To: netconf@ietf.org > >> >Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 > >> ... > >> >The problem: > >> > > >> > If module A is imported w/o revision by another module that the > >> > server implements, the server MUST somehow inform the client which > >> > revision of A is used. > >> > > >> >Solution 1: > >> > > >> > Reported implicitly - the server lists all revisions of A that it > >> > uses, and the most recent one is the one that is used to resolve > >> > import w/o revision. > >> > > >> >Solution 2: > >> > > >> > Reported explicitly - the server lists all revisions of A that it > >> > uses, and the the one that is used to resolve import w/o revision is > >> > marked by setting a leaf "default-revision". > >> > > >> > > >> >The current draft has 1 (but it needs to be clarified). Lada prefers > >> >2. What do others think? > >> > >> Solution 1 is sufficient if the underlying implementations of all > >> the importing modules in a system strictly play by the current rules. > >> I think solution 2 would be *slightly* more robust, particularly in > >> systems supporting dynamic component updates or components from > >> multiple vendors. If we ever get to the realistic state of being > >> able to support multiple revisions of a particular kind of component > >> concurrently through a single server, both are inadequate. > >> > >> > > IMO, solution 1 is appropriate because IMO nobody is going to > > write complex client apps to analyze revision-date trees, so they > > can be applied to all the import-stmts without revision found nested > > in all the server YANG modules. > > Solutions 1 and 2 don't differ on this: all revisions of all modules > used by the server will be listed in yang-library. > > > > > We also implemented solution 1 many years ago, and it > > has been working fine. Nobody has ever asked to > > use multiple revisions for the default import. > > Also, neither solution 1 nor 2 proposes this. There will be only one > revision available for imports without revision. Let me rephrase Andy's statement: Nobody has ever asked us to be able to have a different default revision than the latest revision. > The real difference is that solution 1 may force an upgrade in a module > that imports another module without revision as a side effect of > extending the data model, because the maximum revision can change. It is not an upgrade of the *module*, it is an upgrade of the instrumentation code for that module. /martin From nobody Wed Jan 13 02:47:08 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53E31A1B9C for ; Wed, 13 Jan 2016 02:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNXRcpnYAKpi for ; Wed, 13 Jan 2016 02:47:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CE41A1B8B for ; Wed, 13 Jan 2016 02:47:04 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id AF0B2181A2C; Wed, 13 Jan 2016 11:47:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452682022; bh=4juI4z/jRScjiVJGD5YEj7CCDclzCIOlSnbswyyWlZs=; h=From:Date:To; b=cZzkU26f4KAxj68idMSS5ZDVft5n0r0E9U/uhicw6UQ8J4CLP9D1PmaDyI9WiV8mb TGzU1D5pYAL7tgAKVyOWEvajf4jTPOAQMFn8D4hisvnQ0EF+YwO4WXLWifx372sl+0 mNH2FvhGsooP55Gf09H2gu5axjJOLMLchostuac4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160113.112843.1618780489460806431.mbj@tail-f.com> Date: Wed, 13 Jan 2016 11:47:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> References: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <20160113.112843.1618780489460806431.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 10:47:07 -0000 > On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < >>> randy_presuhn@mindspring.com> wrote: >>>=20 >>>> Hi - >>>>=20 >>>>> From: Martin Bjorklund >>>>> Sent: Jan 12, 2016 3:53 AM >>>>> To: netconf@ietf.org >>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03 >>>> ... >>>>> The problem: >>>>>=20 >>>>> If module A is imported w/o revision by another module that the >>>>> server implements, the server MUST somehow inform the client which >>>>> revision of A is used. >>>>>=20 >>>>> Solution 1: >>>>>=20 >>>>> Reported implicitly - the server lists all revisions of A that it >>>>> uses, and the most recent one is the one that is used to resolve >>>>> import w/o revision. >>>>>=20 >>>>> Solution 2: >>>>>=20 >>>>> Reported explicitly - the server lists all revisions of A that it >>>>> uses, and the the one that is used to resolve import w/o revision = is >>>>> marked by setting a leaf "default-revision". >>>>>=20 >>>>>=20 >>>>> The current draft has 1 (but it needs to be clarified). Lada = prefers >>>>> 2. What do others think? >>>>=20 >>>> Solution 1 is sufficient if the underlying implementations of all >>>> the importing modules in a system strictly play by the current = rules. >>>> I think solution 2 would be *slightly* more robust, particularly in >>>> systems supporting dynamic component updates or components from >>>> multiple vendors. If we ever get to the realistic state of being >>>> able to support multiple revisions of a particular kind of = component >>>> concurrently through a single server, both are inadequate. >>>>=20 >>>>=20 >>> IMO, solution 1 is appropriate because IMO nobody is going to >>> write complex client apps to analyze revision-date trees, so they >>> can be applied to all the import-stmts without revision found nested >>> in all the server YANG modules. >>=20 >> Solutions 1 and 2 don't differ on this: all revisions of all modules >> used by the server will be listed in yang-library. >>=20 >>>=20 >>> We also implemented solution 1 many years ago, and it >>> has been working fine. Nobody has ever asked to >>> use multiple revisions for the default import. >>=20 >> Also, neither solution 1 nor 2 proposes this. There will be only one >> revision available for imports without revision. >=20 > Let me rephrase Andy's statement: Nobody has ever asked us to be able = to > have a different default revision than the latest revision. Rephrase? Andy says "use multiple revisions for the default import", not = "different than latest". >=20 >> The real difference is that solution 1 may force an upgrade in a = module >> that imports another module without revision as a side effect of >> extending the data model, because the maximum revision can change. >=20 > It is not an upgrade of the *module*, it is an upgrade of the > instrumentation code for that module. Correct, and this is what the instrumentation code may not be prepared = for. I think it is quite important to be able to keep the default import = revision stable. The fact that nobody has asked for it yet isn't IMO = very relevant because most modules so far have only one revision. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 03:04:57 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5421A6F8B for ; Wed, 13 Jan 2016 03:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jko5MYE3ojzl for ; Wed, 13 Jan 2016 03:04:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1311A6F8A for ; Wed, 13 Jan 2016 03:04:53 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 535851AE0A47; Wed, 13 Jan 2016 12:04:52 +0100 (CET) Date: Wed, 13 Jan 2016 12:04:59 +0100 (CET) Message-Id: <20160113.120459.920122826629125868.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> References: <20160113.112843.1618780489460806431.mbj@tail-f.com> <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 11:04:56 -0000 Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> Andy Bierman writes: > >> > >>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > >>> randy_presuhn@mindspring.com> wrote: > >>> > >>>> Hi - > >>>> > >>>>> From: Martin Bjorklund > >>>>> Sent: Jan 12, 2016 3:53 AM > >>>>> To: netconf@ietf.org > >>>>> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 > >>>> ... > >>>>> The problem: > >>>>> > >>>>> If module A is imported w/o revision by another module that the > >>>>> server implements, the server MUST somehow inform the client which > >>>>> revision of A is used. > >>>>> > >>>>> Solution 1: > >>>>> > >>>>> Reported implicitly - the server lists all revisions of A that it > >>>>> uses, and the most recent one is the one that is used to resolve > >>>>> import w/o revision. > >>>>> > >>>>> Solution 2: > >>>>> > >>>>> Reported explicitly - the server lists all revisions of A that it > >>>>> uses, and the the one that is used to resolve import w/o revision is > >>>>> marked by setting a leaf "default-revision". > >>>>> > >>>>> > >>>>> The current draft has 1 (but it needs to be clarified). Lada prefers > >>>>> 2. What do others think? > >>>> > >>>> Solution 1 is sufficient if the underlying implementations of all > >>>> the importing modules in a system strictly play by the current rules. > >>>> I think solution 2 would be *slightly* more robust, particularly in > >>>> systems supporting dynamic component updates or components from > >>>> multiple vendors. If we ever get to the realistic state of being > >>>> able to support multiple revisions of a particular kind of component > >>>> concurrently through a single server, both are inadequate. > >>>> > >>>> > >>> IMO, solution 1 is appropriate because IMO nobody is going to > >>> write complex client apps to analyze revision-date trees, so they > >>> can be applied to all the import-stmts without revision found nested > >>> in all the server YANG modules. > >> > >> Solutions 1 and 2 don't differ on this: all revisions of all modules > >> used by the server will be listed in yang-library. > >> > >>> > >>> We also implemented solution 1 many years ago, and it > >>> has been working fine. Nobody has ever asked to > >>> use multiple revisions for the default import. > >> > >> Also, neither solution 1 nor 2 proposes this. There will be only one > >> revision available for imports without revision. > > > > Let me rephrase Andy's statement: Nobody has ever asked us to be able > > to > > have a different default revision than the latest revision. > > Rephrase? Andy says "use multiple revisions for the default import", > not "different than latest". > > >> The real difference is that solution 1 may force an upgrade in a > >> module > >> that imports another module without revision as a side effect of > >> extending the data model, because the maximum revision can change. > > > > It is not an upgrade of the *module*, it is an upgrade of the > > instrumentation code for that module. > > Correct, and this is what the instrumentation code may not be prepared > for. I think it is quite important to be able to keep the default > import revision stable. The fact that nobody has asked for it yet > isn't IMO very relevant because most modules so far have only one > revision. Not true! Vendors have been writing and updating modules since 2010. I am just providing one data point. /martin From nobody Wed Jan 13 03:29:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723811A6FDD for ; Wed, 13 Jan 2016 03:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o57olszjnsJr for ; Wed, 13 Jan 2016 03:29:35 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152D81A6FE8 for ; Wed, 13 Jan 2016 03:29:35 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id cl12so71382311lbc.1 for ; Wed, 13 Jan 2016 03:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nIMmX5/BFy+Vg1y6zk+A5SwyxryEcoaFwGcFYcCo4Ds=; b=iR/+974psz0ajbuKj30HBO6JEGfXqarSFbIedsxZigrDsxjnEelCHPoNS5Rs0KL5dd d/Dc3AcWXEpvXMFmz7luFkbrcmtx7Qg6rUF+5iH5OVslCG9pa1UTZZiOJ1Yf1EHiTNIB E7g+SoNd4M5vPiNAfP20IE1E8xEkG3p7CKEcDwOd02IbmOkExVcwbUA/54bfd9YBUInO Loxnjwr6wW9sXZ0RE6Bjkjyg5Pk2UCN42DUgnP2t0byrFBGVoqXrx7B1T7ZxRx21jNYX rDdWFbnFQB85CLrcYxIofmLxhhaFW3zFO/0OG3ai3ceR4tq+AKILAPEy8nnk+rKj9YRO OrcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nIMmX5/BFy+Vg1y6zk+A5SwyxryEcoaFwGcFYcCo4Ds=; b=lefISrc83fYCuJq3GFDU95SeCfDdwK3LMe3pnxIeFFTkQqzLm9F5HIlf4o6BYs7SFn 6PdPOst6ws1rORkMundZl2GxY4Cqh13xZnkdeO44hGp5D+KPewF1Tzpnc3rhIbXTPygw fDikurlLt+9ImK98b6jLZnx4NBwCht5guTAk+mOFJ6pX8LmVWHmevyvyo/jcb6PJt6yu wD8IJSeb/U+wwWsa8I2ejaFoUglrEUN4eRH744S0eW53Lekxj/Ytbgycv/gJ4KGxBX8G WVtFBZpMqhjraE8rzCOna554NTmpNawbHwVEfeVv1QFloxd+4XpT2W83dz1NrBX6uJpw hexA== X-Gm-Message-State: ALoCoQl2aR+94Qp/0Z4MK+X3ETef+vj8d4CExCihdElVkICXRVf9R0gbl35oHamU11/cMO6kbxZuu+ysSPoWAcu6/406i31HTA== MIME-Version: 1.0 X-Received: by 10.112.147.1 with SMTP id tg1mr154678lbb.119.1452684573200; Wed, 13 Jan 2016 03:29:33 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 13 Jan 2016 03:29:33 -0800 (PST) In-Reply-To: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> References: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <20160113.112843.1618780489460806431.mbj@tail-f.com> <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> Date: Wed, 13 Jan 2016 03:29:33 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b3a7f5cf4ebc30529357b61 Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 11:29:37 -0000 --047d7b3a7f5cf4ebc30529357b61 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 13, 2016 at 2:47 AM, Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> Andy Bierman writes: > >> > >>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > >>> randy_presuhn@mindspring.com> wrote: > >>> > >>>> Hi - > >>>> > >>>>> From: Martin Bjorklund > >>>>> Sent: Jan 12, 2016 3:53 AM > >>>>> To: netconf@ietf.org > >>>>> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 > >>>> ... > >>>>> The problem: > >>>>> > >>>>> If module A is imported w/o revision by another module that the > >>>>> server implements, the server MUST somehow inform the client which > >>>>> revision of A is used. > >>>>> > >>>>> Solution 1: > >>>>> > >>>>> Reported implicitly - the server lists all revisions of A that it > >>>>> uses, and the most recent one is the one that is used to resolve > >>>>> import w/o revision. > >>>>> > >>>>> Solution 2: > >>>>> > >>>>> Reported explicitly - the server lists all revisions of A that it > >>>>> uses, and the the one that is used to resolve import w/o revision is > >>>>> marked by setting a leaf "default-revision". > >>>>> > >>>>> > >>>>> The current draft has 1 (but it needs to be clarified). Lada prefers > >>>>> 2. What do others think? > >>>> > >>>> Solution 1 is sufficient if the underlying implementations of all > >>>> the importing modules in a system strictly play by the current rules. > >>>> I think solution 2 would be *slightly* more robust, particularly in > >>>> systems supporting dynamic component updates or components from > >>>> multiple vendors. If we ever get to the realistic state of being > >>>> able to support multiple revisions of a particular kind of component > >>>> concurrently through a single server, both are inadequate. > >>>> > >>>> > >>> IMO, solution 1 is appropriate because IMO nobody is going to > >>> write complex client apps to analyze revision-date trees, so they > >>> can be applied to all the import-stmts without revision found nested > >>> in all the server YANG modules. > >> > >> Solutions 1 and 2 don't differ on this: all revisions of all modules > >> used by the server will be listed in yang-library. > >> > >>> > >>> We also implemented solution 1 many years ago, and it > >>> has been working fine. Nobody has ever asked to > >>> use multiple revisions for the default import. > >> > >> Also, neither solution 1 nor 2 proposes this. There will be only one > >> revision available for imports without revision. > > > > Let me rephrase Andy's statement: Nobody has ever asked us to be able to > > have a different default revision than the latest revision. > > Rephrase? Andy says "use multiple revisions for the default import", not > "different than latest". > > I meant what Martin said -- using the latest revision supported by the server as the default has been sufficient. > > > >> The real difference is that solution 1 may force an upgrade in a module > >> that imports another module without revision as a side effect of > >> extending the data model, because the maximum revision can change. > > > > It is not an upgrade of the *module*, it is an upgrade of the > > instrumentation code for that module. > > Correct, and this is what the instrumentation code may not be prepared > for. I think it is quite important to be able to keep the default import > revision stable. The fact that nobody has asked for it yet isn't IMO very > relevant because most modules so far have only one revision. > > No -- it is quite the opposite. If the YANG update rules are followed then the latest revision will work just fine, and updating the default revision to the latest is transparent to old clients. This would be the point of all those rules in section 10. > Lada > > > > > > > /martin > > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b3a7f5cf4ebc30529357b61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 13, 2016 at 2:47 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Jan 2016, at 11:28, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn <
>>> randy_presuhn@= mindspring.com> wrote:
>>>
>>>> Hi -
>>>>
>>>>> From: Martin Bjorklund <mbj@tail-f.com>
>>>>> Sent: Jan 12, 2016 3:53 AM
>>>>> To: netconf@ietf.o= rg
>>>>> Subject: Re: [Netconf] review of draft-ietf-netconf-ya= ng-library-03
>>>> ...
>>>>> The problem:
>>>>>
>>>>> If module A is imported w/o revision by another module= that the
>>>>> server implements, the server MUST somehow inform the = client which
>>>>> revision of A is used.
>>>>>
>>>>> Solution 1:
>>>>>
>>>>> Reported implicitly - the server lists all revisions o= f A that it
>>>>> uses, and the most recent one is the one that is used = to resolve
>>>>> import w/o revision.
>>>>>
>>>>> Solution 2:
>>>>>
>>>>> Reported explicitly - the server lists all revisions o= f A that it
>>>>> uses, and the the one that is used to resolve import w= /o revision is
>>>>> marked by setting a leaf "default-revision".=
>>>>>
>>>>>
>>>>> The current draft has 1 (but it needs to be clarified)= .=C2=A0 Lada prefers
>>>>> 2.=C2=A0 What do others think?
>>>>
>>>> Solution 1 is sufficient if the underlying implementations= of all
>>>> the importing modules in a system strictly play by the cur= rent rules.
>>>> I think solution 2 would be *slightly* more robust, partic= ularly in
>>>> systems supporting dynamic component updates or components= from
>>>> multiple vendors.=C2=A0 If we ever get to the realistic st= ate of being
>>>> able to support multiple revisions of a particular kind of= component
>>>> concurrently through a single server, both are inadequate.=
>>>>
>>>>
>>> IMO, solution 1 is appropriate because IMO nobody is going to<= br> >>> write complex client apps to analyze revision-date trees, so t= hey
>>> can be applied to all the import-stmts without revision found = nested
>>> in all the server YANG modules.
>>
>> Solutions 1 and 2 don't differ on this: all revisions of all m= odules
>> used by the server will be listed in yang-library.
>>
>>>
>>> We also implemented solution 1 many years ago, and it
>>> has been working fine.=C2=A0 Nobody has ever asked to
>>> use multiple revisions for the default import.
>>
>> Also, neither solution 1 nor 2 proposes this. There will be only o= ne
>> revision available for imports without revision.
>
> Let me rephrase Andy's statement: Nobody has ever asked us to be a= ble to
> have a different default revision than the latest revision.

Rephrase? Andy says "use multiple revisions for the default import&quo= t;, not "different than latest".



I meant what Martin sai= d -- using the latest revision supported by the
server as the def= ault has been sufficient.

=C2=A0
>
>> The real difference is that solution 1 may force an upgrade in a m= odule
>> that imports another module without revision as a side effect of >> extending the data model, because the maximum revision can change.=
>
> It is not an upgrade of the *module*, it is an upgrade of the
> instrumentation code for that module.

Correct, and this is what the instrumentation code may not be prepared for.= I think it is quite important to be able to keep the default import revisi= on stable. The fact that nobody has asked for it yet isn't IMO very rel= evant because most modules so far have only one revision.



No -- it is quite the o= pposite.
If the YANG update rules are followed then the latest re= vision will
work just fine, and updating the default revision to = the latest is transparent
to old clients.

This would be the point of all those rules in section 10.

<= /div>

=C2=A0
Lada

>
>
> /martin



Andy

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





--047d7b3a7f5cf4ebc30529357b61-- From nobody Wed Jan 13 03:38:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFED1A7035 for ; Wed, 13 Jan 2016 03:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypPGrwKSmKk4 for ; Wed, 13 Jan 2016 03:37:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D551A7026 for ; Wed, 13 Jan 2016 03:37:59 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id 37AAF180C7B; Wed, 13 Jan 2016 12:37:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452685078; bh=MPAlj4MifpEpcV+5mgmAZayi26P0JjITyImwtcgRirs=; h=From:Date:To; b=u7lpYS300VW4utoRKDxVuRFKEP8jz3eTXk2IDaTYQktjdU3k37WksoCcxtdo1b1Xa RRO93jdaWMNLVA3a10PiNWabsHyBeF0ilmmhshmRYp4+B0VSvXOMvnjBa8SQ0/ZyS/ mg+INPa2lj47LxGyZZIhA0ZkxNsKJLYUXYOaPJuk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160113.120459.920122826629125868.mbj@tail-f.com> Date: Wed, 13 Jan 2016 12:37:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160113.112843.1618780489460806431.mbj@tail-f.com> <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 11:38:01 -0000 > On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>> Andy Bierman writes: >>>>=20 >>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < >>>>> randy_presuhn@mindspring.com> wrote: >>>>>=20 >>>>>> Hi - >>>>>>=20 >>>>>>> From: Martin Bjorklund >>>>>>> Sent: Jan 12, 2016 3:53 AM >>>>>>> To: netconf@ietf.org >>>>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03 >>>>>> ... >>>>>>> The problem: >>>>>>>=20 >>>>>>> If module A is imported w/o revision by another module that the >>>>>>> server implements, the server MUST somehow inform the client = which >>>>>>> revision of A is used. >>>>>>>=20 >>>>>>> Solution 1: >>>>>>>=20 >>>>>>> Reported implicitly - the server lists all revisions of A that = it >>>>>>> uses, and the most recent one is the one that is used to resolve >>>>>>> import w/o revision. >>>>>>>=20 >>>>>>> Solution 2: >>>>>>>=20 >>>>>>> Reported explicitly - the server lists all revisions of A that = it >>>>>>> uses, and the the one that is used to resolve import w/o = revision is >>>>>>> marked by setting a leaf "default-revision". >>>>>>>=20 >>>>>>>=20 >>>>>>> The current draft has 1 (but it needs to be clarified). Lada = prefers >>>>>>> 2. What do others think? >>>>>>=20 >>>>>> Solution 1 is sufficient if the underlying implementations of all >>>>>> the importing modules in a system strictly play by the current = rules. >>>>>> I think solution 2 would be *slightly* more robust, particularly = in >>>>>> systems supporting dynamic component updates or components from >>>>>> multiple vendors. If we ever get to the realistic state of being >>>>>> able to support multiple revisions of a particular kind of = component >>>>>> concurrently through a single server, both are inadequate. >>>>>>=20 >>>>>>=20 >>>>> IMO, solution 1 is appropriate because IMO nobody is going to >>>>> write complex client apps to analyze revision-date trees, so they >>>>> can be applied to all the import-stmts without revision found = nested >>>>> in all the server YANG modules. >>>>=20 >>>> Solutions 1 and 2 don't differ on this: all revisions of all = modules >>>> used by the server will be listed in yang-library. >>>>=20 >>>>>=20 >>>>> We also implemented solution 1 many years ago, and it >>>>> has been working fine. Nobody has ever asked to >>>>> use multiple revisions for the default import. >>>>=20 >>>> Also, neither solution 1 nor 2 proposes this. There will be only = one >>>> revision available for imports without revision. >>>=20 >>> Let me rephrase Andy's statement: Nobody has ever asked us to be = able >>> to >>> have a different default revision than the latest revision. >>=20 >> Rephrase? Andy says "use multiple revisions for the default import", >> not "different than latest". >>=20 >>>> The real difference is that solution 1 may force an upgrade in a >>>> module >>>> that imports another module without revision as a side effect of >>>> extending the data model, because the maximum revision can change. >>>=20 >>> It is not an upgrade of the *module*, it is an upgrade of the >>> instrumentation code for that module. >>=20 >> Correct, and this is what the instrumentation code may not be = prepared >> for. I think it is quite important to be able to keep the default >> import revision stable. The fact that nobody has asked for it yet >> isn't IMO very relevant because most modules so far have only one >> revision. >=20 > Not true! Vendors have been writing and updating modules since 2010. These don't count - vendors writing both modules and instrumentation are = in control of everything. The problem I am talking about is this: I want = to use a standard module M, but its author decided to import module X = with revision that is greater than the default revision I am currently = using in the data model. So I have three options: 1. forget about module M, 2. write a proprietary version of M so that it uses at most my default = revision of X, 3. upgrade the instrumentation to use the higher revision of X. Lada >=20 > I am just providing one data point. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 03:45:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1895E1A86DD for ; Wed, 13 Jan 2016 03:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXp4nfJx1MBJ for ; Wed, 13 Jan 2016 03:45:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEB31A7D84 for ; Wed, 13 Jan 2016 03:45:54 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id ACA9A1AE0A47; Wed, 13 Jan 2016 12:45:53 +0100 (CET) Date: Wed, 13 Jan 2016 12:46:00 +0100 (CET) Message-Id: <20160113.124600.805156894654343799.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 11:45:56 -0000 Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> Andy Bierman writes: > >>>> > >>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > >>>>> randy_presuhn@mindspring.com> wrote: > >>>>> > >>>>>> Hi - > >>>>>> > >>>>>>> From: Martin Bjorklund > >>>>>>> Sent: Jan 12, 2016 3:53 AM > >>>>>>> To: netconf@ietf.org > >>>>>>> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 > >>>>>> ... > >>>>>>> The problem: > >>>>>>> > >>>>>>> If module A is imported w/o revision by another module that the > >>>>>>> server implements, the server MUST somehow inform the client which > >>>>>>> revision of A is used. > >>>>>>> > >>>>>>> Solution 1: > >>>>>>> > >>>>>>> Reported implicitly - the server lists all revisions of A that it > >>>>>>> uses, and the most recent one is the one that is used to resolve > >>>>>>> import w/o revision. > >>>>>>> > >>>>>>> Solution 2: > >>>>>>> > >>>>>>> Reported explicitly - the server lists all revisions of A that it > >>>>>>> uses, and the the one that is used to resolve import w/o revision is > >>>>>>> marked by setting a leaf "default-revision". > >>>>>>> > >>>>>>> > >>>>>>> The current draft has 1 (but it needs to be clarified). Lada prefers > >>>>>>> 2. What do others think? > >>>>>> > >>>>>> Solution 1 is sufficient if the underlying implementations of all > >>>>>> the importing modules in a system strictly play by the current rules. > >>>>>> I think solution 2 would be *slightly* more robust, particularly in > >>>>>> systems supporting dynamic component updates or components from > >>>>>> multiple vendors. If we ever get to the realistic state of being > >>>>>> able to support multiple revisions of a particular kind of component > >>>>>> concurrently through a single server, both are inadequate. > >>>>>> > >>>>>> > >>>>> IMO, solution 1 is appropriate because IMO nobody is going to > >>>>> write complex client apps to analyze revision-date trees, so they > >>>>> can be applied to all the import-stmts without revision found nested > >>>>> in all the server YANG modules. > >>>> > >>>> Solutions 1 and 2 don't differ on this: all revisions of all modules > >>>> used by the server will be listed in yang-library. > >>>> > >>>>> > >>>>> We also implemented solution 1 many years ago, and it > >>>>> has been working fine. Nobody has ever asked to > >>>>> use multiple revisions for the default import. > >>>> > >>>> Also, neither solution 1 nor 2 proposes this. There will be only one > >>>> revision available for imports without revision. > >>> > >>> Let me rephrase Andy's statement: Nobody has ever asked us to be able > >>> to > >>> have a different default revision than the latest revision. > >> > >> Rephrase? Andy says "use multiple revisions for the default import", > >> not "different than latest". > >> > >>>> The real difference is that solution 1 may force an upgrade in a > >>>> module > >>>> that imports another module without revision as a side effect of > >>>> extending the data model, because the maximum revision can change. > >>> > >>> It is not an upgrade of the *module*, it is an upgrade of the > >>> instrumentation code for that module. > >> > >> Correct, and this is what the instrumentation code may not be prepared > >> for. I think it is quite important to be able to keep the default > >> import revision stable. The fact that nobody has asked for it yet > >> isn't IMO very relevant because most modules so far have only one > >> revision. > > > > Not true! Vendors have been writing and updating modules since 2010. > > These don't count - vendors writing both modules and instrumentation > are in control of everything. The point is that many vendors follow the upgrade rules, and they have been doing this for several years. > The problem I am talking about is this: > I want to use a standard module M, but its author decided to import > module X with revision that is greater than the default revision I am > currently using in the data model. I think you meant "using in the instrumentation". > So I have three options: > > 1. forget about module M, > 2. write a proprietary version of M so that it uses at most my default > revision of X, > 3. upgrade the instrumentation to use the higher revision of X. Correct. You may run into the same situation if you also want to add the instrumentation for module N, which also imports X w/o revision, and this instrumentation uses a higher version of X than your implementation of M. The 'default-revision' leaf doesn't solve this. Our experience, and Andy's experience, is that doing (3) has not been an issue in implementations. /martin From nobody Wed Jan 13 03:57:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF571A8715 for ; Wed, 13 Jan 2016 03:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rkqVhqR6yJa for ; Wed, 13 Jan 2016 03:57:26 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD4E1A870D for ; Wed, 13 Jan 2016 03:57:26 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id B138B1CC0337; Wed, 13 Jan 2016 12:57:30 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <2057000.1452626644780.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <20160113.112843.1618780489460806431.mbj@tail-f.com> <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 13 Jan 2016 12:57:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 11:57:28 -0000 Andy Bierman writes: > On Wed, Jan 13, 2016 at 2:47 AM, Ladislav Lhotka wrote: > >> >> > On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: >> > >> > Ladislav Lhotka wrote: >> >> Andy Bierman writes: >> >> >> >>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < >> >>> randy_presuhn@mindspring.com> wrote: >> >>> >> >>>> Hi - >> >>>> >> >>>>> From: Martin Bjorklund >> >>>>> Sent: Jan 12, 2016 3:53 AM >> >>>>> To: netconf@ietf.org >> >>>>> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 >> >>>> ... >> >>>>> The problem: >> >>>>> >> >>>>> If module A is imported w/o revision by another module that the >> >>>>> server implements, the server MUST somehow inform the client which >> >>>>> revision of A is used. >> >>>>> >> >>>>> Solution 1: >> >>>>> >> >>>>> Reported implicitly - the server lists all revisions of A that it >> >>>>> uses, and the most recent one is the one that is used to resolve >> >>>>> import w/o revision. >> >>>>> >> >>>>> Solution 2: >> >>>>> >> >>>>> Reported explicitly - the server lists all revisions of A that it >> >>>>> uses, and the the one that is used to resolve import w/o revision is >> >>>>> marked by setting a leaf "default-revision". >> >>>>> >> >>>>> >> >>>>> The current draft has 1 (but it needs to be clarified). Lada prefers >> >>>>> 2. What do others think? >> >>>> >> >>>> Solution 1 is sufficient if the underlying implementations of all >> >>>> the importing modules in a system strictly play by the current rules. >> >>>> I think solution 2 would be *slightly* more robust, particularly in >> >>>> systems supporting dynamic component updates or components from >> >>>> multiple vendors. If we ever get to the realistic state of being >> >>>> able to support multiple revisions of a particular kind of component >> >>>> concurrently through a single server, both are inadequate. >> >>>> >> >>>> >> >>> IMO, solution 1 is appropriate because IMO nobody is going to >> >>> write complex client apps to analyze revision-date trees, so they >> >>> can be applied to all the import-stmts without revision found nested >> >>> in all the server YANG modules. >> >> >> >> Solutions 1 and 2 don't differ on this: all revisions of all modules >> >> used by the server will be listed in yang-library. >> >> >> >>> >> >>> We also implemented solution 1 many years ago, and it >> >>> has been working fine. Nobody has ever asked to >> >>> use multiple revisions for the default import. >> >> >> >> Also, neither solution 1 nor 2 proposes this. There will be only one >> >> revision available for imports without revision. >> > >> > Let me rephrase Andy's statement: Nobody has ever asked us to be able to >> > have a different default revision than the latest revision. >> >> Rephrase? Andy says "use multiple revisions for the default import", not >> "different than latest". >> >> > > I meant what Martin said -- using the latest revision supported by the > server as the default has been sufficient. > > > >> > >> >> The real difference is that solution 1 may force an upgrade in a module >> >> that imports another module without revision as a side effect of >> >> extending the data model, because the maximum revision can change. >> > >> > It is not an upgrade of the *module*, it is an upgrade of the >> > instrumentation code for that module. >> >> Correct, and this is what the instrumentation code may not be prepared >> for. I think it is quite important to be able to keep the default import >> revision stable. The fact that nobody has asked for it yet isn't IMO very >> relevant because most modules so far have only one revision. >> >> > > No -- it is quite the opposite. > If the YANG update rules are followed then the latest revision will > work just fine, and updating the default revision to the latest is > transparent > to old clients. > > This would be the point of all those rules in section 10. The rules in sec. 10 protect old clients, not old servers. Let me expand the example: module X { ... revision n; grouping grp { leaf foo {...} } ... } module X { ... revision n+1; grouping grp { leaf foo {...} leaf bar {...} } ... } Note that this module update is fully compatible with sec. 10 rules. My data model imports module X without revision and uses grouping "grp". I chose to use revision n of X in my data model. Now, I want to use module M that imports X with revision n+1. How do sec. 10 rules protect me from rewriting the old parts of my instrumentation and implementing "bar"? Lada > > > > >> Lada >> >> > >> > >> > /martin >> >> > > Andy > > > >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 04:17:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81CF1ACD77 for ; Wed, 13 Jan 2016 04:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGR5lh7HY3TN for ; Wed, 13 Jan 2016 04:17:55 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750391ACD76 for ; Wed, 13 Jan 2016 04:17:55 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id 19544181AB9; Wed, 13 Jan 2016 13:17:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452687474; bh=z7Lo+MyRkvh/z77C40wZEohfZ0jYtbryPBQBzNCwdYw=; h=From:Date:To; b=j6ZMx6mV6qNbzVnMVWApwNvVUleCiiHhCcw3NEpSoUn4vFxmKHndAbZwqvKiB891k 9qWL/tQ5Hm240OeLx52mqCbyF9DicBGvGmL7H/y8Wi8kMQStUBszGF/Hs+G+iLEvdg rpk4EIlhsnoUcQe03FgNlwuhYb+Tu97/keLmo/NQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160113.124600.805156894654343799.mbj@tail-f.com> Date: Wed, 13 Jan 2016 13:17:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:17:58 -0000 > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>> Andy Bierman writes: >>>>>>=20 >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < >>>>>>> randy_presuhn@mindspring.com> wrote: >>>>>>>=20 >>>>>>>> Hi - >>>>>>>>=20 >>>>>>>>> From: Martin Bjorklund >>>>>>>>> Sent: Jan 12, 2016 3:53 AM >>>>>>>>> To: netconf@ietf.org >>>>>>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03 >>>>>>>> ... >>>>>>>>> The problem: >>>>>>>>>=20 >>>>>>>>> If module A is imported w/o revision by another module that = the >>>>>>>>> server implements, the server MUST somehow inform the client = which >>>>>>>>> revision of A is used. >>>>>>>>>=20 >>>>>>>>> Solution 1: >>>>>>>>>=20 >>>>>>>>> Reported implicitly - the server lists all revisions of A that = it >>>>>>>>> uses, and the most recent one is the one that is used to = resolve >>>>>>>>> import w/o revision. >>>>>>>>>=20 >>>>>>>>> Solution 2: >>>>>>>>>=20 >>>>>>>>> Reported explicitly - the server lists all revisions of A that = it >>>>>>>>> uses, and the the one that is used to resolve import w/o = revision is >>>>>>>>> marked by setting a leaf "default-revision". >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The current draft has 1 (but it needs to be clarified). Lada = prefers >>>>>>>>> 2. What do others think? >>>>>>>>=20 >>>>>>>> Solution 1 is sufficient if the underlying implementations of = all >>>>>>>> the importing modules in a system strictly play by the current = rules. >>>>>>>> I think solution 2 would be *slightly* more robust, = particularly in >>>>>>>> systems supporting dynamic component updates or components from >>>>>>>> multiple vendors. If we ever get to the realistic state of = being >>>>>>>> able to support multiple revisions of a particular kind of = component >>>>>>>> concurrently through a single server, both are inadequate. >>>>>>>>=20 >>>>>>>>=20 >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to >>>>>>> write complex client apps to analyze revision-date trees, so = they >>>>>>> can be applied to all the import-stmts without revision found = nested >>>>>>> in all the server YANG modules. >>>>>>=20 >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all = modules >>>>>> used by the server will be listed in yang-library. >>>>>>=20 >>>>>>>=20 >>>>>>> We also implemented solution 1 many years ago, and it >>>>>>> has been working fine. Nobody has ever asked to >>>>>>> use multiple revisions for the default import. >>>>>>=20 >>>>>> Also, neither solution 1 nor 2 proposes this. There will be only = one >>>>>> revision available for imports without revision. >>>>>=20 >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be = able >>>>> to >>>>> have a different default revision than the latest revision. >>>>=20 >>>> Rephrase? Andy says "use multiple revisions for the default = import", >>>> not "different than latest". >>>>=20 >>>>>> The real difference is that solution 1 may force an upgrade in a >>>>>> module >>>>>> that imports another module without revision as a side effect of >>>>>> extending the data model, because the maximum revision can = change. >>>>>=20 >>>>> It is not an upgrade of the *module*, it is an upgrade of the >>>>> instrumentation code for that module. >>>>=20 >>>> Correct, and this is what the instrumentation code may not be = prepared >>>> for. I think it is quite important to be able to keep the default >>>> import revision stable. The fact that nobody has asked for it yet >>>> isn't IMO very relevant because most modules so far have only one >>>> revision. >>>=20 >>> Not true! Vendors have been writing and updating modules since = 2010. >>=20 >> These don't count - vendors writing both modules and instrumentation >> are in control of everything. >=20 > The point is that many vendors follow the upgrade rules, and they have > been doing this for several years. See my response to Andy, upgrade rules really don't help server = implementors. >=20 >> The problem I am talking about is this: >> I want to use a standard module M, but its author decided to import >> module X with revision that is greater than the default revision I am >> currently using in the data model. >=20 > I think you meant "using in the instrumentation". No, I meant the complete and concrete data model in use by the server, = in which the decision about revisions of imported modules has to be = made. In my example, I would need to make the "bar" leaf a part of the = data model schema, and instrumentation as well, of course. >=20 >> So I have three options: >>=20 >> 1. forget about module M, >> 2. write a proprietary version of M so that it uses at most my = default >> revision of X, >> 3. upgrade the instrumentation to use the higher revision of X. >=20 > Correct. >=20 > You may run into the same situation if you also want to add the > instrumentation for module N, which also imports X w/o revision, and > this instrumentation uses a higher version of X than your > implementation of M. The 'default-revision' leaf doesn't solve this. It does solve this! As the server implementor I am in control of the = contents of yang-library, so I can bump "default-revision" any time, and = module M is unaffected because it imports X with revision. The only issue would be with other modules that import X without = revision: their instrumentation need to be upgraded at the same time, = but that's the deal if we want to have no more than one default = revision. Lada >=20 >=20 > Our experience, and Andy's experience, is that doing (3) has not been > an issue in implementations. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 07:28:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048D1B2EB9 for ; Wed, 13 Jan 2016 07:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi77eKz4Si0t for ; Wed, 13 Jan 2016 07:28:11 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CFB1B2EA4 for ; Wed, 13 Jan 2016 07:28:10 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id bc4so291808445lbc.2 for ; Wed, 13 Jan 2016 07:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PJyMNuF9jPp9IRo98vbm/Z3kj6Th1Q0wcsgiSA1d330=; b=K3GmKjQ6PX8mMKVnJbBG3Qj2CYuctRhcXq2l6IvJOZIshQbCnslWsrymRGB/zF9uPN 1nVPPH/x7nxlVljQUQgPwtXnz3Jd6vZbkniFnNqWxM6XeA0zKf7GJgo5Hdw3NZ6furpe sB11iBroAanBYYHpznn3i5U/+chKCJkAogLq2BzVbnCjy2fBUBHzODR0WuaadZOnOvuk +cVfO3nIPPgXfFSOgxoptKO+g+tufLKLutTuZH3hZQKPO2y8gbHVEUXJ/U58SRgWaZPO 7YVKx3xL1yv590LnuI/YC4Kho8v987RBL9MjrGKQBvoQygBmRyrcNBhOh246xX/HJoTG ImeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PJyMNuF9jPp9IRo98vbm/Z3kj6Th1Q0wcsgiSA1d330=; b=W8tqE44OTOvrICez3ZeF0VOz1HZrN4LYuqT2ycqPjDuCHnnQjBCrMPQi1nGF36flfL vzuwY1G2dif0J0kVWWqspeo7u9A9TZFp0vupv9r5LbTm68jHQBwLjMS7fmTlja3x4DdX N3C6AjA8V4wDgc0VbGGzraqTXVadbdsYOWYxqC6H3EACOYopn5RST6p5z2qt5BM5vMYF 2TQGmsEV5FaYG+LZszKIZWi6u8gn0SDJYIpQdX/A/qc8Vw3JhS+L9lmcpWUleqqf2jao 2x+QsOE1T4ZYQOIvcJCpHDox4X8Kpg/JMWj4qxu4/jEqTNW5xXgBcSrFAUpDKHWTdEpR B1FA== X-Gm-Message-State: ALoCoQm0yFJ8C6ho4vqz+Oke7IPvkCuyAOEtGGC5CGrMhs3Yf0d1gAcKy15ICbDttgB6iHsqsjXKQ6unLEx2dAgkjfHE7KEkOA== MIME-Version: 1.0 X-Received: by 10.112.147.1 with SMTP id tg1mr562635lbb.119.1452698889039; Wed, 13 Jan 2016 07:28:09 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 13 Jan 2016 07:28:08 -0800 (PST) In-Reply-To: <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> Date: Wed, 13 Jan 2016 07:28:08 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b3a7f5c3f4b31052938d144 Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:28:14 -0000 --047d7b3a7f5c3f4b31052938d144 Content-Type: text/plain; charset=UTF-8 Hi, I don't see the point of redoing the debate of the corner-case that started the entire "conformance drift" discussion several years ago. In YANG 1.1, the designer can import the same module 67 times, with 67 different revision dates. They can add new groupings instead of extending an existing one. YANG 1.1 has mechanisms to use that allow the details to be properly reflected. We have not seen any desire by vendors to break their own client code or their customers client code, so even though YANG 1.0 allows import-without-revision to cause drift, vendors avoid doing this because it breaks deployed product. IMO, a complex solution will not get implemented. Any solution that requires any YANG modules to be parsed to discover the imports is even worse than what we have in YANG 1.0. We will just continue using the and ignore YANG 1.1 rules if the solution is worse than what we have now. Andy On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> Andy Bierman writes: > >>>>>> > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > >>>>>>> randy_presuhn@mindspring.com> wrote: > >>>>>>> > >>>>>>>> Hi - > >>>>>>>> > >>>>>>>>> From: Martin Bjorklund > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > >>>>>>>>> To: netconf@ietf.org > >>>>>>>>> Subject: Re: [Netconf] review of > draft-ietf-netconf-yang-library-03 > >>>>>>>> ... > >>>>>>>>> The problem: > >>>>>>>>> > >>>>>>>>> If module A is imported w/o revision by another module that the > >>>>>>>>> server implements, the server MUST somehow inform the client > which > >>>>>>>>> revision of A is used. > >>>>>>>>> > >>>>>>>>> Solution 1: > >>>>>>>>> > >>>>>>>>> Reported implicitly - the server lists all revisions of A that it > >>>>>>>>> uses, and the most recent one is the one that is used to resolve > >>>>>>>>> import w/o revision. > >>>>>>>>> > >>>>>>>>> Solution 2: > >>>>>>>>> > >>>>>>>>> Reported explicitly - the server lists all revisions of A that it > >>>>>>>>> uses, and the the one that is used to resolve import w/o > revision is > >>>>>>>>> marked by setting a leaf "default-revision". > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The current draft has 1 (but it needs to be clarified). Lada > prefers > >>>>>>>>> 2. What do others think? > >>>>>>>> > >>>>>>>> Solution 1 is sufficient if the underlying implementations of all > >>>>>>>> the importing modules in a system strictly play by the current > rules. > >>>>>>>> I think solution 2 would be *slightly* more robust, particularly > in > >>>>>>>> systems supporting dynamic component updates or components from > >>>>>>>> multiple vendors. If we ever get to the realistic state of being > >>>>>>>> able to support multiple revisions of a particular kind of > component > >>>>>>>> concurrently through a single server, both are inadequate. > >>>>>>>> > >>>>>>>> > >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to > >>>>>>> write complex client apps to analyze revision-date trees, so they > >>>>>>> can be applied to all the import-stmts without revision found > nested > >>>>>>> in all the server YANG modules. > >>>>>> > >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all modules > >>>>>> used by the server will be listed in yang-library. > >>>>>> > >>>>>>> > >>>>>>> We also implemented solution 1 many years ago, and it > >>>>>>> has been working fine. Nobody has ever asked to > >>>>>>> use multiple revisions for the default import. > >>>>>> > >>>>>> Also, neither solution 1 nor 2 proposes this. There will be only one > >>>>>> revision available for imports without revision. > >>>>> > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be able > >>>>> to > >>>>> have a different default revision than the latest revision. > >>>> > >>>> Rephrase? Andy says "use multiple revisions for the default import", > >>>> not "different than latest". > >>>> > >>>>>> The real difference is that solution 1 may force an upgrade in a > >>>>>> module > >>>>>> that imports another module without revision as a side effect of > >>>>>> extending the data model, because the maximum revision can change. > >>>>> > >>>>> It is not an upgrade of the *module*, it is an upgrade of the > >>>>> instrumentation code for that module. > >>>> > >>>> Correct, and this is what the instrumentation code may not be prepared > >>>> for. I think it is quite important to be able to keep the default > >>>> import revision stable. The fact that nobody has asked for it yet > >>>> isn't IMO very relevant because most modules so far have only one > >>>> revision. > >>> > >>> Not true! Vendors have been writing and updating modules since 2010. > >> > >> These don't count - vendors writing both modules and instrumentation > >> are in control of everything. > > > > The point is that many vendors follow the upgrade rules, and they have > > been doing this for several years. > > See my response to Andy, upgrade rules really don't help server > implementors. > > > > >> The problem I am talking about is this: > >> I want to use a standard module M, but its author decided to import > >> module X with revision that is greater than the default revision I am > >> currently using in the data model. > > > > I think you meant "using in the instrumentation". > > No, I meant the complete and concrete data model in use by the server, in > which the decision about revisions of imported modules has to be made. In > my example, I would need to make the "bar" leaf a part of the data model > schema, and instrumentation as well, of course. > > > > >> So I have three options: > >> > >> 1. forget about module M, > >> 2. write a proprietary version of M so that it uses at most my default > >> revision of X, > >> 3. upgrade the instrumentation to use the higher revision of X. > > > > Correct. > > > > You may run into the same situation if you also want to add the > > instrumentation for module N, which also imports X w/o revision, and > > this instrumentation uses a higher version of X than your > > implementation of M. The 'default-revision' leaf doesn't solve this. > > It does solve this! As the server implementor I am in control of the > contents of yang-library, so I can bump "default-revision" any time, and > module M is unaffected because it imports X with revision. > > The only issue would be with other modules that import X without revision: > their instrumentation need to be upgraded at the same time, but that's the > deal if we want to have no more than one default revision. > > Lada > > > > > > > Our experience, and Andy's experience, is that doing (3) has not been > > an issue in implementations. > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b3a7f5c3f4b31052938d144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't see the point of redoin= g the debate of the corner-case that started
the entire "con= formance drift" discussion several years ago.
In YANG 1.1, t= he designer can import the same module 67 times,
with 67 differen= t revision dates.=C2=A0 They can add new groupings instead of
ext= ending an existing one.=C2=A0 YANG 1.1 has mechanisms to use
that= allow the details to be properly reflected.

We ha= ve not seen any desire by vendors to break their own
client code = or their customers client code, so even though
YANG 1.0 allows im= port-without-revision to cause drift,
vendors avoid doing this be= cause it breaks deployed product.

IMO, =C2=A0a com= plex solution will not get implemented.
Any solution that require= s any YANG modules to be parsed
to discover the imports is even w= orse than what we have in YANG 1.0.
We will just continue using t= he <hello> and ignore YANG 1.1 rules
if the solution is wor= se than what we have now.


Andy



On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka <lhotka@ni= c.cz> wrote:

> On 13 Jan 2016, at 12:46, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>
>>> On 13 Jan 2016, at 12:04, Martin Bjorklund <mbj@tail-f.com> wrote:
>>>
>>> Ladislav Lhotka <lhotka@ni= c.cz> wrote:
>>>>
>>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund <mbj@tail-f.com> wrote:
>>>>>
>>>>> Ladislav Lhotka <l= hotka@nic.cz> wrote:
>>>>>> Andy Bierman <andy@yumaworks.com> writes:
>>>>>>
>>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuh= n <
>>>>>>> randy_presuhn@mindspring.com> wrote:
>>>>>>>
>>>>>>>> Hi -
>>>>>>>>
>>>>>>>>> From: Martin Bjorklund <mbj@tail-f.com>
>>>>>>>>> Sent: Jan 12, 2016 3:53 AM
>>>>>>>>> To: netconf@ietf.org
>>>>>>>>> Subject: Re: [Netconf] review of draft= -ietf-netconf-yang-library-03
>>>>>>>> ...
>>>>>>>>> The problem:
>>>>>>>>>
>>>>>>>>> If module A is imported w/o revision b= y another module that the
>>>>>>>>> server implements, the server MUST som= ehow inform the client which
>>>>>>>>> revision of A is used.
>>>>>>>>>
>>>>>>>>> Solution 1:
>>>>>>>>>
>>>>>>>>> Reported implicitly - the server lists= all revisions of A that it
>>>>>>>>> uses, and the most recent one is the o= ne that is used to resolve
>>>>>>>>> import w/o revision.
>>>>>>>>>
>>>>>>>>> Solution 2:
>>>>>>>>>
>>>>>>>>> Reported explicitly - the server lists= all revisions of A that it
>>>>>>>>> uses, and the the one that is used to = resolve import w/o revision is
>>>>>>>>> marked by setting a leaf "default= -revision".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The current draft has 1 (but it needs = to be clarified).=C2=A0 Lada prefers
>>>>>>>>> 2.=C2=A0 What do others think?
>>>>>>>>
>>>>>>>> Solution 1 is sufficient if the underlying= implementations of all
>>>>>>>> the importing modules in a system strictly= play by the current rules.
>>>>>>>> I think solution 2 would be *slightly* mor= e robust, particularly in
>>>>>>>> systems supporting dynamic component updat= es or components from
>>>>>>>> multiple vendors.=C2=A0 If we ever get to = the realistic state of being
>>>>>>>> able to support multiple revisions of a pa= rticular kind of component
>>>>>>>> concurrently through a single server, both= are inadequate.
>>>>>>>>
>>>>>>>>
>>>>>>> IMO, solution 1 is appropriate because IMO nob= ody is going to
>>>>>>> write complex client apps to analyze revision-= date trees, so they
>>>>>>> can be applied to all the import-stmts without= revision found nested
>>>>>>> in all the server YANG modules.
>>>>>>
>>>>>> Solutions 1 and 2 don't differ on this: all re= visions of all modules
>>>>>> used by the server will be listed in yang-library.=
>>>>>>
>>>>>>>
>>>>>>> We also implemented solution 1 many years ago,= and it
>>>>>>> has been working fine.=C2=A0 Nobody has ever a= sked to
>>>>>>> use multiple revisions for the default import.=
>>>>>>
>>>>>> Also, neither solution 1 nor 2 proposes this. Ther= e will be only one
>>>>>> revision available for imports without revision. >>>>>
>>>>> Let me rephrase Andy's statement: Nobody has ever = asked us to be able
>>>>> to
>>>>> have a different default revision than the latest revi= sion.
>>>>
>>>> Rephrase? Andy says "use multiple revisions for the d= efault import",
>>>> not "different than latest".
>>>>
>>>>>> The real difference is that solution 1 may force a= n upgrade in a
>>>>>> module
>>>>>> that imports another module without revision as a = side effect of
>>>>>> extending the data model, because the maximum revi= sion can change.
>>>>>
>>>>> It is not an upgrade of the *module*, it is an upgrade= of the
>>>>> instrumentation code for that module.
>>>>
>>>> Correct, and this is what the instrumentation code may not= be prepared
>>>> for. I think it is quite important to be able to keep the = default
>>>> import revision stable. The fact that nobody has asked for= it yet
>>>> isn't IMO very relevant because most modules so far ha= ve only one
>>>> revision.
>>>
>>> Not true!=C2=A0 Vendors have been writing and updating modules= since 2010.
>>
>> These don't count - vendors writing both modules and instrumen= tation
>> are in control of everything.
>
> The point is that many vendors follow the upgrade rules, and they have=
> been doing this for several years.

See my response to Andy, upgrade rules really don't help server impleme= ntors.

>
>> The problem I am talking about is this:
>> I want to use a standard module M, but its author decided to impor= t
>> module X with revision that is greater than the default revision I= am
>> currently using in the data model.
>
> I think you meant "using in the instrumentation".

No, I meant the complete and concrete data model in use by the server, in w= hich the decision about revisions of imported modules has to be made. In my= example, I would need to make the "bar" leaf a part of the data = model schema, and instrumentation as well, of course.

>
>> So I have three options:
>>
>> 1. forget about module M,
>> 2. write a proprietary version of M so that it uses at most my def= ault
>> revision of X,
>> 3. upgrade the instrumentation to use the higher revision of X. >
> Correct.
>
> You may run into the same situation if you also want to add the
> instrumentation for module N, which also imports X w/o revision, and > this instrumentation uses a higher version of X than your
> implementation of M.=C2=A0 The 'default-revision' leaf doesn&#= 39;t solve this.

It does solve this! As the server implementor I am in control of the conten= ts of yang-library, so I can bump "default-revision" any time, an= d module M is unaffected because it imports X with revision.

The only issue would be with other modules that import X without revision: = their instrumentation need to be upgraded at the same time, but that's = the deal if we want to have no more than one default revision.

Lada

>
>
> Our experience, and Andy's experience, is that doing (3) has not b= een
> an issue in implementations.
>
>
> /martin

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





--047d7b3a7f5c3f4b31052938d144-- From nobody Wed Jan 13 07:38:03 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946181A900B for ; Wed, 13 Jan 2016 07:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqLvKzBr9T2j for ; Wed, 13 Jan 2016 07:38:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7A1B2A49 for ; Wed, 13 Jan 2016 07:37:59 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 6024D1AE0A47; Wed, 13 Jan 2016 16:37:58 +0100 (CET) Date: Wed, 13 Jan 2016 16:38:06 +0100 (CET) Message-Id: <20160113.163806.285664913405156097.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> References: <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:38:02 -0000 Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> Andy Bierman writes: > >>>>>> > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > >>>>>>> randy_presuhn@mindspring.com> wrote: > >>>>>>> > >>>>>>>> Hi - > >>>>>>>> > >>>>>>>>> From: Martin Bjorklund > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > >>>>>>>>> To: netconf@ietf.org > >>>>>>>>> Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 > >>>>>>>> ... > >>>>>>>>> The problem: > >>>>>>>>> > >>>>>>>>> If module A is imported w/o revision by another module that the > >>>>>>>>> server implements, the server MUST somehow inform the client which > >>>>>>>>> revision of A is used. > >>>>>>>>> > >>>>>>>>> Solution 1: > >>>>>>>>> > >>>>>>>>> Reported implicitly - the server lists all revisions of A that it > >>>>>>>>> uses, and the most recent one is the one that is used to resolve > >>>>>>>>> import w/o revision. > >>>>>>>>> > >>>>>>>>> Solution 2: > >>>>>>>>> > >>>>>>>>> Reported explicitly - the server lists all revisions of A that it > >>>>>>>>> uses, and the the one that is used to resolve import w/o revision is > >>>>>>>>> marked by setting a leaf "default-revision". > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The current draft has 1 (but it needs to be clarified). Lada prefers > >>>>>>>>> 2. What do others think? > >>>>>>>> > >>>>>>>> Solution 1 is sufficient if the underlying implementations of all > >>>>>>>> the importing modules in a system strictly play by the current rules. > >>>>>>>> I think solution 2 would be *slightly* more robust, particularly in > >>>>>>>> systems supporting dynamic component updates or components from > >>>>>>>> multiple vendors. If we ever get to the realistic state of being > >>>>>>>> able to support multiple revisions of a particular kind of component > >>>>>>>> concurrently through a single server, both are inadequate. > >>>>>>>> > >>>>>>>> > >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to > >>>>>>> write complex client apps to analyze revision-date trees, so they > >>>>>>> can be applied to all the import-stmts without revision found nested > >>>>>>> in all the server YANG modules. > >>>>>> > >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all modules > >>>>>> used by the server will be listed in yang-library. > >>>>>> > >>>>>>> > >>>>>>> We also implemented solution 1 many years ago, and it > >>>>>>> has been working fine. Nobody has ever asked to > >>>>>>> use multiple revisions for the default import. > >>>>>> > >>>>>> Also, neither solution 1 nor 2 proposes this. There will be only one > >>>>>> revision available for imports without revision. > >>>>> > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be able > >>>>> to > >>>>> have a different default revision than the latest revision. > >>>> > >>>> Rephrase? Andy says "use multiple revisions for the default import", > >>>> not "different than latest". > >>>> > >>>>>> The real difference is that solution 1 may force an upgrade in a > >>>>>> module > >>>>>> that imports another module without revision as a side effect of > >>>>>> extending the data model, because the maximum revision can change. > >>>>> > >>>>> It is not an upgrade of the *module*, it is an upgrade of the > >>>>> instrumentation code for that module. > >>>> > >>>> Correct, and this is what the instrumentation code may not be prepared > >>>> for. I think it is quite important to be able to keep the default > >>>> import revision stable. The fact that nobody has asked for it yet > >>>> isn't IMO very relevant because most modules so far have only one > >>>> revision. > >>> > >>> Not true! Vendors have been writing and updating modules since 2010. > >> > >> These don't count - vendors writing both modules and instrumentation > >> are in control of everything. > > > > The point is that many vendors follow the upgrade rules, and they have > > been doing this for several years. > > See my response to Andy, upgrade rules really don't help server > implementors. > > > > >> The problem I am talking about is this: > >> I want to use a standard module M, but its author decided to import > >> module X with revision that is greater than the default revision I am > >> currently using in the data model. > > > > I think you meant "using in the instrumentation". > > No, I meant the complete and concrete data model in use by the server, > in which the decision about revisions of imported modules has to be > made. In my example, I would need to make the "bar" leaf a part of the > data model schema, and instrumentation as well, of course. > > > > >> So I have three options: > >> > >> 1. forget about module M, > >> 2. write a proprietary version of M so that it uses at most my default > >> revision of X, > >> 3. upgrade the instrumentation to use the higher revision of X. > > > > Correct. > > > > You may run into the same situation if you also want to add the > > instrumentation for module N, which also imports X w/o revision, and > > this instrumentation uses a higher version of X than your > > implementation of M. The 'default-revision' leaf doesn't solve this. > > It does solve this! As the server implementor I am in control of the > contents of yang-library, so I can bump "default-revision" any time, > and module M is unaffected because it imports X with revision. I messed up the module names. I meant to describe the situation you describe below. And the point is that the situation you think is problematic can happen with both solutions 1 and 2. > The only issue would be with other modules that import X without > revision: their instrumentation need to be upgraded at the same time, > but that's the deal if we want to have no more than one default > revision. /martin From nobody Wed Jan 13 07:51:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58FE1A8A9A for ; Wed, 13 Jan 2016 07:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fMZ1qtWXv6u for ; Wed, 13 Jan 2016 07:51:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1806A1A8A99 for ; Wed, 13 Jan 2016 07:51:21 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id A7A041818C3; Wed, 13 Jan 2016 16:51:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452700279; bh=ryb+ymHF/MqRtIFxJ7v9zxNo4gMXIDaPQacg0xzBsuo=; h=From:Date:To; b=pS/Tqq7dsqOG6tN7v08jAf6SBNu3tl7pw3C5sBRuv4xMaSiPma0HtYEDV4IAA3wry khQZ5mhqOwWAJpxE+eY5VM6vSGS8cnGKJryXxdScoESn3oBnBX7x84SfvdRGtvURRn bEURM/Hd1BIoU1SfgNfj8Odv1laYtNxdSFSsReyg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jan 2016 16:51:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 15:51:24 -0000 > On 13 Jan 2016, at 16:28, Andy Bierman wrote: >=20 > Hi, >=20 > I don't see the point of redoing the debate of the corner-case that = started > the entire "conformance drift" discussion several years ago. No need to redo anything. Y45 resolution declares rough consensus on = Y45-04, and I am fine with that. I thought you weren't, so that's why we started discussing alternatives. > In YANG 1.1, the designer can import the same module 67 times, > with 67 different revision dates. They can add new groupings instead = of > extending an existing one. YANG 1.1 has mechanisms to use > that allow the details to be properly reflected. >=20 > We have not seen any desire by vendors to break their own > client code or their customers client code, so even though > YANG 1.0 allows import-without-revision to cause drift, > vendors avoid doing this because it breaks deployed product. >=20 > IMO, a complex solution will not get implemented. > Any solution that requires any YANG modules to be parsed > to discover the imports is even worse than what we have in YANG 1.0. > We will just continue using the and ignore YANG 1.1 rules > if the solution is worse than what we have now. I think we are talking past each other. The solution I would support is: * List all revisions of all imported modules in yang-library. No YANG = modules need to be parsed. * For each module, tag one of its revisions as default - to be used for = all imports without revision. Is this so complex? Lada >=20 >=20 > Andy >=20 >=20 >=20 > On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka = wrote: >=20 > > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund = wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> Andy Bierman writes: > >>>>>> > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > >>>>>>> randy_presuhn@mindspring.com> wrote: > >>>>>>> > >>>>>>>> Hi - > >>>>>>>> > >>>>>>>>> From: Martin Bjorklund > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > >>>>>>>>> To: netconf@ietf.org > >>>>>>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03 > >>>>>>>> ... > >>>>>>>>> The problem: > >>>>>>>>> > >>>>>>>>> If module A is imported w/o revision by another module that = the > >>>>>>>>> server implements, the server MUST somehow inform the client = which > >>>>>>>>> revision of A is used. > >>>>>>>>> > >>>>>>>>> Solution 1: > >>>>>>>>> > >>>>>>>>> Reported implicitly - the server lists all revisions of A = that it > >>>>>>>>> uses, and the most recent one is the one that is used to = resolve > >>>>>>>>> import w/o revision. > >>>>>>>>> > >>>>>>>>> Solution 2: > >>>>>>>>> > >>>>>>>>> Reported explicitly - the server lists all revisions of A = that it > >>>>>>>>> uses, and the the one that is used to resolve import w/o = revision is > >>>>>>>>> marked by setting a leaf "default-revision". > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The current draft has 1 (but it needs to be clarified). = Lada prefers > >>>>>>>>> 2. What do others think? > >>>>>>>> > >>>>>>>> Solution 1 is sufficient if the underlying implementations of = all > >>>>>>>> the importing modules in a system strictly play by the = current rules. > >>>>>>>> I think solution 2 would be *slightly* more robust, = particularly in > >>>>>>>> systems supporting dynamic component updates or components = from > >>>>>>>> multiple vendors. If we ever get to the realistic state of = being > >>>>>>>> able to support multiple revisions of a particular kind of = component > >>>>>>>> concurrently through a single server, both are inadequate. > >>>>>>>> > >>>>>>>> > >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to > >>>>>>> write complex client apps to analyze revision-date trees, so = they > >>>>>>> can be applied to all the import-stmts without revision found = nested > >>>>>>> in all the server YANG modules. > >>>>>> > >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all = modules > >>>>>> used by the server will be listed in yang-library. > >>>>>> > >>>>>>> > >>>>>>> We also implemented solution 1 many years ago, and it > >>>>>>> has been working fine. Nobody has ever asked to > >>>>>>> use multiple revisions for the default import. > >>>>>> > >>>>>> Also, neither solution 1 nor 2 proposes this. There will be = only one > >>>>>> revision available for imports without revision. > >>>>> > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be = able > >>>>> to > >>>>> have a different default revision than the latest revision. > >>>> > >>>> Rephrase? Andy says "use multiple revisions for the default = import", > >>>> not "different than latest". > >>>> > >>>>>> The real difference is that solution 1 may force an upgrade in = a > >>>>>> module > >>>>>> that imports another module without revision as a side effect = of > >>>>>> extending the data model, because the maximum revision can = change. > >>>>> > >>>>> It is not an upgrade of the *module*, it is an upgrade of the > >>>>> instrumentation code for that module. > >>>> > >>>> Correct, and this is what the instrumentation code may not be = prepared > >>>> for. I think it is quite important to be able to keep the default > >>>> import revision stable. The fact that nobody has asked for it yet > >>>> isn't IMO very relevant because most modules so far have only one > >>>> revision. > >>> > >>> Not true! Vendors have been writing and updating modules since = 2010. > >> > >> These don't count - vendors writing both modules and = instrumentation > >> are in control of everything. > > > > The point is that many vendors follow the upgrade rules, and they = have > > been doing this for several years. >=20 > See my response to Andy, upgrade rules really don't help server = implementors. >=20 > > > >> The problem I am talking about is this: > >> I want to use a standard module M, but its author decided to import > >> module X with revision that is greater than the default revision I = am > >> currently using in the data model. > > > > I think you meant "using in the instrumentation". >=20 > No, I meant the complete and concrete data model in use by the server, = in which the decision about revisions of imported modules has to be = made. In my example, I would need to make the "bar" leaf a part of the = data model schema, and instrumentation as well, of course. >=20 > > > >> So I have three options: > >> > >> 1. forget about module M, > >> 2. write a proprietary version of M so that it uses at most my = default > >> revision of X, > >> 3. upgrade the instrumentation to use the higher revision of X. > > > > Correct. > > > > You may run into the same situation if you also want to add the > > instrumentation for module N, which also imports X w/o revision, and > > this instrumentation uses a higher version of X than your > > implementation of M. The 'default-revision' leaf doesn't solve = this. >=20 > It does solve this! As the server implementor I am in control of the = contents of yang-library, so I can bump "default-revision" any time, and = module M is unaffected because it imports X with revision. >=20 > The only issue would be with other modules that import X without = revision: their instrumentation need to be upgraded at the same time, = but that's the deal if we want to have no more than one default = revision. >=20 > Lada >=20 > > > > > > Our experience, and Andy's experience, is that doing (3) has not = been > > an issue in implementations. > > > > > > /martin >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 08:19:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805B61A914C for ; Wed, 13 Jan 2016 08:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGgWm90W7RC8 for ; Wed, 13 Jan 2016 08:19:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25471A8AF4 for ; Wed, 13 Jan 2016 08:19:19 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id 24A1C180B49; Wed, 13 Jan 2016 17:19:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452701958; bh=EL4ySAYx/AMU+WFXbsyqWWxIKL6Vm/a/YKBtN60KlZI=; h=From:Date:To; b=c3MwJ6K/C1gzVxC5JM2CyNZ7WFN/0AgwBTaQ3L/f6cpm80RICtCQO22DU+vNRI2la oSd6ILOAARUAQySY0T8jvTrJUBQvixaLsivvS8u0CJ2zQ9JGUZCbyVde8B+a353a9b TgzHLyq8UlKrEz8GH59xSq/S8NKO0CT+fgZoNcyc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160113.163806.285664913405156097.mbj@tail-f.com> Date: Wed, 13 Jan 2016 17:19:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> <20160113.163806.285664913405156097.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:19:22 -0000 > On 13 Jan 2016, at 16:38, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Andy Bierman writes: >>>>>>>>=20 >>>>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < >>>>>>>>> randy_presuhn@mindspring.com> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi - >>>>>>>>>>=20 >>>>>>>>>>> From: Martin Bjorklund >>>>>>>>>>> Sent: Jan 12, 2016 3:53 AM >>>>>>>>>>> To: netconf@ietf.org >>>>>>>>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03 >>>>>>>>>> ... >>>>>>>>>>> The problem: >>>>>>>>>>>=20 >>>>>>>>>>> If module A is imported w/o revision by another module that = the >>>>>>>>>>> server implements, the server MUST somehow inform the client = which >>>>>>>>>>> revision of A is used. >>>>>>>>>>>=20 >>>>>>>>>>> Solution 1: >>>>>>>>>>>=20 >>>>>>>>>>> Reported implicitly - the server lists all revisions of A = that it >>>>>>>>>>> uses, and the most recent one is the one that is used to = resolve >>>>>>>>>>> import w/o revision. >>>>>>>>>>>=20 >>>>>>>>>>> Solution 2: >>>>>>>>>>>=20 >>>>>>>>>>> Reported explicitly - the server lists all revisions of A = that it >>>>>>>>>>> uses, and the the one that is used to resolve import w/o = revision is >>>>>>>>>>> marked by setting a leaf "default-revision". >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The current draft has 1 (but it needs to be clarified). = Lada prefers >>>>>>>>>>> 2. What do others think? >>>>>>>>>>=20 >>>>>>>>>> Solution 1 is sufficient if the underlying implementations of = all >>>>>>>>>> the importing modules in a system strictly play by the = current rules. >>>>>>>>>> I think solution 2 would be *slightly* more robust, = particularly in >>>>>>>>>> systems supporting dynamic component updates or components = from >>>>>>>>>> multiple vendors. If we ever get to the realistic state of = being >>>>>>>>>> able to support multiple revisions of a particular kind of = component >>>>>>>>>> concurrently through a single server, both are inadequate. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to >>>>>>>>> write complex client apps to analyze revision-date trees, so = they >>>>>>>>> can be applied to all the import-stmts without revision found = nested >>>>>>>>> in all the server YANG modules. >>>>>>>>=20 >>>>>>>> Solutions 1 and 2 don't differ on this: all revisions of all = modules >>>>>>>> used by the server will be listed in yang-library. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> We also implemented solution 1 many years ago, and it >>>>>>>>> has been working fine. Nobody has ever asked to >>>>>>>>> use multiple revisions for the default import. >>>>>>>>=20 >>>>>>>> Also, neither solution 1 nor 2 proposes this. There will be = only one >>>>>>>> revision available for imports without revision. >>>>>>>=20 >>>>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be = able >>>>>>> to >>>>>>> have a different default revision than the latest revision. >>>>>>=20 >>>>>> Rephrase? Andy says "use multiple revisions for the default = import", >>>>>> not "different than latest". >>>>>>=20 >>>>>>>> The real difference is that solution 1 may force an upgrade in = a >>>>>>>> module >>>>>>>> that imports another module without revision as a side effect = of >>>>>>>> extending the data model, because the maximum revision can = change. >>>>>>>=20 >>>>>>> It is not an upgrade of the *module*, it is an upgrade of the >>>>>>> instrumentation code for that module. >>>>>>=20 >>>>>> Correct, and this is what the instrumentation code may not be = prepared >>>>>> for. I think it is quite important to be able to keep the default >>>>>> import revision stable. The fact that nobody has asked for it yet >>>>>> isn't IMO very relevant because most modules so far have only one >>>>>> revision. >>>>>=20 >>>>> Not true! Vendors have been writing and updating modules since = 2010. >>>>=20 >>>> These don't count - vendors writing both modules and = instrumentation >>>> are in control of everything. >>>=20 >>> The point is that many vendors follow the upgrade rules, and they = have >>> been doing this for several years. >>=20 >> See my response to Andy, upgrade rules really don't help server >> implementors. >>=20 >>>=20 >>>> The problem I am talking about is this: >>>> I want to use a standard module M, but its author decided to import >>>> module X with revision that is greater than the default revision I = am >>>> currently using in the data model. >>>=20 >>> I think you meant "using in the instrumentation". >>=20 >> No, I meant the complete and concrete data model in use by the = server, >> in which the decision about revisions of imported modules has to be >> made. In my example, I would need to make the "bar" leaf a part of = the >> data model schema, and instrumentation as well, of course. >>=20 >>>=20 >>>> So I have three options: >>>>=20 >>>> 1. forget about module M, >>>> 2. write a proprietary version of M so that it uses at most my = default >>>> revision of X, >>>> 3. upgrade the instrumentation to use the higher revision of X. >>>=20 >>> Correct. >>>=20 >>> You may run into the same situation if you also want to add the >>> instrumentation for module N, which also imports X w/o revision, and >>> this instrumentation uses a higher version of X than your >>> implementation of M. The 'default-revision' leaf doesn't solve = this. >>=20 >> It does solve this! As the server implementor I am in control of the >> contents of yang-library, so I can bump "default-revision" any time, >> and module M is unaffected because it imports X with revision. >=20 > I messed up the module names. I meant to describe the situation you > describe below. And the point is that the situation you think is > problematic can happen with both solutions 1 and 2. OK, let's see if we agree: - In both 1 and 2, we have only one default revision for each imported = module, so necessarily modules that import it without revision need to = be upgraded (i.e. their instrumentation) at the same time. - Solution 1 may force module upgrades (as side effects of new imports = with revision) in cases where solution 2 is able to avoid them. - Solution 1 has no advantage over 2 except that some existing = implementations already use it.=20 Lada >=20 >> The only issue would be with other modules that import X without >> revision: their instrumentation need to be upgraded at the same time, >> but that's the deal if we want to have no more than one default >> revision. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 08:24:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FA51A8A0F for ; Wed, 13 Jan 2016 08:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK9GyTMLjJM6 for ; Wed, 13 Jan 2016 08:24:44 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65B21A8A06 for ; Wed, 13 Jan 2016 08:24:43 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id c192so258858733lfe.2 for ; Wed, 13 Jan 2016 08:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lfpPIW3ecZCSR18v3k/j3a9wT/2P9EwHM2qOp/O9ix0=; b=mXn9ABS+vVnjJtC4FKSJDkRXdWAqidy0sf2ZYU7bH0hSyUAzKwT9PDl2e/rCieLzKb xNc+LrsoK/xZOSVkrq/JjP47dBBG9mA6hTXY5jaheQQODMgOeXVs8kG6bosYG0hGFNoQ hjgBoVQOdaBvm80RAyCdkjBXX/xBwFGA9UmySI+ZZ8+W2G6xVHqwnlxXcgL7Lq3pB76e Jh3EFoqr5FfW4zoyd2xNalUMFdnZ+LHH8WXnYU6YBuOxOgA6JsUix4M4NTO0PoPe/Hz7 FRKn75A9aDP2GkT6PdylrS9+OoEliG5CdqJUxFfjXJPaH1M/R0fX1fMIzpiHSfXXdJG9 +2aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lfpPIW3ecZCSR18v3k/j3a9wT/2P9EwHM2qOp/O9ix0=; b=EZFYYv+a4EJc/RByXZYiijogJu5TqFiBDRSL/i2yV/Sjq5UABM74pttg1EdediKARJ erOxpco2UhK+J7SUwIWTlRGvJBOG+Y/15FWF7u1x5Rx+mM/7C8MoWsIVIzhmPb7OOjo7 T//Pk6M0VcA+E1Ab3lnYSc4DUdl9IeC36nIZGHSzKTOTvwuU3DuReJNYGfNOkvi1zbai uD/9dhX01TqtLUAR+FG86rXtc20PJeao3Dh+DWo2qKYhY8N/uJqOhvqjQMSDpGsBIfTX mOY9OQHJFEbQsxtY8jeqOsMtXBWUrJTUfpzwGlaq8Rxa+EgBaHHd/Yuv238V0dwWPdyR wH/w== X-Gm-Message-State: ALoCoQn4hRcqCTe/jezR6FypmtvgbENsZunB9C13cKYIym+tB+IRSaoW+4aIHHx8TzRkE5ozrwajVCuagLoxlJe71OXFR7a74A== MIME-Version: 1.0 X-Received: by 10.25.85.20 with SMTP id j20mr42953464lfb.131.1452702281697; Wed, 13 Jan 2016 08:24:41 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 13 Jan 2016 08:24:41 -0800 (PST) In-Reply-To: References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> Date: Wed, 13 Jan 2016 08:24:41 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1141c532779fa70529399b3b Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:24:47 -0000 --001a1141c532779fa70529399b3b Content-Type: text/plain; charset=UTF-8 On Wed, Jan 13, 2016 at 7:51 AM, Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 16:28, Andy Bierman wrote: > > > > Hi, > > > > I don't see the point of redoing the debate of the corner-case that > started > > the entire "conformance drift" discussion several years ago. > > No need to redo anything. Y45 resolution declares rough consensus on > Y45-04, and I am fine with that. > I thought you weren't, so that's why we started discussing alternatives. > > > In YANG 1.1, the designer can import the same module 67 times, > > with 67 different revision dates. They can add new groupings instead of > > extending an existing one. YANG 1.1 has mechanisms to use > > that allow the details to be properly reflected. > > > > We have not seen any desire by vendors to break their own > > client code or their customers client code, so even though > > YANG 1.0 allows import-without-revision to cause drift, > > vendors avoid doing this because it breaks deployed product. > > > > IMO, a complex solution will not get implemented. > > Any solution that requires any YANG modules to be parsed > > to discover the imports is even worse than what we have in YANG 1.0. > > We will just continue using the and ignore YANG 1.1 rules > > if the solution is worse than what we have now. > > I think we are talking past each other. The solution I would support is: > > * List all revisions of all imported modules in yang-library. No YANG > modules need to be parsed. > > * For each module, tag one of its revisions as default - to be used for > all imports without revision. > > Is this so complex? > > Do you have real examples where the latest module implemented by the server cannot be the default? The extra complexity is incremental, but it is for a feature nobody has ever wanted before, so please explain why it is needed. > Lada > > Andy > > > > > > Andy > > > > > > > > On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka wrote: > > > > > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: > > > > > > Ladislav Lhotka wrote: > > >> > > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: > > >>> > > >>> Ladislav Lhotka wrote: > > >>>> > > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund wrote: > > >>>>> > > >>>>> Ladislav Lhotka wrote: > > >>>>>> Andy Bierman writes: > > >>>>>> > > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > > >>>>>>> randy_presuhn@mindspring.com> wrote: > > >>>>>>> > > >>>>>>>> Hi - > > >>>>>>>> > > >>>>>>>>> From: Martin Bjorklund > > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > > >>>>>>>>> To: netconf@ietf.org > > >>>>>>>>> Subject: Re: [Netconf] review of > draft-ietf-netconf-yang-library-03 > > >>>>>>>> ... > > >>>>>>>>> The problem: > > >>>>>>>>> > > >>>>>>>>> If module A is imported w/o revision by another module that the > > >>>>>>>>> server implements, the server MUST somehow inform the client > which > > >>>>>>>>> revision of A is used. > > >>>>>>>>> > > >>>>>>>>> Solution 1: > > >>>>>>>>> > > >>>>>>>>> Reported implicitly - the server lists all revisions of A that > it > > >>>>>>>>> uses, and the most recent one is the one that is used to > resolve > > >>>>>>>>> import w/o revision. > > >>>>>>>>> > > >>>>>>>>> Solution 2: > > >>>>>>>>> > > >>>>>>>>> Reported explicitly - the server lists all revisions of A that > it > > >>>>>>>>> uses, and the the one that is used to resolve import w/o > revision is > > >>>>>>>>> marked by setting a leaf "default-revision". > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> The current draft has 1 (but it needs to be clarified). Lada > prefers > > >>>>>>>>> 2. What do others think? > > >>>>>>>> > > >>>>>>>> Solution 1 is sufficient if the underlying implementations of > all > > >>>>>>>> the importing modules in a system strictly play by the current > rules. > > >>>>>>>> I think solution 2 would be *slightly* more robust, > particularly in > > >>>>>>>> systems supporting dynamic component updates or components from > > >>>>>>>> multiple vendors. If we ever get to the realistic state of > being > > >>>>>>>> able to support multiple revisions of a particular kind of > component > > >>>>>>>> concurrently through a single server, both are inadequate. > > >>>>>>>> > > >>>>>>>> > > >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to > > >>>>>>> write complex client apps to analyze revision-date trees, so they > > >>>>>>> can be applied to all the import-stmts without revision found > nested > > >>>>>>> in all the server YANG modules. > > >>>>>> > > >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all > modules > > >>>>>> used by the server will be listed in yang-library. > > >>>>>> > > >>>>>>> > > >>>>>>> We also implemented solution 1 many years ago, and it > > >>>>>>> has been working fine. Nobody has ever asked to > > >>>>>>> use multiple revisions for the default import. > > >>>>>> > > >>>>>> Also, neither solution 1 nor 2 proposes this. There will be only > one > > >>>>>> revision available for imports without revision. > > >>>>> > > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be > able > > >>>>> to > > >>>>> have a different default revision than the latest revision. > > >>>> > > >>>> Rephrase? Andy says "use multiple revisions for the default import", > > >>>> not "different than latest". > > >>>> > > >>>>>> The real difference is that solution 1 may force an upgrade in a > > >>>>>> module > > >>>>>> that imports another module without revision as a side effect of > > >>>>>> extending the data model, because the maximum revision can change. > > >>>>> > > >>>>> It is not an upgrade of the *module*, it is an upgrade of the > > >>>>> instrumentation code for that module. > > >>>> > > >>>> Correct, and this is what the instrumentation code may not be > prepared > > >>>> for. I think it is quite important to be able to keep the default > > >>>> import revision stable. The fact that nobody has asked for it yet > > >>>> isn't IMO very relevant because most modules so far have only one > > >>>> revision. > > >>> > > >>> Not true! Vendors have been writing and updating modules since 2010. > > >> > > >> These don't count - vendors writing both modules and instrumentation > > >> are in control of everything. > > > > > > The point is that many vendors follow the upgrade rules, and they have > > > been doing this for several years. > > > > See my response to Andy, upgrade rules really don't help server > implementors. > > > > > > > >> The problem I am talking about is this: > > >> I want to use a standard module M, but its author decided to import > > >> module X with revision that is greater than the default revision I am > > >> currently using in the data model. > > > > > > I think you meant "using in the instrumentation". > > > > No, I meant the complete and concrete data model in use by the server, > in which the decision about revisions of imported modules has to be made. > In my example, I would need to make the "bar" leaf a part of the data model > schema, and instrumentation as well, of course. > > > > > > > >> So I have three options: > > >> > > >> 1. forget about module M, > > >> 2. write a proprietary version of M so that it uses at most my default > > >> revision of X, > > >> 3. upgrade the instrumentation to use the higher revision of X. > > > > > > Correct. > > > > > > You may run into the same situation if you also want to add the > > > instrumentation for module N, which also imports X w/o revision, and > > > this instrumentation uses a higher version of X than your > > > implementation of M. The 'default-revision' leaf doesn't solve this. > > > > It does solve this! As the server implementor I am in control of the > contents of yang-library, so I can bump "default-revision" any time, and > module M is unaffected because it imports X with revision. > > > > The only issue would be with other modules that import X without > revision: their instrumentation need to be upgraded at the same time, but > that's the deal if we want to have no more than one default revision. > > > > Lada > > > > > > > > > > > Our experience, and Andy's experience, is that doing (3) has not been > > > an issue in implementations. > > > > > > > > > /martin > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1141c532779fa70529399b3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 13, 2016 at 7:51 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Jan 2016, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> I don't see the point of redoing the debate of the corner-case tha= t started
> the entire "conformance drift" discussion several years ago.=

No need to redo anything. Y45 resolution declares rough consensus on Y45-04= , and I am fine with that.
I thought you weren't, so that's why we started discussing alternat= ives.

> In YANG 1.1, the designer can import the same module 67 times,
> with 67 different revision dates.=C2=A0 They can add new groupings ins= tead of
> extending an existing one.=C2=A0 YANG 1.1 has mechanisms to use
> that allow the details to be properly reflected.
>
> We have not seen any desire by vendors to break their own
> client code or their customers client code, so even though
> YANG 1.0 allows import-without-revision to cause drift,
> vendors avoid doing this because it breaks deployed product.
>
> IMO,=C2=A0 a complex solution will not get implemented.
> Any solution that requires any YANG modules to be parsed
> to discover the imports is even worse than what we have in YANG 1.0. > We will just continue using the <hello> and ignore YANG 1.1 rule= s
> if the solution is worse than what we have now.

I think we are talking past each other. The solution I would support is:
* List all revisions of all imported modules in yang-library. No YANG modul= es need to be parsed.

* For each module, tag one of its revisions as default - to be used for all= imports without revision.

Is this so complex?




Do you h= ave real examples where the latest module implemented
by the serv= er cannot be the default?

The extra complexity is = incremental, but it is for a feature
nobody has ever wanted befor= e, so please explain why
it is needed.

= =C2=A0
Lada


Andy
=C2=A0
>
>
> Andy
>
>
>
> On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 13 Jan 2016, at 12:46, Martin Bjorklund <mbj@tail-f.com> wrote:
> >
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> >>
> >>> On 13 Jan 2016, at 12:04, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>>
> >>> Ladislav Lhotka <lhot= ka@nic.cz> wrote:
> >>>>
> >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>>>>
> >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>>>>> Andy Bierman <andy@yumaworks.com> writes:
> >>>>>>
> >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy P= resuhn <
> >>>>>>> randy_presuhn@mindspring.com> wrote:
> >>>>>>>
> >>>>>>>> Hi -
> >>>>>>>>
> >>>>>>>>> From: Martin Bjorklund <mbj@tail-f.com>
> >>>>>>>>> Sent: Jan 12, 2016 3:53 AM
> >>>>>>>>> To: netconf@ietf.org
> >>>>>>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03
> >>>>>>>> ...
> >>>>>>>>> The problem:
> >>>>>>>>>
> >>>>>>>>> If module A is imported w/o revis= ion by another module that the
> >>>>>>>>> server implements, the server MUS= T somehow inform the client which
> >>>>>>>>> revision of A is used.
> >>>>>>>>>
> >>>>>>>>> Solution 1:
> >>>>>>>>>
> >>>>>>>>> Reported implicitly - the server = lists all revisions of A that it
> >>>>>>>>> uses, and the most recent one is = the one that is used to resolve
> >>>>>>>>> import w/o revision.
> >>>>>>>>>
> >>>>>>>>> Solution 2:
> >>>>>>>>>
> >>>>>>>>> Reported explicitly - the server = lists all revisions of A that it
> >>>>>>>>> uses, and the the one that is use= d to resolve import w/o revision is
> >>>>>>>>> marked by setting a leaf "de= fault-revision".
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The current draft has 1 (but it n= eeds to be clarified).=C2=A0 Lada prefers
> >>>>>>>>> 2.=C2=A0 What do others think? > >>>>>>>>
> >>>>>>>> Solution 1 is sufficient if the under= lying implementations of all
> >>>>>>>> the importing modules in a system str= ictly play by the current rules.
> >>>>>>>> I think solution 2 would be *slightly= * more robust, particularly in
> >>>>>>>> systems supporting dynamic component = updates or components from
> >>>>>>>> multiple vendors.=C2=A0 If we ever ge= t to the realistic state of being
> >>>>>>>> able to support multiple revisions of= a particular kind of component
> >>>>>>>> concurrently through a single server,= both are inadequate.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> IMO, solution 1 is appropriate because IM= O nobody is going to
> >>>>>>> write complex client apps to analyze revi= sion-date trees, so they
> >>>>>>> can be applied to all the import-stmts wi= thout revision found nested
> >>>>>>> in all the server YANG modules.
> >>>>>>
> >>>>>> Solutions 1 and 2 don't differ on this: a= ll revisions of all modules
> >>>>>> used by the server will be listed in yang-lib= rary.
> >>>>>>
> >>>>>>>
> >>>>>>> We also implemented solution 1 many years= ago, and it
> >>>>>>> has been working fine.=C2=A0 Nobody has e= ver asked to
> >>>>>>> use multiple revisions for the default im= port.
> >>>>>>
> >>>>>> Also, neither solution 1 nor 2 proposes this.= There will be only one
> >>>>>> revision available for imports without revisi= on.
> >>>>>
> >>>>> Let me rephrase Andy's statement: Nobody has = ever asked us to be able
> >>>>> to
> >>>>> have a different default revision than the latest= revision.
> >>>>
> >>>> Rephrase? Andy says "use multiple revisions for = the default import",
> >>>> not "different than latest".
> >>>>
> >>>>>> The real difference is that solution 1 may fo= rce an upgrade in a
> >>>>>> module
> >>>>>> that imports another module without revision = as a side effect of
> >>>>>> extending the data model, because the maximum= revision can change.
> >>>>>
> >>>>> It is not an upgrade of the *module*, it is an up= grade of the
> >>>>> instrumentation code for that module.
> >>>>
> >>>> Correct, and this is what the instrumentation code ma= y not be prepared
> >>>> for. I think it is quite important to be able to keep= the default
> >>>> import revision stable. The fact that nobody has aske= d for it yet
> >>>> isn't IMO very relevant because most modules so f= ar have only one
> >>>> revision.
> >>>
> >>> Not true!=C2=A0 Vendors have been writing and updating mo= dules since 2010.
> >>
> >> These don't count - vendors writing both modules and inst= rumentation
> >> are in control of everything.
> >
> > The point is that many vendors follow the upgrade rules, and they= have
> > been doing this for several years.
>
> See my response to Andy, upgrade rules really don't help server im= plementors.
>
> >
> >> The problem I am talking about is this:
> >> I want to use a standard module M, but its author decided to = import
> >> module X with revision that is greater than the default revis= ion I am
> >> currently using in the data model.
> >
> > I think you meant "using in the instrumentation".
>
> No, I meant the complete and concrete data model in use by the server,= in which the decision about revisions of imported modules has to be made. = In my example, I would need to make the "bar" leaf a part of the = data model schema, and instrumentation as well, of course.
>
> >
> >> So I have three options:
> >>
> >> 1. forget about module M,
> >> 2. write a proprietary version of M so that it uses at most m= y default
> >> revision of X,
> >> 3. upgrade the instrumentation to use the higher revision of = X.
> >
> > Correct.
> >
> > You may run into the same situation if you also want to add the > > instrumentation for module N, which also imports X w/o revision, = and
> > this instrumentation uses a higher version of X than your
> > implementation of M.=C2=A0 The 'default-revision' leaf do= esn't solve this.
>
> It does solve this! As the server implementor I am in control of the c= ontents of yang-library, so I can bump "default-revision" any tim= e, and module M is unaffected because it imports X with revision.
>
> The only issue would be with other modules that import X without revis= ion: their instrumentation need to be upgraded at the same time, but that&#= 39;s the deal if we want to have no more than one default revision.
>
> Lada
>
> >
> >
> > Our experience, and Andy's experience, is that doing (3) has = not been
> > an issue in implementations.
> >
> >
> > /martin
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--001a1141c532779fa70529399b3b-- From nobody Wed Jan 13 08:41:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005581B2F02 for ; Wed, 13 Jan 2016 08:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7667KGzAo-T for ; Wed, 13 Jan 2016 08:41:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3DD1B2F05 for ; Wed, 13 Jan 2016 08:41:45 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id 51E4918174F; Wed, 13 Jan 2016 17:41:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452703304; bh=zMIthPMIvFwGl9vOp3yE4oL/fFjpFdzr1kyS4LyixcE=; h=From:Date:To; b=jg1gymC8XRmKBwMah2a0jVVRsvasK6mhHmqzpQRc8YDv4PG+LPnRBc3stTqlZB3qG ZByZseqHS18nTnHRP+DGZ8ybSzi1nOtOYoJfkx9RCcWir7eiyhQXBWqTT3OTLCtiwG iwL97mmxuEwh6Rfe+ou1EfZ2Fcj/SdqTuNLEQJ2U= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jan 2016 17:41:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 16:41:48 -0000 > On 13 Jan 2016, at 17:24, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jan 13, 2016 at 7:51 AM, Ladislav Lhotka = wrote: >=20 > > On 13 Jan 2016, at 16:28, Andy Bierman wrote: > > > > Hi, > > > > I don't see the point of redoing the debate of the corner-case that = started > > the entire "conformance drift" discussion several years ago. >=20 > No need to redo anything. Y45 resolution declares rough consensus on = Y45-04, and I am fine with that. > I thought you weren't, so that's why we started discussing = alternatives. >=20 > > In YANG 1.1, the designer can import the same module 67 times, > > with 67 different revision dates. They can add new groupings = instead of > > extending an existing one. YANG 1.1 has mechanisms to use > > that allow the details to be properly reflected. > > > > We have not seen any desire by vendors to break their own > > client code or their customers client code, so even though > > YANG 1.0 allows import-without-revision to cause drift, > > vendors avoid doing this because it breaks deployed product. > > > > IMO, a complex solution will not get implemented. > > Any solution that requires any YANG modules to be parsed > > to discover the imports is even worse than what we have in YANG 1.0. > > We will just continue using the and ignore YANG 1.1 rules > > if the solution is worse than what we have now. >=20 > I think we are talking past each other. The solution I would support = is: >=20 > * List all revisions of all imported modules in yang-library. No YANG = modules need to be parsed. >=20 > * For each module, tag one of its revisions as default - to be used = for all imports without revision. >=20 > Is this so complex? >=20 >=20 >=20 >=20 > Do you have real examples where the latest module implemented > by the server cannot be the default? No. >=20 > The extra complexity is incremental, but it is for a feature > nobody has ever wanted before, so please explain why > it is needed. When somebody starts from a clean slate, then IMO the complexity of = implementing either 1 or 2 should be comparable. In fact, 1 has to = determine the maximum revision for each imported module, so arguably it = has to do more work. Solution 1 relies on a CLR written in the spec while 2 provides the = information about the default revision explicitly in yang-library data. Lada >=20 > =20 > Lada >=20 >=20 > Andy > =20 > > > > > > Andy > > > > > > > > On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka = wrote: > > > > > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: > > > > > > Ladislav Lhotka wrote: > > >> > > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund = wrote: > > >>> > > >>> Ladislav Lhotka wrote: > > >>>> > > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund = wrote: > > >>>>> > > >>>>> Ladislav Lhotka wrote: > > >>>>>> Andy Bierman writes: > > >>>>>> > > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > > >>>>>>> randy_presuhn@mindspring.com> wrote: > > >>>>>>> > > >>>>>>>> Hi - > > >>>>>>>> > > >>>>>>>>> From: Martin Bjorklund > > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > > >>>>>>>>> To: netconf@ietf.org > > >>>>>>>>> Subject: Re: [Netconf] review of = draft-ietf-netconf-yang-library-03 > > >>>>>>>> ... > > >>>>>>>>> The problem: > > >>>>>>>>> > > >>>>>>>>> If module A is imported w/o revision by another module = that the > > >>>>>>>>> server implements, the server MUST somehow inform the = client which > > >>>>>>>>> revision of A is used. > > >>>>>>>>> > > >>>>>>>>> Solution 1: > > >>>>>>>>> > > >>>>>>>>> Reported implicitly - the server lists all revisions of A = that it > > >>>>>>>>> uses, and the most recent one is the one that is used to = resolve > > >>>>>>>>> import w/o revision. > > >>>>>>>>> > > >>>>>>>>> Solution 2: > > >>>>>>>>> > > >>>>>>>>> Reported explicitly - the server lists all revisions of A = that it > > >>>>>>>>> uses, and the the one that is used to resolve import w/o = revision is > > >>>>>>>>> marked by setting a leaf "default-revision". > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> The current draft has 1 (but it needs to be clarified). = Lada prefers > > >>>>>>>>> 2. What do others think? > > >>>>>>>> > > >>>>>>>> Solution 1 is sufficient if the underlying implementations = of all > > >>>>>>>> the importing modules in a system strictly play by the = current rules. > > >>>>>>>> I think solution 2 would be *slightly* more robust, = particularly in > > >>>>>>>> systems supporting dynamic component updates or components = from > > >>>>>>>> multiple vendors. If we ever get to the realistic state of = being > > >>>>>>>> able to support multiple revisions of a particular kind of = component > > >>>>>>>> concurrently through a single server, both are inadequate. > > >>>>>>>> > > >>>>>>>> > > >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going = to > > >>>>>>> write complex client apps to analyze revision-date trees, so = they > > >>>>>>> can be applied to all the import-stmts without revision = found nested > > >>>>>>> in all the server YANG modules. > > >>>>>> > > >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all = modules > > >>>>>> used by the server will be listed in yang-library. > > >>>>>> > > >>>>>>> > > >>>>>>> We also implemented solution 1 many years ago, and it > > >>>>>>> has been working fine. Nobody has ever asked to > > >>>>>>> use multiple revisions for the default import. > > >>>>>> > > >>>>>> Also, neither solution 1 nor 2 proposes this. There will be = only one > > >>>>>> revision available for imports without revision. > > >>>>> > > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to = be able > > >>>>> to > > >>>>> have a different default revision than the latest revision. > > >>>> > > >>>> Rephrase? Andy says "use multiple revisions for the default = import", > > >>>> not "different than latest". > > >>>> > > >>>>>> The real difference is that solution 1 may force an upgrade = in a > > >>>>>> module > > >>>>>> that imports another module without revision as a side effect = of > > >>>>>> extending the data model, because the maximum revision can = change. > > >>>>> > > >>>>> It is not an upgrade of the *module*, it is an upgrade of the > > >>>>> instrumentation code for that module. > > >>>> > > >>>> Correct, and this is what the instrumentation code may not be = prepared > > >>>> for. I think it is quite important to be able to keep the = default > > >>>> import revision stable. The fact that nobody has asked for it = yet > > >>>> isn't IMO very relevant because most modules so far have only = one > > >>>> revision. > > >>> > > >>> Not true! Vendors have been writing and updating modules since = 2010. > > >> > > >> These don't count - vendors writing both modules and = instrumentation > > >> are in control of everything. > > > > > > The point is that many vendors follow the upgrade rules, and they = have > > > been doing this for several years. > > > > See my response to Andy, upgrade rules really don't help server = implementors. > > > > > > > >> The problem I am talking about is this: > > >> I want to use a standard module M, but its author decided to = import > > >> module X with revision that is greater than the default revision = I am > > >> currently using in the data model. > > > > > > I think you meant "using in the instrumentation". > > > > No, I meant the complete and concrete data model in use by the = server, in which the decision about revisions of imported modules has to = be made. In my example, I would need to make the "bar" leaf a part of = the data model schema, and instrumentation as well, of course. > > > > > > > >> So I have three options: > > >> > > >> 1. forget about module M, > > >> 2. write a proprietary version of M so that it uses at most my = default > > >> revision of X, > > >> 3. upgrade the instrumentation to use the higher revision of X. > > > > > > Correct. > > > > > > You may run into the same situation if you also want to add the > > > instrumentation for module N, which also imports X w/o revision, = and > > > this instrumentation uses a higher version of X than your > > > implementation of M. The 'default-revision' leaf doesn't solve = this. > > > > It does solve this! As the server implementor I am in control of the = contents of yang-library, so I can bump "default-revision" any time, and = module M is unaffected because it imports X with revision. > > > > The only issue would be with other modules that import X without = revision: their instrumentation need to be upgraded at the same time, = but that's the deal if we want to have no more than one default = revision. > > > > Lada > > > > > > > > > > > Our experience, and Andy's experience, is that doing (3) has not = been > > > an issue in implementations. > > > > > > > > > /martin > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 09:02:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4544B1B2AF6 for ; Wed, 13 Jan 2016 09:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjsrxJ3ETh_b for ; Wed, 13 Jan 2016 09:02:11 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2401B2F49 for ; Wed, 13 Jan 2016 09:02:11 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id m198so112119003lfm.0 for ; Wed, 13 Jan 2016 09:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pu6hNrvrvBLUM5mZQjI/mec3hp6/vRsOvhTA0TYlAsE=; b=My+WIt26AfcP1A9u+FDvxuzYyJ1BqHul8W036LRup74MrhrWUf30OmmMYRtUvvtoSJ bz4DHen4L1WbaP/yAPTgPFUs+iBKrfJpw7XXSsXBDWKT6Q/9AOywgKE+ulietor4k8/I OhQNz17Bc6fWLB4pvgTFxJ+EHVUjzlrPTMf0ZSFEq2gI/dyUO0TNsz21qm75oLPcrdoK nNhYkAH60ojT33uXCMLz2YZg46OgAUZQsv/RLJaWe74ikd3VP/HnvyGOYUvO6oGiUk+9 F4MViSUkMlHRAcP/vBzULX8eOaPe5WG3uHM7o7w2N4RvZzkjTpgiA3NRXqz+cpoPARFZ QaxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Pu6hNrvrvBLUM5mZQjI/mec3hp6/vRsOvhTA0TYlAsE=; b=fIkbATrjV95lqAGmw2nxCPc8QdD/Oo6BVpK7A9vkHlyq99hI2Tg3DgyPf+HKgiFS9q OwTptrvbBxzFk4Y+oN5MMjm3T9sJ2EZ9vzDki1djjI7UPf/RP9drtVflolpCl7MfocHz kEpU3bUSfjMc8LwjOtWTwpkv/4tOGe2Z2BMkoLG3Rl31qiN6cgZz7rDlKrHe5y25Kwwa AArByrhOSdc5nDmfG0BAB9gmBJCfukCupFJpwmpkBweBtUl4XF97PsDS84RjFJeeU+Rl vlIobO7hUduhiOfni6zGi6mgAkfnVpI3DndhYzimQp0tI+6wHPpbbmHkXrRCLIRUY44g QOiQ== X-Gm-Message-State: ALoCoQmjFRakSHCrcfwJP1WsIIjVAu16sxi4+HmNBw2rv+CW8HOP3N9AyyaB66peinfmLPYY3FvfOhWzrTpFNfpi1D9bgmSn2w== MIME-Version: 1.0 X-Received: by 10.25.218.9 with SMTP id r9mr52211637lfg.138.1452704529263; Wed, 13 Jan 2016 09:02:09 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 13 Jan 2016 09:02:09 -0800 (PST) In-Reply-To: References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> Date: Wed, 13 Jan 2016 09:02:09 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114026006e48d905293a219f Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 17:02:15 -0000 --001a114026006e48d905293a219f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 13, 2016 at 8:41 AM, Ladislav Lhotka wrote: > > > On 13 Jan 2016, at 17:24, Andy Bierman wrote: > > > > > > > > On Wed, Jan 13, 2016 at 7:51 AM, Ladislav Lhotka wrote: > > > > > On 13 Jan 2016, at 16:28, Andy Bierman wrote: > > > > > > Hi, > > > > > > I don't see the point of redoing the debate of the corner-case that > started > > > the entire "conformance drift" discussion several years ago. > > > > No need to redo anything. Y45 resolution declares rough consensus on > Y45-04, and I am fine with that. > > I thought you weren't, so that's why we started discussing alternatives. > > > > > In YANG 1.1, the designer can import the same module 67 times, > > > with 67 different revision dates. They can add new groupings instead > of > > > extending an existing one. YANG 1.1 has mechanisms to use > > > that allow the details to be properly reflected. > > > > > > We have not seen any desire by vendors to break their own > > > client code or their customers client code, so even though > > > YANG 1.0 allows import-without-revision to cause drift, > > > vendors avoid doing this because it breaks deployed product. > > > > > > IMO, a complex solution will not get implemented. > > > Any solution that requires any YANG modules to be parsed > > > to discover the imports is even worse than what we have in YANG 1.0. > > > We will just continue using the and ignore YANG 1.1 rules > > > if the solution is worse than what we have now. > > > > I think we are talking past each other. The solution I would support is: > > > > * List all revisions of all imported modules in yang-library. No YANG > modules need to be parsed. > > > > * For each module, tag one of its revisions as default - to be used for > all imports without revision. > > > > Is this so complex? > > > > > > > > > > Do you have real examples where the latest module implemented > > by the server cannot be the default? > > No. > > > > > The extra complexity is incremental, but it is for a feature > > nobody has ever wanted before, so please explain why > > it is needed. > > When somebody starts from a clean slate, then IMO the complexity of > implementing either 1 or 2 should be comparable. In fact, 1 has to > determine the maximum revision for each imported module, so arguably it has > to do more work. > > Solution 1 relies on a CLR written in the spec while 2 provides the > information about the default revision explicitly in yang-library data. > > It is not a CLR. Picking 1 standard way to do something is our design goal. As Martin pointed out, both solutions have the same affect, except #2 is more complicated If the vendor changes the default revision from 1 release to the next, then they just set the flag to false on foo.yang,R1 and change it to true on foo.yang,R2. The client has no guarantee that the default revision will stay the same from 1 server release to the next. You cannot identity any use-cases where the server needs to use a down-rev as the default. > Lada > > Andy > > > > > > Lada > > > > > > Andy > > > > > > > > > > > Andy > > > > > > > > > > > > On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka > wrote: > > > > > > > On 13 Jan 2016, at 12:46, Martin Bjorklund wrote: > > > > > > > > Ladislav Lhotka wrote: > > > >> > > > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund wrote: > > > >>> > > > >>> Ladislav Lhotka wrote: > > > >>>> > > > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund > wrote: > > > >>>>> > > > >>>>> Ladislav Lhotka wrote: > > > >>>>>> Andy Bierman writes: > > > >>>>>> > > > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Randy Presuhn < > > > >>>>>>> randy_presuhn@mindspring.com> wrote: > > > >>>>>>> > > > >>>>>>>> Hi - > > > >>>>>>>> > > > >>>>>>>>> From: Martin Bjorklund > > > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > > > >>>>>>>>> To: netconf@ietf.org > > > >>>>>>>>> Subject: Re: [Netconf] review of > draft-ietf-netconf-yang-library-03 > > > >>>>>>>> ... > > > >>>>>>>>> The problem: > > > >>>>>>>>> > > > >>>>>>>>> If module A is imported w/o revision by another module that > the > > > >>>>>>>>> server implements, the server MUST somehow inform the client > which > > > >>>>>>>>> revision of A is used. > > > >>>>>>>>> > > > >>>>>>>>> Solution 1: > > > >>>>>>>>> > > > >>>>>>>>> Reported implicitly - the server lists all revisions of A > that it > > > >>>>>>>>> uses, and the most recent one is the one that is used to > resolve > > > >>>>>>>>> import w/o revision. > > > >>>>>>>>> > > > >>>>>>>>> Solution 2: > > > >>>>>>>>> > > > >>>>>>>>> Reported explicitly - the server lists all revisions of A > that it > > > >>>>>>>>> uses, and the the one that is used to resolve import w/o > revision is > > > >>>>>>>>> marked by setting a leaf "default-revision". > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> The current draft has 1 (but it needs to be clarified). > Lada prefers > > > >>>>>>>>> 2. What do others think? > > > >>>>>>>> > > > >>>>>>>> Solution 1 is sufficient if the underlying implementations of > all > > > >>>>>>>> the importing modules in a system strictly play by the > current rules. > > > >>>>>>>> I think solution 2 would be *slightly* more robust, > particularly in > > > >>>>>>>> systems supporting dynamic component updates or components > from > > > >>>>>>>> multiple vendors. If we ever get to the realistic state of > being > > > >>>>>>>> able to support multiple revisions of a particular kind of > component > > > >>>>>>>> concurrently through a single server, both are inadequate. > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>> IMO, solution 1 is appropriate because IMO nobody is going to > > > >>>>>>> write complex client apps to analyze revision-date trees, so > they > > > >>>>>>> can be applied to all the import-stmts without revision found > nested > > > >>>>>>> in all the server YANG modules. > > > >>>>>> > > > >>>>>> Solutions 1 and 2 don't differ on this: all revisions of all > modules > > > >>>>>> used by the server will be listed in yang-library. > > > >>>>>> > > > >>>>>>> > > > >>>>>>> We also implemented solution 1 many years ago, and it > > > >>>>>>> has been working fine. Nobody has ever asked to > > > >>>>>>> use multiple revisions for the default import. > > > >>>>>> > > > >>>>>> Also, neither solution 1 nor 2 proposes this. There will be > only one > > > >>>>>> revision available for imports without revision. > > > >>>>> > > > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be > able > > > >>>>> to > > > >>>>> have a different default revision than the latest revision. > > > >>>> > > > >>>> Rephrase? Andy says "use multiple revisions for the default > import", > > > >>>> not "different than latest". > > > >>>> > > > >>>>>> The real difference is that solution 1 may force an upgrade in a > > > >>>>>> module > > > >>>>>> that imports another module without revision as a side effect of > > > >>>>>> extending the data model, because the maximum revision can > change. > > > >>>>> > > > >>>>> It is not an upgrade of the *module*, it is an upgrade of the > > > >>>>> instrumentation code for that module. > > > >>>> > > > >>>> Correct, and this is what the instrumentation code may not be > prepared > > > >>>> for. I think it is quite important to be able to keep the default > > > >>>> import revision stable. The fact that nobody has asked for it yet > > > >>>> isn't IMO very relevant because most modules so far have only one > > > >>>> revision. > > > >>> > > > >>> Not true! Vendors have been writing and updating modules since > 2010. > > > >> > > > >> These don't count - vendors writing both modules and instrumentation > > > >> are in control of everything. > > > > > > > > The point is that many vendors follow the upgrade rules, and they > have > > > > been doing this for several years. > > > > > > See my response to Andy, upgrade rules really don't help server > implementors. > > > > > > > > > > >> The problem I am talking about is this: > > > >> I want to use a standard module M, but its author decided to import > > > >> module X with revision that is greater than the default revision I > am > > > >> currently using in the data model. > > > > > > > > I think you meant "using in the instrumentation". > > > > > > No, I meant the complete and concrete data model in use by the server, > in which the decision about revisions of imported modules has to be made. > In my example, I would need to make the "bar" leaf a part of the data model > schema, and instrumentation as well, of course. > > > > > > > > > > >> So I have three options: > > > >> > > > >> 1. forget about module M, > > > >> 2. write a proprietary version of M so that it uses at most my > default > > > >> revision of X, > > > >> 3. upgrade the instrumentation to use the higher revision of X. > > > > > > > > Correct. > > > > > > > > You may run into the same situation if you also want to add the > > > > instrumentation for module N, which also imports X w/o revision, and > > > > this instrumentation uses a higher version of X than your > > > > implementation of M. The 'default-revision' leaf doesn't solve this. > > > > > > It does solve this! As the server implementor I am in control of the > contents of yang-library, so I can bump "default-revision" any time, and > module M is unaffected because it imports X with revision. > > > > > > The only issue would be with other modules that import X without > revision: their instrumentation need to be upgraded at the same time, but > that's the deal if we want to have no more than one default revision. > > > > > > Lada > > > > > > > > > > > > > > > Our experience, and Andy's experience, is that doing (3) has not been > > > > an issue in implementations. > > > > > > > > > > > > /martin > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a114026006e48d905293a219f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 13, 2016 at 8:41 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Jan 2016, at 17:24, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Jan 13, 2016 at 7:51 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 13 Jan 2016, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > I don't see the point of redoing the debate of the corner-cas= e that started
> > the entire "conformance drift" discussion several years= ago.
>
> No need to redo anything. Y45 resolution declares rough consensus on Y= 45-04, and I am fine with that.
> I thought you weren't, so that's why we started discussing alt= ernatives.
>
> > In YANG 1.1, the designer can import the same module 67 times, > > with 67 different revision dates.=C2=A0 They can add new grouping= s instead of
> > extending an existing one.=C2=A0 YANG 1.1 has mechanisms to use > > that allow the details to be properly reflected.
> >
> > We have not seen any desire by vendors to break their own
> > client code or their customers client code, so even though
> > YANG 1.0 allows import-without-revision to cause drift,
> > vendors avoid doing this because it breaks deployed product.
> >
> > IMO,=C2=A0 a complex solution will not get implemented.
> > Any solution that requires any YANG modules to be parsed
> > to discover the imports is even worse than what we have in YANG 1= .0.
> > We will just continue using the <hello> and ignore YANG 1.1= rules
> > if the solution is worse than what we have now.
>
> I think we are talking past each other. The solution I would support i= s:
>
> * List all revisions of all imported modules in yang-library. No YANG = modules need to be parsed.
>
> * For each module, tag one of its revisions as default - to be used fo= r all imports without revision.
>
> Is this so complex?
>
>
>
>
> Do you have real examples where the latest module implemented
> by the server cannot be the default?

No.

>
> The extra complexity is incremental, but it is for a feature
> nobody has ever wanted before, so please explain why
> it is needed.

When somebody starts from a clean slate, then IMO the complexity of impleme= nting either 1 or 2 should be comparable. In fact, 1 has to determine the m= aximum revision for each imported module, so arguably it has to do more wor= k.

Solution 1 relies on a CLR written in the spec while 2 provides the informa= tion about the default revision explicitly in yang-library data.


It is not a CLR.=C2=A0 Picking 1 stand= ard way to do something is our design goal.

As Mar= tin pointed out, both solutions have the same affect, except #2 is more com= plicated
If the vendor changes the default revision from 1 releas= e to the next, then they just set
the flag to false on foo.yang,R= 1 and change it to true on foo.yang,R2. The client has
no guarant= ee that the default revision will stay the same from 1 server release
=
to the next.=C2=A0 You cannot identity any use-cases where the server = needs to
use a down-rev as the default.

=
=C2=A0
Lada


Andy
=C2=A0
>
>
> Lada
>
>
> Andy
>
> >
> >
> > Andy
> >
> >
> >
> > On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 13 Jan 2016, at 12:46, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >
> > > Ladislav Lhotka <lhotka@= nic.cz> wrote:
> > >>
> > >>> On 13 Jan 2016, at 12:04, Martin Bjorklund <mbj@tail-f.com> wrote:
> > >>>
> > >>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >>>>
> > >>>>> On 13 Jan 2016, at 11:28, Martin Bjorklund &= lt;mbj@tail-f.com> wrote:
> > >>>>>
> > >>>>> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >>>>>> Andy Bierman <andy@yumaworks.com> writes:
> > >>>>>>
> > >>>>>>> On Tue, Jan 12, 2016 at 11:24 AM, Ra= ndy Presuhn <
> > >>>>>>> randy_presuhn@mindspring.com> wrote:
> > >>>>>>>
> > >>>>>>>> Hi -
> > >>>>>>>>
> > >>>>>>>>> From: Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com">mbj@tail-f.com>
> > >>>>>>>>> Sent: Jan 12, 2016 3:53 AM > > >>>>>>>>> To: netconf@ietf.org
> > >>>>>>>>> Subject: Re: [Netconf] revie= w of draft-ietf-netconf-yang-library-03
> > >>>>>>>> ...
> > >>>>>>>>> The problem:
> > >>>>>>>>>
> > >>>>>>>>> If module A is imported w/o = revision by another module that the
> > >>>>>>>>> server implements, the serve= r MUST somehow inform the client which
> > >>>>>>>>> revision of A is used.
> > >>>>>>>>>
> > >>>>>>>>> Solution 1:
> > >>>>>>>>>
> > >>>>>>>>> Reported implicitly - the se= rver lists all revisions of A that it
> > >>>>>>>>> uses, and the most recent on= e is the one that is used to resolve
> > >>>>>>>>> import w/o revision.
> > >>>>>>>>>
> > >>>>>>>>> Solution 2:
> > >>>>>>>>>
> > >>>>>>>>> Reported explicitly - the se= rver lists all revisions of A that it
> > >>>>>>>>> uses, and the the one that i= s used to resolve import w/o revision is
> > >>>>>>>>> marked by setting a leaf &qu= ot;default-revision".
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> The current draft has 1 (but= it needs to be clarified).=C2=A0 Lada prefers
> > >>>>>>>>> 2.=C2=A0 What do others thin= k?
> > >>>>>>>>
> > >>>>>>>> Solution 1 is sufficient if the = underlying implementations of all
> > >>>>>>>> the importing modules in a syste= m strictly play by the current rules.
> > >>>>>>>> I think solution 2 would be *sli= ghtly* more robust, particularly in
> > >>>>>>>> systems supporting dynamic compo= nent updates or components from
> > >>>>>>>> multiple vendors.=C2=A0 If we ev= er get to the realistic state of being
> > >>>>>>>> able to support multiple revisio= ns of a particular kind of component
> > >>>>>>>> concurrently through a single se= rver, both are inadequate.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>> IMO, solution 1 is appropriate becau= se IMO nobody is going to
> > >>>>>>> write complex client apps to analyze= revision-date trees, so they
> > >>>>>>> can be applied to all the import-stm= ts without revision found nested
> > >>>>>>> in all the server YANG modules.
> > >>>>>>
> > >>>>>> Solutions 1 and 2 don't differ on th= is: all revisions of all modules
> > >>>>>> used by the server will be listed in yan= g-library.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> We also implemented solution 1 many = years ago, and it
> > >>>>>>> has been working fine.=C2=A0 Nobody = has ever asked to
> > >>>>>>> use multiple revisions for the defau= lt import.
> > >>>>>>
> > >>>>>> Also, neither solution 1 nor 2 proposes = this. There will be only one
> > >>>>>> revision available for imports without r= evision.
> > >>>>>
> > >>>>> Let me rephrase Andy's statement: Nobody= has ever asked us to be able
> > >>>>> to
> > >>>>> have a different default revision than the l= atest revision.
> > >>>>
> > >>>> Rephrase? Andy says "use multiple revisions= for the default import",
> > >>>> not "different than latest".
> > >>>>
> > >>>>>> The real difference is that solution 1 m= ay force an upgrade in a
> > >>>>>> module
> > >>>>>> that imports another module without revi= sion as a side effect of
> > >>>>>> extending the data model, because the ma= ximum revision can change.
> > >>>>>
> > >>>>> It is not an upgrade of the *module*, it is = an upgrade of the
> > >>>>> instrumentation code for that module.
> > >>>>
> > >>>> Correct, and this is what the instrumentation co= de may not be prepared
> > >>>> for. I think it is quite important to be able to= keep the default
> > >>>> import revision stable. The fact that nobody has= asked for it yet
> > >>>> isn't IMO very relevant because most modules= so far have only one
> > >>>> revision.
> > >>>
> > >>> Not true!=C2=A0 Vendors have been writing and updati= ng modules since 2010.
> > >>
> > >> These don't count - vendors writing both modules and= instrumentation
> > >> are in control of everything.
> > >
> > > The point is that many vendors follow the upgrade rules, and= they have
> > > been doing this for several years.
> >
> > See my response to Andy, upgrade rules really don't help serv= er implementors.
> >
> > >
> > >> The problem I am talking about is this:
> > >> I want to use a standard module M, but its author decide= d to import
> > >> module X with revision that is greater than the default = revision I am
> > >> currently using in the data model.
> > >
> > > I think you meant "using in the instrumentation".<= br> > >
> > No, I meant the complete and concrete data model in use by the se= rver, in which the decision about revisions of imported modules has to be m= ade. In my example, I would need to make the "bar" leaf a part of= the data model schema, and instrumentation as well, of course.
> >
> > >
> > >> So I have three options:
> > >>
> > >> 1. forget about module M,
> > >> 2. write a proprietary version of M so that it uses at m= ost my default
> > >> revision of X,
> > >> 3. upgrade the instrumentation to use the higher revisio= n of X.
> > >
> > > Correct.
> > >
> > > You may run into the same situation if you also want to add = the
> > > instrumentation for module N, which also imports X w/o revis= ion, and
> > > this instrumentation uses a higher version of X than your > > > implementation of M.=C2=A0 The 'default-revision' le= af doesn't solve this.
> >
> > It does solve this! As the server implementor I am in control of = the contents of yang-library, so I can bump "default-revision" an= y time, and module M is unaffected because it imports X with revision.
> >
> > The only issue would be with other modules that import X without = revision: their instrumentation need to be upgraded at the same time, but t= hat's the deal if we want to have no more than one default revision. > >
> > Lada
> >
> > >
> > >
> > > Our experience, and Andy's experience, is that doing (3)= has not been
> > > an issue in implementations.
> > >
> > >
> > > /martin
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a114026006e48d905293a219f-- From nobody Wed Jan 13 12:08:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088921B31C9 for ; Wed, 13 Jan 2016 12:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86wiGJkY7psW for ; Wed, 13 Jan 2016 12:08:52 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4D71B31C8 for ; Wed, 13 Jan 2016 12:08:52 -0800 (PST) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 2A62D1CC0286 for ; Wed, 13 Jan 2016 21:08:58 +0100 (CET) From: Ladislav Lhotka To: Netconf User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 13 Jan 2016 21:08:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Netconf] problem in ietf-netconf-acm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 20:08:54 -0000 Hi, I just noticed that the module ietf-netconf-acm in RFC 6536 violates a rule in sec. 4.9 of RFC 6087 because the top-level node "nacm" is a mandatory non-presence container. Does it make sense to submit an erratum? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jan 13 12:28:25 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537C41B3205 for ; Wed, 13 Jan 2016 12:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNTJWiPqfHcz for ; Wed, 13 Jan 2016 12:28:23 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E441B3204 for ; Wed, 13 Jan 2016 12:28:22 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id m198so115719068lfm.0 for ; Wed, 13 Jan 2016 12:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+xReVdnUmVnw7sSRr2wVRrOdqvnpkdqz3ShzJ+B52Uw=; b=sha9ExRfEANzQI00YvrhTWNj/xJqwgB+w9Wm/XoJbYQGaxz9MNvM0REHg09FGFg+du cYYrjTM8sR1FrckBEeL8iIC17khcBICTg4JPJhn8C7CpvAFTVwXkOWwjjcDaLoB5NteM fYGW3TK2gKLRY+HP2Y1kqIs8x/0sEZXhaoq0vb3TNm/pt+cC/eWLsDm2zoN+dFxPHrtq VRtqzyQUDBbXc8AQFIO4TJkXO9VfNOL0nmLyNU+5fIMZU8ul3SSIZWMfS4C0XI2akPbk iYmpzgwuidFR8QsBIQcJQT8JleyVlT7gpFKInQpFKeUtvZgD/Wrzh+HcwS7l/wPar/U/ R0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+xReVdnUmVnw7sSRr2wVRrOdqvnpkdqz3ShzJ+B52Uw=; b=i+FbyNCPnpi4zzsUht7d0tun/bIOnsy5Saf97g4OpwMG88xE2r9VCKXCI3udAnnoUB PFBB+4ah0f+vS7kcCqMwEW7jNO2WUQT8m6Lic2OYasGTp+ByrW6dbhCq9ra0st/74IHr pLwEFbtb819Y33+1pkk3kTc9XK+fneQuFDkuwTKZVP0+B8ZtlJEuv/9V/uZpo3B2xnvS E43f04WRXBZ2L+kNuUzoXt/mYAcT+3Zs/7xNIBvVQgMHYH976SgvTT6tj/GDbllKUBRs nfY6zLSN7xqoQpfyJpMrDbQa5m81zLfIcopquhILbxYLlTbFhFzi9o+TxxCCEf3QZahC eaEw== X-Gm-Message-State: ALoCoQnvyYrr98ORJ5UrfZNgyfnphRq6d+ktHjFiyhI1ADUUaGNHOn2kkucJDUveY9LUeee/WuIa35ROGC+AAnG2SkNjUgtOcQ== MIME-Version: 1.0 X-Received: by 10.25.218.9 with SMTP id r9mr62563lfg.138.1452716900839; Wed, 13 Jan 2016 12:28:20 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 13 Jan 2016 12:28:20 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Jan 2016 12:28:20 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11402600d5907105293d0228 Archived-At: Cc: Netconf Subject: Re: [Netconf] problem in ietf-netconf-acm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 20:28:24 -0000 --001a11402600d5907105293d0228 Content-Type: text/plain; charset=UTF-8 Hi, There are mandatory config=false counters. This guideline only applies to config=true nodes. I will try to make that more clear: A mandatory database data definition is defined as a node that a client must provide for the database to be valid. The server is not required to provide a value. Top-level database data definitions MUST NOT be mandatory. If a mandatory node appears at the top level, it will immediately cause the database to be invalid. This can occur when the server boots or when a module is loaded dynamically at runtime. Since the client does not provide read-only counters, they do not count as mandatory by this definition. Andy On Wed, Jan 13, 2016 at 12:08 PM, Ladislav Lhotka wrote: > Hi, > > I just noticed that the module ietf-netconf-acm in RFC 6536 violates a > rule in sec. 4.9 of RFC 6087 because the top-level node "nacm" is a > mandatory non-presence container. > > Does it make sense to submit an erratum? > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11402600d5907105293d0228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There are mandatory config=3Dfalse = counters.
This guideline only applies to config=3Dtrue nodes.
I will try to make that more clear:

   A mandatory database data definition is defined as a node =
that a
   client must provide for the database to be valid.  The server is not
   required to provide a value.

   Top-level database data definitions MUST NOT be mandatory.  If a
   mandatory node appears at the top level, it will immediately cause
   the database to be invalid.  This can occur when the server boots or
   when a module is loaded dynamically at runtime.

Since the client does not provide read-only counters, they do n= ot count as mandatory by
this definition.


Andy

=
On Wed, Jan 13, 2016 at 12:08 PM, Ladislav L= hotka <lhotka@nic.cz> wrote:
H= i,

I just noticed that the module ietf-netconf-acm in RFC 6536 violates a
rule in sec. 4.9 of RFC 6087 because the top-level node "nacm" is= a
mandatory non-presence container.

Does it make sense to submit an erratum?

Lada

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

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

--001a11402600d5907105293d0228-- From nobody Wed Jan 13 12:41:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE181B3240 for ; Wed, 13 Jan 2016 12:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.452 X-Spam-Level: X-Spam-Status: No, score=-4.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd_XHFFjrAAH for ; Wed, 13 Jan 2016 12:41:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BD91B323D for ; Wed, 13 Jan 2016 12:41:47 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:fc0f:1e55:8d2d:55f8] (unknown [IPv6:2a01:5e0:29:ffff:fc0f:1e55:8d2d:55f8]) by mail.nic.cz (Postfix) with ESMTPSA id EBB8C181898; Wed, 13 Jan 2016 21:41:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452717705; bh=S2dO6q6WrgMVLEN74EIHid/JP6NFAtYKihfw+WNUL40=; h=From:Date:To; b=usVxMIq6Ztb2R7zLVQiexBCNG7rkCPykLfVOETd+D+qIbbDKdAjKOqFZHjvBZ+hzz hZxbiMEG65nsuQx/jgkrDbGbRdvZ51V/u+TCExvYKaWkEUcFIvbLOj3VoLtPPynpoY 5u3esUuUVz0iaxvf0DnvJAij24nHVoWT8aR7h2F0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 13 Jan 2016 21:41:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73144FC0-BE37-46F3-BA15-03F6A9C7D000@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] problem in ietf-netconf-acm X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 20:41:49 -0000 > On 13 Jan 2016, at 21:28, Andy Bierman wrote: >=20 > Hi, >=20 > There are mandatory config=3Dfalse counters. > This guideline only applies to config=3Dtrue nodes. nacm is config=3Dtrue. I think this problem has to do with the fact that = "mandatory" for state data is a requirement on the server whereas for = configuration it is a requrement on the client. Lada > I will try to make that more clear: >=20 > A mandatory database data definition is defined as a node that a > client must provide for the database to be valid. The server is = not > required to provide a value. >=20 > Top-level database data definitions MUST NOT be mandatory. If a > mandatory node appears at the top level, it will immediately cause > the database to be invalid. This can occur when the server boots = or > when a module is loaded dynamically at runtime. >=20 >=20 > Since the client does not provide read-only counters, they do not = count as mandatory by > this definition. >=20 >=20 > Andy >=20 >=20 > On Wed, Jan 13, 2016 at 12:08 PM, Ladislav Lhotka = wrote: > Hi, >=20 > I just noticed that the module ietf-netconf-acm in RFC 6536 violates a > rule in sec. 4.9 of RFC 6087 because the top-level node "nacm" is a > mandatory non-presence container. >=20 > Does it make sense to submit an erratum? >=20 > Lada >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 14 02:53:12 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2405A1B3309 for ; Thu, 14 Jan 2016 02:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eDmyHK2tdul for ; Thu, 14 Jan 2016 02:53:06 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::783]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CC31B32F8 for ; Thu, 14 Jan 2016 02:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UIyXz5nDkY85OLv8bxX/Mm7M6JWFAFB9hCs63FBSI28=; b=VgJa/v6QVCzOeYi+OE0YAR4qM2DaXxqQBxEnUhwS1L2twlulG7A9SjICjF8xTmHOyVhEDYiIxEHFfic+vnBh4jd1+8BdHrtM8TQQTKEsh8ivFRVDaZVr/QDELwE+HVTzLhDcAd8cr5ilgqnn2SSl2fAm6Y0yOEHKqWXuRl5RHw8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 14 Jan 2016 10:52:43 +0000 Message-ID: <028b01d14eb9$53ba7560$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Andy Bierman References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> Date: Thu, 14 Jan 2016 10:40:06 +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: [86.185.87.133] X-ClientProxiedBy: HE1PR08CA0033.eurprd08.prod.outlook.com (25.161.112.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 2:kb2OHcfKHcLSPWfSEU26FkO6l/9ileNZLKRKHFJyW4ucoSzhJMY+WeWxsJiJhB2pMUAIWo1uF5Nv77T9AhUDmO3lvJvi8JmcIAEhmMDJ3oZhFgO958uRj6JkOfS4Vpcnd/lghbhyf/9g9meJ853jnw==; 3:50/+o+qhj6QkMLVvrmvOWcqmXLdFs0Ci+yk1rGNUMnWb1aQvKvAi0WZz6ovJ3nK5lHn/ueIXIOz+iA9HvORlT3rpWdCA0vciPthgcw/nFAGYlXHNw6gaPDgyzUthbpWK; 25:EawdO4KbZx5QKzTV8lszNy4S5RU559/DKd6j7UWVMjROtWeiorrT7IZKDfCTbbES9CzYPTomdGRglQMlJ0R6ZBsidyGHtyMUlqUWc1sX2LkSBcoUDlGtC6sfBXvWqzul05jbAe+9FhnW9GrTJ+3cgSQUw9sVJsd5qwER6cOzUxtd8RS5uym43kRsta7c7jZlQElhWKf0YorPkr3pyNT2OM4xQG+XbqMkkhLGT//EnUOSBiZOMZxIyWKVVWPTdTbt; 4:FxnCleOZp4KiBdFe+ITS13vVNyDuyMQIb21M0s0houNz6vVhGD6oAicUZA9dTwx0Ln0idZ/R2Bklyx98UDeTVCtWfb2HAKSJsAaIlQacArZCVHUo+fM4MjgysYjB8wSqTLB3/avCg0CvSJ5bbW3uYI9bzVggBfn9AAjF1qzNay1fYyr7KtS8pSy9LFv5CalFgj91GHpb70jCV2qXqP5Auami/Mlf9FNpAQtteCpjc3FEeHK4xxVEP0vUNwIStxXsHiFH4JjKm6IN3mNW/OkVXWqUZV9X98kRLtw8Cz56ai3nKk5GazTpBHPxpdnSWziX1vKS2uy3OLtSlGxHSsBD6BnKtVomvxGfvbZ7gWIT99tFGpo66NgWIme6YM3QSxkG X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-MS-Office365-Filtering-Correlation-Id: ef956bda-36e7-4d49-6232-08d31cd0d4bd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 08213D42D3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(24454002)(189002)(13464003)(51444003)(33646002)(2906002)(122386002)(97736004)(61296003)(6116002)(40100003)(81686999)(1096002)(42186005)(586003)(92566002)(5008740100001)(1556002)(87976001)(3846002)(81816999)(106356001)(66066001)(4326007)(84392002)(47776003)(230700001)(50466002)(105586002)(62236002)(5004730100002)(86362001)(44716002)(19580395003)(77096005)(19580405001)(93886004)(81156007)(230783001)(50986999)(116806002)(76176999)(189998001)(5001960100002)(14496001)(1456003)(101416001)(23756003)(50226001)(44736004)(5001770100001)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB3PR07MB060; 23:OA7IDmh/SBEHUcGaLm2UaGL8RSRQpluVjFP+t4L9?= =?iso-8859-1?Q?vCNeXT0wqke9Oy0sZ/6A6FU7ASYOIfE1ykZ0Jf7B/NkzD+dDwi/zxbAAQk?= =?iso-8859-1?Q?oz3y2eLAGq/6fUaEvMJcqznPAGR2Wq80N1LlO6i3imoyrBngv0NVeNW45j?= =?iso-8859-1?Q?VgutVOD0HnEuS7Yf4QIBidSjnOlHDNwaf0niQ2OZZnupkvspLpVX6Sqih6?= =?iso-8859-1?Q?GIkbAHYDij7xW8LtA64RcJDIbL5mL2XN8/i4jLFS6Q3vZjn2OnG13rl4/p?= =?iso-8859-1?Q?QzBF7P4rKjChdkCEXGNcpfVSzckjWhiI8Zr/XhdEEMoCfgZLTrpNz0jL59?= =?iso-8859-1?Q?Pd2DzkuPjlMye+XB8MAMIyzQb9r8GC5hKelNTDPw9EYPAKBUxtjxHhV1jE?= =?iso-8859-1?Q?GFVfkE+sFbGKtN/MASCpdJcB99o0EpMqgznUAkjIetO9hb+0F/UNqVOOdP?= =?iso-8859-1?Q?/xXrCia1fx8auHs6eRfzW9sCsO3/rurza1efxNvPOEOA0Siu4acgvHZeMp?= =?iso-8859-1?Q?Hus5O/tDgayya/uBD7uyYxpKLL6O1CDFJ9F/2nP6ighItuLE+YASKmsqvk?= =?iso-8859-1?Q?gmKWigJJMTxTJRh2+hPrEQ7Cqwlgu2xb9eUOJbYalIBeY9FkKNQsUTWrQM?= =?iso-8859-1?Q?0CSzaVQWqThxqjevieaT5rygdxVVJwBiVttk0UXRjyaoKjzw4Ya29T2Y36?= =?iso-8859-1?Q?ptyY5UzwJIEQfA+viVGu/gQd0FfbFjlTOpkjZeKGrvjLgfRQMxf5Urgo6N?= =?iso-8859-1?Q?PWttvjzGZPOJSGJJiPtonaT367m3XZ3BWMY/xHWajt9CJxkfR9FAqFUCJB?= =?iso-8859-1?Q?RR9zBy13o+kS7+G0nZDph9JB8KPXhQFS/P9UQYIxSD4FetCYLqadKJVkOm?= =?iso-8859-1?Q?oMhFTZFUMwEOU7qZV7i97cKVUA8aDIoiLvMXJASNbS0KhUQgY5GCl6ZYCt?= =?iso-8859-1?Q?+uZZO7UBHmrSN+le2ZVTH6OeDJ6M/QT5TChWl+DlAOoa5vLso2VskyHYA5?= =?iso-8859-1?Q?C2ClmJJMAZTvbDTZtl9WVHiPGHWoR1W48kleyp0UBAhaCeRqCcX43/vteh?= =?iso-8859-1?Q?XoKKS06esiQ1Ftl10SZ5RTLZobVPY3UhwWrUy6ssJOU5wZOEEsrU+DTkyx?= =?iso-8859-1?Q?tOcLQkutjFRGX2mwhNO1sc/5QXPV7/3IWPtpBu6mNU1ylw27zAv3qtUqne?= =?iso-8859-1?Q?QDnXPdU6qatBxfBtt5FBeZsgQhEd2kX788m+LyH0mbgB1YY+NbFI5eo5/A?= =?iso-8859-1?Q?NZhD3NEiJ4e+8F7snw2h7hYUWP0+gse8JBPy7Co/NEdFYaoZUMzq0yEuvU?= =?iso-8859-1?Q?JumKWt4Xcv2L7wi0fGgJE07ky8Fke++YBa5GqHnmWEu49wuqzlWw5KFkKy?= =?iso-8859-1?Q?v2bp6/5zd3TIllIfblBuYYOTch7bz+ExGZfYemrvWbHCiyON4s74FyL0Uj?= =?iso-8859-1?Q?ozSqmAVLWd4ic2MAhXN/lD96RRzUPpgpsD?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 5:wB05ChJ6aapoWPkKfdOvE4U6VRiBbgezXNPvfGCMygeNGi1xXccgpUnRNT0q5G22orVkTK5QHomFDTjSFq3UPAA5HXOXmemvJl4SQJBeCSmkRz/1lDdb4nwrQ4hriSMvedxsR3WoLn/WlPRLR9UUfA==; 24:V1UWjqDdnCBIt3p8/o/Xk9OI2zNHqpQeLxHxdhKFRk41jVqoJ9fkia99csRsu3KCvR3Y6v9OA6KPDNFykJU5YoSSDhH8PEIurajZEVuxV4w= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2016 10:52:43.0308 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 10:53:11 -0000 ---- Original Message ----- From: "Ladislav Lhotka" To: "Andy Bierman" Cc: "Randy Presuhn" ; "Netconf" Sent: Wednesday, January 13, 2016 3:51 PM > > > On 13 Jan 2016, at 16:28, Andy Bierman wrote: > > > > I don't see the point of redoing the debate of the corner-case that started > > the entire "conformance drift" discussion several years ago. > > No need to redo anything. Y45 resolution declares rough consensus on Y45-04, and I am fine with that. > I thought you weren't, so that's why we started discussing alternatives. > > > In YANG 1.1, the designer can import the same module 67 times, > > with 67 different revision dates. They can add new groupings instead of > > extending an existing one. YANG 1.1 has mechanisms to use > > that allow the details to be properly reflected. > > > > We have not seen any desire by vendors to break their own > > client code or their customers client code, so even though > > YANG 1.0 allows import-without-revision to cause drift, > > vendors avoid doing this because it breaks deployed product. > > > > IMO, a complex solution will not get implemented. > > Any solution that requires any YANG modules to be parsed > > to discover the imports is even worse than what we have in YANG 1.0. > > We will just continue using the and ignore YANG 1.1 rules > > if the solution is worse than what we have now. > > I think we are talking past each other. The solution I would support is: > > * List all revisions of all imported modules in yang-library. No YANG modules need to be parsed. > > * For each module, tag one of its revisions as default - to be used for all imports without revision. I think that tagging is the right approach, less likely to induce errors. As has been said already, there is limited experience of multiple revisions of standard modules with YANG. In other fields, such as SNMP, I saw the servers implement the latest revision at the time and then not be upgraded, so that the server's latest was well behind the industry view of latest, while clients did get upgraded and so knew of more recent revisions than the server. The issue then is that a user of the client needs to be aware that the server is down level when the client itself is uplevel (probably concurrently, with other servers), so I like the idea of the server being explicit about its view of latest, since it will vary from the client's, user's etc view of latest, and will vary across servers. You do not have to have a tag to make this apparent, but I see it as a more robust way, something that the client can point out to the user, the differing views of what revisions are in use. Tom Petch > Is this so complex? > > Lada > > > > > > > Andy > > > > From nobody Thu Jan 14 03:00:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7FD1B331C for ; Thu, 14 Jan 2016 03:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBHCaU8VzRjs for ; Thu, 14 Jan 2016 03:00:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7261B331A for ; Thu, 14 Jan 2016 03:00:50 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 339181AE047A; Thu, 14 Jan 2016 12:00:49 +0100 (CET) Date: Thu, 14 Jan 2016 12:00:51 +0100 (CET) Message-Id: <20160114.120051.2102268456697235589.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <028b01d14eb9$53ba7560$4001a8c0@gateway.2wire.net> References: <028b01d14eb9$53ba7560$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 11:00:54 -0000 t.petch wrote: > ---- Original Message ----- > From: "Ladislav Lhotka" > To: "Andy Bierman" > Cc: "Randy Presuhn" ; "Netconf" > > Sent: Wednesday, January 13, 2016 3:51 PM > > > > > On 13 Jan 2016, at 16:28, Andy Bierman wrote: > > > > > > I don't see the point of redoing the debate of the corner-case that > started > > > the entire "conformance drift" discussion several years ago. > > > > No need to redo anything. Y45 resolution declares rough consensus on > Y45-04, and I am fine with that. > > I thought you weren't, so that's why we started discussing > alternatives. > > > > > In YANG 1.1, the designer can import the same module 67 times, > > > with 67 different revision dates. They can add new groupings > instead of > > > extending an existing one. YANG 1.1 has mechanisms to use > > > that allow the details to be properly reflected. > > > > > > We have not seen any desire by vendors to break their own > > > client code or their customers client code, so even though > > > YANG 1.0 allows import-without-revision to cause drift, > > > vendors avoid doing this because it breaks deployed product. > > > > > > IMO, a complex solution will not get implemented. > > > Any solution that requires any YANG modules to be parsed > > > to discover the imports is even worse than what we have in YANG 1.0. > > > We will just continue using the and ignore YANG 1.1 rules > > > if the solution is worse than what we have now. > > > > I think we are talking past each other. The solution I would support > is: > > > > * List all revisions of all imported modules in yang-library. No YANG > modules need to be parsed. > > > > * For each module, tag one of its revisions as default - to be used > for all imports without revision. > > I think that tagging is the right approach, less likely to induce > errors. As has been said already, there is limited experience of > multiple revisions of standard modules with YANG. In other fields, such > as SNMP, I saw the servers implement the latest revision at the time and > then not be upgraded, so that the server's latest was well behind the > industry view of latest, while clients did get upgraded and so knew of > more recent revisions than the server. But the tagging proposed here is different. It would be useful when the server upgrades to a new version of a module, but only partly. /martin > The issue then is that a user of the client needs to be aware that the > server is down level when the client itself is uplevel (probably > concurrently, with other servers), so I like the idea of the server > being explicit about its view of latest, since it will vary from the > client's, user's etc view of latest, and will vary across servers. You > do not have to have a tag to make this apparent, but I see it as a more > robust way, something that the client can point out to the user, the > differing views of what revisions are in use. > > Tom Petch > > > Is this so complex? > > > > Lada > > > > > > > > > > > Andy > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Jan 14 03:37:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8690F1B3382 for ; Thu, 14 Jan 2016 03:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdJnjJDExUvp for ; Thu, 14 Jan 2016 03:36:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EE11A6EF9 for ; Thu, 14 Jan 2016 03:36:56 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:cd15:5104:e5cd:7f78] (unknown [IPv6:2001:718:1a02:1:cd15:5104:e5cd:7f78]) by mail.nic.cz (Postfix) with ESMTPSA id D2383180EA2; Thu, 14 Jan 2016 12:36:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452771414; bh=BrlbTl+EuwJ9o+a58PHdZAqQwnrM2w8PKA4iSItpqqE=; h=From:Date:To; b=FDRhygXazRpg55fdTfsglyV6F9kjNyAlU9H/1e4n+JOQQoy+YDCCDtnHp2FfLw42v tiRhmexXdKTUWYzTdNYmsGuYvUQ9Oa0JeIjjM9VDn6oa9H+eG+Y91//rCCplugRKRV PvFBOcAp0aOQKYM51uAG2Eis4bLGfHUES6L85Uus= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160114.120051.2102268456697235589.mbj@tail-f.com> Date: Thu, 14 Jan 2016 12:36:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04025C9E-9F3C-457D-A807-56D38C051F86@nic.cz> References: <028b01d14eb9$53ba7560$4001a8c0@gateway.2wire.net> <20160114.120051.2102268456697235589.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 11:37:00 -0000 > On 14 Jan 2016, at 12:00, Martin Bjorklund wrote: >=20 > t.petch wrote: >> ---- Original Message ----- >> From: "Ladislav Lhotka" >> To: "Andy Bierman" >> Cc: "Randy Presuhn" ; "Netconf" >> >> Sent: Wednesday, January 13, 2016 3:51 PM >>>=20 >>>> On 13 Jan 2016, at 16:28, Andy Bierman wrote: >>>>=20 >>>> I don't see the point of redoing the debate of the corner-case that >> started >>>> the entire "conformance drift" discussion several years ago. >>>=20 >>> No need to redo anything. Y45 resolution declares rough consensus on >> Y45-04, and I am fine with that. >>> I thought you weren't, so that's why we started discussing >> alternatives. >>>=20 >>>> In YANG 1.1, the designer can import the same module 67 times, >>>> with 67 different revision dates. They can add new groupings >> instead of >>>> extending an existing one. YANG 1.1 has mechanisms to use >>>> that allow the details to be properly reflected. >>>>=20 >>>> We have not seen any desire by vendors to break their own >>>> client code or their customers client code, so even though >>>> YANG 1.0 allows import-without-revision to cause drift, >>>> vendors avoid doing this because it breaks deployed product. >>>>=20 >>>> IMO, a complex solution will not get implemented. >>>> Any solution that requires any YANG modules to be parsed >>>> to discover the imports is even worse than what we have in YANG = 1.0. >>>> We will just continue using the and ignore YANG 1.1 rules >>>> if the solution is worse than what we have now. >>>=20 >>> I think we are talking past each other. The solution I would support >> is: >>>=20 >>> * List all revisions of all imported modules in yang-library. No = YANG >> modules need to be parsed. >>>=20 >>> * For each module, tag one of its revisions as default - to be used >> for all imports without revision. >>=20 >> I think that tagging is the right approach, less likely to induce >> errors. As has been said already, there is limited experience of >> multiple revisions of standard modules with YANG. In other fields, = such >> as SNMP, I saw the servers implement the latest revision at the time = and >> then not be upgraded, so that the server's latest was well behind the >> industry view of latest, while clients did get upgraded and so knew = of >> more recent revisions than the server. >=20 > But the tagging proposed here is different. It would be useful when > the server upgrades to a new version of a module, but only partly. Well, partly only because we agreed up-front to use a single default = revision, at least for YANG 1.1, and then *by definition* all imports of = the same module without revision must be bound to that revision. So = saying that my proposal is an incomplete solution seems unfair. If you want, I am open to discussing ways how the server can indicate = actual revisions separately for every import without revision. Lada >=20 >=20 > /martin >=20 >> The issue then is that a user of the client needs to be aware that = the >> server is down level when the client itself is uplevel (probably >> concurrently, with other servers), so I like the idea of the server >> being explicit about its view of latest, since it will vary from the >> client's, user's etc view of latest, and will vary across servers. = You >> do not have to have a tag to make this apparent, but I see it as a = more >> robust way, something that the client can point out to the user, the >> differing views of what revisions are in use. >>=20 >> Tom Petch >>=20 >>> Is this so complex? >>>=20 >>> Lada >>>=20 >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >> >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 14 05:30:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF441B34D0 for ; Thu, 14 Jan 2016 05:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTT2ip0fyJ1H for ; Thu, 14 Jan 2016 05:29:54 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E74A1B34BD for ; Thu, 14 Jan 2016 05:29:54 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id b14so432416554wmb.1 for ; Thu, 14 Jan 2016 05:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ucpXQfhmKCQ14DgowAVUibKpxzTUahNueA3TJdcEwWw=; b=O4oQGxdilOWi2pSc9yzqx0k4cAOv+LCMGjyke2gRvNScarNhMu8pfJX6fPwGCQ+RuE 96O53bXCPC3QD3AO4cN5h1lkddqSZZXndPq7yjvtBQ5Lwn1EokaQHv+cLiEXx3KMDAfg CeQb7qO6+qZEU5UtCRYTV8ISvAMX7faXk6ABfaYY+FiWB3hNTBLuwB2Fonqi/GNo+yjh 22N4ubIRRvDtdx52FZEpjX8CJvZtQYExBUor6Ja2pc2zcFt8spsNiPuBE5MA+Znn4lE7 XrbbXRFuFvgK4B6UfUoJGjJySp5kyweBCH7jywzPX/CU1ySQMnkYYXKVxEIxVZoEr5BD mlJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ucpXQfhmKCQ14DgowAVUibKpxzTUahNueA3TJdcEwWw=; b=Zqk8yh+wtwFTeefdraQXJ21uJdy5vqZ/nq8TxsgC6eveBsM+a8GZFfDME0f/tujD+y 4wgNA2R3e/JptFg1aPjt5Y3t7D6E1aiyEE90DocGVVcGswhYRhVuTK/wlpXccZK08tvE A3N3UbgtgEjHOz7x1kE/+aCP/IFplBsMD/Izc6UXsKW6WcTUAM8Fhx8epOCvMdY0Nq/2 YCoVezrp2G7Vg7vKJq9Hlq6piyG7YHo2fRAIi4iNzCFlIa0RqkUKPP8nSSTKxo6B4Fwh 9FdmrMdRYWj6zhno2A4TvVLs+H7K4B2xF8a+zVkCF/b74b2NLMh1cWQjikgG4N1G4EW1 vt3w== X-Gm-Message-State: ALoCoQkfRENyDAWz6vKwlVp9Ra1UPubSPU2QUUKvTQiB+KeLJcdUUU2nwD3L8hA8axMyLOkwzEYB0cb43I1ZY2zOsg/z/oyNTA== MIME-Version: 1.0 X-Received: by 10.112.164.97 with SMTP id yp1mr1072287lbb.30.1452778192598; Thu, 14 Jan 2016 05:29:52 -0800 (PST) Received: by 10.112.144.36 with HTTP; Thu, 14 Jan 2016 05:29:52 -0800 (PST) In-Reply-To: <028b01d14eb9$53ba7560$4001a8c0@gateway.2wire.net> References: <51E5E4FA-7337-4240-AC17-57A1F740DD11@nic.cz> <20160113.120459.920122826629125868.mbj@tail-f.com> <20160113.124600.805156894654343799.mbj@tail-f.com> <6B5B02EF-D2B3-4411-9A50-1701624A1AF4@nic.cz> <028b01d14eb9$53ba7560$4001a8c0@gateway.2wire.net> Date: Thu, 14 Jan 2016 05:29:52 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c33c981b96c905294b48b7 Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 13:30:01 -0000 --001a11c33c981b96c905294b48b7 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 14, 2016 at 2:40 AM, t.petch wrote: > ---- Original Message ----- > From: "Ladislav Lhotka" > To: "Andy Bierman" > Cc: "Randy Presuhn" ; "Netconf" > > Sent: Wednesday, January 13, 2016 3:51 PM > > > > > On 13 Jan 2016, at 16:28, Andy Bierman wrote: > > > > > > I don't see the point of redoing the debate of the corner-case that > started > > > the entire "conformance drift" discussion several years ago. > > > > No need to redo anything. Y45 resolution declares rough consensus on > Y45-04, and I am fine with that. > > I thought you weren't, so that's why we started discussing > alternatives. > > > > > In YANG 1.1, the designer can import the same module 67 times, > > > with 67 different revision dates. They can add new groupings > instead of > > > extending an existing one. YANG 1.1 has mechanisms to use > > > that allow the details to be properly reflected. > > > > > > We have not seen any desire by vendors to break their own > > > client code or their customers client code, so even though > > > YANG 1.0 allows import-without-revision to cause drift, > > > vendors avoid doing this because it breaks deployed product. > > > > > > IMO, a complex solution will not get implemented. > > > Any solution that requires any YANG modules to be parsed > > > to discover the imports is even worse than what we have in YANG 1.0. > > > We will just continue using the and ignore YANG 1.1 rules > > > if the solution is worse than what we have now. > > > > I think we are talking past each other. The solution I would support > is: > > > > * List all revisions of all imported modules in yang-library. No YANG > modules need to be parsed. > > > > * For each module, tag one of its revisions as default - to be used > for all imports without revision. > > I think that tagging is the right approach, less likely to induce > errors. As has been said already, there is limited experience of > multiple revisions of standard modules with YANG. In other fields, such > as SNMP, I saw the servers implement the latest revision at the time and > then not be upgraded, so that the server's latest was well behind the > industry view of latest, while clients did get upgraded and so knew of > more recent revisions than the server. > > The latest industry revision is not relevant here. The server only lists the revisions it uses. It is not required to change just because the industry published a new revision of a module. > The issue then is that a user of the client needs to be aware that the > server is down level when the client itself is uplevel (probably > concurrently, with other servers), so I like the idea of the server > being explicit about its view of latest, since it will vary from the > client's, user's etc view of latest, and will vary across servers. You > do not have to have a tag to make this apparent, but I see it as a more > robust way, something that the client can point out to the user, the > differing views of what revisions are in use. > > The client knows which revisions are present on the server from examining the YANG library contents on that server. The server is explicit about its view of the latest, simply by listing N revisions and 1 of the N will have a revision date more recent than the other entries. The YANG library is a per-server-instance data structure. It is not a collection of all revisions ever published. > Tom Petch > > Andy > > Is this so complex? > > > > Lada > > > > > > > > > > > Andy > > > > > > > > > --001a11c33c981b96c905294b48b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 14, 2016 at 2:40 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
---- Original Message --= ---
From: "Ladislav Lhotka" <lhot= ka@nic.cz>
To: "Andy Bierman" <andy= @yumaworks.com>
Cc: "Randy Presuhn" <randy_presuhn@mindspring.com>; "Netconf"
<netconf@ietf.org>
Sent: Wednesday, January 13, 2016 3:51 PM
>
> > On 13 Jan 2016, at 16:28, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > I don't see the point of redoing the debate of the corner-cas= e that
started
> > the entire "conformance drift" discussion several years= ago.
>
> No need to redo anything. Y45 resolution declares rough consensus on Y45-04, and I am fine with that.
> I thought you weren't, so that's why we started discussing
alternatives.
>
> > In YANG 1.1, the designer can import the same module 67 times, > > with 67 different revision dates.=C2=A0 They can add new grouping= s
instead of
> > extending an existing one.=C2=A0 YANG 1.1 has mechanisms to use > > that allow the details to be properly reflected.
> >
> > We have not seen any desire by vendors to break their own
> > client code or their customers client code, so even though
> > YANG 1.0 allows import-without-revision to cause drift,
> > vendors avoid doing this because it breaks deployed product.
> >
> > IMO,=C2=A0 a complex solution will not get implemented.
> > Any solution that requires any YANG modules to be parsed
> > to discover the imports is even worse than what we have in YANG 1= .0.
> > We will just continue using the <hello> and ignore YANG 1.1= rules
> > if the solution is worse than what we have now.
>
> I think we are talking past each other. The solution I would support is:
>
> * List all revisions of all imported modules in yang-library. No YANG<= br> modules need to be parsed.
>
> * For each module, tag one of its revisions as default - to be used for all imports without revision.

I think that tagging is the right approach, less likely to induce
errors.=C2=A0 As has been said already, there is limited experience of
multiple revisions of standard modules with YANG.=C2=A0 In other fields, su= ch
as SNMP, I saw the servers implement the latest revision at the time and then not be upgraded, so that the server's latest was well behind the industry view of latest, while clients did get upgraded and so knew of
more recent revisions than the server.



The latest industry rev= ision is not relevant here.
The server only lists the revisions i= t uses.
It is not required to change just because the industry pu= blished a
new revision of a module.

=C2= =A0
The issue then is that a user of the client needs to be aware that the
server is down level when the client itself is uplevel (probably
concurrently, with other servers), so I like the idea of the server
being explicit about its view of latest, since it will vary from the
client's, user's etc view of latest, and will vary across servers.= =C2=A0 You
do not have to have a tag to make this apparent, but I see it as a more
robust way, something that the client can point out to the user, the
differing views of what revisions are in use.


The client knows which revisions are p= resent on the server from examining the
YANG library contents on = that server.


The server is explicit= about its view of the latest, simply by listing
N revisions and = 1 of the N will have a revision date more
recent than the other e= ntries.

The YANG library is a per-server-instance = data structure.=C2=A0 It is not a collection
of all revisions eve= r published.

=C2=A0
Tom Petch



Andy
=C2=A0
> Is this so complex?
>
> Lada
>
> >
> >
> > Andy
> >
> >
<snip>


--001a11c33c981b96c905294b48b7-- From nobody Tue Jan 19 02:46:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1A41B2A3D for ; Tue, 19 Jan 2016 02:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsQDpA9tfbrY for ; Tue, 19 Jan 2016 02:45:58 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7001B1B2A09 for ; Tue, 19 Jan 2016 02:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=930; q=dns/txt; s=iport; t=1453200357; x=1454409957; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=eYabjQr0iyG8YNx8daKbUCYKucwAIc5Nfa48IyXTeGo=; b=G2bFK3vg0vfuy2/v3qgzHzNks9EhxuRSFDU4ucKkMxsrI6ah52gyb3Z9 e55AduJx8+Rnj+Tydo/jTobmxfZs+eDmePis4qt50/9Limm5k/vLSAaxR KLQPOH2rRHCOSuUvoliJQ5l705Jv+Wxi9p2jza9PBxjU/stEx9mn8JPo7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBAC7Ep5W/xbLJq1ehAyJQ7E4hAOIG?= =?us-ascii?q?wEBAQEBAYEAC4ReFUA2AgUWCwILAwIBAgFLDQgBAYgXnwyPZ5ABAQEBBwIBIIE?= =?us-ascii?q?AhVWMc4FJAQSXGo1fiSqFV45dZIQJPociAQEB?= X-IronPort-AV: E=Sophos;i="5.22,316,1449532800"; d="scan'208";a="624624845" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2016 10:45:55 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0JAjsZC012050 for ; Tue, 19 Jan 2016 10:45:55 GMT To: "netconf@ietf.org" From: Robert Wilton Message-ID: <569E13E2.9020802@cisco.com> Date: Tue, 19 Jan 2016 10:45:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 10:45:59 -0000 Hi, I had a few questions regarding draft-ietf-netconf-restconf-09: 1. Is the expectation that RESTCONF only supports HTTP 1.1, and using HTTP/2 isn't supported? Would it help if the document explicitly indicated which versions of HTTP are allowed? 2. Is HTTP 1.1 pipelining allowed/supported? If it is supported then does there need to be any statement made about when the requests are serviced and how they are ordered relative to each other? 3. Even if HTTP pipelining isn't supported then does there need to be any statement made about the relative orderings and what can be seen in the datastore when processing a combination of edit operations (PUT/PATCH/POST/DELETE) and GET requests by a single client? I.e. from a client's perspective is it fair to assume that a GET request will see all updates to the running configuration datastore from all previous edit operations? Thanks, Rob From nobody Tue Jan 19 23:31:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4760D1A874D for ; Tue, 19 Jan 2016 23:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w047CkQhNMvU for ; Tue, 19 Jan 2016 23:31:12 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 053BD1A8741 for ; Tue, 19 Jan 2016 23:31:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lIYdyVuvm/PHs64fubJOO2iUODKSmJFQ7+arFzWg5kLv7zPYZ/LO+sn60UJt/TB2; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aLnEN-0005GR-Pg for netconf@ietf.org; Wed, 20 Jan 2016 02:31:03 -0500 Received: from 76.254.54.144 by webmail.earthlink.net with HTTP; Wed, 20 Jan 2016 02:31:03 -0500 Message-ID: <32693445.1453275063758.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Tue, 19 Jan 2016 23:31:03 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddce45befe0e76bdd4c52b0b28d6d719d50350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: Subject: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 07:31:18 -0000 Hi - I was asked to take a look at draft-ietf-netconf-yang-library-03, so here are a few of my comments. Comments on draft-ietf-netconf-yang-library-03.txt Abstract: First sentence includes the phrase "YANG modules used by a device to represent management and protocol information." It's unclear what is meant by "protocol information", particularly since the following sentence uses "protocols" to mean (AFAICT) seomthing else. Second sentence gives a requirement for cache management, but the document doesn't address it in any meaningful way. This sentence should either be deleted or amended to declare that the requirement is recognized but solutions to the problem are outside the scope of this document. Introduction: First paragraph states "This information changes very infrequently, so it is important that clients be able to cache the YANG library and easily identify if their cache is out-of-date." The assertion "changes very infrequently" may characterize some existing implementations today, but is this a necessary, *architectural* implication for all systems using YANG to model information? I'd like to see either documention of this alleged archictectual limitation, revision of this sentence to identify this limiting assumption of this particular model, or if there is no *architectural* limitation and this model could in fact be useful in dynamic environments, re-working this sentence to justify cacheing without presuming a nearly-static environment. Second paragraph states "Typically, a firmware upgrade is required to change the set of YANG modules used by a server." While this might be true of some implementations, I see no architectural justification whatsoever for this limitation/ assumption. Suggest deleting this sentence. Third paragraph states "The following information is needed by a client application (for each YANG module in the library) to fully utilize the YANG data modeling language:" The following list makes no sense for this introductory sentence, so I suggest fixing the introductory sentence. I think the gist of the problem is (1) that knowing what a YANG module means requires looking at other YANG modules, and knowing *exactly* what those other modules are CANNOT in general be determined by looking only at the module making the reference. It's not a problem of "fully utiliz[ing] the YANG data modeling language." Furthermore, (2) knowing that a system "implements" a particular module is also insufficient for knowing how to interact with it. This, too, is not a matter of utilizing the language, but rather one of determining what the model actually implemented by a system might be by starting with one model and applying changes to it. What is the rationale for the optionality in this requirement? | o deviation list: The name of each YANG module used for deviation | statements SHOULD be identified. 2.1.1 module-set-id There's an ambiguity surrounding the word "unique" here. If the set of modules and submodules reverts to some previous set, is the module-set-id *required* to revert to the corresponding prior value, or is it sufficient for the value to take on a new value every time the set of modules and submodules changes? Second paragraph: pronoun antecedant agreement: there is no plural noun for "them" to refer to. Replace "them" with "it". 2.1.2 yang-protocol This section left me with a few of questions about what was really being modeled and how it might possibly be implemented: - how does the implementation of this model discover that YANG models are being used by one or more protocols within a system? - when we talk about "protocols that are using the YANG library" do we only mean in the server role? - is there really a conflict if two protocols employ the same model but use different datastores? - what if one protocol is supported by multiple servers within a system? - what happens when a protocol uses a YANG model and doesn't tell the yang-library implementation? In the Model: Why is the following "MUST NOT" necessary? I can understand it as a *consequence* of other (IMO unfortunate) rules, but do not see why it is an architecturally neccesary requirement on this model. For YANG 1.1 modules, there MUST NOT be more than one module entry with conformance 'implement' for a particular module name. This statement leads me to another question: For import statements that do not specify a revision date, the most recent revision in the library SHOULD be used by the server."; I think it would be helpful to be a little more specific about potential interactions with imports and the decision to represent an unknown version with a zero-length string. When multiple versions are present, is the one lacking a revision string *necessarily* considered the oldest, and thus "SHOULD" not the match for an import without revision if any other versions are present? Randy From nobody Wed Jan 20 07:00:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C301A8A89 for ; Wed, 20 Jan 2016 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zOuPahDzHd5 for ; Wed, 20 Jan 2016 07:00:47 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C9B371A8A85 for ; Wed, 20 Jan 2016 07:00:46 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E8F11AE027A; Wed, 20 Jan 2016 16:00:45 +0100 (CET) Date: Wed, 20 Jan 2016 16:00:47 +0100 (CET) Message-Id: <20160120.160047.2088004523201785005.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <32693445.1453275063758.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <32693445.1453275063758.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:00:49 -0000 Hi Randy, Thank you for your review! Comments inline. Randy Presuhn wrote: > Hi - > > I was asked to take a look at draft-ietf-netconf-yang-library-03, > so here are a few of my comments. > > Comments on draft-ietf-netconf-yang-library-03.txt > > Abstract: > First sentence includes the phrase "YANG modules > used by a device to represent management and protocol > information." It's unclear what is meant by "protocol > information", particularly since the following sentence > uses "protocols" to mean (AFAICT) seomthing else. > > Second sentence gives a requirement for cache management, > but the document doesn't address it in any meaningful way. > This sentence should either be deleted or amended to declare > that the requirement is recognized but solutions to the > problem are outside the scope of this document. How about this NEW Abstract: This document describes a YANG library, which provides information about all the YANG modules used by a server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. > Introduction: > First paragraph states "This information changes very > infrequently, so it is important that clients be able > to cache the YANG library and easily identify if their > cache is out-of-date." The assertion "changes very > infrequently" may characterize some existing implementations > today, but is this a necessary, *architectural* implication > for all systems using YANG to model information? I'd like > to see either documention of this alleged archictectual > limitation, revision of this sentence to identify this > limiting assumption of this particular model, or if there > is no *architectural* limitation and this model could > in fact be useful in dynamic environments, re-working > this sentence to justify cacheing without presuming > a nearly-static environment. I think this text simply means that the module set "normally" changes less often than a client access the server, and thus that caching can be useful. Maybe we can simply say: OLD: If a large number of YANG modules are utilized by the server, then the YANG library information needed can be relatively large. This information changes very infrequently, so it is important that clients be able to cache the YANG library and easily identify if their cache is out-of-date. NEW: If a large number of YANG modules are utilized by the server, then the YANG library information needed can be relatively large. Thus it is important that clients be able to cache the YANG library and easily identify if their cache is out-of-date. > Second paragraph states "Typically, a firmware upgrade is > required to change the set of YANG modules used by a server." > While this might be true of some implementations, I see no > architectural justification whatsoever for this limitation/ > assumption. Suggest deleting this sentence. Ok. > Third paragraph states "The following information is needed > by a client application (for each YANG module in the library) > to fully utilize the YANG data modeling language:" The following > list makes no sense for this introductory sentence, so I suggest > fixing the introductory sentence. I think the gist of the > problem is (1) that knowing what a YANG module means requires > looking at other YANG modules, and knowing *exactly* what those > other modules are CANNOT in general be determined by looking only > at the module making the reference. It's not a problem of > "fully utiliz[ing] the YANG data modeling language." Furthermore, > (2) knowing that a system "implements" a particular module is > also insufficient for knowing how to interact with it. This, too, > is not a matter of utilizing the language, but rather one of > determining what the model actually implemented by a system might > be by starting with one model and applying changes to it. I agree that the words "fully utilize the YANG data modeling language" are bad. Maybe we can just remove that last part of the sentence? > What is the rationale for the optionality in this requirement? > | o deviation list: The name of each YANG module used for deviation > | statements SHOULD be identified. I think it should be MUST. > 2.1.1 module-set-id > > There's an ambiguity surrounding the word "unique" here. If the > set of modules and submodules reverts to some previous set, is the > module-set-id *required* to revert to the corresponding prior value, > or is it sufficient for the value to take on a new value every time > the set of modules and submodules changes? Since it is only used to help caching on the client, it is ok if the value changes every time the set changes. Do you think this needs to be clarified? > Second paragraph: pronoun antecedant agreement: there is no plural > noun for "them" to refer to. Replace "them" with "it". Ok. > 2.1.2 yang-protocol > > This section left me with a few of questions about what was > really being modeled and how it might possibly be implemented: > - how does the implementation of this model discover that > YANG models are being used by one or more protocols > within a system? > - when we talk about "protocols that are using the YANG > library" do we only mean in the server role? > - is there really a conflict if two protocols employ the same > model but use different datastores? > - what if one protocol is supported by multiple servers > within a system? > - what happens when a protocol uses a YANG model and doesn't > tell the yang-library implementation? It was already agreed on the ML to remove everything about protocols, including this section. Instead, this paragraph is added (in the next revision) to Introduction: If the server implements multiple protocols to access the YANG-defined data, each such protocol has it's own conceptual instantiation of the YANG library. > In the Model: > Why is the following "MUST NOT" necessary? I can understand it > as a *consequence* of other (IMO unfortunate) rules, but do not > see why it is an architecturally neccesary requirement on this model. > > For YANG 1.1 modules, there MUST NOT be more than one > module entry with conformance 'implement' for a > particular module name. You are correct. In the upcoming revision this text is changed to: For YANG version 1.1 modules, there is at most one module entry with conformance 'implement' for a particular module name, since YANG 1.1 requires that at most one revision of a module is implemented. > This statement leads me to another question: > For import statements that do not specify a revision > date, the most recent revision in the library SHOULD > be used by the server."; This sentence was also removed, and corresponding text is added to 6020bis (thus only for YANG 1.1 modules). > I think it would be helpful to be a little more specific about > potential interactions with imports and the decision to represent > an unknown version with a zero-length string. When multiple versions > are present, is the one lacking a revision string *necessarily* > considered the oldest, and thus "SHOULD" not the match for an import > without revision if any other versions are present? I think this makes sense. I can see how the first version of a module is written w/o a revision statement, but not how the first has a revision statement, and the next version removes it. /martin From nobody Wed Jan 20 09:32:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810931A92BD for ; Wed, 20 Jan 2016 09:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XefKiEm_dIu8 for ; Wed, 20 Jan 2016 09:32:14 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D071A92DC for ; Wed, 20 Jan 2016 09:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1953; q=dns/txt; s=iport; t=1453311134; x=1454520734; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=VYV0UdcNNs5yaEPeZmke8Tq7y61QnrVujWnkgYHr7sg=; b=g66Z9n9WPQAFzRyHRMCw7CJ7Mx3+6HVchfT5yhv4saaOyHDghv/1Wwz1 PDfUXKCsOPwMPO0nG2G5g7WQFIzInrFOkwwHBeR5pfCFRxHbCDp0zQMD6 1Z+l8H0arEMPIYnYMGtdkGIS74yd2R56oCBYi/W05eumk1/SQ7PYp8SJv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBAC1w59W/xbLJq1VCY1QsnmBZIgRE?= =?us-ascii?q?gEBAQEBAQF/C4ReFUA2AgUWCwILAwIBAgFLDQgBAYgXoQmPW487AQEBBwIBHXu?= =?us-ascii?q?FP4R0hCiDKoE6BY0wiVSBEoxNgV6HTCOFM4VviFInBjWDZzyHQAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,321,1449532800"; d="scan'208";a="648655883" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 17:32:11 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0KHWBXq028174 for ; Wed, 20 Jan 2016 17:32:11 GMT From: Robert Wilton To: "netconf@ietf.org" Message-ID: <569FC49C.1060703@cisco.com> Date: Wed, 20 Jan 2016 17:32:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] Review comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 17:32:20 -0000 Hi, Generally I found this document pretty easy to read, and hence only have a few minor comments/questions: Section 2.1.2 .... - It was unclear to me what multi-protocol conflicts might arise on a managed device. Are these genuine conflicts, or is it just that some YANG modules are only relevant/specific to particular YANG management access protocols? Section 2.2: identity yang-protocol ... - What is the plan going forward to update these identities? Is the expectation that a new version of the Yang Library Module, and hence a new version of this draft be published whenever a new version of NETCONF/RESTCONF is published? Section 2.2 grouping common-leafs ... - Perhaps a more specific name would help here, or should it be common-leaves instead of common-leafs? - I appreciate that they are only used as list keys, but would it be more clear to the reader if the name and revision leaves were marked as mandatory? Section 2.2 list deviation ... - It wasn't clear to me exactly what was meant by "If the deviation module is available for download". Further, if the deviation module isn't available for download then would it help to have "uses schema-leaf" here so that it could potentially reference the deviation? Section 2.2 restricted-protocol .... - I guess not understanding the exact requirement for restricted-protocols I was wondering whether it wouldn't be better if this list was written with the reverse sense? I.e. list the protocols that are supported rather than the ones that are not. Section 4: Security Considerations .... - This seems to only consider NETCONF. On the presumption that YANG library is useful for RESTCONF as well then does this section need to be updated to also cover RESTCONF? Appendix B. Open Issues ... - The URL lists 3 open issues. Should those issues now be closed/resolved and this text removed? Thanks, Rob From nobody Wed Jan 20 09:48:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814331AC3A1 for ; Wed, 20 Jan 2016 09:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5cqoCLtckUN for ; Wed, 20 Jan 2016 09:48:19 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E151AC3A0 for ; Wed, 20 Jan 2016 09:48:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C6DD2EBE for ; Wed, 20 Jan 2016 18:48:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 34bfgYZ2Y6B9 for ; Wed, 20 Jan 2016 18:48:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 20 Jan 2016 18:48:15 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D78652002B for ; Wed, 20 Jan 2016 18:48:15 +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 GH43zh_4CgkT; Wed, 20 Jan 2016 18:48:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF08320013; Wed, 20 Jan 2016 18:48:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B204D399C7E7; Wed, 20 Jan 2016 18:48:14 +0100 (CET) Date: Wed, 20 Jan 2016 18:48:14 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20160120174814.GA92598@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [Netconf] js review of yang patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 17:48:21 -0000 Here is my review of draft-ietf-netconf-yang-patch-07. - The introduction says that there is a need "to patch NETCONF [RFC6241] datastores" but then there is no binding to use YANG patch with NETCONF... I guess this is due to the fact that we lack an overall architectural framework and hence we use 'NETCONF datastore' - but still kind a funny. Perhaps "NETCONF" simply be removed here since the sentence does actually explain what a datastore is. - But then the following sentence states that a "simpler edit request format" is needed. I guess this implicitly refers to edit-config and if this is indeed a requirement, then the document fails to deliver since there is no binding to NETCONF. - Should it be 'patch procedure' or 'edit procedure' instead of 'transaction procedure'? What has the 'ordered edit list' approach to do with transactions or transaction procedures? - Why does section 2 only talk about how to use yang-patch with RESTCONF and ignore NETCONF? - The YANG module uses YANG 1.1 (good) but the text imports terms etc. from RFC 6020 and reference statements refer to sections in RFC 6020. I think the document should consistently refer to RFC 6020bis. - The date included in the file is not in sync with the revision date. (Perhaps add an RFC editor note to make sure these are in sync in the final version?) - How do I use yang-patch with multiple datastores? Suppose I want to edit an ephemeral datastore - how do I select the datastore? It should be part of the target (that is not be part of the patch itself). - The Registrant Contact in section 4.1 is wrong; this is a product of the NETCONF WG and not the NETMOD WG. - Security considerations are worded to be RESTCONF specific. - I have not tried to verify the examples, I hope they are correct (and that the authors have tools in place to verify this while editing the 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 nobody Wed Jan 20 10:46:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C461ACCFD for ; Wed, 20 Jan 2016 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl84uksVCvYo for ; Wed, 20 Jan 2016 10:46:14 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0110.outbound.protection.outlook.com [104.47.2.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777541ACD03 for ; Wed, 20 Jan 2016 10:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IxVc/AkZcYtYo+WMKEBWBen4+XQ3Qbysd6dXy5ftv4E=; b=FMNBjgXPNUKAM/tP46Z/4euCnpEd201D/nuXFSDIbWU+NWwg4fz+9rpDnT72dhPuuAelMgdcVvWEok3iB1sJXb5mxQTUWoblihElRXIXx548tSNcWApFshZ6P0zR4sJ3UOFRIbxwtjCICgoCqgUnFtFInIb/Go1ohqFuSqebyWA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 18:46:04 +0000 Message-ID: <00ec01d153b2$6cafce00$4001a8c0@gateway.2wire.net> From: t.petch To: Date: Wed, 20 Jan 2016 18:43:08 +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: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0019.eurprd02.prod.outlook.com (10.242.240.19) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 2:lHWMM8tJELopzY/gzfAfn+PlQ/VA2X9YZCba5B5IjDsxGfUweRX5G9+mQhdrZLnThPcmz8fwP55q0l1+5lEupXAQZquiwMM6nxqFukN6sK76EDX6tpQ8ABLMVqtdgbaE5Sn67GTrUvDxbTIVW9g2EQ==; 3:rmR1QfICsicDtQW9o3M3j8WRCnuD86T7sN7S+8YQPG/HHkBfbAJ0RYUnLNWr4Bwl3mIrlh4yDugKpYK0bannJZRbh4SJECrL/xj52tqLyipvtm4jKBQGQn3pSIBfs6rM; 25:gQ4ZYywT4RC5vST8/O2uZxxI1HIFp16KeGYMfHD8tSo5pBABMUB4stOcUE55WFnGqZQCE7MzMhWjGx9+hQVtcYg4d2jasjjadM2Uf7yV6wF4BhcPdvf+SAyBgTdAIkOjIqZzSF+T0zcW1uNW57RxcoUjpky2QqijYZ1DZ/lIrX3dnbL+W+e5QYEh8oKbSxGv3fEWEJ/RgnN0GJtVWX8KXLlfaTGpqN3O7q06AnboCJpjHqhIhPlfxgHh4BmpZpxx; 4:1U/b2oG/UnddIdTDHLqJdHRmqsH1oG47/126BMJibn1XUpXwOn6iPTMOi96jzaLGg7iTfKzqeTheP42NDVphIRPOiPv8M29cVX9iifH9VmJ3/qiubVaZKLSJJvhpqO+GSu1e1Kmn/pSSUCfn7pLsFKeuBwitzn9es/gINFGkSBF0eOgHONq7rGiC/VvRJQJ3xUcpKCXSSNu3SlgxyeaBF8Em9QOy6C732ictLYeR85QrdoLcvIO3WJVbvsYZ/a1q70bl+V55MIaBgK2TQUKT3uJFrVqCYAZo7vDxx615fKc4OaY8bhzLDWFAtkgGDFFpQvneRTorPMjTiXZ8zTgtBDGj0aVtbWTK2QLEL1MNBOG9z+v9y4+v6ewBtM65aq/b X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-MS-Office365-Filtering-Correlation-Id: 0e3c9ab1-4bce-4f9c-c877-08d321c9f37a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB052; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB052; X-Forefront-PRVS: 0827D7ACB9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(199003)(51444003)(44736004)(4326007)(1096002)(66066001)(2351001)(50226001)(5008740100001)(62236002)(33646002)(14496001)(44716002)(230700001)(84392002)(1456003)(116806002)(92566002)(50466002)(23756003)(3846002)(47776003)(6116002)(586003)(81686999)(19580395003)(19580405001)(86362001)(1556002)(77096005)(122386002)(40100003)(87976001)(15975445007)(101416001)(2906002)(230783001)(5004730100002)(61296003)(97736004)(50986999)(106356001)(81156007)(105586002)(110136002)(189998001)(42186005)(5001960100002)(81816999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMSPR07MB052; 23:eQn45ubNwqdah1TojFt35gPZ9Qg0zWdEllgp3Xxt?= =?iso-8859-1?Q?S9sWFArq8bnLNbJqsZN3ryijjoEpDv6clKgyu1DfHvzKYzUF3q626RDD0C?= =?iso-8859-1?Q?UI7tVpBEPMiWLDR/1n5poj0jVn7HUHzKL41GsCb544OukTR4wEDpz15jfW?= =?iso-8859-1?Q?tQSVKvt3rXAp+Fe0PScXl1E5OnQ416OHmUDrtu3i+I8iJR5TJ/4mNx3EDI?= =?iso-8859-1?Q?jRtTWt4M3bLGOEmj253zRNnzUBldB58oyvYNuEz+OmQtk0/MKwtKlwaJI8?= =?iso-8859-1?Q?Ppc5mgOmxz5gsKBCsljbpAgr4sxkVpthFS32k1HnHczWHQP89V2t/N/7PP?= =?iso-8859-1?Q?rUUG+9xkjonXjDnLNhHIKlJGXnn61CraQ+toak0Xqp0ZjBEx0a6tPZ6mY9?= =?iso-8859-1?Q?1TSmcmUYAPQ9Xn2OxdkmpMWNBzYVTybdV2jZdzlIU6rWzqm7wxT/YkwuFn?= =?iso-8859-1?Q?15shrdGjDxDKP8yB4f8/NYfFsLIlYVygKxZ4cIJTCpvqv+9OkU3f/Q+h2E?= =?iso-8859-1?Q?xaWP+oa8ctwOPbbq16gf9a/CTWh4jF4Wf5ogiOum6+y23VDxAd+D5Tjctb?= =?iso-8859-1?Q?vVsnnwUY3x8ivAdj/Cuj40fKSO19+ja5rFNgMk4ELdxT3CTC4ptsXWjSIb?= =?iso-8859-1?Q?GFS0V1WdL9Ch4i5GTnmYkuz8bk6RadcWcIadcRgnzAR+5ZmjFvLf4aHpyK?= =?iso-8859-1?Q?6HiwBBB2JZTKqJEqsnXXfRKbNXys3Ua0o3coiLc5DmrNKjkrvV6o4UpaTw?= =?iso-8859-1?Q?OfjeLANADGwUSSnAL51kkuIu94ShCMM+NXKxSiTaVXM4VkVqtuawrinnVB?= =?iso-8859-1?Q?UFaUQGzmd7L5ykUCpqc+sJjiSsZALbgPS9ncF2pVNhBWDPpHIxNuJLQoEP?= =?iso-8859-1?Q?0p9cjDFbWcja1syZjiZytq66K2mvRc+iaG7rjnzzUANXZQuvgvvqJLxAMT?= =?iso-8859-1?Q?JspthMoO95iZLspAdyFTB9a2Gy6KOmTIqXtgVCkKHtzYsQwhipPCg93lDB?= =?iso-8859-1?Q?T1vbqxMJq+CpAaAwFA+opnw6J44Biiv+MXkDKWA7ox2B8X0qFmKXKK8Ic5?= =?iso-8859-1?Q?fg61wbux6j1KlFbGssjPmJoAd7ghOkweJxwCu2On6wseawdXQEBTut9XCq?= =?iso-8859-1?Q?nCtiyIcvwGtG2XMtUox5uIj1aqVFFrHrZ3k5946uBoOvWxNSIod3jf0lhN?= =?iso-8859-1?Q?qnpK1Zcx0uUW0su1oBjCUiQCPV1c6q8jUYEsY5QGuvd4P2PKKBPnWidO+4?= =?iso-8859-1?Q?GZAbGMuOhVIedpUvb3qaZ5O9jj7c4CbEfSqaLDdCxsZ4Z3ksG4rhYk8j8I?= =?iso-8859-1?Q?hWPHbyEvLYrt9Uzi8nvRp8eAJgYts+Z1OKrC1h4wNV6qcGf4Rg8Xcc2ds+?= =?iso-8859-1?Q?DPvmb046A9YcCBIX2Fra1s/ZQHTXJ6jCJpHipvq7lxACXLC+oQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 5:IxWipkeVJo/I36r/5KtLfeVKxVCKh5m37jconEs7yD1qdfvnRMat9SZH8WQ/9c+MguBWusPcbzrmioz0D9iwIfwOTvUVwYToy8PlfVmBRACOXPhhSeFwLY0teOLe4GZuNkzaDP9jYVLStDw93QPXGA==; 24:bcUaCruL4hxxIWoroyNakN3tI6mPCF7SS68F1ePThwubVoNvbhZwWg8irMSx2EqYlvr75c+CRFd/oSrWcB2+ULAphPJr/XkrbNddOmZ0flY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2016 18:46:04.4397 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 18:46:19 -0000 [um, got error messages so sending it again and again] I have had a first look at netconf-restconf-09 up to the start of section 4. I have not been exposed to REST and its variants except on the IETF lists, nor to HTTP 1.1, and so my comments are more editorial than technical. Mostly, this is about what I see as a thread running through the I-D, on the use of terminology, which makes it more difficult for me to understand than I would like. s.1 " the user should not need any prior knowledge of NETCONF in order to use RESTCONF." Really? so why is RFC6241 a Normative reference:-) Well, obviously you do need an intimate knowledge of NETCONF else you get the kind of discussions on the netmod wg list from those trying to understand YANG without NETCONF:-) I think you should say something like " the user should not need any prior knowledge of the NETCONF protocol in order to use RESTCONF but does need to understand the concepts defined in RFC6241 such as configuration, state and datastores" s1.4 defines terminology much of which has been used or not used in the previous sections. I think that Terminology belongs before s.1.1 s1.4 defines configuration and state and the latter is then hardly ever used (twice as far as I can see) whereas 'operational data' occurs over and over again without AFAICT ever being defined. Given the ongoing discussions in netmod concerning operational state, I think this problematicr. Having defined 'state', then 'state' should be used (or else wait for consensus on Derived State etc and then use them but that might take a while:-); but see also s.3.3.1. s.1 "defined in NETCONF [RFC6241]. The NETCONF protocol defines configuration datastores and ... " Um no; NETCONF (which you have just equated to RFC6241) defines configuration datastores and ... so elide "The" and "protocol". s.1 "RESTCONF uses HTTP operations to provide CRUD operations on a NETCONF datastore " The reference to NETCONF could confuse as to whether NETCONF is required to use RESTCONF or not. I assume from the Introduction that NETCONF is not a prerequisite for RESTCONF but the rest of the document seems less clear on this. In particular, the discussion on what datastores get updated when implies to me that NETCONF is there. I think that this needs clarifying. Likewise, I think greater clarity is needed about datastores; can RESTCONF access user-defined ones or only startup/candidate/running? For me, s.1.3 comes at this from the wrong direction - assume the reader understands datastores and their existence, because they must understand that part of RFC6241, then what is the algorithm to decide which datastore is accessed along the lines of'if .. then ... else if ... ' I realise that this has evolved with the I-D but think that the current text has become unclear. RFC6241 is famously vague about this as we have discussed before so I think that this needs to be more precise. s.1 I note that the reference for XML is not that same as that used in RFC6241 - is there a significant difference? s.1.3 "The candidate is automatically committed to running after a successful edit." For interoperability, that sounds to me like the server 'MUST commit to running' s.1.4.3 " o RPC operation (now called protocol operation)" um where so called? I see RPC still in RFC6241 and rfc6020bis s.2.2 "Consistent with the exclusive use of X.509v3 certificates for NETCONF over TLS [RFC7589], use of certificates in RESTCONF is also limited to X.509v3 certificates." I think that this is open to misinterpretation. It is the use of TLS by NETCONF that is limited to X.509v3 certificates, not that when TLS uses certificates, as opposed to e.g. PSK, then they must be X.509v3. I seem to recall the IESG getting this wrong with call-home so best to be precise. s.2.5 "If the RESTCONF client is not authenticated to access a resource, .. " Well, no, it is not authorised, not not authenticated. s.3 "top-level data node" Again from netmod discussions, this term seems open to misunderstanding and seems not to be defined. I never quite know what is intended by it. s.3.1 It is sort of unfortunate that the restconf API root in the examples is always 'restconf'. Doubtless, most servers will do this and inevitably, some client will hardcode this and then fail on a server that uses something else. I think that you need to show that the API root can be called 'rockandroll' or some other term of your choosing. s.3.2 In a similar vein, a media type of 'application/yang.errors+xml ' corresponds to a resource of 'errors', just what I would expect, until a media type of 'application/yang.operation+xml ' corresponds to 'operations'. Another fruitful source of coding errors:-) s.3.3.1 '?content=nonconfig ' Unfortunate. This makes it at least three in this I-D, 'state', 'operational configuration' and now 'nonconfig'. Given the rumblings on the netmod list, this could run and run. s.3.5.2 "leaf has not been given a value" default handling is another of those topics I see confusing those coming to YANG without NETCONF. Is this 'configured with a value'? If so, I suggest it be made explicit. s.3.7 "The server can optionally support retrieval of the YANG modules it supports, using the "ietf-yang-library" module, " But s.1.2 says "The server lists each YANG module it supports using the "ietf-yang-library" YANG module, defined in [I-D.ietf-netconf-yang-library]. The server MUST implement the "ietf-yang-library" module, which MUST identify all the YANG modules used by the server." so what is optional in s.3.7? More to come:-( Tom Petch ----- Original Message ----- From: ; To: "netconf@ietf.org" Cc: "'core@ietf.org ' >" ; "'i2rs@ietf.org ' >" ; "'6lo@ietf.org ' >" ; "'6tisch@ietf.org ' >" Sent: Wednesday, January 20, 2016 5:04 PM > Dear NETCONF WG, > we hereby issue a WG Last Call for the drafts below: > > > > Please review and send your comments to the NETCONF WG mailing list by January 22, 2015 EOB PT. > The drafts on RESTCONF, YANG patch and YANG library are planned to publish as standard track documents. > As RESTCONF is a major protocol we seek a detailed and thorough review within NETCONF WG but also by the related WGs before publishing. > Therefore the WGLC is planned to finalize on January 22th (covering the holiday time in between) and APP, INT and RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review. > Please take your time to review the documents and send your comments to the NETCONF maillist by the deadline. > Please state on NETCONF maillist also explicitly, whether you have read/reviewed and whether you support the publication. > Furthermore please indicate if you plan to implement or have already implementations for RESTCONF and its supplementary drafts. > Thank you for your review and kind help getting RESTCONF specifications stable. > Best Regards, > Mehmet and Mahesh > From nobody Wed Jan 20 11:41:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2131ACDCC; Wed, 20 Jan 2016 11:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onW7ZgiOD-mA; Wed, 20 Jan 2016 11:41:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CED1ACDC7; Wed, 20 Jan 2016 11:41:03 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0KJf2xW097985 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 20 Jan 2016 13:41:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: General Area Review Team , netconf@ietf.org, draft-ietf-netconf-restconf.all@ietf.org From: Robert Sparks Message-ID: <569FE2CE.6080008@nostrum.com> Date: Wed, 20 Jan 2016 13:41:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] Gen-Art requested early review: draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:41:08 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. This is a requested early review. Please treat these comments just like any other comments. For more information, please see the FAQ at . Document: draft-ietf-netconf-restconf-09 Reviewer: Robert Sparks Review Date: 20Jan2015 IETF LC End Date: (not yet in IETF last call) IESG Telechat date: (not yet scheduled) Summary: This document has a few issues that should be addressed before requesting publication. Please make sure the semantics you're giving to POST vs PUT sit well with HTTP experts. Similarly, please make sure you have someone steeped in character sets and encoding look closely at section 5.3. I'll leave commenting on those things to people more qualified than me. Other reviewers have asked for more information about the interaction of this use of HTTP with things like pipelining. Major issues: The document should explicitly discuss how the restconf protocol will be extended. It mentions that other documents might do that in several places (specifically with "Additional functionality can be defined in external documents, outside the scope of this document"). Section 3.4 claims a datastore resource can only be written directly with the optional to implement PATCH method. That does not seem consistent with the rest of the document. Section 2.2 says "RESTCONF requires that the transport-layer protocol provides both data integrity and confidentiality, such as are provided by the TLS protocol [RFC5246]." and "RESTCONF implementations MUST support the "https" URI scheme", but I don't see any text that prohibits the use of RESTCONF over HTTP without TLS. If the intent was to prohibit that, please make it more explicit. If the intent is to allow the use of RESTCONF without requiring the use of TLS, the security considerations section (at least) needs more discussion about when doing so is a bad idea. Section 2.3 (Certificate Validation) seems to be restating things that it could simply point to instead. Why not replace this section with something like "the RESTCONF peer will follow the procedures and recommendations in RFC6125."? If it's because you want this section to talk only about validating the client certificate, that should be clarified (and there is still probably something that already exists that you can point to rather than restate things here). The current text claims RFC5246 requires the peer to terminate the connection if the certificate path validation fails - where in RFC5246 are you seeing that? Should section 3.1 talk about what a client should do if more than one restconf link relation is returned when querying host-meta? Section 4.3 speaks to returning different content for the same resource depending on what authentication is provided. Specifically "the unauthorized content is omitted from the response message-body, and the authorized content is returned to the client.". Some discussion of how this interacts with caching (or even the ETag mechanisms) is warranted here. What happens if the authorization policies for a given user changes - will they be able to fetch the new things they have been given permission to see, or will the cache, etag, or if-changed-since mechanics interfere? Minor issues: There are some requirements stated with 2119 keywords buried in the Introduction sections. Consider moving them to the protocol definition sections. Section 2.5 cuts off the possibility of using session-based authentication. If that's something you want to be able to add later, make sure you're leaving the right extension points. (I know the typical restconf client won't be a browser, but for those use cases where using a browser makes sense, remember that browsers make it very hard to change identities when you are using HTTP Authentication). In sections 4.2 and 4.3 consider explicitly saying what to return if something issues a HEAD or GET request against an operation resource. The first paragraph in section 5 (before 5.1.1) seems confused in its use of message vs method. Please review the use of the terms and make sure they align with the words used in the introduction to rfc7231, for example. I suggest deleting section 5.2. You already say RESTCONF uses HTTP, and that this section is not comprehensive. As it is, it restates things said in the HTTP documentation without adding anything - at best, it's an opportunity to introduce errors while restating things. Just point to HTTP instead. Similarly, the first table in section 7 could be replaced with a pointer to the relevant place in the HTTP specs. Nits/editorial comments: The introduction says a user should not need any prior knowledge of NETCONF to use RESTCONF. It would be good to also call out here that the implementer _will_ need prior knowledge of NETCONF. The first sentence of section 2.4 ("The RESTCONF client MUST carefully examine the certificate presented by the RESTCONF server to determine if it meets the client's expectations.") adds nothing. Please delete the sentence or replace it with specific things the client needs to do.. The introduction says "Edits are usually applied". Why is this qualified with "usually"? In the examples at the end of 3.5.1 (before 3.5.1.1), consider saying list1=key1,key2,key3/ instead of list1=key1val,key2val,key3val to be consistent with the way you refer to the elements in other places. It would be useful to explicitly discuss what to return if a resource already exists in Section 4.4.1. Right now, that's specified primarily by an example in section 7.1. The "MUST use this exact path" after the last bullet in 5.1 is not a good use of 2119. The sentence is observing a truth about the defined system, not placing an interoperability requirement on the client. The client uses the returned identifier to access the resource. If it uses anything else, it is not accessing the resource. I suggest replacing the prase with "uses this exact path". In section 5.6, I suggest replacing "Instead of using HTTP caching" with "Instead of relying on HTTP caching". Consider adding an example that shows a 500 response corresponding to a "partial-operation" error in NETCONF, demonstrating what information the client gets to distinguish this 500 from an "operation-failed" error. There is a phrase missing in the first sentence of section 7.1. Perhaps "will be returned" just before the left-parenthesis? From nobody Wed Jan 20 22:53:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87C71A00BF for ; Wed, 20 Jan 2016 22:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJuBRN2lfDgZ for ; Wed, 20 Jan 2016 22:53:13 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 110791A009C for ; Wed, 20 Jan 2016 22:53:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TL0CJw8sIEXr9nqSLqsYInzQguxc2KRd+uZcdVjVdZLNO5NMFIHCDVq5fH0CaMkO; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aM977-0007SX-FR for netconf@ietf.org; Thu, 21 Jan 2016 01:53:01 -0500 Received: from 76.254.53.157 by webmail.earthlink.net with HTTP; Thu, 21 Jan 2016 01:53:01 -0500 Message-ID: <26587408.1453359181488.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Wed, 20 Jan 2016 22:53:01 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc8ef0ad3e59c592370fb2fd63fef90795350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Archived-At: Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:53:15 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 20, 2016 7:00 AM >To: randy_presuhn@mindspring.com >Cc: netconf@ietf.org >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >Hi Randy, > >Thank you for your review! Comments inline. > >Randy Presuhn wrote: >> Hi - >> >> I was asked to take a look at draft-ietf-netconf-yang-library-03, >> so here are a few of my comments. >> >> Comments on draft-ietf-netconf-yang-library-03.txt >> >> Abstract: >> First sentence includes the phrase "YANG modules >> used by a device to represent management and protocol >> information." It's unclear what is meant by "protocol >> information", particularly since the following sentence >> uses "protocols" to mean (AFAICT) seomthing else. >> >> Second sentence gives a requirement for cache management, >> but the document doesn't address it in any meaningful way. >> This sentence should either be deleted or amended to declare >> that the requirement is recognized but solutions to the >> problem are outside the scope of this document. > >How about this NEW Abstract: > > This document describes a YANG library, which provides information > about all the YANG modules used by a server. Simple caching > mechanisms are provided to allow clients to minimize retrieval of > this information. This addresses the thrust of my comment. But.... I wonder whether it might be better (in this instance, since abstracts are read with relatively little context) to replace "server" with something that would make it clear that NETCONF (and other management protocol) servers were intended, and not servers in some more general sense. "Device" was problematic because a device might host multiple (NETCONF) servers; I realize this is intended to work with more than just NETCONF, but the naked term "server" in this particular case (without benefit of the definitions section) leaves me uncomfortable. >> Introduction: >> First paragraph states "This information changes very >> infrequently, so it is important that clients be able >> to cache the YANG library and easily identify if their >> cache is out-of-date." The assertion "changes very >> infrequently" may characterize some existing implementations >> today, but is this a necessary, *architectural* implication >> for all systems using YANG to model information? I'd like >> to see either documention of this alleged archictectual >> limitation, revision of this sentence to identify this >> limiting assumption of this particular model, or if there >> is no *architectural* limitation and this model could >> in fact be useful in dynamic environments, re-working >> this sentence to justify cacheing without presuming >> a nearly-static environment. > >I think this text simply means that the module set "normally" changes >less often than a client access the server, and thus that caching can >be useful. > >Maybe we can simply say: > >OLD: > > If a large number of YANG modules are utilized by the server, then > the YANG library information needed can be relatively large. This > information changes very infrequently, so it is important that > clients be able to cache the YANG library and easily identify if > their cache is out-of-date. > >NEW: > > If a large number of YANG modules are utilized by the server, then > the YANG library information needed can be relatively large. Thus > it is important that clients be able to cache the YANG library and > easily identify if their cache is out-of-date. Works for me. I'd replace the last "if" with "whether" as a courtesy to non-native speakers. Does the second occurrance of "YANG library" refer to the same thing as the previous occurance of "YANG library information"? In my mind the summary represented by this "library" module and the actual definitions thus summarized are two distinct things, and a client, depending on what that client needs to do, might need to only cache one or the other. >> Second paragraph states "Typically, a firmware upgrade is >> required to change the set of YANG modules used by a server." >> While this might be true of some implementations, I see no >> architectural justification whatsoever for this limitation/ >> assumption. Suggest deleting this sentence. > >Ok. > >> Third paragraph states "The following information is needed >> by a client application (for each YANG module in the library) >> to fully utilize the YANG data modeling language:" The following >> list makes no sense for this introductory sentence, so I suggest >> fixing the introductory sentence. I think the gist of the >> problem is (1) that knowing what a YANG module means requires >> looking at other YANG modules, and knowing *exactly* what those >> other modules are CANNOT in general be determined by looking only >> at the module making the reference. It's not a problem of >> "fully utiliz[ing] the YANG data modeling language." Furthermore, >> (2) knowing that a system "implements" a particular module is >> also insufficient for knowing how to interact with it. This, too, >> is not a matter of utilizing the language, but rather one of >> determining what the model actually implemented by a system might >> be by starting with one model and applying changes to it. > >I agree that the words "fully utilize the YANG data modeling language" >are bad. Maybe we can just remove that last part of the sentence? Works for me. >> What is the rationale for the optionality in this requirement? >> | o deviation list: The name of each YANG module used for deviation >> | statements SHOULD be identified. > >I think it should be MUST. That answers my question. :-) >> 2.1.1 module-set-id >> >> There's an ambiguity surrounding the word "unique" here. If the >> set of modules and submodules reverts to some previous set, is the >> module-set-id *required* to revert to the corresponding prior value, >> or is it sufficient for the value to take on a new value every time >> the set of modules and submodules changes? > >Since it is only used to help caching on the client, it is ok if the >value changes every time the set changes. Do you think this needs to >be clarified? Yes. It's easy to read the existing language as mandating some kind of implementation-specific guaranteed-collision-free hashing. It sounds like some much easier to implement and verify would meet the requirement. >> Second paragraph: pronoun antecedant agreement: there is no plural >> noun for "them" to refer to. Replace "them" with "it". > >Ok. > >> 2.1.2 yang-protocol >> >> This section left me with a few of questions about what was >> really being modeled and how it might possibly be implemented: >> - how does the implementation of this model discover that >> YANG models are being used by one or more protocols >> within a system? >> - when we talk about "protocols that are using the YANG >> library" do we only mean in the server role? >> - is there really a conflict if two protocols employ the same >> model but use different datastores? >> - what if one protocol is supported by multiple servers >> within a system? >> - what happens when a protocol uses a YANG model and doesn't >> tell the yang-library implementation? > >It was already agreed on the ML to remove everything about protocols, >including this section. Instead, this paragraph is added (in the next >revision) to Introduction: > > If the server implements multiple protocols to access the > YANG-defined data, each such protocol has it's own conceptual > instantiation of the YANG library. Works for me. >> In the Model: >> Why is the following "MUST NOT" necessary? I can understand it >> as a *consequence* of other (IMO unfortunate) rules, but do not >> see why it is an architecturally neccesary requirement on this model. >> >> For YANG 1.1 modules, there MUST NOT be more than one >> module entry with conformance 'implement' for a >> particular module name. > >You are correct. In the upcoming revision this text is changed to: > > For YANG version 1.1 modules, there is at most one > module entry with conformance 'implement' for a > particular module name, since YANG 1.1 requires that at > most one revision of a module is implemented. I think this is ok if it leave open the posibility of this module continuing to work if some future version of Yang doesn't suffer from the one revision limitation. (In most of the systems I worked on, that limitation would have been a complete non-starter. But I digress... ) >> This statement leads me to another question: >> For import statements that do not specify a revision >> date, the most recent revision in the library SHOULD >> be used by the server."; > >This sentence was also removed, and corresponding text is added to >6020bis (thus only for YANG 1.1 modules). This was in the library module as well... >> I think it would be helpful to be a little more specific about >> potential interactions with imports and the decision to represent >> an unknown version with a zero-length string. When multiple versions >> are present, is the one lacking a revision string *necessarily* >> considered the oldest, and thus "SHOULD" not the match for an import >> without revision if any other versions are present? > >I think this makes sense. I can see how the first version of a module >is written w/o a revision statement, but not how the first has a >revision statement, and the next version removes it. Cool. Randy From nobody Thu Jan 21 03:15:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495DB1A86E0 for ; Thu, 21 Jan 2016 03:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw1k4q662BXD for ; Thu, 21 Jan 2016 03:15:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9F1A82E2 for ; Thu, 21 Jan 2016 03:15:24 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 31DF01AE0386; Thu, 21 Jan 2016 12:15:22 +0100 (CET) Date: Thu, 21 Jan 2016 12:15:24 +0100 (CET) Message-Id: <20160121.121524.368078770845175548.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <26587408.1453359181488.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <26587408.1453359181488.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 11:15:26 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Jan 20, 2016 7:00 AM > >To: randy_presuhn@mindspring.com > >Cc: netconf@ietf.org > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > > > >Hi Randy, > > > >Thank you for your review! Comments inline. > > > >Randy Presuhn wrote: > >> Hi - > >> > >> I was asked to take a look at draft-ietf-netconf-yang-library-03, > >> so here are a few of my comments. > >> > >> Comments on draft-ietf-netconf-yang-library-03.txt > >> > >> Abstract: > >> First sentence includes the phrase "YANG modules > >> used by a device to represent management and protocol > >> information." It's unclear what is meant by "protocol > >> information", particularly since the following sentence > >> uses "protocols" to mean (AFAICT) seomthing else. > >> > >> Second sentence gives a requirement for cache management, > >> but the document doesn't address it in any meaningful way. > >> This sentence should either be deleted or amended to declare > >> that the requirement is recognized but solutions to the > >> problem are outside the scope of this document. > > > >How about this NEW Abstract: > > > > This document describes a YANG library, which provides information > > about all the YANG modules used by a server. Simple caching > > mechanisms are provided to allow clients to minimize retrieval of > > this information. > > This addresses the thrust of my comment. > > But.... > I wonder whether it might be better (in this instance, since > abstracts are read with relatively little context) to replace > "server" with something that would make it clear that NETCONF > (and other management protocol) servers were intended, and not > servers in some more general sense. "Device" was problematic > because a device might host multiple (NETCONF) servers; I realize > this is intended to work with more than just NETCONF, but the naked > term "server" in this particular case (without benefit of the > definitions section) leaves me uncomfortable. How about: This document describes a YANG library, which provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). > >> Introduction: > >> First paragraph states "This information changes very > >> infrequently, so it is important that clients be able > >> to cache the YANG library and easily identify if their > >> cache is out-of-date." The assertion "changes very > >> infrequently" may characterize some existing implementations > >> today, but is this a necessary, *architectural* implication > >> for all systems using YANG to model information? I'd like > >> to see either documention of this alleged archictectual > >> limitation, revision of this sentence to identify this > >> limiting assumption of this particular model, or if there > >> is no *architectural* limitation and this model could > >> in fact be useful in dynamic environments, re-working > >> this sentence to justify cacheing without presuming > >> a nearly-static environment. > > > >I think this text simply means that the module set "normally" changes > >less often than a client access the server, and thus that caching can > >be useful. > > > >Maybe we can simply say: > > > >OLD: > > > > If a large number of YANG modules are utilized by the server, then > > the YANG library information needed can be relatively large. This > > information changes very infrequently, so it is important that > > clients be able to cache the YANG library and easily identify if > > their cache is out-of-date. > > > >NEW: > > > > If a large number of YANG modules are utilized by the server, then > > the YANG library information needed can be relatively large. Thus > > it is important that clients be able to cache the YANG library and > > easily identify if their cache is out-of-date. > > Works for me. I'd replace the last "if" with "whether" as a courtesy > to non-native speakers. Ok. > Does the second occurrance of "YANG library" refer to the same thing > as the previous occurance of "YANG library information"? Yes. Should we use "YANG library contents" in both places instead? > In my mind > the summary represented by this "library" module and the actual > definitions thus summarized are two distinct things, and a client, > depending on what that client needs to do, might need to only cache > one or the other. [...] > >> 2.1.1 module-set-id > >> > >> There's an ambiguity surrounding the word "unique" here. If the > >> set of modules and submodules reverts to some previous set, is the > >> module-set-id *required* to revert to the corresponding prior value, > >> or is it sufficient for the value to take on a new value every time > >> the set of modules and submodules changes? > > > >Since it is only used to help caching on the client, it is ok if the > >value changes every time the set changes. Do you think this needs to > >be clarified? > > Yes. It's easy to read the existing language as mandating some > kind of implementation-specific guaranteed-collision-free hashing. > It sounds like some much easier to implement and verify would meet > the requirement. Would this be better? OLD: This mandatory leaf contains a unique implementation-specific identifier representing the current set of modules and submodules. This can for example be a checksum of all modules and submodules. NEW: This mandatory leaf contains a unique implementation-specific identifier representing the current set of modules and submodules. The value of this leaf MUST change if the set of modules and submodules in the YANG library changes. There is no requirement that the same set always results in the same module-set-id value. The value can for example be a timestamp or a checksum of all modules and submodules. /martin From nobody Thu Jan 21 03:28:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F7D1A86FC for ; Thu, 21 Jan 2016 03:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zya5Rp1gL1-4 for ; Thu, 21 Jan 2016 03:28:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5224B1A86FB for ; Thu, 21 Jan 2016 03:28:31 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CFEF1AE0386; Thu, 21 Jan 2016 12:28:30 +0100 (CET) Date: Thu, 21 Jan 2016 12:28:33 +0100 (CET) Message-Id: <20160121.122833.832483064159421793.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <569FC49C.1060703@cisco.com> References: <569FC49C.1060703@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Review comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 11:28:33 -0000 Hi Robert, Thank you for your review! Comments inline. Robert Wilton wrote: > Hi, > > Generally I found this document pretty easy to read, and hence only > have a few minor comments/questions: > > Section 2.1.2 .... > - It was unclear to me what multi-protocol conflicts might arise on > a managed device. Are these genuine conflicts, or is it just that > some YANG modules are only relevant/specific to particular YANG > management access protocols? Since we agreed to remove all protocol-specifics, this section has been removed. > Section 2.2: identity yang-protocol ... > - What is the plan going forward to update these identities? Is the > expectation that a new version of the Yang Library Module, and hence > a new version of this draft be published whenever a new version of > NETCONF/RESTCONF is published? See above - these identities are removed. > Section 2.2 grouping common-leafs ... > - Perhaps a more specific name would help here, or should it be > common-leaves instead of common-leafs? It think the name is ok; note that it is a locally scoped grouping, which cannot be used outside of "module-list" grouping. > - I appreciate that they are only used as list keys, but would it > be more clear to the reader if the name and revision leaves were > marked as mandatory? Since the grouping can only be used internally in this module, I don't think it is necessary. > Section 2.2 list deviation ... > - It wasn't clear to me exactly what was meant by "If the deviation > module is available for download". Further, if the deviation module > isn't available for download then would it help to have "uses > schema-leaf" here so that it could potentially reference the > deviation? Actually, I think this statement is not correct. I think the deviation module MUST be present in the "module" list: OLD: If the deviation module is available for download from the server then a 'module' entry for that module will exist, with the same name and revision values. The 'conformance' value will be 'implement' for the deviation module."; NEW: The deviation module MUST be present in the 'module' list, with the same name and revision values. The 'conformance' value will be 'implement' for the deviation module."; > Section 2.2 restricted-protocol .... > - I guess not understanding the exact requirement for > restricted-protocols I was wondering whether it wouldn't be better > if this list was written with the reverse sense? I.e. list the > protocols that are supported rather than the ones that are not. This leaf is also removed. > Section 4: Security Considerations .... > - This seems to only consider NETCONF. On the presumption that > YANG library is useful for RESTCONF as well then does this section > need to be updated to also cover RESTCONF? This was also noted by Bert. I think we need to update the Security Considerations template to also take RESTCONF into account. > Appendix B. Open Issues ... > - The URL lists 3 open issues. Should those issues now be > closed/resolved and this text removed? I have closed the issues now. /martin From nobody Thu Jan 21 06:16:41 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23661A883E for ; Thu, 21 Jan 2016 06:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMclAKkQEp82 for ; Thu, 21 Jan 2016 06:16:39 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A591A8835 for ; Thu, 21 Jan 2016 06:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1292; q=dns/txt; s=iport; t=1453385799; x=1454595399; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XNS17TsXS+sKH7K4xkbhgwO1xpNEscQY2B+entBtkh0=; b=Pz2IJR5ohbzVygxG5cDXOcOuIXQiDpRU/ge2E+n0lTPYZR5QPlVqnfg0 lzxUYpOVSFvYR2YqlwBHvy048IN8vWFWefU+u2QSHMZTCh2Vg9Cz4c3/3 xFWWMkYtR/Yjcmy0swCQ7EfJKMkhYg9/xoVFTu7cHPqa0TCUpn9qSVH6K k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQB+56BW/xbLJq1ehHmIV7IbAQ2BY?= =?us-ascii?q?4YPAoFxFAEBAQEBAQGBCoQ1AQEEOEEQCw4KCSUPAkYGDQYCAQGIF70oAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEZhjmEdIQ4hFMBBI0tiVGNWYFeh0qFVIprg1UeAQFCg2Y8L?= =?us-ascii?q?ocSAQEB?= X-IronPort-AV: E=Sophos;i="5.22,325,1449532800"; d="scan'208";a="631803858" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 14:16:37 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0LEGaYd006341; Thu, 21 Jan 2016 14:16:37 GMT To: Martin Bjorklund References: <569FC49C.1060703@cisco.com> <20160121.122833.832483064159421793.mbj@tail-f.com> From: Robert Wilton Message-ID: <56A0E846.50201@cisco.com> Date: Thu, 21 Jan 2016 14:16:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160121.122833.832483064159421793.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Review comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:16:40 -0000 Hi Martin, On 21/01/2016 11:28, Martin Bjorklund wrote: > Hi Robert, > > Thank you for your review! Comments inline. > > Robert Wilton wrote: > >> Section 2.2 list deviation ... >> - It wasn't clear to me exactly what was meant by "If the deviation >> module is available for download". Further, if the deviation module >> isn't available for download then would it help to have "uses >> schema-leaf" here so that it could potentially reference the >> deviation? > Actually, I think this statement is not correct. I think the > deviation module MUST be present in the "module" list: > > OLD: > > If the deviation module is available for download > from the server then a 'module' entry for that module > will exist, with the same name and revision values. > The 'conformance' value will be 'implement' for > the deviation module."; > > NEW: > > The deviation module MUST be present in the 'module' > list, with the same name and revision values. > The 'conformance' value will be 'implement' for > the deviation module."; Yes, with that change it makes sense. I'm also happy with all your other responses. Thanks, Rob From nobody Thu Jan 21 08:32:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CB41B32AA for ; Thu, 21 Jan 2016 08:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ob5iIgDuVZf for ; Thu, 21 Jan 2016 08:32:52 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB411B32A7 for ; Thu, 21 Jan 2016 08:32:52 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id h129so30509875lfh.3 for ; Thu, 21 Jan 2016 08:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gqjqDZNbRMULHNYObZ4A3rmnvxSeVx/pM1Lt9VLGC3E=; b=jW1hUlv/JyqmeMXoTFJyKWLnkyuiar8wYzy/Pr+SOMEiwFnlk7jG14VJbtlX5EkGDS 6aBQviBTZm0KyUT/fAMqHdSPJxB9HFPJ/s34Eo4fq0EBtNrieOwQCc5VRNlNaCCKkRvR lOlVmQdHSV2/NtxG3xstQDW7qbMe2NzYGB/X7HL3j1WL+CLyQxzRjdfXGJ3PByA80dPr F9SDFZAnWh1lWatYnYC6TZKINnBtWBsqlVVaH/ceZSlZV1+6CH6TIqyosvY+RyDHSfBg nzQ3jP7bYeqoH7HxaH9MAT7LDeTW6PBKpoldGGS8EH3YpMEZejgjL615hh7rv/QZzomi Zjmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gqjqDZNbRMULHNYObZ4A3rmnvxSeVx/pM1Lt9VLGC3E=; b=ayp3RjWgHNwD2fAmO9uy/3E2fCdCEH3uk/dA7xrT4MPyS/E7m5bZBedlp9KjJJlzEY W6N4aB9sAt7iWnAqin5AkRvN9A3Kotc4C09gzb9/VzfuZo0tHIx2jUeSZUP5C9zcR4Zx zKTuqgovkMY3gaCnAbsOvEwayPk+KLW/dj6H/PpAadOcupOL3Bp7KsgJ02AI3kh9N9tJ iq5MHfPxE8mqgfk5gMk/Q8FhabhZO97YEJpH3Es63JY8MpeUgimTrgIH64HrSOvlgke4 JTqEX9+BXZWSP7MCfdBgFj4IzQYXkzwUh9CztSBG2ri6fKX3g8eWzehi/uR0UEqAGQ7R wYZg== X-Gm-Message-State: ALoCoQnWpIGJBlodFQLI4Vq3echShSPRBipdCNOwmB5l4Dh2pRFTFEfcsV94N82tW+9ysIYbaeeFdqYsBA6Z2guyoj/s25AkDQ== MIME-Version: 1.0 X-Received: by 10.25.77.203 with SMTP id a194mr17285650lfb.62.1453393970234; Thu, 21 Jan 2016 08:32:50 -0800 (PST) Received: by 10.112.200.167 with HTTP; Thu, 21 Jan 2016 08:32:50 -0800 (PST) In-Reply-To: <20160121.122833.832483064159421793.mbj@tail-f.com> References: <569FC49C.1060703@cisco.com> <20160121.122833.832483064159421793.mbj@tail-f.com> Date: Thu, 21 Jan 2016 08:32:50 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1141f2c450abc50529daa7bb Archived-At: Cc: Netconf Subject: Re: [Netconf] Review comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:32:54 -0000 --001a1141f2c450abc50529daa7bb Content-Type: text/plain; charset=UTF-8 On Thu, Jan 21, 2016 at 3:28 AM, Martin Bjorklund wrote: > Hi Robert, > > Thank you for your review! Comments inline. > > Robert Wilton wrote: > > Hi, > > > > Generally I found this document pretty easy to read, and hence only > > have a few minor comments/questions: > > > > Section 2.1.2 .... > > - It was unclear to me what multi-protocol conflicts might arise on > > a managed device. Are these genuine conflicts, or is it just that > > some YANG modules are only relevant/specific to particular YANG > > management access protocols? > > Since we agreed to remove all protocol-specifics, this section has > been removed. > When did the WG agree to this and what are the details? > > > Section 2.2: identity yang-protocol ... > > - What is the plan going forward to update these identities? Is the > > expectation that a new version of the Yang Library Module, and hence > > a new version of this draft be published whenever a new version of > > NETCONF/RESTCONF is published? > > See above - these identities are removed. > > > Section 2.2 grouping common-leafs ... > > - Perhaps a more specific name would help here, or should it be > > common-leaves instead of common-leafs? > > It think the name is ok; note that it is a locally scoped grouping, > which cannot be used outside of "module-list" grouping. > > > - I appreciate that they are only used as list keys, but would it > > be more clear to the reader if the name and revision leaves were > > marked as mandatory? > > Since the grouping can only be used internally in this module, I don't > think it is necessary. > > > Section 2.2 list deviation ... > > - It wasn't clear to me exactly what was meant by "If the deviation > > module is available for download". Further, if the deviation module > > isn't available for download then would it help to have "uses > > schema-leaf" here so that it could potentially reference the > > deviation? > > Actually, I think this statement is not correct. I think the > deviation module MUST be present in the "module" list: > > OLD: > > If the deviation module is available for download > from the server then a 'module' entry for that module > will exist, with the same name and revision values. > The 'conformance' value will be 'implement' for > the deviation module."; > > NEW: > > The deviation module MUST be present in the 'module' > list, with the same name and revision values. > The 'conformance' value will be 'implement' for > the deviation module."; > > > Section 2.2 restricted-protocol .... > > - I guess not understanding the exact requirement for > > restricted-protocols I was wondering whether it wouldn't be better > > if this list was written with the reverse sense? I.e. list the > > protocols that are supported rather than the ones that are not. > > This leaf is also removed. > > > Section 4: Security Considerations .... > > - This seems to only consider NETCONF. On the presumption that > > YANG library is useful for RESTCONF as well then does this section > > need to be updated to also cover RESTCONF? > > This was also noted by Bert. I think we need to update the Security > Considerations template to also take RESTCONF into account. > > > > Appendix B. Open Issues ... > > - The URL lists 3 open issues. Should those issues now be > > closed/resolved and this text removed? > > I have closed the issues now. > > > /martin > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1141f2c450abc50529daa7bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 21, 2016 at 3:28 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi Robert,

Thank you for your review!=C2=A0 Comments inline.

Robert Wilton <rwilton@cisco.com> wrote:
> Hi,
>
> Generally I found this document pretty easy to read, and hence only > have a few minor comments/questions:
>
> Section 2.1.2 ....
> - It was unclear to me what multi-protocol conflicts might arise on > a managed device.=C2=A0 Are these genuine conflicts, or is it just tha= t
> some YANG modules are only relevant/specific to particular YANG
> management access protocols?

Since we agreed to remove all protocol-specifics, this section has
been removed.


> Section 2.2: identity yang-protocol ...
> - What is the plan going forward to update these identities?=C2=A0 Is = the
> expectation that a new version of the Yang Library Module, and hence > a new version of this draft be published whenever a new version of
> NETCONF/RESTCONF is published?

See above - these identities are removed.

> Section 2.2 grouping common-leafs ...
>=C2=A0 - Perhaps a more specific name would help here, or should it be<= br> > common-leaves instead of common-leafs?

It think the name is ok; note that it is a locally scoped grouping,
which cannot be used outside of "module-list" grouping.

>=C2=A0 - I appreciate that they are only used as list keys, but would i= t
> be more clear to the reader if the name and revision leaves were
> marked as mandatory?

Since the grouping can only be used internally in this module, I don't<= br> think it is necessary.

> Section 2.2 list deviation ...
>=C2=A0 - It wasn't clear to me exactly what was meant by "If t= he deviation
> module is available for download".=C2=A0 Further, if the deviatio= n module
> isn't available for download then would it help to have "uses=
> schema-leaf" here so that it could potentially reference the
> deviation?

Actually, I think this statement is not correct.=C2=A0 I think the
deviation module MUST be present in the "module" list:

OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the deviation module is availab= le for download
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the server then a 'module= ' entry for that module
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will exist, with the same name and= revision values.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The 'conformance' value wi= ll be 'implement' for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the deviation module.";

NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The deviation module MUST be prese= nt in the 'module'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list, with the same name and revis= ion values.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The 'conformance' value wi= ll be 'implement' for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the deviation module.";

> Section 2.2 restricted-protocol ....
>=C2=A0 - I guess not understanding the exact requirement for
> restricted-protocols I was wondering whether it wouldn't be better=
> if this list was written with the reverse sense?=C2=A0 I.e. list the > protocols that are supported rather than the ones that are not.

This leaf is also removed.

> Section 4: Security Considerations ....
>=C2=A0 - This seems to only consider NETCONF.=C2=A0 On the presumption = that
> YANG library is useful for RESTCONF as well then does this section
> need to be updated to also cover RESTCONF?

This was also noted by Bert.=C2=A0 I think we need to update the Security Considerations template to also take RESTCONF into account.
=C2=A0

> Appendix B.=C2=A0 Open Issues ...
>=C2=A0 - The URL lists 3 open issues.=C2=A0 Should those issues now be<= br> > closed/resolved and this text removed?

I have closed the issues now.


/martin


Andy
= =C2=A0

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

--001a1141f2c450abc50529daa7bb-- From nobody Thu Jan 21 12:06:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7041A9090 for ; Thu, 21 Jan 2016 12:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiNtmO7WnCoo for ; Thu, 21 Jan 2016 12:06:10 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9670D1A908F for ; Thu, 21 Jan 2016 12:06:10 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 336221AE0386; Thu, 21 Jan 2016 21:06:09 +0100 (CET) Date: Thu, 21 Jan 2016 21:07:07 +0100 (CET) Message-Id: <20160121.210707.47415526330378267.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <569FC49C.1060703@cisco.com> <20160121.122833.832483064159421793.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Review comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 20:06:12 -0000 Andy Bierman wrote: > On Thu, Jan 21, 2016 at 3:28 AM, Martin Bjorklund wrote: > > > Hi Robert, > > > > Thank you for your review! Comments inline. > > > > Robert Wilton wrote: > > > Hi, > > > > > > Generally I found this document pretty easy to read, and hence only > > > have a few minor comments/questions: > > > > > > Section 2.1.2 .... > > > - It was unclear to me what multi-protocol conflicts might arise on > > > a managed device. Are these genuine conflicts, or is it just that > > > some YANG modules are only relevant/specific to particular YANG > > > management access protocols? > > > > Since we agreed to remove all protocol-specifics, this section has > > been removed. > > > > When did the WG agree to this and what are the details? See the mail thread starting at https://mailarchive.ietf.org/arch/msg/netconf/H6IW7pHJ3dJ_y0uvkhIb9BQ5t5A /martin From nobody Thu Jan 21 13:45:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24171B33AD for ; Thu, 21 Jan 2016 13:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDTzfYVkii51 for ; Thu, 21 Jan 2016 13:45:15 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 715AF1B33AC for ; Thu, 21 Jan 2016 13:45:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tjrc+LDZeukuuKltqLXaJZMgsYFlTvWWGdZEwqV4uCvFaleNOPrsBrkEvwU2iSh4; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aMN2O-0007IP-4i for netconf@ietf.org; Thu, 21 Jan 2016 16:45:04 -0500 Received: from 76.254.55.96 by webmail.earthlink.net with HTTP; Thu, 21 Jan 2016 16:45:03 -0500 Message-ID: <30570559.1453412704034.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Thu, 21 Jan 2016 13:45:03 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc4554c0207f13e31beacbb1e7b175e90a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 Archived-At: Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 21:45:17 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 21, 2016 3:15 AM >To: randy_presuhn@mindspring.com >Cc: netconf@ietf.org >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >Randy Presuhn wrote: >> Hi - >> >> >From: Martin Bjorklund >> >Sent: Jan 20, 2016 7:00 AM >> >To: randy_presuhn@mindspring.com >> >Cc: netconf@ietf.org >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 >> > >> >Hi Randy, >> > >> >Thank you for your review! Comments inline. >> > >> >Randy Presuhn wrote: >> >> Hi - >> >> >> >> I was asked to take a look at draft-ietf-netconf-yang-library-03, >> >> so here are a few of my comments. >> >> >> >> Comments on draft-ietf-netconf-yang-library-03.txt >> >> >> >> Abstract: >> >> First sentence includes the phrase "YANG modules >> >> used by a device to represent management and protocol >> >> information." It's unclear what is meant by "protocol >> >> information", particularly since the following sentence >> >> uses "protocols" to mean (AFAICT) seomthing else. >> >> >> >> Second sentence gives a requirement for cache management, >> >> but the document doesn't address it in any meaningful way. >> >> This sentence should either be deleted or amended to declare >> >> that the requirement is recognized but solutions to the >> >> problem are outside the scope of this document. >> > >> >How about this NEW Abstract: >> > >> > This document describes a YANG library, which provides information >> > about all the YANG modules used by a server. Simple caching >> > mechanisms are provided to allow clients to minimize retrieval of >> > this information. >> >> This addresses the thrust of my comment. >> >> But.... >> I wonder whether it might be better (in this instance, since >> abstracts are read with relatively little context) to replace >> "server" with something that would make it clear that NETCONF >> (and other management protocol) servers were intended, and not >> servers in some more general sense. "Device" was problematic >> because a device might host multiple (NETCONF) servers; I realize >> this is intended to work with more than just NETCONF, but the naked >> term "server" in this particular case (without benefit of the >> definitions section) leaves me uncomfortable. > >How about: > > This document describes a YANG library, which provides information > about all the YANG modules used by a network management server > (e.g., a Network Configuration Protocol (NETCONF) server). Sounds good to me. Thanks! >> >> Introduction: >> >> First paragraph states "This information changes very >> >> infrequently, so it is important that clients be able >> >> to cache the YANG library and easily identify if their >> >> cache is out-of-date." The assertion "changes very >> >> infrequently" may characterize some existing implementations >> >> today, but is this a necessary, *architectural* implication >> >> for all systems using YANG to model information? I'd like >> >> to see either documention of this alleged archictectual >> >> limitation, revision of this sentence to identify this >> >> limiting assumption of this particular model, or if there >> >> is no *architectural* limitation and this model could >> >> in fact be useful in dynamic environments, re-working >> >> this sentence to justify cacheing without presuming >> >> a nearly-static environment. >> > >> >I think this text simply means that the module set "normally" changes >> >less often than a client access the server, and thus that caching can >> >be useful. >> > >> >Maybe we can simply say: >> > >> >OLD: >> > >> > If a large number of YANG modules are utilized by the server, then >> > the YANG library information needed can be relatively large. This >> > information changes very infrequently, so it is important that >> > clients be able to cache the YANG library and easily identify if >> > their cache is out-of-date. >> > >> >NEW: >> > >> > If a large number of YANG modules are utilized by the server, then >> > the YANG library information needed can be relatively large. Thus >> > it is important that clients be able to cache the YANG library and >> > easily identify if their cache is out-of-date. >> >> Works for me. I'd replace the last "if" with "whether" as a courtesy >> to non-native speakers. > >Ok. > >> Does the second occurrance of "YANG library" refer to the same thing >> as the previous occurance of "YANG library information"? > >Yes. Should we use "YANG library contents" in both places instead? If that's what's intended, I think that would be fine. >> In my mind >> the summary represented by this "library" module and the actual >> definitions thus summarized are two distinct things, and a client, >> depending on what that client needs to do, might need to only cache >> one or the other. > >[...] > >> >> 2.1.1 module-set-id >> >> >> >> There's an ambiguity surrounding the word "unique" here. If the >> >> set of modules and submodules reverts to some previous set, is the >> >> module-set-id *required* to revert to the corresponding prior value, >> >> or is it sufficient for the value to take on a new value every time >> >> the set of modules and submodules changes? >> > >> >Since it is only used to help caching on the client, it is ok if the >> >value changes every time the set changes. Do you think this needs to >> >be clarified? >> >> Yes. It's easy to read the existing language as mandating some >> kind of implementation-specific guaranteed-collision-free hashing. >> It sounds like some much easier to implement and verify would meet >> the requirement. > >Would this be better? > >OLD: > > This mandatory leaf contains a unique implementation-specific > identifier representing the current set of modules and submodules. > This can for example be a checksum of all modules and submodules. > >NEW: > > This mandatory leaf contains a unique implementation-specific > identifier representing the current set of modules and submodules. > > The value of this leaf MUST change if the set of modules and > submodules in the YANG library changes. There is no requirement > that the same set always results in the same module-set-id value. So far, so good, though I'd prefer "whenever" to "if". > The value can for example be a timestamp or a checksum of all > modules and submodules. This still makes me a bit queasy - checksums are not *guaranteed* to change, and it omits the simplest, cheapest, and most robust example that comes to mind: an integer (with a large potential range) incremented with each change. For this to work, it's not sufficient that it be merely *highly probable* that the value changes when the library changes; it has to be a "sure thing." Getting a bit beyond the scope of this draft, this leaf presumes a polling-based monitoring strategy. Forgive me for thinking like an SNMP guy, but wouldn't it scale much better for the system to be able to generate a notification whenever this piece of information changes? Randy From nobody Thu Jan 21 13:52:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B931B33B5 for ; Thu, 21 Jan 2016 13:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66uNhrgYRYxh for ; Thu, 21 Jan 2016 13:52:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 941A21B31B3 for ; Thu, 21 Jan 2016 13:52:08 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 916F41AE0386; Thu, 21 Jan 2016 22:52:07 +0100 (CET) Date: Thu, 21 Jan 2016 22:53:06 +0100 (CET) Message-Id: <20160121.225306.1858243111662770795.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <30570559.1453412704034.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> References: <30570559.1453412704034.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 21:52:10 -0000 Hi, Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Jan 21, 2016 3:15 AM > >To: randy_presuhn@mindspring.com > >Cc: netconf@ietf.org > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > > > >Randy Presuhn wrote: > >> Hi - > >> > >> >From: Martin Bjorklund > >> >Sent: Jan 20, 2016 7:00 AM > >> >To: randy_presuhn@mindspring.com > >> >Cc: netconf@ietf.org > >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >> > > >> >Hi Randy, > >> > > >> >Thank you for your review! Comments inline. > >> > > >> >Randy Presuhn wrote: [...] > >> >> 2.1.1 module-set-id > >> >> > >> >> There's an ambiguity surrounding the word "unique" here. If the > >> >> set of modules and submodules reverts to some previous set, is the > >> >> module-set-id *required* to revert to the corresponding prior value, > >> >> or is it sufficient for the value to take on a new value every time > >> >> the set of modules and submodules changes? > >> > > >> >Since it is only used to help caching on the client, it is ok if the > >> >value changes every time the set changes. Do you think this needs to > >> >be clarified? > >> > >> Yes. It's easy to read the existing language as mandating some > >> kind of implementation-specific guaranteed-collision-free hashing. > >> It sounds like some much easier to implement and verify would meet > >> the requirement. > > > >Would this be better? > > > >OLD: > > > > This mandatory leaf contains a unique implementation-specific > > identifier representing the current set of modules and submodules. > > This can for example be a checksum of all modules and submodules. > > > >NEW: > > > > This mandatory leaf contains a unique implementation-specific > > identifier representing the current set of modules and submodules. > > > > The value of this leaf MUST change if the set of modules and > > submodules in the YANG library changes. There is no requirement > > that the same set always results in the same module-set-id value. > > So far, so good, though I'd prefer "whenever" to "if". Ok. > > The value can for example be a timestamp or a checksum of all > > modules and submodules. > > This still makes me a bit queasy - checksums are not > *guaranteed* to change, and it omits the simplest, > cheapest, and most robust example that comes to mind: > an integer (with a large potential range) incremented > with each change. For this to work, it's not sufficient > that it be merely *highly probable* that the value changes > when the library changes; it has to be a "sure thing." Maybe we should simply remove this "for example" sentence? > Getting a bit beyond the scope of this draft, this leaf presumes > a polling-based monitoring strategy. Forgive me for thinking > like an SNMP guy, but wouldn't it scale much better for the > system to be able to generate a notification whenever this > piece of information changes? For YANG 1.1, the module-set-id is actually presented in the capability in the message. Since the module-set-id is part of a capability, the server will generate a netconf-capability-change notification (defined in RFC 6470) if the module set changes. /martin From nobody Thu Jan 21 14:10:00 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450FE1B33D3 for ; Thu, 21 Jan 2016 14:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vqi4t1FQvNb for ; Thu, 21 Jan 2016 14:09:57 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 89D651AD061 for ; Thu, 21 Jan 2016 14:09:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B5cQD2opdQMg3P6ulhMkI7yjHtsnVL0ptx7qD95tCaPsdnF9LKU8FI0ib0Z23ZT3; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aMNQO-0000NE-2N for netconf@ietf.org; Thu, 21 Jan 2016 17:09:52 -0500 Received: from 76.254.55.96 by webmail.earthlink.net with HTTP; Thu, 21 Jan 2016 17:09:51 -0500 Message-ID: <16305489.1453414191853.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Thu, 21 Jan 2016 14:09:51 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc46a1d00b4242b09b93a144e294a06836350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 Archived-At: Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 22:09:59 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 21, 2016 1:53 PM >To: randy_presuhn@mindspring.com >Cc: netconf@ietf.org >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >Hi, > >Randy Presuhn wrote: >> Hi - >> >> >From: Martin Bjorklund >> >Sent: Jan 21, 2016 3:15 AM >> >To: randy_presuhn@mindspring.com >> >Cc: netconf@ietf.org >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 >> > >> >Randy Presuhn wrote: >> >> Hi - >> >> >> >> >From: Martin Bjorklund >> >> >Sent: Jan 20, 2016 7:00 AM >> >> >To: randy_presuhn@mindspring.com >> >> >Cc: netconf@ietf.org >> >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 >> >> > >> >> >Hi Randy, >> >> > >> >> >Thank you for your review! Comments inline. >> >> > >> >> >Randy Presuhn wrote: > >[...] > >> >> >> 2.1.1 module-set-id >> >> >> >> >> >> There's an ambiguity surrounding the word "unique" here. If the >> >> >> set of modules and submodules reverts to some previous set, is the >> >> >> module-set-id *required* to revert to the corresponding prior value, >> >> >> or is it sufficient for the value to take on a new value every time >> >> >> the set of modules and submodules changes? >> >> > >> >> >Since it is only used to help caching on the client, it is ok if the >> >> >value changes every time the set changes. Do you think this needs to >> >> >be clarified? >> >> >> >> Yes. It's easy to read the existing language as mandating some >> >> kind of implementation-specific guaranteed-collision-free hashing. >> >> It sounds like some much easier to implement and verify would meet >> >> the requirement. >> > >> >Would this be better? >> > >> >OLD: >> > >> > This mandatory leaf contains a unique implementation-specific >> > identifier representing the current set of modules and submodules. >> > This can for example be a checksum of all modules and submodules. >> > >> >NEW: >> > >> > This mandatory leaf contains a unique implementation-specific >> > identifier representing the current set of modules and submodules. >> > >> > The value of this leaf MUST change if the set of modules and >> > submodules in the YANG library changes. There is no requirement >> > that the same set always results in the same module-set-id value. >> >> So far, so good, though I'd prefer "whenever" to "if". > >Ok. > >> > The value can for example be a timestamp or a checksum of all >> > modules and submodules. >> >> This still makes me a bit queasy - checksums are not >> *guaranteed* to change, and it omits the simplest, >> cheapest, and most robust example that comes to mind: >> an integer (with a large potential range) incremented >> with each change. For this to work, it's not sufficient >> that it be merely *highly probable* that the value changes >> when the library changes; it has to be a "sure thing." > >Maybe we should simply remove this "for example" sentence? That would be ok with me. >> Getting a bit beyond the scope of this draft, this leaf presumes >> a polling-based monitoring strategy. Forgive me for thinking >> like an SNMP guy, but wouldn't it scale much better for the >> system to be able to generate a notification whenever this >> piece of information changes? > >For YANG 1.1, the module-set-id is actually presented in the >capability in the message. > >Since the module-set-id is part of a capability, the server will >generate a netconf-capability-change notification (defined in RFC >6470) if the module set changes. This is helpful, but now I'm going to ask a particularly ignorant question: does this explanation necessarily hold true for all protocols used to shovel around information defined using YANG models? That is, do all protocols based on YANG *necessarily* have a "" message and netconf-capability-change notifications? It could be a mistake to treat quirks of the current implementation environments for this model as though they would hold true all future environments in which this model might be employed. On the other hand, if this model is only intended to be used in netconf protocol environments, case closed. :-) Randy From nobody Fri Jan 22 00:38:57 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F81ACD8F for ; Fri, 22 Jan 2016 00:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw0xD9NlNwMD for ; Fri, 22 Jan 2016 00:38:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 092B31ACD8E for ; Fri, 22 Jan 2016 00:38:53 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 13C071AE035C; Fri, 22 Jan 2016 09:38:53 +0100 (CET) Date: Fri, 22 Jan 2016 09:38:55 +0100 (CET) Message-Id: <20160122.093855.1966604606532445328.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <16305489.1453414191853.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> References: <16305489.1453414191853.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 08:38:56 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Jan 21, 2016 1:53 PM > >To: randy_presuhn@mindspring.com > >Cc: netconf@ietf.org > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > > > >Hi, > > > >Randy Presuhn wrote: > >> Hi - > >> > >> >From: Martin Bjorklund > >> >Sent: Jan 21, 2016 3:15 AM > >> >To: randy_presuhn@mindspring.com > >> >Cc: netconf@ietf.org > >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >> > > >> >Randy Presuhn wrote: > >> >> Hi - > >> >> > >> >> >From: Martin Bjorklund > >> >> >Sent: Jan 20, 2016 7:00 AM > >> >> >To: randy_presuhn@mindspring.com > >> >> >Cc: netconf@ietf.org > >> >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >> >> > > >> >> >Hi Randy, > >> >> > > >> >> >Thank you for your review! Comments inline. > >> >> > > >> >> >Randy Presuhn wrote: > > > >[...] > > > >> >> >> 2.1.1 module-set-id [...] > >> Getting a bit beyond the scope of this draft, this leaf presumes > >> a polling-based monitoring strategy. Forgive me for thinking > >> like an SNMP guy, but wouldn't it scale much better for the > >> system to be able to generate a notification whenever this > >> piece of information changes? > > > >For YANG 1.1, the module-set-id is actually presented in the > >capability in the message. > > > >Since the module-set-id is part of a capability, the server will > >generate a netconf-capability-change notification (defined in RFC > >6470) if the module set changes. > > This is helpful, but now I'm going to ask a particularly > ignorant question: does this explanation necessarily hold true > for all protocols used to shovel around information defined > using YANG models? No. I guess we could specify a notification "yang-library-change": notification yang-library-change { description "Generated when the set of modules and submodules supported by the server has changed."; leaf module-set-id { type leafref { path "/yanglib:module/yanglib:module-set-id"; } mandatory true; description "Contains the module-set-id value representing the set of modules and submodules supported at the server at the time the notification is generated."; } } but it is not obvious to me that such a notification would be the correct solution. If a new protocol gets defined that supports some kind of capability discovery, shouldn't that protocol define how capability changes are communicated in that particular protocol? > That is, do all protocols based on YANG > *necessarily* have a "" message and netconf-capability-change > notifications? It could be a mistake to treat quirks of the current > implementation environments for this model as though they would > hold true all future environments in which this model might be > employed. On the other hand, if this model is only intended to > be used in netconf protocol environments, case closed. :-) One of the main ideas with this module is to have a generic mechanism to discovery YANG modules regardless of protocol. Hmm, this statement clearly speaks for a generic notification... /martin From nobody Fri Jan 22 04:13:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240B11A1AB3 for ; Fri, 22 Jan 2016 04:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jeOdo7rfaQd for ; Fri, 22 Jan 2016 04:13:42 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F071A1AAD for ; Fri, 22 Jan 2016 04:13:41 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id oh2so39954197lbb.3 for ; Fri, 22 Jan 2016 04:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B++x8475kWJ5NeB/RNgVBRp72UAQDirHhwKIAVFtb74=; b=wwYMR6W8AgW6O1BEpKD+hZ/JN4m7FkQDXjbMkSLpgomTSK+Z6DQhHw21/3kya+mrdQ K7UqJiNYzhgW3S/uILQJXQlo7sXePVcoSCrbTEtaQNVTYldHWr9J0v/Z2RdHY1VHar9E 1KPiiBI4VSt3yJPolXhqj/+CiC4/zOo9/6zjLtB0LhXQEwUgjJsn78hu3nSY7fHJpO9q PY6EwIc0Pm3QzntxCZaw+kdH8XSWrJDkt2JopYflK6KqDDy6qIah4R3j+EgY7DIyxRwB YMd1OEhTsFcQgGPGwir/0roRFr3j/7/u93JX9rlMxTXsszXz5vlXLU4+KMn7HsjhVfbd ZNxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B++x8475kWJ5NeB/RNgVBRp72UAQDirHhwKIAVFtb74=; b=imh5ERYjRa3veFHFg7EnAAzSxkFHJkEpuOl029sKcFjse6KqFAdXH4gXDYnL+4PD79 tMl/e9qu5APHxsnrSuGkxGh0A+ezytSZGcws6/2s+C6hRPVwTQ3I+Hi5MpdX24CTd2o9 2UGJJoH+8n/6CKJ66GwvmVoU7k0El3XTZVSBqfXVyHJLXDbRNf1kMqfcsA910X2hgorN 1o2m149mMLQdwHVQkQ1yxx37mNXVw6J9x02i7KT7wXNiZYT2jcIN7NkKTjne45J/Hbc+ BK2qy32R4Z/YeJmcB+XBA0RolF1Ak2YetMYyVIKZamQFGn/Y877o1Zin7DgaWV/McWy8 XboA== X-Gm-Message-State: AG10YOQb7J26WAQn1z3LHLLmg/UAedncyem71Ows4c2IwIKfy7wq2Ip4PlFtHrkgZdE8SMfdw0B15LK6ZgKB3Q== MIME-Version: 1.0 X-Received: by 10.112.146.34 with SMTP id sz2mr1118494lbb.96.1453464819803; Fri, 22 Jan 2016 04:13:39 -0800 (PST) Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 04:13:39 -0800 (PST) In-Reply-To: <20160122.093855.1966604606532445328.mbj@tail-f.com> References: <16305489.1453414191853.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <20160122.093855.1966604606532445328.mbj@tail-f.com> Date: Fri, 22 Jan 2016 04:13:39 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b3a85c84741870529eb260f Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 12:13:44 -0000 --047d7b3a85c84741870529eb260f Content-Type: text/plain; charset=UTF-8 Hi, The WG discussed this issue at length and decided not to send 2 notifications for the same thing. That is why the existing event is being used. I don't think anything changed since this decision was made. Andy On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund wrote: > Randy Presuhn wrote: > > Hi - > > > > >From: Martin Bjorklund > > >Sent: Jan 21, 2016 1:53 PM > > >To: randy_presuhn@mindspring.com > > >Cc: netconf@ietf.org > > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > > > > > >Hi, > > > > > >Randy Presuhn wrote: > > >> Hi - > > >> > > >> >From: Martin Bjorklund > > >> >Sent: Jan 21, 2016 3:15 AM > > >> >To: randy_presuhn@mindspring.com > > >> >Cc: netconf@ietf.org > > >> >Subject: Re: [Netconf] RP comments on > draft-ietf-netconf-yang-library-03 > > >> > > > >> >Randy Presuhn wrote: > > >> >> Hi - > > >> >> > > >> >> >From: Martin Bjorklund > > >> >> >Sent: Jan 20, 2016 7:00 AM > > >> >> >To: randy_presuhn@mindspring.com > > >> >> >Cc: netconf@ietf.org > > >> >> >Subject: Re: [Netconf] RP comments on > draft-ietf-netconf-yang-library-03 > > >> >> > > > >> >> >Hi Randy, > > >> >> > > > >> >> >Thank you for your review! Comments inline. > > >> >> > > > >> >> >Randy Presuhn wrote: > > > > > >[...] > > > > > >> >> >> 2.1.1 module-set-id > > [...] > > > >> Getting a bit beyond the scope of this draft, this leaf presumes > > >> a polling-based monitoring strategy. Forgive me for thinking > > >> like an SNMP guy, but wouldn't it scale much better for the > > >> system to be able to generate a notification whenever this > > >> piece of information changes? > > > > > >For YANG 1.1, the module-set-id is actually presented in the > > >capability in the message. > > > > > >Since the module-set-id is part of a capability, the server will > > >generate a netconf-capability-change notification (defined in RFC > > >6470) if the module set changes. > > > > This is helpful, but now I'm going to ask a particularly > > ignorant question: does this explanation necessarily hold true > > for all protocols used to shovel around information defined > > using YANG models? > > No. I guess we could specify a notification "yang-library-change": > > notification yang-library-change { > description > "Generated when the set of modules and submodules supported > by the server has changed."; > leaf module-set-id { > type leafref { > path "/yanglib:module/yanglib:module-set-id"; > } > mandatory true; > description > "Contains the module-set-id value representing the > set of modules and submodules supported at the server at the > time the notification is generated."; > } > } > > but it is not obvious to me that such a notification would be the > correct solution. If a new protocol gets defined that supports some > kind of capability discovery, shouldn't that protocol define how > capability changes are communicated in that particular protocol? > > > That is, do all protocols based on YANG > > *necessarily* have a "" message and netconf-capability-change > > notifications? It could be a mistake to treat quirks of the current > > implementation environments for this model as though they would > > hold true all future environments in which this model might be > > employed. On the other hand, if this model is only intended to > > be used in netconf protocol environments, case closed. :-) > > One of the main ideas with this module is to have a generic mechanism > to discovery YANG modules regardless of protocol. Hmm, this statement > clearly speaks for a generic notification... > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --047d7b3a85c84741870529eb260f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The WG discussed this issue at leng= th and decided not
to send 2 notifications for the same thing.=C2= =A0 That is why the
existing event is being used.=C2=A0 I don'= ;t think anything changed
since this decision was made.


Andy


On Fri, Jan 22, 2016 at 12:38 = AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> Hi -
>
> >From: Martin Bjorklund <mbj@t= ail-f.com>
> >Sent: Jan 21, 2016 1:53 PM
> >To: randy_presuhn@= mindspring.com
> >Cc: netconf@ietf.org
> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-libr= ary-03
> >
> >Hi,
> >
> >Randy Presuhn <= randy_presuhn@mindspring.com> wrote:
> >> Hi -
> >>
> >> >From: Martin Bjorklund <mbj@tail-f.com>
> >> >Sent: Jan 21, 2016 3:15 AM
> >> >To: randy= _presuhn@mindspring.com
> >> >Cc: netconf@ietf.org<= /a>
> >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-= yang-library-03
> >> >
> >> >Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> >> >> Hi -
> >> >>
> >> >> >From: Martin Bjorklund <mbj@tail-f.com>
> >> >> >Sent: Jan 20, 2016 7:00 AM
> >> >> >To: randy_presuhn@mindspring.com
> >> >> >Cc: netconf@= ietf.org
> >> >> >Subject: Re: [Netconf] RP comments on draft-ietf= -netconf-yang-library-03
> >> >> >
> >> >> >Hi Randy,
> >> >> >
> >> >> >Thank you for your review!=C2=A0 Comments inline= .
> >> >> >
> >> >> >Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> >
> >[...]
> >
> >> >> >> 2.1.1 module-set-id

[...]

> >> Getting a bit beyond the scope of this draft, this leaf presu= mes
> >> a polling-based monitoring strategy.=C2=A0 Forgive me for thi= nking
> >> like an SNMP guy, but wouldn't it scale much better for t= he
> >> system to be able to generate a notification whenever this > >> piece of information changes?
> >
> >For YANG 1.1, the module-set-id is actually presented in the
> >capability in the <hello> message.
> >
> >Since the module-set-id is part of a capability, the server will > >generate a netconf-capability-change notification (defined in RFC<= br> > >6470) if the module set changes.
>
> This is helpful, but now I'm going to ask a particularly
> ignorant question: does this explanation necessarily hold true
> for all protocols used to shovel around information defined
> using YANG models?

No.=C2=A0 I guess we could specify a notification "yang-library-change= ":

=C2=A0 notification yang-library-change {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "Generated when the set of modules and submodules= supported
=C2=A0 =C2=A0 =C2=A0 =C2=A0by the server has changed.";
=C2=A0 =C2=A0 leaf module-set-id {
=C2=A0 =C2=A0 =C2=A0 type leafref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 path "/yanglib:module/yanglib:module-set-i= d";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Contains the module-set-id value represen= ting the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set of modules and submodules supported a= t the server at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time the notification is generated."= ;
=C2=A0 =C2=A0 }
=C2=A0 }

but it is not obvious to me that such a notification would be the
correct solution.=C2=A0 If a new protocol gets defined that supports some kind of capability discovery, shouldn't that protocol define how
capability changes are communicated in that particular protocol?

> That is, do all protocols based on YANG
> *necessarily* have a "<hello>" message and netconf-cap= ability-change
> notifications?=C2=A0 It could be a mistake to treat quirks of the curr= ent
> implementation environments for this model as though they would
> hold true all future environments in which this model might be
> employed.=C2=A0 On the other hand, if this model is only intended to > be used in netconf protocol environments, case closed.=C2=A0 :-)

One of the main ideas with this module is to have a generic mechanism
to discovery YANG modules regardless of protocol.=C2=A0 Hmm, this statement=
clearly speaks for a generic notification...


/martin

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

--047d7b3a85c84741870529eb260f-- From nobody Fri Jan 22 07:47:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402841AD0A3 for ; Fri, 22 Jan 2016 07:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t34roZ_L43W6 for ; Fri, 22 Jan 2016 07:47:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC4D1AD0A2 for ; Fri, 22 Jan 2016 07:47:04 -0800 (PST) Received: from muimrel002.emea.nsn-intra.net ([10.159.32.133]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u0MFl2UN018216 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 22 Jan 2016 15:47:02 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by muimrel002.emea.nsn-intra.net (8.14.3/8.14.3) with ESMTP id u0MFl2ts025335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Jan 2016 15:47:02 GMT Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 22 Jan 2016 16:47:02 +0100 Received: from DEMUMBX006.nsn-intra.net ([169.254.6.129]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0248.002; Fri, 22 Jan 2016 16:47:02 +0100 From: "Uveges, Balint (Nokia - HU/Budapest)" To: "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-restconf-09 review comments Thread-Index: AdFUZZ6+noostUYfTXmx1wyDBO+tzA== Date: Fri, 22 Jan 2016 15:47:01 +0000 Message-ID: <28B876C36C5AA84CBAB912BA734FAC35016F21EA@DEMUMBX006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2746 X-purgate-ID: 151667::1453477622-00002F1E-C8B894EA/0/0 Archived-At: Subject: [Netconf] draft-ietf-netconf-restconf-09 review comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 15:47:08 -0000 Hi all, I've reviewed the latest restconf draft and I would like to share my though= ts and comments. Otherwise I think the document is in fairly good shape. 1. XML Examples Through the document I couldn't find that many XML payload examples. Especi= ally the POST (Create Resource Mode) and PUT method lacks of that. I unders= tand that from JSON point of view every HTTP method is covered, but it woul= d greatly enhance the document, if that would be also true for XML. 2. POST (Create Resource Mode) vs. XML Chapter 4.4.1 says: If the target resource type is a datastore or data resource, then the POST is treated as a request to create a top-level resource or child resource, respectively. The message-body is expected to contain the content of a child resource to create within the parent (target resource). If my understanding is correct, that means (taking the example-jukebox modu= le as an example), if I apply a POST on the artist resource to create two n= ew albums, I would have something like this in case of XML encoding, becaus= e it only contains the content of the child resources: POST /restconf/data/example-jukebox:jukebox/ library/artist=3DFoo%20Fighters HTTP/1.1 Host: example.com Content-Type: application/yang.data+xml Wasting Light g:alternative 2011 Sonic Highways g:alternative 2014 But that would result in an XML that is not well formed, since it does not = have one root parameter. My assumption is, that if I create a new resource,= I should also include the parent resource's, like: Wasting Light ...etc, etc... Could you verify which approach is correct? Would it make sense to reflect = that in the document? 3. Status code I have somewhat the feeling, that the Status Code table is not in the right= place in the 7th chapter. The table also contains 1xx and 2xx codes, that = are not about error reporting. Wouldn't it make sense, to move the table to= a separate chapter? Also, the status code 202 Accepted is only mentioned h= ere in the whole document. Shouldn't it receive some extra care? I mean to = describe the semantics behind 202? Thank you, Best regards: -Balint From nobody Fri Jan 22 08:06:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A1D1AD289 for ; Fri, 22 Jan 2016 08:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUCygaVkmlsU for ; Fri, 22 Jan 2016 08:06:27 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DBC1AD277 for ; Fri, 22 Jan 2016 08:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kIvvC4GVcsuPJj91+LV3uD8bToZcx+9OfZH5wp5rfbU=; b=OAWcqsbQnRa2OQD7SiWbRLsM/jJDMFAsBxgW2GvDydflYgbQHgDIVhaG9gsS6odDHay0697J1AC6UjGa2oYopfQm385fdQmm7UFseg2Oiq2kCLvZM90BOnGEw8Y4+72N1iHRfbK5rpRmYWyv+5EMEMW2q8jWF+2pBC4aeX12iTY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 16:06:09 +0000 Message-ID: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> From: t.petch To: t.petch , Date: Fri, 22 Jan 2016 16:03:08 +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: [86.185.87.133] X-ClientProxiedBy: DBXPR04CA0020.eurprd04.prod.outlook.com (10.141.8.148) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 2:gBD5GxW7cfk513iW5Mxxapd1uP12jCBR1Ivd0h5fdxcQRZuxtVpEuD1i8vkDLCs3GgJw6SuyEqyKVBvcw3FB8pO+9oy08HxO/krSENSvq0YZc5qWk2FKJy/zUT9sL3CsmCzjtgRNIP20EEEaHDOFvQ==; 3:BuyKvqk/jj8VLUeeQ7v3g+pXjMlSI5gKwOsK5CR5Ko3C0UIRXBKRb6LofBiw/doWOuhj0jEmtIWDc3BQ9GPdRMiBENLRr0ZQ75cbNU9S5p7gzSR57kMpYMd+LfC7xTXj; 25:j+V/mzNACfQ5kixbaW9ynfXJYMv9ICvdQlcHOOHPOhrOGcWx43ngkaA19vzWX7UP0TLmRes277YsrHKC4iAqyoWUQc3FUSaF72/SZ4rwVqhxD9uqH6KjfvzUrvndFEIxTwFLwaW2S7L3Hidgd39cURU2v6sfz7L5lFMVIr4S0EVq0SL7/8dlbN3SC16e3MJ5GQ1u7diHnc5rA2i9X1ndNWdD5W+zGBEozy99RQYf6B+kOUyACF9GePARtY8jo84Y X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-MS-Office365-Filtering-Correlation-Id: bafa4369-9ac4-4eb7-1c0c-08d32345f108 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 4:sTiiBriH8x77uAjL4mLo3Xz4VKE7j5OVzEDFGgpOqPqoYpllv9JDLwYTssB0e5xMm5NkZdk0HcRvCiaM9fwp8SZWNNQp7Oxv/IqEPQKSsIoQXmQdvs7Lu79ALLFpr9hCcKzvsK8U0aBsHo/F/0jVh+prOZs2jkiumvYxyk2x+1u/4KVQHCVomvsv2/YMtr/IGA8W52SIOd4cERzTLQacciMEIvdcReKNkA+N5EOX06w00o8idJfcWOxB8H4qvL7Hir0xWVYMGiL/6zAJ/Og5f0Qnaq7R9Ctus7+I7hfSoaoQcyVkGm2coyRNYcWUl4maj3BhODSg2jEBBtu3jWvJkiniSu2aBt9R8X9E1h6LsEti7uJudDVzB3dScypYlsKmWXZ0RAOSrH0ajmVNrMc/U6QFzOs17q4p/By+IctXzfwIpeJdImPtQUHzFeTT//U+ X-Forefront-PRVS: 08296C9B35 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(199003)(377454003)(33646002)(44716002)(1556002)(92566002)(81816999)(87976001)(81686999)(50986999)(19580405001)(5004730100002)(5001770100001)(2906002)(50226001)(19580395003)(5001960100002)(86362001)(81156007)(62236002)(14496001)(97736004)(5008740100001)(189998001)(66066001)(230700001)(6116002)(101416001)(105586002)(40100003)(1456003)(61296003)(77096005)(44736004)(42186005)(23756003)(84392002)(3846002)(4326007)(1096002)(106356001)(50466002)(586003)(122386002)(47776003)(230783001)(116806002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB062; 23:/vZezyKLsD2YBC/lCaBiLeaJL0pBn5slIsOMARYx?= =?iso-8859-1?Q?VaYMctHyGfDBwJ8orF34/evwgGybtWuNra6dy1X6wBdwDn+Gd3IrNi4jSm?= =?iso-8859-1?Q?QCsKyXF1D4bvOWx67PFsPcb5eLa1zoLv7pExdMUPTDERmlsi6OHv4FSib1?= =?iso-8859-1?Q?vckviv3MFU+us4ef4PPdGL4sn3A8RqAFb2gw+3SzF6cbhBVFegWlDW7OKN?= =?iso-8859-1?Q?BKbI9gdSsRt1+FkWh9OS+7T5YhMs4r+hStZShh/zp/KdRhu2kxkljxRkJD?= =?iso-8859-1?Q?Cbx0dHgCAJ4uuX5Jh40+YohNPgtx+KRAyyYgtPlyCaQnY2/fQmRCKfj54Q?= =?iso-8859-1?Q?p+YVEBCe/Qx2i0upn4Qp2rrwEIEe+L/+NIz5IafdFjWRbvvdsN+YpZ4msS?= =?iso-8859-1?Q?52qBUQwg57QIJKf6LueXNJHUFlNxNlKs//+pLSymA7WxKZMGHb+U5vjQaK?= =?iso-8859-1?Q?X4UPQMO5ejd/M1RutQfdpbK+LBd/CPSrgPLOlbNra05+w+OBo883Fc0J/2?= =?iso-8859-1?Q?GgYrD6oP13PPHLhg3u8mqvj6eG5hjCp3kDLVp4hnszGtMxEgu6s+Ek99aj?= =?iso-8859-1?Q?ui4nricbQ+hpg61LHgHn61UdshGTRlzUcHeZ8kTlqC890H5cADn1vOjjZs?= =?iso-8859-1?Q?zgfRHY7cDSBZw/FQo1KY1pMTJZaP5V4L0RgYRhFiZFoddCjhsobRZ9+abU?= =?iso-8859-1?Q?h4ZGAh6jpc3+iSZn71kL7u3hDbCHSe1GKXNYQblhd6WePpa3HVQ4j3TL6y?= =?iso-8859-1?Q?+uAV9wRllJt+WWNpuTgzSMwe4gaO2IPylsSqes1a+dRCViuR8jg/zL52JC?= =?iso-8859-1?Q?vuijiQJtHFGhyJYvNUf48OvJQY1x5/Zu9DyQ3lP016eERKcjJ5GivXrojg?= =?iso-8859-1?Q?BgUjME1LtO/Wh7E3eITUZ9BrSAOCOB8VHtoreLkGz/9DZeqn6g/acFCgm9?= =?iso-8859-1?Q?U2WGL0SFq9Uh8zOJPQm0rLBWlFyRGvXFsj/Qs3AbJXHigMSSmrTFkTt3gB?= =?iso-8859-1?Q?wbka+yODo70zW+p+vFoRqZuy+qBpoYv6/dYOySTph3rVK2RTK25NDFvfxm?= =?iso-8859-1?Q?jW9VXl0vFeBcXnNz8FA2EyC4o0RfYz3vdKedByTfqsdwjFTtrFYfxQSEkU?= =?iso-8859-1?Q?iQQXIyYHGYofeaOc3bUCNGE7sKzAyRp9Y3CRmZn/wG0y9ni5R9gdYouN+2?= =?iso-8859-1?Q?3gQYOh6SziOSg9G1Wgesw9h+3Bum9qXFhxYZSdz+DzWSC9qgEt1PnANC7c?= =?iso-8859-1?Q?pc2DaB+ro5JTUCf8NzeqSeCuJFBI7lahY38cKqpmLQgv20p2KL3hiTFmg5?= =?iso-8859-1?Q?0AkTDx76c1RHPwzhcN4Jy/FybSbp0b8mjcSuHXQsEu8QeH3gdkL2wFAUDC?= =?iso-8859-1?Q?ROiDO28=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 5:oqQZPl5Vk1cTP8R/E38bnKm/Ivoiim4q8Dhdbv+GRZ1TVT6lyFxggp6U2u6++xC8rV6M5yQCY4BMpmZgLxMNT82nXCSAtrp/tYpSVgvItozyqPNZU/5DaFBT3mOH+BO5mbrwKCPbqgoYbRnnnpeTww==; 24:yqcZ0jo0yGt/hSekzDl58cGjWRX++W/ZmQx12u66ehafRI1qrSODGFVBtZUbVHzb5lTqmjMPNIkD3h7P0f3QNTAMn6zE54I03DvcTad3f4Y= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2016 16:06:09.0900 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 16:06:32 -0000 Having read all of restconf, I find myself with some fairly basic questions for which I cannot see answers. A) Is restconf an optional extra for a server on top of NETCONF or do you expect there to be restconf-only servers? S.1.3 says that they can coexists, yes, great, marketing. But can you perform useful operational tasks from a restconf-only client to a restconf-only server? I started off assuming you could, but ended up thinking the I-D was telling me that at least the server musy have both e.g. s.12 "it does require that an authenticated NETCONF username be associated with each request" which also begs the question, can there be restconf-only client? Needs specifying IMO, perhaps after thinking through the consequences. B) " the user should not need any prior knowledge of NETCONF in order to use RESTCONF" Well, I wrote 'rubbish' alongside that and taken literally, it is:=) NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the operational infrastructure (configuration, state, datastore, event, error handling, persistence of data. ....) and while the former is replaced, in whole or in part, by restconf, the latter most definitely is not, as exemplified by the definitions imported in s.1.4.1 But that also in untrue. This I-D implies, mostly without being explicit, that it refines NETCONF the operational infrastructure (perhaps using the terms in a different way). Thus it appears that there is no explicit selection of NETCONF datastore but that which one is chosen is implicit. I infer this from s.1.3 but think that it needs separating out more clearly. C) configuration and state; RFC 6241 is very clear about this, this I-D seems to be half way towards whatever resolution netmod comes to on netmod-opstate-reqs, which is probably not a good idea. 'state' I see used only twice, then this undefined 'operational data' takes over and the water is then muddied by 'config' and 'nonconfig'. This is wandering off into its own 'restconf the operational infrastructure' without ever saying AFAICT how it differs from NETCONF. It is as if the three authors each independently wrote parts of the I-D:-) D) Then there are datastores, at least there are until s.4.4.1, when datastore seems to be redefined to mean 'top level node' a term which has surfaced on the (netmod or netconf) mailing list as being something that is not defined and may mean different things to different people. I read the first half of the I-D thinking that 'datastore' is as defined in RFC6241 and then find half way through that I cannot see any way that it is. I note the absence of any examples involving 'application/yang.datastore' and think, well yes, that figures! E) This then calls into question for me the meaning of the term 'data'. In the latter part of the I-D, it seems to be shorthand for 'data or datastore' with datastore having its non-NETCONF meaning but early on, it is used alongside 'datastore' suggesting that it has a more restricted meaning, coupled with the use of different media types, but I cannot tell. So, I have some detailed comments on s.4 onwards but think that the 'beams' need resolving first. Tom Petch ----- Original Message ----- From: "t.petch" To: Cc: Sent: Wednesday, January 20, 2016 6:43 PM Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 From nobody Fri Jan 22 08:32:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090F81ADBFA for ; Fri, 22 Jan 2016 08:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt_5kgY3AUZc for ; Fri, 22 Jan 2016 08:32:51 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F531ADBFB for ; Fri, 22 Jan 2016 08:32:50 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id 17so50398116lfz.1 for ; Fri, 22 Jan 2016 08:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L43sz4hLeILYugzoRULcPooTwqQWqUrGhi+t6WNYZK4=; b=qkAxysimlHgNlcTgNVq1hlDT4JajNS0r5ts77DHUlz+uyYrrTDp3SFHuCAW1+bRePO kpSqXD+u9SmJY/zWRndmzvrHgfXLs7xmdj9UecGIyYLl8q2FBXYQ7IVf16CFnCwdpMUr s7PuR6E/ItdhK3LSZccDtwPirMvcXhQjrHoYwI/S44Di2A+DqjIyeC14sNJFiY1YkHAF 0HUVP+8HtDvQRPSfmFEacUZH5imi+c/SLHTNWuW8YijS1pjI0EmEDjfL2TgDmzxeLI9k dDR1K8pUNQ3a5tIWAKdud6Ofw9wvH7BH++MeEVSOaRRSTVM+95ZQaf2s6LCxvZDz1c5R 21oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L43sz4hLeILYugzoRULcPooTwqQWqUrGhi+t6WNYZK4=; b=DjrEkSHhg8/VBH0oSG+c/PkYsikGRxPqw1vzWUdHgiMqe+HDyW2XehEb5A66uPR01R oiQYwoSrcCQk3NtBI1EPJsS4+8tZUB+mox70Nk5KNetSW6qdQyn4VCyxhtMap+x85e2F l3ZS9rB/Rd2E1nV+ijc7Axau3//sDBuwXQRxQ21uJabRhADMvxKzxxiBHiC5+PpXAi0F oPNdXssTj3pFASOdf8RjmwhpMdxFMNoku/h8B9Uc/AF3PFcB8sOuestr2K0nFkaeOvyp A9dTURcsfWWBEZMz468xubyiHqrM6Bti2eTLLzWPLUZtf62kN1kkgbmi9qUetCHMU9VW ALNQ== X-Gm-Message-State: AG10YOQd0I51cYBPFQ+adUYYldw1PsGThnvOzofE9NVrDA7wMxlpNmSHcnpnZpj6VxPgvKKy7LPTRzvRC8xz2A== MIME-Version: 1.0 X-Received: by 10.25.64.9 with SMTP id n9mr1616740lfa.13.1453480368661; Fri, 22 Jan 2016 08:32:48 -0800 (PST) Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 08:32:48 -0800 (PST) In-Reply-To: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> Date: Fri, 22 Jan 2016 08:32:48 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a113ea4f6100cb60529eec599 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 16:32:53 -0000 --001a113ea4f6100cb60529eec599 Content-Type: text/plain; charset=UTF-8 Hi, Why is it rubbish that there can be a RESTCONF-only server? I can't find any text that says NETCONF MUST be implemented if RESTCONF is implemented. Some details (like defaults handling) are aligned with NETCONF. That doesn't mean the RESTCONF client needs to know much about NETCONF datastores or locks, etc. Andy On Fri, Jan 22, 2016 at 8:03 AM, t.petch wrote: > Having read all of restconf, I find myself with some fairly basic > questions for which I cannot see answers. > > A) Is restconf an optional extra for a server on top of NETCONF or do > you expect there to be restconf-only servers? S.1.3 says that they can > coexists, yes, great, marketing. But can you perform useful operational > tasks from a restconf-only client to a restconf-only server? I started > off assuming you could, but ended up thinking the I-D was telling me > that at least the server musy have both e.g. s.12 > "it does require that an authenticated NETCONF username be associated > with each request" > which also begs the question, can there be restconf-only client? > > Needs specifying IMO, perhaps after thinking through the consequences. > > B) " the user should not need any prior knowledge of NETCONF in order to > use RESTCONF" > Well, I wrote 'rubbish' alongside that and taken literally, it is:=) > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the > operational infrastructure (configuration, state, datastore, event, > error handling, persistence of data. ....) and while the former is > replaced, in whole or in part, by restconf, the latter most definitely > is not, as exemplified by the definitions imported in s.1.4.1 > > But that also in untrue. This I-D implies, mostly without being > explicit, that it refines NETCONF the operational infrastructure > (perhaps using the terms in a different way). Thus it appears that > there is no explicit selection of NETCONF datastore but that which one > is chosen is implicit. I infer this from s.1.3 but think that it needs > separating out more clearly. > > C) configuration and state; RFC 6241 is very clear about this, this I-D > seems to be half way towards whatever resolution netmod comes to on > netmod-opstate-reqs, which is probably not a good idea. 'state' I see > used only twice, then this undefined 'operational data' takes over and > the water is then muddied by 'config' and 'nonconfig'. This is > wandering off into its own 'restconf the operational infrastructure' > without ever saying AFAICT how it differs from NETCONF. It is as if the > three authors each independently wrote parts of the I-D:-) > > D) Then there are datastores, at least there are until s.4.4.1, when > datastore seems to be redefined to mean 'top level node' a term which > has surfaced on the (netmod or netconf) mailing list as being something > that is not defined and may mean different things to different people. > I read the first half of the I-D thinking that 'datastore' is as defined > in RFC6241 and then find half way through that I cannot see any way that > it is. I note the absence of any examples involving > 'application/yang.datastore' > and think, well yes, that figures! > > E) This then calls into question for me the meaning of the term 'data'. > In the latter part of the I-D, it seems to be shorthand for 'data or > datastore' with datastore having its non-NETCONF meaning but early on, > it is used alongside 'datastore' suggesting that it has a more > restricted meaning, coupled with the use of different media types, but I > cannot tell. > > So, I have some detailed comments on s.4 onwards but think that the > 'beams' need resolving first. > > Tom Petch > > ----- Original Message ----- > From: "t.petch" > To: > Cc: > Sent: Wednesday, January 20, 2016 6:43 PM > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113ea4f6100cb60529eec599 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Why is it rubbish that there can be= a RESTCONF-only server?
I can't find any text that says NETC= ONF MUST be implemented
if RESTCONF is implemented.
Some details (like defaults handling) are aligned with NETCONF.=
That doesn't mean the RESTCONF client needs to know much
about NETCONF datastores or locks, etc.=C2=A0


Andy




On Fri, Jan 22, 201= 6 at 8:03 AM, t.petch <ietfc@btconnect.com> wrote:
Having read all of restconf, I find myself with = some fairly basic
questions for which I cannot see answers.

A) Is restconf an optional extra for a server on top of NETCONF or do
you expect there to be restconf-only servers?=C2=A0 S.1.3 says that they ca= n
coexists, yes, great, marketing.=C2=A0 But can you perform useful operation= al
tasks from a restconf-only client to a restconf-only server?=C2=A0 I starte= d
off assuming you could, but ended up thinking the I-D was telling me
that at least the server musy have both e.g. s.12
"it does=C2=A0 require that an authenticated NETCONF username be assoc= iated
with each request"
which also begs the question, can there be restconf-only client?

Needs specifying IMO, perhaps after thinking through the consequences.

B) " the user should not need any prior knowledge of NETCONF in order = to
use RESTCONF"
Well, I wrote 'rubbish' alongside that and taken literally, it is:= =3D)
NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the
operational infrastructure (configuration, state, datastore, event,
error handling, persistence of data. ....) and while the former is
replaced, in whole or in part, by restconf, the latter most definitely
is not, as exemplified by the definitions imported in s.1.4.1

But that also in untrue.=C2=A0 This I-D implies, mostly without being
explicit, that it refines NETCONF the operational infrastructure
(perhaps using the terms in a different way).=C2=A0 Thus it appears that there is no explicit selection of NETCONF datastore but that which one
is chosen is implicit.=C2=A0 I infer this from s.1.3 but think that it need= s
separating out more clearly.

C) configuration and state; RFC 6241 is very clear about this, this I-D
seems to be half way towards whatever resolution netmod comes to on
netmod-opstate-reqs, which is probably not a good idea.=C2=A0 'state= 9; I see
used only twice, then this undefined 'operational data' takes over = and
the water is then muddied by 'config' and 'nonconfig'.=C2= =A0 This is
wandering off into its own 'restconf the operational infrastructure'= ;
without ever saying AFAICT how it differs from NETCONF.=C2=A0 It is as if t= he
three authors each independently wrote parts of the I-D:-)

D) Then there are datastores, at least there are until s.4.4.1, when
datastore seems to be redefined to mean 'top level node' a term whi= ch
has surfaced on the (netmod or netconf) mailing list as being something
that is not defined and may mean different things to different people.
I read the first half of the I-D thinking that 'datastore' is as de= fined
in RFC6241 and then find half way through that I cannot see any way that it is.=C2=A0 I note the absence of any examples involving
'application/yang.datastore'
and think, well yes, that figures!

E) This then calls into question for me the meaning of the term 'data&#= 39;.
In the latter part of the I-D, it seems to be shorthand for 'data or datastore' with datastore having its non-NETCONF meaning but early on,<= br> it is used alongside 'datastore' suggesting that it has a more
restricted meaning, coupled with the use of different media types, but I cannot tell.

So, I have some detailed comments on s.4 onwards but think that the
'beams' need resolving first.

Tom Petch

----- Original Message -----
From: "t.petch" <ietfc@= btconnect.com>
To: <mehmet.ersue@nokia.com>
Cc: <netconf@ietf.org>
Sent: Wednesday, January 20, 2016 6:43 PM
Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09,
draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

<snip>

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

--001a113ea4f6100cb60529eec599-- From nobody Fri Jan 22 09:43:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565EB1B2AFF for ; Fri, 22 Jan 2016 09:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEqVTca4ctjw for ; Fri, 22 Jan 2016 09:43:07 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53801B2AFE for ; Fri, 22 Jan 2016 09:43:06 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id cl12so45202095lbc.1 for ; Fri, 22 Jan 2016 09:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vd3LdaGa6fhPqCivYO0grz2vTCT312U9N90gJ4UhbUU=; b=OdsXpNuMaLC+nc1/XJgCshZ8DqLBbOGGnWvCf6rphVW/6/+qDB4Kc8G84CKJPxpdDl Z+uRgQYizzjz6Q45YKSEIUm1apf7eDYuf6A8N+KPcxk55RepzX22S0eOn5wLrx1Bdej4 zUJwHrWn7yIabQX2ZT8wB7zA6bT5hKharndiMkTM/m/KapMq+AgbCkOit1HpbVrV4ry9 OR7+kzefej1sSk3x42ygc4hoTy4DpQr7AK1OvgJQbpx6CRTJv27VuYnIGCnKxdvB4IkT pFmMF981c9EmRjpv7gJiza+mImeDa7npmd04ooRDOLQfJhNlp1ea+m5zcFsHfRKl+ZkK CYnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vd3LdaGa6fhPqCivYO0grz2vTCT312U9N90gJ4UhbUU=; b=FfIox4/BDobEtObGHrW/c6DEj+JAduylBiKiv1A8EKQs7L9G4+g6n/kn0tBRaQqAhn BP3dQ8kAd7QE3Hv3XHNPrnFvabcwjYIswr6Z94fZRafAZ2klGLe04l/ZbjG20MMtFrA3 75WaTb/9nfAp0kpC+hMkZSEroNBGq8WL6Pqe/BPOWAMqUBAA4BSccGBFQbTulCRXLQdt Sr8ABoj9yCfp7jPukCJnNE1u5qIoqwfQawXS113bhzPruexaumNKyN5qVJvBGyjEuQVU 3GVDXX7E/ZgYB0eVRFX9D0lTunXPS6m1WzEwT5wyMFuoGnTfEfkc4Mndvn5xG0yCv88f H2fA== X-Gm-Message-State: AG10YORBSVtmJ5M2bw++fP8Fpo9Ets0KDlNiQH98+n9uET4ujIqb61F7uE/LniLTH2ZKGeeHbJPo2QcSCzb1Lw== MIME-Version: 1.0 X-Received: by 10.112.147.1 with SMTP id tg1mr1406607lbb.119.1453484585171; Fri, 22 Jan 2016 09:43:05 -0800 (PST) Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 09:43:05 -0800 (PST) In-Reply-To: <28B876C36C5AA84CBAB912BA734FAC35016F21EA@DEMUMBX006.nsn-intra.net> References: <28B876C36C5AA84CBAB912BA734FAC35016F21EA@DEMUMBX006.nsn-intra.net> Date: Fri, 22 Jan 2016 09:43:05 -0800 Message-ID: From: Andy Bierman To: "Uveges, Balint (Nokia - HU/Budapest)" Content-Type: multipart/alternative; boundary=047d7b3a7f5c62d3c00529efc0a3 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-restconf-09 review comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 17:43:09 -0000 --047d7b3a7f5c62d3c00529efc0a3 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 22, 2016 at 7:47 AM, Uveges, Balint (Nokia - HU/Budapest) < balint.uveges@nokia.com> wrote: > Hi all, > > I've reviewed the latest restconf draft and I would like to share my > thoughts and comments. Otherwise I think the document is in fairly good > shape. > > 1. XML Examples > Through the document I couldn't find that many XML payload examples. > Especially the POST (Create Resource Mode) and PUT method lacks of that. I > understand that from JSON point of view every HTTP method is covered, but > it would greatly enhance the document, if that would be also true for XML. > > We can add more examples I guess. Understanding XML or JSON is not really the scope of this document. > 2. POST (Create Resource Mode) vs. XML > Chapter 4.4.1 says: > If the target resource type is a datastore or data resource, then the > POST is treated as a request to create a top-level resource or child > resource, respectively. The message-body is expected to contain the > content of a child resource to create within the parent (target > resource). > > If my understanding is correct, that means (taking the example-jukebox > module as an example), if I apply a POST on the artist resource to create > two new albums, I would have something like this in case of XML encoding, > because it only contains the content of the child resources: > POST /restconf/data/example-jukebox:jukebox/ > library/artist=Foo%20Fighters HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+xml > > > Wasting Light > > g:alternative > > 2011 > > > Sonic Highways > > g:alternative > > 2014 > > > But that would result in an XML that is not well formed, since it does not > have one root parameter. My assumption is, that if I create a new resource, > I should also include the parent resource's, like: > > > Wasting Light > ...etc, etc... > > > Could you verify which approach is correct? Would it make sense to reflect > that in the document? > > You have to use YANG Patch to modify multiple subtrees at once. HTTP/REST allows 1 resource to be altered or retrieved at a time. > 3. Status code > I have somewhat the feeling, that the Status Code table is not in the > right place in the 7th chapter. The table also contains 1xx and 2xx codes, > that are not about error reporting. Wouldn't it make sense, to move the > table to a separate chapter? Also, the status code 202 Accepted is only > mentioned here in the whole document. Shouldn't it receive some extra care? > I mean to describe the semantics behind 202? > > I guess we can change the section name and add more text about 202 Accepted. > Thank you, > Best regards: > -Balint > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --047d7b3a7f5c62d3c00529efc0a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 22, 2016 at 7:47 AM, Uveges, Balint (Nokia - HU/Budapest) <= span dir=3D"ltr"><balint.uveges@nokia.com> wrote:
Hi all,

I've reviewed the latest restconf draft and I would like to share my th= oughts and comments. Otherwise I think the document is in fairly good shape= .

1. XML Examples
Through the document I couldn't find that many XML payload examples. Es= pecially the POST (Create Resource Mode) and PUT method lacks of that. I un= derstand that from JSON point of view every HTTP method is covered, but it = would greatly enhance the document, if that would be also true for XML.


We can add more examples I guess.
Understanding XML or JSON is not really the scope of this document.

=C2=A0
2. POST (Create Resource Mode) vs. XML
Chapter 4.4.1 says:
=C2=A0 =C2=A0If the target resource type is a datastore or data resource, t= hen the
=C2=A0 =C2=A0POST is treated as a request to create a top-level resource or= child
=C2=A0 =C2=A0resource, respectively.=C2=A0 The message-body is expected to = contain the
=C2=A0 =C2=A0content of a child resource to create within the parent (targe= t
=C2=A0 =C2=A0resource).

If my understanding is correct, that means (taking the example-jukebox modu= le as an example), if I apply a POST on the artist resource to create two n= ew albums, I would have something like this in case of XML encoding, becaus= e it only contains the content of the child resources:
=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebox/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 library/artist=3DFoo%20Fighters=C2=A0 HT= TP/1.1
=C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.data+xml

=C2=A0 =C2=A0 =C2=A0<album xmlns=3D"http://example.com/= ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 <name>Wasting Light</name>
=C2=A0 =C2=A0 =C2=A0 <genre xmlns:g=3D"http://example.c= om/ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 g:alternative
=C2=A0 =C2=A0 =C2=A0 </genre>
=C2=A0 =C2=A0 =C2=A0 <year>2011</2011>
=C2=A0 =C2=A0 =C2=A0</album>
=C2=A0 =C2=A0 =C2=A0<album xmlns=3D"http://example.com/= ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 <name>Sonic Highways</name>
=C2=A0 =C2=A0 =C2=A0 <genre xmlns:g=3D"http://example.c= om/ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 g:alternative
=C2=A0 =C2=A0 =C2=A0 </genre>
=C2=A0 =C2=A0 =C2=A0 <year>2014</2011>
=C2=A0 =C2=A0 </album>

But that would result in an XML that is not well formed, since it does not = have one root parameter. My assumption is, that if I create a new resource,= I should also include the parent resource's, like:
=C2=A0 =C2=A0 <artist>
=C2=A0 =C2=A0 =C2=A0 <album xmlns=3D"http://example.com= /ns/example-jukebox">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>Wasting Light</name>
=C2=A0 =C2=A0 ...etc, etc...
=C2=A0 =C2=A0 </artist>

Could you verify which approach is correct? Would it make sense to reflect = that in the document?


You have to use YANG Patch to modify m= ultiple subtrees at once.
HTTP/REST allows 1 resource to be alter= ed or retrieved at a time.

=C2=A0
3. Status code
I have somewhat the feeling, that the Status Code table is not in the right= place in the 7th chapter. The table also contains 1xx and 2xx codes, that = are not about error reporting. Wouldn't it make sense, to move the tabl= e to a separate chapter? Also, the status code 202 Accepted is only mention= ed here in the whole document. Shouldn't it receive some extra care? I = mean to describe the semantics behind 202?


I guess we can change the section name= and add more text about 202 Accepted.

=C2=A0
Thank you,
Best regards:
-Balint



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

--047d7b3a7f5c62d3c00529efc0a3-- From nobody Fri Jan 22 10:18:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886BD1B2B5D for ; Fri, 22 Jan 2016 10:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D12s20rYXG2m for ; Fri, 22 Jan 2016 10:18:31 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCBA1B2B4D for ; Fri, 22 Jan 2016 10:18:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=i8wqw65MAUx/T2AlyqX96hpn0wAdvIui6dbTyFAhzWnSXnK4P37705elU0duFtwp; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aMgHq-0003EG-OW for netconf@ietf.org; Fri, 22 Jan 2016 13:18:18 -0500 Received: from 76.254.54.237 by webmail.earthlink.net with HTTP; Fri, 22 Jan 2016 13:18:18 -0500 Message-ID: <27941932.1453486698803.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Fri, 22 Jan 2016 10:18:18 -0800 (GMT-08:00) From: Randy Presuhn To: Netconf Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc25d79719c1b20b3601927e51db3269db350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:18:33 -0000 Hi - The point is that the consequence of that decision is to impose a requirement on any future protocol making use of this model. Since this model's applicability is stated as essentially anything using YANG-based data models, that seems like a rather large swath of collateral damage. Randy -----Original Message----- From: Andy Bierman Sent: Jan 22, 2016 4:13 AM To: Martin Bjorklund Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 Hi, The WG discussed this issue at length and decided notto send 2 notifications for the same thing. That is why theexisting event is being used. I don't think anything changedsince this decision was made. Andy On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund wrote: Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Jan 21, 2016 1:53 PM > >To: randy_presuhn@mindspring.com > >Cc: netconf@ietf.org > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > > > >Hi, > > > >Randy Presuhn wrote: > >> Hi - > >> > >> >From: Martin Bjorklund > >> >Sent: Jan 21, 2016 3:15 AM > >> >To: randy_presuhn@mindspring.com > >> >Cc: netconf@ietf.org > >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >> > > >> >Randy Presuhn wrote: > >> >> Hi - > >> >> > >> >> >From: Martin Bjorklund > >> >> >Sent: Jan 20, 2016 7:00 AM > >> >> >To: randy_presuhn@mindspring.com > >> >> >Cc: netconf@ietf.org > >> >> >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > >> >> > > >> >> >Hi Randy, > >> >> > > >> >> >Thank you for your review! Comments inline. > >> >> > > >> >> >Randy Presuhn wrote: > > > >[...] > > > >> >> >> 2.1.1 module-set-id [...] > >> Getting a bit beyond the scope of this draft, this leaf presumes > >> a polling-based monitoring strategy. Forgive me for thinking > >> like an SNMP guy, but wouldn't it scale much better for the > >> system to be able to generate a notification whenever this > >> piece of information changes? > > > >For YANG 1.1, the module-set-id is actually presented in the > >capability in the message. > > > >Since the module-set-id is part of a capability, the server will > >generate a netconf-capability-change notification (defined in RFC > >6470) if the module set changes. > > This is helpful, but now I'm going to ask a particularly > ignorant question: does this explanation necessarily hold true > for all protocols used to shovel around information defined > using YANG models? No. I guess we could specify a notification "yang-library-change": notification yang-library-change { description "Generated when the set of modules and submodules supported by the server has changed."; leaf module-set-id { type leafref { path "/yanglib:module/yanglib:module-set-id"; } mandatory true; description "Contains the module-set-id value representing the set of modules and submodules supported at the server at the time the notification is generated."; } } but it is not obvious to me that such a notification would be the correct solution. If a new protocol gets defined that supports some kind of capability discovery, shouldn't that protocol define how capability changes are communicated in that particular protocol? > That is, do all protocols based on YANG > *necessarily* have a "" message and netconf-capability-change > notifications? It could be a mistake to treat quirks of the current > implementation environments for this model as though they would > hold true all future environments in which this model might be > employed. On the other hand, if this model is only intended to > be used in netconf protocol environments, case closed. :-) One of the main ideas with this module is to have a generic mechanism to discovery YANG modules regardless of protocol. Hmm, this statement clearly speaks for a generic notification... /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Jan 22 16:50:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44ED1B2E2B for ; Fri, 22 Jan 2016 16:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGZhX2_778Pi for ; Fri, 22 Jan 2016 16:50:06 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7431F1B2E47 for ; Fri, 22 Jan 2016 16:50:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=DtVwEanDiA4KXg827+qslitcqnsizYsIMLpjvN/dNCUYeiLB8Rzz2EPAxXrp1C0u; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aMmOp-0006ll-8x for netconf@ietf.org; Fri, 22 Jan 2016 19:49:55 -0500 Received: from 76.254.54.237 by webmail.earthlink.net with HTTP; Fri, 22 Jan 2016 19:49:55 -0500 Message-ID: <30633625.1453510195305.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Fri, 22 Jan 2016 16:49:55 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc77f5882d13c6e40614d29432fde2b78a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: Subject: [Netconf] RP partial comments on draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 00:50:10 -0000 Hi - Here are my partial comments on draft-ietf-netconf-restconf-09. I promised to have something by today, but was not able to get through the entire document - it's slow going for a non-netconf person! General stylistic comment: The tone of the opening portions of the draft seemed like marketing rather than specification. Some passages may have been intended to provide the rationale for specific design decisions, but lacked the context and level of detail needed to be useful to someone considering implementation, deployment, or use of this technology. Serious, easily fixed problem: The draft is filled with occurrances of "‑" As far as I can tell, every single one of theme should be replaced with "-". Section 1: Third paragraph: the all-caps term RESTCONF is instroduced without definition or acronym expansion. Why all-caps? Section 1.1: First paragraph: Requirements without justification or clear motivation (e.g. "does not need to mirror the functionality of the NETCONF protocol") and ones that are unduly vague (e.g. "needs to be compatible with NETCONF" - which BTW seems to directly contradict the previous stated requirement) are not helpful. Suggest rephrasing in terms of what this protocol *is* or *does*, rather than waving around ill-defined requirements. Second paragraph: "Edits are usually applied to one data resource instance at a time." The word "usually" provides no guidance and has no normative force. This statement isn't helpful, so I suggest deleting it. Third paragraph: "The base RESTCONF protocol is intentionally simple to allow deployment for as many use cases as possible." How does simplicity increase the number of use cases that can be addressed? Fourth paragraph: The term/acronym "REST" is used without prior definition or reference. Section 1.2 First paragraph: The term acronym "HATEOAS" is used without prior definition or reference. I found this paragraph is general to be quite unhelpful - it doesn't say how this protocol does anything, yet brings in undefined terms, e.g. "resource endpoint". I suggest deleting the paragraph. Second paragraph: This paragraph describes a strategy *not* employed by this protocol. This is not helpful information. Delete it. Third paragraph: This adds nothing to the specification. Delete it. Fifth paragraph: What is this paragraph trying to say? For SNMP, the location of information is very much tied down by the schema. I don't get the point of whatever contrast the authors are trying to draw here. Sixth paragraph: The introduction talked about datastoreS, but this paragraph and the following make it sound like there is only a single datastore. Which will it be? Section 1.3 Second paragraph: "The candidate is automatically committed to running after a successful edit." Replace "a" with "each" - that's what's meant, right? Third paragraph: "after" - leads to two questions: "how long after?" and "after each edit?" page 10 "HTML5" - no reference? From context, assume this should be a normative reference. 2.3 The text considers three of four possibilities. What happens in the case not spelled out, to wit, when X.509 certificate path validation fails and the presented X.509 certificate *DOES* match a locally configured certificate fingerprint? 2.5 Second paragraph - this seems like an inappropriate use of MUST, at least as the text is currently structured. The first sentence says something must be done in one of two ways. The next sentence that an implementation-specific approach is also allowed. That means the "MUST" is really an option, so using "MUST" doesn't make sense. Third paragraph - "RESTCONF client identity" perhaps my SNMP orientation is showing, but for purposes of access control, wouldn't one want to draw a clear distinction between "client identity" and *user* identity? Both matter, but it seems to me that they're different things. 3 First paragraph: "Each resource represents a manageable component within the device." Is this intended to prohibit the use of this protocol to manage components external to the device, as in various kinds of proxy? It seems that this would interact badly with the various "mount" proposals. Does this require that the manageable component actually exists? if not, then perhaps it might be better to say something like "potential manageable component" Second paragraph: what is "conceptual" data? Third paragraph: "A resource has its own media type identifier..." are the words "its own" intended to convey some meaning other than "a"? Fourth paragraph: "All RESTCONF resources are defined in this document..." It sounds like "resource types" is intended. Last paragraph: I'm not able to reconcile this paragraph with the immediately following section, number 3.1. If this paragraph *is* correct, how does it interract with the various moutn point proposals? 3.1 First paragraph: the "MUST" seems overstated. Failure to execute this step in this manner does not necessarily result in a failure to interoperate. At most this should be a "SHOULD", and even then it seems contrary to RFC 2119's guidance to be sparing in the use of these words. Second paragraph: "Once discovering the RESTCONF API root" The English is broken. 3.3.2 Since this facility is described as *COMPLETELY* optional, it does nothing to foster interoperability. Either change the "MAY" in the second paragraph to a "MUST", or remove this section. 3.4 I'm having a hard time reconciling the straightforward notion of datastore presumed by this section with the rather baroque facilities needed to support some of the alternatives being discussed with regard to operational / state data. In particular, I'm worried about the "all" in the statement that "[t]he RESTCONF datastore resource is a conceptual collection of all configuration and operational data that is present". To me this implies the ability to explicity distinguish / access, for example, both "intended" and "applied" versions of a configuration parameter. The phrase "on the device" seems to be intended to exclude use with proxy technologies. 3.4.1 This is in the datastore resource section, but talks about the data resources. This seems odd. Why are two mechanisms mandated? Why is no comparable mechanism provided for non-configuration data? 3.4.1.1 The text describing the maintenance of last-modified seems incomplete. As a read the current text, in a server maintaining only a timestamp for a parent resource, modification of a child resource's configuration data doesn't cause the parent's timestamp to change. I think these algorithms make some big unspoken assumptions about timestamp propagation within a tree. 3.4.1.2 Same comment as for 3.4.1.1 3.5 "For configuration data resources, the server MAY maintain a last- modified timestamp for the resource, and return the "Last-Modified" header when it is retrieved with the GET or HEAD methods." Making returning the "Last-Modified" header OPTIONAL here seems at odds with 3.4.1.1. Likewise for etags and 3.4.1.2. Last paragraph: what is the resource definition version in the case of an undated module? 3.5.1 Third bullet - shouldn't there be an "=" in there somewhere, as there is in the second bullet for the single-key case and as shown in the example? 3.6 "If the "action" or "rpc" statement has an "input" section, then a message-body MAY be sent by the client in the request, otherwise the request message MUST NOT include a message-body." This seems odd. Why is the MAY only a MAY? If the action/rpc has an input section, what does it mean to omit the message-body? Why is the MUST NOT *necessary*? What would *break* if such an unexpected message-body were sent? "If the operation is successfully invoked, and if the "action" or "rpc" statement has an "output" section, then a message-body MAY be sent by the server in the response, otherwise the response message MUST NOT include a message-body in the response message, and MUST send a "204 No Content" status-line instead." This, too, seems odd. Why is the message-body optional for actions/ rpcs with output statements? What does it mean when the message body is omitted in such cases? Why is the MUST NOT *necessary*? What *breaks* if an unexpected (empty) message-body is sent? "If the operation is not successfully invoked, then a message-body SHOULD be sent by the server, containing an "errors" resource, as defined in Section 3.9." Is this intended to mean that it would be ok for the server to give no response at all, or to give a message-body containing some other information? 3.6.3 is what is here called an '"errors" data structure' the same thing as what is called an '"errors" resource' earlier in the document? 3.9 How does one reconcile this explanation with earlier references in the document to an '"errors resource"? Section 4 Fourth paragraph: Is it really intended to make access control OPTIONAL? This seems a serious shortcoming, and seems somewhat at odds with the fifth paragraph. 4.1 What is the interoperability benefit of making this facility optional? Suggest making it mandatory or removing it altogether. Third paragraph: is this intended to mean that support for OPTIONS is MANDATORY whenever PATCH is supported? 4.3 Third paragraph: "an error response containing a "403 Forbidden" or "404 Not Found" status-line is returned to the client." How does the server decide which of these two? Consistently returning 404 would fit the SNMP world-view. 4.4.1 "an error response containing a "403 Forbidden" or "404 Not Found" status-line is returned to the client." How does the server decide? Consistently returning 404 would seem to leak less. 4.4.2 " an error response containing a "403 Forbidden" or "404 Not Found" status-line is returned to the client" Pick one. 4.5 "If an existing resource is modified, either "200 OK" or "204 No Content" are returned." Pick one or give the criteria for deciding which one to use. "an error response containing a "403 Forbidden" or "404 Not Found" status-line is returned to the client" Pick one or give the criteria for deciding between them. 4.6 "a "403 Forbidden" or "404 Not Found" status-line is returned to the client." Pick one or give criteria for deciding which to use. 4.7 "a "403 Forbidden" or "404 Not Found" status-line is returned to the client." Pick one or give criteria for deciding which to use. Section 10: This section strikes me as rather odd. It feels like it's using some HTTP-specific hacks to accomplish query optimizations that more properly should have been done through the information model. Section 10.1.1 paragraph 3: "The server MAY maintain a last-modified timestamp for each instance of this list entry, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. If not supported then the timestamp for the parent "modules" container MAY be used instead." This text baffles me. Section 10.1 makes support for timestamping "modules" mandatory. The second sentence here makes it optional. This makes no sense. I suggest deleting the second sentence. paragraph 4: "The server MAY maintain an entity-tag for each instance of this list entry, and return the "ETag" header when this data node is retrieved with the GET or HEAD methods. If not supported then the timestamp for the parent "modules" container MAY be used instead." Likewise baffling. Delete the second nonsensical sentence. Section 11.1 Why both "RFCXXXX" and "RFC XXXX"? Section 11.3 Does the "xxx" have any relationship to the "XXXX" in this section? Section 12 Last paragraph: "Note that authorization information can be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection." I think "authentication" rather than "authorization" is intended here. Did not look at appendix A or appendix B. Do not have tools to verify appendix C or D, made no attempt to manually work through all that stuff. Randy From nobody Fri Jan 22 19:11:47 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C201B3022 for ; Fri, 22 Jan 2016 19:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_71nAvFGGex for ; Fri, 22 Jan 2016 19:11:40 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3F21B3021 for ; Fri, 22 Jan 2016 19:11:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: Date: Fri, 22 Jan 2016 22:11:43 -0500 Message-ID: <001601d1558b$c9b3bd70$5d1b3850$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01D15561.E0E4E160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdFVdNwAA5f/EL9GRVWMHZjEZL6JIg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jgs@bgp.nu Subject: [Netconf] read-through comments on draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 03:11:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0017_01D15561.E0E4E160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, Martin, Ken: My read through comments have 4 parts: status, minor issues, editorial, and i2rs-related comments. The I2RS-related comments are only to show that ephemeral state can be added incrementally to this design. I hope these comments will help progress RESTCONF quickly! Sue =================================== Section 1: Status: Almost Ready to be publish, minor issues/editorial nits ========== Section 2: Minor issues: +2.1 - what other protocols than TLS are possible for HTTP for RESTCONF [Joe Clarke Fri 1/8/2016 2:10 PM also mentions] +3.4.1 - This is Edit Collision detection for the {+restconf}/data nodes by the server for Patch entities may be useful for I2RS (see I2RS comments below). What is not clear from the text is whether you can have a tree +--rw data-level-1 time-stamp, Entity-Tag +--rw data-level-2 Entity-Tag [no time stamp] +--rw data-level 3 Time stamp [no entity] +--rw data-level 4 Time-stamp, Entity tag If you must a continuous line of ancestors with time-stamp (levels 1-3) to have level 4, then this must be explained. Likewise if you must have a continuous line of ancestors for Entity-Tag, then this must be explained. +3. Section 4.6 - there is a plain patch, but no mention is made of a more complicated patch. Is this on purpose, or did you want to refer to another draft? +4. List actions that apply to all list entries: GET, DELETE, sequence of PATCHes for a list (multiple entries from Lada (+1 on Lada: Mon 1/11/2016 5:36 AM), +5 Application of multiple filters in order for Query plus start-time/stop time. Is this possible? +6 - Does Data timestamp and E-Tag apply to operational state data? +--rw restconf +--rw data +--rw config-data +--ro oper-state-data +--rw operations +7: You do not mention leaf-lists (this is +1 on Lada Mon 1/1/2016 5:36AM comment). +8: CAN RESTCONF and NETCONF both attach to a data store? If so the question regarding netconf lock (persist-id), and RESTCONF edit collisions Needs to be reference in section n3.4.1. If not, it needs to be clearly stated (+1 Martin Bjorklund's comment on revising locking 1/8/2016 9:45pm) (see Tom Petch's comment A) on 1/22/2016 at 11:20am) +9: +1 on Security review that more needs to be in the security section. . It would be helpful to consider whether the I2RS extensions suggested below might break the data security of RESTCONF. I believe RESTCONF will fulfill the I2RS protocol security requirements minus the ephemeral state (not created yet). . Note that Tom Petch (comment A on 1/22/2016 at 11:20am) - asks if "authenticated NETCONF username [MUST] be associated with each request". . NACM is clearly specified in order to allow some filtering of results, but the link to authenticated NETCONF user name is not as strongly linked. Since I2RS has suggested NACM may prevent some DoS attacks, this may be useful. +10- +1 on (Rodney Cummings 1/11/2016 5:30pm) - we should have a capability that indicates if we can pull module schema if this is optional. Security may restrict a full pull of the module schema if there is a module augmentation by a vendor that has security add-ons. +11 - Since insert and point is required for PUT/POST on the server, can modules be designed that do not support it? The comment from Rodney Cummings 1/11/2016 5:30pm] surprised me. Can this be explained or defined some-how? If modules do not support it for lists, then please explain the error handling. +12 - +1 to Robert Wilton's question on http 1.2? Section 2.1 specifies http 1.1 [RFC7230]. Will RESTCONF run over HTTP 1.2? I did not find any restrictions on http 1.1 pipelining. Does this mean that RESTCONF can access different parts of a tree via two different sessions? What happens if overwrites - Last one wins edit collisions - unless you have the model timestamp and ETAG ID flags on? +13 - +1 on the question or edit ordering from Robert Wilton [1/19/2016 5:46am] +14 - +1 - where netmod-opsstate-reqs fit into this document? It would be good to determine if the module that is "read-only" can get a query such as "op-state-only". It would be good to query for multiple flags (op-state, with-default, ephemeral). Have you considered how you will merge this in? It would be good if these would be incremental upgrades. ========= Section 3: Editorial issues: ============================= #1 Multiple places /operational data/operational state data/ [+ to Lada: Mon 1/11/2016 5:36am concern, but different resolution] #2 p. 6: HATEOAS ( at least deserves an expansion, and a definition) since it is the scheme you are not choosing. (+1 on Lada: Mon 1/11/2016 5:36 AM), #3 p. 10: ABNF - first time ABNF is used, it should be expanded. #4 p. 25 - In section 3.6.3 in paragraph 2 /Using the "reset" operation/ Using the "reset" operation from the example in section 3.6 #5 p. 30 section 4.4.1 paragraph 2 from /The "insert" and the "point query parameters are supported by the POST method for data store and data resource types, as specified in the yang definition in section 8./ /The "insert (section 4.8.4) and the "point" (section 4.8.5) are supported by the POST method for data store and data resource types, as specified in the yang definition in section 8./ #6: [Lada's comments] = +1 on most of Lada's editorial comments [Lada Monday 1/10/2016 5:36am] ===================================== Section 4 - I2RS and ephemeral state. ----------------- #1 - expanding the Query and PUT/PATCH to allow for ephemeral state in Data Store per node a) Expand Query's "content" and create a "with-ephemeral" to allow for query of Ephemeral state. Expanding b) Expand PUT content to allow ephemeral RESTCONF allows access via API to data (datastore) and operations. The data store has Allows default data for a node. If one considers ephemeral to apply to a node, and Entries under it - then the treatment of "default" (section 4.8.9) may be useful as a template for ephemeral. Recently, I have reviewed BGP and found Session ephemeral state (BGP Flow Specification, and BGP QoS SLA state) which terminates if peer goes down. There are two types of ephemeral: reboot ephemeral and session ephemeral. Let me give the example with packet forwarding filter (a filter) which can have two types of ephemeral nodes: I2RS FB-RIB filter, BGP Flow Specification filters, as well a configuration filter (ACL or packet-reception-filter-Condition-Action rule). +--rw restconfig +--rw data +--rw configuration +--filter-list* [name] +--rw name +--rw Filter | +--value | +--rw default-value | +--rw config-store-value | +--rw ephemeral-reboot-value | +--rw ephemeral-session-value | +--rw value-type - flag on what is in value | default, config-stored-value, | ephemeral-reboot-value, | ephemeral-session-value | +--rw precedence-order (default, different order) | (this provides either a precedence or different order) +--ro oper-state +--ro Filter-1 | +--ro value-type - type currently runing | +--ro pkt-match-count +--rw operations +--- The value - could be set from default value, config-store value, ephemeral-reboot-value, or ephemeral-session value. The "value-type" gives the type set in the node. Expansion of command: . If we expand the Query concepts of "content (section 4.8.1) or create a "with-ephemeral", you can utilize the Query to get specific ephemeral state. . If you expand the concepts in PUT/Patch to allow to set the ephemeral notes. #2- RESTCONF Collision handling vs. I2RS Collision handling . Timestamp and E-Tag - provide the when and who . I2RS collision uses - when, who, and priority - Since 1 user has 1 priority per session, I think we could simply link the "E-Tag" to a Priority table? . Alternatively, we could just create a third collision resource for I2RS. The reason for this discussion is to point out, we could just augment existing RESTCONF to support I2RS requirements. #3 - if you create an ephemeral data store rather than ephemeral nodes, will ------=_NextPart_000_0017_01D15561.E0E4E160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy, = Martin, Ken:

 

My read through comments have 4 parts:  status, = minor issues, editorial, and i2rs-related comments.  The = I2RS-related comments are only to show that ephemeral state can be added = incrementally to this design.   I hope these comments will = help progress RESTCONF quickly!

 

Sue =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Section 1: =  Status: Almost Ready to be publish, minor issues/editorial = nits

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Section 2: Minor issues:

+2.1 –  what other protocols than TLS are = possible for HTTP for RESTCONF

       =      [Joe Clarke Fri 1/8/2016 2:10 PM also = mentions]

 

+3.4.1 -  This is Edit Collision detection for = the {+restconf}/data nodes by the server for Patch = entities

         &= nbsp;      may be useful for I2RS (see I2RS = comments below).  What is not clear from the text is whether you = can

         &= nbsp;     have a tree

         &= nbsp;           &n= bsp;          +--rw = data-level-1 time-stamp, Entity-Tag

         &= nbsp;      =             &= nbsp;     +--rw data-level-2  Entity-Tag [no = time stamp]

         &= nbsp;           &n= bsp;           &nb= sp;  +--rw data-level 3  Time stamp [no = entity]

         &= nbsp;           &n= bsp;           &nb= sp;       +--rw data-level 4  = Time-stamp, Entity tag

 

         &= nbsp;      If you must a continuous line of = ancestors with time-stamp (levels 1-3) to have level 4, then this must = be explained.

         &= nbsp;    Likewise if you must have a continuous line of = ancestors for Entity-Tag, then this must be explained.

 

+3. Section = 4.6 – there is a plain patch, but no mention is made of a more = complicated patch.   Is this on purpose, or did you want to = refer to another draft?

 

+4. List = actions that apply to all list entries: GET, DELETE, sequence of PATCHes = for a list (multiple entries from Lada (+1 on Lada: Mon 1/11/2016 5:36 = AM),

 

+5 Application of multiple filters in order for Query = plus start-time/stop time.  Is this possible?

 

+6 – = Does Data timestamp and E-Tag apply to operational state data? =

 +--rw = restconf

     = +--rw data

         += --rw config-data

         = +--ro  oper-state-data

     +--rw operations =

 

+7: You do not mention leaf-lists (this is +1 on Lada = Mon 1/1/2016 5:36AM comment).

 

+8: CAN = RESTCONF and NETCONF both attach to a data store?

      If so the question = regarding netconf lock (persist-id), and RESTCONF edit = collisions

      Needs to be reference = in section n3.4.1.  If not, it needs to be clearly = stated

     (+1 = Martin Bjorklund’s comment on revising locking 1/8/2016 9:45pm) =  

     (see Tom Petch’s = comment A) on 1/22/2016 at 11:20am)

 

+9: +1 on = Security review that more needs to be in the security section. =

·         = It would be helpful to consider whether = the I2RS extensions suggested below might break the data security of = RESTCONF.  I believe RESTCONF will fulfill the I2RS protocol = security requirements minus the ephemeral state (not created yet). =

·         = Note that Tom Petch (comment A on = 1/22/2016 at 11:20am) – asks if “authenticated NETCONF = username [MUST] be associated with each request”.  =

·         = NACM is clearly specified in order to = allow some filtering of results, but the link to authenticated NETCONF = user name is not as strongly linked.   Since I2RS has = suggested NACM may prevent some DoS attacks, this may be useful. =

 

+10- +1 on (Rodney Cummings 1/11/2016 5:30pm) – = we should have a capability that indicates if we can pull module schema = if this is optional.  Security may restrict a full pull of the = module schema if there is a module augmentation by a vendor that has = security add-ons.

 

+11 – = Since insert and point is required for PUT/POST on the server,  can = modules be designed that do not support it?  The comment from = Rodney Cummings 1/11/2016 5:30pm] surprised me.  Can this be = explained or defined some-how?  If modules do not support it for = lists, then please explain the error handling.

 

+12 - +1 to = Robert Wilton’s question on http 1.2?  Section 2.1 specifies = http 1.1 [RFC7230].   Will RESTCONF run over HTTP 1.2?  I = did not find any restrictions on http 1.1 pipelining.  Does this = mean that RESTCONF can access different parts of a tree via two = different sessions?   What happens if overwrites – Last = one wins edit collisions – unless you have the model timestamp and = ETAG ID flags on?

 

+13 - +1 on = the question or edit ordering from Robert Wilton [1/19/2016 5:46am] =

 

+14 - +1 – where netmod-opsstate-reqs fit into = this document? It would be good to determine if the module that is = “read-only” can get a query such as = “op-state-only”.   It would be good to query for = multiple flags (op-state, with-default, ephemeral).   Have you = considered how you will merge this in? It would be good if these would = be incremental upgrades.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Section 3: = Editorial issues:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

#1 = Multiple places /operational data/operational state data/ =

[+ to Lada: Mon 1/11/2016 5:36am = concern, but different resolution]

 

#2 p. 6: = HATEOAS ( at least deserves an expansion, and a definition) since it is = the scheme you are not choosing.   (+1 on Lada: Mon 1/11/2016 = 5:36 AM),

#3 p. 10: ABNF =  – first time ABNF is used, it should be expanded. =  

#4 p. 25 – In section = 3.6.3 in paragraph 2 

/Using = the “reset” operation/ Using the “reset” = operation from the example in section 3.6

 

#5 p. 30 = section 4.4.1 paragraph 2

from /The = “insert” and the “point query parameters are supported = by the POST method

for data store = and data resource types, as specified in the yang definition in section = 8./

 

/The “insert (section 4.8.4) and the = “point” (section 4.8.5) are supported by the POST method =

for data store and data resource = types, as specified in the yang definition in section = 8./

 

#6: [Lada’s comments] =3D +1 on most of = Lada’s editorial comments [Lada Monday 1/10/2016 5:36am] =

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Section 4 = – I2RS and ephemeral state.

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

#1 – expanding the Query and PUT/PATCH to allow = for ephemeral state in Data Store per node

 

a)      = Expand Query’s “content” and = create a “with-ephemeral” to allow for query of Ephemeral = state.  Expanding

b)      = Expand PUT content to allow ephemeral =

 

RESTCONF allows access via API to data (datastore) and = operations.  The data store has

Allows default data for a node.   If one = considers ephemeral to apply to a node, and

Entries under it – then the treatment of = “default” (section 4.8.9) may be useful as a template for = ephemeral.

 

Recently, I have reviewed BGP and found Session = ephemeral state (BGP Flow Specification, and

BGP QoS SLA state) which terminates if peer goes = down.  There are two types of ephemeral: reboot ephemeral and = session ephemeral.  Let me give the example with packet forwarding = filter (a filter) which can have two types of ephemeral nodes: I2RS = FB-RIB filter, BGP Flow Specification filters, as well a configuration = filter (ACL or packet-reception-filter-Condition-Action = rule).

 

+--rw restconfig

    +--rw data

        +--rw = configuration

        =     +--filter-list* [name]

         &= nbsp;     +--rw name

         &= nbsp;     +--rw Filter

          =      |  +--value 

         &= nbsp;     |  +--rw default-value =

         &= nbsp;     |  +--rw  = config-store-value

         &= nbsp;     |  +--rw ephemeral-reboot-value =

         &= nbsp;     |  +--rw ephemeral-session-value =

         &= nbsp;     |  +--rw value-type – flag = on what is in value

         &= nbsp;     |     =     default, config-stored-value,

         &= nbsp;   =   |         = ephemeral-reboot-value,

         &= nbsp;     |       =   ephemeral-session-value

         &= nbsp;     |  +--rw precedence-order = (default, different order)

         &= nbsp;    |       (this = provides either a precedence or different order)  

         += --ro  oper-state

         &= nbsp;    +--ro Filter-1

         &= nbsp;    |  +--ro value-type – type = currently runing

         &= nbsp;    |  +--ro pkt-match-count =

    +--rw = operations

        +---

 

The value – could be set from default value, = config-store value, ephemeral-reboot-value, or ephemeral-session = value.  The “value-type” gives the type set in the = node. 

 

Expansion of command:

·         = If we expand the Query concepts of = “content (section 4.8.1) or create a “with-ephemeral”, = you can utilize the Query to get specific ephemeral state. =

·         = If you expand the concepts in PUT/Patch = to allow to set the ephemeral notes.

 

#2- RESTCONF = Collision handling  vs. I2RS Collision handling

·         = Timestamp and E-Tag – provide the = when and who

·         = I2RS collision uses -  when, who, = and priority –

Since 1 user has 1 priority per session, I = think

we could simply link the = “E-Tag” to a Priority table?

·         = Alternatively, we could just create a = third collision resource for I2RS.

 

The reason = for this discussion is to point out, we could just augment existing = RESTCONF to support I2RS requirements.

 

 

#3 – = if you create an ephemeral data store rather than ephemeral nodes, will =

 

 

------=_NextPart_000_0017_01D15561.E0E4E160-- From nobody Sat Jan 23 04:55:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F561A010C for ; Sat, 23 Jan 2016 04:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL7knxDYyc7u for ; Sat, 23 Jan 2016 04:55:21 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1FA1A010B for ; Sat, 23 Jan 2016 04:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9tXxAJVut4iVuqGsfwQc0fc9HZVbLoONGk7s/yzN4Js=; b=JOTciZodGHIjy3co93AsyiFdq44MJNf3PVjmvLpBEPVW/IFIBagMTEcBDTQaXthCkwsRkxlGoAnJ2+KkU4UDa2NpIn9ld/86+oeHZd+x/xRSGlvLkUCbFtTLJ5kHAuWcn3qoxOeptBztBRGxnbsn/1opF2jmmnk/0Ud60jzYrZM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sat, 23 Jan 2016 12:55:00 +0000 Message-ID: <010901d155dc$dec87420$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> Date: Sat, 23 Jan 2016 12:51:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: [86.185.87.133] X-ClientProxiedBy: DB3PR05CA0011.eurprd05.prod.outlook.com (25.160.41.139) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 2:qrksmL0V8G7YK3ZrK3qyQU+70MgP/p2Kr+sh7P+EtANQgoX9S98dxsRIYhL9WxfDQG4yukiyWGPuqkGPfkICPspazMe5y81gHp2CkcoRAtFSPmyOW9UfKsOdsIqAn5eS7OQuJ9tJZkUB67IfDdDvfQ==; 3:Qha2T53qB17OWr843tedfgg7dT8bRPNFP0nqLTXIym8E5ChQCGZYlbUu5FH+jeeAR/WeL93Qj2yUAwogBRw1NNv/3ElQXUXTARo14ANMZj79sEK93CoWL3efKLbWOZC9; 25:AXV/jffhKpuLVr8oFlqDALH9Kkhao3okmYtKcJEYjQEXtlMbJ3OV+xG12dzt3teU14JZIcq9hlCNHKtMxggtYMFamyp4V/CtdBre3LV4HN96FDjrjV99i7MW7LQGGfb0LJtCoWVK+/V66Aq9VO9PbjlB11em5S5SBrhdVgLsikcFg5e+J9QTZlHtD17f4/PmKUBtK+ACvp3t3GBCEn82mNvXokoESROiIz1WY3vZO6RRnh4FOExAXlZqs0gA69IE X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-MS-Office365-Filtering-Correlation-Id: 02ae8216-cda5-4988-e86d-08d323f467ee X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 4:8gHuLUWd004nxk6DYk8DoJTa1iCY860Yhb3ObfOh4fkavvvs9+DbbybThMOyahRWNRk8iAdrL3sZdzc2RJGCWgiglbNduVdGVK67vV8P5t5LnJh/5B81tS4ZcWQlkp8UNxBnK3gW3qKyLikHv5Q7FScrueGY5+gtp1aF2el9JhiCU/UZiShu9MaguX/vmXvzh150/Fho6zGuJOp0WSO1xXkVtjvRtR0t34jBan7N87j32zt7avJiIx5ACQrMnkymsqJjT4hV3UYqXdi2wQer6MK+YG+cxB1eCm/cXcQ11FtxXp62m5YOT+Fu3obJERMt6K6EtQIIfwmPETKM3DOx7s6tVYv2uNrGMq+Ho7GYFgWX/qOas+JTnKpH+PM8RFAUovhIAg27cHMVYA3efWD6CL2yHG+Volrw8xvBo7Eaf6wLG/0dvVkVlbOT0xjlCWsS X-Forefront-PRVS: 0830866D19 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(13464003)(377454003)(40100003)(4326007)(19580405001)(230783001)(33646002)(14496001)(50986999)(101416001)(3846002)(81816999)(42186005)(61296003)(81686999)(5001960100002)(19580395003)(76176999)(2906002)(1096002)(6116002)(110136002)(5008740100001)(122386002)(5004730100002)(44736004)(189998001)(230700001)(97736004)(84392002)(586003)(81156007)(87976001)(1456003)(66066001)(44716002)(1556002)(15975445007)(92566002)(50466002)(62236002)(23676002)(105586002)(106356001)(50226001)(47776003)(77096005)(116806002)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTY7MjM6d2VLNEY4TnRNSUJ6bzVBUFppdVhjejNBcHgr?= =?utf-8?B?Mmo2cWtSc0I5bjg4b0pIR0JxMVhYMi93eEhBT3BwNEdPcFZGYWNseXVaNUlZ?= =?utf-8?B?Q0JQa1pFU1hSRElKVjc4a2swYlI5bTdCdllQYjdUNjcwVmdyS1pML0txV2Z1?= =?utf-8?B?V2hTTkJOcTBncWpWQ2J4dTFIRnVkWldIMXJLVFVqazYvaUlmcm11WG15T2Vq?= =?utf-8?B?K1lodmxqbm9RbnRhbDk5V0V1Yk5rTjJsclZ4dG1YT0l1YlNkVk9RNVIwdzVv?= =?utf-8?B?eG5WakNwT1M5Tnd6VCs0VGZCSTdUNDVtajdscmZVNjZzNGtkTzFoZlc1WHJQ?= =?utf-8?B?U3pnZGxiNWt4UXVUYXYvUXdtTU9tcm1BL3FqcmRId1J5YWVndGpPZVN1ZlhW?= =?utf-8?B?emdoaFlzV3RpbjRRVHA3U25ERjIyNCtsU0dFTlYrZkk1SlYwU1d0QVI0Q3Vu?= =?utf-8?B?a0x2SGY1R1dTWUw3Y3owOHFsUTZUZGR2VldJM0JDSi9uWkdHNXRYbG4yNlhu?= =?utf-8?B?ajlYeGx5MkdkRVlkL1lFNVoxWGpZN0RDcnZGdDVaUzVaNzg0R2x1YzM0QzFR?= =?utf-8?B?by9uQXlxVnEzaWhtR3J4clNuWjYzeGNWUGZrRm5wZ0JJUGYxU3pLazNHUHp6?= =?utf-8?B?V3JWdUZiRitoRGhkQUFYclJWMi9UekxBczdSVGFFb3Z2UWJxRC9UTjRGNzQ3?= =?utf-8?B?VWR0dHZVam5iZXVXRlM3UUJzTC94RFZ4d0FEdVJwK3lIbC9Jcy9ldVAyRERp?= =?utf-8?B?ckUwNFAzS1h5cEdQdEFEMWtoVEYxQWdHUlhwWWxHelVIaFQzM2kzaUU4dHg5?= =?utf-8?B?RURib1ZWN0Z2QUEzWkVKWmE3dWFwSStuV3crYTJtbmIvR3o0TWVXbFhPb0pN?= =?utf-8?B?d0czWlZTTkdISnhFQjhET1lPT1VpYktUQTN2dFAvNWV2VEQ5SW96czQ1Z3hC?= =?utf-8?B?aUh2SUZIamtuNUxJMWpEdXdxY2JRbVJGY2lyUVVuWlF5c2haamZhRFZZTW5z?= =?utf-8?B?VmVJeXRkQXVUTGowSVBSY1hQbTArOWpNbnBBK25abUU3QVZGUzNMbm9VMEs1?= =?utf-8?B?d0JsMXFwSVBialh3cHZ5Zm5FL21aZnNqWmo0QkdaWU1JVWdIb0JlZ1ZDSElZ?= =?utf-8?B?TnNVd1N2S2VOUUo4ZU0rQXFuUnlUT0h5VnEybkpVeVFBR0VIZDJtMDBTcUFo?= =?utf-8?B?QVNRakdlNGtkdUo4TjJpVUE3SzMvelFUZXRKeGNleHhWSGhmbFE1U0tPeXl2?= =?utf-8?B?c1NETzlzRUp5eStSc2ZoNGZUaDBhTk9jZkYxQkI0aU1WNG1IOXQ2V01vaXcr?= =?utf-8?B?Ry91U2hYSi9pbFZvSVQyUDUrRXVsNEcrV0FKQXBRQmdvNnByZURiZEhHS2hk?= =?utf-8?B?RzhubkNvQXhHOGVUa2V5elhBU2NBZzJPUE9hUkFYV3FBb2pGR2NTMzU1Ymlo?= =?utf-8?B?cDVwTXNieHIzdWZSTFQ1T09aNlUvNVQ1cWdrUC91ckUyRVczdkUrd0pVcXdI?= =?utf-8?B?ejYvZ1lsVlFUTVNuWWt0cnZ6YVNDblBuNllIT2ZieHJVMGFPRmNZNEcvQm9p?= =?utf-8?B?TkFGdjZlZjcvbVZOOE0xdkhJbVJiU0ZTR2p0VGtuS01ONHRZK2dFL1JqbEtX?= =?utf-8?B?K29KdEx3OGF0QlBxTFVHLzh2NXFQTkJXMmRDMU90QjFaOFB0ZFV0RnJUTVJr?= =?utf-8?B?N1g5NkdyT25vRHFFY3NLK25EK3A2YUZSY0FXTjByU0JEUTVpbUI5VjgwVE83?= =?utf-8?B?bi9oOW1mVEwwS1FlcXlLTlpPY3VWend3cFlJVW4xMFRmTlJEalUzaUFMMWNi?= =?utf-8?B?TzNPYTVaZ1RWVjYyNWUzVHcwZWlLdFNwOFJVVnRjMDY4dz09?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 5:LVGPCTX+BjzAauQmEmKd/aLLQ3wbnI8ecUxtSDCLmSVSEJWmGJ3lHIZHe/QHwPjnhSOTQMRYlekvjmdD9jFLsXA8F7MHT/WtD8QXsbyRhxxFjEpqZak9zVHfZ3ZkqMBxymotBiqgye2L95+wVIta7Q==; 24:Il5oq24tBsfZJBAyPCgCui0T9dmkCldEN9lXERmzXNe8FFpc2cz2/Fwx5vCV1xyz8vzv2NXEZSreMmFfIaeoRp5Rp5J1SEy87I1B7X7Zt1g= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2016 12:55:00.8642 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 12:55:25 -0000 ---- Original Message ----- From: "Andy Bierman" Sent: Friday, January 22, 2016 4:32 PM > Why is it rubbish that there can be a RESTCONF-only server? > I can't find any text that says NETCONF MUST be implemented > if RESTCONF is implemented. > > Some details (like defaults handling) are aligned with NETCONF. > That doesn't mean the RESTCONF client needs to know much > about NETCONF datastores or locks, etc. Andy I find the I-D silent on its applicability. I see " RESTCONF can be implemented on a device that supports NETCONF." which I regard as close to marketing but have no problem with it being there. What I lack is any indication as to whether or not it is feasible to have a restconf-only management system. restconf lacks some of NETCONF's capabilities so is it expected that the server will be NETCONF as well or is the expectation that there will be restconf-only systems? This colours how I comment on the following text. One small example of several is in s.12 "Implementors SHOULD provide a comprehensive authorization scheme with RESTCONF and ensure that the resulting NETCONF username is made available to the RESTCONF server." which implies to me that the server has NETCONF capabilities, at least in part. If not, then s.12 needs rewriting, along the lines that restconf imports the idea of a username (along with masses of other things) from NETCONF and must conform to the specification of usersname as in section .. of RFC ..... So can there be a restconf-only system, clients and servers? (dunno, I-D implies not) Can a server support restconf and NETCONF? yes, s1.2 tells me so Can a restconf-only client do useful work with a hybrid restconf/NETCONF server? (hopefully) Can a client support restconf and NETCONF and use them to work with restconf-only servers and NETCONF-only servers? um, authentication needs thinking about but hopefully yes I find the I-D incomplete without this being clearly stated. My comment of 'rubbish' was aimed at a different point, where the I-D says that " the user should not need any prior knowledge of NETCONF in order to use RESTCONF." To me it is abundantly clear that the user must understand NETCONF in depth in order to make sense of this I-D and I extrapolate that to understanding NETCONF in order to make use of restconf. There may or may not be a need to have access to NETCONF client/server, which is my point above, but there has to be an understanding of the concepts of NETCONF in order to make sense of restconf. You of course, along with your fellow authors, WG Chairs, WG ADs, have that in depth. I have it to some degree. Someone without such knowledge has no hope of understanding or using restconf! Tom Petch > Andy > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch wrote: > > > Having read all of restconf, I find myself with some fairly basic > > questions for which I cannot see answers. > > > > A) Is restconf an optional extra for a server on top of NETCONF or do > > you expect there to be restconf-only servers? S.1.3 says that they can > > coexists, yes, great, marketing. But can you perform useful operational > > tasks from a restconf-only client to a restconf-only server? I started > > off assuming you could, but ended up thinking the I-D was telling me > > that at least the server musy have both e.g. s.12 > > "it does require that an authenticated NETCONF username be associated > > with each request" > > which also begs the question, can there be restconf-only client? > > > > Needs specifying IMO, perhaps after thinking through the consequences. > > > > B) " the user should not need any prior knowledge of NETCONF in order to > > use RESTCONF" > > Well, I wrote 'rubbish' alongside that and taken literally, it is:=) > > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the > > operational infrastructure (configuration, state, datastore, event, > > error handling, persistence of data. ....) and while the former is > > replaced, in whole or in part, by restconf, the latter most definitely > > is not, as exemplified by the definitions imported in s.1.4.1 > > > > But that also in untrue. This I-D implies, mostly without being > > explicit, that it refines NETCONF the operational infrastructure > > (perhaps using the terms in a different way). Thus it appears that > > there is no explicit selection of NETCONF datastore but that which one > > is chosen is implicit. I infer this from s.1.3 but think that it needs > > separating out more clearly. > > > > C) configuration and state; RFC 6241 is very clear about this, this I-D > > seems to be half way towards whatever resolution netmod comes to on > > netmod-opstate-reqs, which is probably not a good idea. 'state' I see > > used only twice, then this undefined 'operational data' takes over and > > the water is then muddied by 'config' and 'nonconfig'. This is > > wandering off into its own 'restconf the operational infrastructure' > > without ever saying AFAICT how it differs from NETCONF. It is as if the > > three authors each independently wrote parts of the I-D:-) > > > > D) Then there are datastores, at least there are until s.4.4.1, when > > datastore seems to be redefined to mean 'top level node' a term which > > has surfaced on the (netmod or netconf) mailing list as being something > > that is not defined and may mean different things to different people. > > I read the first half of the I-D thinking that 'datastore' is as defined > > in RFC6241 and then find half way through that I cannot see any way that > > it is. I note the absence of any examples involving > > 'application/yang.datastore' > > and think, well yes, that figures! > > > > E) This then calls into question for me the meaning of the term 'data'. > > In the latter part of the I-D, it seems to be shorthand for 'data or > > datastore' with datastore having its non-NETCONF meaning but early on, > > it is used alongside 'datastore' suggesting that it has a more > > restricted meaning, coupled with the use of different media types, but I > > cannot tell. > > > > So, I have some detailed comments on s.4 onwards but think that the > > 'beams' need resolving first. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "t.petch" > > To: > > Cc: > > Sent: Wednesday, January 20, 2016 6:43 PM > > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > > draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > From nobody Sat Jan 23 05:26:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0871A040C for ; Sat, 23 Jan 2016 05:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-tl6EFcI2av for ; Sat, 23 Jan 2016 05:26:38 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA7A1A0461 for ; Sat, 23 Jan 2016 05:26:37 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id 17so61995702lfz.1 for ; Sat, 23 Jan 2016 05:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IdVA7FLV2NJp3l8YXboZW/gVo6+iBn85F0VQMnldS1Q=; b=ZnYJ+87UavU4B/Mw5MEMrvKgSTEj3qtsDAzbeCkq4ZV6XM0b0927DTCF14nn1GaQiO PacGsf03HCHVoV0cIsRX9TduDnoX5YOTjKFG7z4u4BAs197DAuIwCJ1ZvhKilVrg25J5 9eVcvOvKTfOVj5IR5390Mj5d5vtcXUc9Rv2aX3DrJFWC91PzgQDJGJruSOlOaZ+TMhV/ T1NdL2xntaIubSxMPK7WzqcgsXI1SVCwbSQ4aOq6o/S+LG1NDqQwmWKldYhUFOw8GhVd /XZQDja9JcP5bD2IW6ieTUzn3ZyBEkTrunmfhqG1V0YS68bbvhSqlGY5q2Xm/c2Oshjp vt6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IdVA7FLV2NJp3l8YXboZW/gVo6+iBn85F0VQMnldS1Q=; b=XvntL+VlFKuNe3VI00a3Bb4zAYWg6pImiVP33i/PCqmFfNuQjt9TP4AaKs6Obxu8M+ queMho3tx8hUc7CVRK34r0yFDzYUKDq2gDOwmmWjMclaD/Kj4K/pMXyZ8/dSzybYvX58 fnOyAuU/m7zVPsMlby4B1RkMhgrtIFjXigvKSiyN+FhgryIFpegz4aM+KIbCAEDU8c75 vOebOI9dTth0KR1bsVJYQit6obDiTmmiv8mxqV1BIamlvG824gHaU8MJwKfJsHKTeuYd BmzUOnyyvmOCAEJKT9otshhD7OB9b2cvcPoo+Idd7oJzjoaIKBAzn5LuTZVDKt7RfwmQ NdXA== X-Gm-Message-State: AG10YOQ7pSEESarhG1irWwAJSj/Vv3DLvDD3JD1/+HuzBxE0wS5LDovwJ8Ixhh4bvzp1kf1qlqoZ4rAw8HbHDA== MIME-Version: 1.0 X-Received: by 10.25.155.194 with SMTP id d185mr3295143lfe.8.1453555595902; Sat, 23 Jan 2016 05:26:35 -0800 (PST) Received: by 10.112.200.167 with HTTP; Sat, 23 Jan 2016 05:26:35 -0800 (PST) In-Reply-To: <010901d155dc$dec87420$4001a8c0@gateway.2wire.net> References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> <010901d155dc$dec87420$4001a8c0@gateway.2wire.net> Date: Sat, 23 Jan 2016 05:26:35 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a113fbdd4f4a0d3052a004805 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 13:26:41 -0000 --001a113fbdd4f4a0d3052a004805 Content-Type: text/plain; charset=UTF-8 Hi, We can clarify the sentence about NETCONF knowledge needed. First of all, a RESTCONF-only implementation is certainly possible, and planned, and implemented. JSON-only. Ditto. If NETCONF is supported, then there are implementation details within the server that need to be addressed. The unfortunate text that you and some others are complaining about could be changed to say the client developer does not need to know the NETCONF details, such as :candidate vs. :writable-running vs. plus :startup. In RESTCONF the client just sends an edit and the server will take care of these details. Andy On Sat, Jan 23, 2016 at 4:51 AM, t.petch wrote: > ---- Original Message ----- > From: "Andy Bierman" > Sent: Friday, January 22, 2016 4:32 PM > > > Why is it rubbish that there can be a RESTCONF-only server? > > I can't find any text that says NETCONF MUST be implemented > > if RESTCONF is implemented. > > > > Some details (like defaults handling) are aligned with NETCONF. > > That doesn't mean the RESTCONF client needs to know much > > about NETCONF datastores or locks, etc. > > Andy > > I find the I-D silent on its applicability. I see > " RESTCONF can be implemented on a device that supports NETCONF." > which I regard as close to marketing but have no problem with it being > there. What I lack is any indication as to whether or not it is > feasible to have a restconf-only management system. restconf lacks some > of NETCONF's capabilities so is it expected that the server will be > NETCONF as well or is the expectation that there will be restconf-only > systems? > > This colours how I comment on the following text. One small example of > several is in s.12 > > "Implementors SHOULD provide a comprehensive > authorization scheme with RESTCONF and ensure that the resulting > NETCONF username is made available to the RESTCONF server." > > which implies to me that the server has NETCONF capabilities, at least > in part. If not, then s.12 needs rewriting, along the lines that > restconf imports the idea of a username (along with masses of other > things) from NETCONF and must conform to the specification of usersname > as in section .. of RFC ..... > > So can there be a restconf-only system, clients and servers? (dunno, > I-D implies not) > Can a server support restconf and NETCONF? yes, s1.2 tells me so > Can a restconf-only client do useful work with a hybrid restconf/NETCONF > server? (hopefully) > Can a client support restconf and NETCONF and use them to work with > restconf-only servers and NETCONF-only servers? um, authentication > needs thinking about but hopefully yes > > I find the I-D incomplete without this being clearly stated. > > My comment of 'rubbish' was aimed at a different point, where the I-D > says that > " the user should not need any prior knowledge of NETCONF in order to > use RESTCONF." > To me it is abundantly clear that the user must understand NETCONF in > depth in order to make sense of this I-D and I extrapolate that to > understanding NETCONF in order to make use of restconf. There may or > may not be a need to have access to NETCONF client/server, which is my > point above, but there has to be an understanding of the concepts of > NETCONF in order to make sense of restconf. You of course, along with > your fellow authors, WG Chairs, WG ADs, have that in depth. I have it > to some degree. Someone without such knowledge has no hope of > understanding or using restconf! > > Tom Petch > > > Andy > > > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch wrote: > > > > > Having read all of restconf, I find myself with some fairly basic > > > questions for which I cannot see answers. > > > > > > A) Is restconf an optional extra for a server on top of NETCONF or > do > > > you expect there to be restconf-only servers? S.1.3 says that they > can > > > coexists, yes, great, marketing. But can you perform useful > operational > > > tasks from a restconf-only client to a restconf-only server? I > started > > > off assuming you could, but ended up thinking the I-D was telling me > > > that at least the server musy have both e.g. s.12 > > > "it does require that an authenticated NETCONF username be > associated > > > with each request" > > > which also begs the question, can there be restconf-only client? > > > > > > Needs specifying IMO, perhaps after thinking through the > consequences. > > > > > > B) " the user should not need any prior knowledge of NETCONF in > order to > > > use RESTCONF" > > > Well, I wrote 'rubbish' alongside that and taken literally, it is:=) > > > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the > > > operational infrastructure (configuration, state, datastore, event, > > > error handling, persistence of data. ....) and while the former is > > > replaced, in whole or in part, by restconf, the latter most > definitely > > > is not, as exemplified by the definitions imported in s.1.4.1 > > > > > > But that also in untrue. This I-D implies, mostly without being > > > explicit, that it refines NETCONF the operational infrastructure > > > (perhaps using the terms in a different way). Thus it appears that > > > there is no explicit selection of NETCONF datastore but that which > one > > > is chosen is implicit. I infer this from s.1.3 but think that it > needs > > > separating out more clearly. > > > > > > C) configuration and state; RFC 6241 is very clear about this, this > I-D > > > seems to be half way towards whatever resolution netmod comes to on > > > netmod-opstate-reqs, which is probably not a good idea. 'state' I > see > > > used only twice, then this undefined 'operational data' takes over > and > > > the water is then muddied by 'config' and 'nonconfig'. This is > > > wandering off into its own 'restconf the operational infrastructure' > > > without ever saying AFAICT how it differs from NETCONF. It is as if > the > > > three authors each independently wrote parts of the I-D:-) > > > > > > D) Then there are datastores, at least there are until s.4.4.1, when > > > datastore seems to be redefined to mean 'top level node' a term > which > > > has surfaced on the (netmod or netconf) mailing list as being > something > > > that is not defined and may mean different things to different > people. > > > I read the first half of the I-D thinking that 'datastore' is as > defined > > > in RFC6241 and then find half way through that I cannot see any way > that > > > it is. I note the absence of any examples involving > > > 'application/yang.datastore' > > > and think, well yes, that figures! > > > > > > E) This then calls into question for me the meaning of the term > 'data'. > > > In the latter part of the I-D, it seems to be shorthand for 'data or > > > datastore' with datastore having its non-NETCONF meaning but early > on, > > > it is used alongside 'datastore' suggesting that it has a more > > > restricted meaning, coupled with the use of different media types, > but I > > > cannot tell. > > > > > > So, I have some detailed comments on s.4 onwards but think that the > > > 'beams' need resolving first. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "t.petch" > > > To: > > > Cc: > > > Sent: Wednesday, January 20, 2016 6:43 PM > > > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > > > draft-ietf-netconf-yang-patch-07 and > draft-ietf-netconf-yang-library-03 > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > --001a113fbdd4f4a0d3052a004805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We can clarify the sentence about N= ETCONF knowledge needed.

First of all, a RESTCONF-= only implementation is certainly possible,
and planned, and imple= mented. JSON-only. Ditto.

If NETCONF is supported,= then there are implementation details
within the server that nee= d to be addressed.=C2=A0 The unfortunate text
that you and some o= thers are complaining about could be changed
to say the client de= veloper does not need to know the NETCONF details,
such as :candi= date vs. :writable-running vs. plus :startup.
In RESTCONF the cli= ent just sends an edit and the server
will take care of these det= ails.


Andy


On Sat, Jan 23, 2016 = at 4:51 AM, t.petch <ietfc@btconnect.com> wrote:
---- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
Sent: Friday, January 22, 2016 4:32 PM

> Why is it rubbish that there can be a RESTCONF-only server?
> I can't find any text that says NETCONF MUST be implemented
> if RESTCONF is implemented.
>
> Some details (like defaults handling) are aligned with NETCONF.
> That doesn't mean the RESTCONF client needs to know much
> about NETCONF datastores or locks, etc.

Andy

I find the I-D silent on its applicability.=C2=A0 I see
"=C2=A0 RESTCONF can be implemented on a device that supports NETCONF.= "
which I regard as close to marketing but have no problem with it being
there.=C2=A0 What I lack is any indication as to whether or not it is
feasible to have a restconf-only management system.=C2=A0 restconf lacks so= me
of NETCONF's capabilities so is it expected that the server will be
NETCONF as well or is the expectation that there will be restconf-only
systems?

This colours how I comment on the following text.=C2=A0 One small example o= f
several is in s.12

"Implementors SHOULD provide a comprehensive
=C2=A0 =C2=A0authorization scheme with RESTCONF and ensure that the resulti= ng
=C2=A0 =C2=A0NETCONF username is made available to the RESTCONF server.&quo= t;

which implies to me that the server has NETCONF capabilities, at least
in part.=C2=A0 If not, then s.12 needs rewriting, along the lines that
restconf imports the idea of a username (along with masses of other
things) from NETCONF and must conform to the specification of usersname
as in section .. of RFC .....

So can there be a restconf-only system, clients and servers?=C2=A0 (dunno,<= br> I-D implies not)
Can a server support restconf and NETCONF? yes, s1.2 tells me so
Can a restconf-only client do useful work with a hybrid restconf/NETCONF server? (hopefully)
Can a client support restconf and NETCONF and use them to work with
restconf-only servers and NETCONF-only servers?=C2=A0 um, authentication needs thinking about but hopefully yes

I find the I-D incomplete without this being clearly stated.

My comment of 'rubbish' was aimed at a different point, where the I= -D
says that
" the user should not need any prior knowledge of NETCONF in order to<= br> =C2=A0 =C2=A0use RESTCONF."
To me it is abundantly clear that the user must understand NETCONF in
depth in order to make sense of this I-D and I extrapolate that to
understanding NETCONF in order to make use of restconf.=C2=A0 There may or<= br> may not be a need to have access to NETCONF client/server, which is my
point above, but there has to be an understanding of the concepts of
NETCONF in order to make sense of restconf.=C2=A0 You of course, along with=
your fellow authors, WG Chairs, WG ADs, have that in depth.=C2=A0 I have it=
to some degree.=C2=A0 Someone without such knowledge has no hope of
understanding or using restconf!

Tom Petch

=C2=A0> Andy
>
> On Fri, Jan 22, 2016 at 8:03 AM, t.petch <ietfc@btconnect.com> wrote:
>
> > Having read all of restconf, I find myself with some fairly basic=
> > questions for which I cannot see answers.
> >
> > A) Is restconf an optional extra for a server on top of NETCONF o= r
do
> > you expect there to be restconf-only servers?=C2=A0 S.1.3 says th= at they
can
> > coexists, yes, great, marketing.=C2=A0 But can you perform useful=
operational
> > tasks from a restconf-only client to a restconf-only server?=C2= =A0 I
started
> > off assuming you could, but ended up thinking the I-D was telling= me
> > that at least the server musy have both e.g. s.12
> > "it does=C2=A0 require that an authenticated NETCONF usernam= e be
associated
> > with each request"
> > which also begs the question, can there be restconf-only client?<= br> > >
> > Needs specifying IMO, perhaps after thinking through the
consequences.
> >
> > B) " the user should not need any prior knowledge of NETCONF= in
order to
> > use RESTCONF"
> > Well, I wrote 'rubbish' alongside that and taken literall= y, it is:=3D)
> > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF = the
> > operational infrastructure (configuration, state, datastore, even= t,
> > error handling, persistence of data. ....) and while the former i= s
> > replaced, in whole or in part, by restconf, the latter most
definitely
> > is not, as exemplified by the definitions imported in s.1.4.1
> >
> > But that also in untrue.=C2=A0 This I-D implies, mostly without b= eing
> > explicit, that it refines NETCONF the operational infrastructure<= br> > > (perhaps using the terms in a different way).=C2=A0 Thus it appea= rs that
> > there is no explicit selection of NETCONF datastore but that whic= h
one
> > is chosen is implicit.=C2=A0 I infer this from s.1.3 but think th= at it
needs
> > separating out more clearly.
> >
> > C) configuration and state; RFC 6241 is very clear about this, th= is
I-D
> > seems to be half way towards whatever resolution netmod comes to = on
> > netmod-opstate-reqs, which is probably not a good idea.=C2=A0 = 9;state' I
see
> > used only twice, then this undefined 'operational data' t= akes over
and
> > the water is then muddied by 'config' and 'nonconfig&= #39;.=C2=A0 This is
> > wandering off into its own 'restconf the operational infrastr= ucture'
> > without ever saying AFAICT how it differs from NETCONF.=C2=A0 It = is as if
the
> > three authors each independently wrote parts of the I-D:-)
> >
> > D) Then there are datastores, at least there are until s.4.4.1, w= hen
> > datastore seems to be redefined to mean 'top level node' = a term
which
> > has surfaced on the (netmod or netconf) mailing list as being
something
> > that is not defined and may mean different things to different people.
> > I read the first half of the I-D thinking that 'datastore'= ; is as
defined
> > in RFC6241 and then find half way through that I cannot see any w= ay
that
> > it is.=C2=A0 I note the absence of any examples involving
> > 'application/yang.datastore'
> > and think, well yes, that figures!
> >
> > E) This then calls into question for me the meaning of the term 'data'.
> > In the latter part of the I-D, it seems to be shorthand for '= data or
> > datastore' with datastore having its non-NETCONF meaning but = early
on,
> > it is used alongside 'datastore' suggesting that it has a= more
> > restricted meaning, coupled with the use of different media types= ,
but I
> > cannot tell.
> >
> > So, I have some detailed comments on s.4 onwards but think that t= he
> > 'beams' need resolving first.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "t.petch" <ietfc@btconnect.com>
> > To: <mehmet.ersue@no= kia.com>
> > Cc: <netconf@ietf.org&= gt;
> > Sent: Wednesday, January 20, 2016 6:43 PM
> > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09,
> > draft-ietf-netconf-yang-patch-07 and
draft-ietf-netconf-yang-library-03
> >
> > <snip>
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >
>


--001a113fbdd4f4a0d3052a004805-- From nobody Sat Jan 23 07:13:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CA21B37B7 for ; Sat, 23 Jan 2016 07:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J-HuzYzNNrX for ; Sat, 23 Jan 2016 07:13:37 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240A21B37B4 for ; Sat, 23 Jan 2016 07:13:37 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id x4so55523370lbm.0 for ; Sat, 23 Jan 2016 07:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JQNWt5EKpFRT8Q2VQiM81uIdkAmUd9NloOFHt6MtuXU=; b=MJ6P5WaNhtHJjQU7oSBRJ0egaReSKX/bfe/a2pFDBtL4uUHHcGk1aKZc6zGc2gq/Z+ AEl7gSQT9f2GrOqxUCpcnxsCkKPGB6TVPj00UNrG5xtCzgwXuGOlm3DTQWIL4vwDX2cZ CI2Rf8vNOUMDf9fPERWBuXMw8rGhXLUVABekCNTlzimq6Ey3tNLQsMIe82MMigi6IRI/ aQHFzzqosRKacB2P7zKXGIpwbQ+oOn716UXNKXcM2/JQb61IjkL8eQv1h8mljGF0Q7dG o+Satyu3pNo61nlHTerG2OnFvOh/pv2z2dXhtAKGOiVz1yQhlnEGX/ltwSNkaWK2pI72 tFhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JQNWt5EKpFRT8Q2VQiM81uIdkAmUd9NloOFHt6MtuXU=; b=NQqnzrQCtGAGZXou9iXXIsd7dp5hHt9g04hFDwQKskDoS3irgdtNve/L6/lrJFdd0S ldyz10cjhOzWPKD4SH8MRgZ8/FbwLCmCuF5q25VzEr1jjteKB6707MX03Jk30+1mNrle Lc4KPtJAT6So0Gwlj/kzZFP9/XTsBunJtpFA5Zl+JrHha6Gcur/NvynG+zFeZDpeugxt yHj917N3suM0shwnxR/Ms1X7iVkpYILM/2qwmvex8ma3xwu4g0K1Gf3dET2zeY5rgSrz 8iumVnlIYB42b8sW1x+0v96aWvpsFNcvePD3cW/KzIPI/qtSWZRK2EqIcZ3kW9hbpI9r J4Eg== X-Gm-Message-State: AG10YOQxw/Z+uhZm4T7OQamI1UnLcTWQeCVoUrJBCZbAPSg15pIjleOh4+i8V/ac2Q9PrGM3hMDwoD06xy791A== MIME-Version: 1.0 X-Received: by 10.112.12.2 with SMTP id u2mr3218552lbb.145.1453562015297; Sat, 23 Jan 2016 07:13:35 -0800 (PST) Received: by 10.112.200.167 with HTTP; Sat, 23 Jan 2016 07:13:35 -0800 (PST) In-Reply-To: <010901d155dc$dec87420$4001a8c0@gateway.2wire.net> References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> <010901d155dc$dec87420$4001a8c0@gateway.2wire.net> Date: Sat, 23 Jan 2016 07:13:35 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c3f18494d190052a01c7ef Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 15:13:41 -0000 --001a11c3f18494d190052a01c7ef Content-Type: text/plain; charset=UTF-8 Hi, Would your concerns be we put more detail in the NETCONF Coexistence section. I have already pointed out that the confirmed-commit details are missing. We will make it clear which details a RESTCONF client needs to know. We can add another short section for RESTCONF only considerations. I thought it was already clear that implementation of NETCONF was not required, but we can make it extra clear. Applicability is another problem. IMO let the market decide. Some companies (and WGs) are already working on solutions that provide a unified "YANG development environment" to deploy with whatever protocol, across a range of platforms from IoT to SDN. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF) The boundaries of applicability are subjective and might be rapidly changing for awhile. (So I don't want to write an AS for RESTCONF.) Andy On Sat, Jan 23, 2016 at 4:51 AM, t.petch wrote: > ---- Original Message ----- > From: "Andy Bierman" > Sent: Friday, January 22, 2016 4:32 PM > > > Why is it rubbish that there can be a RESTCONF-only server? > > I can't find any text that says NETCONF MUST be implemented > > if RESTCONF is implemented. > > > > Some details (like defaults handling) are aligned with NETCONF. > > That doesn't mean the RESTCONF client needs to know much > > about NETCONF datastores or locks, etc. > > Andy > > I find the I-D silent on its applicability. I see > " RESTCONF can be implemented on a device that supports NETCONF." > which I regard as close to marketing but have no problem with it being > there. What I lack is any indication as to whether or not it is > feasible to have a restconf-only management system. restconf lacks some > of NETCONF's capabilities so is it expected that the server will be > NETCONF as well or is the expectation that there will be restconf-only > systems? > > This colours how I comment on the following text. One small example of > several is in s.12 > > "Implementors SHOULD provide a comprehensive > authorization scheme with RESTCONF and ensure that the resulting > NETCONF username is made available to the RESTCONF server." > > which implies to me that the server has NETCONF capabilities, at least > in part. If not, then s.12 needs rewriting, along the lines that > restconf imports the idea of a username (along with masses of other > things) from NETCONF and must conform to the specification of usersname > as in section .. of RFC ..... > > So can there be a restconf-only system, clients and servers? (dunno, > I-D implies not) > Can a server support restconf and NETCONF? yes, s1.2 tells me so > Can a restconf-only client do useful work with a hybrid restconf/NETCONF > server? (hopefully) > Can a client support restconf and NETCONF and use them to work with > restconf-only servers and NETCONF-only servers? um, authentication > needs thinking about but hopefully yes > > I find the I-D incomplete without this being clearly stated. > > My comment of 'rubbish' was aimed at a different point, where the I-D > says that > " the user should not need any prior knowledge of NETCONF in order to > use RESTCONF." > To me it is abundantly clear that the user must understand NETCONF in > depth in order to make sense of this I-D and I extrapolate that to > understanding NETCONF in order to make use of restconf. There may or > may not be a need to have access to NETCONF client/server, which is my > point above, but there has to be an understanding of the concepts of > NETCONF in order to make sense of restconf. You of course, along with > your fellow authors, WG Chairs, WG ADs, have that in depth. I have it > to some degree. Someone without such knowledge has no hope of > understanding or using restconf! > > Tom Petch > > > Andy > > > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch wrote: > > > > > Having read all of restconf, I find myself with some fairly basic > > > questions for which I cannot see answers. > > > > > > A) Is restconf an optional extra for a server on top of NETCONF or > do > > > you expect there to be restconf-only servers? S.1.3 says that they > can > > > coexists, yes, great, marketing. But can you perform useful > operational > > > tasks from a restconf-only client to a restconf-only server? I > started > > > off assuming you could, but ended up thinking the I-D was telling me > > > that at least the server musy have both e.g. s.12 > > > "it does require that an authenticated NETCONF username be > associated > > > with each request" > > > which also begs the question, can there be restconf-only client? > > > > > > Needs specifying IMO, perhaps after thinking through the > consequences. > > > > > > B) " the user should not need any prior knowledge of NETCONF in > order to > > > use RESTCONF" > > > Well, I wrote 'rubbish' alongside that and taken literally, it is:=) > > > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the > > > operational infrastructure (configuration, state, datastore, event, > > > error handling, persistence of data. ....) and while the former is > > > replaced, in whole or in part, by restconf, the latter most > definitely > > > is not, as exemplified by the definitions imported in s.1.4.1 > > > > > > But that also in untrue. This I-D implies, mostly without being > > > explicit, that it refines NETCONF the operational infrastructure > > > (perhaps using the terms in a different way). Thus it appears that > > > there is no explicit selection of NETCONF datastore but that which > one > > > is chosen is implicit. I infer this from s.1.3 but think that it > needs > > > separating out more clearly. > > > > > > C) configuration and state; RFC 6241 is very clear about this, this > I-D > > > seems to be half way towards whatever resolution netmod comes to on > > > netmod-opstate-reqs, which is probably not a good idea. 'state' I > see > > > used only twice, then this undefined 'operational data' takes over > and > > > the water is then muddied by 'config' and 'nonconfig'. This is > > > wandering off into its own 'restconf the operational infrastructure' > > > without ever saying AFAICT how it differs from NETCONF. It is as if > the > > > three authors each independently wrote parts of the I-D:-) > > > > > > D) Then there are datastores, at least there are until s.4.4.1, when > > > datastore seems to be redefined to mean 'top level node' a term > which > > > has surfaced on the (netmod or netconf) mailing list as being > something > > > that is not defined and may mean different things to different > people. > > > I read the first half of the I-D thinking that 'datastore' is as > defined > > > in RFC6241 and then find half way through that I cannot see any way > that > > > it is. I note the absence of any examples involving > > > 'application/yang.datastore' > > > and think, well yes, that figures! > > > > > > E) This then calls into question for me the meaning of the term > 'data'. > > > In the latter part of the I-D, it seems to be shorthand for 'data or > > > datastore' with datastore having its non-NETCONF meaning but early > on, > > > it is used alongside 'datastore' suggesting that it has a more > > > restricted meaning, coupled with the use of different media types, > but I > > > cannot tell. > > > > > > So, I have some detailed comments on s.4 onwards but think that the > > > 'beams' need resolving first. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "t.petch" > > > To: > > > Cc: > > > Sent: Wednesday, January 20, 2016 6:43 PM > > > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > > > draft-ietf-netconf-yang-patch-07 and > draft-ietf-netconf-yang-library-03 > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > --001a11c3f18494d190052a01c7ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Would your concerns be we put more = detail in the NETCONF Coexistence section.
I have already pointed= out that the confirmed-commit details are missing.
We will make = it clear which details a RESTCONF client needs to know.

We can add another short section for RESTCONF only considerations.
I thought it was already clear that implementation of NETCONF was n= ot
required, but we can make it extra clear.

=
Applicability is another problem.=C2=A0 IMO let the market decide.
Some companies (and WGs) are already working on solutions that provi= de a unified
"YANG development environment" to deploy w= ith whatever protocol, across a range of
platforms from IoT to SD= N. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF)
The boundaries of = applicability are subjective and might be rapidly changing for awhile.
(So I don't want to write an AS for RESTCONF.)



Andy


On Sat, Jan 23, 2016 at = 4:51 AM, t.petch <ietfc@btconnect.com> wrote:
---- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
Sent: Friday, January 22, 2016 4:32 PM

> Why is it rubbish that there can be a RESTCONF-only server?
> I can't find any text that says NETCONF MUST be implemented
> if RESTCONF is implemented.
>
> Some details (like defaults handling) are aligned with NETCONF.
> That doesn't mean the RESTCONF client needs to know much
> about NETCONF datastores or locks, etc.

Andy

I find the I-D silent on its applicability.=C2=A0 I see
"=C2=A0 RESTCONF can be implemented on a device that supports NETCONF.= "
which I regard as close to marketing but have no problem with it being
there.=C2=A0 What I lack is any indication as to whether or not it is
feasible to have a restconf-only management system.=C2=A0 restconf lacks so= me
of NETCONF's capabilities so is it expected that the server will be
NETCONF as well or is the expectation that there will be restconf-only
systems?

This colours how I comment on the following text.=C2=A0 One small example o= f
several is in s.12

"Implementors SHOULD provide a comprehensive
=C2=A0 =C2=A0authorization scheme with RESTCONF and ensure that the resulti= ng
=C2=A0 =C2=A0NETCONF username is made available to the RESTCONF server.&quo= t;

which implies to me that the server has NETCONF capabilities, at least
in part.=C2=A0 If not, then s.12 needs rewriting, along the lines that
restconf imports the idea of a username (along with masses of other
things) from NETCONF and must conform to the specification of usersname
as in section .. of RFC .....

So can there be a restconf-only system, clients and servers?=C2=A0 (dunno,<= br> I-D implies not)
Can a server support restconf and NETCONF? yes, s1.2 tells me so
Can a restconf-only client do useful work with a hybrid restconf/NETCONF server? (hopefully)
Can a client support restconf and NETCONF and use them to work with
restconf-only servers and NETCONF-only servers?=C2=A0 um, authentication needs thinking about but hopefully yes

I find the I-D incomplete without this being clearly stated.

My comment of 'rubbish' was aimed at a different point, where the I= -D
says that
" the user should not need any prior knowledge of NETCONF in order to<= br> =C2=A0 =C2=A0use RESTCONF."
To me it is abundantly clear that the user must understand NETCONF in
depth in order to make sense of this I-D and I extrapolate that to
understanding NETCONF in order to make use of restconf.=C2=A0 There may or<= br> may not be a need to have access to NETCONF client/server, which is my
point above, but there has to be an understanding of the concepts of
NETCONF in order to make sense of restconf.=C2=A0 You of course, along with=
your fellow authors, WG Chairs, WG ADs, have that in depth.=C2=A0 I have it=
to some degree.=C2=A0 Someone without such knowledge has no hope of
understanding or using restconf!

Tom Petch

=C2=A0> Andy
>
> On Fri, Jan 22, 2016 at 8:03 AM, t.petch <ietfc@btconnect.com> wrote:
>
> > Having read all of restconf, I find myself with some fairly basic=
> > questions for which I cannot see answers.
> >
> > A) Is restconf an optional extra for a server on top of NETCONF o= r
do
> > you expect there to be restconf-only servers?=C2=A0 S.1.3 says th= at they
can
> > coexists, yes, great, marketing.=C2=A0 But can you perform useful=
operational
> > tasks from a restconf-only client to a restconf-only server?=C2= =A0 I
started
> > off assuming you could, but ended up thinking the I-D was telling= me
> > that at least the server musy have both e.g. s.12
> > "it does=C2=A0 require that an authenticated NETCONF usernam= e be
associated
> > with each request"
> > which also begs the question, can there be restconf-only client?<= br> > >
> > Needs specifying IMO, perhaps after thinking through the
consequences.
> >
> > B) " the user should not need any prior knowledge of NETCONF= in
order to
> > use RESTCONF"
> > Well, I wrote 'rubbish' alongside that and taken literall= y, it is:=3D)
> > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF = the
> > operational infrastructure (configuration, state, datastore, even= t,
> > error handling, persistence of data. ....) and while the former i= s
> > replaced, in whole or in part, by restconf, the latter most
definitely
> > is not, as exemplified by the definitions imported in s.1.4.1
> >
> > But that also in untrue.=C2=A0 This I-D implies, mostly without b= eing
> > explicit, that it refines NETCONF the operational infrastructure<= br> > > (perhaps using the terms in a different way).=C2=A0 Thus it appea= rs that
> > there is no explicit selection of NETCONF datastore but that whic= h
one
> > is chosen is implicit.=C2=A0 I infer this from s.1.3 but think th= at it
needs
> > separating out more clearly.
> >
> > C) configuration and state; RFC 6241 is very clear about this, th= is
I-D
> > seems to be half way towards whatever resolution netmod comes to = on
> > netmod-opstate-reqs, which is probably not a good idea.=C2=A0 = 9;state' I
see
> > used only twice, then this undefined 'operational data' t= akes over
and
> > the water is then muddied by 'config' and 'nonconfig&= #39;.=C2=A0 This is
> > wandering off into its own 'restconf the operational infrastr= ucture'
> > without ever saying AFAICT how it differs from NETCONF.=C2=A0 It = is as if
the
> > three authors each independently wrote parts of the I-D:-)
> >
> > D) Then there are datastores, at least there are until s.4.4.1, w= hen
> > datastore seems to be redefined to mean 'top level node' = a term
which
> > has surfaced on the (netmod or netconf) mailing list as being
something
> > that is not defined and may mean different things to different people.
> > I read the first half of the I-D thinking that 'datastore'= ; is as
defined
> > in RFC6241 and then find half way through that I cannot see any w= ay
that
> > it is.=C2=A0 I note the absence of any examples involving
> > 'application/yang.datastore'
> > and think, well yes, that figures!
> >
> > E) This then calls into question for me the meaning of the term 'data'.
> > In the latter part of the I-D, it seems to be shorthand for '= data or
> > datastore' with datastore having its non-NETCONF meaning but = early
on,
> > it is used alongside 'datastore' suggesting that it has a= more
> > restricted meaning, coupled with the use of different media types= ,
but I
> > cannot tell.
> >
> > So, I have some detailed comments on s.4 onwards but think that t= he
> > 'beams' need resolving first.
> >
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "t.petch" <ietfc@btconnect.com>
> > To: <mehmet.ersue@no= kia.com>
> > Cc: <netconf@ietf.org&= gt;
> > Sent: Wednesday, January 20, 2016 6:43 PM
> > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09,
> > draft-ietf-netconf-yang-patch-07 and
draft-ietf-netconf-yang-library-03
> >
> > <snip>
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >
>


--001a11c3f18494d190052a01c7ef-- From nobody Sat Jan 23 10:51:12 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D421F1A871B for ; Sat, 23 Jan 2016 10:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koPFNP8B0ehH for ; Sat, 23 Jan 2016 10:51:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 109911A871A for ; Sat, 23 Jan 2016 10:51:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EYPChatjEKLCY+hBxvvmTXvQ1WK/ccMbnotq/L8PO6mMBAp50HI1wVVjaMgymBTe; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aN3H0-0004gi-6R for netconf@ietf.org; Sat, 23 Jan 2016 13:50:58 -0500 Received: from 76.254.55.124 by webmail.earthlink.net with HTTP; Sat, 23 Jan 2016 13:50:57 -0500 Message-ID: <26301803.1453575058231.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Sat, 23 Jan 2016 10:50:57 -0800 (GMT-08:00) From: Randy Presuhn To: Netconf Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc62e4ccc71d98c409e03fc2be108ad2bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 18:51:11 -0000 Hi - >From: "t.petch" >Sent: Jan 23, 2016 4:51 AM >To: Andy Bierman >Cc: Netconf >Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview ... >To me it is abundantly clear that the user must understand NETCONF in >depth in order to make sense of this I-D That is very much my impression after attempting to review the document. I'm reasonably familiar with network management, and have been casually following NETCONF for a while, and still found the document very slow going. I think fully understanding this document requires a better understanding of NETCONF than one would gain merely by following the activity on this list. > and I extrapolate that to >understanding NETCONF in order to make use of restconf. I don't fully endorse the logic, but I agree with the conclusion. Reading this document has not left me feeling like I'd be able to use RESTCONF productively unless much of the stuff the document talks about were well-hidden by a well-crafted application, or I had learned and totally internalized the NETCONF weltanschauung. > There may or >may not be a need to have access to NETCONF client/server, which is my >point above, but there has to be an understanding of the concepts of >NETCONF in order to make sense of restconf. ... Yes, that is my impression as well after reading this document. Randy From nobody Sat Jan 23 17:26:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0391B3A4C; Sat, 23 Jan 2016 17:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvcsnODSWGW9; Sat, 23 Jan 2016 17:26:03 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5751B3A4A; Sat, 23 Jan 2016 17:26:03 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id n128so62351046pfn.3; Sat, 23 Jan 2016 17:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Q+IfsrppBWQvv4ZIQD0/3YnGq4UM6LM1092YysDtK0U=; b=ZOw1YVN1QkDqhgVk+kWFoipOXVkRdqGJnxhSEsCyr+DjeoZ9+FeKWriJch+a7uF6K4 fWVwJj6Gmjvvlm0Wp+GmCgxyiON1qgpUGyKGsI+thoQiiZqt72+9NjaycTbRzHltHvzI 4hkSRRaUv1OmQUCJnpP1FHCaMo8lKGGDI7cMZJQjHNq67Cs9CGkQt9pQT7hI/cRNtnYK 8jPHE5wmQhKW7yrvEH0EqNHFcOQ2jP2HOIgwjk9R0siAKZICJX8WLLq2XoOkUSTNkNnU NCJqSSp6PyMHPYAMtFhfrplQk4m4i2Au8x4bcGU59Vyg2WkhLL91N2wHBIRPqn7EaZ8b A5TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Q+IfsrppBWQvv4ZIQD0/3YnGq4UM6LM1092YysDtK0U=; b=i0Q8Hs7Pvs4PBAvSA6j9qaN7w7bGdDjruuMxSKBDwq6l15UR+SUG+6X5UEpPRu1TOa n5PhFJNZcB2oEAeFYfSht2lQnXr92Rv3mMXLb+JCotqzc26ydw6Bdx7stXVOtDBFjlV+ 9YIsJ2mL/f7p24yz4YnRtAlxVmo6YluS5cEF4QCbwRjVxSlfQ5wg2JDJpFDYQeBFj8pj pPXUSr+nSZ1L8U3az2Pm3ktOyEm2gJEFAa4XdwNLcGat5YGXK8HnFKamekneI6XMwwUo B0xbMN2wvMUw8NkcGIwxiByIphtbXK4DNaRnKEHzvjOtQHKVGapx+JWSwIXzXcNBdvEt dTcA== X-Gm-Message-State: AG10YOQGo6EbEfN6FHv/yNcL68/+fEzrYdTxeDPyZnApSRP650eKVMy38BOA0wgUpc1I+Q== X-Received: by 10.98.70.151 with SMTP id o23mr15450815pfi.124.1453598763215; Sat, 23 Jan 2016 17:26:03 -0800 (PST) Received: from [10.24.22.192] ([128.107.241.181]) by smtp.gmail.com with ESMTPSA id 68sm18820675pfa.78.2016.01.23.17.26.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 Jan 2016 17:26:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: Date: Sat, 23 Jan 2016 18:25:59 -0700 Message-Id: References: To: NETCONF X-Mailer: Apple Mail (2.2104) Archived-At: Cc: i2rs@ietf.org, 6tisch@ietf.org, core@ietf.org, "netmod@ietf.org" , 6lo@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 01:26:06 -0000 --Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Last Call period for the above three drafts closed yesterday. Thanks = to everyone who provided comments on the three drafts. The authors will update the documents based on the comments received and = post an updated version of the draft(s). Mahesh & Mehmet. > On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - DE/Munich) = wrote: >=20 > FYI and attention. > =20 > Please provide your comments to NETCONF WG maillist. > =20 > Mehmet > =20 > From: Ersue, Mehmet (Nokia - DE/Munich)=20 > Sent: Tuesday, December 15, 2015 9:59 PM > To: netconf@ietf.org > Cc: 'core@ietf.org ' >; 'i2rs@ietf.org ' = >; '6lo@ietf.org = ' <6lo@ietf.org >; = '6tisch@ietf.org ' <6tisch@ietf.org = > > Subject: WG Last Call for draft-ietf-netconf-restconf-09, = draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 > =20 > Dear NETCONF WG, > =20 > we hereby issue a WG Last Call for the drafts below: > =20 > http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt = > http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt = > http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt = > =20 > Please review and send your comments to the NETCONF WG mailing list by = January 22, 2015 EOB PT. > =20 > The drafts on RESTCONF, YANG patch and YANG library are planned to = publish as standard track documents. > =20 > As RESTCONF is a major protocol we seek a detailed and thorough review = within NETCONF WG but also by the related WGs before publishing. > Therefore the WGLC is planned to finalize on January 22th (covering = the holiday time in between) and APP, INT and RTG area ADs will be = informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to = review. > =20 > Please take your time to review the documents and send your comments = to the NETCONF maillist by the deadline. > Please state on NETCONF maillist also explicitly, whether you have = read/reviewed and whether you support the publication. > Furthermore please indicate if you plan to implement or have already = implementations for RESTCONF and its supplementary drafts. > =20 > Thank you for your review and kind help getting RESTCONF = specifications stable. > =20 > Best Regards, > Mehmet and Mahesh --Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The Last Call period for the above three drafts closed = yesterday. Thanks to everyone who provided comments on the three = drafts.

The authors = will update the documents based on the comments received and post an = updated version of the draft(s).

Mahesh & Mehmet.

On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - = DE/Munich) <mehmet.ersue@nokia.com> wrote:

FYI and attention.
 
Please provide your = comments to NETCONF WG maillist.
 
Mehmet
 
From: Ersue, = Mehmet (Nokia - DE/Munich) 
Sent: Tuesday, December 15, 2015 = 9:59 PM
To: netconf@ietf.org
Cc: 'core@ietf.org' <core@ietf.org>; 'i2rs@ietf.org' <i2rs@ietf.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org>
Subject: WG Last Call for = draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and = draft-ietf-netconf-yang-library-03
 
Dear NETCONF WG,
 
we hereby issue a WG Last = Call for the drafts below:
 
http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt
 
Please review and send = your comments to the NETCONF WG mailing list by January 22, 2015 EOB = PT.
 
The = drafts on RESTCONF, YANG patch and YANG library are planned to publish = as standard track documents.
 
As RESTCONF is a major protocol we seek a = detailed and thorough review within NETCONF WG but also by the related = WGs before publishing.
Therefore the WGLC is planned to finalize on January 22th = (covering the holiday time in between) and APP, INT and RTG area ADs = will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited = to review.
 
Please take your time to review the documents and send your = comments to the NETCONF maillist by the deadline.
Please state on NETCONF maillist also = explicitly, whether you have read/reviewed and whether you support the = publication.
Furthermore please = indicate if you plan to implement or have already = implementations for RESTCONF and its supplementary = drafts.
 
Thank= you for your review and kind help getting RESTCONF specifications = stable.
 
Best = Regards,
Mehmet and = Mahesh




= --Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC-- From nobody Sun Jan 24 02:39:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E61B2DEC for ; Sun, 24 Jan 2016 02:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5yKc8CYOkux for ; Sun, 24 Jan 2016 02:39:27 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF9D1B2DEB for ; Sun, 24 Jan 2016 02:39:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 72B56946; Sun, 24 Jan 2016 11:39:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id azsG2Y_gFbl0; Sun, 24 Jan 2016 11:39:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 24 Jan 2016 11:39:24 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C8302002C; Sun, 24 Jan 2016 11:39:24 +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 3pMcEWLr_Fxd; Sun, 24 Jan 2016 11:39:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32CF520013; Sun, 24 Jan 2016 11:39:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 462EB39AD81F; Sun, 24 Jan 2016 11:39:20 +0100 (CET) Date: Sun, 24 Jan 2016 11:39:20 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160124103920.GA34787@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Randy Presuhn , Netconf References: <16305489.1453414191853.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <20160122.093855.1966604606532445328.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.4.2.3i Archived-At: Cc: Randy Presuhn , Netconf Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 10:39:30 -0000 Andy, can you provide a pointer to backup your claim? Thanks, /js On Fri, Jan 22, 2016 at 04:13:39AM -0800, Andy Bierman wrote: > Hi, > > The WG discussed this issue at length and decided not > to send 2 notifications for the same thing. That is why the > existing event is being used. I don't think anything changed > since this decision was made. > > > Andy > > > On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund wrote: > > > Randy Presuhn wrote: > > > Hi - > > > > > > >From: Martin Bjorklund > > > >Sent: Jan 21, 2016 1:53 PM > > > >To: randy_presuhn@mindspring.com > > > >Cc: netconf@ietf.org > > > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 > > > > > > > >Hi, > > > > > > > >Randy Presuhn wrote: > > > >> Hi - > > > >> > > > >> >From: Martin Bjorklund > > > >> >Sent: Jan 21, 2016 3:15 AM > > > >> >To: randy_presuhn@mindspring.com > > > >> >Cc: netconf@ietf.org > > > >> >Subject: Re: [Netconf] RP comments on > > draft-ietf-netconf-yang-library-03 > > > >> > > > > >> >Randy Presuhn wrote: > > > >> >> Hi - > > > >> >> > > > >> >> >From: Martin Bjorklund > > > >> >> >Sent: Jan 20, 2016 7:00 AM > > > >> >> >To: randy_presuhn@mindspring.com > > > >> >> >Cc: netconf@ietf.org > > > >> >> >Subject: Re: [Netconf] RP comments on > > draft-ietf-netconf-yang-library-03 > > > >> >> > > > > >> >> >Hi Randy, > > > >> >> > > > > >> >> >Thank you for your review! Comments inline. > > > >> >> > > > > >> >> >Randy Presuhn wrote: > > > > > > > >[...] > > > > > > > >> >> >> 2.1.1 module-set-id > > > > [...] > > > > > >> Getting a bit beyond the scope of this draft, this leaf presumes > > > >> a polling-based monitoring strategy. Forgive me for thinking > > > >> like an SNMP guy, but wouldn't it scale much better for the > > > >> system to be able to generate a notification whenever this > > > >> piece of information changes? > > > > > > > >For YANG 1.1, the module-set-id is actually presented in the > > > >capability in the message. > > > > > > > >Since the module-set-id is part of a capability, the server will > > > >generate a netconf-capability-change notification (defined in RFC > > > >6470) if the module set changes. > > > > > > This is helpful, but now I'm going to ask a particularly > > > ignorant question: does this explanation necessarily hold true > > > for all protocols used to shovel around information defined > > > using YANG models? > > > > No. I guess we could specify a notification "yang-library-change": > > > > notification yang-library-change { > > description > > "Generated when the set of modules and submodules supported > > by the server has changed."; > > leaf module-set-id { > > type leafref { > > path "/yanglib:module/yanglib:module-set-id"; > > } > > mandatory true; > > description > > "Contains the module-set-id value representing the > > set of modules and submodules supported at the server at the > > time the notification is generated."; > > } > > } > > > > but it is not obvious to me that such a notification would be the > > correct solution. If a new protocol gets defined that supports some > > kind of capability discovery, shouldn't that protocol define how > > capability changes are communicated in that particular protocol? > > > > > That is, do all protocols based on YANG > > > *necessarily* have a "" message and netconf-capability-change > > > notifications? It could be a mistake to treat quirks of the current > > > implementation environments for this model as though they would > > > hold true all future environments in which this model might be > > > employed. On the other hand, if this model is only intended to > > > be used in netconf protocol environments, case closed. :-) > > > > One of the main ideas with this module is to have a generic mechanism > > to discovery YANG modules regardless of protocol. Hmm, this statement > > clearly speaks for a generic notification... > > > > > > /martin > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jan 24 02:43:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5011B2DFC for ; Sun, 24 Jan 2016 02:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNRz-YqHbNlR for ; Sun, 24 Jan 2016 02:43:49 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D4F1B2DFB for ; Sun, 24 Jan 2016 02:43:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1EBA59DB; Sun, 24 Jan 2016 11:43:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id db84ftZDvqWm; Sun, 24 Jan 2016 11:43:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 24 Jan 2016 11:43:47 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FBDB2002B; Sun, 24 Jan 2016 11:43: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 7B4iiBg_MZtN; Sun, 24 Jan 2016 11:43:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB45820013; Sun, 24 Jan 2016 11:43:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B064239AD85B; Sun, 24 Jan 2016 11:43:44 +0100 (CET) Date: Sun, 24 Jan 2016 11:43:44 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160124104344.GA34881@elstar.local> Mail-Followup-To: Andy Bierman , "Uveges, Balint (Nokia - HU/Budapest)" , "netconf@ietf.org" References: <28B876C36C5AA84CBAB912BA734FAC35016F21EA@DEMUMBX006.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-restconf-09 review comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 10:43:51 -0000 On Fri, Jan 22, 2016 at 09:43:05AM -0800, Andy Bierman wrote: > > > 2. POST (Create Resource Mode) vs. XML > > Chapter 4.4.1 says: > > If the target resource type is a datastore or data resource, then the > > POST is treated as a request to create a top-level resource or child > > resource, respectively. The message-body is expected to contain the > > content of a child resource to create within the parent (target > > resource). > > > > If my understanding is correct, that means (taking the example-jukebox > > module as an example), if I apply a POST on the artist resource to create > > two new albums, I would have something like this in case of XML encoding, > > because it only contains the content of the child resources: > > POST /restconf/data/example-jukebox:jukebox/ > > library/artist=Foo%20Fighters HTTP/1.1 > > Host: example.com > > Content-Type: application/yang.data+xml > > > > > > Wasting Light > > > > g:alternative > > > > 2011 > > > > > > Sonic Highways > > > > g:alternative > > > > 2014 > > > > > > But that would result in an XML that is not well formed, since it does not > > have one root parameter. My assumption is, that if I create a new resource, > > I should also include the parent resource's, like: > > > > > > Wasting Light > > ...etc, etc... > > > > > > Could you verify which approach is correct? Would it make sense to reflect > > that in the document? > > > > > You have to use YANG Patch to modify multiple subtrees at once. > HTTP/REST allows 1 resource to be altered or retrieved at a time. Is the resource not /restconf/data/example-jukebox:jukebox/ in this case? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jan 24 03:03:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4F31B2E5B for ; Sun, 24 Jan 2016 03:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWfCbUuPfFeb for ; Sun, 24 Jan 2016 03:03:27 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::707]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588DB1B2E5A for ; Sun, 24 Jan 2016 03:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D0TODbOAQ8eQ/6/WBLATpcrEzWImzOyTXNexCsjV/uk=; b=ftr0rwimHjR2/EGY2+SWwmSTGSKiBRsTCTCc85wZVDXZWqsUcjyvE9QXUHO4DmqZD1fdROeP0PVbbgZ42rMgApXECx4mHrdCUbvVS8c+L+qjNTEGI6036/rQJ6d1bM8t5H5QnzAGboMRE/f7f0CPHKAZ+jt+5QZcP1zdbqvZhEU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sun, 24 Jan 2016 11:03:04 +0000 Message-ID: <00b401d15696$6528a260$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net><010901d155dc$dec87420$4001a8c0@gateway.2wire.net> Date: Sun, 24 Jan 2016 11:00:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: [86.185.87.133] X-ClientProxiedBy: HE1PR08CA0009.eurprd08.prod.outlook.com (25.161.112.19) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 2:eZKs5JuIlLjOg99TFs7C47ldfMBWbcn0mFH/Aib+q5Mn4nmyQ+HPB77w4gm6zl8pblOp6Ufpeyhjx4zp5qM4/vTjaZtrAIKez1dOeL6FRZXDU+0G+Zijh1oJE29kuujRpl9VR5hhP8n8RrtSdEyYzQ==; 3:SoGKT+z1mPtblZOFpMGsLF5qgJvCHOrGo+2/xlZHPS7zyq7O//kD8ytjZvyhVYOOhD0FHZiJr8iOp+YSEuwJNxvGuC+pzZB7lwsJim8m0ZX9ev1dKWzcyu+a6EaLuL9u; 25:rh6/t6fAUwmxGQj5VqguYqrbqyu3sUWJvkFL/OHq4zq2VA2iaWGAI+QsS7VBCnGsjzp/1J08CUB+OrZBRk6udvaveQvcaV3znK04VUQvkGlmxp6FGcI7puTUYPg9W+r5TkAPfcDkEIr0qH1exzxtMy9ZJtUCjWGX3hMoiI1mE284iKRGzicxX36wXdxlIPm44aUaGTmba/zLjCEmdAWaZWRpSRfal+rdBUtKNvh1wYQ6OE+uuo+1tdRJC0Uw+SqH X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-MS-Office365-Filtering-Correlation-Id: 9a2c5824-b427-4c63-7ff5-08d324adef2b X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 4:IlsPcTAnflnlisKgnyNhLPaWwFVec9Auvkuvnk8euOQl5EtwXh98ZmCEEx8cwjt1paCC0WwxbQ9E5INMZToZWvs+Eke1sxajgn2YTzlYhF7t/PVO0Hv8rOZKOoOeW7Sz0kSwyse6oXOo06fpNSIJSRnXep5YqJD/o0H+XKV+27gMkqSPLJeRNnQsZim9a0+tSWzcm2mHhygtz9KmrqWN9rqVy+fUXr3COJr3vvoCwDYu+5MuK3M0/6SzXy83aT5QiN07DN3Kypk+pWXTj+GYv2q6vPONubfeZyD4JeuIZG+ydZt1ZOqpfZGdrFJv2+XfvhZdjx9ZALFS5u+7x618AqrMossMlX3ueWIkOZ+b1iPQpR5NRPWhAIOrCQVaHuBvEk55YOGPyVpjDmFoHb97hNFEc24sn1fMNVN0lPKE+9JhFhCttEDO9rA+eztk/k3Y X-Forefront-PRVS: 0831C25939 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(13464003)(51444003)(377454003)(24454002)(87976001)(50466002)(76176999)(47776003)(44736004)(3846002)(84392002)(230700001)(14496001)(81816999)(50986999)(189998001)(23676002)(50226001)(77096005)(6116002)(586003)(101416001)(5008740100001)(5004730100002)(62236002)(15975445007)(1096002)(92566002)(230783001)(81156007)(1456003)(42186005)(33646002)(19580395003)(86362001)(1556002)(19580405001)(97736004)(93886004)(81686999)(2906002)(4326007)(116806002)(5001960100002)(66066001)(105586002)(106356001)(122386002)(40100003)(61296003)(110136002)(44716002)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTQ7MjM6TDdXVFVlVDFlOFB0OXlZbkdncXF4SjdULzR1?= =?utf-8?B?L1VBaVNyLzV2RnRSckpkNU5lbU9pWlpYUXR2UnpWUkF6akFpZmlweFFreGtM?= =?utf-8?B?VTQ4Vk1nenlJbVRXVUp3UlVDTDMyRWRRbU9Rc3NQc0R2Q3VyaGgrYm9WdGQ4?= =?utf-8?B?d2FnaXBYeTRnY3dPMkJMdjVyUWtGYnRNOVNGMkJSLzUyUGxMNm9EeDhLU01z?= =?utf-8?B?YjVlWnlLOUV1K0U3NEx1eUd6ZU5yRzZURHVuMnBibUJvM201Y1BaSjc0QzdG?= =?utf-8?B?Q01pV0RWcTdJTHRXZkkyOGRqU0MrTk5tYmRCMGsvQ080SVNFNjVMWklUSHhZ?= =?utf-8?B?eFc0c0NHL1J4MlRGbUczMVBtTDNYL1ViUVpyYUZuYnZRbnNOTFhObFE0c2dF?= =?utf-8?B?OXE2NVcvckNaYjM3TWh3YUVhb0QveGZSYTB2L1ZhYUdiRjBJbFBwNXFDTU1G?= =?utf-8?B?dGwxMFJTeHFWOVozQ1IvTlhoYTNkVDV5dUFsbUhwYkpTNk1GSkNIK09zK1pj?= =?utf-8?B?SDM2aW56cjMyRm9uOTUyR0xSdGJGU3lLdnpKazBMd3BGb0JXc1FHZUFsWmMw?= =?utf-8?B?aXJYWnVJVDJMYWVnL21wMUFMc1dSN3RZWGtXWmdIc09WZzd4a1VEcjdDK3BU?= =?utf-8?B?ZzluVnJSNkl2YmtLaTFuN0tVb25qbGUrUnk2TldXQk5pLzYrM1ZreG9oSHox?= =?utf-8?B?U21HUVBoZzI2OHVxQkpZOGI3QnVPQ0phUTNDVzEzckpseUtCRCtWcklUVG1M?= =?utf-8?B?a0ZUU2FGeVJmcUErMlpTV0dWdEdqYXpnSHpEcUhMY0FPS0lFeEZ6NEpobEJ3?= =?utf-8?B?WVkzZlBlVHFGQTZQUUdXSXcyZGl0SVdCSGxtVWRqb3l3dmI0Yks1U2xnSXJB?= =?utf-8?B?TXltektvSDZEaHZEaklDbzBpdGhzVWNJVlg2UlhjbUtlMEpKWDVNYlNRRENH?= =?utf-8?B?ejU5WWpUNjRSWVQrYnhIcFZ1dTE5a2R1Y3VtaFI3WlVHSjNsVi9rK3hLclJh?= =?utf-8?B?dlBneG9VRC85MTJhTVRiV3VkeDhTcCtuZWpEUk5oRzFxQ0NjT0xpdE8wc05P?= =?utf-8?B?cEtwVUkyWnNIcGdlWXNRK1htaDNoczhLOEtBOWczeXltZzNBS09xa0Z5VG9W?= =?utf-8?B?WWJSMzZWd2lWQWhhN3lhZEZ1ejVnM0lhUU5oWTlpeXMvOE93ZmRhZHNCSjgx?= =?utf-8?B?L1kwUk5Uc2dDTDhNM0Y1M0l4cGhGY2dZZEV0UHhPMjNRTEgyS1A4cDVPU2Y1?= =?utf-8?B?V0VwUER2a2NGU1p0Mm95Ky9GSHVJOUJTUklLUi82dEV1NjlDRGVoZEt0SDhM?= =?utf-8?B?Q3I1ZHNaRGhNU0htNUNmbjBVb2pVUEliZE9oVWlTTXNZTk5GbEx2Q0RzMHlY?= =?utf-8?B?c1A0OVA5TE5HUjkvTVE3Sjk0Mzg1N096cDI5MExoaFdwd2FDK2ljbkY3TUU3?= =?utf-8?B?dXA2Q1dTMFZEaEhUTnRRS0lHdk5SVlh1SVdQVU5iV1pQZzdYTWdGZ1VVTUlN?= =?utf-8?B?RHhnemM5TGl1ZGtDWXlzN29oWkh5aHVrdXJENHMxY21qZm83cklzTmJoZFpG?= =?utf-8?B?M3huTjdVaWJIOGh6QUlYUitRWXVwaWc2bjZ6UE91NHNUNk4waWxLVkwvQUNh?= =?utf-8?B?Y1B5Q2xUelExVkQ5SVRnN3Zla0RWUFY4OEt1TjVScGppK3phVTdGSTVaQzds?= =?utf-8?B?cXUyWUF4MVJFYTVVdVZEZlMyODVJL2pNK0NhWmFiNFU3cXJ1WHJRS0FtSnZV?= =?utf-8?B?Lzl3WXIrMmU4b3ljYVppcFBScWllSlZTc2JtcTVDaU1VZDdQTDFwM1VvaDY3?= =?utf-8?B?MmcyRnFjRzZNSXQwMllPVTRnbTdkeU5laVlYVHFFek1hU3NvNXpuTDAzVjBr?= =?utf-8?B?WHQ1NG81Mmt3UG1ndGZDNTNJYURlekNIUytFSHRwVkw5R3NGeDFRV1YzTWFW?= =?utf-8?B?SkVaaEJSbkxVMGthNmU1QWpzSTc4eUJLMmZhZmtPY1RUbmhWY1NaY3JQWVBL?= =?utf-8?B?ZU13anpOMjhjQTZKQWc4ZWdaUllnMlovb3RBRU84aWc1SVRBejQ3VkQ5MHBu?= =?utf-8?Q?xG0=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 5:NDdt83RdUIUM/9O/yarbVyiScIAZYU10yyNUBM6F0AZChH9qubnwMrgeElXqsIOOw8UZIEo6bdvr3bvnD8UFU3LSBhswdJKHh31Biy8tPNSr9INdGB/OqcTPGpco1f+Fto5zOw1dErFUKn7XTaKNjg==; 24:o+ITwlSrKfcLFcIQrbqyavKO2VhODmMC7eQMWp2vi3ZPEbO3Hq/WvbFr4k4ZECAbVlqcNjPHmmB4VCiGuIQAdUu6JEnuixjDzysuwK30hHw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2016 11:03:04.4615 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 11:03:34 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "Ersue, Mehmet (Nokia - DE/Munich)" ; "Netconf" Sent: Saturday, January 23, 2016 3:13 PM > > Would your concerns be we put more detail in the NETCONF Coexistence > section. > I have already pointed out that the confirmed-commit details are missing. > We will make it clear which details a RESTCONF client needs to know. > > We can add another short section for RESTCONF only considerations. > I thought it was already clear that implementation of NETCONF was not > required, but we can make it extra clear. > > Applicability is another problem. IMO let the market decide. > Some companies (and WGs) are already working on solutions that provide a > unified > "YANG development environment" to deploy with whatever protocol, across a > range of > platforms from IoT to SDN. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF) > The boundaries of applicability are subjective and might be rapidly > changing for awhile. > (So I don't want to write an AS for RESTCONF.) Andy I think that it is s1.3 that most needs changing, as I said in my first e-mail of comments, but that its direction needs changing, to become 'Relationship with NETCONF'. It should then say (although not in this order) - a restconf client may or may not also be a NETCONF client - a restconf server may or may not also be a NETCONF server (and that is all I am intending by way of applicability) - restconf replaces NETCONF the protocol but does use everything else from NETCONF, followed by an exhaustive list, which would include at least: state date and configuration data, multiple datastores, data persistence (yes, I know RFC6241 is rather vague), (roll back on) error handling, defaults, capabilities (e.g :writable-running), locks, ... Tom Petch > Andy > > > On Sat, Jan 23, 2016 at 4:51 AM, t.petch wrote: > > > ---- Original Message ----- > > From: "Andy Bierman" > > Sent: Friday, January 22, 2016 4:32 PM > > > > > Why is it rubbish that there can be a RESTCONF-only server? > > > I can't find any text that says NETCONF MUST be implemented > > > if RESTCONF is implemented. > > > > > > Some details (like defaults handling) are aligned with NETCONF. > > > That doesn't mean the RESTCONF client needs to know much > > > about NETCONF datastores or locks, etc. > > > > Andy > > > > I find the I-D silent on its applicability. I see > > " RESTCONF can be implemented on a device that supports NETCONF." > > which I regard as close to marketing but have no problem with it being > > there. What I lack is any indication as to whether or not it is > > feasible to have a restconf-only management system. restconf lacks some > > of NETCONF's capabilities so is it expected that the server will be > > NETCONF as well or is the expectation that there will be restconf-only > > systems? > > > > This colours how I comment on the following text. One small example of > > several is in s.12 > > > > "Implementors SHOULD provide a comprehensive > > authorization scheme with RESTCONF and ensure that the resulting > > NETCONF username is made available to the RESTCONF server." > > > > which implies to me that the server has NETCONF capabilities, at least > > in part. If not, then s.12 needs rewriting, along the lines that > > restconf imports the idea of a username (along with masses of other > > things) from NETCONF and must conform to the specification of usersname > > as in section .. of RFC ..... > > > > So can there be a restconf-only system, clients and servers? (dunno, > > I-D implies not) > > Can a server support restconf and NETCONF? yes, s1.2 tells me so > > Can a restconf-only client do useful work with a hybrid restconf/NETCONF > > server? (hopefully) > > Can a client support restconf and NETCONF and use them to work with > > restconf-only servers and NETCONF-only servers? um, authentication > > needs thinking about but hopefully yes > > > > I find the I-D incomplete without this being clearly stated. > > > > My comment of 'rubbish' was aimed at a different point, where the I-D > > says that > > " the user should not need any prior knowledge of NETCONF in order to > > use RESTCONF." > > To me it is abundantly clear that the user must understand NETCONF in > > depth in order to make sense of this I-D and I extrapolate that to > > understanding NETCONF in order to make use of restconf. There may or > > may not be a need to have access to NETCONF client/server, which is my > > point above, but there has to be an understanding of the concepts of > > NETCONF in order to make sense of restconf. You of course, along with > > your fellow authors, WG Chairs, WG ADs, have that in depth. I have it > > to some degree. Someone without such knowledge has no hope of > > understanding or using restconf! > > > > Tom Petch > > > > > Andy > > > > > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch wrote: > > > > > > > Having read all of restconf, I find myself with some fairly basic > > > > questions for which I cannot see answers. > > > > > > > > A) Is restconf an optional extra for a server on top of NETCONF or > > do > > > > you expect there to be restconf-only servers? S.1.3 says that they > > can > > > > coexists, yes, great, marketing. But can you perform useful > > operational > > > > tasks from a restconf-only client to a restconf-only server? I > > started > > > > off assuming you could, but ended up thinking the I-D was telling me > > > > that at least the server musy have both e.g. s.12 > > > > "it does require that an authenticated NETCONF username be > > associated > > > > with each request" > > > > which also begs the question, can there be restconf-only client? > > > > > > > > Needs specifying IMO, perhaps after thinking through the > > consequences. > > > > > > > > B) " the user should not need any prior knowledge of NETCONF in > > order to > > > > use RESTCONF" > > > > Well, I wrote 'rubbish' alongside that and taken literally, it is:=) > > > > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF the > > > > operational infrastructure (configuration, state, datastore, event, > > > > error handling, persistence of data. ....) and while the former is > > > > replaced, in whole or in part, by restconf, the latter most > > definitely > > > > is not, as exemplified by the definitions imported in s.1.4.1 > > > > > > > > But that also in untrue. This I-D implies, mostly without being > > > > explicit, that it refines NETCONF the operational infrastructure > > > > (perhaps using the terms in a different way). Thus it appears that > > > > there is no explicit selection of NETCONF datastore but that which > > one > > > > is chosen is implicit. I infer this from s.1.3 but think that it > > needs > > > > separating out more clearly. > > > > > > > > C) configuration and state; RFC 6241 is very clear about this, this > > I-D > > > > seems to be half way towards whatever resolution netmod comes to on > > > > netmod-opstate-reqs, which is probably not a good idea. 'state' I > > see > > > > used only twice, then this undefined 'operational data' takes over > > and > > > > the water is then muddied by 'config' and 'nonconfig'. This is > > > > wandering off into its own 'restconf the operational infrastructure' > > > > without ever saying AFAICT how it differs from NETCONF. It is as if > > the > > > > three authors each independently wrote parts of the I-D:-) > > > > > > > > D) Then there are datastores, at least there are until s.4.4.1, when > > > > datastore seems to be redefined to mean 'top level node' a term > > which > > > > has surfaced on the (netmod or netconf) mailing list as being > > something > > > > that is not defined and may mean different things to different > > people. > > > > I read the first half of the I-D thinking that 'datastore' is as > > defined > > > > in RFC6241 and then find half way through that I cannot see any way > > that > > > > it is. I note the absence of any examples involving > > > > 'application/yang.datastore' > > > > and think, well yes, that figures! > > > > > > > > E) This then calls into question for me the meaning of the term > > 'data'. > > > > In the latter part of the I-D, it seems to be shorthand for 'data or > > > > datastore' with datastore having its non-NETCONF meaning but early > > on, > > > > it is used alongside 'datastore' suggesting that it has a more > > > > restricted meaning, coupled with the use of different media types, > > but I > > > > cannot tell. > > > > > > > > So, I have some detailed comments on s.4 onwards but think that the > > > > 'beams' need resolving first. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "t.petch" > > > > To: > > > > Cc: > > > > Sent: Wednesday, January 20, 2016 6:43 PM > > > > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > > > > draft-ietf-netconf-yang-patch-07 and > > draft-ietf-netconf-yang-library-03 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > From nobody Sun Jan 24 06:52:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2424F1A0029 for ; Sun, 24 Jan 2016 06:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxZUusbEterT for ; Sun, 24 Jan 2016 06:52:02 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341A91A0026 for ; Sun, 24 Jan 2016 06:52:02 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id h129so71840592lfh.3 for ; Sun, 24 Jan 2016 06:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=s1T5umKRo9pBFF2/F0iO/JORYc1PqFMCC2cmCtnHpis=; b=YReb6czlOQj+6D7tC4rgUkjPB2qu6GJT5LZYRf72+VNv0kyRcZQ+74JcEttBa2SrBv fEWdSP+08hcUVDSKoRqkd3Xc/Z1EaAwMs3i3r2IWOLDrHQJslr0f5MqK/kJqJCoFNQcH fXVQzBs+f6W8pYOfYpM0O6f0qP3B13VJzyXcuFHMQXlOK6vJX0xMe980h3e6SclcYzX/ ty1wdwnZFkzZd9SX+KNCzfwmpU7SE4A3cWQcFrQ41bM1tLtOEgydd5+YAwA0JyiPjJhP 9Tadn6KS0/k0Or3zTEFof7MeCwUgHaNKlFJttmec64eWBou57NA4wmNE70HO1ADU1gL5 mG2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=s1T5umKRo9pBFF2/F0iO/JORYc1PqFMCC2cmCtnHpis=; b=DIeh4PGucSz+e03u8waoqdwb++C/lHEjVp3KeFGz1pvycB8tT20njQOFHA1DXq+3lP LBgNBpoRI9d/HR6IUJX7hpdzQJKYzVlKCidagK+K4YtrqvcYet0aL1TPcEqa27eRFQj8 B9pABTymb7f0fken8Ax/6aVRWdH2ja8vXI0ezqpbIlc4cCTUdf1qEL4Q1Qwx2vLDeeU1 +9R/VQk8v95tXtEQISnlF3ezm/MI1DbM5qQeLk3tq38wShyqWlMbPUbRrpQIhEjSVjPg 1rUPd/uSOldSAwO+VAXktDioYA/D66K/rI06YpfF6vVnyYiEF4Y/Le3W50RJwQe/OnEF yZ2A== X-Gm-Message-State: AG10YORsipM2MccP1RH78Z3lglJHa7hkA0kequmKuzbNHqwdLhf+N6jxXFEBAxOL/v2Wtr+pfVyiQgyqdMWwWA== MIME-Version: 1.0 X-Received: by 10.25.90.83 with SMTP id o80mr4686834lfb.23.1453647120325; Sun, 24 Jan 2016 06:52:00 -0800 (PST) Received: by 10.112.200.167 with HTTP; Sun, 24 Jan 2016 06:52:00 -0800 (PST) In-Reply-To: <20160124103920.GA34787@elstar.local> References: <16305489.1453414191853.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <20160122.093855.1966604606532445328.mbj@tail-f.com> <20160124103920.GA34787@elstar.local> Date: Sun, 24 Jan 2016 06:52:00 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Randy Presuhn , Netconf Content-Type: multipart/alternative; boundary=001a1140042a3c7833052a159846 Archived-At: Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:52:05 -0000 --001a1140042a3c7833052a159846 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 2:39 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Andy, > > can you provide a pointer to backup your claim? > > I was wrong. We discussed adding the module-set-id leaf to the netconf-capability-change event. But there is no augment-stmt in the YANG module for this detail. Looks like when we decided to claim there is no relationship between ietf-netconf-monitoring and RESTCONF, that this got dropped or taken out. So I don't care if a notification is added. > Thanks, > > /js > Andy > > On Fri, Jan 22, 2016 at 04:13:39AM -0800, Andy Bierman wrote: > > Hi, > > > > The WG discussed this issue at length and decided not > > to send 2 notifications for the same thing. That is why the > > existing event is being used. I don't think anything changed > > since this decision was made. > > > > > > Andy > > > > > > On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund > wrote: > > > > > Randy Presuhn wrote: > > > > Hi - > > > > > > > > >From: Martin Bjorklund > > > > >Sent: Jan 21, 2016 1:53 PM > > > > >To: randy_presuhn@mindspring.com > > > > >Cc: netconf@ietf.org > > > > >Subject: Re: [Netconf] RP comments on > draft-ietf-netconf-yang-library-03 > > > > > > > > > >Hi, > > > > > > > > > >Randy Presuhn wrote: > > > > >> Hi - > > > > >> > > > > >> >From: Martin Bjorklund > > > > >> >Sent: Jan 21, 2016 3:15 AM > > > > >> >To: randy_presuhn@mindspring.com > > > > >> >Cc: netconf@ietf.org > > > > >> >Subject: Re: [Netconf] RP comments on > > > draft-ietf-netconf-yang-library-03 > > > > >> > > > > > >> >Randy Presuhn wrote: > > > > >> >> Hi - > > > > >> >> > > > > >> >> >From: Martin Bjorklund > > > > >> >> >Sent: Jan 20, 2016 7:00 AM > > > > >> >> >To: randy_presuhn@mindspring.com > > > > >> >> >Cc: netconf@ietf.org > > > > >> >> >Subject: Re: [Netconf] RP comments on > > > draft-ietf-netconf-yang-library-03 > > > > >> >> > > > > > >> >> >Hi Randy, > > > > >> >> > > > > > >> >> >Thank you for your review! Comments inline. > > > > >> >> > > > > > >> >> >Randy Presuhn wrote: > > > > > > > > > >[...] > > > > > > > > > >> >> >> 2.1.1 module-set-id > > > > > > [...] > > > > > > > >> Getting a bit beyond the scope of this draft, this leaf presumes > > > > >> a polling-based monitoring strategy. Forgive me for thinking > > > > >> like an SNMP guy, but wouldn't it scale much better for the > > > > >> system to be able to generate a notification whenever this > > > > >> piece of information changes? > > > > > > > > > >For YANG 1.1, the module-set-id is actually presented in the > > > > >capability in the message. > > > > > > > > > >Since the module-set-id is part of a capability, the server will > > > > >generate a netconf-capability-change notification (defined in RFC > > > > >6470) if the module set changes. > > > > > > > > This is helpful, but now I'm going to ask a particularly > > > > ignorant question: does this explanation necessarily hold true > > > > for all protocols used to shovel around information defined > > > > using YANG models? > > > > > > No. I guess we could specify a notification "yang-library-change": > > > > > > notification yang-library-change { > > > description > > > "Generated when the set of modules and submodules supported > > > by the server has changed."; > > > leaf module-set-id { > > > type leafref { > > > path "/yanglib:module/yanglib:module-set-id"; > > > } > > > mandatory true; > > > description > > > "Contains the module-set-id value representing the > > > set of modules and submodules supported at the server at the > > > time the notification is generated."; > > > } > > > } > > > > > > but it is not obvious to me that such a notification would be the > > > correct solution. If a new protocol gets defined that supports some > > > kind of capability discovery, shouldn't that protocol define how > > > capability changes are communicated in that particular protocol? > > > > > > > That is, do all protocols based on YANG > > > > *necessarily* have a "" message and netconf-capability-change > > > > notifications? It could be a mistake to treat quirks of the current > > > > implementation environments for this model as though they would > > > > hold true all future environments in which this model might be > > > > employed. On the other hand, if this model is only intended to > > > > be used in netconf protocol environments, case closed. :-) > > > > > > One of the main ideas with this module is to have a generic mechanism > > > to discovery YANG modules regardless of protocol. Hmm, this statement > > > clearly speaks for a generic notification... > > > > > > > > > /martin > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1140042a3c7833052a159846 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 2:39 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Andy,

can you provide a pointer to backup your claim?



I was wrong.
= We discussed adding the module-set-id leaf to the netconf-capability-change= event.
But there is no augment-stmt in the YANG module for this = detail.=C2=A0 Looks like when we decided
to claim there is no rel= ationship between ietf-netconf-monitoring and RESTCONF,
that this= got dropped or taken out.

So I don't care if = a notification is added.

=C2=A0
Thanks,

/js

Andy
=C2=A0

On Fri, Jan 22, 2016 at 04:13:39AM -0800, Andy Bierman wrote:
> Hi,
>
> The WG discussed this issue at length and decided not
> to send 2 notifications for the same thing.=C2=A0 That is why the
> existing event is being used.=C2=A0 I don't think anything changed=
> since this decision was made.
>
>
> Andy
>
>
> On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> > > Hi -
> > >
> > > >From: Martin Bjorklund <mbj@tail-f.com>
> > > >Sent: Jan 21, 2016 1:53 PM
> > > >To: rand= y_presuhn@mindspring.com
> > > >Cc: netconf@ietf.org=
> > > >Subject: Re: [Netconf] RP comments on draft-ietf-netconf= -yang-library-03
> > > >
> > > >Hi,
> > > >
> > > >Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> > > >> Hi -
> > > >>
> > > >> >From: Martin Bjorklund <mbj@tail-f.com>
> > > >> >Sent: Jan 21, 2016 3:15 AM
> > > >> >To: randy_presuhn@mindspring.com
> > > >> >Cc: netconf= @ietf.org
> > > >> >Subject: Re: [Netconf] RP comments on
> > draft-ietf-netconf-yang-library-03
> > > >> >
> > > >> >Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> > > >> >> Hi -
> > > >> >>
> > > >> >> >From: Martin Bjorklund <mbj@tail-f.com>
> > > >> >> >Sent: Jan 20, 2016 7:00 AM
> > > >> >> >To: randy_presuhn@mindspring.com
> > > >> >> >Cc: netconf@ietf.org
> > > >> >> >Subject: Re: [Netconf] RP comments on<= br> > > draft-ietf-netconf-yang-library-03
> > > >> >> >
> > > >> >> >Hi Randy,
> > > >> >> >
> > > >> >> >Thank you for your review!=C2=A0 Comme= nts inline.
> > > >> >> >
> > > >> >> >Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> > > >
> > > >[...]
> > > >
> > > >> >> >> 2.1.1 module-set-id
> >
> > [...]
> >
> > > >> Getting a bit beyond the scope of this draft, this = leaf presumes
> > > >> a polling-based monitoring strategy.=C2=A0 Forgive = me for thinking
> > > >> like an SNMP guy, but wouldn't it scale much be= tter for the
> > > >> system to be able to generate a notification whenev= er this
> > > >> piece of information changes?
> > > >
> > > >For YANG 1.1, the module-set-id is actually presented in= the
> > > >capability in the <hello> message.
> > > >
> > > >Since the module-set-id is part of a capability, the ser= ver will
> > > >generate a netconf-capability-change notification (defin= ed in RFC
> > > >6470) if the module set changes.
> > >
> > > This is helpful, but now I'm going to ask a particularly=
> > > ignorant question: does this explanation necessarily hold tr= ue
> > > for all protocols used to shovel around information defined<= br> > > > using YANG models?
> >
> > No.=C2=A0 I guess we could specify a notification "yang-libr= ary-change":
> >
> >=C2=A0 =C2=A0notification yang-library-change {
> >=C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Generated when the set of modules= and submodules supported
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 by the server has changed.";
> >=C2=A0 =C2=A0 =C2=A0leaf module-set-id {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path "/yanglib:module/yangl= ib:module-set-id";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Contains the module-set-id= value representing the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set of modules and submodules s= upported at the server at the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 time the notification is genera= ted.";
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0}
> >
> > but it is not obvious to me that such a notification would be the=
> > correct solution.=C2=A0 If a new protocol gets defined that suppo= rts some
> > kind of capability discovery, shouldn't that protocol define = how
> > capability changes are communicated in that particular protocol?<= br> > >
> > > That is, do all protocols based on YANG
> > > *necessarily* have a "<hello>" message and n= etconf-capability-change
> > > notifications?=C2=A0 It could be a mistake to treat quirks o= f the current
> > > implementation environments for this model as though they wo= uld
> > > hold true all future environments in which this model might = be
> > > employed.=C2=A0 On the other hand, if this model is only int= ended to
> > > be used in netconf protocol environments, case closed.=C2=A0= :-)
> >
> > One of the main ideas with this module is to have a generic mecha= nism
> > to discovery YANG modules regardless of protocol.=C2=A0 Hmm, this= statement
> > clearly speaks for a generic notification...
> >
> >
> > /martin
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >

> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a1140042a3c7833052a159846-- From nobody Sun Jan 24 06:55:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2632E1A0018 for ; Sun, 24 Jan 2016 06:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj1cO12dVHV7 for ; Sun, 24 Jan 2016 06:55:02 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05D01A0010 for ; Sun, 24 Jan 2016 06:55:01 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id cl12so62309857lbc.1 for ; Sun, 24 Jan 2016 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4u0E4ssfrdYCFmdXOunacRfoiD3uCYu4KAIZ+AqBnH0=; b=C3W61o5dUEpq2z8RA48cQdgUHlDB7zHuMgA905HYSsCgteZII8Glnc5N6IMaelbEbv r5xh8wY9jywu4mi1rnweATWOx3ihVSUZubZIVwQJPq5A5an1BZ89FYEk9ZI8rIkJrs/E N+dejW52reLIP9kcvLa9qeq7X5mF9smf6/C0+47HixlmbqdqoZEh0ROkDXFUNWRGce1Y zBDCSEMgw2GIpMffLO1r/AU7Fi0E8r/E3Z3HmJteokHsmO1aAmq2MIxBSRw6aTaR74kZ EW3q6s7Eh2RSF3SrI7t53eG5fEpzHlmejYRO8Sb8RP591jNJxzzNl13mTaw5Rdq+C+kk vlOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4u0E4ssfrdYCFmdXOunacRfoiD3uCYu4KAIZ+AqBnH0=; b=WxCJGpqjgeo+cRQPx/QKwW5tUY+JoBfP/z8k5QlJ6kk9TCT/eKUigE4hDLM7QlvBg7 yZpFrGgzGZyxCDbUcRh2XO8SgqO1cKL2fCOSlUIQIgfcSInJIBUFIRRqI84SuOqDJSWO pou8QDB1TRICdFJ/XgxT2JEN+hO+RKndBIIaOHIC0x/g87L1GkFIqbrwN+0rmQ6zRUgU 4UNwPb2bIUNOO2S74wM6g2dYU+CSWVjb9sU3H9reWlFdvKJevrHP60NNOpFFHZnD4LqV I1jGMJujob5eLBvpdJ7J1bVTqsHFCY2848q49kRUO6gTAwIeYG1cMIHbRrrP3cusAXvc i8zA== X-Gm-Message-State: AG10YOT7/sTzP4DozG/q78N1yLBrVY+sNfOKM85ef4bZvKXfeDqw4uCyUciTlpLMnVXHZSpPg9St2jra5fqoyQ== MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr4524234lbb.66.1453647300202; Sun, 24 Jan 2016 06:55:00 -0800 (PST) Received: by 10.112.200.167 with HTTP; Sun, 24 Jan 2016 06:55:00 -0800 (PST) In-Reply-To: <20160124104344.GA34881@elstar.local> References: <28B876C36C5AA84CBAB912BA734FAC35016F21EA@DEMUMBX006.nsn-intra.net> <20160124104344.GA34881@elstar.local> Date: Sun, 24 Jan 2016 06:55:00 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Uveges, Balint (Nokia - HU/Budapest)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=089e01161bf4f52e13052a15a2c0 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-restconf-09 review comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:55:04 -0000 --089e01161bf4f52e13052a15a2c0 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 2:43 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Jan 22, 2016 at 09:43:05AM -0800, Andy Bierman wrote: > > > > > 2. POST (Create Resource Mode) vs. XML > > > Chapter 4.4.1 says: > > > If the target resource type is a datastore or data resource, then > the > > > POST is treated as a request to create a top-level resource or child > > > resource, respectively. The message-body is expected to contain the > > > content of a child resource to create within the parent (target > > > resource). > > > > > > If my understanding is correct, that means (taking the example-jukebox > > > module as an example), if I apply a POST on the artist resource to > create > > > two new albums, I would have something like this in case of XML > encoding, > > > because it only contains the content of the child resources: > > > POST /restconf/data/example-jukebox:jukebox/ > > > library/artist=Foo%20Fighters HTTP/1.1 > > > Host: example.com > > > Content-Type: application/yang.data+xml > > > > > > > > > Wasting Light > > > > > > g:alternative > > > > > > 2011 > > > > > > > > > Sonic Highways > > > > > > g:alternative > > > > > > 2014 > > > > > > > > > But that would result in an XML that is not well formed, since it does > not > > > have one root parameter. My assumption is, that if I create a new > resource, > > > I should also include the parent resource's, like: > > > > > > > > > Wasting Light > > > ...etc, etc... > > > > > > > > > Could you verify which approach is correct? Would it make sense to > reflect > > > that in the document? > > > > > > > > You have to use YANG Patch to modify multiple subtrees at once. > > HTTP/REST allows 1 resource to be altered or retrieved at a time. > > Is the resource not /restconf/data/example-jukebox:jukebox/ in this > case? > > You can patch the jukebox with multiple 'create' edits. What is your concern? > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e01161bf4f52e13052a15a2c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 2:43 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jan 22, 2016 at 09:43:05AM -0800, Andy Bierm= an wrote:
>
> > 2. POST (Create Resource Mode) vs. XML
> > Chapter 4.4.1 says:
> >=C2=A0 =C2=A0 If the target resource type is a datastore or data r= esource, then the
> >=C2=A0 =C2=A0 POST is treated as a request to create a top-level r= esource or child
> >=C2=A0 =C2=A0 resource, respectively.=C2=A0 The message-body is ex= pected to contain the
> >=C2=A0 =C2=A0 content of a child resource to create within the par= ent (target
> >=C2=A0 =C2=A0 resource).
> >
> > If my understanding is correct, that means (taking the example-ju= kebox
> > module as an example), if I apply a POST on the artist resource t= o create
> > two new albums, I would have something like this in case of XML e= ncoding,
> > because it only contains the content of the child resources:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0POST /restconf/data/example-jukebox:juk= ebox/
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library/artist=3DFoo%20Fi= ghters=C2=A0 HTTP/1.1
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Host: example.com
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Content-Type: application/yang.data+xml=
> >
> >=C2=A0 =C2=A0 =C2=A0 <album xmlns=3D"http://ex= ample.com/ns/example-jukebox">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>Wasting Light</name><= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<genre xmlns:g=3D"h= ttp://example.com/ns/example-jukebox">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g:alternative
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</genre>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<year>2011</2011>
> >=C2=A0 =C2=A0 =C2=A0 </album>
> >=C2=A0 =C2=A0 =C2=A0 <album xmlns=3D"http://ex= ample.com/ns/example-jukebox">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>Sonic Highways</name>=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<genre xmlns:g=3D"h= ttp://example.com/ns/example-jukebox">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0g:alternative
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</genre>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<year>2014</2011>
> >=C2=A0 =C2=A0 =C2=A0</album>
> >
> > But that would result in an XML that is not well formed, since it= does not
> > have one root parameter. My assumption is, that if I create a new= resource,
> > I should also include the parent resource's, like:
> >=C2=A0 =C2=A0 =C2=A0<artist>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<album xmlns=3D"htt= p://example.com/ns/example-jukebox">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>Wasting Light</na= me>
> >=C2=A0 =C2=A0 =C2=A0...etc, etc...
> >=C2=A0 =C2=A0 =C2=A0</artist>
> >
> > Could you verify which approach is correct? Would it make sense t= o reflect
> > that in the document?
> >
> >
> You have to use YANG Patch to modify multiple subtrees at once.
> HTTP/REST allows 1 resource to be altered or retrieved at a time.

Is the resource not /restconf/data/example-jukebox:jukebox/ in this
case?


You can patch the jukebox with multiple 'create&= #39; edits.
What is your concern?



=C2=A0
/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--089e01161bf4f52e13052a15a2c0-- From nobody Sun Jan 24 06:59:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305471A005A for ; Sun, 24 Jan 2016 06:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VwogYnhJf9C for ; Sun, 24 Jan 2016 06:59:40 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9691A0056 for ; Sun, 24 Jan 2016 06:59:39 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id h129so71893716lfh.3 for ; Sun, 24 Jan 2016 06:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1y8lFDa25JxSV7rxac9ectg/HOyo2dwCEtCdNFYD3Cs=; b=YlYWe1dSr+Sal/U0h0jfsPo83z29Jb7nnxb4PkLxUXEASrQhTGlpzaY3bC3lzL4w9v KZZ4zPIaknRSdGKsjS8xjj6V7EldaBCeHZzj9YcWJIQvdqBk4eKVjlpMw2PaqWwIvDcM Vn8bTHmg4Na7lrtIlzhPDFCfCSDc+CmS4B7MZC5oSUAk/n9/E3VlYf+oPz8oPcSILbp/ fhcZjII34HLl/5Ow6dofJWe67QC9bdfESZiYwcVrpamh7JLxzf3q/xUJkQvX36f7PNyf NuQ11Xozj9MUcm7Px7WbG6+K4zAlWv5MPqYrYGWU21vDv206UDXS8oFA+H2+hSNl7xrV Wrqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1y8lFDa25JxSV7rxac9ectg/HOyo2dwCEtCdNFYD3Cs=; b=fMdOj7cgnvKnu+gyzCe/BjclU1oAfuAxgqe0gDJu1K+Ssvgj2ifVBCiAQd+8aqLp3F hv7Te76RsbCM6zdiVYIDXQ6vI6Y/9ZsHNUDLjBlsvm1GqBMWKBcU+e+60LsNtda3VaQX 8hiFSsuvQM6tDCE8GEM6YcBWLVW2+KVn3LG7FrWTNnpwjiln3wTNonhf1fx6ehuO4VwM biH+K7ODY/t5XJ69qCnRlriNqPjNKZNxxf5qvxGo44cMETmKuh9XLrqHQEk+jvdMnFDY Vq2O4CrEECw4U5FiBHtkzHyYldS7ier+0hYx3W6mCHGjW7GjLFmr2VvfeMDHExHbvHs+ ECtg== X-Gm-Message-State: AG10YORsY2HQ5mXTUHaT53KBvau17AnBA40pZd1L2/P9/hTItL+hc0Fb0aI50ucn5DJUUulGbJ30XjB9fteNmw== MIME-Version: 1.0 X-Received: by 10.25.155.194 with SMTP id d185mr4912769lfe.8.1453647578192; Sun, 24 Jan 2016 06:59:38 -0800 (PST) Received: by 10.112.200.167 with HTTP; Sun, 24 Jan 2016 06:59:38 -0800 (PST) In-Reply-To: <00b401d15696$6528a260$4001a8c0@gateway.2wire.net> References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net> <010901d155dc$dec87420$4001a8c0@gateway.2wire.net> <00b401d15696$6528a260$4001a8c0@gateway.2wire.net> Date: Sun, 24 Jan 2016 06:59:38 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a113fbdd486f57f052a15b3fc Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:59:44 -0000 --001a113fbdd486f57f052a15b3fc Content-Type: text/plain; charset=UTF-8 On Sun, Jan 24, 2016 at 3:00 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Cc: "Ersue, Mehmet (Nokia - DE/Munich)" ; > "Netconf" > Sent: Saturday, January 23, 2016 3:13 PM > > > > Would your concerns be we put more detail in the NETCONF Coexistence > > section. > > I have already pointed out that the confirmed-commit details are > missing. > > We will make it clear which details a RESTCONF client needs to know. > > > > We can add another short section for RESTCONF only considerations. > > I thought it was already clear that implementation of NETCONF was not > > required, but we can make it extra clear. > > > > Applicability is another problem. IMO let the market decide. > > Some companies (and WGs) are already working on solutions that provide > a > > unified > > "YANG development environment" to deploy with whatever protocol, > across a > > range of > > platforms from IoT to SDN. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF) > > The boundaries of applicability are subjective and might be rapidly > > changing for awhile. > > (So I don't want to write an AS for RESTCONF.) > > Andy > > I think that it is s1.3 that most needs changing, as I said in my first > e-mail of comments, but that its direction needs changing, to become > 'Relationship with NETCONF'. > > > It should then say (although not in this order) > > - a restconf client may or may not also be a NETCONF client > IMO you are really confused. Why would a RESTCONF client need to implement NETCONF? The ONLY things a RESTCONF client needs to do to access RESTCONF functionality if be a RESTCONF clent. The argument "but RESTCONF can't do everything that NETCONF can do" is irrelevant because the RESTCONF protocol does not claim to do everything NETCONF can do. A RESTCONF-only server may also have CLI, which can lock the datastore, which can cause a RESTCONF edit to fail. I suppose we have to warn people about this in the draft as well. Andy > - a restconf server may or may not also be a NETCONF server > (and that is all I am intending by way of applicability) > > - restconf replaces NETCONF the protocol but does use everything else > from NETCONF, followed by an exhaustive list, which would include at > least: > state date and configuration data, multiple datastores, data > persistence (yes, I know RFC6241 is rather vague), (roll back on) error > handling, defaults, capabilities (e.g :writable-running), locks, ... > > Tom Petch > > > Andy > > > > > > On Sat, Jan 23, 2016 at 4:51 AM, t.petch wrote: > > > > > ---- Original Message ----- > > > From: "Andy Bierman" > > > Sent: Friday, January 22, 2016 4:32 PM > > > > > > > Why is it rubbish that there can be a RESTCONF-only server? > > > > I can't find any text that says NETCONF MUST be implemented > > > > if RESTCONF is implemented. > > > > > > > > Some details (like defaults handling) are aligned with NETCONF. > > > > That doesn't mean the RESTCONF client needs to know much > > > > about NETCONF datastores or locks, etc. > > > > > > Andy > > > > > > I find the I-D silent on its applicability. I see > > > " RESTCONF can be implemented on a device that supports NETCONF." > > > which I regard as close to marketing but have no problem with it > being > > > there. What I lack is any indication as to whether or not it is > > > feasible to have a restconf-only management system. restconf lacks > some > > > of NETCONF's capabilities so is it expected that the server will be > > > NETCONF as well or is the expectation that there will be > restconf-only > > > systems? > > > > > > This colours how I comment on the following text. One small example > of > > > several is in s.12 > > > > > > "Implementors SHOULD provide a comprehensive > > > authorization scheme with RESTCONF and ensure that the resulting > > > NETCONF username is made available to the RESTCONF server." > > > > > > which implies to me that the server has NETCONF capabilities, at > least > > > in part. If not, then s.12 needs rewriting, along the lines that > > > restconf imports the idea of a username (along with masses of other > > > things) from NETCONF and must conform to the specification of > usersname > > > as in section .. of RFC ..... > > > > > > So can there be a restconf-only system, clients and servers? > (dunno, > > > I-D implies not) > > > Can a server support restconf and NETCONF? yes, s1.2 tells me so > > > Can a restconf-only client do useful work with a hybrid > restconf/NETCONF > > > server? (hopefully) > > > Can a client support restconf and NETCONF and use them to work with > > > restconf-only servers and NETCONF-only servers? um, authentication > > > needs thinking about but hopefully yes > > > > > > I find the I-D incomplete without this being clearly stated. > > > > > > My comment of 'rubbish' was aimed at a different point, where the > I-D > > > says that > > > " the user should not need any prior knowledge of NETCONF in order > to > > > use RESTCONF." > > > To me it is abundantly clear that the user must understand NETCONF > in > > > depth in order to make sense of this I-D and I extrapolate that to > > > understanding NETCONF in order to make use of restconf. There may > or > > > may not be a need to have access to NETCONF client/server, which is > my > > > point above, but there has to be an understanding of the concepts of > > > NETCONF in order to make sense of restconf. You of course, along > with > > > your fellow authors, WG Chairs, WG ADs, have that in depth. I have > it > > > to some degree. Someone without such knowledge has no hope of > > > understanding or using restconf! > > > > > > Tom Petch > > > > > > > Andy > > > > > > > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch > wrote: > > > > > > > > > Having read all of restconf, I find myself with some fairly > basic > > > > > questions for which I cannot see answers. > > > > > > > > > > A) Is restconf an optional extra for a server on top of NETCONF > or > > > do > > > > > you expect there to be restconf-only servers? S.1.3 says that > they > > > can > > > > > coexists, yes, great, marketing. But can you perform useful > > > operational > > > > > tasks from a restconf-only client to a restconf-only server? I > > > started > > > > > off assuming you could, but ended up thinking the I-D was > telling me > > > > > that at least the server musy have both e.g. s.12 > > > > > "it does require that an authenticated NETCONF username be > > > associated > > > > > with each request" > > > > > which also begs the question, can there be restconf-only client? > > > > > > > > > > Needs specifying IMO, perhaps after thinking through the > > > consequences. > > > > > > > > > > B) " the user should not need any prior knowledge of NETCONF in > > > > order to > > > > > use RESTCONF" > > > > > Well, I wrote 'rubbish' alongside that and taken literally, it > is:=) > > > > > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF > the > > > > > operational infrastructure (configuration, state, datastore, > event, > > > > > error handling, persistence of data. ....) and while the former > is > > > > > replaced, in whole or in part, by restconf, the latter most > > > definitely > > > > > is not, as exemplified by the definitions imported in s.1.4.1 > > > > > > > > > > But that also in untrue. This I-D implies, mostly without being > > > > > explicit, that it refines NETCONF the operational infrastructure > > > > > (perhaps using the terms in a different way). Thus it appears > that > > > > > there is no explicit selection of NETCONF datastore but that > which > > > one > > > > > is chosen is implicit. I infer this from s.1.3 but think that > it > > > needs > > > > > separating out more clearly. > > > > > > > > > > C) configuration and state; RFC 6241 is very clear about this, > this > > > I-D > > > > > seems to be half way towards whatever resolution netmod comes to > on > > > > > netmod-opstate-reqs, which is probably not a good idea. 'state' > I > > > see > > > > > used only twice, then this undefined 'operational data' takes > over > > > and > > > > > the water is then muddied by 'config' and 'nonconfig'. This is > > > > > wandering off into its own 'restconf the operational > infrastructure' > > > > > without ever saying AFAICT how it differs from NETCONF. It is > as if > > > the > > > > > three authors each independently wrote parts of the I-D:-) > > > > > > > > > > D) Then there are datastores, at least there are until s.4.4.1, > when > > > > > datastore seems to be redefined to mean 'top level node' a term > > > which > > > > > has surfaced on the (netmod or netconf) mailing list as being > > > something > > > > > that is not defined and may mean different things to different > > > people. > > > > > I read the first half of the I-D thinking that 'datastore' is as > > > defined > > > > > in RFC6241 and then find half way through that I cannot see any > way > > > that > > > > > it is. I note the absence of any examples involving > > > > > 'application/yang.datastore' > > > > > and think, well yes, that figures! > > > > > > > > > > E) This then calls into question for me the meaning of the term > > > 'data'. > > > > > In the latter part of the I-D, it seems to be shorthand for > 'data or > > > > > datastore' with datastore having its non-NETCONF meaning but > early > > > on, > > > > > it is used alongside 'datastore' suggesting that it has a more > > > > > restricted meaning, coupled with the use of different media > types, > > > but I > > > > > cannot tell. > > > > > > > > > > So, I have some detailed comments on s.4 onwards but think that > the > > > > > 'beams' need resolving first. > > > > > > > > > > Tom Petch > > > > > > > > > > ----- Original Message ----- > > > > > From: "t.petch" > > > > > To: > > > > > Cc: > > > > > Sent: Wednesday, January 20, 2016 6:43 PM > > > > > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > > > > > draft-ietf-netconf-yang-patch-07 and > > > draft-ietf-netconf-yang-library-03 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > > > > > > --001a113fbdd486f57f052a15b3fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jan 24, 2016 at 3:00 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "t.petch" <ietfc@bt= connect.com>
Cc: "Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>;
"Netconf" <netconf@ietf.or= g>
Sent: Saturday, January 23, 2016 3:13 PM
>
> Would your concerns be we put more detail in the NETCONF Coexistence > section.
> I have already pointed out that the confirmed-commit details are
missing.
> We will make it clear which details a RESTCONF client needs to know. >
> We can add another short section for RESTCONF only considerations.
> I thought it was already clear that implementation of NETCONF was not<= br> > required, but we can make it extra clear.
>
> Applicability is another problem.=C2=A0 IMO let the market decide.
> Some companies (and WGs) are already working on solutions that provide=
a
> unified
> "YANG development environment" to deploy with whatever proto= col,
across a
> range of
> platforms from IoT to SDN. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF)=
> The boundaries of applicability are subjective and might be rapidly > changing for awhile.
> (So I don't want to write an AS for RESTCONF.)

Andy

I think that it is s1.3 that most needs changing, as I said in my first
e-mail of comments, but that its direction needs changing, to become
'Relationship with NETCONF'.


=C2=A0
It should then say (although not in this order)

- a restconf client may or may not also be a NETCONF client


IMO you are really confused.
= Why would a RESTCONF client need to implement NETCONF?

=
The ONLY things a RESTCONF client needs to do
to access REST= CONF functionality if be a RESTCONF clent.

The arg= ument "but RESTCONF can't do everything that NETCONF can do"<= /div>
is irrelevant because the RESTCONF protocol does not claim
<= div>to do everything NETCONF can do.

A RESTCONF-on= ly server may also have CLI, which can
lock the datastore, which = can cause a RESTCONF edit to fail.
I suppose we have to warn peop= le about this in the draft as well.


Andy


=C2=A0

=C2=A0
- a restconf server may or may not also be a NETCONF server
(and that is all I am intending by way of applicability)



- restconf replaces NETCONF the protocol but does use everything else
from NETCONF, followed by an exhaustive list, which would include at
least:
=C2=A0state date and configuration data, multiple datastores, data
persistence (yes, I know RFC6241 is rather vague), (roll back on) error
handling, defaults, capabilities=C2=A0 (e.g :writable-running), locks, ...<= br>
Tom Petch

> Andy
>
>
> On Sat, Jan 23, 2016 at 4:51 AM, t.petch <ietfc@btconnect.com> wrote:
>
> > ---- Original Message -----
> > From: "Andy Bierman" <andy@yumaworks.com>
> > Sent: Friday, January 22, 2016 4:32 PM
> >
> > > Why is it rubbish that there can be a RESTCONF-only server?<= br> > > > I can't find any text that says NETCONF MUST be implemen= ted
> > > if RESTCONF is implemented.
> > >
> > > Some details (like defaults handling) are aligned with NETCO= NF.
> > > That doesn't mean the RESTCONF client needs to know much=
> > > about NETCONF datastores or locks, etc.
> >
> > Andy
> >
> > I find the I-D silent on its applicability.=C2=A0 I see
> > "=C2=A0 RESTCONF can be implemented on a device that support= s NETCONF."
> > which I regard as close to marketing but have no problem with it<= br> being
> > there.=C2=A0 What I lack is any indication as to whether or not i= t is
> > feasible to have a restconf-only management system.=C2=A0 restcon= f lacks
some
> > of NETCONF's capabilities so is it expected that the server w= ill be
> > NETCONF as well or is the expectation that there will be
restconf-only
> > systems?
> >
> > This colours how I comment on the following text.=C2=A0 One small= example
of
> > several is in s.12
> >
> > "Implementors SHOULD provide a comprehensive
> >=C2=A0 =C2=A0 authorization scheme with RESTCONF and ensure that t= he resulting
> >=C2=A0 =C2=A0 NETCONF username is made available to the RESTCONF s= erver."
> >
> > which implies to me that the server has NETCONF capabilities, at<= br> least
> > in part.=C2=A0 If not, then s.12 needs rewriting, along the lines= that
> > restconf imports the idea of a username (along with masses of oth= er
> > things) from NETCONF and must conform to the specification of
usersname
> > as in section .. of RFC .....
> >
> > So can there be a restconf-only system, clients and servers?
(dunno,
> > I-D implies not)
> > Can a server support restconf and NETCONF? yes, s1.2 tells me so<= br> > > Can a restconf-only client do useful work with a hybrid
restconf/NETCONF
> > server? (hopefully)
> > Can a client support restconf and NETCONF and use them to work wi= th
> > restconf-only servers and NETCONF-only servers?=C2=A0 um, authent= ication
> > needs thinking about but hopefully yes
> >
> > I find the I-D incomplete without this being clearly stated.
> >
> > My comment of 'rubbish' was aimed at a different point, w= here the
I-D
> > says that
> > " the user should not need any prior knowledge of NETCONF in= order
to
> >=C2=A0 =C2=A0 use RESTCONF."
> > To me it is abundantly clear that the user must understand NETCON= F
in
> > depth in order to make sense of this I-D and I extrapolate that t= o
> > understanding NETCONF in order to make use of restconf.=C2=A0 The= re may
or
> > may not be a need to have access to NETCONF client/server, which = is
my
> > point above, but there has to be an understanding of the concepts= of
> > NETCONF in order to make sense of restconf.=C2=A0 You of course, = along
with
> > your fellow authors, WG Chairs, WG ADs, have that in depth.=C2=A0= I have
it
> > to some degree.=C2=A0 Someone without such knowledge has no hope = of
> > understanding or using restconf!
> >
> > Tom Petch
> >
> >=C2=A0 > Andy
> > >
> > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch <ietfc@btconnect.com>
wrote:
> > >
> > > > Having read all of restconf, I find myself with some fa= irly
basic
> > > > questions for which I cannot see answers.
> > > >
> > > > A) Is restconf an optional extra for a server on top of= NETCONF
or
> > do
> > > > you expect there to be restconf-only servers?=C2=A0 S.1= .3 says that
they
> > can
> > > > coexists, yes, great, marketing.=C2=A0 But can you perf= orm useful
> > operational
> > > > tasks from a restconf-only client to a restconf-only se= rver?=C2=A0 I
> > started
> > > > off assuming you could, but ended up thinking the I-D w= as
telling me
> > > > that at least the server musy have both e.g. s.12
> > > > "it does=C2=A0 require that an authenticated NETCO= NF username be
> > associated
> > > > with each request"
> > > > which also begs the question, can there be restconf-onl= y client?
> > > >
> > > > Needs specifying IMO, perhaps after thinking through th= e
> > consequences.
> > > >
> > > > B) " the user should not need any prior knowledge = of NETCONF in

> > order to
> > > > use RESTCONF"
> > > > Well, I wrote 'rubbish' alongside that and take= n literally, it
is:=3D)
> > > > NETCONF [RFC6241 et al] defines NETCONF the protocol an= d NETCONF
the
> > > > operational infrastructure (configuration, state, datas= tore,
event,
> > > > error handling, persistence of data. ....) and while th= e former
is
> > > > replaced, in whole or in part, by restconf, the latter = most
> > definitely
> > > > is not, as exemplified by the definitions imported in s= .1.4.1
> > > >
> > > > But that also in untrue.=C2=A0 This I-D implies, mostly= without being
> > > > explicit, that it refines NETCONF the operational infra= structure
> > > > (perhaps using the terms in a different way).=C2=A0 Thu= s it appears
that
> > > > there is no explicit selection of NETCONF datastore but= that
which
> > one
> > > > is chosen is implicit.=C2=A0 I infer this from s.1.3 bu= t think that
it
> > needs
> > > > separating out more clearly.
> > > >
> > > > C) configuration and state; RFC 6241 is very clear abou= t this,
this
> > I-D
> > > > seems to be half way towards whatever resolution netmod= comes to
on
> > > > netmod-opstate-reqs, which is probably not a good idea.= =C2=A0 'state'
I
> > see
> > > > used only twice, then this undefined 'operational d= ata' takes
over
> > and
> > > > the water is then muddied by 'config' and '= nonconfig'.=C2=A0 This is
> > > > wandering off into its own 'restconf the operationa= l
infrastructure'
> > > > without ever saying AFAICT how it differs from NETCONF.= =C2=A0 It is
as if
> > the
> > > > three authors each independently wrote parts of the I-D= :-)
> > > >
> > > > D) Then there are datastores, at least there are until = s.4.4.1,
when
> > > > datastore seems to be redefined to mean 'top level = node' a term
> > which
> > > > has surfaced on the (netmod or netconf) mailing list as= being
> > something
> > > > that is not defined and may mean different things to di= fferent
> > people.
> > > > I read the first half of the I-D thinking that 'dat= astore' is as
> > defined
> > > > in RFC6241 and then find half way through that I cannot= see any
way
> > that
> > > > it is.=C2=A0 I note the absence of any examples involvi= ng
> > > > 'application/yang.datastore'
> > > > and think, well yes, that figures!
> > > >
> > > > E) This then calls into question for me the meaning of = the term
> > 'data'.
> > > > In the latter part of the I-D, it seems to be shorthand= for
'data or
> > > > datastore' with datastore having its non-NETCONF me= aning but
early
> > on,
> > > > it is used alongside 'datastore' suggesting tha= t it has a more
> > > > restricted meaning, coupled with the use of different m= edia
types,
> > but I
> > > > cannot tell.
> > > >
> > > > So, I have some detailed comments on s.4 onwards but th= ink that
the
> > > > 'beams' need resolving first.
> > > >
> > > > Tom Petch
> > > >
> > > > ----- Original Message -----
> > > > From: "t.petch" <ietfc@btconnect.com>
> > > > To: <mehme= t.ersue@nokia.com>
> > > > Cc: <netconf@iet= f.org>
> > > > Sent: Wednesday, January 20, 2016 6:43 PM
> > > > Subject: Re: WG Last Call for draft-ietf-netconf-restco= nf-09,
> > > > draft-ietf-netconf-yang-patch-07 and
> > draft-ietf-netconf-yang-library-03
> > > >
> > > > <snip>
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listin= fo/netconf
> > > >
> > >
> >
> >
>


--001a113fbdd486f57f052a15b3fc-- From nobody Sun Jan 24 13:14:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970CE1B32DD for ; Sun, 24 Jan 2016 13:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F84XJFzW4ieC for ; Sun, 24 Jan 2016 13:14:33 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60C21B32FD for ; Sun, 24 Jan 2016 13:14:32 -0800 (PST) Received: from muvmp319.nsn-intra.net ([10.159.32.166]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u0OLEUUW024711 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 24 Jan 2016 21:14:30 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by muvmp319.nsn-intra.net (8.14.3/8.14.3) with ESMTP id u0OLEUTK031956 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 24 Jan 2016 21:14:30 GMT Received: from DEMUMBX005.nsn-intra.net ([169.254.5.234]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0248.002; Sun, 24 Jan 2016 22:14:30 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: NETCONF Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Thread-Index: AdFW3hA0GkYxdS45Tz++0DXRdqG8cQ== Date: Sun, 24 Jan 2016 21:14:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.118] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819899EEBDEMUMBX005nsnin_" MIME-Version: 1.0 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: 42230 X-purgate-ID: 151667::1453670070-00000F3E-351B757D/0/0 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 21:14:48 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819899EEBDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, Thank You all indeed for the thorough reviews. We've got many valuable comm= ents. I believe the RESTCONF drafts are on the right track and it'll be good to g= o to AD review after a careful update. Below are a few points for draft-ietf-netconf-restconf-09 to emphasize some= of the comments on the maillist and a few minor things to increase the cla= rity. It is fine if the authors find a better formulation than I propose. - Section 1.1: "Edits are usually applied to one data resource instance at a time." The word "usually" does not make it clear when this is the case. - "The base RESTCONF protocol is intentionally simple to allow deployment f= or as many use cases as possible." I agree with one of the reviewers that "as many use cases as" is not suffic= iently clear. - Section 1.1: "simplified interface that follows REST principles" In the abstract and NETCONF charter text we explicitly avoided to state tha= t RESTCONF would be REST-based. If we say it "follows REST principles" we need to be very clear which prin= ciples are followed and which ones are not. - Section 1.4.3: I agree with one of the reviewers that the differentiation between RPC oper= ation vs. protocol operation and the usage of these terms through the docum= ent is unclear. - Section 1.4.4: The abbreviation HATEOAS needs to be defined. We need a reference to HTML5 (I think somebody stated this already). - Section 2.4: "The RESTCONF client MUST check the identity" s/check/verify/ s/including processing the outcome as described in/ including processing the outcome of the identifier matching procedure as de= scribed in/ I think for readability we need to give at least a minimal hint for the typ= e of the outcome. - Section 2.5: s/MUST either use TLS client certificates, like in NETCONF over TLS/ MUST either use TLS client certificates, as described in NETCONF over TLS/ s/scheme is also allowed, with the determination of how to process this com= bination left as an implementation decision./ scheme is also allowed. The determination of how to process this combinatio= n is seen as an implementation decision./ - Section 3.1: s/In line with the best practices defined by [RFC7320],/ In line with the best practices for URI design defined in [RFC7320],/ s/the client MUST prepend it to any subsequent request/ the client MUST prefix it to any subsequent request/ I think this increases the readability for many non-native speakers. Section 3.4.1.2: s/the "ETag" ([RFC7232], = Section 2.3) header is re= turned/ the "ETag" header([RFC7232], Section 2.3) is retur= ned/ I think "ETag" header is one term. Section 3.5.1: s/double-quote is not a reserved characters/ double-quote is not a reserved character/ Section 3.5.2: Suggest to rename the section title as: "3.5.2. Defaults Handling Mode" s/default handling mode/ defaults handling mode/ Section 3.6: s/if "module-A" defined a "reset-all" action/ if "module-A" defines a "reset-all" action/ Section 4: s/Implementation of all methods (except PATCH) are defined in [RFC7231]./ HTTP methods and their semantics are defined in [RFC7231] except HTTP PATCH method is defined in [RFC5789]./ - In Section 4.3: I agree with one of the reviewers that concerning "403 Forbidden" or "404 N= ot Found", GET should define which error response exactly should be used wh= en. Section 4.6: s/Each patch type needs a unique media type./ Each patch type needs to use a unique media type./ Section 4.6.1: s/Plain patch can used to/ Plain patch can be used to/ Section 4.8.9: s/it MUST implement the behavior in Section 4.5.1 of [RFC6243]/ it MUST implement the behavior defined in Section 4.5.1 of [RFC6243]/ Section 5.3: The sentence "This encoding is valid JSON, but also has special encoding ru= les to identify module namespaces and provide consistent type processing of= YANG data." is unclear. Does "This encoding" refer to the JSON encoding defined in [I-D.ietf-netmod= -yang-metadata]? Why it is important to highlight that it is valid JSON? I suggest to write "The JSON encoding defined in [I-D.ietf-netmod-yang-meta= data] has special encoding rules to identify module name= spaces . . . " Section 12: s/Implementors/Implementers/ s/an authenticated NETCONF username be associated with/ an authenticated NETCONF username ([RFC 7589]) be associated with/ Section 13: s/the The/The/ Mehmet From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of EXT Mahesh Jethanand= ani Sent: Sunday, January 24, 2016 2:26 AM To: NETCONF Cc: i2rs@ietf.org; 6tisch@ietf.org; core@ietf.org; netmod@ietf.org; 6lo@iet= f.org Subject: Re: [i2rs] WG Last Call for draft-ietf-netconf-restconf-09, draft-= ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 The Last Call period for the above three drafts closed yesterday. Thanks to= everyone who provided comments on the three drafts. The authors will update the documents based on the comments received and po= st an updated version of the draft(s). Mahesh & Mehmet. On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - DE/Munich) > wrote: FYI and attention. Please provide your comments to NETCONF WG maillist. Mehmet From: Ersue, Mehmet (Nokia - DE/Munich) Sent: Tuesday, December 15, 2015 9:59 PM To: netconf@ietf.org Cc: 'core@ietf.org' >; 'i2rs@ietf.org' >; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org> Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netcon= f-yang-patch-07 and draft-ietf-netconf-yang-library-03 Dear NETCONF WG, we hereby issue a WG Last Call for the drafts below: http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt Please review and send your comments to the NETCONF WG mailing list by Janu= ary 22, 2015 EOB PT. The drafts on RESTCONF, YANG patch and YANG library are planned to publish = as standard track documents. As RESTCONF is a major protocol we seek a detailed and thorough review with= in NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned to finalize on January 22th (covering the hol= iday time in between) and APP, INT and RTG area ADs will be informed as wel= l as Core, I2RS, 6lo, and 6tisch WGs are invited to review. Please take your time to review the documents and send your comments to the= NETCONF maillist by the deadline. Please state on NETCONF maillist also explicitly, whether you have read/rev= iewed and whether you support the publication. Furthermore please indicate if you plan to implement or have already implem= entations for RESTCONF and its supplementary drafts. Thank you for your review and kind help getting RESTCONF specifications sta= ble. Best Regards, Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F819899EEBDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Thank You all indeed for the thorough= reviews. We’ve got many valuable comments.

I believe the RESTCONF drafts are on = the right track and it’ll be good to go to AD review after a careful = update.

 

Below are a few points for draft-ietf= -netconf-restconf-09 to emphasize some of the comments on the maillist and = a few minor things to increase the clarity.

It is fine if the authors find a bett= er formulation than I propose.

 

- Section 1.1:

“Edits are usually applied to o= ne data resource instance at a time.”

The word “usually” does n= ot make it clear when this is the case.

 

- “The base RESTCONF protocol i= s intentionally simple to allow deployment for as many use cases as possibl= e.”

I agree with one of the reviewers tha= t “as many use cases as” is not sufficiently clear.<= /span>

 

- Section 1.1:

“simplified interface that foll= ows REST principles“

In the abstract and NETCONF charter t= ext we explicitly avoided to state that RESTCONF would be REST-based.<= /o:p>

If we say it “follows REST prin= ciples”  we need to be very clear which principles are followed = and which ones are not.

 

- Section 1.4.3:

I agree with one of the reviewers tha= t the differentiation between RPC operation vs. protocol operation and the = usage of these terms through the document is unclear.

 

- Section 1.4.4:

The abbreviation HATEOAS needs to be = defined.

We need a reference to HTML5 (I think= somebody stated this already).

 

- Section 2.4:

“The RESTCONF client MUST check= the identity”

s/check/verify/

s/including processing the outcome as= described in/

including processing the outcome of t= he identifier matching procedure as described in/

I think for readability we need to gi= ve at least a minimal hint for the type of the outcome.

 

- Section 2.5:

s/MUST either use TLS client certific= ates, like in NETCONF over TLS/

MUST either use TLS client certificat= es, as described in NETCONF over TLS/

 

s/scheme is also allowed, with the de= termination of how to process this combination

left as an implementation decision./<= o:p>

scheme is also allowed. The determina= tion of how to process this combination

is seen as an implementation decision= ./

 

- Section 3.1:

s/In line with the best practices def= ined by [RFC7320],/

In line with the best practices for U= RI design defined in [RFC7320],/<= /p>

 

s/the client MUST prepend it to any s= ubsequent request/

the client MUST prefix it to any subs= equent request/

I think this increases the readabilit= y for many non-native speakers.

 

Section 3.4.1.2:

s/the "ETag" ([RFC7232],   Section = 2.3) header is returned/

the "ETag" header([RFC7232],   Section=  2.3) is returned/

I think "ETag" header is on= e term.

 

Section 3.5.1:

s/double-quote is not a reserved char= acters/

double-quote is not a reserved charac= ter/

 

Section 3.5.2:

Suggest to rename the section title a= s: “3.5.2.  Defaults Handling Mode”

 

s/default handling mode/

defaults handling mode/

 

Section 3.6:

s/if "module-A" defined a &= quot;reset-all" action/

if "module-A" defines a &qu= ot;reset-all" action/

 

Section 4:

s/Implementation of all methods (exce= pt PATCH) are defined in [RFC7231]./

HTTP methods and their semantics are = defined in [RFC723= 1] except HTTP PATCH method is defined in [RFC5789]./

 

- In Section 4.3:

I agree with one of the reviewers tha= t concerning "403 Forbidden" or "404 Not Found", GET sh= ould define which error response exactly should be used when.

 

Section 4.6:

s/Each patch type needs a unique medi= a type./

Each patch type needs to use a unique= media type./

 

Section 4.6.1:

s/Plain patch can used to/=

Plain patch can be used to/

 

Section 4.8.9:

s/it MUST implement the behavior in Section = 4.5.1 of [RFC6243]/

it MUST implement the behavior define= d in Section = 4.5.1 of [RFC6243]/

 

Section 5.3:

The sentence “This encoding is = valid JSON, but also has special encoding rules to identify module namespac= es and provide consistent type processing of YANG data.” is unclear.

Does “This encoding” refe= r to the JSON encoding defined in [I-D.ietf-n= etmod-yang-metadata]?

Why it is important to highlight that= it is valid JSON?

I suggest to write ”The JSON en= coding defined in [I-D.ietf-netmod-yang-metad= ata] has special encoding rules to identify module namespaces . . . “

 

Section 12:

s/Implementors/Implementers/

 

s/an authenticated NETCONF username b= e associated with/

an authenticated NETCONF username ([R= FC 7589]) be associated with/

 

Section 13:

s/the The/The/

 

Mehmet

 

From: i2rs [mailto:i2rs-bounces@ietf= .org] On Behalf Of EXT Mahesh Jethanandani
Sent: Sunday, January 24, 2016 2:26 AM
To: NETCONF <netconf@ietf.org>
Cc: i2rs@ietf.org; 6tisch@ietf.org; core@ietf.org; netmod@ietf.org; = 6lo@ietf.org
Subject: Re: [i2rs] WG Last Call for draft-ietf-netconf-restconf-09,= draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

 

The Last Call period for the above three drafts clos= ed yesterday. Thanks to everyone who provided comments on the three drafts.=

 

The authors will update the documents based on the c= omments received and post an updated version of the draft(s).

 

Mahesh & Mehmet.

 

On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - = DE/Munich) <mehmet.ersue@nokia= .com> wrote:

 

FYI and attention.<= /p>

 

Please provide your comments to NETCO= NF WG maillist.

 

Mehmet<= /p>

 

From: Ersue, Mehmet (Nokia - DE/Munich) 
Sent: Tuesday, Dec= ember 15, 2015 9:59 PM
To: netconf@ietf.org<= /a>
Cc: 'core@ietf.org' = <core@ietf= .org>; 'i2rs@ietf.org' <i2rs@iet= f.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch= @ietf.org>
Subject: WG Last C= all for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 an= d draft-ietf-netconf-yang-library-03

 

Dear NETCONF WG,

 

we hereby issue a WG Last Call for th= e drafts below:

 

 

Please review and send your comments = to the NETCONF WG mailing list by January 22, 2015 EOB PT.

 

The drafts on RESTCONF, YANG patch an= d YANG library are planned to publish as standard track documents.

 

As RESTCONF is a major protocol we se= ek a detailed and thorough review within NETCONF WG but also by the related= WGs before publishing.

Therefore the WGLC is planned to fina= lize on January 22th (covering the holiday time in between) and APP, INT an= d RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

 

Please take your time to review the d= ocuments and send your comments to the NETCONF maillist by the deadline.

Please state on NETCONF maillist also= explicitly, whether you have read/reviewed and whether you support the pub= lication.

Furthermore please indicate if you pl= an to implement or have already implementations for RESTCONF and its supplementary drafts.

 

Thank you for your review and kind he= lp getting RESTCONF specifications stable.

 

Best Regards,

Mehmet and Mahesh

 

 

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819899EEBDEMUMBX005nsnin_-- From nobody Sun Jan 24 23:34:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3D1AD1EC for ; Sun, 24 Jan 2016 23:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dZtl6sl4-mM for ; Sun, 24 Jan 2016 23:34:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F49D1AD1C3 for ; Sun, 24 Jan 2016 23:34:35 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 373671AE02AB; Mon, 25 Jan 2016 08:34:33 +0100 (CET) Date: Mon, 25 Jan 2016 08:34:35 +0100 (CET) Message-Id: <20160125.083435.2011604469768165937.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20160124103920.GA34787@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 07:34:37 -0000 Andy Bierman wrote: > On Sun, Jan 24, 2016 at 2:39 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Andy, > > > > can you provide a pointer to backup your claim? > > > > > > I was wrong. > We discussed adding the module-set-id leaf to the netconf-capability-change > event. > But there is no augment-stmt in the YANG module for this detail. Looks > like when we decided > to claim there is no relationship between ietf-netconf-monitoring and > RESTCONF, > that this got dropped or taken out. > > So I don't care if a notification is added. I think shuch a notification makes sense, in order to make yang-library complete and self-contained, even though it means duplicate notifications for NETCONF. I believe this is the last issue for yang library, so it would be very useful to hear people's opinion before we publish an updated draft. /martin > > > > > Thanks, > > > > /js > > > > Andy > > > > > > On Fri, Jan 22, 2016 at 04:13:39AM -0800, Andy Bierman wrote: > > > Hi, > > > > > > The WG discussed this issue at length and decided not > > > to send 2 notifications for the same thing. That is why the > > > existing event is being used. I don't think anything changed > > > since this decision was made. > > > > > > > > > Andy > > > > > > > > > On Fri, Jan 22, 2016 at 12:38 AM, Martin Bjorklund > > wrote: > > > > > > > Randy Presuhn wrote: > > > > > Hi - > > > > > > > > > > >From: Martin Bjorklund > > > > > >Sent: Jan 21, 2016 1:53 PM > > > > > >To: randy_presuhn@mindspring.com > > > > > >Cc: netconf@ietf.org > > > > > >Subject: Re: [Netconf] RP comments on > > draft-ietf-netconf-yang-library-03 > > > > > > > > > > > >Hi, > > > > > > > > > > > >Randy Presuhn wrote: > > > > > >> Hi - > > > > > >> > > > > > >> >From: Martin Bjorklund > > > > > >> >Sent: Jan 21, 2016 3:15 AM > > > > > >> >To: randy_presuhn@mindspring.com > > > > > >> >Cc: netconf@ietf.org > > > > > >> >Subject: Re: [Netconf] RP comments on > > > > draft-ietf-netconf-yang-library-03 > > > > > >> > > > > > > >> >Randy Presuhn wrote: > > > > > >> >> Hi - > > > > > >> >> > > > > > >> >> >From: Martin Bjorklund > > > > > >> >> >Sent: Jan 20, 2016 7:00 AM > > > > > >> >> >To: randy_presuhn@mindspring.com > > > > > >> >> >Cc: netconf@ietf.org > > > > > >> >> >Subject: Re: [Netconf] RP comments on > > > > draft-ietf-netconf-yang-library-03 > > > > > >> >> > > > > > > >> >> >Hi Randy, > > > > > >> >> > > > > > > >> >> >Thank you for your review! Comments inline. > > > > > >> >> > > > > > > >> >> >Randy Presuhn wrote: > > > > > > > > > > > >[...] > > > > > > > > > > > >> >> >> 2.1.1 module-set-id > > > > > > > > [...] > > > > > > > > > >> Getting a bit beyond the scope of this draft, this leaf presumes > > > > > >> a polling-based monitoring strategy. Forgive me for thinking > > > > > >> like an SNMP guy, but wouldn't it scale much better for the > > > > > >> system to be able to generate a notification whenever this > > > > > >> piece of information changes? > > > > > > > > > > > >For YANG 1.1, the module-set-id is actually presented in the > > > > > >capability in the message. > > > > > > > > > > > >Since the module-set-id is part of a capability, the server will > > > > > >generate a netconf-capability-change notification (defined in RFC > > > > > >6470) if the module set changes. > > > > > > > > > > This is helpful, but now I'm going to ask a particularly > > > > > ignorant question: does this explanation necessarily hold true > > > > > for all protocols used to shovel around information defined > > > > > using YANG models? > > > > > > > > No. I guess we could specify a notification "yang-library-change": > > > > > > > > notification yang-library-change { > > > > description > > > > "Generated when the set of modules and submodules supported > > > > by the server has changed."; > > > > leaf module-set-id { > > > > type leafref { > > > > path "/yanglib:module/yanglib:module-set-id"; > > > > } > > > > mandatory true; > > > > description > > > > "Contains the module-set-id value representing the > > > > set of modules and submodules supported at the server at the > > > > time the notification is generated."; > > > > } > > > > } > > > > > > > > but it is not obvious to me that such a notification would be the > > > > correct solution. If a new protocol gets defined that supports some > > > > kind of capability discovery, shouldn't that protocol define how > > > > capability changes are communicated in that particular protocol? > > > > > > > > > That is, do all protocols based on YANG > > > > > *necessarily* have a "" message and netconf-capability-change > > > > > notifications? It could be a mistake to treat quirks of the current > > > > > implementation environments for this model as though they would > > > > > hold true all future environments in which this model might be > > > > > employed. On the other hand, if this model is only intended to > > > > > be used in netconf protocol environments, case closed. :-) > > > > > > > > One of the main ideas with this module is to have a generic mechanism > > > > to discovery YANG modules regardless of protocol. Hmm, this statement > > > > clearly speaks for a generic notification... > > > > > > > > > > > > /martin > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > From nobody Mon Jan 25 00:47:02 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A851B2A0F for ; Mon, 25 Jan 2016 00:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjYe5NB7CwSZ for ; Mon, 25 Jan 2016 00:46:59 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E9E1B2A12 for ; Mon, 25 Jan 2016 00:46:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C9302781; Mon, 25 Jan 2016 09:46:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GDYPGj0sBeJk; Mon, 25 Jan 2016 09:46:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Jan 2016 09:46:56 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF58320013; Mon, 25 Jan 2016 09:46:55 +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 Aqo4ZbpDtU36; Mon, 25 Jan 2016 09:46: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 11CFD2002C; Mon, 25 Jan 2016 09:46:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2C04B39ADCF8; Mon, 25 Jan 2016 09:46:50 +0100 (CET) Date: Mon, 25 Jan 2016 09:46:50 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160125084650.GA36874@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, randy_presuhn@mindspring.com, netconf@ietf.org References: <20160124103920.GA34787@elstar.local> <20160125.083435.2011604469768165937.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160125.083435.2011604469768165937.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:47:01 -0000 On Mon, Jan 25, 2016 at 08:34:35AM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Sun, Jan 24, 2016 at 2:39 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > Andy, > > > > > > can you provide a pointer to backup your claim? > > > > > > > > > > I was wrong. > > We discussed adding the module-set-id leaf to the netconf-capability-change > > event. > > But there is no augment-stmt in the YANG module for this detail. Looks > > like when we decided > > to claim there is no relationship between ietf-netconf-monitoring and > > RESTCONF, > > that this got dropped or taken out. > > > > So I don't care if a notification is added. > > I think shuch a notification makes sense, in order to make > yang-library complete and self-contained, even though it means > duplicate notifications for NETCONF. I believe this is the last issue > for yang library, so it would be very useful to hear people's opinion > before we publish an updated draft. > Some observations: - If the change of the module set should be considered a capability change by implementors, then I think we should spell this out somewhere so that implementors who also implement ietf-netconf-notifications.yang get this right. - Given that module set changes are assumed to be infrequent, I think it is OK to have a more specific notification defined that makes the yang-library module self-contained. - I would not be surprised to see applications that check the module-set-id upon 'session' start and then they will silently assume that module-set-id does not change for the duration of the 'session' (and they won't sign up for notifications). (I put session in quotes here since RESTCONF does not have a strict notion of a session.) Does it make sense to give guidance here? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 25 01:17:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02D41B2A57 for ; Mon, 25 Jan 2016 01:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-W6EFr0vIgh for ; Mon, 25 Jan 2016 01:17:29 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121611B2A56 for ; Mon, 25 Jan 2016 01:17:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D5B1E8D7; Mon, 25 Jan 2016 10:17:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id L1yjHAq1owBD; Mon, 25 Jan 2016 10:17:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Jan 2016 10:17:26 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE5F820013; Mon, 25 Jan 2016 10:17: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 VlB2PEzn6v1E; Mon, 25 Jan 2016 10:17:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 306CB2002B; Mon, 25 Jan 2016 10:17:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 73E5639ADE08; Mon, 25 Jan 2016 10:17:24 +0100 (CET) Date: Mon, 25 Jan 2016 10:17:24 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160125091724.GA37049@elstar.local> Mail-Followup-To: Andy Bierman , "Uveges, Balint (Nokia - HU/Budapest)" , "netconf@ietf.org" References: <28B876C36C5AA84CBAB912BA734FAC35016F21EA@DEMUMBX006.nsn-intra.net> <20160124104344.GA34881@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-restconf-09 review comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 09:17:31 -0000 On Sun, Jan 24, 2016 at 06:55:00AM -0800, Andy Bierman wrote: > On Sun, Jan 24, 2016 at 2:43 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Fri, Jan 22, 2016 at 09:43:05AM -0800, Andy Bierman wrote: > > > > > > > 2. POST (Create Resource Mode) vs. XML > > > > Chapter 4.4.1 says: > > > > If the target resource type is a datastore or data resource, then > > the > > > > POST is treated as a request to create a top-level resource or child > > > > resource, respectively. The message-body is expected to contain the > > > > content of a child resource to create within the parent (target > > > > resource). > > > > > > > > If my understanding is correct, that means (taking the example-jukebox > > > > module as an example), if I apply a POST on the artist resource to > > create > > > > two new albums, I would have something like this in case of XML > > encoding, > > > > because it only contains the content of the child resources: > > > > POST /restconf/data/example-jukebox:jukebox/ > > > > library/artist=Foo%20Fighters HTTP/1.1 > > > > Host: example.com > > > > Content-Type: application/yang.data+xml > > > > > > > > > > > > Wasting Light > > > > > > > > g:alternative > > > > > > > > 2011 > > > > > > > > > > > > Sonic Highways > > > > > > > > g:alternative > > > > > > > > 2014 > > > > > > > > > > > > But that would result in an XML that is not well formed, since it does > > not > > > > have one root parameter. My assumption is, that if I create a new > > resource, > > > > I should also include the parent resource's, like: > > > > > > > > > > > > Wasting Light > > > > ...etc, etc... > > > > > > > > > > > > Could you verify which approach is correct? Would it make sense to > > reflect > > > > that in the document? > > > > > > > > > > > You have to use YANG Patch to modify multiple subtrees at once. > > > HTTP/REST allows 1 resource to be altered or retrieved at a time. > > > > Is the resource not /restconf/data/example-jukebox:jukebox/ in this > > case? > > > > > You can patch the jukebox with multiple 'create' edits. > What is your concern? > My main concern is fair answers to reasonable questions that people ask. If the restriction here is an XML one, then this may need to be spelled out (plus any guidelines how to deal with this) so that people do not have to ask this question. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 25 07:34:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDC11B2C34 for ; Mon, 25 Jan 2016 07:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrKtZKNa5d_W for ; Mon, 25 Jan 2016 07:34:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 13A341B2C31 for ; Mon, 25 Jan 2016 07:34:56 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id E93021AE02AB; Mon, 25 Jan 2016 16:34:53 +0100 (CET) Date: Mon, 25 Jan 2016 16:34:56 +0100 (CET) Message-Id: <20160125.163456.1269436826896028399.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160125084650.GA36874@elstar.local> References: <20160125.083435.2011604469768165937.mbj@tail-f.com> <20160125084650.GA36874@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 15:34:57 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 25, 2016 at 08:34:35AM +0100, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > On Sun, Jan 24, 2016 at 2:39 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > Andy, > > > > > > > > can you provide a pointer to backup your claim? > > > > > > > > > > > > > > I was wrong. > > > We discussed adding the module-set-id leaf to the netconf-capability-change > > > event. > > > But there is no augment-stmt in the YANG module for this detail. Looks > > > like when we decided > > > to claim there is no relationship between ietf-netconf-monitoring and > > > RESTCONF, > > > that this got dropped or taken out. > > > > > > So I don't care if a notification is added. > > > > I think shuch a notification makes sense, in order to make > > yang-library complete and self-contained, even though it means > > duplicate notifications for NETCONF. I believe this is the last issue > > for yang library, so it would be very useful to hear people's opinion > > before we publish an updated draft. > > > > Some observations: > > - If the change of the module set should be considered a capability > change by implementors, then I think we should spell this out > somewhere so that implementors who also implement > ietf-netconf-notifications.yang get this right. Something like this: Note that for a NETCONF server that implements YANG 1.1 [I-D.ietf-netmod-rfc6020bis], a change of the "module-set-id" value results in a new value for the :yang-library capability defined in [I-D.ietf-netmod-rfc6020bis]. Thus, if such a server implements NETCONF notifications [RFC5277], and the notification "netconf-capability-change" [RFC6470], a "netconf-capability-change" notification MUST be generated whenever the "module-set-id" changes. or should it be s/MUST be/is/ ? Suggestions for shorter / simpler text are welcome! > - Given that module set changes are assumed to be infrequent, I think > it is OK to have a more specific notification defined that makes the > yang-library module self-contained. Ok. > - I would not be surprised to see applications that check the > module-set-id upon 'session' start and then they will silently > assume that module-set-id does not change for the duration of the > 'session' (and they won't sign up for notifications). (I put > session in quotes here since RESTCONF does not have a strict notion > of a session.) Does it make sense to give guidance here? Do you have any suggestions for specific text? /martin From nobody Mon Jan 25 07:52:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF9D1B2C73 for ; Mon, 25 Jan 2016 07:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krt95z4w1gi2 for ; Mon, 25 Jan 2016 07:52:47 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493731B2C72 for ; Mon, 25 Jan 2016 07:52:47 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 689A673C; Mon, 25 Jan 2016 16:52:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 19Jo3m-nl6hq; Mon, 25 Jan 2016 16:52:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Jan 2016 16:52:44 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 617272003B; Mon, 25 Jan 2016 16:52: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 hyJdDdVcakKH; Mon, 25 Jan 2016 16:52: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 6EFFF2003C; Mon, 25 Jan 2016 16:52:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BBC2139AED60; Mon, 25 Jan 2016 16:52:34 +0100 (CET) Date: Mon, 25 Jan 2016 16:52:32 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160125155230.GA39647@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, randy_presuhn@mindspring.com, netconf@ietf.org References: <20160125.083435.2011604469768165937.mbj@tail-f.com> <20160125084650.GA36874@elstar.local> <20160125.163456.1269436826896028399.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160125.163456.1269436826896028399.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 15:52:50 -0000 On Mon, Jan 25, 2016 at 04:34:56PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jan 25, 2016 at 08:34:35AM +0100, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > On Sun, Jan 24, 2016 at 2:39 AM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > Andy, > > > > > > > > > > can you provide a pointer to backup your claim? > > > > > > > > > > > > > > > > > > I was wrong. > > > > We discussed adding the module-set-id leaf to the netconf-capability-change > > > > event. > > > > But there is no augment-stmt in the YANG module for this detail. Looks > > > > like when we decided > > > > to claim there is no relationship between ietf-netconf-monitoring and > > > > RESTCONF, > > > > that this got dropped or taken out. > > > > > > > > So I don't care if a notification is added. > > > > > > I think shuch a notification makes sense, in order to make > > > yang-library complete and self-contained, even though it means > > > duplicate notifications for NETCONF. I believe this is the last issue > > > for yang library, so it would be very useful to hear people's opinion > > > before we publish an updated draft. > > > > > > > Some observations: > > > > - If the change of the module set should be considered a capability > > change by implementors, then I think we should spell this out > > somewhere so that implementors who also implement > > ietf-netconf-notifications.yang get this right. > > Something like this: > > Note that for a NETCONF server that implements YANG 1.1 > [I-D.ietf-netmod-rfc6020bis], a change of the "module-set-id" value > results in a new value for the :yang-library capability defined in > [I-D.ietf-netmod-rfc6020bis]. Thus, if such a server implements > NETCONF notifications [RFC5277], and the notification > "netconf-capability-change" [RFC6470], a "netconf-capability-change" > notification MUST be generated whenever the "module-set-id" changes. > > or should it be s/MUST be/is/ ? > > Suggestions for shorter / simpler text are welcome! Looks good to me. I think this helps to explain things. > > - I would not be surprised to see applications that check the > > module-set-id upon 'session' start and then they will silently > > assume that module-set-id does not change for the duration of the > > 'session' (and they won't sign up for notifications). (I put > > session in quotes here since RESTCONF does not have a strict notion > > of a session.) Does it make sense to give guidance here? > > Do you have any suggestions for specific text? I fear this might carry us away from this I-D and gets us into new feature discussion space. But since you ask... I could envision certain 'session' properties where I can ask the server to end the 'session' if assumptions my code makes about certain session properties are not true anymore. But yes, something like this sounds like an item for a wishlist. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 25 13:39:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A711A19F8 for ; Mon, 25 Jan 2016 13:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc_zG8ksi_k8 for ; Mon, 25 Jan 2016 13:39:06 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71B1A19FA for ; Mon, 25 Jan 2016 13:39:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IElpbikvjV9NBb8eUW9IhwQQx3JiyaWTwodWe9gPiOELN80za5kQHiU5hClymae2; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aNoqg-0001Gw-Rf for netconf@ietf.org; Mon, 25 Jan 2016 16:38:58 -0500 Received: from 76.254.55.245 by webmail.earthlink.net with HTTP; Mon, 25 Jan 2016 16:38:58 -0500 Message-ID: <1227977.1453757938767.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Mon, 25 Jan 2016 13:38:58 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc872b0aa5538acebdd81edbd4cc216293350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 21:39:08 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 25, 2016 7:34 AM >To: j.schoenwaelder@jacobs-university.de >Cc: andy@yumaworks.com, randy_presuhn@mindspring.com, netconf@ietf.org >Subject: Re: [Netconf] RP comments on draft-ietf-netconf-yang-library-03 ... >Something like this: > > Note that for a NETCONF server that implements YANG 1.1 > [I-D.ietf-netmod-rfc6020bis], a change of the "module-set-id" value > results in a new value for the :yang-library capability defined in > [I-D.ietf-netmod-rfc6020bis]. Thus, if such a server implements > NETCONF notifications [RFC5277], and the notification > "netconf-capability-change" [RFC6470], a "netconf-capability-change" > notification MUST be generated whenever the "module-set-id" changes. > >or should it be s/MUST be/is/ ? I prefer "is" or "would be". Randy From nobody Tue Jan 26 06:20:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688961ABB1A for ; Tue, 26 Jan 2016 06:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6kWgW6tJNwr for ; Tue, 26 Jan 2016 06:20:31 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB521A9250 for ; Tue, 26 Jan 2016 06:20:31 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2B2881CC0144; Tue, 26 Jan 2016 15:20:30 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton , "netconf\@ietf.org" In-Reply-To: <569E13E2.9020802@cisco.com> References: <569E13E2.9020802@cisco.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 26 Jan 2016 15:20:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 14:20:33 -0000 Hi Rob, Robert Wilton writes: > Hi, > > I had a few questions regarding draft-ietf-netconf-restconf-09: > > 1. Is the expectation that RESTCONF only supports HTTP 1.1, and using > HTTP/2 isn't supported? Would it help if the document explicitly > indicated which versions of HTTP are allowed? The use of HTTP/2 streams is an interesting topic, but I think it is up to a client implementation to make sure the messages are delivered in a correct order. Apart from message ordering issues, do you see other differences between HTTP 1.1 and 2 that might affect RESTCONF? > > 2. Is HTTP 1.1 pipelining allowed/supported? If it is supported then > does there need to be any statement made about when the requests are > serviced and how they are ordered relative to each other? I don't think such a statement is needed. Pipelining would have to be started by the client, but there seems to be no reason to do so because RESTCONF data are not like normal web pages with a hundred or so separate objects to fetch. > > 3. Even if HTTP pipelining isn't supported then does there need to be > any statement made about the relative orderings and what can be seen in > the datastore when processing a combination of edit operations > (PUT/PATCH/POST/DELETE) and GET requests by a single client? I.e. from > a client's perspective is it fair to assume that a GET request will see > all updates to the running configuration datastore from all previous > edit operations? I would say so. Lada > > Thanks, > Rob > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 26 07:05:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3341B2AB8 for ; Tue, 26 Jan 2016 07:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK3CI9vc0CLy for ; Tue, 26 Jan 2016 07:05:11 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E837D1ACDB2 for ; Tue, 26 Jan 2016 07:05:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C6C3C8C1; Tue, 26 Jan 2016 16:05:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id a2qyA1ESPK3G; Tue, 26 Jan 2016 16:05:08 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Jan 2016 16:05:08 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A63920033; Tue, 26 Jan 2016 16:05:08 +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 HnTpwrz_dU1D; Tue, 26 Jan 2016 16:05:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBF632002C; Tue, 26 Jan 2016 16:05:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2E97639C22F5; Tue, 26 Jan 2016 16:05:05 +0100 (CET) Date: Tue, 26 Jan 2016 16:05:04 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160126150503.GB53158@elstar.local> Mail-Followup-To: Ladislav Lhotka , Robert Wilton , "netconf@ietf.org" References: <569E13E2.9020802@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 15:05:17 -0000 On Tue, Jan 26, 2016 at 03:20:30PM +0100, Ladislav Lhotka wrote: > Apart from message ordering issues, do you see other differences between > HTTP 1.1 and 2 that might affect RESTCONF? I think notification delivery could be done more elegant in HTTP/2 using Server Push (section 8 of RFC 7540) but then I do not know to what extend deployed APIs support HTTP/2 push of objects. Several APIs seem to provide an HTTP/1.1 view on HTTP/2 sessions and thus they do not expose the new push feature of HTTP/2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 26 07:25:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F821B2A7F for ; Tue, 26 Jan 2016 07:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDzOVI210X8C for ; Tue, 26 Jan 2016 07:25:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3F41B2AAE for ; Tue, 26 Jan 2016 07:25:56 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:a8b8:32fe:2ff0:5b4c] (unknown [IPv6:2001:718:1a02:1:a8b8:32fe:2ff0:5b4c]) by mail.nic.cz (Postfix) with ESMTPSA id 0483518088A; Tue, 26 Jan 2016 16:25:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1453821955; bh=t5P0B4ES8XFEq+sn8a74JqmveI3NN6DOMzPufKo3MhY=; h=From:Date:To; b=dUJoSBwOlvgE6dp6j7/ynFjHq8ASUwLQgH9Zwx0twY7BjC/p/20sHKiQTrUeLpjyZ wAKk/fCvgPj4X1LS5qXS5EfxBHitXzzE6cSMvD1PU4fdLpXXf0OGTgX8cZ6nDrHHiP wqY2e0/Lj6jw57/jn/IoepbfSW1Fft6DN1oce/pM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160126150503.GB53158@elstar.local> Date: Tue, 26 Jan 2016 16:25:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <569E13E2.9020802@cisco.com> <20160126150503.GB53158@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 15:25:58 -0000 > On 26 Jan 2016, at 16:05, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 26, 2016 at 03:20:30PM +0100, Ladislav Lhotka wrote: >=20 >> Apart from message ordering issues, do you see other differences = between >> HTTP 1.1 and 2 that might affect RESTCONF? >=20 > I think notification delivery could be done more elegant in HTTP/2 > using Server Push (section 8 of RFC 7540) but then I do not know to My understanding is that HTTP/2 server push cannot be used as a = replacement for SSE or Websockets, because the server has to send the = PUSH_PROMISE frame also containing "expected" request headers to which = the server is about to send responses. So, for example, a HTTP/2 server, after receiving GET /.well-known/host-meta *might* use server push for sending yang-library information right away, = because the client is likely to need it, too. But I don't think server = push can be used for implementing notifications. Lada > what extend deployed APIs support HTTP/2 push of objects. Several APIs > seem to provide an HTTP/1.1 view on HTTP/2 sessions and thus they do > not expose the new push feature of HTTP/2. >=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 nobody Tue Jan 26 07:32:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576521B2B1F for ; Tue, 26 Jan 2016 07:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjomcupStsas for ; Tue, 26 Jan 2016 07:32:10 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3A91B2B0F for ; Tue, 26 Jan 2016 07:32:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A6D91781; Tue, 26 Jan 2016 16:32:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Vh0KGMItfrMS; Tue, 26 Jan 2016 16:32:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Jan 2016 16:32:07 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C704220033; Tue, 26 Jan 2016 16:32:07 +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 H35Lflgorb0Q; Tue, 26 Jan 2016 16:32:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13ED82002C; Tue, 26 Jan 2016 16:32:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 041CB39C246A; Tue, 26 Jan 2016 16:32:05 +0100 (CET) Date: Tue, 26 Jan 2016 16:32:05 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160126153205.GA53359@elstar.local> Mail-Followup-To: Ladislav Lhotka , Robert Wilton , Netconf References: <569E13E2.9020802@cisco.com> <20160126150503.GB53158@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 15:32:13 -0000 On Tue, Jan 26, 2016 at 04:25:56PM +0100, Ladislav Lhotka wrote: > > > On 26 Jan 2016, at 16:05, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 26, 2016 at 03:20:30PM +0100, Ladislav Lhotka wrote: > > > >> Apart from message ordering issues, do you see other differences between > >> HTTP 1.1 and 2 that might affect RESTCONF? > > > > I think notification delivery could be done more elegant in HTTP/2 > > using Server Push (section 8 of RFC 7540) but then I do not know to > > My understanding is that HTTP/2 server push cannot be used as a replacement for SSE or Websockets, because the server has to send the PUSH_PROMISE frame also containing "expected" request headers to which the server is about to send responses. > > So, for example, a HTTP/2 server, after receiving > > GET /.well-known/host-meta > > *might* use server push for sending yang-library information right away, because the client is likely to need it, too. But I don't think server push can be used for implementing notifications. > Because notifications are not modelled as first class resources? I doubt this matters. The notification stream could be a resource and then you simply craft GET requests that return the notification content. In fact, RESTCONF already has 'event stream resources'. But at the end, wide-spread support in HTTP APIs does matter and it is perhaps too early to tell. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 26 09:45:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B11A9116 for ; Tue, 26 Jan 2016 09:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBqLqrMBkztk for ; Tue, 26 Jan 2016 09:45:16 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3231A9113 for ; Tue, 26 Jan 2016 09:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2833; q=dns/txt; s=iport; t=1453830313; x=1455039913; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qx0Rke+9vpX/HEnoKNIFAZVfPV47vt356PsCT61AIQs=; b=Y0PENMalIPcCBxLNx/hPrpsDPaHZH6ry7KVhB0aUQEY69bXVeP68kpMx sfVQHo1wL+7Uy/hoW/54ZR9NiDmjFLMwY8pB3v+eFl7/ysJZEGmHt7U5v RKq3EumZBiiTCbwDGm4LaARQZFtKvWQwJmPzFcWNOgmdEQ5/zisc6yx41 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmBQAnsKdW/4cNJK1bA4M6Um0GiFGyL?= =?us-ascii?q?IFiGAqFI0oCgU45EwEBAQEBAQGBCoRBAQEBAgEBAQEBNzQLBQkCAgEIDgIFAx4?= =?us-ascii?q?QGwwLJQIEAQ0FCIgLCA6+YgEBAQEBAQEBAQEBAQEBAQEBAQEBARUEhi6EbYQsA?= =?us-ascii?q?QEFOREVg3QFlnkBjU6PAI5CASIDPYNpagGHEzR8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="67318352" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jan 2016 17:45:12 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0QHjB6k019250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 17:45:12 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 12:45:11 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 12:45:11 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder , "Ladislav Lhotka" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 Thread-Index: AQHRWE6/sZkYl04aS0ml1QE4AkU/MZ8OBbvw Date: Tue, 26 Jan 2016 17:45:10 +0000 Message-ID: <490555c0a8bf4741914459892cdddce1@XCH-RTP-013.cisco.com> References: <569E13E2.9020802@cisco.com> <20160126150503.GB53158@elstar.local> <20160126153205.GA53359@elstar.local> In-Reply-To: <20160126153205.GA53359@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.230] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:45:17 -0000 At this point, Restconf does not expose the necessary capabilities to fully= utilize HTTP/2. Previously the NETCONF WG talked about this in a thread: https://www.ietf.org/mail-archive/web/netconf/current/msg10429.html There are several nice things full HTTP/2 can provide, should the capabilit= ies be exposed above Restconf: - Prioritized TCP stream de-queuing=20 - Avoiding head-of-line blocking from elephant flows - Per-stream flow control For more, see slides 5 & 6 from IETF 94 https://www.ietf.org/proceedings/94/slides/slides-94-netconf-5.pdf (This deck is framed in terms of subscriptions, but the points are equally = valid for normal TCP streams.) Although I would love to see this in the initial Restconf RFC, I have alway= s expected the such a specification would be in a subsequent draft. Eric > From: Juergen Schoenwaelder, Tuesday, January 26, 2016 10:32 AM >=20 > On Tue, Jan 26, 2016 at 04:25:56PM +0100, Ladislav Lhotka wrote: > > > > > On 26 Jan 2016, at 16:05, Juergen Schoenwaelder > wrote: > > > > > > On Tue, Jan 26, 2016 at 03:20:30PM +0100, Ladislav Lhotka wrote: > > > > > >> Apart from message ordering issues, do you see other differences > > >> between HTTP 1.1 and 2 that might affect RESTCONF? > > > > > > I think notification delivery could be done more elegant in HTTP/2 > > > using Server Push (section 8 of RFC 7540) but then I do not know to > > > > My understanding is that HTTP/2 server push cannot be used as a replace= ment > for SSE or Websockets, because the server has to send the PUSH_PROMISE > frame also containing "expected" request headers to which the server is a= bout > to send responses. > > > > So, for example, a HTTP/2 server, after receiving > > > > GET /.well-known/host-meta > > > > *might* use server push for sending yang-library information right away= , > because the client is likely to need it, too. But I don't think server pu= sh can be > used for implementing notifications. > > >=20 > Because notifications are not modelled as first class resources? I doubt = this > matters. The notification stream could be a resource and then you simply = craft > GET requests that return the notification content. In fact, RESTCONF alre= ady has > 'event stream resources'. > But at the end, wide-spread support in HTTP APIs does matter and it is pe= rhaps > too early to tell. >=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 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jan 26 09:57:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5602A1A92A9 for ; Tue, 26 Jan 2016 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC0ukcTCX3wg for ; Tue, 26 Jan 2016 09:56:53 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319E81A9244 for ; Tue, 26 Jan 2016 09:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kL2XbXt+NCAKrzfV5KhJ4gQ8gtQtZgICkiTWVigxw8Y=; b=MdTkahIvk2JAkOduW5BqKJNIrjvqEV61KLlnVlxVd4VfGqCWLjqeqOQKKdfs4JeYgVU8EiqpeTww+lq3CcpuiOltaNY3dKi6hv+Jiu/hTuDGugqvaX5+eEmdbRRZAIDDVXnlcx3F5FdtlYzSwqH2YizVkTCD9qI6ZhlKlUzHtYA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 26 Jan 2016 17:56:33 +0000 Message-ID: <016e01d15862$7bb5b400$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <001701d1552e$68966b80$4001a8c0@gateway.2wire.net><010901d155dc$dec87420$4001a8c0@gateway.2wire.net><00b401d15696$6528a260$4001a8c0@gateway.2wire.net> Date: Tue, 26 Jan 2016 17:53:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: [86.185.87.133] X-ClientProxiedBy: DB4PR05CA0034.eurprd05.prod.outlook.com (25.160.40.44) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 2:9kD+FB+WemOXpRE6XsEBLHqItmh+Bix74/nPf0mHTNg48UhDN5l3ZGeCnyQGP5SEgr47ak4HlRMaCEBj7kXdDIwECsXBUC3p7JKLxS6N7fRubgA9qgRMVGMRHC5wcw9l6yIx2fjT9jPaSfT7WV/Q7A==; 3:ljJ8qQ4viz8FqjKw+rXOQQ3a+EgvHEcU3Y5/Mj3A4FnAg85qnwRVxaN/zCQ1Q8176S6YEYymhqc4NlUFI9McgtkG5TFS4SH+6LKxOLKpxZ952fZ1XCv5BY2dsgKMxCX9; 25:PzzgAzIMaVnaKgCB6s6IWkF6zXkanlH2P8xh7HWllY1ieVUmzfes1pjuErfuBFX4neLZzDTUfufOaoe0yB69gAIKnoeu7cxV+pk72zFo8Mk45PZ9z/nMqB+GXFir9bIwFN4Nj0V8Gsbuw4ptuWOb4oHU7bXkBxO1eRhmNOlT2tWrhOuyQeu2Q9coo9KDm3nqDmn6YJW3S3AQdou3pMLVZR+s71BzNeS80vrGgl+lv0GFW0ntWPlQe7kbuPqVEUWE X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-MS-Office365-Filtering-Correlation-Id: d44b2843-e5d4-4bff-caf0-08d3267a0715 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB051; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB051; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 4:fAaIjlesJXV6wY4X3bw1jsB2Cg9XGe8Zj40AMAjGlW8JgQ1wQbB9rUhbztIhr+ujQqIfPLRMBkH6+uMla9PcpXTDOmzWOhw053PYRIaZITuvxyw1SU/hFxsqBabv/xq9mZqrQrXJqtmTGEe6IENfRfM/WFD0tZ2/EO7DwXHiMvuNZRAyR2chkF8QyN+0Eh9C865BUIS9gIO+20g0BFaxAp19kH2d5EMsQRqQW26Dnet8PsRTcIzMeKOpdY9fQDdRynYykmND1wq9++5++NSnJsIfTqezuPvsPSD9YEkvpF4ALPi55AOaSUemXNat/C+6NDYgmu8VeDO8sZfZyJS9ullkxrk6qaHypHSDz53h9szBPxyBnufD8qMml+KGGbB2O42ISIDxo7WHz0Avt3Ym3VjmlNw0dg/ZieHXElix4d3N+nOcDkQyiVts2BfCmUT6 X-Forefront-PRVS: 08331F819E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(24454002)(189002)(377454003)(199003)(13464003)(230700001)(15975445007)(1456003)(5001960100002)(110136002)(3846002)(81686999)(1096002)(14496001)(61296003)(62236002)(106356001)(50986999)(5008740100001)(101416001)(586003)(44716002)(105586002)(81816999)(19580395003)(76176999)(189998001)(6116002)(81156007)(97736004)(44736004)(47776003)(66066001)(77096005)(19580405001)(50466002)(2906002)(122386002)(4326007)(84392002)(1556002)(116806002)(230783001)(87976001)(50226001)(5004730100002)(42186005)(40100003)(86362001)(93886004)(23676002)(92566002)(33646002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA3TUIwNTE7MjM6Y2p1L2IwejJFSmxQK3NzTFU2Z2MxMFpXQ2RH?= =?utf-8?B?T0w2bExUR2FiRGp3VlNlT09UajJlekdwQkx2T2djV0tCaEl1bEsvanFCTG94?= =?utf-8?B?bGttcldac0xFZDZLc2RWRnpnTEczTmlDOCtEbW9RWHZwMk1nMW92cy9ockdM?= =?utf-8?B?SC9YblpCc3Jxdko4S28yVVhlRDM0dkM3SFJvek1TazdrYVFrMGRkTVZaTGRj?= =?utf-8?B?WE5KeTZqcmJqcC9tWTlNSVNNb2xQenNmL2lTdzQ5SkRQM1ZuODNGTzBNZnh2?= =?utf-8?B?bzI3TEo4a3lSZW13S3RwZlhBUkIvSzJqbGpUaGJRZGFINXYyR2QvSnJxUVB0?= =?utf-8?B?eS96WGZaTXJjMGJpTVhURTdYVXpJd2J5dGNLWE1hOU1wcUFQMUFYc1E2S1px?= =?utf-8?B?VDB5ZEV1YjhFU2F1MlFTaEFuV1g3cDlmVHNSOVZiWWdLVENuM2JWYXk0S2tI?= =?utf-8?B?US9rcGFpMUJrWHdkZUNBb0RFNzlCK0I5c3IzOUh2QU9sOXBkTHhkSWE3K0cx?= =?utf-8?B?VmI3Q1NudlB6NUN4eVoxRHkwQ0N1VmNmLzZHbCs3NWVMTlRrZUdQclVLVENC?= =?utf-8?B?Y1dHSHg1M2JhQXZWT2MzVVlwTXJJZlhkVlluMm9Sdy9UMFovQ1d0SEFFc1FX?= =?utf-8?B?bnFNa0pPaDlBc0laTlIyWTlVMjkvNVNKdktCdHRwRFpyVVN0SFc4UnZNNDZO?= =?utf-8?B?RFBxWWp6bEdnb3ByRFl0UEI5RWw4TFh6ZGxzczdoYkFjVnBIQmdBWkU4RGVG?= =?utf-8?B?dnFRUStiZ3hLeU9xWGQ5UjR0TkR6Ykc1MnVtY0xWMjByWjNVZlFCYnJSMTFV?= =?utf-8?B?TGpZemhySVVySlgzYVJyYTZkc2wvMSt5R0RpeEZFSGljTno0Z1pZWnBDR296?= =?utf-8?B?L2UxS3ZMWEVpbERqYS9YS0VMMzNkcG9vdEJDWXVjWGVPRnJpUGVlQ3Jqbkgw?= =?utf-8?B?clV4Mi9QMWVOTmxHc21HOGdHcFhGM2pvbTBpaUlRQi9ScGJzL3AveEZzSnlT?= =?utf-8?B?OFZGY0F4Y3VwYnc0YnhRV1FxYlEwTE92WmprNHR0L0RlbUwzZUFibXQ3eE9k?= =?utf-8?B?OGlYS2cySFRYbll3QnIzNVVZMEc4MWNMakFidzd3a1ZtL2ZLb2o2MU5HSmpw?= =?utf-8?B?NWIza2NXK3Q1aUwrRklUeHB5eUorNm8xWFlSbVRtd3RWVTl6ZlRwcmdURUZX?= =?utf-8?B?VUt1Z2pUYU93VzRFMisxZ0I2TTFjTE8yY0lMYktna3lOaytyTWxIT1FObDFX?= =?utf-8?B?QUtBU3A0SmFaaUVtSVBESTgxd3VuRC9kMDlrdGM3SFVTOEllOVpTdTVORVZl?= =?utf-8?B?RUdRV3hFZVYzTmJtbHRWaDRsUEtXRkw3dGs0bHl0RFYvcVprMkc2L2c4d2p4?= =?utf-8?B?QnNsUnZFL0tNSFRvMEZHMDEzWU9XRjR5dE16MXorbm1IRzlxL2g3TjRuY3RS?= =?utf-8?B?NkdDc004MWpFSDFQcldxSGl2SnJUTXV2cWdNSTlVNUVEaFY2ZTJHQmdoTDN0?= =?utf-8?B?TzFPTDE5emYyM2lrbnNKeGNBUk5IM01MU2R3OEdIZStsZ2xkcEgwc093MG9v?= =?utf-8?B?RTZUcTNaTXRYa1JYVStpNkRVZC9qTmhha093b2R6dTJhV0FuSGUzUUU0QitE?= =?utf-8?B?MkpLdnl3MWNyWFFRcDY3b1lVL3RCMyt2c1RZaWVFNDFiZnFPT2ZqQ0hONGVR?= =?utf-8?B?ejFoTlVIK3MvUTF5bTgwWUpoTVhuclZhTzBwVXBUUmV5ODI2YW84MzgyVUli?= =?utf-8?B?endrNThaTU8zc2d0V2tOQzdpQlFvd1pxU25neHFvaXl1NkttcmNDcDhiYklp?= =?utf-8?B?T3VSaU4wTm5Ud1hjcTZBZUFvUTNDd3I2ZXowUFA1Y1lFUHp4SEZ5WkJid2dr?= =?utf-8?Q?ZuGw4jjZZF6pbrNrQswQORptBglFZO+?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB051; 5:Ogz6lMpAkJTPpzuBI+wAogjp4wg6p5mrJgwsmvFWu7h4z8gw90943Z6jkZkCzaGdnehlFC6sY3LSQ0x2eZKq1VAeVEBADub4AUPEw62hvrNbMPyzzaTY6T/yHIuRCawCZy0RiXoEhjFSYSYvBqgEtQ==; 24:AWAwca1W1jIJa0yUemcQ2yJpW8kAg/7CVSS61KFe6NJpfu00PRvog8ryfkX+5sjbRhbWc7vUmAzY9gP7OWvlXVsSz8PFj8r1Pif0pLXpJcU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2016 17:56:33.2518 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:56:59 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Sent: Sunday, January 24, 2016 2:59 PM > On Sun, Jan 24, 2016 at 3:00 AM, t.petch wrote: > > > ----- Original Message ----- > > From: "Andy Bierman" > > To: "t.petch" > > Cc: "Ersue, Mehmet (Nokia - DE/Munich)" ; > > "Netconf" > > Sent: Saturday, January 23, 2016 3:13 PM > > > > > > Would your concerns be we put more detail in the NETCONF Coexistence > > > section. > > > I have already pointed out that the confirmed-commit details are > > missing. > > > We will make it clear which details a RESTCONF client needs to know. > > > > > > We can add another short section for RESTCONF only considerations. > > > I thought it was already clear that implementation of NETCONF was not > > > required, but we can make it extra clear. > > > > > > Applicability is another problem. IMO let the market decide. > > > Some companies (and WGs) are already working on solutions that provide > > a > > > unified > > > "YANG development environment" to deploy with whatever protocol, > > across a > > > range of > > > platforms from IoT to SDN. (CoAP, RESTCONF, RESTCONF/NETCONF, NETCONF) > > > The boundaries of applicability are subjective and might be rapidly > > > changing for awhile. > > > (So I don't want to write an AS for RESTCONF.) > > > > Andy > > > > I think that it is s1.3 that most needs changing, as I said in my first > > e-mail of comments, but that its direction needs changing, to become > > 'Relationship with NETCONF'. > > > It should then say (although not in this order) > > > > - a restconf client may or may not also be a NETCONF client > > IMO you are really confused. If I am, perhaps it is the result of reading this I-D:-) After all, it is the authors who put in " 1.3. Coexistence with NETCONF RESTCONF can be implemented on a device that supports NETCONF." which draws the topic of coexistence to my attention for review, which I have done. My marginal comment on this section was 'marketing' but I see nothing wrong with that. But as I said before, I think that this section has the wrong emphasis, that it should be about the relationship between NETCONF and restconf, not just about coexistence on a box; and if the authors want to cover coexistence, then to me that means coexistence in a client and coexistence in the server (of which the latter seems to raise more issues that need addressing, such as locks, authenticated usernames and such like). Again, as I have said before, rather than sorting out coexistence, I do see a greater need to spell out those parts of NETCONF that are being used alongside the restconf protocol to produce a system for operations. Tom Petch > Why would a RESTCONF client need to implement NETCONF? > > The ONLY things a RESTCONF client needs to do > to access RESTCONF functionality if be a RESTCONF clent. > > The argument "but RESTCONF can't do everything that NETCONF can do" > is irrelevant because the RESTCONF protocol does not claim > to do everything NETCONF can do. > > A RESTCONF-only server may also have CLI, which can > lock the datastore, which can cause a RESTCONF edit to fail. > I suppose we have to warn people about this in the draft as well. > > Andy > > > > > > > > - a restconf server may or may not also be a NETCONF server > > (and that is all I am intending by way of applicability) > > > > > > - restconf replaces NETCONF the protocol but does use everything else > > from NETCONF, followed by an exhaustive list, which would include at > > least: > > state date and configuration data, multiple datastores, data > > persistence (yes, I know RFC6241 is rather vague), (roll back on) error > > handling, defaults, capabilities (e.g :writable-running), locks, ... > > > > Tom Petch > > > > > Andy > > > > > > > > > On Sat, Jan 23, 2016 at 4:51 AM, t.petch wrote: > > > > > > > ---- Original Message ----- > > > > From: "Andy Bierman" > > > > Sent: Friday, January 22, 2016 4:32 PM > > > > > > > > > Why is it rubbish that there can be a RESTCONF-only server? > > > > > I can't find any text that says NETCONF MUST be implemented > > > > > if RESTCONF is implemented. > > > > > > > > > > Some details (like defaults handling) are aligned with NETCONF. > > > > > That doesn't mean the RESTCONF client needs to know much > > > > > about NETCONF datastores or locks, etc. > > > > > > > > Andy > > > > > > > > I find the I-D silent on its applicability. I see > > > > " RESTCONF can be implemented on a device that supports NETCONF." > > > > which I regard as close to marketing but have no problem with it > > being > > > > there. What I lack is any indication as to whether or not it is > > > > feasible to have a restconf-only management system. restconf lacks > > some > > > > of NETCONF's capabilities so is it expected that the server will be > > > > NETCONF as well or is the expectation that there will be > > restconf-only > > > > systems? > > > > > > > > This colours how I comment on the following text. One small example > > of > > > > several is in s.12 > > > > > > > > "Implementors SHOULD provide a comprehensive > > > > authorization scheme with RESTCONF and ensure that the resulting > > > > NETCONF username is made available to the RESTCONF server." > > > > > > > > which implies to me that the server has NETCONF capabilities, at > > least > > > > in part. If not, then s.12 needs rewriting, along the lines that > > > > restconf imports the idea of a username (along with masses of other > > > > things) from NETCONF and must conform to the specification of > > usersname > > > > as in section .. of RFC ..... > > > > > > > > So can there be a restconf-only system, clients and servers? > > (dunno, > > > > I-D implies not) > > > > Can a server support restconf and NETCONF? yes, s1.2 tells me so > > > > Can a restconf-only client do useful work with a hybrid > > restconf/NETCONF > > > > server? (hopefully) > > > > Can a client support restconf and NETCONF and use them to work with > > > > restconf-only servers and NETCONF-only servers? um, authentication > > > > needs thinking about but hopefully yes > > > > > > > > I find the I-D incomplete without this being clearly stated. > > > > > > > > My comment of 'rubbish' was aimed at a different point, where the > > I-D > > > > says that > > > > " the user should not need any prior knowledge of NETCONF in order > > to > > > > use RESTCONF." > > > > To me it is abundantly clear that the user must understand NETCONF > > in > > > > depth in order to make sense of this I-D and I extrapolate that to > > > > understanding NETCONF in order to make use of restconf. There may > > or > > > > may not be a need to have access to NETCONF client/server, which is > > my > > > > point above, but there has to be an understanding of the concepts of > > > > NETCONF in order to make sense of restconf. You of course, along > > with > > > > your fellow authors, WG Chairs, WG ADs, have that in depth. I have > > it > > > > to some degree. Someone without such knowledge has no hope of > > > > understanding or using restconf! > > > > > > > > Tom Petch > > > > > > > > > Andy > > > > > > > > > > On Fri, Jan 22, 2016 at 8:03 AM, t.petch > > wrote: > > > > > > > > > > > Having read all of restconf, I find myself with some fairly > > basic > > > > > > questions for which I cannot see answers. > > > > > > > > > > > > A) Is restconf an optional extra for a server on top of NETCONF > > or > > > > do > > > > > > you expect there to be restconf-only servers? S.1.3 says that > > they > > > > can > > > > > > coexists, yes, great, marketing. But can you perform useful > > > > operational > > > > > > tasks from a restconf-only client to a restconf-only server? I > > > > started > > > > > > off assuming you could, but ended up thinking the I-D was > > telling me > > > > > > that at least the server musy have both e.g. s.12 > > > > > > "it does require that an authenticated NETCONF username be > > > > associated > > > > > > with each request" > > > > > > which also begs the question, can there be restconf-only client? > > > > > > > > > > > > Needs specifying IMO, perhaps after thinking through the > > > > consequences. > > > > > > > > > > > > B) " the user should not need any prior knowledge of NETCONF in > > > > > > order to > > > > > > use RESTCONF" > > > > > > Well, I wrote 'rubbish' alongside that and taken literally, it > > is:=) > > > > > > NETCONF [RFC6241 et al] defines NETCONF the protocol and NETCONF > > the > > > > > > operational infrastructure (configuration, state, datastore, > > event, > > > > > > error handling, persistence of data. ....) and while the former > > is > > > > > > replaced, in whole or in part, by restconf, the latter most > > > > definitely > > > > > > is not, as exemplified by the definitions imported in s.1.4.1 > > > > > > > > > > > > But that also in untrue. This I-D implies, mostly without being > > > > > > explicit, that it refines NETCONF the operational infrastructure > > > > > > (perhaps using the terms in a different way). Thus it appears > > that > > > > > > there is no explicit selection of NETCONF datastore but that > > which > > > > one > > > > > > is chosen is implicit. I infer this from s.1.3 but think that > > it > > > > needs > > > > > > separating out more clearly. > > > > > > > > > > > > C) configuration and state; RFC 6241 is very clear about this, > > this > > > > I-D > > > > > > seems to be half way towards whatever resolution netmod comes to > > on > > > > > > netmod-opstate-reqs, which is probably not a good idea. 'state' > > I > > > > see > > > > > > used only twice, then this undefined 'operational data' takes > > over > > > > and > > > > > > the water is then muddied by 'config' and 'nonconfig'. This is > > > > > > wandering off into its own 'restconf the operational > > infrastructure' > > > > > > without ever saying AFAICT how it differs from NETCONF. It is > > as if > > > > the > > > > > > three authors each independently wrote parts of the I-D:-) > > > > > > > > > > > > D) Then there are datastores, at least there are until s.4.4.1, > > when > > > > > > datastore seems to be redefined to mean 'top level node' a term > > > > which > > > > > > has surfaced on the (netmod or netconf) mailing list as being > > > > something > > > > > > that is not defined and may mean different things to different > > > > people. > > > > > > I read the first half of the I-D thinking that 'datastore' is as > > > > defined > > > > > > in RFC6241 and then find half way through that I cannot see any > > way > > > > that > > > > > > it is. I note the absence of any examples involving > > > > > > 'application/yang.datastore' > > > > > > and think, well yes, that figures! > > > > > > > > > > > > E) This then calls into question for me the meaning of the term > > > > 'data'. > > > > > > In the latter part of the I-D, it seems to be shorthand for > > 'data or > > > > > > datastore' with datastore having its non-NETCONF meaning but > > early > > > > on, > > > > > > it is used alongside 'datastore' suggesting that it has a more > > > > > > restricted meaning, coupled with the use of different media > > types, > > > > but I > > > > > > cannot tell. > > > > > > > > > > > > So, I have some detailed comments on s.4 onwards but think that > > the > > > > > > 'beams' need resolving first. > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "t.petch" > > > > > > To: > > > > > > Cc: > > > > > > Sent: Wednesday, January 20, 2016 6:43 PM > > > > > > Subject: Re: WG Last Call for draft-ietf-netconf-restconf-09, > > > > > > draft-ietf-netconf-yang-patch-07 and > > > > draft-ietf-netconf-yang-library-03 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Netconf mailing list > > > > > > Netconf@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Tue Jan 26 10:15:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5553E1ACDF9 for ; Tue, 26 Jan 2016 10:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAMntOpwI1Xc for ; Tue, 26 Jan 2016 10:15:28 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CD41ACD93 for ; Tue, 26 Jan 2016 10:15:28 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DEFA972F; Tue, 26 Jan 2016 19:15:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7WgOrkyvBEo2; Tue, 26 Jan 2016 19:15:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 26 Jan 2016 19:15:26 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C2A420033; Tue, 26 Jan 2016 19:15:26 +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 PbPyDGhmVJ6b; Tue, 26 Jan 2016 19:15:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F1CE2002C; Tue, 26 Jan 2016 19:15:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A38F439C29F8; Tue, 26 Jan 2016 19:15:23 +0100 (CET) Date: Tue, 26 Jan 2016 19:15:22 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20160126181522.GA53933@elstar.local> Mail-Followup-To: "t. petch" , Netconf References: <016e01d15862$7bb5b400$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016e01d15862$7bb5b400$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 18:15:30 -0000 On Tue, Jan 26, 2016 at 05:53:21PM +0000, t. petch wrote: > > Again, as I have said before, rather than sorting out coexistence, I do > see a greater need to spell out those parts of NETCONF that are being > used alongside the restconf protocol to produce a system for operations. > What you are looking for is an architectural document that defines the basic concepts that tie NETCONF, RESTCONF, YANG, etc together. I see that such a document is needed and I am happy to invest some of my time into such a document in the future. That said, I do not think that we should hold back RESTCONF until such a document has been written and gone through the consensus process. Hence, we need to find a reasonable compromise (as we do with other documents at the moment) but the long term goal should indeed be to create this architectural document (and future revisions of protocol and language specifications should then align with it). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 26 14:47:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E51B328E for ; Tue, 26 Jan 2016 14:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxtEjAD5TIBr for ; Tue, 26 Jan 2016 14:47:30 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 746EB1B328D for ; Tue, 26 Jan 2016 14:47:30 -0800 (PST) Received: from [172.16.0.179] (chello085216168097.chello.sk [85.216.168.97]) by mail.hq.sk (Postfix) with ESMTPSA id C99FE2401B1; Tue, 26 Jan 2016 23:47:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1453848448; bh=6VuCEQuclyGgq8qvK1A/KZg8ICoqsdVHpQv3adRCHKk=; h=Subject:To:References:From:Date:In-Reply-To; b=LD2Q3yMAR/lsDoqGJM66M382omSH99gOqPtZSEy3QbvC/FhwZx/AkEQ4aKmVSQWsF IyF0Ce4ouOa7jDiPZHB2mgyf+gJ04S2L3R4X0qnlSoITHlWSsddp57iPvKvKJOTknO YscN0t/uNHLzdcYD87zWECjBy6fNiw5uL3Ph/+G8= To: Ladislav Lhotka , Robert Wilton , "netconf@ietf.org" References: <569E13E2.9020802@cisco.com> From: Robert Varga Message-ID: <56A7F77E.7050800@hq.sk> Date: Tue, 26 Jan 2016 23:47:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 22:47:33 -0000 On 2016-01-26 15:20, Ladislav Lhotka wrote: >> > >> >3. Even if HTTP pipelining isn't supported then does there need to be >> >any statement made about the relative orderings and what can be seen in >> >the datastore when processing a combination of edit operations >> >(PUT/PATCH/POST/DELETE) and GET requests by a single client? I.e. from >> >a client's perspective is it fair to assume that a GET request will see >> >all updates to the running configuration datastore from all previous >> >edit operations? > I would say so. +1, assuming these do not happen concurrently on multiple HTTP sessions. A generic client must not assume it is the only entity talking to the server, though. Bye, Robert From nobody Thu Jan 28 11:27:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5D31B35AD for ; Thu, 28 Jan 2016 11:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX8XFNtvR0kC for ; Thu, 28 Jan 2016 11:27:13 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB3E1B35AE for ; Thu, 28 Jan 2016 11:27:12 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-7b-56aa6b8dbc85 Received: from ESGSCHC008.ericsson.se (Unknown_Domain [146.11.116.89]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.8E.05690.D8B6AA65; Thu, 28 Jan 2016 20:27:10 +0100 (CET) Received: from ESGSCMB103.ericsson.se ([169.254.3.24]) by ESGSCHC008.ericsson.se ([146.11.116.89]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 03:27:08 +0800 From: Yong Zhu To: "Netconf@ietf.org" Thread-Topic: [netconf] Question on the output of rpc-reply for operational model? Thread-Index: AdFaAbVQh1gWInAeS9qQ0MDBq89+1g== Date: Thu, 28 Jan 2016 19:27:08 +0000 Message-ID: <31BFEF67CF6AC44BBEDE1890158D737738896455@ESGSCMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyibskUrcve1WYwa4WSYupm26zOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49LGb6wFVwQqth06ztrAOEegi5GTQ0LAROL3ygZGCFtM4sK9 9WxdjFwcQgKHGSW+f3/JDuEsZpTYceEiM0gVm4CaxInLW1m6GDk4RAQ0JSY+1gMJCwuESvy/ fY8JxBYRiJJYdXE7K0SJnsSC9lqQMIuAqsTPyXNZQWxeAV+Jq4+3gU1kBNr7/dQasFZmAXGJ W0/mM0HcIyCxZM95ZghbVOLl43+sELaCxNx/T5lBxjMDXbB+lz5Eq6LElO6H7BDjBSVOznzC MoFReBaSqbMQOmYh6ZiFpGMBI8sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDgPrjlt+4O xtWvHQ8xCnAwKvHwGrSsDBNiTSwrrsw9xCjBwawkwhuetSpMiDclsbIqtSg/vqg0J7X4EKM0 B4uSOO9B/kVhQgLpiSWp2ampBalFMFkmDk6pBsbUCV0T77mc2D6lPGX+svvT9l+fdv6ofZ4q Q9C0f94X5+pz19qGus0o2nziuKTktuOyeuv6mB7tSVkmJTer3v7K3zklyQ4NLDrHljy7s5Kv RGJO+jO5Wzefya3vPjmzY2qD5k9374Cw/RuePXA9dkxw2bJnwmYXs9OrDoZfCQy6ejJCZHPV +RpXJZbijERDLeai4kQAF2ovkWoCAAA= Archived-At: Subject: [Netconf] [netconf] Question on the output of rpc-reply for operational model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 19:27:14 -0000 SGkgV29ya2dyb3VwLA0KDQpCYXNlZCBvbiBqcydzIGZlZWRiYWNrLCBJIGZvcndhcmQgbXkgcXVl c3Rpb24gdG8gbmV0Y29uZiB3b3JrZ3JvdXAuDQoNCldlIGdvdCBzb21lIHF1ZXN0aW9uIHJlZ2Fy ZGluZyBuZXRjb25mIG9wZXJhdGlvbuKAmXMgcnBjLXJlcGx5IG91dHB1dC4NCkZvciBleGFtcGxl LCB3ZSBoYXZlIGRyYWZ0IG9wZXJhdGlvbmFsIG1vZGVsIGFzIGZvbGxvd3MgKGxpc3QgQUFBIGNv bnRhaW5zIGxpc3QgQkJCIHdoaWNoIGNvbnRhaW5zIGxpc3QgQ0NDKToNCmxpc3QgQUFBIHsNCiAg a2V5ICJhYWFfbmFtZSI7DQogIGNvbmZpZyBmYWxzZTsNCiAgbGVhZiBhYWFfbmFtZSB7DQogICAg dHlwZSBzdHJpbmc7DQogIH0NCiAgbGVhZiBhYWFfbGVhZjEgew0KICAgIHR5cGUgaW50MzI7DQog ICB9DQogICBsaXN0IEJCQiB7IA0KICAgICBrZXkgImJiYl9uYW1lIjsNCiAgICAgY29uZmlnIGZh bHNlOw0KICAgICBsZWFmIGJiYl9uYW1lIHsNCiAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgfQ0K ICAgICBsZWFmIGJiYl9sZWFmMSB7DQogICAgICAgdHlwZSB1aW50MzI7DQogICAgIH0NCiAgICAg bGlzdCBDQ0Mgew0KICAgICAgIGtleSAiY2NjX25hbWUiOw0KICAgICAgIGNvbmZpZyBmYWxzZTsN CiAgICAgICBsZWFmIGNjY19uYW1lIHsNCiAgICAgICAgIHR5cGUgc3RyaW5nOyAgICAgDQogICAg ICAgfQ0KICAgICAgIGxlYWYgY2NjX2xlYWYxIHsNCiAgICAgICAgIHR5cGUgdWludDMyDQogICAg ICAgfQ0KICAgICB9IC8vbGlzdCBDQ0MNCiAgfSAvL2xpc3QgQkJCDQp9IC8vbGlzdCBBQUENCg0K VGhlIG5ldGNvbmYgPHJwYz4gcmVxdWVzdCBpcyB0aGUgZm9sbG93aW5nOg0KPHJwYz4NCiAgPGdl dD4NCiAgICA8ZmlsdGVyIHR5cGU9InN1YnRyZWUiPg0KICAgICAgPEFBQT4NCiAgICAgICA8QkJC Pg0KICAgICAgICA8Q0NDPg0KICAgICAgICAgIDxjY2NfbGVhZjEvPiAgLy9xdWVyeSBvbiBjY2Mg bGVhZiBub2RlDQogICAgICAgIDwvQ0NDPg0KICAgICAgIDwvQkJCPg0KICAgICAgPC9BQUE+DQog ICA8L2ZpbHRlcj4NCiAgPC9nZXQ+DQo8L3JwYz4NCg0KV2hhdCBpcyB0aGUgZXhwZWN0ZWQgPyBN b3JlIHNwZWNpZmljYWxseSwgd2lsbCBDQ0PigJlzIGtleSAobGVhZiApIGJlIGluY2x1ZGVkIGlu IHJwYy1yZXBseT8gV2lsbCBBQUEvQkJC4oCZcyBrZXkgKGxlYWYgLyApIGJlIGluY2x1ZGVkIGlu IHJwYy1yZXBseT8NClRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJIGFtIHRoaW5raW5nIG5vdy4gUGxl YXNlIGNvbW1lbnQuDQo8cnBjLXJlcGx5Pg0KPGRhdGE+DQogIDxBQUE+DQogICAgPGFhYV9uYW1l Pm15IGFhYSBuYW1lPC9hYWFfbmFtZT4NCiAgICA8QkJCPg0KICAgICAgPGJiYl9uYW1lPm15IGJi YiBuYW1lPC9iYmJfbmFtZT4NCiAgICAgIDxDQ0M+DQogICAgICAgPGNjY19uYW1lPm15IGNjYyBu YW1lPC9jY2NfbmFtZT4NCiAgICAgICA8Y2NjX2xlYWYxPm15IGNjYyBsZWFmMTwvY2NjX2xlYWYx Pg0KICAgICAgPC9DQ0M+DQogICAgPC9CQkI+DQogIDwvQUFBPg0KPC9kYXRhPg0KPC9ycGMtcmVw bHk+DQoNClRoYW5rcw0KLw0K From nobody Thu Jan 28 17:15:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6341B305F for ; Thu, 28 Jan 2016 17:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIUR_d8usG35 for ; Thu, 28 Jan 2016 17:15:20 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C501B305D for ; Thu, 28 Jan 2016 17:15:20 -0800 (PST) Received: by mail-pa0-x234.google.com with SMTP id uo6so32561700pac.1 for ; Thu, 28 Jan 2016 17:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nzyGYoijj91YkGKVCkU7fsNarA+P65W4fuINdfuKqI4=; b=FlESY5CjusV/KHjDC2ah5FuGi3irxIDlgZHkmSlpxQVR85leS81TWDVHtFADjYsd16 1sP8KHGMCWXJId957fsyCI0YZ4pKA1UdNZ2NMOynimdCkpmTbEc3pkfpgQ53hHn7aMS3 MKdwsiztTgLQ012Rc9tjH1thKzJoEvDg6trpc9KcvcmHxztuAtOcS4ISr8yF5wt5gwBQ mqYYTfxw1TIui4OmtT/JbkGvnt7CrNMz1VZ4ajEcAms9Oz4lFVqpRoeeIoSum0goFWEU GNgtKNeClhOMzIniNF7YDNffuDELeh17XqXbp1IX97WSbpQQbPhN14Ak8GUhnvK5WFbs iPQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nzyGYoijj91YkGKVCkU7fsNarA+P65W4fuINdfuKqI4=; b=ayfNoFThrFV9GP/Ul7FbE7kcPtbDRkG2w+j3UNZKhlOBkLXj6dxWtef8p4X7z3rltc 7JYLJNPHNOBKTHLCXGM0O9o3WE1bgbE3XKV6w5zUEcXP/kGIJ6kh71I1np1hRf2UcVdT ELGYgHofL5ToJy4uqIBSrE5sotSt6G/QxAw/agzEesn0IoIsQcfJ7HDu9GHYeetGrR3D We9Thv1k0vBWxRNl33hxqHltD7TgtItfgh8cOG+UQ8cqZIc5B5LWQx62X2Cal9lzYC3X QXOQk0LbG3WZbY0RF3nJxvukH/B7ADi2BlqdSxvznEPNSFS1VOjuO/3iz80UqQX93j8B 2W3A== X-Gm-Message-State: AG10YOQtwZX7R/a4FHfsWgz+h0jo3F5lztNplc0gjEMoz2uuGffhQzxHYRFJQS16Wn9FaQ== X-Received: by 10.66.150.228 with SMTP id ul4mr9386040pab.15.1454030120069; Thu, 28 Jan 2016 17:15:20 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::40c? ([2001:420:c0c8:1003::40c]) by smtp.gmail.com with ESMTPSA id r26sm19191839pfb.21.2016.01.28.17.15.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 17:15:18 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A91E0662-EF85-41B0-888B-23FBBC674208" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <31BFEF67CF6AC44BBEDE1890158D737738896455@ESGSCMB103.ericsson.se> Date: Thu, 28 Jan 2016 15:20:25 -0800 Message-Id: <963ECE63-ECE3-443D-BFFA-0FA3EA4060D6@gmail.com> References: <31BFEF67CF6AC44BBEDE1890158D737738896455@ESGSCMB103.ericsson.se> To: Yong Zhu X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Netconf@ietf.org" Subject: Re: [Netconf] [netconf] Question on the output of rpc-reply for operational model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 01:15:22 -0000 --Apple-Mail=_A91E0662-EF85-41B0-888B-23FBBC674208 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yong, In addition to giving feedback, did Juergen not answer the question = also? I am including his response. Did you have questions about his = response? > Hi, >=20 > your question is mainly a protocol question and not so much a YANG > question so it probably belongs to NETCONF more than NETMOD. RFC 6241 > in the section describing subtree filtering says: >=20 > o If any sibling nodes of the selection node are instance = identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output. >=20 > I would expect that sensible implementations implement the MAY and > include sibling key leafs (and that they would do this recursively). >=20 > /js > On Jan 28, 2016, at 11:27 AM, Yong Zhu wrote: >=20 > Hi Workgroup, >=20 > Based on js's feedback, I forward my question to netconf workgroup. >=20 > We got some question regarding netconf operation=E2=80=99s rpc-reply = output. > For example, we have draft operational model as follows (list AAA = contains list BBB which contains list CCC): > list AAA { > key "aaa_name"; > config false; > leaf aaa_name { > type string; > } > leaf aaa_leaf1 { > type int32; > } > list BBB {=20 > key "bbb_name"; > config false; > leaf bbb_name { > type string; > } > leaf bbb_leaf1 { > type uint32; > } > list CCC { > key "ccc_name"; > config false; > leaf ccc_name { > type string; =20 > } > leaf ccc_leaf1 { > type uint32 > } > } //list CCC > } //list BBB > } //list AAA >=20 > The netconf request is the following: > > > > > > > //query on ccc leaf node > > > > > > >=20 > What is the expected ? More specifically, will CCC=E2=80=99s key (leaf = ) be included in rpc-reply? Will AAA/BBB=E2=80=99s key (leaf / ) be = included in rpc-reply? > The following is what I am thinking now. Please comment. > > > > my aaa name > > my bbb name > > my ccc name > my ccc leaf1 > > > > > >=20 > Thanks > / > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A91E0662-EF85-41B0-888B-23FBBC674208 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yong,

In = addition to giving feedback, did Juergen not answer the question also? I = am including his response. Did you have questions about his = response?

Hi,

your question is mainly a = protocol question and not so much a YANG
question so it = probably belongs to NETCONF more than NETMOD. RFC 6241
in = the section describing subtree filtering says:

  o  If any sibling nodes of the selection = node are instance identifier
     components for a conceptual = data structure (e.g., list key leaf),
     then they MAY also be included = in the filter output.

I would expect that = sensible implementations implement the MAY and
include = sibling key leafs (and that they would do this recursively).

/js


On Jan 28, 2016, at 11:27 AM, = Yong Zhu <yong.zhu@ericsson.com> wrote:

Hi Workgroup,

Based on js's feedback, I forward my question = to netconf workgroup.

We got some question = regarding netconf operation=E2=80=99s rpc-reply output.
For = example, we have draft operational model as follows (list AAA contains = list BBB which contains list CCC):
list AAA {
=  key "aaa_name";
 config false;
=  leaf aaa_name {
   type string;
 }
 leaf aaa_leaf1 {
=    type int32;
  }
=   list BBB {
    key = "bbb_name";
    config false;
    leaf bbb_name {
=       type string;
=     }
    leaf = bbb_leaf1 {
      type = uint32;
    }
=     list CCC {
=       key "ccc_name";
=       config false;
=       leaf ccc_name {
=         type string; =     
=       }
=       leaf ccc_leaf1 {
=         type uint32
=       }
=     } //list CCC
 } //list = BBB
} //list AAA

The netconf = <rpc> request is the following:
<rpc>
 <get>
=    <filter type=3D"subtree">
=      <AAA>
=       <BBB>
=        <CCC>
=          <ccc_leaf1/> =  //query on ccc leaf node
=        </CCC>
=       </BBB>
=      </AAA>
=   </filter>
 </get>
</rpc>

What is the = expected ? More specifically, will CCC=E2=80=99s key (leaf ) be included = in rpc-reply? Will AAA/BBB=E2=80=99s key (leaf / ) be included in = rpc-reply?
The following is what I am thinking now. Please = comment.
<rpc-reply>
<data>
 <AAA>
=    <aaa_name>my aaa name</aaa_name>
   <BBB>
=      <bbb_name>my bbb = name</bbb_name>
=      <CCC>
=       <ccc_name>my ccc = name</ccc_name>
=       <ccc_leaf1>my ccc = leaf1</ccc_leaf1>
=      </CCC>
=    </BBB>
 </AAA>
</data>
</rpc-reply>

Thanks
/
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_A91E0662-EF85-41B0-888B-23FBBC674208-- From nobody Thu Jan 28 18:49:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097451B3756 for ; Thu, 28 Jan 2016 18:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgEafjGrXD7k for ; Thu, 28 Jan 2016 18:49:53 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8ED1B3754 for ; Thu, 28 Jan 2016 18:49:52 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 29 Jan 2016 02:49:50 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0396.015; Fri, 29 Jan 2016 02:49:50 +0000 From: Kent Watsen To: Yong Zhu , "Netconf@ietf.org" Thread-Topic: [Netconf] [netconf] Question on the output of rpc-reply for operational model? Thread-Index: AQHRWj+4h1gWInAeS9qQ0MDBq89+1g== Date: Fri, 29 Jan 2016 02:49:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:3PoefU52b2haXVzHXpYLV7khVvJa3J/12bSOpvKgkMMJOk2k6wx26bbBT1nz/AnQH+1Xvz8rhVw9sQ94q1yGELHwsjvOMibA6ZjGb4UjybB8lPIlT41SwzJPIM9TOVmubYSIEaIfKi0mXjihDfIHAw==; 24:rc12ohEzYuCmrqKLla5ZZdp4X9aHzdf5trGsn26bNwXCsUMCNEkxnxrYjhU1BXZ7DppK3KMGionOZNZtc5/QAaBTowh+mwsmo+53X72dftI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: 8df920fc-51a2-44b1-20cf-08d32856dbbf x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 083691450C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(189002)(199003)(5001960100002)(54356999)(15975445007)(3846002)(82746002)(36756003)(2900100001)(11100500001)(1220700001)(102836003)(77096005)(97736004)(107886002)(81156007)(5002640100001)(105586002)(4001350100001)(3280700002)(1096002)(6116002)(50986999)(106116001)(101416001)(5008740100001)(586003)(3470700001)(66066001)(19580395003)(106356001)(33656002)(189998001)(99286002)(87936001)(83716003)(19580405001)(10400500002)(2501003)(5001770100001)(86362001)(5004730100002)(83506001)(2906002)(122556002)(3660700001)(92566002)(40100003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2016 02:49:50.3875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [Netconf] [netconf] Question on the output of rpc-reply for operational model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 02:49:55 -0000 DQpMb29rIGZpbmUgdG8gbWUuDQoNCktlbnQNCg0KDQoNCg0KDQoNCk9uIDEvMjgvMTYsIDI6Mjcg UE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBZb25nIFpodSIgPG5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgeW9uZy56aHVAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkhpIFdv cmtncm91cCwNCj4NCj5CYXNlZCBvbiBqcydzIGZlZWRiYWNrLCBJIGZvcndhcmQgbXkgcXVlc3Rp b24gdG8gbmV0Y29uZiB3b3JrZ3JvdXAuDQo+DQo+V2UgZ290IHNvbWUgcXVlc3Rpb24gcmVnYXJk aW5nIG5ldGNvbmYgb3BlcmF0aW9u4oCZcyBycGMtcmVwbHkgb3V0cHV0Lg0KPkZvciBleGFtcGxl LCB3ZSBoYXZlIGRyYWZ0IG9wZXJhdGlvbmFsIG1vZGVsIGFzIGZvbGxvd3MgKGxpc3QgQUFBIGNv bnRhaW5zIGxpc3QgQkJCIHdoaWNoIGNvbnRhaW5zIGxpc3QgQ0NDKToNCj5saXN0IEFBQSB7DQo+ ICBrZXkgImFhYV9uYW1lIjsNCj4gIGNvbmZpZyBmYWxzZTsNCj4gIGxlYWYgYWFhX25hbWUgew0K PiAgICB0eXBlIHN0cmluZzsNCj4gIH0NCj4gIGxlYWYgYWFhX2xlYWYxIHsNCj4gICAgdHlwZSBp bnQzMjsNCj4gICB9DQo+ICAgbGlzdCBCQkIgeyANCj4gICAgIGtleSAiYmJiX25hbWUiOw0KPiAg ICAgY29uZmlnIGZhbHNlOw0KPiAgICAgbGVhZiBiYmJfbmFtZSB7DQo+ICAgICAgIHR5cGUgc3Ry aW5nOw0KPiAgICAgfQ0KPiAgICAgbGVhZiBiYmJfbGVhZjEgew0KPiAgICAgICB0eXBlIHVpbnQz MjsNCj4gICAgIH0NCj4gICAgIGxpc3QgQ0NDIHsNCj4gICAgICAga2V5ICJjY2NfbmFtZSI7DQo+ ICAgICAgIGNvbmZpZyBmYWxzZTsNCj4gICAgICAgbGVhZiBjY2NfbmFtZSB7DQo+ICAgICAgICAg dHlwZSBzdHJpbmc7ICAgICANCj4gICAgICAgfQ0KPiAgICAgICBsZWFmIGNjY19sZWFmMSB7DQo+ ICAgICAgICAgdHlwZSB1aW50MzINCj4gICAgICAgfQ0KPiAgICAgfSAvL2xpc3QgQ0NDDQo+ICB9 IC8vbGlzdCBCQkINCj59IC8vbGlzdCBBQUENCj4NCj5UaGUgbmV0Y29uZiA8cnBjPiByZXF1ZXN0 IGlzIHRoZSBmb2xsb3dpbmc6DQo+PHJwYz4NCj4gIDxnZXQ+DQo+ICAgIDxmaWx0ZXIgdHlwZT0i c3VidHJlZSI+DQo+ICAgICAgPEFBQT4NCj4gICAgICAgPEJCQj4NCj4gICAgICAgIDxDQ0M+DQo+ ICAgICAgICAgIDxjY2NfbGVhZjEvPiAgLy9xdWVyeSBvbiBjY2MgbGVhZiBub2RlDQo+ICAgICAg ICA8L0NDQz4NCj4gICAgICAgPC9CQkI+DQo+ICAgICAgPC9BQUE+DQo+ICAgPC9maWx0ZXI+DQo+ ICA8L2dldD4NCj48L3JwYz4NCj4NCj5XaGF0IGlzIHRoZSBleHBlY3RlZCA/IE1vcmUgc3BlY2lm aWNhbGx5LCB3aWxsIENDQ+KAmXMga2V5IChsZWFmICkgYmUgaW5jbHVkZWQgaW4gcnBjLXJlcGx5 PyBXaWxsIEFBQS9CQkLigJlzIGtleSAobGVhZiAvICkgYmUgaW5jbHVkZWQgaW4gcnBjLXJlcGx5 Pw0KPlRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJIGFtIHRoaW5raW5nIG5vdy4gUGxlYXNlIGNvbW1l bnQuDQo+PHJwYy1yZXBseT4NCj48ZGF0YT4NCj4gIDxBQUE+DQo+ICAgIDxhYWFfbmFtZT5teSBh YWEgbmFtZTwvYWFhX25hbWU+DQo+ICAgIDxCQkI+DQo+ICAgICAgPGJiYl9uYW1lPm15IGJiYiBu YW1lPC9iYmJfbmFtZT4NCj4gICAgICA8Q0NDPg0KPiAgICAgICA8Y2NjX25hbWU+bXkgY2NjIG5h bWU8L2NjY19uYW1lPg0KPiAgICAgICA8Y2NjX2xlYWYxPm15IGNjYyBsZWFmMTwvY2NjX2xlYWYx Pg0KPiAgICAgIDwvQ0NDPg0KPiAgICA8L0JCQj4NCj4gIDwvQUFBPg0KPjwvZGF0YT4NCj48L3Jw Yy1yZXBseT4NCj4NCj5UaGFua3MNCj4vDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5OZXRjb25mIG1haWxpbmcgbGlzdA0KPk5ldGNvbmZAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Jan 28 22:47:12 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD71A00D5 for ; Thu, 28 Jan 2016 22:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBDGOAIg7TnY for ; Thu, 28 Jan 2016 22:47:07 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id A16DD1A00CC for ; Thu, 28 Jan 2016 22:47:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B3cUR1JHl/bEDm2rIJRo3qSo1QsKDz7qKa+aUjBS0UmFv1khNQtMEhIpackSAfql; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aP2pc-0007cV-Qp for netconf@ietf.org; Fri, 29 Jan 2016 01:46:56 -0500 Received: from 76.254.48.204 by webmail.earthlink.net with HTTP; Fri, 29 Jan 2016 01:46:56 -0500 Message-ID: <8257099.1454050016819.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Thu, 28 Jan 2016 22:46:56 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc72344885faad86667196916a426f8df6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Archived-At: Subject: Re: [Netconf] [netmod] Question on the output of rpc-reply for operational model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 06:47:09 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Jan 28, 2016 10:03 AM >To: Yong Zhu >Cc: "netmod@ietf.org" >Subject: Re: [netmod] Question on the output of rpc-reply for operational model? > >Hi, > >your question is mainly a protocol question and not so much a YANG >question so it probably belongs to NETCONF more than NETMOD. RFC 6241 >in the section describing subtree filtering says: > > o If any sibling nodes of the selection node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output. > >I would expect that sensible implementations implement the MAY and >include sibling key leafs (and that they would do this recursively). As a practial matter, interoperability dictates that clients must *always* be prepared for the possibility that a server might not be "sensible", and will instead omit such sibling key leafs. Randy From nobody Fri Jan 29 00:30:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E401A1A78 for ; Fri, 29 Jan 2016 00:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWjLvLEmO6KH for ; Fri, 29 Jan 2016 00:30:34 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F4E1A1A70 for ; Fri, 29 Jan 2016 00:30:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4ADB6103D; Fri, 29 Jan 2016 09:30:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id X5vQLiavdRTD; Fri, 29 Jan 2016 09:30:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Jan 2016 09:30:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E84920031; Fri, 29 Jan 2016 09:30:30 +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 ZQZrlNO1K61h; Fri, 29 Jan 2016 09:30:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B394620033; Fri, 29 Jan 2016 09:30:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 27AFD39C5E7D; Fri, 29 Jan 2016 09:30:26 +0100 (CET) Date: Fri, 29 Jan 2016 09:30:25 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20160129083025.GA4833@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <8257099.1454050016819.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8257099.1454050016819.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Question on the output of rpc-reply for operational model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 08:30:37 -0000 On Thu, Jan 28, 2016 at 10:46:56PM -0800, Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Jan 28, 2016 10:03 AM > >To: Yong Zhu > >Cc: "netmod@ietf.org" > >Subject: Re: [netmod] Question on the output of rpc-reply for operational model? > > > >Hi, > > > >your question is mainly a protocol question and not so much a YANG > >question so it probably belongs to NETCONF more than NETMOD. RFC 6241 > >in the section describing subtree filtering says: > > > > o If any sibling nodes of the selection node are instance identifier > > components for a conceptual data structure (e.g., list key leaf), > > then they MAY also be included in the filter output. > > > >I would expect that sensible implementations implement the MAY and > >include sibling key leafs (and that they would do this recursively). > > As a practial matter, interoperability dictates that clients > must *always* be prepared for the possibility that a server might > not be "sensible", and will instead omit such sibling key leafs. > Right. So a client better asks explicitly for key leafs to be returned than relying on a MAY behavior. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 29 07:08:24 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC4C1A7022 for ; Fri, 29 Jan 2016 07:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc9p63wyWQOC for ; Fri, 29 Jan 2016 07:08:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84F81A7018 for ; Fri, 29 Jan 2016 07:08:21 -0800 (PST) X-AuditID: c1b4fb2d-f78fe6d00000163a-de-56ab80622769 Received: from ESGSCHC006.ericsson.se (Unknown_Domain [146.11.116.83]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AE.DC.05690.3608BA65; Fri, 29 Jan 2016 16:08:19 +0100 (CET) Received: from ESGSCMB103.ericsson.se ([169.254.3.24]) by ESGSCHC006.ericsson.se ([146.11.116.83]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 23:08:18 +0800 From: Yong Zhu To: Juergen Schoenwaelder , "Randy Presuhn" Thread-Topic: [Netconf] [netmod] Question on the output of rpc-reply for operational model? Thread-Index: AQHRWmDpFEaZrdL7O0ugGt7HL9/HC58Ro7uAgAD00ZA= Date: Fri, 29 Jan 2016 15:08:17 +0000 Message-ID: <31BFEF67CF6AC44BBEDE1890158D737738896D2B@ESGSCMB103.ericsson.se> References: <8257099.1454050016819.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> <20160129083025.GA4833@elstar.local> In-Reply-To: <20160129083025.GA4833@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZxF0SrJvcsDrM4PFpa4urG38yWkzddJvV 4v7CI+wOzB5Llvxk8thwwNPjx4Ye9gDmKC6blNSczLLUIn27BK6MM0srCu7xV2z8+ZW9gfEM TxcjJ4eEgIlE78SbTBC2mMSFe+vZuhi5OIQEDjNKtNx8zwrhLGaUOL90JStIFZuAmsSJy1tZ uhg5OEQEiiTWv/MBCTMLaEqs/fuRGcQWFkiSmPZ6FiOILSKQLHHv0X+ociuJn7OqQMIsAqoS 2+ZsASvhFfCV6On/wQ5iCwnUSHzZ9YsNxOYUMJRYdmMyC4jNCHTb91NrmCBWiUvcejIf6mYB iSV7zjND2KISLx//Y4WwFSQOLFoCVa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRbBaSsbOQ tMxC0jILScsCRpZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIHRdHDLb90djKtfOx5iFOBg VOLhLZi7KkyINbGsuDL3EKMEB7OSCG+d1uowId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwH+ReF CQmkJ5akZqemFqQWwWSZODilGhhrp81+c9GFVXbR9xUbgqzZixc8vV38zencuavvvbb0bCqM qefeq+DksKmuNmNl9LplqYw8/C6686+qOt7OZ3kj9Tqof8KmVJZndio9QUHBeosO3xPY+PJi 0/eqJocENhu/qRo5oisMKjdfOtXe6ce9mbtubtTxdE+l5Wpv+x1mTn8it0X6LYsSS3FGoqEW c1FxIgBvqbxjogIAAA== Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] [netmod] Question on the output of rpc-reply for operational model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:08:24 -0000 Hi Juergen and Randy, Thank for your answer. I am good now. /Yong -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoen= waelder Sent: Friday, January 29, 2016 12:30 AM To: Randy Presuhn Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Question on the output of rpc-reply f= or operational model? On Thu, Jan 28, 2016 at 10:46:56PM -0800, Randy Presuhn wrote: > Hi - >=20 > >From: Juergen Schoenwaelder > >Sent: Jan 28, 2016 10:03 AM > >To: Yong Zhu > >Cc: "netmod@ietf.org" > >Subject: Re: [netmod] Question on the output of rpc-reply for oper= ational model? > > > >Hi, > > > >your question is mainly a protocol question and not so much a YANG=20 > >question so it probably belongs to NETCONF more than NETMOD. RFC 6241=20 > >in the section describing subtree filtering says: > > > > o If any sibling nodes of the selection node are instance identifier > > components for a conceptual data structure (e.g., list key leaf), > > then they MAY also be included in the filter output. > > > >I would expect that sensible implementations implement the MAY and=20 > >include sibling key leafs (and that they would do this recursively). >=20 > As a practial matter, interoperability dictates that clients must=20 > *always* be prepared for the possibility that a server might not be=20 > "sensible", and will instead omit such sibling key leafs. > Right. So a client better asks explicitly for key leafs to be returned than= relying on a MAY behavior. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Jan 29 07:21:53 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D161ACE18 for ; Fri, 29 Jan 2016 07:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xrxo4h-W5sq for ; Fri, 29 Jan 2016 07:21:50 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2702A1ACE17 for ; Fri, 29 Jan 2016 07:21:49 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-a4-56ab838ab742 Received: from ESGSCHC002.ericsson.se (Unknown_Domain [146.11.116.71]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.2F.05041.B838BA65; Fri, 29 Jan 2016 16:21:48 +0100 (CET) Received: from ESGSCMB103.ericsson.se ([169.254.3.24]) by ESGSCHC002.ericsson.se ([146.11.116.71]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 23:21:46 +0800 From: Yong Zhu To: "Netconf@ietf.org" Thread-Topic: Question on filter - is it valid that multiple content match nodes in nested containers Thread-Index: AdFap8Ot36Q1Kvl+TcuewGBb8tchfg== Date: Fri, 29 Jan 2016 15:21:45 +0000 Message-ID: <31BFEF67CF6AC44BBEDE1890158D737738896D59@ESGSCMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyibvEXbeneXWYwcGNHBZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuZnh9kLNrNUXJ53m72BcStzFyMnh4SAicSvW5PZIWwxiQv3 1rN1MXJxCAkcZpRY8m4FI4SzmFHiYvtssA42ATWJE5e3snQxcnCICGhKTHysBxIWFkiSOHf3 GhuILSKQLtG9uxvK1pOYcmQnK4jNIqAqsaH9MdgYXgFfiV/rrzGB2IxAi7+fWgNmMwuIS9x6 Mp8J4iABiSV7zkMdKirx8vE/VghbQeLAoiVQ9ToSC3Z/YoOwtSWWLXwNNV9Q4uTMJywTGIVn IRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGOIHt/y22sF48Lnj IUYBDkYlHt6CuavChFgTy4orcw8xSnAwK4nw1mmtDhPiTUmsrEotyo8vKs1JLT7EKM3BoiTO e5B/UZiQQHpiSWp2ampBahFMlomDU6qBMVl7uX3tBimvb+/vSChe375V5/r5iiKDzYKW9c53 r6nMzqxnv2S3aKH0qaIHf+uc/r/iadKW/BtisjKtsz5dqcn8SUD0hysytloTF1kelFqRmi3x uOXrcusEJmvJTQ/8Z6r8Wzlje1fr3ntbcmNnG1VYHN9qUjRLRMzu4/Unkx/ePlz1ZnbaDyWW 4oxEQy3mouJEAMDDOx5tAgAA Archived-At: Subject: [Netconf] Question on filter - is it valid that multiple content match nodes in nested containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 15:21:51 -0000 Hi Workgroup, I just want to verify the "nested multiple content match nodes" filter is v= alid or not. " o If any containment nodes are present in the sibling set, then they are processed further and included if any nested filter criteria are also met. "=20 >From the above, I think it is valid filter, right? For example: users leaf1 match content user leaf1 match content From nobody Fri Jan 29 09:09:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98A41A887A for ; Fri, 29 Jan 2016 09:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tyc0rDJ6_V0d for ; Fri, 29 Jan 2016 09:09:49 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F231E1A886C for ; Fri, 29 Jan 2016 09:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4B2XD9VM5mgwjDeKBOJlIQlLRYUDpuPYRESuO5+cZ8w=; b=VzMDrCDTuoA+8qS7c9gb99JlRU+fhrJDo1XOgaHEkIy4JImkAgeFrnDGlNru3/+vfJjn/QIfHcWdSKI+surIrnKmB24gFZ3u3Op7mGZJgp8qdo4X5nXLOQ+c9kzvgI7nQAgyJgTAi9t67r+vQwUdwwkUR/3XtnfrhMTiCPHsIww= Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 29 Jan 2016 17:09:29 +0000 Message-ID: <004301d15ab7$64ce1f00$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <016e01d15862$7bb5b400$4001a8c0@gateway.2wire.net> <20160126181522.GA53933@elstar.local> Date: Fri, 29 Jan 2016 17:06:11 +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: [86.185.87.133] X-ClientProxiedBy: DB4PR05CA0013.eurprd05.prod.outlook.com (25.160.40.23) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 2:WZ1jR/tH+tdKymDpxwkFeyA4LiiQ7KARdmNU1XOSQXqG5I0iU4VCi7ok5KGIWhASJsAIAhGk04QWrQSsMMVCeUwPPLD5Lk5M0HNG+vGnQELbnh0hYOPwX1yIB1P41O/d5GrQo9Ax1ZQqOE5lX5OY5Q==; 3:hidUnHKZR1gKcGeZVxCoPS7QPP4Jp8DG7+M0fXe4GXK5nTwlsqcBkVCZ8DpmEijYJPyuUDfODggGT4E21nG6ULFPvRIwOHS1Fo6nd3MxpPsaVaot6V/brFKKS1PVu+TV; 25:NQHE9YtRolKYL/n+pEcy6XLnZvrRBGUVN4CTY2+3zeziBJiKP4MHo/2aDo/0Ltwti+99XVhlEWfV84jxULnJH7vE0f+Yo+d3bgvOrZCSvJp3Z71GDZ05cAGW045okzd4xu+I/kLoieT2PTcymR4ywU8jdd3+5qT4dpGnexziMCrPMqFkdaRx7vEb3hK1NNZy2CI3PEHTkQY+YZ/NZsE69OuYOw4V/WDEmz7BAabgVe1sFW16VoUf8SbwablldsRp; 4:vVNMxjiKq3Vfqoamn/yHjvieHXNcZDHK3XWPM+Huzlw5byThcvHhqtUDE+AbOUljIzvqtLLBYOabxZJxn6tQEw4UjGeTk/dt/b9GaP+UfaGOacLP53jjynjkxZKkootqhjbN3JGmFJuWzVx8Xo0xaL5wC+xxW1bFbo5muofuQC/LeLZKLgOs97YBXYvASr0IXV6viZ22KzZUsCB1U90gTxVQ3eGzYMrE94HjM1Xup0efqXNoAfA+AaTiX3iDgLQyg6ufM4h2ip1FBaNQvJG3ShIG+zLykC39rq+1YN8ju2LWd55lDTkWyL5hmlsEhkt4mu0HSZn0zQiTVm8mhRu6GfRzHoqoaE0cOqK0GagK2Q69M8WilJWyKBtPJExiYfLDe2xkRjwSM8YK3XRwW9fCEby61paa84+4CJWU+SxS/hg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-MS-Office365-Filtering-Correlation-Id: 23049fcf-33b3-436d-a2c2-08d328cef315 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 083691450C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(33646002)(1096002)(110136002)(5001960100002)(586003)(6116002)(3846002)(116806002)(86362001)(122386002)(14496001)(2906002)(47776003)(4326007)(84392002)(50986999)(76176999)(81686999)(40100003)(50226001)(77096005)(15975445007)(44736004)(81816999)(1456003)(5004730100002)(189998001)(1556002)(87976001)(42186005)(66066001)(19580395003)(5008740100001)(19580405001)(23756003)(230700001)(62236002)(44716002)(92566002)(61296003)(50466002)(230783001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB056; 23:9SZVv6N2pNpZWxakTwvtICADKAF+Bfpu51WQMPKt?= =?iso-8859-1?Q?obQ334+ucezlVcwX43fMkgjgQOQ+WqpI+Qctj637ORQIY3poFIoYRpF7F3?= =?iso-8859-1?Q?c1vwXvwQnzBrVDF0AmYIPRzV5udg0/RJVmcUOb0yUVLRXNCaa/5AFZeTWU?= =?iso-8859-1?Q?4vb9V2jrw2rXEgIKLbFQdQwNLHGcRwAku0C5O9C5SuKkurfHGF5yqcEnzD?= =?iso-8859-1?Q?AtcH1ASvDHimCMq6GNW8BFOeajn40s/U169pOe6EYqDyvYk2yq91IE1gYQ?= =?iso-8859-1?Q?56xhAKhuAlDJhHjqiJqIwe6wv5VPqq6c4b16c4hiCklJ+VmIEPBwyVCVGT?= =?iso-8859-1?Q?/UkYcyRxyl7Ofx3K2tXMU14F9rZdYG+GCSfg1fZQ1hjkujSZRVyfju1MhH?= =?iso-8859-1?Q?PPAZ3UtRuZvsJcOvIL04BDQVNsrqf+aDrwnvqT92Jwy2EZ6w9HoXqPL4tA?= =?iso-8859-1?Q?/lFp8JoNMoWyFxSFbyuYdEDv9ho3yjOcrXezrrvOaptTzCyxNr3BssqFdx?= =?iso-8859-1?Q?ZGPCXRUl7SqY/2xba1c4Nf+CNGtRwu/xMKfaIXBQGrEFlr4PJIiBc3fJAJ?= =?iso-8859-1?Q?H7Le1wbv2pqbhyVPa87D7QP0Je5cJ+QQ19LbcJajJLvOBbq9oUGGXT81DG?= =?iso-8859-1?Q?M50r82cRfG9x1VZsSQT19aEQt4j83sVpWb4mq6/tKg3S1QZMOla2E6YuZ1?= =?iso-8859-1?Q?FYl1N/GV0nbtWDu2ZUOn77Rdda4xmQG0Tx4g9kxxNhea6HnAbZu6LvFbiR?= =?iso-8859-1?Q?+AgeydUVGLBpK/qxWJhIkMdfgh8XzjJ1XDdqjvqguonAl4j4wslt/KhhqV?= =?iso-8859-1?Q?BW02EwuTK9wlYciopzCcTSw8RkixGhZMrBQ55j7CG14I7kytdq+SWTeomz?= =?iso-8859-1?Q?YNMhxQ94haMJzb18vTAfWMfrXbulr4EjaS9XUHzC7Y63DaT9z9IHaPVu+/?= =?iso-8859-1?Q?RLS11Ni+tqd/r/JWTd70WzkREbTW5U1Qb4iaKK3zR4GR5ye+Wk84gyyyMD?= =?iso-8859-1?Q?wXv0EUR2wAwM9fGCc6PZLN8HdTGfmf42DA07VL5OgqND9y+it079Xoh91S?= =?iso-8859-1?Q?sdIAaUzR8/eZ7y8QJAx10jajR6M5OvKUatiWabrHd+5pV0VuRMHmsQwFDu?= =?iso-8859-1?Q?pR3V/t/7m3lO3aOz2dRiFFqVVDgcn12AmUaRhFC49Um3c0ZiCwM51aNz7r?= =?iso-8859-1?Q?hJmnBUl1zbfHNwQ5Dzgabp64d99gDueTQwg6kyjtUVjloESZCYsvnDjEev?= =?iso-8859-1?Q?IVvxAUiwP6kB9VA2AnyLprH/Rhz5E5e/qgLb5h4lcDwnxhbbkex1VQg6hD?= =?iso-8859-1?Q?s=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 5:iyBKszBusekmDJT6rDw6TQ6TG7V0KIBwsrPhZqQWc7M6TeB2MUjXLZbXhLpXBdSJbpfSAXT2xNgJAHqJMVUDLoVz0sr3qoN72TxyQny07TATXyq8s8DNEpjxs+jjZE+yMJ+b064HT6nXB6xQPIA6KA==; 24:2iWSui2Kzk2QS4WfLTcG61HVz7QWFkFLQRY3SSY2tlsRoJwO+qu692qpNe7t28ysrj9TbMJtBLYv+j9+1vGqq82Ggnmv0QIbgH8a/D+oXZU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2016 17:09:29.1503 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, overview X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 17:09:55 -0000 I know; if you want to change an I-D, send text! This is what I would like to have seen at the start of the I-D; likely it is slanted towards a reader familiar with NETCONF, but that seems a reasonable assumption to me at this point in time NEW 1.x Relationship with NETVIEW NETVIEW [RFC6241 et al] defines a protocol and associated concepts for the configuration of network devices; RESTCONF, in this document, provides an alternative protocol while reusing many of those concepts. A sound grasp of those concepts is necessary in order to understand this document. While RESTCONF can be used instead of the NETCONF protocol, the two, RESTCONF and NETCONF can also coexist, in a network device or an application or both. NETCONF divides data into configuration data and state data, the former being the writeable data that may be needed to get a device into its running condition, the latter the additional read-only data that is available on a device which is not configuration data, such as status information and collected statistics. Data resides in configuration datastores of which NETCONF defines running, candidate, startup and user-defined datastores along with a capability, :writable-running, which allows changes to be made to the running datastore. While NETCONF allows explicit control over which datastore(s) an operation applies to, with RESTCONF, this is implicit (RESTCONF defines a media type yang.datastore but this refers to top level nodes, not to datastores as defined by NETCONF). If the device supports :writable-running, all edits to configuration nodes are performed in the running datastore. If the device does not support :writable-running but supports candidate, all edits to configuration nodes are performed in the candidate datastore. The candidate is automatically committed to running after a successful edit. Note that this may commit edits that have been performed by means other than RESTCONF. If the device supports neither :writable-running nor candidate, then RESTCONF cannot be used to edit the configuration. If the device supports startup, then any edits that are performed to running are copied to startup upon successful completion of the edits. RESTCONF cannot be used to access user-defined datastores. If the datastore that RESTCONF would edit is locked as a result of actions by another protocol, such as NETCONF, then the edit fails with a 409 (Conflict) error code. RESTCONF does not provide means to lock a datastore. NETCONF requires the underlying protocols to provide confidentiality and authentication and to provide an authenticated user identity; this is equally true of RESTCONF. Where RESTCONF and NETCONF coexist on a device, then it is expected that they share the same set of user identities. While the authentication of a NETCONF server over TLS is restricted to the use of X.509v3 certificates, and the same is true of RESTCONF, RESTCONF is more flexible than NETCONF in the methods available for the authentication of a user; this is discussed in section 2.5. NETCONF offers a number of options for the retrieval of default values [RFC6243] and the behaviour of RESTCONF is aligned with that of NETCONF. A default data node is one which is not present in a datastore and for which the server uses the schema default definition; not all servers use the same criteria to decide if a data node is actually instantiated in a datastore although the behaviour should be consistent between NETCONF and RESTCONF where a device supports both servers. RESTCONF edits are usually applied to one instance at a time, whereas with NETCONF, the number of resources affected by an edit can be considerable in number. Hence NETCONF offers an optional rollback-on-error capability which restores the datastore to its initial state when an error is detected; with RESTCONF, this capability is implicit - if an error is detected, then edits performed so far, if any, are removed. (The server may be unable to perform this rollback in which case, it reports a rollback-failed error, code 500). NETCONF also has the capability to lock a datastore so that a sequence of edits can be treated as atomic. RESTCONF has no such capability but an edit may encounter a datastore locked by NETCONF, or by some other protocol, in which case the edit will fail (code 409). Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Netconf" Sent: Tuesday, January 26, 2016 6:15 PM > On Tue, Jan 26, 2016 at 05:53:21PM +0000, t. petch wrote: > > > > Again, as I have said before, rather than sorting out coexistence, I do > > see a greater need to spell out those parts of NETCONF that are being > > used alongside the restconf protocol to produce a system for operations. > > > > What you are looking for is an architectural document that defines the > basic concepts that tie NETCONF, RESTCONF, YANG, etc together. I see > that such a document is needed and I am happy to invest some of my > time into such a document in the future. That said, I do not think > that we should hold back RESTCONF until such a document has been > written and gone through the consensus process. Hence, we need to find > a reasonable compromise (as we do with other documents at the moment) > but the long term goal should indeed be to create this architectural > document (and future revisions of protocol and language specifications > should then align with it). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Jan 29 12:35:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE76E1B337F for ; Fri, 29 Jan 2016 12:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JitqgwHZqn3s for ; Fri, 29 Jan 2016 12:35:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7585E1B337C for ; Fri, 29 Jan 2016 12:35:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AB0328C1; Fri, 29 Jan 2016 21:35:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dIUuhS2xq9xS; Fri, 29 Jan 2016 21:35:28 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Jan 2016 21:35:28 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05D0120031; Fri, 29 Jan 2016 21:35:28 +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 nZyQIJ4RSbQx; Fri, 29 Jan 2016 21:35:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68F012002C; Fri, 29 Jan 2016 21:35:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5310839D0000; Fri, 29 Jan 2016 21:35:26 +0100 (CET) Date: Fri, 29 Jan 2016 21:35:26 +0100 From: Juergen Schoenwaelder To: Yong Zhu Message-ID: <20160129203526.GA6532@elstar.local> Mail-Followup-To: Yong Zhu , "Netconf@ietf.org" References: <31BFEF67CF6AC44BBEDE1890158D737738896D59@ESGSCMB103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31BFEF67CF6AC44BBEDE1890158D737738896D59@ESGSCMB103.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "Netconf@ietf.org" Subject: Re: [Netconf] Question on filter - is it valid that multiple content match nodes in nested containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 20:35:33 -0000 This is invalid XML. /js On Fri, Jan 29, 2016 at 03:21:45PM +0000, Yong Zhu wrote: > Hi Workgroup, > > I just want to verify the "nested multiple content match nodes" filter is valid or not. > " o If any containment nodes are present in the sibling set, then they > are processed further and included if any nested filter criteria > are also met. > " > >From the above, I think it is valid filter, right? > > For example: > > > > users leaf1 match content > > user leaf1 match content > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Jan 30 19:50:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24081B3F02 for ; Sat, 30 Jan 2016 19:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7D6_ffX3Fjo for ; Sat, 30 Jan 2016 19:50:16 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDD61B3F01 for ; Sat, 30 Jan 2016 19:50:15 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id x4so59558211lbm.0 for ; Sat, 30 Jan 2016 19:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dgijJtwcGI89ZKAdhgiDI54Fysid65PJ4xyPIFOLzWk=; b=ygqH6aB1PBWa7xfRz7TufoIBMTdG+GZnJcKm9AjCVp5xwU0Q0AQDNxSXWcQg0dknbX An/Mzi0cXx9usgSBkq49zPGi3G2syi7d9G3GydGIPURwtxNrcJjGDin/cL/xQ2dq4kDh gYzXnrztbSuadXfqHShzQ4PH4wb1nScW7f2A1y4k7vx7jviH7RnGM9HQ+eY2SJn/9DF7 U25goHcWZTgffqhzVvZBPFFXlbEOUJv2APj2yTQYtBtDWP9ut35CbjfQCO+DTdUhHGxw ORWqSC7lCAYnvVrPDuv8Gn38vvOqZTfUUpYjZt6WRZJ4Wh8nSbb905ZpS0IZyuiAXC1N uKzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dgijJtwcGI89ZKAdhgiDI54Fysid65PJ4xyPIFOLzWk=; b=XohI9ZMH3gATb3cIhr9HTO5mqwN9ESUlmh5rRgY2t51YjztAOG77P9Y5A7vFiDykmj eP/Re1XisqMeTmOTni3rGQUyrDJz4L8QpRshsiQ1R22Ppo+Q+G9Lt1RtGWpWxG/pBJ4w 6kHGE30LWjdaiOvRJvxKaQfxH8QAOqW55pY/3QQlNf0Wx7IjS8GDLr3KU8dd++gAh6gd V/ztv5+NmpYgZZBbhFcJGfTyRhvFp/BMa0CLC1sHKxZQVjEcJgGG/BuAoVNG8J8mgyoO OZO002vMSi5rGSdC0w2J4vtn9PIlh/K5L9VuvyeWl+CGdT3unBaYOUcrXzZWFkY6KJuk oc/A== X-Gm-Message-State: AG10YOQ+WPepcazluQx6YJ0oiam0pacchWMK0r2hcuKzplNtelU5Z2zYuo0/MoEaAQ3FVzWXa/uxdSS2/yPeCA== MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr5909945lbb.66.1454212213552; Sat, 30 Jan 2016 19:50:13 -0800 (PST) Received: by 10.112.200.167 with HTTP; Sat, 30 Jan 2016 19:50:13 -0800 (PST) In-Reply-To: <20160108.122211.286894587579856645.mbj@tail-f.com> References: <20160108085531.GB29486@elstar.local> <20160108.110633.1793241211777947336.mbj@tail-f.com> <20160108103505.GA29774@elstar.local> <20160108.122211.286894587579856645.mbj@tail-f.com> Date: Sat, 30 Jan 2016 19:50:13 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e01161bf46ae5a1052a992a3c Archived-At: Cc: Netconf Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 03:50:20 -0000 --089e01161bf46ae5a1052a992a3c Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 3:22 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > .... > > > > The question really was not about the grouping but more whether > > /modules should be /modules-state but yeah I expected that people > > won't get excited about such a proposal... > > Aha, ok. I don't have a strong opinion on this one. > > We should try to have some naming consistency, so it appears we should reserve /modules for configuration and use /modules-state for reporting. This will be more consistent with /interfaces-state. A more interesting issue is how we might solve module configuration. This may be too proprietary. E.g, our server can load "bundles" or modules and there are other implementation-specific parameters. So the opstate is not a mirror of the config at all. There is a chicken and egg problem, because the server needs to load some modules like ietf-yang-library or ietf-netconf, before it processes config input against those modules. Some module config cannot be part of the running config. It needs to be in a 'bootstrap config'. There is an architectural problem because the library is not allowed to contain modules the server knows about, but are not currently being used at all. A separate /found-modules tree is needed to report the modules available for loading at run-time. It gets really wasteful to have 2 or 3 copies of every module entry. The goal is to support a configuration model like Apache mods-available/mods-enabled. > /martin > Andy --089e01161bf46ae5a1052a992a3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 8, 2016 at 3:22 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Juergen Schoenwaelder <<= a href=3D"mailto:j.schoenwaelder@jacobs-university.de">j.schoenwaelder@jaco= bs-university.de> wrote:
....
>
> The question really was not about the grouping but more whether
> /modules should be /modules-state but yeah I expected that people
> won't get excited about such a proposal...

Aha, ok.=C2=A0 I don't have a strong opinion on this one.



We should try to have some naming con= sistency, so it appears we should
reserve /modules for configurat= ion and use /modules-state for reporting.
This will be more consi= stent with /interfaces-state.

A more interesting i= ssue is how we might solve module configuration.
This may be too = proprietary. E.g, our server can load "bundles" or modules and
there are other implementation-specific parameters. So the opst= ate is not
a mirror of the config at all.

There is a chicken and egg problem, because the server needs to load some= modules
like ietf-yang-library or ietf-netconf, before it proces= ses config input against those modules.
Some module config cannot= be part of the running config. It needs to be in a 'bootstrap config&#= 39;.

There is an architectural problem because the= library is not allowed to contain
modules the server knows about= , but are not currently being used at all.=C2=A0 A separate
/foun= d-modules tree is needed to report the modules available for loading at run= -time.
It gets really wasteful to have 2 or 3 copies of every mod= ule entry.
The goal is to support a configuration model like Apac= he mods-available/mods-enabled.



/martin


<= /div>
Andy

--089e01161bf46ae5a1052a992a3c-- From nobody Sun Jan 31 11:27:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217011B2C22 for ; Sun, 31 Jan 2016 11:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4Chwy1htTrX for ; Sun, 31 Jan 2016 11:27:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C49271B2C20 for ; Sun, 31 Jan 2016 11:27:30 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id D2BFD1AE0285; Sun, 31 Jan 2016 20:27:28 +0100 (CET) Date: Sun, 31 Jan 2016 20:30:02 +0100 (CET) Message-Id: <20160131.203002.839052159543001659.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20160108103505.GA29774@elstar.local> <20160108.122211.286894587579856645.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 19:27:32 -0000 Andy Bierman wrote: > On Fri, Jan 8, 2016 at 3:22 AM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > .... > > > > > > The question really was not about the grouping but more whether > > > /modules should be /modules-state but yeah I expected that people > > > won't get excited about such a proposal... > > > > Aha, ok. I don't have a strong opinion on this one. > > > > > > We should try to have some naming consistency, so it appears we should > reserve /modules for configuration and use /modules-state for reporting. Ok. It makes sense. Are there any objections to changing the top-level container name to "modules-state"? /martin