[netmod] Fwd: Broadband Forum NMDA Questions

[Lou Berger]

FYI - I don't see this yet at https://datatracker.ietf.org/liaison/



 Forwarded Message 
Subject:Broadband Forum NMDA Questions
Date:   Tue, 19 Sep 2017 21:25:21 +
From:   David Sinicrope 
To: Lou Berger , Kent Watsen ,
Benoit Claise 
CC: Michael Fargano, Broadband Forum Technical Committee Chair
, David Sinicrope
, Sven Ooghe, BBF Common YANG Project
Stream Leader, , William Lupton, BBF Common YANG
Project Stream Leader, , Robin Mersh,
Broadband Forum CEO , Gabrielle Bond,
Broadband Forum Secretariat , Statements at
IETF , Liaisons at BBF 



Please find attached a liaison from Broadband Forum to the IETF NETMOD WG.

Please let me know if you have any questions or issues receiving this
liaison.

Please acknowledge successful receipt of the liaison via reply to this
email.

Thank you,

Dave Sinicrope

 



LIAISE-83 - oLS to IETF NETMOD re NMDA (Network Management Datastore Architecture).final.pdf
Description: Adobe PDF document
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02

[Robert Wilton]

I support adoption of this draft.

I have reviewed draft-acee-netmod-rfc8022bis-02, and ask that the 
following comments be considered after the document has been adopted:


1. Does the draft still require a normative reference to 6020? Given 
that the modules are all YANG revision 1.1 perhaps this isn't required 
any more?


2. In appendix D:
i) it would be better if the YANG library example was updated to match 
the model in YANG library bis (e.g. use a modules path rather than 
modules-state).
ii) I think that it should state that this is an example of the data 
that may be received by reading from the operational state datastore.
iii) In the example, the "interface-state" tree output should be merged 
in with "interfaces" so illustrate the combined NMDA view.


3. ipv6 prefix list.
When I had first looked at combining the existing RFC YANG modules to 
NMDA, I came up with a slightly different way of modelling IPv6 
prefixes, splitting "no-advertise-prefix-list" separately from the 
"advertised prefixes".


E.g. if your draft the tree output is:

  +--rw prefix-list
 +--rw prefix* [prefix-spec]
+--rw prefix-spec   inet:ipv6-prefix
+--rw (control-adv-prefixes)?
   +--:(no-advertise)
   |  +--rw no-advertise? empty
   +--:(advertise)
  +--rw valid-lifetime?   uint32
  +--rw on-link-flag? boolean
  +--rw preferred-lifetime?   uint32
  +--rw autonomous-flag?  boolean

Perhaps you could consider this structure instead (I can send you the 
actual YANG if it helps):


   +--rw no-advertise-prefix-list
   |  +--rw prefix* [prefix-spec]
   | +--rw prefix-spec inet:ipv6-prefix
   | +--rw (control-adv-prefixes)?
   |    +--:(no-advertise)
   |   +--rw no-advertise?   empty
   +--rw prefix-list
  +--rw prefix* [prefix-spec]
 +--rw prefix-spec   inet:ipv6-prefix
 +--ro valid-lifetime?   uint32
 +--ro on-link-flag? boolean
 +--ro preferred-lifetime?   uint32
 +--ro autonomous-flag?  boolean

Thanks,
Rob


On 18/09/2017 14:55, Acee Lindem (acee) wrote:

As a co-author,

No, I'm not aware of any IPR that applies to this draft.


Thanks,
Acee

On 9/18/17, 9:48 AM, "Lou Berger"  wrote:


Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




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



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

Re: [netmod] vs

[Robert Wilton]

On 19/09/2017 10:55, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 18/09/2017 19:25, Andy Bierman wrote:


On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund > wrote:

 Juergen Schoenwaelder > wrote:
 > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
 > >
 > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
 > > > I do not agree the architecture should update YANG at all.
 > > OK.
 >
 > I am with Andy here.  has always had the requirement to be
 > valid and we are not supposed to change that. Mechanisms for
 inactive
 > configuration or templating must be designed to be backwards
 compatible
 > I think.

 Ok.  If we keep the requirement that  in itself must be
 valid, it just restricts the usefulness/expressiveness of inactive and
 template mechanisms, but it might be ok.

 I think that even w/o this requirement, the observable behavior for a
 client can be backwards compatible.  For example, suppose we have an
 inactive access control rule that refers to a non-existing
 interface in
 .  If a client that doesn't know anything about inactive asks
 for the contents of , our implementation removes the inactive
 nodes from the reply to the client.  Only a client that opts-in to
 inactive will receive a reply with things that looks invalid if you
 don't take the inactive annotation into account.



There are many ways that validation can fail because inactive nodes
are present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed
to continue to work.

Yes.


Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled
nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These
responses
     include enabled and disabled nodes, so validation does not apply
for 
4) new style  (i.e.  parameter used) can alter
any type of data node

//I think that inactive should always be an optional extension.  Not
everything needs the additional complexity.

