Re: [netmod] tree diagram guidelines

[Andy Bierman]

Hi,

These changes are OK with me.



Andy


On Thu, Dec 7, 2017 at 3:38 PM, Lou Berger  wrote:

> Hi,
>
> Following up on this discussion (and hoping to wrap it up):
>
> I have created two  wikis off of
> https://trac.ietf.org/trac/netmod/wiki/WikiStart, one for 6087bis
> content and the other for section 3 of tree diagrams.  I also propose
> the following changes to the tree-diagrams draft:
>
> To section 3 intro, add:
> For the most current quidelines being developed, please see the IETF
> NetMod Working
>Group Wiki, see:  https://trac.ietf.org/trac/netmod/wiki/WikiStart
>
> Add :
>   3.2.  Groupings
>
>If the YANG module is comprised of groupings only, then the tree
>diagram should contain the groupings.  The 'pyang' compiler can be
>used to produce a tree diagram with groupings using the "-f tree --
>tree-print-groupings" command line parameters.
>
> And to section 3.3, start with:
>
>Tree diagrams can be split into sections to correspond to document
>structure.
>
> For 6087 bis, I think section 3.4 gets replaced with something like.
>
> YANG tree diagrams provide a concise representation of a YANG module,
>and SHOULD be included to help readers understand YANG module
> structure.  Guidelines on tree diagrams can be found in Section 3 of
> [I-D.ietf-netmod-yang-tree-diagrams].
>
> These changes can be found at:
> https://github.com/netmod-wg/yang-tree-diagrams/commit/
> 53919e0a4549c285758eb5aaaf02cf980269afff
>
> This leaves the intended status as the key open issue on the draft.
>
> Lou
>
>
> On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:
> > I am confused. I think there was some consensus to
> >
> > - include all tree related guidelines in the tree document, remove all
> tree
> >   related guidelines from 6087bis and have 6087bis point to the tree
> document
> >   (which it already does)
> >
> > The rest is pointless since AFAIK there is no wiki guidelines pages to
> > point to and there is AFAIK nobody in place to actually maintain such
> > a wiki page. Perhaps a wiki is the future but until future has
> > arrived, we should not point to it.
> >
> > The other proposal I heard was to have a landing page that points to
> > the current guideline work which points to the relevant documents. A
> > wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not
> > affect the documents.
> >
> > /js
> >
> > PS: I am happy to add pointers to guidelines as a section to the
> > wikipedia page.
> >
> > On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
> >> To circle back to this.  My sense of this discussion (as contributor) is
> >> (a) the tree diagrams draft should be updated to point to a "guidelines"
> >> wiki page for "the most current guidelines"
> >> (b) the tree diagrams draft should be updated to include a full set of
> the
> >> current tree related guidelines
> >> (c) 6087bis should be updated to point to a "guidelines" wiki page for
> "the
> >> most current guidelines"
> >> (d) 6087bis should have it's tree guidelines point to the tree diagrams
> >> document -- in addition to pointing to the wiki
> >>
> >> Does this sound right?
> >>
> >> Lou
> >> (as tree co-author)
> >>
> >> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
> >>> The Wiki is useful as a starting point providing a collection of
> pointers to guideline RFCs and the bis-revisions in development.
> >>>
> >>> Cheers,
> >>> Mehmet
> >>>
>  -Original Message-
>  From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Mahesh
>  Jethanandani
>  Sent: Thursday, November 16, 2017 7:39 AM
>  To: Robert Wilton 
>  Cc: netmod@ietf.org
>  Subject: Re: [netmod] tree diagram guidelines
> 
>  Other SDOs can and follow the work in IETF through the RFCs we
> publish.
>  They do not follow wiki’s, unless the document itself says, “here are
> the
>  guidelines, but if you are looking for the latest, go to this wiki”.
> I therefore
>  would support the proposal outlined below. It gives the SDO a stable
> point of
>  reference with a document, which gets updated occasionally, but also
> allows
>  them to peak at what is coming down the pipeline.
> 
>  Thanks.
> 
> > On Nov 15, 2017, at 6:53 PM, Robert Wilton 
> wrote:
> >
> > I liked the suggestion from Chris Hopps:
> >
> > I think that it was along the lines of ...
> >
> > The RFC contains a reference at the top that states that updates to
> the
>  guidelines is available on a wiki at 
> > Every few years the guidelines on the wiki can be folded into a
> latest
>  version of the guidelines draft.
> > 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,,
> IEEE, or MEF be
>  using the latest draft guidelines, or should then use the published
> RFC until
>  6087bis is actually republshed?
> > Thanks,
> > Rob
> >
> >
> 