Hence rather than tying this function to specific NETCONF operations,
I would suggest that there should be an extra parameter (like for
with-defaults) to allow a client to indicate to the server that a get
or edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during
a get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during
an edit-data request then the request cannot include an extra inactive
meta-data.  The request is processed in a way that is equivalent to an
existing NETCONF implementation, but it may unknowingly remove some
inactive configuration (e.g. via a replace or remove operation on an
inactive node).  Operations like create, delete, none, replace should
all treat an inactive target node the same way as in the node doesn't
exist (e.g. delete on an inactive node would return a "data-missing"
error), this ensures that the behaviour that an unaware client
observes is the same as the existing behaviour that it would expect
from a regular 6241 compliant NETCONF implementation.
4) It a client makes a get request including the "with-inactive"
parameter then they also get the inactive nodes as well, marked with a
meta-data annotation.
5) If a client makes an edit request including the "with-inactive"
parameter, then the inactive meta-data annotation can be used to label
inactive nodes.  Inactive nodes are regarded as regular data nodes for
create/delete/replace/none operation error checking.

I think that this approach is similar (perhaps even the same) as
Martin described.

This is indeed how our implementation works (except I think we don't
do 5; if the client sends an "inactive" attribute it doesn't have to
also send with-inactive).


Note that the YANG MUST rule still applies, because validation is only
done on enabled nodes.
It is only the response message representations that cannot be
validated, not the contents
of  on a server.

So the question is how we can make sure that the text in the NMDA
draft covers this yet-to-be-defined feature w/o having to define it
now?  We thought that the current text was sufficient, but do we have
to make any changes to it?
1) Do we also need to illustrate a similar proof of concept templating 
implementation to show that templating could work whilst keeping running 
valid?  I would prefer that this is just deferred to whichever draft 
defines templating.


2) I think that we need to reach a 

Re: [netmod] Proposal to enhance the YANG tree output

[Juergen Schoenwaelder]

[...]

I prefer that the (schema) tree format is restricted to show the
schema tree.

If a tree format is also needed for data trees, then this really is a
different tree format. It may use a similar base notation but what it
shows is fundamentally different.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Robert Wilton]

On 19/09/2017 15:07, Ladislav Lhotka wrote:

Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:

Hi Lada,


On 19/09/2017 14:37, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not
necessary to carry along the deprecated baggage. If readability is
the primary concern, this is IMO the way to go. Instead of
"ietf-ip-2", I'd suggest something like "ietf- ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue
to be used
in areas where NMDA is an overkill, such as open source home
routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

The new YANG library allows different sets of modules to be available
for  datastores vs .   The operational
datastore can also have different features supported and different
deviations vs the conventional datastores.

OK, I missed the 7895bis draft, sorry. Then there could be differences in
mandatory/optional (e.g. a node is optional in configuration but mandatory in
state data) or the data type of a leaf can differ. How can these be handled?
If the data type of the leaf can differ, then normally this should be 
modeled as two separate leaves.  Do you have a concrete example of this?


If some data is mandatory in config, but not necessarily mandatory in 
 then normally it can be marked as mandatory true, since 
optional is allowed to violate this constraint if necessary, but 
implementations would generally be expected to conform to the constraint 
if possible.


For the reverse case, we can't express that.  I think that you would 
have to leave out the "mandatory: true" constraint.  Again, can you 
provide a concrete example of this please?  That makes it a bit easier 
to reason about.


Thanks,
Rob




Lada


So, the device can make the same deviations to remove the state leaves
from .  Or if they don't want to support the module in
operational at all then a device could just list it as being supported
in the conventional datastores and not .


There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

The new YANG library also supports this:

The "router-id" feature would be disabled for the conventional
datastores, but enabled for .


In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

I think that creating a "-2" versions of these models at this time might
be a mistake.  I actually think that the "deprecate state leaves" ->
"obsolete state leaves" -> "delete state leaves" path is a better choice.

Thanks,
Rob



Lada


/martin







NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
   
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not
support".
If indicating no, please state your reservations with the
document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Proposal to enhance the YANG tree output

[Lou Berger]

On 9/19/2017 9:55 AM, Robert Wilton wrote:
>
> On 19/09/2017 14:47, Martin Bjorklund wrote:
>> Robert Wilton  wrote:
>>> On 19/09/2017 14:28, Lou Berger wrote:
 On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Martin,
>>
>> Speaking as a contributor:
>>
>>
>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
 On 15/09/2017 11:21, Ladislav Lhotka wrote:
> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>> Hi,
>>
>>
>> Actually I liked the early pyang output that was concise and easy to
>> remember.
>> The current format gets very cluttered and there are too many little
>> symbols
>> to remember them all.
> I agree.
>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>> "/".
>>>
>>> "mp" is for a mount point, and it can be generated directly from the
>>> YANG modules.
>>>
>>> Directly under a "mp", "/" and "@" are used to indicate that a node is
>>> mounted
>>> or available through a parent reference, respectively.
>>>
>>> I actually question the usability of "/" and "@".
>> I agree that / and @ are something new, and enabled by schema mount.
>> There have been repeated comments in the RTG WG that there needs to be
>> some way for vendors to convey what they have implemented with Schema
>> mount
> If that's the requirement, using the tree diagram is probably not the
> best way.  The tree diagram is intended to provide an overview of a
> given (set of) YANG module(s).
>
> A perhaps better way to convey the information is to create a file
> with an instantiated /schema-mounts tree.
 using what syntax?  JSON and XML really isn't that easy for the
 (human)
 reader to parse.