Re: [netmod] *one* week 2nd WG Last Call: draft-ietf-netmod-revised-datastores-07

[Andy Bierman]

Hi,

I have reviewed draft-07 and my previous comments about NMDA have been
addressed.

This might be the most important sentence in the draft:

sec. 5.3

   The datastore schema for  MUST be a superset of the
   combined datastore schema used in all configuration datastores except
   that YANG nodes supported in a configuration datastore MAY be omitted
   from  if a server is not able to accurately report them.

The MUST implies that there is no need to design a YANG library that can
support
an implementation that violates this MUST (i.e., 1 schema tree for the
super-set)

The MAY is troublesome because it completely contradicts the conformance
expressed
in each YANG module supported by the server.  Any data node without any
if-feature-stmts is mandatory to implement.

What about config=false subtrees within a config=true subtree?
Can they be omitted from  as well, or does the draft just
intend to
omit the operational value of config=true nodes?  Should be specific.

Perhaps this draft does not need the MAY half of the sentence at all.
The YANG library can specify that it is for conformance-reporting, not
conformance-defining.




Andy


On Mon, Dec 4, 2017 at 6:35 AM, Lou Berger  wrote:

> All,
>
> This starts a second working group last call on
> draft-ietf-netmod-revised-datastores.
>
> As this is a 2nd LC that is focused on changes since the last LC, it
> closes in *one* week. The working group last call ends on December 11.
> Please send your comments to the netmod mailing list.
>
> At this point, we're most interested in verifying that previous comments
> are addressed since the last call on the -04 rev of the draft was held.
>
> A summary of changes can be found at
> https://mailarchive.ietf.org/arch/msg/netmod/DWtD12bGkBZabEygRfiwZfcnUU4
>
> A diff can be found at
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-
> revised-datastores-04.txt=draft-ietf-netmod-revised-datastores-07.txt
>
> Comments along the of: I have reviewed this version of the document and it
> addresses my previous comments would be particularly helpful.
>
> Thank you,
> Netmod Chairs
>
> ___
> 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] intended status of the tree diagram document

[Benoit Claise]

Dear all,

I believe BCP is correct for the tree diagram document.
Exactly as this is the right status for RFC6087bis, as discussed on the 
list.


Regards, Benoit.

I think the rules and recommendations in this document should be used, once
agreed and published, by all YANG module drafts within and outside of IETF.
As such its content is BCP.
IETF consensus will be achieved during IETF LC.

Cheers,
Mehmet


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Friday, December 8, 2017 2:07 AM
To: 'Kent Watsen' ; 'Lou Berger' ;
netmod@ietf.org; 'Benoit Claise' ; 'Juergen
Schoenwaelder' 
Subject: Re: [netmod] intended status of the tree diagram document

Kent:

A common way to express tree-diagrams in Yang documents provides a
common and clear to describe the models.  This would be really helpful to
those using these yang models.  Seems like a standard or a BCP to me.

Sue Hares


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, December 7, 2017 7:06 PM
To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder
Subject: Re: [netmod] intended status of the tree diagram document


BCP for tree-diagrams?   This doesn't seem like an appropriate application
of that designation.  I don't view the format for tree diagrams to be a
"practice", whereas it definitely seems "informational".

Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does

not

represent an Internet community consensus or recommendation" could be
cause for objection, since this draft is obviously going through a WG
(NETMOD) and therefore does, in fact, represent some form of consensus,
but I'm willing to gloss over that line as, clearly, many Informational

RFCs are

published by WGs, which wouldn't be possible if that line were taken

literally.

Perhaps we should file Errata against it?

Kent // co-chair


= original message =

Hi Juergen,

 Sorry for the slow response, I missed this message.

Circling back to this discussion made me go revisit RFC2026.  Based on all

the

factors/discussions I agree  that standards track isn't quite right for

this

document, but I also think informational isn't quite right either.  I do

think

BCP would as described in RFC2026 fits.  This said, I think it would be

good to

hear from at least Kent (as Chair) and Benoit (as AD) if they

agree/disagree

with publishing as a BCP.

Kent, Benoit?

Thanks,

Lou

On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:

Lou,

right now, the document says standards track, Martin's proposal was to
move to informational. So how do I parse "I think you are correct.  We
should leave as is."?