>>> Perhaps there needs to be multiple versions of the generated tree
>>> output?
>>>
>>> 1) A normative tree diagram that shows the structure of the model.
>>> 2) A subsequent example that demonstrates what it looks like with the
>>> schema mounted modules.  Within the confines of a text document, the
>>> tree format still seems like a reasonable way to illustrate this, and
>>> I would say it is preferable to the verbosity of JSON or XML.
>>>
>>> I note that RFC 8022 includes an overview tree model in section 4 with
>>> some branches pruned, and then the complete representation in an
>>> appendix, which seems like a pragmatic approach.
>> Sure, but the question is about what special symbols we define.  Do we
>> need the extra symbols "/" and "@", and do we agree on what they mean?
> If we agree that tree style output is OK to illustrate the use of schema 
> mount, then I think that draft-ietf-netmod-yang-tree-diagrams could 
> define them, but indicate that they are only used to illustrate how 
> schema mount is used, and would not be seen in a regular YANG tree 
> diagram illustrating the structure of a YANG module.  

This seems like a reasonable compromise to me, and not a major change to
the draft.

Martin, what do you think?

Lou

> The alternative 
> might be that the RFCs that uses them defines what '/' and '@' mean for 
> that specific example.
>
> As for what the precise definition of '/' and '@' should be, I'm not 
> sure.  I think that you and Lou have a better handle on that ;-)
>
> Thanks,
> Rob
>
>
>>
>> /martin
>

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

Re: [netmod] Proposal to enhance the YANG tree output

[Lou Berger]

On 9/19/2017 9:42 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
>>> Lou Berger  wrote:
 Martin,

 Speaking as a contributor:


 On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
 Hi,


 Actually I liked the early pyang output that was concise and easy to
 remember.
 The current format gets very cluttered and there are too many little
 symbols
 to remember them all.
>>> I agree.
> Me too.  The current draft adds three new magic symbols: "mp" "@" and
> "/".
>
> "mp" is for a mount point, and it can be generated directly from the
> YANG modules.
>
> Directly under a "mp", "/" and "@" are used to indicate that a node is 
> mounted
> or available through a parent reference, respectively.
>
> I actually question the usability of "/" and "@".  
 I agree that / and @ are something new, and enabled by schema mount. 
 There have been repeated comments in the RTG WG that there needs to be
 some way for vendors to convey what they have implemented with Schema
 mount
>>> If that's the requirement, using the tree diagram is probably not the
>>> best way.  The tree diagram is intended to provide an overview of a
>>> given (set of) YANG module(s).
>>>
>>> A perhaps better way to convey the information is to create a file
>>> with an instantiated /schema-mounts tree.
>> using what syntax?  JSON and XML really isn't that easy for the (human)
>> reader to parse.
> Either JSON or XML.
This is fine for code, less so for humans.  We include both in the NI
draft, the tree provides a quick overview, the JSON provides the details. 

>
 and this is one way to help convey (a) what is expected of server
 implementors and (b) what client implementors should expect.

>>>    Hence the
 current draft text:

   In describing the intended use of a module containing a mount point,
    it is helpful to show how the mount point would look with mounted
    modules.

 The whole point of trees is to facilitate understanding for those who
 are less familiar with a model than the authors, and IMO that's the
 paramount perspective in this discussion.
>>> Fully agree!  I would say that we have to make sure that the diagrams
>>> can be understood by people less familiar with the technology than the
>>> authors.  Mixing schema and instance data does not help here.
>> Can you propose an alternative?
> As I have written before, I think the "/" is not needed, so I would
> remove that.  I would also not list the nodes from "parent-references"
> in the same tree ouput.  It is not clear to me that this level of
> detail is needed in the tree, and - as noted before - it isn't even
> correct to list e.g. "interfaces" when the parent-reference in fact
> selects a single interface.
>
>> The routing WG participants seem to
>> find these useful, we can also ask there for broader input if you'd like.
> One approach is to add the union of eveything that some people find
> useful.  In the end we have to look for WG consensus.  Several people
> have said that they prefer a less cluttered format.
In the context of listing enums...

>
> Since a parent
> reference can be very specific, e.g. one specific interface, it isn't
> really accurate to show:
>
>   +--mp vrf-root
>  +--rw rt:routing/
>  |  ...
>  +--ro if:interfaces@
 This is just a conditional and we have precedent on how to handle
 conditional representation.   

> And the trailing "/" on rt:routing doesn't add any information we
> don't already know.  Since vrf-root is a mount point, it follows that
> its children are mounted.
 The issue is a bit more complex when considering some real use cases,
 particularity when parent references and augmentations are used.  For
 example consider the following *without* the use / or @:

 module: ietf-network-instance
   +--rw network-instances
  +--rw network-instance* [name]
     | ...
     +--rw (root-type)
    +--:(vrf-root)
   +--mp vrf-root
  +--ro rt:routing-state
  |  +--ro router-id? yang:dotted-quad
  |  +--ro control-plane-protocols
  | +--ro control-plane-protocol* [type name]
  |    +--ro ospf:ospf
  |   +--ro instance* [af]
  +--rw rt:routing
  |  +--rw router-id? yang:dotted-quad
  |  +--rw 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
> Hi Lada,
> 
> 
> On 19/09/2017 14:37, Ladislav Lhotka wrote:
> > Martin Bjorklund  writes:
> > 
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > I support the adoption but I propose two conceptual changes:
> > > > 
> > > > 1. Introduce a new module name and namespace so that it is not
> > > > necessary to carry along the deprecated baggage. If readability is
> > > > the primary concern, this is IMO the way to go. Instead of
> > > > "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> > > > 
> > > > 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
> > > > to be used
> > > > in areas where NMDA is an overkill, such as open source home
> > > > routers.
> > > 
> > > Why wouldn't NMDA be appropriate in an open source home router?  Note
> > > that the new model really just have a single tree instead of two
> > > trees, so the data that needs to be instrumented is more or less the
> > > same.
> > 
> > It is quite likely that some parts of the data models will be
> > implemented only as configuration but not state data. In the "old style"
> > modules it is easy to add a deviation for the node(s) under -state but
> > in NMDA style this is not possible because we only have one node.
> 
> The new YANG library allows different sets of modules to be available 
> for  datastores vs .   The operational 
> datastore can also have different features supported and different 
> deviations vs the conventional datastores.

OK, I missed the 7895bis draft, sorry. Then there could be differences in
mandatory/optional (e.g. a node is optional in configuration but mandatory in
state data) or the data type of a leaf can differ. How can these be handled?

Lada 

> 
> So, the device can make the same deviations to remove the state leaves 
> from .  Or if they don't want to support the module in 
> operational at all then a device could just list it as being supported 
> in the conventional datastores and not .
> 
> > 
> > There are subtle differences in the schemas for configuration and state
> > data that the NMDA concept doesn't address. If you want another example,
> > ietf-routing-2 has the "router-id" leaf that is conditional via the
> > "router-id" feature. If this feature is not supported, router-id cannot
> > be explicitly configured (it is assigned by the system) but in state data
> > "router-id" needs IMO be present in any case. But the if-feature
> > isn't able to differentiate between configuration and state data if
> > there is only one node for both.
> 
> The new YANG library also supports this:
> 
> The "router-id" feature would be disabled for the conventional 
> datastores, but enabled for .
> 
> > 
> > > In fact, if we claim that the new architecture is not appropriate for
> > > some devices I think we have failed, especially if the conclusion is
> > > that we need to maintain two versions of all modules going forward.
> > 
> > I am not asking for this but, on the other hand, if NMDA versions used a new
> > module name and namespace (my item #1, which is what ietf-routing-2
> > does), then I don't see any pressing need for obsoleting the old style
> > modules.
> 
> I think that creating a "-2" versions of these models at this time might 
> be a mistake.  I actually think that the "deprecate state leaves" -> 
> "obsolete state leaves" -> "delete state leaves" path is a better choice.
> 
> Thanks,
> Rob
> 
> 
> > 
> > Lada
> > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > NMDA
> > > > implementors should be aware of the new modules but there is no need to
> > > > eradicate the old data models.
> > > > 
> > > > #2 applies also to other modules for which the NMDA version is underway.
> > > > 
> > > > Lada
> > > > 
> > > > PS. The subject is wrong, it shoud be -rfc7277bis-
> > > >   
> > > > Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > > > > All,
> > > > > 
> > > > > This is start of a two week poll on making
> > > > > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > > > > send email to the list indicating "yes/support" or "no/do not
> > > > > support".
> > > > > If indicating no, please state your reservations with the
> > > > > document.  If
> > > > > yes, please also feel free to provide comments you'd like to see
> > > > > addressed once the document is a WG document.
> > > > > 
> > > > > The poll ends Oct 2.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Lou (and Kent)
> > > > > 
> > > > > ___
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> 
> 

Re: [netmod] Proposal to enhance the YANG tree output

[Robert Wilton]

On 19/09/2017 14:47, Martin Bjorklund wrote:

Robert Wilton  wrote:


On 19/09/2017 14:28, Lou Berger wrote:

On 9/19/2017 7:29 AM, Martin Bjorklund wrote:

Lou Berger  wrote:

Martin,

Speaking as a contributor:


On 9/15/2017 7:40 AM, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 15/09/2017 11:21, Ladislav Lhotka wrote:

Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:

Hi,


Actually I liked the early pyang output that was concise and easy to
remember.
The current format gets very cluttered and there are too many little
symbols
to remember them all.

I agree.

Me too.  The current draft adds three new magic symbols: "mp" "@" and
"/".

"mp" is for a mount point, and it can be generated directly from the
YANG modules.

Directly under a "mp", "/" and "@" are used to indicate that a node is
mounted
or available through a parent reference, respectively.

I actually question the usability of "/" and "@".

I agree that / and @ are something new, and enabled by schema mount.
There have been repeated comments in the RTG WG that there needs to be
some way for vendors to convey what they have implemented with Schema
mount

If that's the requirement, using the tree diagram is probably not the
best way.  The tree diagram is intended to provide an overview of a
given (set of) YANG module(s).

A perhaps better way to convey the information is to create a file
with an instantiated /schema-mounts tree.

using what syntax?  JSON and XML really isn't that easy for the
(human)
reader to parse.

Perhaps there needs to be multiple versions of the generated tree
output?

1) A normative tree diagram that shows the structure of the model.
2) A subsequent example that demonstrates what it looks like with the
schema mounted modules.  Within the confines of a text document, the
tree format still seems like a reasonable way to illustrate this, and
I would say it is preferable to the verbosity of JSON or XML.

I note that RFC 8022 includes an overview tree model in section 4 with
some branches pruned, and then the complete representation in an
appendix, which seems like a pragmatic approach.

Sure, but the question is about what special symbols we define.  Do we
need the extra symbols "/" and "@", and do we agree on what they mean?
If we agree that tree style output is OK to illustrate the use of schema 
mount, then I think that draft-ietf-netmod-yang-tree-diagrams could 
define them, but indicate that they are only used to illustrate how 
schema mount is used, and would not be seen in a regular YANG tree 
diagram illustrating the structure of a YANG module.  The alternative 
might be that the RFCs that uses them defines what '/' and '@' mean for 
that specific example.