/js

On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:

Martin,
I think you are correct.  We should leave as is.

I'm sure Kent/the document Shepherd makes sure whatever we do is
right before publication in any case.

Lou (as contributor)

On 11/15/2017 8:58 PM, Martin Bjorklund wrote:

Hi,

Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
Standards Track.  I think I heard during the meeting today that it
ought to be Informational.  I think this makes sense.  It would then
imply that other standards track documents will have the tree
diagram document as an informative reference.

Should we make this change?


/martin

___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-

3A__www.ietf.org_ma
ilman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
ndb3voD
TXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpv
oumTA

-

4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byE
sko

noVDeyYcQE=


___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-

3A__www.ietf.org_mai

lman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-

ndb3voDTX
cWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvou
mTA-4y
jD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsk
onoVD

eyYcQE=



___
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] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 11/15/2017 06:29 PM, Robert Wilton wrote:

I don't think that this is really a good idea.  You would end up 
returning server metadata in addition to the configuration.
Obviously RFC 7895 defines only config false; data and I was not 
proposing a change to that. But I agree something has to be added to 
complete the solution. Special purpose datastore identities can be 
defined that return instance of yang-library data when read with 
. (Datastores with yang-library config false; only data not 
represented in 'operational')


Adding this special yang-library-datastore to the proposed 
ietf-datastores container e.g.


module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref
| +--ro yang-library-datastore  identityref

Notifications can indicate which yang-library-datastore is their origin 
(adding optional parameter in ietf-datastores through augmentation to 
the notifications in ietf-yang-library).




I still think that the YANG library proposal is the best solution.
The solution I propose has an obvious advantage for all designing 
systems that use single model for operational and the configuration 
datastores in terms of keeping the already implemented model and full 
backward compatibility without maintaining the obsolete /modules-state 
container in addition to any of the 3 proposals with additional 
indirection layers added. I am not sure if there are any disadvantages 
for the rest but I would like to read some arguments.


Vladimir


Thanks,
Rob


On 16/11/2017 01:21, Vladimir Vassilev wrote:

Hello,

I have a proposal based on  that provides an elegant 
solution to consider as a 3rd option.  It is based on keeping exactly 
the same model as in RFC 7895 and using  RPC to retrieve 
datastore specific yang-library instance data in a similar way one 
would use  to retrieve the datastore contents. In addition 
a top level config=false container e.g. /datastores with list of 
supported datastores that does not need to be part of the 
yang-library module:


module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref

Vladimir

On 11/09/2017 05:51 PM, Robert Wilton wrote:


Hi,

Given some of the feedback related to the complexity of the YANG 
library bis structure, we have come up with two other possible 
structures for the YANG library data:


(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library 
structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also 
extended to allow the structure to be reused for schema-mount via an 
augmentation.


For reference, at the end of this email, I have also included the 
tree diagram of the existing YANG library, and the current YANG 
library bis draft (draft-ietf-netconf-rfc7895bis-02) version.


Considering the two new YANG library structures:



*(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library 
structure.*


The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two 
separate lists, making the most important list (i.e. implemented 
modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default 
(with a "not-implemented-in" leaflist of datastores that a module is 
not implemented in).
(iii) Assume that features are implemented in all datastores by 
default (with a "not-implemented-in" leaflist of datastores that a 
feature is not implemented in).

(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that 
could potentially be extended with further per datastore properties 
in future).


Manually generated tree output for proposed YANG library:

module: ietf-yang-library
 +--ro yang-library
    +--ro modules
    |  +--ro module* [name]
    |  |  +--ro name   yang:yang-identifier
    |  |  +--ro revision?  revision-identifier
    |  |  +--ro schema?    inet:uri
    |  |  +--ro namespace  inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema? inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |  -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |  -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  | -> ../name
    |  |
    |  +--ro import-only-module* [name revision]
    | +--ro name yang:yang-identifier
    | +--ro revision    union
    | +--ro schema? inet:uri
    | +--ro namespace   inet:uri
    | +--ro submodule* [name]
    |    +--ro name    

Re: [netmod] YANG library structure

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Dec 08, 2017 at 07:08:32AM -0500, Lou Berger wrote:
> > On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote:
> > >  
> > >> In talking to some others on this topic, they suggested using a library 
> > >> per
> > >> datastore. I haven't look into this enough to know if that is a good or 
> > >> bad
> > >> idea, but it seems functionally equivalent to your first option but 
> > >> realized
> > >> in a different way. Just something to add to the mix.
> > > If people want to put additional options on the table, they should
> > > work out the details and write down a tree diagram and send the result
> > > to the list.
> > 
> > I guess we have a different philosophical approach here.  I'd prefer to
> > hear about fresh ideas, even if half baked or asked as a "stupid
> > question". Sometimes, if not dismissed out of hand, these lead to
> > something that is a better result than others that have been immersed in
> > the issue have thought of.
> >
> 
> The devil is usally in the details and 'using a library per datastore'
> is for my taste a bit too little to understand what is actually being
> proposed. I am not dismissing proposals, but I like to be able to
> understand what is being proposed. And for that I need a proposal that
> is a bit more than 'using a library per datastore'.

I agree.  In this case, I can't understand how it would work at all.
The library is config false, so a client can never get it via
get-config from .  Maybe the proposal is a new operation
 with the datastore as a parameter?  Or maybe the
idea is to somehow return meta data together with ?  I can
guess, and dismiss the proposal based on my guesses ;-)  Or someone
can write up a concrete proposal.


/martin

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

Re: [netmod] YANG library structure

[Juergen Schoenwaelder]

On Fri, Dec 08, 2017 at 07:08:32AM -0500, Lou Berger wrote:
> On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote:
> >  
> >> In talking to some others on this topic, they suggested using a library per
> >> datastore. I haven't look into this enough to know if that is a good or bad
> >> idea, but it seems functionally equivalent to your first option but 
> >> realized
> >> in a different way. Just something to add to the mix.
> > If people want to put additional options on the table, they should
> > work out the details and write down a tree diagram and send the result
> > to the list.
> 
> I guess we have a different philosophical approach here.  I'd prefer to
> hear about fresh ideas, even if half baked or asked as a "stupid
> question". Sometimes, if not dismissed out of hand, these lead to
> something that is a better result than others that have been immersed in
> the issue have thought of.
>

The devil is usally in the details and 'using a library per datastore'
is for my taste a bit too little to understand what is actually being
proposed. I am not dismissing proposals, but I like to be able to
understand what is being proposed. And for that I need a proposal that
is a bit more than 'using a library per datastore'.

/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] YANG library structure

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Hi,
>
> There has been quite a lot of discussion about the YANG library
> data model on the list.  The authors of draft-ietf-netconf-rfc7895bis
> have tried to understand all arguments in the discussion, and provide
> a solution.  Below are 3 solution proposals (we have discussed more,
> but they are basically just variations on the same themes).
>
> Absolute Requirements
> -
>
> o  RFC 7950, Section 5.6.5 says:
>
>  A server MUST NOT implement more than one revision of a module.

I believe YANG library should be liberated from the dependence on
servers and protocols and become part of a formal data model
specification. It is not just some state data but rather metadata, and
it is also perfectly conceivable that a server does not publish its YANG
library at all (e.g. for security reasons or constrained devices).

And then, I would suggest to consider dropping the above requirement
for the *general* YANG library, i.e. design it so that it can in
principle support multiple revisions of the same module. This is
important because

- it allows for supporting multiple revisions of some hardware
  (e.g. line cards) in the same device

- the server needn't represent just a single device but may be used for
  configuring a network of devices, and then the above restriction could
  be severely limiting.

This said, it would still be possible for a specific protocol to impose
such a restriction.

...

>
> Alt. B.
> ---
>
>   Each datastore refers to a schema, and each schema contains a list
>   of references to module-sets, and each module-set contains a flat
>   list of all modules, features, etc.

I like this one because different schemas will often need to reuse the
same module sets, and it will also be quite easy to add schema mount
specification to this.

Lada

-- 
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] YANG library structure

[Lou Berger]

On 12/08/2017 06:15 AM, Juergen Schoenwaelder wrote:
>  
>> In talking to some others on this topic, they suggested using a library per
>> datastore. I haven't look into this enough to know if that is a good or bad
>> idea, but it seems functionally equivalent to your first option but realized
>> in a different way. Just something to add to the mix.
> If people want to put additional options on the table, they should
> work out the details and write down a tree diagram and send the result
> to the list.

I guess we have a different philosophical approach here.  I'd prefer to
hear about fresh ideas, even if half baked or asked as a "stupid
question". Sometimes, if not dismissed out of hand, these lead to
something that is a better result than others that have been immersed in
the issue have thought of.