As for what the precise definition of '/' and '@' should be, I'm not 
sure.  I think that you and Lou have a better handle on that ;-)


Thanks,
Rob





/martin


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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Robert Wilton]

Hi Lada,


On 19/09/2017 14:37, Ladislav Lhotka wrote:

Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not
necessary to carry along the deprecated baggage. If readability is
the primary concern, this is IMO the way to go. Instead of
"ietf-ip-2", I'd suggest something like "ietf- ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue
to be used
in areas where NMDA is an overkill, such as open source home
routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.
The new YANG library allows different sets of modules to be available 
for  datastores vs .   The operational 
datastore can also have different features supported and different 
deviations vs the conventional datastores.


So, the device can make the same deviations to remove the state leaves 
from .  Or if they don't want to support the module in 
operational at all then a device could just list it as being supported 
in the conventional datastores and not .




There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

The new YANG library also supports this:

The "router-id" feature would be disabled for the conventional 
datastores, but enabled for .





In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.
I think that creating a "-2" versions of these models at this time might 
be a mistake.  I actually think that the "deprecate state leaves" -> 
"obsolete state leaves" -> "delete state leaves" path is a better choice.


Thanks,
Rob




Lada



/martin







NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
  
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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


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

Re: [netmod] Proposal to enhance the YANG tree output

[Robert Wilton]

On 19/09/2017 14:28, Lou Berger wrote:


On 9/19/2017 7:29 AM, Martin Bjorklund wrote:

Lou Berger  wrote:

Martin,

Speaking as a contributor:


On 9/15/2017 7:40 AM, Martin Bjorklund wrote:

Robert Wilton  wrote:

On 15/09/2017 11:21, Ladislav Lhotka wrote:

Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:

Hi,


Actually I liked the early pyang output that was concise and easy to
remember.
The current format gets very cluttered and there are too many little
symbols
to remember them all.

I agree.

Me too.  The current draft adds three new magic symbols: "mp" "@" and
"/".

"mp" is for a mount point, and it can be generated directly from the
YANG modules.

Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
or available through a parent reference, respectively.

I actually question the usability of "/" and "@".

I agree that / and @ are something new, and enabled by schema mount.
There have been repeated comments in the RTG WG that there needs to be
some way for vendors to convey what they have implemented with Schema
mount

If that's the requirement, using the tree diagram is probably not the
best way.  The tree diagram is intended to provide an overview of a
given (set of) YANG module(s).

A perhaps better way to convey the information is to create a file
with an instantiated /schema-mounts tree.

using what syntax?  JSON and XML really isn't that easy for the (human)
reader to parse.

Perhaps there needs to be multiple versions of the generated tree output?

1) A normative tree diagram that shows the structure of the model.
2) A subsequent example that demonstrates what it looks like with the 
schema mounted modules.  Within the confines of a text document, the 
tree format still seems like a reasonable way to illustrate this, and I 
would say it is preferable to the verbosity of JSON or XML.


I note that RFC 8022 includes an overview tree model in section 4 with 
some branches pruned, and then the complete representation in an 
appendix, which seems like a pragmatic approach.


Thanks,
Rob

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi,
>> 
>> I support the adoption but I propose two conceptual changes:
>> 
>> 1. Introduce a new module name and namespace so that it is not
>> necessary to carry along the deprecated baggage. If readability is
>> the primary concern, this is IMO the way to go. Instead of
>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>> 
>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>> to be used 
>> in areas where NMDA is an overkill, such as open source home
>> routers.
>
> Why wouldn't NMDA be appropriate in an open source home router?  Note
> that the new model really just have a single tree instead of two
> trees, so the data that needs to be instrumented is more or less the
> same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

>
> In fact, if we claim that the new architecture is not appropriate for
> some devices I think we have failed, especially if the conclusion is
> that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

Lada

>
>
> /martin
>
>
>
>
>
>
>> NMDA
>> implementors should be aware of the new modules but there is no need to
>> eradicate the old data models.
>> 
>> #2 applies also to other modules for which the NMDA version is underway.
>> 
>> Lada
>> 
>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>  
>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>> > All,
>> > 
>> > This is start of a two week poll on making
>> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>> > send email to the list indicating "yes/support" or "no/do not support".
>> > If indicating no, please state your reservations with the document.  If
>> > yes, please also feel free to provide comments you'd like to see
>> > addressed once the document is a WG document.
>> > 
>> > The poll ends Oct 2.
>> > 
>> > Thanks,
>> > 
>> > Lou (and Kent)
>> > 
>> > ___
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Proposal to enhance the YANG tree output

[Lou Berger]

On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Martin,
>>
>> Speaking as a contributor:
>>
>>
>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
 On 15/09/2017 11:21, Ladislav Lhotka wrote:
> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>> Hi,
>>
>>
>> Actually I liked the early pyang output that was concise and easy to
>> remember.
>> The current format gets very cluttered and there are too many little
>> symbols
>> to remember them all.
> I agree.
>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>> "/".
>>>
>>> "mp" is for a mount point, and it can be generated directly from the
>>> YANG modules.
>>>
>>> Directly under a "mp", "/" and "@" are used to indicate that a node is 
>>> mounted
>>> or available through a parent reference, respectively.
>>>
>>> I actually question the usability of "/" and "@".  
>> I agree that / and @ are something new, and enabled by schema mount. 
>> There have been repeated comments in the RTG WG that there needs to be
>> some way for vendors to convey what they have implemented with Schema
>> mount
> If that's the requirement, using the tree diagram is probably not the
> best way.  The tree diagram is intended to provide an overview of a
> given (set of) YANG module(s).
>
> A perhaps better way to convey the information is to create a file
> with an instantiated /schema-mounts tree.
using what syntax?  JSON and XML really isn't that easy for the (human)
reader to parse.