Lou

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

Re: [netmod] YANG library structure

[Juergen Schoenwaelder]

On Fri, Dec 08, 2017 at 06:10:49AM -0500, Lou Berger wrote:
> Martin,
> 
> Thanks for raising this, there's definitely some open issues as well as
> confusion on this topic. In the different options listed below you say that
> each datastore refers to a schema, correct? What is the mechanism you would
> use to do this?

This is in the tree diagrams, e.g.

>+--ro datastore* [name]
>|  +--ro name  identityref
>|  +--ro schema-> ../../schema/name
 
> In talking to some others on this topic, they suggested using a library per
> datastore. I haven't look into this enough to know if that is a good or bad
> idea, but it seems functionally equivalent to your first option but realized
> in a different way. Just something to add to the mix.

If people want to put additional options on the table, they should
work out the details and write down a tree diagram and send the result
to the list.

/js

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

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

Re: [netmod] YANG library structure

[Lou Berger]

Martin,

Thanks for raising this, there's definitely some open issues as well as 
confusion on this topic. In the different options listed below you say that 
each datastore refers to a schema, correct? What is the mechanism you would 
use to do this?


In talking to some others on this topic, they suggested using a library per 
datastore. I haven't look into this enough to know if that is a good or bad 
idea, but it seems functionally equivalent to your first option but 
realized in a different way. Just something to add to the mix.


Lou


On December 8, 2017 4:48:15 AM Martin Bjorklund  wrote:


Hi,

There has been quite a lot of discussion about the YANG library
data model on the list.  The authors of draft-ietf-netconf-rfc7895bis
have tried to understand all arguments in the discussion, and provide
a solution.  Below are 3 solution proposals (we have discussed more,
but they are basically just variations on the same themes).

Absolute Requirements
-

o  RFC 7950, Section 5.6.5 says:

 A server MUST NOT implement more than one revision of a module.

o  draft-ietf-netmod-revised-datastores says:

 The conventional configuration datastores [...] share exactly
 the same datastore schema

o  draft-ietf-netmod-revised-datastores says:

 The datastore schema for  MUST be a superset of the
 combined datastore schema used in all configuration datastores
 except that YANG nodes supported in a configuration datastore MAY
 be omitted from  if a server is not able to
 accurately report them.


These requirements (of course) still hold, and we think that the YANG
library document should explain what they imply for the data reported
as part of the library.  (For example, all conventional datastores
MUST have a reference to the same "schema").


Objectives (in no particular order)
---

1. As efficient as possible for a client to consume.

   Since the size of the yang library can be quite large, it should
   be possible for clients to cache the yang library information.

2. A dynamic datastore must be able to implement a module or feature
   that is not implemented in the conventional datastores.

3. It must be possible to NOT implement a module or feature in
   operational, even if it is implemented in some other datastore.

   This is required for transition purposes; a server that wants to
   implement  should not have to implement all modules at
   once.

4. A given module can only be implemented in one revision in all
   datastores.  If a module is implemented in more than one
   datastores, the same revision is implemented in all these
   datastores.

5. Multiple revisions can be used for import, if import-by revision
   is used.

6. Nice to have: make it possible to be used by schema mount


It should be noted that because of 2 and 3 (and 6), the original data
model in RFC 7895 cannot be used.


Use Cases
-

Here's a set of use cases that must be supported.

  C1. conventional + operational, all have the same schema

  C2. conventional + operational, ietf-hardware is not implemented in
  conventional

  C3. conventional + operational, some modules not yet implemented in
  operational, and some modules are partly implemented in
  operational.

  C4. conventional + operational + ephemeral, ephemeral has its own
  set of modules



Alt. A.
---

  Each datastore refers to a schema, and each schema contains a flat
  list of all modules, features, etc.

+--ro yang-library
   +--ro schema* [name]
   |  +--ro name  string
   |  +--ro checksum  string
   |  +--ro module* [name]
   |  |  +--ro name yang:yang-identifier
   |  |  +--ro revision?revision-identifier
   |  |  +--ro namespaceinet:uri
   |  |  +--ro location*inet:uri
   |  |  +--ro submodule* [name]
   |  |  |  +--ro nameyang:yang-identifier
   |  |  |  +--ro revision?   revision-identifier
   |  |  |  +--ro location*   inet:uri
   |  |  +--ro feature* [name]
   |  |  |  +--ro nameyang:yang-identifier
   |  |  +--ro deviation* [module]
   |  | +--ro module-> ../../name
   |  +--ro import-only-module* [name revision]
   | +--ro name yang:yang-identifier
   | +--ro revision union
   | +--ro namespaceinet:uri
   | +--ro location*inet:uri
   | +--ro submodule* [name]
   |+--ro nameyang:yang-identifier
   |+--ro revision?   revision-identifier
   |+--ro location*   inet:uri
   +--ro datastore* [name]
   |  +--ro name  identityref
   |  +--ro schema-> ../../schema/name
   +--ro checksum string


  How does this solution handle the use cases above?

  C1: One schema, all datastores refer to this schema.

  C2: Two schemas, "conventional" and "operational".  They differ in

Re: [netmod] intended status of the tree diagram document

[Mehmet Ersue]

I think the rules and recommendations in this document should be used, once
agreed and published, by all YANG module drafts within and outside of IETF.
As such its content is BCP.
IETF consensus will be achieved during IETF LC.

Cheers,
Mehmet

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Susan Hares
> Sent: Friday, December 8, 2017 2:07 AM
> To: 'Kent Watsen' ; 'Lou Berger' ;
> netmod@ietf.org; 'Benoit Claise' ; 'Juergen
> Schoenwaelder' 
> Subject: Re: [netmod] intended status of the tree diagram document
> 
> Kent:
> 
> A common way to express tree-diagrams in Yang documents provides a
> common and clear to describe the models.  This would be really helpful to
> those using these yang models.  Seems like a standard or a BCP to me.
> 
> Sue Hares
> 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Thursday, December 7, 2017 7:06 PM
> To: Lou Berger; netmod@ietf.org; Benoit Claise; Juergen Schoenwaelder
> Subject: Re: [netmod] intended status of the tree diagram document
> 
> 
> BCP for tree-diagrams?   This doesn't seem like an appropriate application
> of that designation.  I don't view the format for tree diagrams to be a
> "practice", whereas it definitely seems "informational".
> 
> Looking more deeply at RFC2026, I can see how Section's 4.2.2's "...does
not
> represent an Internet community consensus or recommendation" could be
> cause for objection, since this draft is obviously going through a WG
> (NETMOD) and therefore does, in fact, represent some form of consensus,
> but I'm willing to gloss over that line as, clearly, many Informational
RFCs are
> published by WGs, which wouldn't be possible if that line were taken
literally.
> Perhaps we should file Errata against it?
> 
> Kent // co-chair
> 
> 
> = original message =
> 
> Hi Juergen,
> 
> Sorry for the slow response, I missed this message.
> 
> Circling back to this discussion made me go revisit RFC2026.  Based on all
the
> factors/discussions I agree  that standards track isn't quite right for
this
> document, but I also think informational isn't quite right either.  I do
think
> BCP would as described in RFC2026 fits.  This said, I think it would be
good to
> hear from at least Kent (as Chair) and Benoit (as AD) if they
agree/disagree
> with publishing as a BCP.
> 
> Kent, Benoit?
> 
> Thanks,
> 
> Lou
> 
> On 11/17/2017 1:54 AM, Juergen Schoenwaelder wrote:
> > Lou,
> >
> > right now, the document says standards track, Martin's proposal was to
> > move to informational. So how do I parse "I think you are correct.  We
> > should leave as is."?
> >
> > /js
> >
> > On Fri, Nov 17, 2017 at 07:36:58AM +0800, Lou Berger wrote:
> >> Martin,
> >>I think you are correct.  We should leave as is.
> >>
> >> I'm sure Kent/the document Shepherd makes sure whatever we do is
> >> right before publication in any case.
> >>
> >> Lou (as contributor)
> >>
> >> On 11/15/2017 8:58 PM, Martin Bjorklund wrote:
> >>> Hi,
> >>>
> >>> Currently, draft-ietf-netmod-yang-tree-diagrams has intended status
> >>> Standards Track.  I think I heard during the meeting today that it
> >>> ought to be Informational.  I think this makes sense.  It would then
> >>> imply that other standards track documents will have the tree
> >>> diagram document as an informative reference.
> >>>
> >>> Should we make this change?
> >>>
> >>>
> >>> /martin
> >>>
> >>> ___
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_ma
> >>>
> ilman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> >>>
> TXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpv
> oumTA
> >>> -
> 4yjD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byE
> sko
> >>> noVDeyYcQE=
> >>>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> >> lman_listinfo_netmod=DwIDaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTX
> >>
> cWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=3BCNpvou
> mTA-4y
> >>
> jD5n04CSFPUs2jLAlNoj5OIoOXDkU=Pi6G9uzvFRpUNkgaZa2tRR07sP7byEsk
> onoVD
> >> eyYcQE=
> 
> 
> 
> ___
> 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 Last Call: draft-ietf-netmod-entity-05