>
>> and this is one way to help convey (a) what is expected of server
>> implementors and (b) what client implementors should expect.
>>
>    Hence the
>> current draft text:
>>
>>   In describing the intended use of a module containing a mount point,
>>    it is helpful to show how the mount point would look with mounted
>>    modules.
>>
>> The whole point of trees is to facilitate understanding for those who
>> are less familiar with a model than the authors, and IMO that's the
>> paramount perspective in this discussion.
> Fully agree!  I would say that we have to make sure that the diagrams
> can be understood by people less familiar with the technology than the
> authors.  Mixing schema and instance data does not help here.

Can you propose an alternative?  The routing WG participants seem to
find these useful, we can also ask there for broader input if you'd like.

>>> Since a parent
>>> reference can be very specific, e.g. one specific interface, it isn't
>>> really accurate to show:
>>>
>>>   +--mp vrf-root
>>>  +--rw rt:routing/
>>>  |  ...
>>>  +--ro if:interfaces@
>> This is just a conditional and we have precedent on how to handle
>> conditional representation.   
>>
>>> And the trailing "/" on rt:routing doesn't add any information we
>>> don't already know.  Since vrf-root is a mount point, it follows that
>>> its children are mounted.
>> The issue is a bit more complex when considering some real use cases,
>> particularity when parent references and augmentations are used.  For
>> example consider the following *without* the use / or @:
>>
>> module: ietf-network-instance
>>   +--rw network-instances
>>  +--rw network-instance* [name]
>>     | ...
>>     +--rw (root-type)
>>    +--:(vrf-root)
>>   +--mp vrf-root
>>  +--ro rt:routing-state
>>  |  +--ro router-id? yang:dotted-quad
>>  |  +--ro control-plane-protocols
>>  | +--ro control-plane-protocol* [type name]
>>  |    +--ro ospf:ospf
>>  |   +--ro instance* [af]
>>  +--rw rt:routing
>>  |  +--rw router-id? yang:dotted-quad
>>  |  +--rw control-plane-protocols
>>  | +--rw control-plane-protocol* [type name]
>>  | +--rw ospf:ospf
>>  |    +--rw instance* [af]
>>  |   +--rw areas
>>  |  +--rw area* [area-id]
>>  | +--rw interfaces
>>  |    +--rw interface* [name]
>>  |   +--rw name if:interface-ref
>>  |   +--rw cost?   uint16
>>  +--ro if:interfaces
>>  |  ...
>>  +--ro if:interfaces-state
>>  |  ...
>>
>>
>> It's certainly not too hard to spot the top level mounts, but it is
>> impossible to distinguish the parent references from the actual mounts. 
> My proposal would be to not even show the parent references in the
> diagram.  If we do that, the '/' is not needed.
>
>> Further more, some mounts are hard to spot.  For example, notice ospf. 
>> Did you notice that it's a mount?
> 

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Juergen Schoenwaelder]

I believe that starting a new model would cause a real pain since any
model augmentations now need to augment two differnet versions of the
IP model. (Actually any model references may cause extra work.)

I also believe that view that NMDA is for big gear but not for small
gear is not quite right. Differences between operational state and
config state exists in almost all systems I have seen. The /foo and
/foo-state approach came out of long discussions about how to model
interfaces (Lada should recall this) and it was kind of clear even
back then that /foo and /foo-state was just a 'hack', given the
specifications we had to work with. NMDA simplifies models and we
would be failing badly if we now start maintaining multiple versions
of models.

/js

On Tue, Sep 19, 2017 at 11:46:57AM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> I support the adoption but I propose two conceptual changes:
> 
> 1. Introduce a new module name and namespace so that it is not necessary to
> carry along the deprecated baggage. If readability is the primary concern, 
> this
> is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like 
> "ietf-
> ip-nmda".
> 
> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be 
> used
> in areas where NMDA is an overkill, such as open source home routers. NMDA
> implementors should be aware of the new modules but there is no need to
> eradicate the old data models.
> 
> #2 applies also to other modules for which the NMDA version is underway.
> 
> Lada
> 
> PS. The subject is wrong, it shoud be -rfc7277bis-
>  
> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > All,
> > 
> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.  If
> > yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> > 
> > The poll ends Oct 2.
> > 
> > Thanks,
> > 
> > Lou (and Kent)
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates

[t.petch]

- Original Message -
From: "Martin Bjorklund" 
Sent: Monday, September 18, 2017 8:58 AM


> "t.petch"  wrote:
> > - Original Message -
> > From: "Martin Bjorklund" 
> > Sent: Sunday, September 17, 2017 2:41 PM
> >
> > > Andy Bierman  wrote:
> > > > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I strongly agree with Tom that the current draft is an
update to
> > RFC
> > > > > 7950.
> > > > > > I also strongly disagree with the decision to omit RFC 2119
in a
> > > > > standards
> > > > > > track document. IMO RFC 2119 terms need to be used in
normative
> > text,
> > > > > > especially when dealing with XPath and YANG compiler
behavior.
> > > > > >
> > > > >
> > > > > RFC 8174:
> > > > >
> > > > >o  These words can be used as defined here, but using them
is
> > not
> > > > >   required.  Specifically, normative text does not require
the
> > use
> > > > >   of these key words.  They are used for clarity and
> > consistency
> > > > >   when that is what's wanted, but a lot of normative text
does
> > not
> > > > >   use them and is still normative.
> > > > >
> > > > >
> > > > So what?
> > > > Existing YANG specifications use RFC 2119 terms.
> > > > This draft uses those terms, just with lower-case.
> > >
> > > Actually, section 5.1 XPath Context in the revised datastore draft
> > > uses the same language as section 6.4.1 XPath Context in RFC 7950.
In
> > > fact, the text in the draft is copied (and adjusted) from RFC
7950.
> >
> > Martin
> >
> > 'Adjusted' might be seen as a weasel word:-)
> >
> >If the XPath expression is defined in a substatement to a
> >   "notification" statement, the accessible tree is the
notification
> >   instance, all state data in the server, and the running
> >   configuration datastore.
> >
> > becomes
> >
> > If the XPath expression is defined in a substatement to a
> >   "notification" statement, the accessible tree is the
notification
> >   instance and all operational state in the server.
> >
> > Goodbye  (well, running configuration in RFC7950).  Is it a
> > material difference? - it will take me a while to work that one out.
>
> The difference is that the xpath expressions no longer sees unused
> configuration in running.  But if the config is used, it exists in
>  under the same path as before, and it is available.
>
> > I focussed on the XPath rules because they seemed the clearest case,
but
> > updating the definitions, and saying this section will replace the
> > definitions in [RFC6241] and [RFC7950] when these documents are
revised
> > seems  well, like an Erratum held for Update i.e. another
Updates.
>
> Are you saying that this is an argument for having "Updates: 7950"?

Yes

Tom Petch

>
> /martin

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

Re: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00

[Acee Lindem (acee)]

I support WG adoption.
Thanks,
Acee

On 9/18/17, 3:47 PM, "netmod on behalf of Lou Berger"
 wrote:

>The draft being polled in this thread is
>draft-bjorklund-netmod-rfc7277bis-00
>
>Lou
>
>On 9/18/2017 3:15 PM, Lou Berger wrote:
>> All,
>>
>> This is start of a two week poll on making
>> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>> send email to the list indicating "yes/support" or "no/do not support".
>> If indicating no, please state your reservations with the document.  If
>> yes, please also feel free to provide comments you'd like to see
>> addressed once the document is a WG document.
>>
>> The poll ends Oct 2.
>>
>> Thanks,
>>
>> Lou (and Kent)
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> I support the adoption but I propose two conceptual changes:
> 
> 1. Introduce a new module name and namespace so that it is not
> necessary to carry along the deprecated baggage. If readability is
> the primary concern, this is IMO the way to go. Instead of
> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> 
> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
> to be used 
> in areas where NMDA is an overkill, such as open source home
> routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.


/martin






> NMDA
> implementors should be aware of the new modules but there is no need to
> eradicate the old data models.
> 
> #2 applies also to other modules for which the NMDA version is underway.
> 
> Lada
> 
> PS. The subject is wrong, it shoud be -rfc7277bis-
>  
> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > All,
> > 
> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.  If
> > yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> > 
> > The poll ends Oct 2.
> > 
> > Thanks,
> > 
> > Lou (and Kent)
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] vs

[Martin Bjorklund]

Robert Wilton  wrote:
> 
> 
> On 18/09/2017 19:25, Andy Bierman wrote:
> >
> >
> > On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund  > > wrote:
> >
> > Juergen Schoenwaelder  > > wrote:
> > > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> > > >
> > > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > > > I do not agree the architecture should update YANG at all.
> > > > OK.
> > >
> > > I am with Andy here.  has always had the requirement to be
> > > valid and we are not supposed to change that. Mechanisms for
> > inactive
> > > configuration or templating must be designed to be backwards
> > compatible
> > > I think.
> >
> > Ok.  If we keep the requirement that  in itself must be
> > valid, it just restricts the usefulness/expressiveness of inactive and
> > template mechanisms, but it might be ok.
> >
> > I think that even w/o this requirement, the observable behavior for a
> > client can be backwards compatible.  For example, suppose we have an
> > inactive access control rule that refers to a non-existing
> > interface in
> > .  If a client that doesn't know anything about inactive asks
> > for the contents of , our implementation removes the inactive
> > nodes from the reply to the client.  Only a client that opts-in to
> > inactive will receive a reply with things that looks invalid if you
> > don't take the inactive annotation into account.
> >
> >
> >
> > There are many ways that validation can fail because inactive nodes
> > are present,
> > and considered part of the validation.
> >
> > e,g, min-elements, max-elements, mandatory, unique.
> >
> > I think we all agree that validation on the enabled nodes is supposed
> > to continue to work.

Yes.