[Carey, Timothy (Nokia - US)]

Kent,

Yes it would be good set a target date so it communicates to the industry the 
intent, allowing them to plan their migration.
It also allows the industry to provide feedback regarding the migration period.

I wanted to reiterate Barts request for the hardware module to have state 
module in an Appendix. What you don't want is have the industry organizations 
that use the modules to create their own state modules - this will cause undue 
fragmentation that will harm the advancement of YANG.

BR,
Tim

-Original Message-
From: Kent Watsen [mailto:kwat...@juniper.net] 
Sent: Thursday, December 07, 2017 2:03 PM
To: Juergen Schoenwaelder ; Bogaert, Bart 
(Nokia - BE/Antwerp) 
Cc: NetMod WG 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-05

All,

Picking up on Juergen's comment:

> If these deprecated objects are essential for BBF (please confirm), 
> then it might be better to define them in a separate module...

I agree that the objects should be defined in a separate module.  The request, 
as I understand it, is for there be an "ietf-hardware-state"
module defined in the Appendix of this draft.  I believe that doing so is 
consistent with the NMDA guidelines:

   (b) Models that require immediate support for "in use" and "system
   created" information SHOULD be structured for NMDA.  A non-NMDA
   version of these models SHOULD exist, either an existing model or a
   model created either by hand or with suitable tools that mirror the
   current modeling strategies.  Both the NMDA and the non-NMDA modules
   SHOULD be published in the same document, with NMDA modules in the
   document main body and the non-NMDA modules in a non-normative
   appendix.  The use of the non-NMDA model will allow temporary
   bridging of the time period until NMDA implementations are available.

Of course, we should ask, for how long is it that the IETF (SDOs in
general) should publish these -state modules?   During the discussion
at the beginning of the first session in Singapore, I said something along the 
lines of "so long as there is market demand for it", which
seems a bit too open-ended for my taste.   I recommend that we set a
date, perhaps a couple years out, after which we (the IETF) will no longer 
publish or maintain such foo-state modules.

Thoughts?

Kent  // as co-chair


= original message ==

Bart,

I think the reason for the difference is that the interfaces model was 
published as an RFC before while the hardware model is new and hence it seems 
to look a bit odd to define new deprecated objects.

If these deprecated objects are essential for BBF (please confirm), then it 
might be better to define them in a separate module that then can silently die 
while systems move to NMDA (and so we do not have the deprecated objects with 
us in the hardware module forever - or at least as long as we use YANG 1.1).

/js

On Tue, Dec 05, 2017 at 02:35:29PM +, Bogaert, Bart (Nokia - BE/Antwerp)
wrote:
> Hello,
>
> The latest draft does not contain an appendix with the deprecated 
> state tree (to support the non-NMDA model as specified in RFC6087bis 
> section 4.23.3), so if it is published in this way, there is an issue 
> at the level of BBF TR-383.
>
> Note that the draft-ietfnetmod-rfc7223bis does include the deprecated 
> container interfaces-state.
>
> Best regards,
> Bart Bogaert
>
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
> Sent: Wednesday, November 29, 2017 6:36 PM
> To: NetMod WG 
> Cc: NetMod WG Chairs 
> Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05
>
> All,
>
> This starts a two-week working group last call on 
> draft-ietf-netmod-entity-05.
>
> The working group last call ends on December 13.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
> zoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chLVKwaAcdC6Llko8
> SagGTdtaLVTMJRVuFxx-MbXvQU=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqd
> Is=



> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW
> zoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=chLVKwaAcdC6Llko8
> SagGTdtaLVTMJRVuFxx-MbXvQU=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqd
> Is=


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587   

[netmod] YANG library structure

[Martin Bjorklund]

Hi,

There has been quite a lot of discussion about the YANG library
data model on the list.  The authors of draft-ietf-netconf-rfc7895bis
have tried to understand all arguments in the discussion, and provide
a solution.  Below are 3 solution proposals (we have discussed more,
but they are basically just variations on the same themes).

Absolute Requirements
-