> > Here is an attempt at a backwards-compatible solution:
> >
> > 1) current  and  responses only include enabled
> > nodes.
> > 2) old-style  operations do not alter inactive nodes
> > 3) NMDA clients use , not  or .  These
> > responses
> >     include enabled and disabled nodes, so validation does not apply
> > for 
> > 4) new style  (i.e.  parameter used) can alter
> > any type of data node
> //I think that inactive should always be an optional extension.  Not
> everything needs the additional complexity.
> 
> Hence rather than tying this function to specific NETCONF operations,
> I would suggest that there should be an extra parameter (like for
> with-defaults) to allow a client to indicate to the server that a get
> or edit request is using the "with-inactive" extension.
> 1) The server should also have a capability (or perhaps a leaf defined
> in YANG library) to indicate that it supports inactive configuration.
> 2) If a client doesn't use the extra "with-inactive" parameter during
> a get request then only active nodes are returned.
> 3) If a client doesn't use the extra "with-inactive" parameter during
> an edit-data request then the request cannot include an extra inactive
> meta-data.  The request is processed in a way that is equivalent to an
> existing NETCONF implementation, but it may unknowingly remove some
> inactive configuration (e.g. via a replace or remove operation on an
> inactive node).  Operations like create, delete, none, replace should
> all treat an inactive target node the same way as in the node doesn't
> exist (e.g. delete on an inactive node would return a "data-missing"
> error), this ensures that the behaviour that an unaware client
> observes is the same as the existing behaviour that it would expect
> from a regular 6241 compliant NETCONF implementation.
> 4) It a client makes a get request including the "with-inactive"
> parameter then they also get the inactive nodes as well, marked with a
> meta-data annotation.
> 5) If a client makes an edit request including the "with-inactive"
> parameter, then the inactive meta-data annotation can be used to label
> inactive nodes.  Inactive nodes are regarded as regular data nodes for
> create/delete/replace/none operation error checking.
> 
> I think that this approach is similar (perhaps even the same) as
> Martin described.

This is indeed how our implementation works (except I think we don't
do 5; if the client sends an "inactive" attribute it doesn't have to
also send with-inactive).

> > Note that the YANG MUST rule still applies, because validation is only
> > done on enabled nodes.
> > It is only the response message representations that cannot be
> > validated, not the contents
> > of  on a server.

So the question is how we can make sure that the text in the NMDA
draft covers this yet-to-be-defined feature w/o having to define it
now?  We thought that the current text was sufficient, but do we have
to make any changes to it?


/martin

___

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00

[Ladislav Lhotka]

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not necessary to
carry along the deprecated baggage. If readability is the primary concern, this
is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like "ietf-
ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be used
in areas where NMDA is an overkill, such as open source home routers. NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
 
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> All,
> 
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
> 
> The poll ends Oct 2.
> 
> Thanks,
> 
> Lou (and Kent)
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] vs

[Robert Wilton]

On 18/09/2017 19:25, Andy Bierman wrote:



On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund > wrote:


Juergen Schoenwaelder > wrote:
> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >
> > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
>
> I am with Andy here.  has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for
inactive
> configuration or templating must be designed to be backwards
compatible
> I think.

Ok.  If we keep the requirement that  in itself must be
valid, it just restricts the usefulness/expressiveness of inactive and
template mechanisms, but it might be ok.

I think that even w/o this requirement, the observable behavior for a
client can be backwards compatible.  For example, suppose we have an
inactive access control rule that refers to a non-existing
interface in
.  If a client that doesn't know anything about inactive asks
for the contents of , our implementation removes the inactive
nodes from the reply to the client.  Only a client that opts-in to
inactive will receive a reply with things that looks invalid if you
don't take the inactive annotation into account.



There are many ways that validation can fail because inactive nodes 
are present,

and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed 
to continue to work.


Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These 
responses
    include enabled and disabled nodes, so validation does not apply 
for 
4) new style  (i.e.  parameter used) can alter 
any type of data node
//I think that inactive should always be an optional extension.  Not 
everything needs the additional complexity.


Hence rather than tying this function to specific NETCONF operations, I 
would suggest that there should be an extra parameter (like for 
with-defaults) to allow a client to indicate to the server that a get or 
edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined 
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during a 
get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during an 
edit-data request then the request cannot include an extra inactive 
meta-data.  The request is processed in a way that is equivalent to an 
existing NETCONF implementation, but it may unknowingly remove some 
inactive configuration (e.g. via a replace or remove operation on an 
inactive node).  Operations like create, delete, none, replace should 
all treat an inactive target node the same way as in the node doesn't 
exist (e.g. delete on an inactive node would return a "data-missing" 
error), this ensures that the behaviour that an unaware client observes 
is the same as the existing behaviour that it would expect from a 
regular 6241 compliant NETCONF implementation.
4) It a client makes a get request including the "with-inactive" 
parameter then they also get the inactive nodes as well, marked with a 
meta-data annotation.
5) If a client makes an edit request including the "with-inactive" 
parameter, then the inactive meta-data annotation can be used to label 
inactive nodes.  Inactive nodes are regarded as regular data nodes for 
create/delete/replace/none operation error checking.


I think that this approach is similar (perhaps even the same) as Martin 
described.


Thanks,
Rob




Note that the YANG MUST rule still applies, because validation is only 
done on enabled nodes.
It is only the response message representations that cannot be 
validated, not the contents

of  on a server.



/martin


Andy



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

Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)

[Robert Wilton]

Support.

I have reviewed this document.

Thanks,
Rob


On 18/09/2017 19:29, Lou Berger wrote:

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7223bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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



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

Re: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00

[Robert Wilton]

support.

I have reviewed this document.

Thanks,
Rob


On 18/09/2017 20:47, Lou Berger wrote:

The draft being polled in this thread is
draft-bjorklund-netmod-rfc7277bis-00

Lou

On 9/18/2017 3:15 PM, Lou Berger wrote:

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)

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


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



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