o  RFC 7950, Section 5.6.5 says:

 A server MUST NOT implement more than one revision of a module.

o  draft-ietf-netmod-revised-datastores says:

 The conventional configuration datastores [...] share exactly
 the same datastore schema

o  draft-ietf-netmod-revised-datastores says:

 The datastore schema for  MUST be a superset of the
 combined datastore schema used in all configuration datastores
 except that YANG nodes supported in a configuration datastore MAY
 be omitted from  if a server is not able to
 accurately report them.


These requirements (of course) still hold, and we think that the YANG
library document should explain what they imply for the data reported
as part of the library.  (For example, all conventional datastores
MUST have a reference to the same "schema").


Objectives (in no particular order)
---

1. As efficient as possible for a client to consume.

   Since the size of the yang library can be quite large, it should
   be possible for clients to cache the yang library information.

2. A dynamic datastore must be able to implement a module or feature
   that is not implemented in the conventional datastores.

3. It must be possible to NOT implement a module or feature in
   operational, even if it is implemented in some other datastore.

   This is required for transition purposes; a server that wants to
   implement  should not have to implement all modules at
   once.

4. A given module can only be implemented in one revision in all
   datastores.  If a module is implemented in more than one
   datastores, the same revision is implemented in all these
   datastores.

5. Multiple revisions can be used for import, if import-by revision
   is used.

6. Nice to have: make it possible to be used by schema mount


It should be noted that because of 2 and 3 (and 6), the original data
model in RFC 7895 cannot be used.


Use Cases
-

Here's a set of use cases that must be supported.

  C1. conventional + operational, all have the same schema

  C2. conventional + operational, ietf-hardware is not implemented in
  conventional

  C3. conventional + operational, some modules not yet implemented in
  operational, and some modules are partly implemented in
  operational.

  C4. conventional + operational + ephemeral, ephemeral has its own
  set of modules



Alt. A.
---

  Each datastore refers to a schema, and each schema contains a flat
  list of all modules, features, etc.

+--ro yang-library
   +--ro schema* [name]
   |  +--ro name  string
   |  +--ro checksum  string
   |  +--ro module* [name]
   |  |  +--ro name yang:yang-identifier
   |  |  +--ro revision?revision-identifier
   |  |  +--ro namespaceinet:uri
   |  |  +--ro location*inet:uri
   |  |  +--ro submodule* [name]
   |  |  |  +--ro nameyang:yang-identifier
   |  |  |  +--ro revision?   revision-identifier
   |  |  |  +--ro location*   inet:uri
   |  |  +--ro feature* [name]
   |  |  |  +--ro nameyang:yang-identifier
   |  |  +--ro deviation* [module]
   |  | +--ro module-> ../../name
   |  +--ro import-only-module* [name revision]
   | +--ro name yang:yang-identifier
   | +--ro revision union
   | +--ro namespaceinet:uri
   | +--ro location*inet:uri
   | +--ro submodule* [name]
   |+--ro nameyang:yang-identifier
   |+--ro revision?   revision-identifier
   |+--ro location*   inet:uri
   +--ro datastore* [name]
   |  +--ro name  identityref
   |  +--ro schema-> ../../schema/name
   +--ro checksum string


  How does this solution handle the use cases above?

  C1: One schema, all datastores refer to this schema.

  C2: Two schemas, "conventional" and "operational".  They differ in
  just one element (ietf-hardware).  All other module information
  is entirely duplicated in both.

  C3: Two schemas, "conventional" and "operational".  They differ in
  the modules not implemented in operational, and operational also
  has some deviation modules with "not-implemented".

  C4: Three schemas, "conventional", "ephemeral", "operational".
  "operational" contains the union of all modules in the other
  two.


  Pro: simple on the client, simple on the server

  Con: verbose, since a single difference requires a complete, new,
   schema.


Alt. B.
---

  Each datastore 

Re: [netmod] tree diagram guidelines

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Dec 07, 2017 at 06:38:14PM -0500, Lou Berger wrote:
> > 
> > This leaves the intended status as the key open issue on the draft.
> >
> 
> Have the suggestions for including a collapsed view of uses been
> included?

No, not yet.

> Related to the status, I do think that the reference to YANG [RFC7950]
> should be normative - other BCP documents also have normative
> references and frankly this document talks a lot about YANG constructs
> and hence it really has more than in informative dependency on YANG.

I agree.

> Is someone tracking issues somewhere?

Not in a tracker, no.  Just manually.


/martin

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