Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[t.petch]

- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, February 21, 2018 9:21 PM

> Kent, Tom, Yaron, and Ron,
>
> A new version of the draft-ietf-netmod-syslog-model has been published
that addresses your concerns.

Optimist:-)

And we can always have fresh concerns:-(

I note that this I-D imports interface-ref  from RFC7223 while
draft-ietf-netmod-rfc7223bis
is in the RFC Edittor's queue.  I do not think that there is any reason
not to use the latter.

Tom Petch


>
> Thanks,
>
> Clyde
>
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"
 wrote:
>
>
>
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution
to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to
reflect the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the
RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.
>
> K.
>
>
> > Note that this is not the case of a Normative i-d reference
being buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this
draft on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>  on behalf
of
> bcla...@cisco.com> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >The YANG model in this document conforms to the Network
Management
> >
> >Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup,
[I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> --
--
> 
>
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> >
>
>
>
> ___
> 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] AD review of draft-ietf-netmod-syslog-model-20

[t.petch]

- Original Message -
From: "Kent Watsen" <kwat...@juniper.net>
To: "t.petch" <ie...@btconnect.com>; "NETMOD Working Group"
<netmod@ietf.org>
Sent: Tuesday, February 20, 2018 5:06 PM
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to reflect
the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.

Kent

Corner case:-)

You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.

Tom Petch

> K.
>
>
> > Note that this is not the case of a Normative i-d reference being
buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this draft
on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
> <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of
> bcla...@cisco.com<mailto:bcla...@cisco.com>> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >The YANG model in this document conforms to the Network
Management
> >
> >Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> --
--
> 
>
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> >
>
>
>
>

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

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[t.petch]

- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, February 14, 2018 6:03 PM

> Buggers, I thought we caught that tree-diagrams informative/normative
thing before.
>
> Regardless, Clyde, please note that I think I was wrong before from
the shepherd write-up regarding idnits having a problem:
>
> """
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1340,
>  but no explicit reference was found in the text
>  '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a
"Keys...'
>
>This is a bug in idnits, whereby a reference that splits two lines
is
>not found.
> """
>
> Looking at the XML, it seems that references are not specified
correctly.
>
> CURRENT:
>
> This module imports typedefs from [RFC7223], groupings from
> [I-D.ietf-netconf-keystore], and
[I-D.ietf-netconf-tls-client-server], and it references [RFC5424],
> [RFC5425], [RFC5426], and [RFC5848] and [Std-1003.1-2008].
>
> SHOULD BE:
>
> This module imports typedefs from ,
groupings from
> , and , and it references ,
> , , and  and .
>
> Right?
>
> And while you're at it, please update the reference to the
tree-diagrams draft (-06 is current).  Also, missing is an RFC Editor
note requesting that the I-D reference to be updated to reflect the
assigned RFC number.

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that
tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC number
is assigned.

Therefore, a note asking the I-D reference to be updated to reflect the
assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED

Note that this is not the case of a Normative i-d reference being buried
in the YANG module and not being.noticed by the RFC Editor; that problem
I am content with.


Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> 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] Draft Informative references in a YANG module

[t.petch]

If a YANG module has a Reference or Description clause specifying an
I-D, and the I-D is listed as an Informative Reference, as many are
outside the
NETCONF/Netmod WGs, then will the I-D be published with that reference
still as a draft e.g. with text such as

 reference "I-D.ietf-netconf-tls-client-server: TLS Client and Server
Models";

or

See section 4.2.1 of draft-ietf-ntp-packet-timestamps
?

The RFC Editor has a MISSREF status/procedure but that only applies to a
Normative Reference, not to an Informative one, so will the RFC appear
with the Reference or Description clause specifying the I-D?

Tom Petch


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

Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[t.petch]

Oppose adoption

As others have said, there is a lack of a problem to solve.

When I ask users of a technology that uses #hashtags where they come
from, how they come into being and similar elements of procedure, I
never get an answer.  #hashtags seem to be provided to allow a storm to
gather on social media, around some vague idea, in order to put pressure
on someone or something that would otherwise be unjustified:-)

The tags listed in Section 10.2 seem just as vague and I do not see a
role for something somewhat ill-defined in YANG.

Tom Petch

- Original Message -
From: "Phil Shafer" 
To: "Andy Bierman" 
Cc: "NETMOD Working Group" 
Sent: Wednesday, February 07, 2018 6:59 PM
Subject: Re: [netmod] Adoption Poll:
draft-rtgyangdt-netmod-module-tags-02


> Andy Bierman writes:
> >The draft avoids discussion of any useful operations based on tags.
>
> Nor does it really clearly say "what" is being tagged.  The absract
> talks about "used to help classify and organize modules", but the
> Introduction lacks any expansion on this.  There's really no clear
> problem statement or a clear definition of why we need tags or what
> one would use them for.
>
> It would also be helpful to understand why "#hashtag" and the string
> format ("ietf:routing", "vendor:super-duper:...") are chosen over
> YANG identities.  It seems like identity naming standards and
inheritance
> would be good features.
>
> Also it's not clear why these would be configurable rather that
> controlled by the module author.  I'd rather have the OAM standard
> YANG module say something like:
>
> module ietf-oam {
> import "ietf-category" { prefix ietf-category; }
>
> identify ietf-oam {
> base ietf-category:ietf-standard;
> description "This module category represents something
>  OAM related.";
> }
>
> ietf-category:module-category ietf-oam;
> ...
> }
>
> The draft says:
>
>Implementations that do not support the reset rpc statement
(whether
>at all, or just for a particular rpc or module) MUST respond with
an
>YANG transport protocol-appropriate rpc layer error when such a
>statement is received.
>
> The entire idea of NETCONF/YANG is that the client _knows_ what it
> can safely send instead of tossing spaghetti at the wall until
> something sticks.  Avoid programming-by-error-detection, which
> creates fragile infrastructure.
>
> Use "feature" to control optional portions of a YANG module.  I'd
> suggest one feature for "reset" support and another for "read-only",
> since IMHO the idea of someone munging the categories of standard
> modules is, well, disconcerting.
>
> "Local" tags are not well explained.  The idea of a user/admin
> tagging modules means that something is broken.  Users shouldn't
> understand YANG modules.  Users use applications, some of which are
> home-grown.  Is "local" appropriate for my "audit interfaces" script?
>
> 6.1 is missing the list "module-tags".
>
> 9.1 advocates putting vital information in the description string,
> which is IMHO not a good idea.  We want to put as much information
> in machine-readable format as possible, so I can ask ietf.org
> questions like "give me a list of ietf-oam-related yang modules"
> and get a nice list.
>
> It also talks about "SHOULD" and "MAY" tags without giving any
> clue as to why or when this would be appropriate or useful.
>
> So my vote would be that this document needs some significant work
> and expansion before it's a supportable draft.  I think the authors
> have more in their heads than they've put into the draft and I'd
> like to see the rest of their thoughts.
>
> Thanks,
>  Phil
>
> ___
> 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] draft-ietf-netmod-rfc6087bis-16

[t.petch]

- Original Message -
From: "Andy Bierman" <a...@yumaworks.com>
Sent: Wednesday, February 07, 2018 5:48 PM

> On Wed, Feb 7, 2018 at 4:58 AM, t.petch <ie...@btconnect.com> wrote:
>
> > Andy
> >
> > If an RFC is mentioned in a Description clause, should it also
appear in
> > the related Reference clause?
>
> yes -- there are many places in 6087bis that mention the
reference-stmt
>
> e.g.:
>
>If the notification semantics are defined in an external document
>(other than another YANG module indicated by an import statement),
>then a reference statement MUST be present.
>
> I cannot find any text that says it is OK or not OK to also put
> the reference in the description-stmt.

Andy

Just to be clear, what I am seeing is RFC in a Description clause in
a YANG module but not appearing anywhere else in the I-D, not in a
Reference clause or in the I-D Reference sections or anywhere.

e.g. in draft-ietf-dhc-dhcpv6-yang
 leaf uuid {
type yang:uuid;
description "A Universally Unique IDentifier in the string
representation
defined in RFC 4122.

4122 appears in three such Description clauses but nowhere else; I am
thinking that it should also be in a Reference clause as well

Tom Petch

> > draft-ietf-dhc-dhcpv6-yang-05 has examples of this not being the
case,
> > as I mention in a recent post.  I assumed that they should be but
cannot
> > see any discussion of this in RFC6087bis
> >
> > Tom Petch
> >
> >
> Andy
>

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

Re: [netmod] Missing references

[t.petch]

Henrik, Benoit

My first e-mail was sloppily worded.  What I meant was RFC in the
Reference clause of a YANG module, since I think that those should be in
the Reference section as well.

I think that it should apply to the Description clause as well, but that
might be more debatable i.e. missing when it appears in Reference I
would see as an error, but missing when it appears in Description, um
perhaps a warning?

Tom Petch

- Original Message -
From: "Benoit Claise" <bcla...@cisco.com>
To: "t.petch" <ie...@btconnect.com>; "Henrik Levkowetz"
<hen...@levkowetz.com>; "NETMOD Working Group" <netmod@ietf.org>
Sent: Wednesday, February 07, 2018 11:56 AM

> Hi Henrik,
>
> Could this check be added to idnits?
>
> Regards, Benoit
> > I just came across (yet) another example of a reference to an RFC in
a
> > description clause of a YANG module that appears nowhere else in the
> > I-D.
> >
> > This seems to be a systematic error that some YANG module authors
make;
> > can the tools be modified to pick it up?  The logic is simple
enough.
> >
> > The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to
> > reference RFC5952;  I think that the I-D is in the RFC Editor queue.
> >
> > Tom Petch
> >
> > .
> >
>

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

[netmod] Draft Normative references in a YANG module

[t.petch]

Will the RFC Editor know that

   reference "draft-ietf-netmod-rfc7223bis: A YANG Data Model
  for Interface Management";
in

draft-ietf-rtgwg-ni-model-09

needs replacing by RFC when that I-D becomes an RFC?

Normally, such a reference would be [draft-ietf-netmod-rfc7223bis] with
the underlying HTML/XML anchor and automated tools can pick this up (I
assume that the RFC Editor is well automated:-)

But when the Normative Reference is in the text of a YANG module and
there is no underlying anchor, will this get noticed and actioned?

Or should there be a

Note to RFC Editor

attached to such references?

Tom Petch

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

[netmod] draft-ietf-netmod-rfc6087bis-16

[t.petch]

Andy

If an RFC is mentioned in a Description clause, should it also appear in
the related Reference clause?

draft-ietf-dhc-dhcpv6-yang-05 has examples of this not being the case,
as I mention in a recent post.  I assumed that they should be but cannot
see any discussion of this in RFC6087bis

Tom Petch

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

[netmod] draft-ietf-dhc-dhcpv6-yang-05

[t.petch]

As and when this comes to a YANG Doctor review, the reviewer might like
to note that while there are 28 RFC referenced in the Reference or
Description clauses of the YANG modules, 6 do not appear in the either
Reference section, namely

RFC826   (Description clause)
RFC2464 (Description clause)
RFC3989
RFC 4122 (Description clause)
RFC4822
RFC7824

Also, the way in which the RFC are referred to in these clauses is
inconsistent, e.g.

RFC826
[RFC0826]
RFC2464
RFC 3315
[RFC3315]

I think that RFC826 is correct but YMMV.

The 19 that are referenced as Informative References are

RFC3319   8.2
RFC3646   8.2
RFC3898   8.2
RFC4075   8.2
RFC4242   8.2
RFC4704   8.2
RFC4833   8.2
RFC5908   8.2
RFC5970   8.2
RFC6334   8.2
RFC6422   8.2
RFC6440   8.2
RFC6784   8.2
RFC6939   8.2
RFC7078   8.2
RFC7083   8.2
RFC7227   8.2
RFC7291   8.2

I am not - and do not want to be -subscribed to the DHCP list.

I will look out for this at IETF Last Call but may miss it.

Tom Petch

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

[netmod] Missing references

[t.petch]

I just came across (yet) another example of a reference to an RFC in a
description clause of a YANG module that appears nowhere else in the
I-D.

This seems to be a systematic error that some YANG module authors make;
can the tools be modified to pick it up?  The logic is simple enough.

The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to
reference RFC5952;  I think that the I-D is in the RFC Editor queue.

Tom Petch

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

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt

[t.petch]

Kent

My request for a reference for Posix hs been fixed in -19.

Tom Petch

- Original Message -
From: "Kent Watsen" 
To: 
Sent: Tuesday, January 16, 2018 4:59 PM

> Clyde,
>
> This draft still isn't passing idnits.  I provided the link to idnits
previously, but here it is again: https://www.ietf.org/tools/idnits.
Below is the idnits output for -19 with inlined comments.
>
> PS: I didn't also checked the other issues we're tracking, but will
when we get past these idnits issues.
>
> Kent
>
>
> = START =
> idnits 2.15.00
>
> /tmp/draft-ietf-netmod-syslog-model-19.txt:
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   https://trustee.ietf.org/license-info):
>   

>
>  No issues found here.
>
>   Checking nits according to
https://www.ietf.org/id-info/1id-guidelines.txt:
>   

>
>  No issues found here.
>
>   Checking nits according to https://www.ietf.org/id-info/checklist :
>   

>
>   ** There is 1 instance of too long lines in the document, the
longest one
>  being 1 character in excess of 72.
>
> Kent: this isn't a big deal IMO, but if it's easy to fix, it saves the
RFC editor a step later on.
>
>
>   Miscellaneous warnings:
>   

>
>   == Line 352 has weird spacing: '...gorithmide...'
>
> Kent: this is fine.  it is in a tree diagram.
>
>
>   == The document seems to lack the recommended RFC 2119 boilerplate,
even if
>  it appears to use RFC 2119 keywords -- however, there's a
paragraph with
>  a matching beginning. Boilerplate error?
>
>  (The document does seem to have the reference to RFC 2119 which
the
>  ID-Checklist requires).
>
> Kent: I can't find the error.  Looking at the xml, it is verbatim what
I have in the zerotouch draft.  my guess is that this is a tooling error
and we should ignore it.
>
>
>   -- The document date (January 12, 2018) is 4 days in the past.  Is
this
>  intentional?
>
> Kent: this is fine, it is intentional.
>
>
>   Checking references for intended status: Proposed Standard
>   

>
>  (See RFCs 3967 and 4897 for information about using normative
references
>  to lower-maturity documents in RFCs)
>
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1386,
>  but no explicit reference was found in the text
>
> Kent: looking at the XML, I see that the entire paragraph uses '[' and
']' as opposed to .  Please fix this.
>
>
>   == Unused Reference: 'RFC7895' is defined on line 1456, but no
explicit
>  reference was found in the text
>
> Kent: looking at the XML, I see two instances of an unwanted "/"
string.  For instance: /  Please fix this.
>
>
>   ** Downref: Normative reference to an Historic RFC: RFC 6587
>
> Kent: hmmm, what's going on here?  This YANG module is providing an
ability to configure the "tcp" transport, even though the IESG made that
ability historic in 2012 (see IESG Note below).  Searching online, it
looks like Cisco supports this, but Juniper does not.  What about other
vendors, is it widely supported?  Was this discussed in the WG?
Answering my own question, searching my local mailbox, I don't see this
ever being discussed before, other than Martin questioning if it was a
good idea in Mar 2016 (no response).  Please start a thread on the list
to get WG opinion if it's okay for the draft to proceed as is or not.
Here's the IESG Note from RFC 6587:
>
>IESG Note
>
>The IESG does not recommend implementing or deploying syslog over
>plain tcp, which is described in this document, because it lacks
the
>ability to enable strong security [RFC3365].
>
>Implementation of the TLS transport [RFC5425] is recommended so
that
>appropriate security features are available to operators who want
to
>deploy secure syslog.  Similarly, those security features can be
>turned off for those who do not want them.
>
>
>
>
>
>  Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment
(--).
>
>  Run idnits with the --verbose option for more detailed
information about
>  the items above.
> = END =
>
> Thanks,
> Kent // shepherd
>
>
>
> ___
> 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] WGLC - draft-ietf-netmod-yang-tree-diagrams

[t.petch]

- Original Message -
From: "Robert Wilton" <rwil...@cisco.com>
Sent: Wednesday, January 17, 2018 10:44 AM

> Hi Tom,
>
>
> On 17/01/2018 09:52, t.petch wrote:
> > - Original Message -
> > From: "Alexander Clemm" <alexander.cl...@huawei.com>
> > Sent: Wednesday, January 17, 2018 2:20 AM
> >
> >> +1 to (2) as preference, followed by (1).  I don't think (3) is
needed
> > here.  The purpose is to make this human-readable and provide
readers a
> > good sense of the overall structure.
> >
> > 
> >
> > That's what I thought until Benoit said, and Robert agreed, that
> >
> > 'In the end, the tree view should be browsed with tooling.'
> The text based YANG tree diagram (i.e. covered by this draft) doesn't
> need to be browsable by tooling. The purpose of these diagrams should
> be to go in text documents to help explain and illustrate (to human
> readers) the structure of a YANG model.
>
> By "In the end, the tree view should be browsed with tooling.", what I
> mean is that I think that tools like YANG catalog will be the long
term
> way of interacting with and browsing YANG modules. For example, the
> link below for the RIP module.
>
> https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-rip
>
> This provides an interactive GUI "tree view" of a YANG model, which
> should be structurally equivalent as the text tree diagram, but
> otherwise the information may be represented in a more visual way.
This
> will become even more powerful when all of the standard YANG modules
are
> available together in a single browsable tree.
>
> Hopefully, that clarifies my previous comment.

Yes, thank you for the clarification,

Tom Petch





>
> Thanks,
> Rob
>
> >
> > i.e. the tree view should be machine readable after which something
is
> > produced for human consumption; not a view I share.
> >
> > Tom Petch
> >
> >
> > The authoritative specification is still the .yang itself.
Providing
> > some guidance for how to represent the tree is good but let's not
> > over-engineer this; I believe retaining some flexibility is good.
> >> --- Alex
> >>
> >>> -Original Message-
> >> ...
> >>>> Does anyone else have an opinion on this?  I can see three
> >>>> alternatives:
> >>>>
> >>>> 1) allow any number of addtional spaces
> >>>> 2) allow any number of addtional spaces + define a suggested
> >>>>alignment algorithm
> >>>> 3) mandate the alignment algorithm
> >>> Definition of symbols should be precise/consistent, so that
readers
> > can
> >>> consistently interpret tree diagrams.
> >>>
> >>> I think that flexibility in layout should be OK, but the draft
> > should provide
> >>> guideline to ensure the output is readable, and likely to be
broadly
> > consistent
> >>> (since consistency aids readability).
> >>>
> >>> If the IETF data modeling group is trying to specify text output
> > precisely
> >>> enough that it can be screen scraped then we may want to consider
> > whether
> >>> we are focusing on the right solution ;-)
> >>>
> >>> In summary, (2) is my preference, followed by (1), followed by
(3).
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>>
> >>>> /martin
> > .
> >
>

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[t.petch]

- Original Message -
From: "Alexander Clemm" 
Sent: Wednesday, January 17, 2018 2:20 AM

> +1 to (2) as preference, followed by (1).  I don't think (3) is needed
here.  The purpose is to make this human-readable and provide readers a
good sense of the overall structure.



That's what I thought until Benoit said, and Robert agreed, that

'In the end, the tree view should be browsed with tooling.'

i.e. the tree view should be machine readable after which something is
produced for human consumption; not a view I share.

Tom Petch


   The authoritative specification is still the .yang itself.  Providing
some guidance for how to represent the tree is good but let's not
over-engineer this; I believe retaining some flexibility is good.
>
> --- Alex
>
> > -Original Message-
> ...
> > > Does anyone else have an opinion on this?  I can see three
> > > alternatives:
> > >
> > >1) allow any number of addtional spaces
> > >2) allow any number of addtional spaces + define a suggested
> > >   alignment algorithm
> > >3) mandate the alignment algorithm
> >
> > Definition of symbols should be precise/consistent, so that readers
can
> > consistently interpret tree diagrams.
> >
> > I think that flexibility in layout should be OK, but the draft
should provide
> > guideline to ensure the output is readable, and likely to be broadly
consistent
> > (since consistency aids readability).
> >
> > If the IETF data modeling group is trying to specify text output
precisely
> > enough that it can be screen scraped then we may want to consider
whether
> > we are focusing on the right solution ;-)
> >
> > In summary, (2) is my preference, followed by (1), followed by (3).
> >
> > Thanks,
> > Rob
> >
> > >
> > >
> > > /martin

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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[t.petch]

I think that the outstanding issue is what to do with long tree
diagrams. Yes, we have discussed it and have a statement about one page
being a good idea but very few of the I-Ds I see can manage that.

RIP has four pages, NAT has six.  OSPF and BFD have divided the diagram
up but many if not most of the subdivisions still exceed one page (I
would regard two as more or less ok but many exceed that).

My own take is that a too long tree diagram reflects a too flat module
structure, just as many years ago, code would be a long unbroken
sequence and now is divided up into manageable modules, so a YANG module
should be structured as smaller pieces, bite-size chunks, and a tree
diagram of one page is a good indicator of a manageable chunk size.

Tom Petch

- Original Message -
From: "joel jaeggli" 
Sent: Monday, January 01, 2018 10:01 PM

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

 YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG 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] FW: I-D Action: draft-ietf-netmod-rfc8022bis-06.txt

[t.petch]

- Original Message -
From: "Acee Lindem (acee)" 
Sent: Wednesday, December 27, 2017 5:25 PM

> Hi Benoit,
>
> On 12/27/17, 6:18 AM, "Benoit Claise (bclaise)" 
wrote:
>
> >Thanks Acee,
> >
> >Minor question for the working group and the
draft-ietf-rtgwg-yang-rip
> >authors.
> >
> >The appendix is about adding a new control-plane protocol. It takes
as
> >an example RIP.
> >However, draft-ietf-rtgwg-yang-rip is being finalized (on the IESG
> >telechat on Jan 11th).
> >Does it make sense to keep the RIP example? If so, is the example
> >consistent with draft-ietf-rtgwg-yang-rip?
> >Or should we just point to draft-ietf-rtgwg-yang-rip as the example?
>
> It is probably better just to reference the RIP module draft. Does
anyone
> disagree?

Disagree; strongly.

You are then holding up as an example to the rest of the world of how to
do it a YANG module produced by a WG over which we have no control and
little influence and who may produce a less than satisfactory module.

I have already commented that IMHO the rip module is not fit to advance
and even if the issues are addressed we have no certainty that the
module will be fit to hold up to the world as an examplar.

So no, referencing yang-rip is a bad idea.

Tom Petch

>
> Thanks,
> Acee
> >
> >Not strong views on my side.
> >
> >Regards, Benoit
> >> This version includes Martin’s YANG doctor comments and some
updates to
> >> the examples (e.g., YANG Library data) from Lada.
> >>
> >> Thanks,
> >> Acee
> >>
> >> On 12/22/17, 1:28 PM, "netmod on behalf of
internet-dra...@ietf.org"
> >> 
wrote:
> >>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>> directories.
> >>> This draft is a work item of the Network Modeling WG of the IETF.
> >>>
> >>> Title   : A YANG Data Model for Routing Management
> >>>(NDMA
> >>> Version)
> >>> Authors : Ladislav Lhotka
> >>>   Acee Lindem
> >>>   Yingzhen Qu
> >>> Filename: draft-ietf-netmod-rfc8022bis-06.txt
> >>> Pages   : 77
> >>> Date: 2017-12-22
> >>>
> >>> Abstract:
> >>>This document contains a specification of three YANG modules
and one
> >>>submodule.  Together they form the core routing data model that
> >>>serves as a framework for configuring and managing a routing
> >>>subsystem.  It is expected that these modules will be augmented
by
> >>>additional YANG modules defining data models for control-plane
> >>>protocols, route filters, and other functions.  The core
routing
> >>>data
> >>>model provides common building blocks for such extensions --
routes,
> >>>Routing Information Bases (RIBs), and control-plane protocols.
> >>>
> >>>The YANG modules in this document conform to the Network
Management
> >>>Datastore Architecture (NMDA).  This document obsoletes RFC
8022.
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8022bis/
> >>>
> >>> There are also htmlized versions available at:
> >>> https://tools.ietf.org/html/draft-ietf-netmod-rfc8022bis-06
> >>>
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8022bis-06
> >>>
> >>> A diff from the previous version is available at:
> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc8022bis-06
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of
> >>> submission
> >>> until the htmlized version and diff are available at
tools.ietf.org.
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> ___
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >> ___
> >> 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] syslog-model-17 shepherd writeup issues -references

[t.petch]

Clyde

Sorry for being unclear

OLD
   This module imports typedefs from [RFC6021], [RFC7223], groupings
   from [RFC ], and [RFC ], and it references [RFC5424],
   [RFC5425], [RFC5426], [RFC6587], and [RFC5848].

NEW
   This module imports typedefs from [RFC6021], [RFC7223], groupings
   from [RFC ], and [RFC ], and it references [RFC5424],
   [RFC5425], [RFC5426], [RFC6587], [RFC5848], and
   [Std-1003.1-2008].

would satisfy me.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
Sent: Thursday, December 14, 2017 5:05 PM


> Tom,
>
> This does not satisfy the reference requirement?
>
> leaf pattern-match {
>   if-feature select-match;
>   type string;
>   description
> "This leaf describes a Posix 1003.2 regular expression
>  string that can be used to select a syslog message for
>  logging. The match is performed on the SYSLOG-MSG field.";
>   reference
> "RFC 5424: The Syslog Protocol
>  Std-1003.1-2008 Regular Expressions";
> }
>
> Please help me understand what more you want.
>
> Thanks,
>
> Clyde
>
> On 12/14/17, 3:55 AM, "t.petch" <ie...@btconnect.com> wrote:
>
> Clyde
>
> A quick glance at -18 shows that there is now a Normative
Reference for
> Posix - good- but I do not see it referenced - not so good:-(
>
> I think that there needs to be a reference in 4.1
>
> Tom Petch
>
>
> - Original Message -
> From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
> To: "Benoit Claise (bclaise)" <bcla...@cisco.com>; "Kent Watsen"
> <kwat...@juniper.net>; "t.petch" <ie...@btconnect.com>;
> <netmod@ietf.org>
> Cc: <draft-ietf-netmod-syslog-mo...@ietf.org>
> Sent: Wednesday, September 27, 2017 5:26 PM
> Subject: Re: [netmod] syslog-model-17 shepherd writeup
> issues -references
>
>
> > Benoit,
> >
> > There were approximately 24 changes requested from you, Kent,
Robert
> Wilton, and Tom Petch. I have made approximately half of them and
will
> try to finish another revision of the draft by Friday.
> >
> > Thanks,
> >
> > Clyde
> >
> > On 9/27/17, 3:24 AM, "Benoit Claise (bclaise)"
<bcla...@cisco.com>
> wrote:
> >
> > Clyde,
> >
> > Do you know your next step to progress this document?
> >
> > Regards, Benoit
> > > I meant to say something about the .1 vs .2 difference.
My
> comment
> > > assumes that it's supposed to be .1, but we of course
should use
> > > whatever is correct.
> > >
> > > I also don't know much about that standards body.
> > >
> > > K.
> > >
> > >
> > >
> > > - Original Message -
> > > From: "Kent Watsen" <kwat...@juniper.net>
> > > Sent: Wednesday, September 13, 2017 6:08 PM
> > >
> > >> Hi Tom,
> > >>
> > >> Thanks.  The fix I'm looking for is for the
'pattern-match'
> leaf
> > >> to have a 'reference' statement to Std-1003.1-2008, and
for
> S4.1
> > >> to also list Std-1003.1-2008 as a draft-level reference.
> > > and I am unfamiliar with that standards body so am looking
for a
> little
> > > more.
> > >
> > > Is STD- always Posix or do we need to say Posix 1003
or
> Posix
> > > Std-1003 or is Std-1003 completely unrelated to Posix
1003?
> > >
> > > Is there a difference between Std-1003.1-2008 and Posix
1003.2
> ie is the
> > > .1 or .2 significant?  You want Std-1003.1; the
description
> contains
> > > Posix 1003.2; the normative Reference is to
Std-1003.1-2008.
> > >
> > > You pointed out that the Normative Reference is not used;
well
> if we can
> > > sort out what the standard is and get the right label in
> Normative
> > > References then we can - must - include this in Section
4.1
> which will
> > > resolve that comment of yours.
> > >
> > > The discussions last July had Clyde saying he wants Posix
1003.2
> so if
> > > St

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[t.petch]

Clyde

A quick glance at -18 shows that there is now a Normative Reference for
Posix - good- but I do not see it referenced - not so good:-(

I think that there needs to be a reference in 4.1

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
To: "Benoit Claise (bclaise)" <bcla...@cisco.com>; "Kent Watsen"
<kwat...@juniper.net>; "t.petch" <ie...@btconnect.com>;
<netmod@ietf.org>
Cc: <draft-ietf-netmod-syslog-mo...@ietf.org>
Sent: Wednesday, September 27, 2017 5:26 PM
Subject: Re: [netmod] syslog-model-17 shepherd writeup
issues -references


> Benoit,
>
> There were approximately 24 changes requested from you, Kent, Robert
Wilton, and Tom Petch. I have made approximately half of them and will
try to finish another revision of the draft by Friday.
>
> Thanks,
>
> Clyde
>
> On 9/27/17, 3:24 AM, "Benoit Claise (bclaise)" <bcla...@cisco.com>
wrote:
>
> Clyde,
>
> Do you know your next step to progress this document?
>
> Regards, Benoit
> > I meant to say something about the .1 vs .2 difference.  My
comment
> > assumes that it's supposed to be .1, but we of course should use
> > whatever is correct.
> >
> > I also don't know much about that standards body.
> >
> > K.
> >
> >
> >
> > - Original Message -
> > From: "Kent Watsen" <kwat...@juniper.net>
> > Sent: Wednesday, September 13, 2017 6:08 PM
> >
> >> Hi Tom,
> >>
> >> Thanks.  The fix I'm looking for is for the 'pattern-match'
leaf
> >> to have a 'reference' statement to Std-1003.1-2008, and for
S4.1
> >> to also list Std-1003.1-2008 as a draft-level reference.
> > and I am unfamiliar with that standards body so am looking for a
little
> > more.
> >
> > Is STD- always Posix or do we need to say Posix 1003 or
Posix
> > Std-1003 or is Std-1003 completely unrelated to Posix 1003?
> >
> > Is there a difference between Std-1003.1-2008 and Posix 1003.2
ie is the
> > .1 or .2 significant?  You want Std-1003.1; the description
contains
> > Posix 1003.2; the normative Reference is to Std-1003.1-2008.
> >
> > You pointed out that the Normative Reference is not used; well
if we can
> > sort out what the standard is and get the right label in
Normative
> > References then we can - must - include this in Section 4.1
which will
> > resolve that comment of yours.
> >
> > The discussions last July had Clyde saying he wants Posix 1003.2
so if
> > Std-1003 and Posix 1003 are the same but .1 and.2 are different,
then
> > you are asking for a semantic change against Clyde's wishes.
> >
> > I hope my confusion is sufficiently clear, at least to Clyde!
> >
> > Tom Petch
> >
> >> I was going to point out the typo "the the" as well, but
figured
> >> that the RFC Editor would get it.
> >>
> >> K. // shepherd
> >>
> >>
> >> --
> >>
> >> Kent
> >>
> >> You flag Std-1003.1-2008 as listed as a normative reference but
not
> > used
> >> anywhere in the document.  In the Descriptions, but not in the
s.4.1
> >> references, I see
> >>
> >> This leaf describes a Posix 1003.2 regular expression ...
> >>
> >> twice, which may, or may not, relate to this issue.
> >>
> >> Back in July, clyde said
> >> "I will insert a normative reference to POSIX 1003.2 in the
next
> >> revision of the draft."
> >>
> >> In a similar vein, RFC6991 appears in a reference statement but
> > nowhere
> >> else.
> >>
> >> As you point out, RFC6021 is referenced but is obsoleted by
RFC6991 so
> >> should not be.
> >>
> >> And in a slightly different vein,
> >>
> >> registry [RFC7895]/>.  Following the format in [RFC7950]/>,
the the
> >>
> >> looks odd for plain text and for the repetition of 'the'..
> >>
> >> Tom Petch
> >>
> >> - Original Message -
> >> From: "Kent Watsen" <kwat...@juniper.net>
> >> To: <netmod@ietf.org>
> >> Cc: <draft-ietf-netmod-syslog-mo...@ietf.org>
>

Re: [netmod] +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

[t.petch]

- Original Message -
From: "Jiangyuanlong" <jiangyuanl...@huawei.com>
Sent: Thursday, November 09, 2017 1:58 AM

Tom,

Good to know all your viewpoints. We will add a sentence in Section 2
explaining the logic of YANG style names in this document, maybe put it
as a note in the 2nd paragraph (as these names are used in the 3rd
paragraph) .



Yuanlong,

Another belated thought.

It is common practice, and I think a good one, to include a sentence
just before the YANG module giving Normative references to other RFC
andsuch like that are referenced, implicitly or explicitly, in the
module itself (which, of course, cannot contain the references in the
same way that the rest of the RFC can).  The sentence does not become
part of the YANG module but anyone harking back to the RFC will quickly
find where to go for more information.

draft-ietf-netmod-rfc7277bis-00 gives a good example of this.  For this
I-D, I would suggest references to IEEE Std 1588-2008 and the RFC from
which ietf-interfaces is imported.

Tom Petch


Thanks,
Yuanlong

-Original Message-----
From: t.petch [mailto:ie...@btconnect.com]
Sent: Wednesday, November 08, 2017 9:12 PM
To: Jiangyuanlong; Alex Campbell; tic...@ietf.org
Cc: Xian Liu; Xujinchun; netmod@ietf.org
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules
is woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for
this I-D.

One fresh comment arising from that.  You commented earlier that you had
departed from IEEE 1588-2008 in changing camel case to the YANG style
names, with hyphens, and I think that that is a logical choice.  But I
would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put
that; probably Section 2, perhaps immediately before the tree diagram,
since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would
be worth having a concordance of IEEE 1588-2008 names and YANG names;
this was common practice with MIB Modules.

Tom Petch

- Original Message -
From: "Jiangyuanlong" <jiangyuanl...@huawei.com>
To: "Alex Campbell" <alex.campb...@aviatnet.com>; <tic...@ietf.org>
Cc: "Xian Liu" <lene.liux...@foxmail.com>; "Xujinchun"
<xujinc...@huawei.com>; <netmod@ietf.org>
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


> Hi Alex,
>
> Sorry for a late reply as I spent the last week for an urgent business
trip.
> Please see my comments in line with [YJ]
>
> Thanks,
> Yuanlong
>
> -Original Message-
> From: Alex Campbell [mailto:alex.campb...@aviatnet.com]
> Sent: Monday, October 30, 2017 10:15 AM
> To: Jiangyuanlong; tic...@ietf.org
> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
>
> Hi,
> I've reviewed this latest draft and have some more comments.
>
> 1. I find the introduction to be unnecessarily wordy; it feels like it
was written with a view of not missing any information out, rather than
trying to keep it concise.
>For example, there is no need to elaborate on YANG data types here.
It is also not here to sell YANG.
>
> [YJ] Yes, we are trying to give some introductory information for an
outsider who may not be familiar with PTP or YANG, and explain why a
YANG for PTP is needed. The juicy part of this document is its YANG
module, and people can skip all the other texts if they are familiar
with PTP and YANG.
> Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear
message from the TICTOC chairs to introduce any big changes at this last
call stage.
>
>
> OLD:
>
>As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>supported in the carrier networks, industrial networks, automotive
>networks, and many other applications. It can provide high
>precision time synchronization as fine as nano-seconds. The
>protocol depends on a Precision Time Protocol (PTP) engine to
>decide its own state automatically, and a PTP transportation layer
>to carry the PTP timing and various quality messages. The
>configuration parameters and state data sets of IEEE 1588-2008 are
>numerous.
>
>According to the concepts described in [RFC3444], IEEE 1588-2008
>itself provides an information model in its normative
&g

Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

[t.petch]

Yuanglong

I think that your Introduction is fine, and would not shorten it at all.
(I think that the Introduction to most I-Ds that describe YANG modules
is woefully weak).

I think too that you are spot on with your terminology; where IEEE
1588-2008 has an accepted way of working, then that is the right way for
this I-D.

One fresh comment arising from that.  You commented earlier that you had
departed from IEEE 1588-2008 in changing camel case to the YANG style
names, with hyphens, and I think that that is a logical choice.  But I
would go further and explain that choice so that those coming from IEEE
1588-2008 understand what has happened and why.  Not sure where to put
that; probably Section 2, perhaps immediately before the tree diagram,
since that is when readers will be exposed to the issue.

If you have done more than just change the style of name, then it would
be worth having a concordance of IEEE 1588-2008 names and YANG names;
this was common practice with MIB Modules.

Tom Petch

- Original Message -
From: "Jiangyuanlong" 
To: "Alex Campbell" ; 
Cc: "Xian Liu" ; "Xujinchun"
; 
Sent: Tuesday, November 07, 2017 7:53 AM
Subject: Re: [netmod] WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06


> Hi Alex,
>
> Sorry for a late reply as I spent the last week for an urgent business
trip.
> Please see my comments in line with [YJ]
>
> Thanks,
> Yuanlong
>
> -Original Message-
> From: Alex Campbell [mailto:alex.campb...@aviatnet.com]
> Sent: Monday, October 30, 2017 10:15 AM
> To: Jiangyuanlong; tic...@ietf.org
> Cc: Xian Liu; Xujinchun; netmod@ietf.org
> Subject: Re: WG Last Call resolutions incorporated in
draft-ietf-tictoc-1588v2-yang-06
>
> Hi,
> I've reviewed this latest draft and have some more comments.
>
> 1. I find the introduction to be unnecessarily wordy; it feels like it
was written with a view of not missing any information out, rather than
trying to keep it concise.
>For example, there is no need to elaborate on YANG data types here.
It is also not here to sell YANG.
>
> [YJ] Yes, we are trying to give some introductory information for an
outsider who may not be familiar with PTP or YANG, and explain why a
YANG for PTP is needed. The juicy part of this document is its YANG
module, and people can skip all the other texts if they are familiar
with PTP and YANG.
> Besides, these texts have been contributed by multiple sources and
undergone several rounds of reviews, thus I will wait for a clear
message from the TICTOC chairs to introduce any big changes at this last
call stage.
>
>
> OLD:
>
>As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
>supported in the carrier networks, industrial networks, automotive
>networks, and many other applications. It can provide high
>precision time synchronization as fine as nano-seconds. The
>protocol depends on a Precision Time Protocol (PTP) engine to
>decide its own state automatically, and a PTP transportation layer
>to carry the PTP timing and various quality messages. The
>configuration parameters and state data sets of IEEE 1588-2008 are
>numerous.
>
>According to the concepts described in [RFC3444], IEEE 1588-2008
>itself provides an information model in its normative
>specifications for the data sets (in IEEE 1588-2008 clause 8). Some
>standardization organizations including the IETF have specified
>data models in MIBs (Management Information Bases) for IEEE 1588-
>2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
>typically focused on retrieval of state data using the Simple
>Network Management Protocol (SNMP), furthermore, configuration of
>PTP data sets is not considered in [RFC8173].
>
>Some service providers and applications require that the management
>of the IEEE 1588-2008 synchronization network be flexible and more
>Internet-based (typically overlaid on their transport networks).
>Software Defined Network (SDN) is another driving factor, which
>demands an improved configuration capability of synchronization
>networks.
>
>YANG [RFC6020] is a data modeling language used to model
>configuration and state data manipulated by network management
>protocols like the Network Configuration Protocol (NETCONF)
>[RFC6241]. A small set of built-in data types are defined in
>[RFC6020], and a collection of common data types are further
>defined in [RFC6991]. Advantages of YANG include Internet based
>configuration capability, validation, rollback and so on. All of
>these characteristics make it attractive to become another
>candidate modeling language for IEEE 1588-2008.
>
> NEW:
>
>IEEE 1588-2008 is a time protocol that provides high precision time
>synchronization as fine as nano-seconds.
>
>IEEE 

Re: [netmod] Action and RPC statements

[t.petch]

 Original Message -
From: "Juergen Schoenwaelder" 
To: "Martin Bjorklund" 
Cc: 
Sent: Monday, November 06, 2017 2:01 PM
> On Mon, Nov 06, 2017 at 02:19:24PM +0100, Martin Bjorklund wrote:
> >
> > Trying to summarize this issue.
> >
> > The problem is which datastore is used to:
> >
> > 1a. evaluate action ancestor nodes
> > 1b. evaluate action input/output parameter leafref,
> > instance-identifier, must, when
> > 2.  evaluate rpc input/output parameter leafref,
> > instance-identifier, must, when
> >
> > (Note that the side effects of an action/rpc is not part of this
> > issue)
> >
> > I think it would be very weird if 1a and 1b were treated
differently,
> > so I just label them as 1 below.
> >
> > Possible solutions:
> >
> > A.  Always use  for 1 and 2.
> >
> > (This is what the current nmda draft says).
> >
> > B.  Let the client specify the datastore for 1, and use

> > for 2.
> >
> > (Note that this is trivial in RESTCONF (since the datastore is
> > part of the URL), but would require a new parameter for NETCONF
> > (or a new ).
> >
> > C.  Let the client specify the datastore for 1 and 2.
> >
> > This would require a new generic parameter for how RPCs are
> > invoked in both NETCONF and RESTCONF.
> >
> > D.  Like B, but let the description of the "rpc" statement
optionally
> > override this.
> >
> >
> > I prefer B and then D.
>
> I prefer A for now and I believe any of the other options may be
> considered in the future (when we can provide proper support of YANG
> and the protocols). I also believe that A covers a large number of
> real-world use cases.

I prefer A.  I think it is the simplest and the one least likely to have
consequences that were not anticipated.  You could see this discussion
as being one of unanticipated consequences so I want the least change to
solve the problem, while thinking about what B (or C or D, roughly the
order of increasing uncertainty) really involves.

Tom Petch

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

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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many

[t.petch]

- Original Message -
From: "Andy Bierman" <a...@yumaworks.com>
To: "Lou Berger" <lber...@labn.net>
Sent: Friday, October 27, 2017 8:56 PM

> On Fri, Oct 27, 2017 at 12:40 PM, Lou Berger <lber...@labn.net> wrote:
>
> > On 10/27/2017 01:20 PM, Juergen Schoenwaelder wrote:
> > > Why do we come up with such rules in the first place? It really
> > > depends on the modules and their relationship and it is the
> > > responsibility of the WG, the authors, the reviewers to produce a
> > > reasonable document.
> > >
> >
> > My personal view - Because having a few knowledgeable people doesn't
> > scale and not all model writers are at the IETF.
> >
> It is easy to add a guideline that says "a YANG tree diagram MAY be
pruned
> if it is too verbose, in order to improve readability.".
>
> Not so easy to define "too verbose" or define what should be pruned.
> This is where I agree with Juergen. The authors and reviewers have the
> responsibility to make these decisions.

A personal take on the size of tree diagrams, based on experience.

One page, as the I-D suggests, fine.

Over five pages, probably of little or no value.

Two or more pages; take steps to reduce, the steps mentioned in the I-D
already, looking for logically separate parts (as per RFC7317), reducing
tree depth, collapsing groupings (probably with a separate tree for each
grouping, which may in turn need to have these rules applied) 

I think that the tree diagrams I see from the Routing Area are pretty
dire, on account of their size, and that this WG can see that already
whereas other WGs may take a year or two to cotton on.

I am an engineer - I want something that works!

Tom Petch

> > Lou
> >
>
>
> Andy
>
>
> >
> > > /js
> > >
> > > On Fri, Oct 27, 2017 at 06:08:31PM +0100, t.petch wrote:
> > >> Lou
> > >>
> > >> Suggested text
> > >>
> > >> NEW
> > >>
> > >> 3.3 One Document Several Modules
> > >>
> > >> When a document contains several YANG modules, all the tree
diagrams
> > >> should be placed together, before all the modules.  Each tree
diagram
> > >> should be preceded by a brief introduction to highlight where one
tree
> > >> diagram ends and another starts.
> > >>
> > >> If a document contains a single module which is logically a
number of
> > >> distinct components, the same strategy should be followed;
RFC7317
> > >> provides a good example of this approach.
> > >>
> > >> /NEW
> > >>
> > >> Like Juergen, I am conflicted as to at what point details like
this
> > >> should be part of rfc6087bis; I think a paragraph like this does
belong
> > >> in 'tree-diagrams'.
> > >>
> > >> Tom Petch
> > >>
> > >> - Original Message -
> > >> From: "Lou Berger" <lber...@labn.net>
> > >> To: "t.petch" <ie...@btconnect.com>; <netmod@ietf.org>
> > >> Sent: Friday, October 27, 2017 1:38 PM
> > >>
> > >>> Tom,
> > >>>
> > >>>
> > >>> On 10/27/2017 7:08 AM, t.petch wrote:
> > >>>> Lou
> > >>>>
> > >>>> On a slightly different tack, so a slightly modified Subject:
line,
> > >>>> when an I-D contains multiple modules, some place all the
models
> > >>>> together and then all the modules, e.g.
> > >>>> draft-hares-i2nsf-capability-data-model-04 while others
intersperse
> > >> the
> > >>>> models and the modules, e.g. draft-ietf-lisp-yang-05 .
> > >>>>
> > >>>> I think the former is superior and should be recommended,
especially
> > >>>> when, as Sue has done, there is a brief paragraph of text
before
> > >> each
> > >>>> model, so it is very clear where a model ends and another
begins.
> > >> With
> > >>>> the latter, models can be hard to find.
> > >>>
> > >>>> I see this as dovetailing into Juergen's comments on RFC7317
which,
> > >> to
> > >>>> me, is really several separate modules packaged as one, so the
> > >>>> separation makes excellent sense to a reader.
> > >>>>
> > >>>> Where the I-D is already several modules, then do as RFC7317
has
> > >> done.
> > >>>

Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many

[t.petch]

Lou

Suggested text

NEW

3.3 One Document Several Modules

When a document contains several YANG modules, all the tree diagrams
should be placed together, before all the modules.  Each tree diagram
should be preceded by a brief introduction to highlight where one tree
diagram ends and another starts.

If a document contains a single module which is logically a number of
distinct components, the same strategy should be followed; RFC7317
provides a good example of this approach.

/NEW

Like Juergen, I am conflicted as to at what point details like this
should be part of rfc6087bis; I think a paragraph like this does belong
in 'tree-diagrams'.

Tom Petch

- Original Message -
From: "Lou Berger" <lber...@labn.net>
To: "t.petch" <ie...@btconnect.com>; <netmod@ietf.org>
Sent: Friday, October 27, 2017 1:38 PM

> Tom,
>
>
> On 10/27/2017 7:08 AM, t.petch wrote:
> > Lou
> >
> > On a slightly different tack, so a slightly modified Subject: line,
> > when an I-D contains multiple modules, some place all the models
> > together and then all the modules, e.g.
> > draft-hares-i2nsf-capability-data-model-04 while others intersperse
the
> > models and the modules, e.g. draft-ietf-lisp-yang-05 .
> >
> > I think the former is superior and should be recommended, especially
> > when, as Sue has done, there is a brief paragraph of text before
each
> > model, so it is very clear where a model ends and another begins.
With
> > the latter, models can be hard to find.
>
> > I see this as dovetailing into Juergen's comments on RFC7317 which,
to
> > me, is really several separate modules packaged as one, so the
> > separation makes excellent sense to a reader.
> >
> > Where the I-D is already several modules, then do as RFC7317 has
done.
> Sure, Do you have text you'd like to propose?
>
>
> > Tom Petch
> >
> > - Original Message -
> > From: "Lou Berger" <lber...@labn.net>
> > To: <netmod@ietf.org>
> > Sent: Wednesday, October 25, 2017 2:13 PM
> >
> >> Hi,
> >>
> >> This version addresses all known / open issues in the draft known
to
> >> the authors.
> >>
> >> The changes are as follows:
> >> - Added groupings and yang-data descriptions
> >> - Added Comments, Long Diagrams and Security Considerations
sections
> >> - Clarified representation of schema mount points and
representation
> > of
> >> modules exposed using schema mount.
> >> - Miscellaneous editorial changes
> >>
> >> Lou (for draft authors)
> >>
> >> On 10/25/2017 8:49 AM, internet-dra...@ietf.org wrote:
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >>> This draft is a work item of the Network Modeling WG of the IETF.
> >>>
> >>> Title   : YANG Tree Diagrams
> >>> Authors : Martin Bjorklund
> >>>   Lou Berger
> >>> Filename: draft-ietf-netmod-yang-tree-diagrams-02.txt
> >>> Pages   : 11

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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size

[t.petch]

- Original Message -
From: "Mahesh Jethanandani" <mjethanand...@gmail.com>
To: "t.petch" <ie...@btconnect.com>
Sent: Thursday, October 26, 2017 6:35 PM

> On Oct 26, 2017, at 9:50 AM, t.petch <ie...@btconnect.com> wrote:
>
> Lou
>
> I like the advice that diagrams should be one page long but wonder how
> to apply that to those I see in routing WGs.  I have just been looking
> at
>
> draft-ietf-teas-yang-te-topo-12
>
> where the diagram is 36 pages long - which may be one of the larger
ones
> but by no means exceptional - and I think the diagram is  more or less
> useless as a result.  But what practical advice can we give them?

How about using the depth of the —tree-depth option to generate smaller
trees that may not give the whole tree, but at least give you a nice
overview? Follow that with smaller chunks using the —tree-path for each
section of the tree.



Yes!  That is what I do manually when I really really want to understand
and refer to a module - but it is time consuming and tedious.

I look to have a top level of less than a page and lower levels which
may be bigger.

I think that this also interacts with groupings.  If a tree diagram with
groupings expanded is 6 pages and one without the expansion is 2 pages
plus one for the grouping, then I would prefer the latter.  YMMV but I
think that there is a guideline in there somewhere.

Tom Petch

>
> I append the diagram below
>
> Tom Petch
>
>
> start of diagram
> ==
.

>+--ro altitude?int64
>+--ro latitude?geographic-coordinate-degree
>+--ro longitude?   geographic-coordinate-degree
>
>
>
> =
> end of diagram
>
> - Original Message -
> From: "Lou Berger" <lber...@labn.net>
> To: <netmod@ietf.org>
> Sent: Wednesday, October 25, 2017 2:13 PM
> Subject: Re: [netmod] I-D Action:
> draft-ietf-netmod-yang-tree-diagrams-02.txt
>
>
>> Hi,
>>
>> This version addresses all known / open issues in the draft known to
>> the authors.
>>
>> The changes are as follows:
>> - Added groupings and yang-data descriptions
>> - Added Comments, Long Diagrams and Security Considerations sections
>> - Clarified representation of schema mount points and representation
> of
>> modules exposed using schema mount.
>> - Miscellaneous editorial changes
>>
>> Lou (for draft authors)
>>
>> On 10/25/2017 8:49 AM, internet-dra...@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>>> This draft is a work item of the Network Modeling WG of the IETF.
>>>
>>>Title   : YANG Tree Diagrams
>>>Authors : Martin Bjorklund
>>>  Lou Berger
>>> Filename: draft-ietf-netmod-yang-tree-diagrams-02.txt
>>> Pages   : 11
>>> Date: 2017-10-25
>>>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt one or many

[t.petch]

Lou

On a slightly different tack, so a slightly modified Subject: line,
when an I-D contains multiple modules, some place all the models
together and then all the modules, e.g.
draft-hares-i2nsf-capability-data-model-04 while others intersperse the
models and the modules, e.g. draft-ietf-lisp-yang-05 .

I think the former is superior and should be recommended, especially
when, as Sue has done, there is a brief paragraph of text before each
model, so it is very clear where a model ends and another begins.  With
the latter, models can be hard to find.

I see this as dovetailing into Juergen's comments on RFC7317 which, to
me, is really several separate modules packaged as one, so the
separation makes excellent sense to a reader.

Where the I-D is already several modules, then do as RFC7317 has done.

Tom Petch

- Original Message -
From: "Lou Berger" 
To: 
Sent: Wednesday, October 25, 2017 2:13 PM

> Hi,
>
> This version addresses all known / open issues in the draft known to
> the authors.
>
> The changes are as follows:
> - Added groupings and yang-data descriptions
> - Added Comments, Long Diagrams and Security Considerations sections
> - Clarified representation of schema mount points and representation
of
> modules exposed using schema mount.
> - Miscellaneous editorial changes
>
> Lou (for draft authors)
>
> On 10/25/2017 8:49 AM, internet-dra...@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> > This draft is a work item of the Network Modeling WG of the IETF.
> >
> > Title   : YANG Tree Diagrams
> > Authors : Martin Bjorklund
> >   Lou Berger
> > Filename: draft-ietf-netmod-yang-tree-diagrams-02.txt
> > Pages   : 11
> > Date: 2017-10-25
> >
> > Abstract:
> >This document captures the current syntax used in YANG module
Tree
> >Diagrams.  The purpose of the document is to provide a single
> >location for this definition.  This syntax may be updated from
time
> >to time based on the evolution of the YANG language.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-02
> >
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagra
ms-02
> >
> > A diff from the previous version is available at:
> >
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-0
2
> >
> >
> > Please note that it may take a couple of minutes from the time of
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> ___
> 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] I-D Action: draft-ietf-netmod-yang-tree-diagrams-02.txt size

[t.petch]

Lou

I like the advice that diagrams should be one page long but wonder how
to apply that to those I see in routing WGs.  I have just been looking
at

 draft-ietf-teas-yang-te-topo-12

where the diagram is 36 pages long - which may be one of the larger ones
but by no means exceptional - and I think the diagram is  more or less
useless as a result.  But what practical advice can we give them?

I append the diagram below

Tom Petch


start of diagram
==


Liu, et al Expires January 17, 2018   [Page 31]


6. Tree Structure

   module: ietf-te-topology
   augment /nw:networks/nw:network/nw:network-types:
  +--rw te-topology!
   augment /nw:networks:
  +--rw te!
 +--rw templates
+--rw node-template* [name] {template}?
|  +--rw name   te-types:te-template-
   name
|  +--rw priority?  uint16
|  +--rw reference-change-policy?   enumeration
|  +--rw te-node-attributes
| +--rw admin-status?te-types:te-admin-status
| +--rw domain-id?   uint32
| +--rw is-abstract? empty
| +--rw name?inet:domain-name
| +--rw signaling-address*   inet:ip-address
| +--rw underlay-topology {te-topology-hierarchy}?
|+--rw network-ref?   leafref
+--rw link-template* [name] {template}?
   +--rw name   te-types:te-template-
   name
   +--rw priority?  uint16
   +--rw reference-change-policy?   enumeration
   +--rw te-link-attributes
  +--rw access-type?  te-types:te-
   link-access-type
  +--rw external-domain
  |  +--rw network-ref?leafref
  |  +--rw remote-te-node-id?  te-types:te-node-id
  |  +--rw remote-te-link-tp-id?   te-types:te-tp-id
  |  +--rw plug-id?uint32
  +--rw is-abstract?  empty
  +--rw name? string
  +--rw underlay {te-topology-hierarchy}?
  |  +--rw enabled? boolean
  |  +--rw primary-path
  |  |  +--rw network-ref?leafref
  |  |  +--rw path-element* [path-element-id]
  |  | +--rw path-element-iduint32
  |  | +--rw index? uint32



  |  | +--rw (type)?
  |  |+--:(numbered)
  |  ||  +--rw numbered-hop
  |  || +--rw address?te-types:te-tp-id
  |  || +--rw hop-type?   te-hop-type
  |  |+--:(as-number)
  |  ||  +--rw as-number-hop
  |  || +--rw as-number?   binary
  |  || +--rw hop-type?te-hop-type
  |  |+--:(unnumbered)
  |  ||  +--rw unnumbered-hop
  |  || +--rw node-id?  te-types:te-
   node-id
  |  || +--rw link-tp-id?   te-types:te-tp-
   id
  |  || +--rw hop-type? te-hop-type
  |  |+--:(label)
  |  ||  +--rw label-hop
  |  || +--rw value?   rt-types:generalized-
   label
  |  |+--:(sid)
  |  |   +--rw sid-hop
  |  |  +--rw sid?   rt-types:generalized-
   label
  |  +--rw backup-path* [index]
  |  |  +--rw index   uint32
  |  |  +--rw network-ref?leafref
  |  |  +--rw path-element* [path-element-id]
  |  | +--rw path-element-iduint32
  |  | +--rw index? uint32
  |  | +--rw (type)?
  |  |+--:(numbered)
  |  ||  +--rw numbered-hop
  |  || +--rw address?te-types:te-tp-id
  |  || +--rw hop-type?   te-hop-type
  |  |+--:(as-number)
  |  ||  +--rw as-number-hop
  |  || +--rw as-number?   binary
  |  || +--rw hop-type?te-hop-type
  |  |+--:(unnumbered)
  |  ||  +--rw unnumbered-hop
  |  || +--rw node-id?  te-types:te-
   node-id
  |  || +--rw link-tp-id?   te-types:te-tp-
   id
  |  || +--rw hop-type? 

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

[t.petch]

Igor

Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.

I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).

The DNS approach works very well, in fact I do not think we would
survive without it.

Tom Petch

- Original Message -
From: "Igor Bryskin" 
Sent: Tuesday, October 10, 2017 2:35 PM

Hi Rob,

This helps a lot. What you wrote will work.

The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.

Thanks a lot,
Igor

c

From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netc...@ietf.org,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:
> Hi Per,
>
> This is a good news, but, please, help us out.
> Consider, we have a node - "te-tunnel" - which among other attributes
has two key leafref lists:
> 1) each member of the 1st list points to a "connection" supporting the
te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.
> 2) each member of the 2nd list points to a supporting "te-tunnel" -
the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.
>
> The question: how the client can retrieve via a single request all
attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

   /te/tunnels/tunnel[name='foo'] |

/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
ns/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.

>
> Likewise, how the client can ask for full data of the te-tunnel and
all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
this:

   /te/tunnels/tunnel[name='foo'] |

/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
s/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.

I hope that this is of some help,
Rob


>
> I really appreciate your help,
>
> Igor
>
>
> -Original Message-
> From: Per Hedeland [mailto:p...@tail-f.com]
> Sent: Monday, October 09, 2017 5:21 PM
> To: Igor Bryskin
> Cc: m...@tail-f.com; xufeng.liu.i...@gmail.com; netc...@ietf.org;
netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
>
> Just to be clear: what we're suggesting is that you can use the
> already-existing standard NETCONF XPath capability to achieve the
desired
> result - see https://tools.ietf.org/html/rfc6241#section-8.9
>
> --Per
>
> On 2017-10-09 21:52, Igor Bryskin wrote:
>> I agree. For example, a leafref may point not to a singls entity, but
to a list of entities, and the client might want to expand all of them
into the joint get response.
>>
>> Igor
>>
>> *From:*Per Hedeland
>> *To:*Martin Bjorklund,
>> *Cc:*Igor
Bryskin,xufeng.liu.i...@gmail.com,netc...@ietf.org,netmod@ietf.org,
>> *Date:*2017-10-09 15:12:22
>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
>>
>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>> Igor Bryskin  wrote:
 Hi Per,

 Basically, what we need is a way for a client to request something
 like this:

 get  joint with 
>>> ... which is what Per's expression does!  Note that "|" in XPath
means
>>> "union".
>>>
>>> But as Per explained, it only works in some cases (when the 

Re: [netmod] handling module incompatibility

[t.petch]

- Original Message -
From: "Lou Berger" 
Sent: Friday, October 06, 2017 2:25 PM

> As part of the my Routing Directorate review of
> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
> changes being made to the ietf-l3vpn-svc module without changing the
> name. I raised this with the YANG doctors and others involved with the
> draft and it surfaced some topics which really should be discussed
here
> in NetMod.
>
> The background (as explained off-list by others, so I hope I have it
> right) is that one of the YANG Doctors noted that RFC8049 was broken
> and could not be implemented as defined, and therefore a fix was
> needed. L3SM has concluded so the fix is in the individual draft
> draft-wu-l3sm-rfc8049bis. Since the rfc8049 version of ietf-l3vpn-svc
> module could not be implemented, the feeling by the YANG Dr was that
> even though the new module is incompatible with the original
definition
> the module the rule defined in Section 11 of YANG 1.1 (or section 10
of
> RFC 6020) didn't have to be followed and the same name could be used.
>
> In the subsequent discussion with the YANG Drs., the general
discussion
> was heading down the path of using a new module name, and thereby not
> violating YANG module update rules. This lead us back to the a similar
> discussion we've been having in the context of 8022bis: how best to
> indicate that a whole module is being obsoleted. RFCs do this by
adding
> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
> help YANG tooling. For 8022, we have one approach - publishing an
> updated rev of the original module marking all nodes as deprecated -
but
> that doesn't really make sense for rfc8049bis.
>
> So the discussion for the WG is:
>
> How do we handle incompatible module changes, notably when one module
> 'obsoletes' another module -- from both the process and tooling
> perspectives?

Add a new substatement to the module statement, 'obsoletes' or
'supersedes'or such like..

And I mean write the RFC now, do not wait for a future version or
revision of RFC7950.

Tom Petch

> I know Benoit plans to bring in some thoughts/proposals, perhaps there
> are others.
>
> Cheers,
>
> Lou
>
> (as contributor/reviewer)
>
>

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

Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt

[t.petch]

- Original Message -
From: "Ladislav Lhotka" 
Sent: Thursday, October 05, 2017 1:52 PM
> Martin Bjorklund  writes:
>
> > This version fixes the XPath context for parent-reference.
> >
> > However, there is one more thing to discuss, which is the term
"mount
> > point".
> >
> > The current text says:
> >
> >- mount point: container or list node whose definition contains
> >  the "mount-point" extension statement. The argument of the
> >  "mount-point" statement defines the name of the mount point.
> >
> > So if we have:
> >
> >   container top {
> > container root {
> >   yangmnt:mount-point ni;
> > }
> >   }
> >
> > There is one mount point, the node /top/root, with the name "ni".
> >
> > Pretty confusing...   Does anyone have any comments around this?
>
> What about this?
>
> OLD
>
> - mount point: container or list node whose definition contains
>   the "mount-point" extension statement. The argument of the
>   "mount-point" statement defines the name of the mount point.
>
> NEW
>
> - mount point: container or list node whose definition contains
>   the "mount-point" extension statement. The argument of the
>   "mount-point" statement defines a label that is used for
>   referencing the mount point.

Lada

Trouble is 'label' is not a defined term in RFC7950 which leaves me (and
others) wondering what is this undefined concept.  I know plenty of
languages that have the concept of a label but YANG is not one of them.

I looked to see what the ABNF says for inspiration but there isn't
any:-)  I think that there should be.

I looked for a worked example for inspiration, nope, none of them
either!   What I mean is that in e.g. A.3  mount point with name root
appears, but that is the only instance of 'root'.  The whole point is
that root should appear more than once, once for where the mount will
be, and then once or more times for the part that will be mounted, so an
example where name appears once is not an example IMHO!

Tom Petch

> Lada
>
> >
> >
> >
> > /martin
> >

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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

[t.petch]

- Original Message -
From: "Kent Watsen" 
Sent: Monday, October 02, 2017 9:06 PM

> The Last Call for this document has completed with *no* responses,
other than Benoit's question regarding if it should be a BCP, which also
had no responses, other than my own wondering if YANG (and hence the
guidelines) was stable enough.
>
> Lou and I discussed.  It is our opinion that, given the nature of this
document, the WG implicitly supports it already.  So, really, the only
thing that matters, is if there are any issues/concerns.  Since no
issues/concerns were raised, we choose to declare the Last Call
successful.  As for promoting it to a BCP, there appears to be no
consensus to do so at this time.   Accordingly, as the document
shepherd, I plan to send the shepherd write-up (with these comments
included) to the AD in the next few days.

Kent

The trouble is that a number of other things have been going on, mostly
NMDA and the
ramifications thereof, and so this one never moved up my todo list.

Yes, it is an I-D that matters, the timing is unfortunate.

Tom Petch


> Looking forwards, we've created a new GitHub repo called
"guidelines-next" (modeled after yang-next) to capture on-going
comments/suggestions for future updates to the document:
https://github.com/netmod-wg/guidelines-next.
>
> Kent (and Lou)
>
>
>
> ___
> 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

[t.petch]

Robert

I would like you to tweak the definition of running configuration
datastore slightly.

You say

" The running configuration datastore () is a configuration
  datastore that holds the complete current configuration
  on the device"

which I see as black and white, the terminology is .

But then you say

"This datastore is commonly referred to
  as "".

which I see as introducing wiggle room with the use of 'commonly' so I
would like you to excise 'commonly' leaving

NEW
This datastore is referred to as "".

Black and white.

Tom Petch

- Original Message -
From: "Robert Wilton" <rwil...@cisco.com>
Sent: Thursday, September 28, 2017 10:37 AM
>
> After comment from the other authors, an updated proposed description
> for  is as follows:
>
> OLD:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> NEW:
>
> 4.1.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () is aconfiguration
>   datastore that holds the complete current configuration
>   on the device. It may include configuration that requires further
>   transformation before it can be applied, e.g., inactive
>   configuration, or template-mechanism-oriented configuration that
>   needs further expansion. However,  MUST always be a 'valid
>   configuration data tree' as defined in Section 8.1 of [RFC7950].
>
>MUST be supported if the device can be configured via
>   conventional configuration datastores.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
>
> Given that the definition of  and  are being
updated,
> I think that the definitions should similarly be updated. Hence I
propose:
>
>
>
> OLD:
>   o running configuration datastore: A configuration datastore holding
>   the current configuration of the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion. This datastore is commonly referred to
>   as "".
>
> NEW (based on the new description of running above):
>   o running configuration datastore: A configuration datastore holding
>   the current configuration of the device. It may include
>   configuration that requires furthertransformations before it can
>   be applied. This datastore is commonly referred to
>   as "".
>
>
>
> OLD:
>
>   o intended configuration: Configuration that is intended to be used
>   by the device. For example, intended configuration excludes any
>   inactive configuration and it would include configuration produced
>   through the expansion of templates.
>
>
> NEW (based on the proposed updated description of intended):
>
>   o intended configuration: Configuration that is intended to be used
>   by the device. It represents the configuration after all
>   configuration transformations to  have been performed and
>   is the configuration that the system attempts to apply.
>
>
>
> It may also be helpful if we define "configuration transformation", or
> would that be better captured in the introduction text?
>
> A possible definition could be along the lines of:
>
>   configuration transformation: The addition, modification or removal
of
>   configuration between the  and  datastores.
>   Examples of configuration transformations include the removal of
>   inactive configuration and the configuration produced through the
>   expansion of templates.
>
> If I don't hear anything back, I'll take that as a tacit approval of
> these proposed changes.
>
> Thanks,
> Rob
>
>
> On 22/09/2017 18:12, Robert Wilton wrote:
> > Hi Tom,
> >
> >
> > On 22/09/2017 17:34, t.petch wrote:
> >> Robert
> >>
> >> I wonder if this says the opposite of what is intended
> >>
> >> -  holds the complete current configuration on the device.
> > I agree.
> >
> >>
> >> - This could include inactiveconfiguration
> > I agree.
> >
> >>
> >> -  must always be a 'valid configuration data tree' as
> >> defined in Section 8.1 of [RFC7950].
> > I agree.
> >
> >>
> >> Ergo, inactiveconfigu

Re: [netmod] vs

[t.petch]

Robert

I wonder if this says the opposite of what is intended

-  holds the complete  current configuration on the device.

- This could include inactiveconfiguration

 -  must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

Ergo, inactiveconfiguration must form part of a valid configuration
tree.

I thought the idea was that inactiveconfiguration was logically removed
before validation but this seems to state the opposite..

Tom Petch

- Original Message -
From: "Robert Wilton" 
Sent: Friday, September 22, 2017 10:03 AM

> Hi,
>
> Regarding whether  is always valid, the proposed modification
> to the draft is to add the following text to section 4.3 that
describes
> :
>
> OLD:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> NEW:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. This could, for example,
include
>   inactiveconfiguration or template-mechanism-oriented configuration
>   thatrequires further expansion.However,  must always be a
>   'valid configuration data tree' as defined in Section 8.1 of
[RFC7950].
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> END
>
>
> Then the intention is that if inactive or a templating solution is
> standardized then those drafts would update the validation rules in
RFC
> 7950 such that  is still valid. E.g. an inactive config draft
> would probably indicate that validation excludes all configuration
nodes
> that are marked as inactive.
>
> Does anyone have any comments?
>
> Do we also need to state that  must always be a 'valid
> configuration data tree'?
>
> Thanks,
> Rob
>
>
> On 19/09/2017 16:22, Robert Wilton wrote:
> >
> >
> > 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 

Re: [netmod] Broadband Forum NMDA Questions

[t.petch]

For those who wonder, the text of the liaison  (slightly mangled by code
page issues) is as follows (I know what advice I would give but am
probably in a minority there on this list:-))

Broadband Forum NMDA Questions

Body

Dear all,

The Broadband Forum has been considering the impact of NMDA (Network
Management Datastore Architecture) on its YANG work.

Many of our standard and draft YANG modules are dependent on the
ietf-interfaces (RFC 7223) and ietf-hardware (draft-ietf-netmod-entity)
YANG
modules, both of which will be impacted by NMDA. Therefore we need to
decide
whether (and, if so, how) we should update our published and draft YANG
modules. We see three possible approaches:
- Ignore NMDA, relying on the fact that updated IETF YANG modules will
retain backwards compatibility.
- Embrace NMDA, updating all our YANG modules to use single trees (no
separate state trees).
- Support NMDA, while retaining backwards compatibility in the same way
as IETF YANG modules will do so.

Our decision will be affected by:
- Our level of confidence that NMDA will be the "last big change" to the
way in
which IETF YANG modules are written.
- The timescales on which NMDA-compliant versions of the ietf-interfaces
and ietfhardware YANG modules will be published as RFCs (we note that
NMDA-compliant versions of these modules are now available).

We would much appreciate your feedback on our analysis of the possible
approaches and on our concerns as expressed above.

Sincerely
Michael Fargano
Broadband Forum Technical Committee Chair

CC:
David Sinicrope, BBF / IETF Liaison Officer/Manager,
 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 


  StatementHistoryStatePosted
  Posted Date2017-09-20
  From GroupBROADBAND-FORUM
  From ContactMichael Fargano
  To Groupsnetmod, OPS
  To ContactsWarren Kumari
  Benoit Claise
  Jürgen Schönwälder
  Tom Nadeau
  CcDavid Sinicrope
  Kent Watsen
  Warren Kumari
  The IETF Chair
  Lou Berger
  Benoit Claise
  Network Modeling Discussion List
  Response contactmichael.farg...@centurylink.com
  david.sinicr...@ericsson.com
  PurposeFor comment
  Deadline2017-11-27 Action Needed
  Attachments41;.final

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

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

[t.petch]

- Original Message -
From: "Robert Wilton" <rwil...@cisco.com>
Sent: Wednesday, September 20, 2017 12:04 PM

> On 20/09/2017 11:18, t.petch wrote:
> > - Original Message -
> > From: "Ladislav Lhotka" <lho...@nic.cz>
> > Sent: Tuesday, September 19, 2017 2:37 PM
> >
> >> Martin Bjorklund <m...@tail-f.com> writes:
> >>
> >>> Ladislav Lhotka <lho...@nic.cz> wrote:
> >>>>
> >>>> 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.
> > So add a second node!  I think that the idea that NMDA eliminates
all
> > duplication of config and state is a myth; there will still be
> > duplication where the life cycle of the data diverges, ie it is not
> > really duplication! I think too that the twin trees approach, while
> > clumsy, was easy to create;
> Easy to create, but just as easy to get wrong. Alas, with the twin
> trees approach, the config and state trees can (and do) diverge.
> Different WGs within IETF were already starting to model the state
> information with different tree structures. Some WG models includes
the
> applied config value, others didn't. We seemed to be loosing
> consistency between the model. My opinion is that the end outcome of
> this would effectively require all clients to write custom code to
> correlate equivalent information between the config and its related
> state, which doesn't seem great.
>
> >   the NMDA approach is more subtle, more
> > complex, easier to get wrong.
> Yes, I agree the NMDA approach is a bit more subtle. And there are
> definitely some concepts that probably should be modeled slightly
> differently:
>
> A case in point might be "interface MTU" that can be automatically
> assigned (the default behaviour) or statically configured.
>
> (1) A pre-NMDA split config/state model might have:
> - a config true interfaces/mtu leaf that is either "auto" or a
specific
> value,
> - a config false interfaces-state/mtu leaf holding the actual
> operational value,
> - [potentially also a config false interfaces-state/cfgd-mtu leaf
> indicating the applied config value.]
>
> (2) One way of modelling this in NMDA would be to split whether mtu
was
> auto vs manually configured separately from the mtu value. So this
> could be modeled as:
> - one config true leaf that represents with MTU is automatic or
manually
> configured.
> --one config true leaf that represents the manually configured and
> operational MTU value. Allow with an appropriate constraint so that
> both leaves are not configured.
>
> (3) Alternatively, in both pre NMDA or post NMDA, the model could
assume
> "automatic" as the implicit default MTU behaviour. In this case you
> only need to have a single leaf i

Re: [netmod] schema mount open issue #1 terminology

[t.petch]

Martin

Since you are doing an update, you might consider updating the
definitions to point to the  NMDA I-D
rather than RFC6241 although configuration data is not defined in
RFC7950 or NMDA.

Tom Petch


- Original Message -
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Wednesday, September 13, 2017 12:20 PM
Subject: Re: [netmod] schema mount open issue #1


Hi,

Lou Berger  wrote:
> Hi,
>
> The LNI/NI authors/RTG Area DT met yesterday and discussed the
proposed
> change as well as the other topics that came up in the subsequent
> discussion. The high order bit is that the proposed and current
> definitions are adequate for our needs. Read further if you care about
> details, including confirming our understanding:
>
> 1) WRT xpath context change proposed by martin
>
> Our understanding is that absolute paths continue to be allowed

Yes, this is correct.

> , for
> example the following remains valid:
>
> "use-schema": [
> {
> "name": "ni-schema",
> "parent-reference": [
> "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
> ]
> }
> ]
>
> Assuming yes, then we have no objection to the change (as it allows
the
> server implementor to choose how/if they support vrf name filtering.
> Obviously, using the new syntax exposes the restriction to the client
> which is probably desirable.)
>
> 2. parent-reference location is adequate for our needs.
> This said, we think parent-references are more appropriately contained
> within the schema list and having them there will yield less complex
> operational data.
>
> 3. current mount point extension usage definition (must be in a list
or
> container).
> Our use case is covered by always having a single mount point
contained
> in a container. We don't see the need for mount point extensions
within
> lists or for there to ever be siblings of mount point extensions.
>
> We don't see a need to discuss items 2 and 3 further at this time.
> Assuming our understanding is correct, we will update the NI and LNE
> draft as soon as schema mount is updated as proposed.

Ok, since we haven't seen any objections to the proposal, I will
update the schema mount draft accordingly.


/martin


>
> Lou
> (as contributor and NI/LNE draft co-author)
>
>
> On 8/30/2017 5:29 AM, Lou Berger wrote:
> > FYI I've asked folks in the routing area, i.e., the ietf users of
schema
> > mount, if they have an opinion on the node discussion. I will also
do so on
> > the point I raised on parent reference location. (Which is
independent from
> > your format change.) Clearly, if I'm the only one to be raising
objections,
> > I'll be the one in the rough on these points.
> >
> > Thanks,
> >
> > Lou
> > - as contributor
> >
> >
> > On August 30, 2017 3:42:26 AM Martin Bjorklund 
wrote:
> >
> >> Ladislav Lhotka  wrote:
> >>> Lou Berger  writes:
> >>>
>  Lada,
> 
> 
>  On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> > Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
> >> [...]
> >>
> >> PS is your view aligned with martin or our example?
> > If you mean shifting the XPath context node to the mount point
instance,
> >>> then
> > yes.
> >> So, going back to the original issue; does anyone have any
objection
> >> to changing the XPath context for parent-reference as describied in
my
> >> original post?
> >>
> >>
> >> /martin
> >>
>
___
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

[t.petch]

- Original Message -
From: "Ladislav Lhotka" 
Sent: Tuesday, September 19, 2017 2:37 PM

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

So add a second node!  I think that the idea that NMDA eliminates all
duplication of config and state is a myth; there will still be
duplication where the life cycle of the data diverges, ie it is not
really duplication! I think too that the twin trees approach, while
clumsy, was easy to create; the NMDA approach is more subtle, more
complex, easier to get wrong.

I recall that in the initial stages of discussion of this issue there
was a proposal for an object to have potentially eight different
characteristics so what NMDA gives us at present is limited and will not
solve all the issues of needing more than one node.

Tom Petch








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

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

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

[t.petch]

- Original Message -
From: "Martin Bjorklund" 
Sent: Tuesday, September 19, 2017 2:42 PM

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

A union is what might be termed the OSI approach to design, an approach
that led to ... well, ISIS and that's about it.

draft-ietf-isis-yang-isis-cfg-18 has some 10 pages of tree structure
which are of little help to me in understanding the module.

With draft-ietf-teas-yang-te-topo-12, the tree structure
runs to over 35 pages and then I think that the tree structure has
failed.

Adding more symbols will not help.

Less is More.

Tom Petch

> > >>> Since a parent
> > >>> reference can be very specific, e.g. one specific interface, it
isn't
> > >>> really accurate to show:


___
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" <m...@tail-f.com>
Sent: Monday, September 18, 2017 8:58 AM


> "t.petch" <ie...@btconnect.com> wrote:
> > - Original Message -
> > From: "Martin Bjorklund" <m...@tail-f.com>
> > Sent: Sunday, September 17, 2017 2:41 PM
> >
> > > Andy Bierman <a...@yumaworks.com> 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] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates

[t.petch]

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

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.

Tom Petch


> /martin

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

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

[t.petch]

- Original Message -
From: "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de>
Sent: Friday, September 15, 2017 6:09 PM


> Two comments:
>
> - Obviously, inactive can be in  and I would not rule out
>   that inactive configuration can be in any other or future
>   configuration datastores.
>
> - Whether protocols support inactive or not does not belong into a
>   definition of what inactive configuration is. The same for backwards
>   compatibility considerations etc.
>
> So if we define inactive configuration, the definition should be
> something like this:
>
> * inactive configuration: Configuration held in a configuration
>   datastore that is marked to be inactive. Inactive configuration is
>   ignored during validation and never applied and actively used by
>   a device.
>
> Yes, we should use 'inactive configuration' everywhere to be
consistent.

Juergen

Yes, your definition is better than mine; let's add it.

Tom Petch

> /js
>
> On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
> > Inactive appears a dozen times but is not defined, except in the
course
> > of those appearances it effectively is, but is sometimes 'inactive',
> > sometimes 'inactive configuration', sometimes 'inactive data'.
> >
> > I would find it clearer if the term was used consistently and if
there
> > was an explicit definition amongst the other definitions in section
2
> > such as
> >
> > inactve configuration: Configuration that is present in 
which
> > is not in use by the device and which plays no part in validation.
It
> > cannot appear in any other datastore.  The protocols that are
currently
> > standardised do not support inactive configuration but a number of
> > proprietary protocols do. Inactive configuration is only exposed to
> > clients that indicate support for inactive configuration; clients
not
> > indicating support for  inactive configuration receive the contents
of
> >  with the inactive configuration removed.
> >
> > This would put a stake in the ground for as and when the concept is
> > standardised and may reduce the proliferation of the term with
multiple
> > meanings.
> >
> > Tom Petch
> >
> >
> > - Original Message -
> > From: "Lou Berger" <lber...@labn.net>
> > Sent: Friday, September 01, 2017 10:02 PM
> >
> > > This starts a two week working group last call on
> > > draft-ietf-netmod-revised-datastores-04.
> > >
> > > The working group last call ends on September 17.
> > > 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://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 <http://www.jacobs-university.de/>

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

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

[t.petch]

- Original Message -
From: "Joe Clarke" 
Sent: Friday, September 15, 2017 2:50 PM

> On 9/15/17 09:21, Juergen Schoenwaelder wrote:
> > On Fri, Sep 15, 2017 at 02:54:31PM +0200, Benoit Claise wrote:
> >
> >> Now, if you are already a YANG expert, I guess you don't use the
> >> tree output much.
> >
> > I think this has nothing to do with YANG experience. The intention
of
> > the tree format was to provide a concise overview of the structure
of
> > the schema tree. If we start to include type specifics that can get
> > very detailed, the diagrams loose their value.
>
> I agree that clutter is bad.  I had the same reservation, but I am
also
> working with models and sharing information with people where a tree
> that has a _bit_ more information would be useful.
>
> I agree that showing this by default will be messy in some cases.  And
> maybe this has moved to a question more for you, Martin, in pyang's
> GitHub channel.  But if this output were put behind an option, would
you
> entertain a PR?

Joe

Less is more.

I agree with Andy, Martin and Lada that it has got too cluttered.

And as for line length, I cannot recall when last I read an I-D that did
not break the rules for RFC.

Tom Petch





>
> Joe
>
> ___
> 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] upcoming adoptions - this appendix is normative

[t.petch]

- Original Message -
From: "Lou Berger" <lber...@labn.net>
Sent: Thursday, September 14, 2017 6:06 PM

> On 9/14/2017 12:36 PM, t.petch wrote:
> > Appendices are Normative if they say that they are Normative.  The
> > default is that they are not so say that they are and they are.
This is
> > well established practice.
>
> Hi Tom,
> My memory (I haven't checked recently) is there is nothing in or
> defined process that says if an Appendix is normative or not. Other
> SDOs certainly have formal definitions here. Within the IETF, my view
> has been that if an appendix includes RFC2119 language, it is
> normative. Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.

Lou

Try RFC4910.

'   This appendix is normative. '

and not a SHOULD or a MUST in sight.

Tom Petch

> Lou
>

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

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

[t.petch]

Inactive appears a dozen times but is not defined, except in the course
of those appearances it effectively is, but is sometimes 'inactive',
sometimes 'inactive configuration', sometimes 'inactive data'.

I would find it clearer if the term was used consistently and if there
was an explicit definition amongst the other definitions in section 2
such as

inactve configuration: Configuration that is present in  which
is not in use by the device and which plays no part in validation.  It
cannot appear in any other datastore.  The protocols that are currently
standardised do not support inactive configuration but a number of
proprietary protocols do. Inactive configuration is only exposed to
clients that indicate support for inactive configuration; clients not
indicating support for  inactive configuration receive the contents of
 with the inactive configuration removed.

This would put a stake in the ground for as and when the concept is
standardised and may reduce the proliferation of the term with multiple
meanings.

Tom Petch


- Original Message -
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM

> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> 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://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-revised-datastores-04 guessing

[t.petch]

Looking at a YANG module in future, how can I tell whether or not it is
written to work with revised datastores?

If the module is written assuming revised datastores and the environment
does not support this in some regard, then we have a management
malfunction, which could be disastrous.

I think that there should be some mechanistic way, something that can be
automated, for a system to check whether or not a module is assuming
revised datastores or not.  This is a bit like the change from YANG 1.0
to YANG 1.1; there needs to be a way of telling what environment the
module is written for, and so we have the

yang-version 1.1;

statement.

Revised datastores needs something similar in the module.

Tom Petch


- Original Message -
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM


> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> 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://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-revised-datastores-04 updates

[t.petch]

This I-D updates RFC7950, since it changes the XPath context that YANG
uses, yet there is no mention of 'Updates'

Well, a purist will say that people can create and use  models using
RFC7950 with no need to have any understanding of this I-D so
technically no 'Updates' is needed.

But a practical engineer will say that the expectation is that many, if
not most, future models will rely on this I-D and its updates to RFC7950
so to say that you do not need to know about it is just misleading.

I am in the latter camp.

I thought of alternatives.  It is true that new models will have a
Normative Reference to this I-D but I suspect that that will not be
enough to alert users.

RFC6087bis could mention it but that is aimed at producers rather than
consumers who are the ones affected.

So. pragmatically, I think that this I-D needs an 'Updates'.

Tom Petch

- Original Message -
From: "Lou Berger" 
To: "netmod WG" 
Cc: ;

Sent: Friday, September 01, 2017 10:02 PM
Subject: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04


> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> 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://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-revised-datastores-04 duplicaiton

[t.petch]

Lou

I am proposing that the text I included would go more or less as is into
the beginning of section 3.  I think that it makes sense even before we
get into the historic definitions of configuration etc.  I want to spell
out the problem - two different values of the one conceptual object,
originally handled with two schema nodes in one store of data, now
handled with one schema node in two datastores.  Thus start section 3
with

NEW

Some data objects can take two different values, the one configured by
the user (configuration), the other the one that the device is using
(operational state),
perhaps as a result of interactions with hardware, with protocols, with
other devices and so on.

 The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and, since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach, such as can be seen in RFC7277 or RFC7223.

This duplication of definitions and separation of operationsl state from
configuration leads to a number of problems.  Having them in
 separate branches in the data model is operationally
complicated and impacts the readability of module
 definitions.  The relationship between
 the branches is not machine readable and filter expressions operating
on configuration and on related operational state are different.

With revised datastores,  the data object appears once in the model
but can appear in two datastores, one for the
configured value, one for the operational state value.

 Instead of two YANG data nodes there is one data node in two
datastores, a more elegant and simpler solution to the problem.

/NEW

I would make minor changes to the last three paragraphs of Section 3
mostly excising where I have already included that material

Tom Petch

> >
> > The problem that is hinted at but never explicitly stated is that
data
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >separate branch in the data model has been found to be
operationally
> >complicated and impacts the readability of module
> >definitions.  The relationship between
> >the branches is not machine readable and filter expressions
operating
> >on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >
ta
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >separate branch in the data model has been found to be
operationally
> >complicated and impacts the readability of module
> >definitions.  The relationship between
> >the branches is not machine readable and filter expressions
operating
> >on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >

Tom Petch

- Original Message -
From: "Lou Berger" <lber...@labn.net>
To: "t.petch" <ie...@btconnect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-cha...@ietf.org>;
<draft-ietf-netmod-revised-datasto...@ietf.org>
Sent: Wednesday, September 13, 2017 5:56

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[t.petch]

- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, September 13, 2017 6:08 PM

> Hi Tom,
>
> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
> to also list Std-1003.1-2008 as a draft-level reference.

and I am unfamiliar with that standards body so am looking for a little
more.

Is STD- always Posix or do we need to say Posix 1003 or Posix
Std-1003 or is Std-1003 completely unrelated to Posix 1003?

Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
.1 or .2 significant?  You want Std-1003.1; the description contains
Posix 1003.2; the normative Reference is to Std-1003.1-2008.

You pointed out that the Normative Reference is not used; well if we can
sort out what the standard is and get the right label in Normative
References then we can - must - include this in Section 4.1 which will
resolve that comment of yours.

The discussions last July had Clyde saying he wants Posix 1003.2 so if
Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
you are asking for a semantic change against Clyde's wishes.

I hope my confusion is sufficiently clear, at least to Clyde!

Tom Petch

>
> I was going to point out the typo "the the" as well, but figured
> that the RFC Editor would get it.
>
> K. // shepherd
>
>
> --
>
> Kent
>
> You flag Std-1003.1-2008 as listed as a normative reference but not
used
> anywhere in the document.  In the Descriptions, but not in the s.4.1
> references, I see
>
> This leaf describes a Posix 1003.2 regular expression ...
>
> twice, which may, or may not, relate to this issue.
>
> Back in July, clyde said
> "I will insert a normative reference to POSIX 1003.2 in the next
> revision of the draft."
>
> In a similar vein, RFC6991 appears in a reference statement but
nowhere
> else.
>
> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
> should not be.
>
> And in a slightly different vein,
>
>registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>
> looks odd for plain text and for the repetition of 'the'..
>
> Tom Petch
>
> - Original Message -
> From: "Kent Watsen" 
> To: 
> Cc: 
> Sent: Tuesday, September 12, 2017 10:50 PM
> Subject: [netmod] syslog-model-17 shepherd writeup issues
>
>
> > Clyde, all,
> >
> > In reviewing the draft for Shepherd writeup, I found the following
> issues that I think need to be addressed before the document can be
sent
> to Benoit for AD review:
> >
> >
> > 1. Idnits found the following:
> >
> >   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
> (--).
> >
> > ** There are 2 instances of too long lines in the document, the
> longest one
> >  being 3 characters in excess of 72.
> >
> > ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC
6991)
> >
> > ** Downref: Normative reference to an Historic RFC: RFC 6587
> >
> > == Missing Reference: 'RFC5425' is mentioned on line 359, but
not
> defined
> >  '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'
> >
> >  == Unused Reference: 'RFC7895' is defined on line 1406, but no
> explicit
> >   reference was found in the text
> >   '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,
"YANG
> Module L...'
> >
> >  == Unused Reference: 'RFC6242' is defined on line 1435, but no
> explicit
> >   reference was found in the text
> >   '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol
over
> Secure Sh...'
> >
> >
> > 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
> "@-mm-dd" in its name
> >
> > 3.  neither `pyang` nor `yanglint` found any errors with
> ietf-syslog.yang.pyang says
> >   for vendor-syslog-types-example: statement "identity" must
have
> a "description"
> >   substatement.
> >
> > 4. testing the examples in the draft against yanglint:
> >   - for both examples: Missing element's "namespace". (/config)
> >   - just removing the "" element envelop resolves this
> error.
> >
> > 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
> SHOULD be a
> >  domain name (e.g., foo.example.com)
> >
> > 6. in the YANG module, anywhere you have an RFC listed in a
> 'description' statement,
> >  there should be a 'reference' statement for that RFC.
> >
> > 7. in the tree diagram, the leafrefs no longer indicate what they
> point at, they now all
> >  just say "leafref".  Did you do this on purpose, or are you
using
> a different tree
> >  output generator from -15?
> >
> > 8. RFC6536 is listed as a normative reference, but it probably
should
> be informative.
> >
> > 9. Std-1003.1-2008 is listed as a normative reference, but it is not
> used anywhere in the document.
> >
> > 10. RFC6242 is listed as an informative reference, but it is not
used
> anywhere in the document.
> >
> 

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

[t.petch]

I think that in one respect, perhaps the key respect, this I-D fails to
state the obvious (or at least what is likely obvious to those who have
been at this for a while:-).

The problem that is hinted at but never explicitly stated is that data
objects can appear both as configuration and as state, e.g. when learned
by other means or at other times.  The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach such as can be seen in RFC7277 or RFC7223.

Amongst other problems, this separation of operational state from
configuration in a
   separate branch in the data model has been found to be operationally
   complicated and impacts the readability of module
   definitions.  The relationship between
   the branches is not machine readable and filter expressions operating
   on configuration and on related operational state are different.

With revised datastores, there is a single data object to model both
values  but this now appears in two datastores, one for the
configuration value, one for the operational state value.

Instead of two YANG data nodes there is one data node in two datastores,
a more elegant and simpler solution to the problem.


I believe that text such as this would make the I-D much easier to
follow.  As it stands, you have to read between the lines and speculate.

Tom Petch


- Original Message -
From: "Lou Berger" 
To: "netmod WG" 
Cc: ;

Sent: Friday, September 01, 2017 10:02 PM

> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> 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://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] syslog-model-17 shepherd writeup issues -references

[t.petch]

Kent

You flag Std-1003.1-2008 as listed as a normative reference but not used
anywhere in the document.  In the Descriptions, but not in the s.4.1
references, I see

This leaf describes a Posix 1003.2 regular expression ...

twice, which may, or may not, relate to this issue.

Back in July, clyde said
"I will insert a normative reference to POSIX 1003.2 in the next
revision of the draft."

In a similar vein, RFC6991 appears in a reference statement but nowhere
else.

As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
should not be.

And in a slightly different vein,

   registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the

looks odd for plain text and for the repetition of 'the'..

Tom Petch

- Original Message -
From: "Kent Watsen" 
To: 
Cc: 
Sent: Tuesday, September 12, 2017 10:50 PM
Subject: [netmod] syslog-model-17 shepherd writeup issues


> Clyde, all,
>
> In reviewing the draft for Shepherd writeup, I found the following
issues that I think need to be addressed before the document can be sent
to Benoit for AD review:
>
>
> 1. Idnits found the following:
>
>   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
(--).
>
> ** There are 2 instances of too long lines in the document, the
longest one
>  being 3 characters in excess of 72.
>
> ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)
>
> ** Downref: Normative reference to an Historic RFC: RFC 6587
>
> == Missing Reference: 'RFC5425' is mentioned on line 359, but not
defined
>  '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]'
>
>  == Unused Reference: 'RFC7895' is defined on line 1406, but no
explicit
>   reference was found in the text
>   '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG
Module L...'
>
>  == Unused Reference: 'RFC6242' is defined on line 1435, but no
explicit
>   reference was found in the text
>   '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over
Secure Sh...'
>
>
> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
"@-mm-dd" in its name
>
> 3.  neither `pyang` nor `yanglint` found any errors with
ietf-syslog.yang.pyang says
>   for vendor-syslog-types-example: statement "identity" must have
a "description"
>   substatement.
>
> 4. testing the examples in the draft against yanglint:
>   - for both examples: Missing element's "namespace". (/config)
>   - just removing the "" element envelop resolves this
error.
>
> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
SHOULD be a
>  domain name (e.g., foo.example.com)
>
> 6. in the YANG module, anywhere you have an RFC listed in a
'description' statement,
>  there should be a 'reference' statement for that RFC.
>
> 7. in the tree diagram, the leafrefs no longer indicate what they
point at, they now all
>  just say "leafref".  Did you do this on purpose, or are you using
a different tree
>  output generator from -15?
>
> 8. RFC6536 is listed as a normative reference, but it probably should
be informative.
>
> 9. Std-1003.1-2008 is listed as a normative reference, but it is not
used anywhere in the document.
>
> 10. RFC6242 is listed as an informative reference, but it is not used
anywhere in the document.
>
> 11. the document fails to declare its normative references to
ietf-keystore and ietf-tls-client-server.
> Note: you manually entered the "[RFC ], and [RFC ]"
references…
>
> 12.  The IANA considerations section seems asymmetric.  Either put
both registry insertions into
> subsections, or keep them both at the top-level…
>
> 13. reviewing the final document against my original YD review, I have
the following responses.  Let's be sure to close out these items as
well.  Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
s-0gOfCe8NSE
>
> 1. ok
> 2. better
> 3. should be: s/the message/these messages/  [RFC Editor might've
caught this]
> 4. better
> 5. still feel the same way, but no biggee
> 6. better, but from 8174, you should add the part "when, and only
when, they appear in all capitals, as shown here."
> 7. fixed
> 8. fixed
> 9. you did what I asked, but the result still isn't satisfying...
> 10. some improvements made in this area, but my ask wasn't among them
> 11. better
> 12. better, but I think the 4th line should be indented too, right?
> 13. better, but I wish you called S1.3 "Tree Diagram Notation"
> 14. fixed
> 15. fixed
> 16. fixed
> 17. fine
> 18. still a weird line brake here.  try putting the quoted string on
the next line.
> 19. fixed
> 20. fixed
> 21. not fixed (re: yang-security-guidelines)
> 22. fine
>
>
> PS: please also be sure to follow-up with Benoit on his AD review.
>
> Thanks,
> Kent  // shepherd & yang doctor
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org

Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

[t.petch]

- Original Message -
From: "Ladislav Lhotka" <lho...@nic.cz>
Sent: Wednesday, August 23, 2017 11:53 AM

> "t.petch" <ie...@btconnect.com> writes:
>
> > - Original Message -
> > From: "Robert Wilton" <rwil...@cisco.com>
> > Sent: Monday, August 21, 2017 4:14 PM
> >
> >> That makes sense.

> >>
> >> Of course, this would allow more invalid values, but most servers
> > would
> >> be expected to reject those when it converts them into an internal
> >> binary format any way.
> >>
> >> What do you, and others, think?
> >
> > Simplify!
> >
> > Bear in mind that the regex for an IPv6 address was wrong for a long
> > time in base YANG before anyone noticed - it was just too complex.
>
> Why was it wrong? Just because it was too complex?

No; it contained a definite error.

This was probably in yang-types and probably around 2012, quite late in
the day, and it stuck in my mind that so many had looked at it and
failed to spot that it was wrong, not just that it did not cater for
some aspects such as interface I-D.  I have used it before as an example
of over complexity

I will have the e-mail filed, along with several thousand other NETMOD
ones so I will find it later rather than sooner.

Tom Petch



> >
> > And ABNF learnt long ago that just because something could be
expressed
> > in code does not mean that it is a good idea to do so.  If a simple
> > English statement replaces many lines of ABNF, then that is a good
> > tradeoff.
>
> Well, YANG models are also intended to be read by tools that so far
> don't understand English statements. Concerning human users, the
easiest
> thing might be to refer to a corresponding RFC, which the descriptions
> already do.
>
> >
> > Pragmatically I am not sure what the cutoff for complexity should be
but
> > it should be less than we have now.
> >
> > Paradoxically, given the original thread, the time when large
> > expressions may work ok is when they have a 'sub-module' like
structure,
> > when I can look at a group of lines in isolation and form a view of
what
> > it does then move on to the next group and so on, building up an
overall
> > picture piece by piece.
>
> Of course, regular expression languages are notorically human
> unfriendly, no matter what flavour we take. The ability to build them
> step by step from reusable pieces, e.g. using non-terminals, would
> certainly help.
>
> Lada
>
> >
> > Tom Petch
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >> On 21/08/2017 15:01, Acee Lindem (acee) wrote:
> >> > Hi William, Rob, Andy,
> >> >
> >> > Given their limited usefulness and the detriments, perhaps we
should
> >> > discourage the creation of new submodules in RFC6087Bis.
> >> >
> >> > Thanks,
> >> > Acee
> >> >
> >> > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
> >> > <netmod-boun...@ietf.org on behalf of william.iv...@intl.att.com>
> > wrote:
> >> >
> >> >> Hi Rob,
> >> >>
> >> >> That would make it very hard to update existing 1.x YANG models
to
> > use
> >> >> new features in YANG 2.x if they used submodules.  Maybe that's
> > something
> >> >> that no one would ever consider doing anyway, or maybe YANG 1.1
> > already
> >> >> has similar differences to 1.0?  I had (perhaps naively) assumed
> > that you
> >> >> could migrate a namespace / model from YANG 1.0 to 2.0?
> >> >>
> >> >> Regards,
> >> >>
> >> >> William
> >> >>
> >> >> -Original Message-
> >> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of
Robert
> > Wilton
> >> >> Sent: 21 August 2017 11:24
> >> >> To: netmod@ietf.org
> >> >> Subject: Re: [netmod] Query about augmenting module from
submodule
> > in
> >> >> YANG 1.0
> >> >>
> >> >>
> >> >>
> >> >> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> >> >>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka
wrote:
> >> >>>> I remember that in early stages of YANG there was some
irrational
> >> >>>> fear of introducing too many namespaces, and submodules may be
a
> >> >>>> consequence of it. As you write, submodules provide no
benefits
> >&g

Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

[t.petch]

- Original Message -
From: "Robert Wilton" 
Sent: Monday, August 21, 2017 4:14 PM

> That makes sense.
>
> The other thing that I think that we have got wrong is modelling regex
> pattern statements.  I think that it would be much better if these
were
> written to be less exhaustive and much simpler.
>
> E.g. the "route distinguisher" pattern in
> draft-ietf-rtgwg-routing-types-09 is defined as this:
>
>   pattern
> '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>   + '6[0-4][0-9]{3}|'
>   + '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>   + '42949672[0-8][0-9]|'
>   + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>   + '42949[0-5][0-9]{4}|'
>   + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>   + '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>   + '[0-3]?[0-9]{0,8}[0-9]))|'
>   + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>   + '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>   + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>   + '655[0-2][0-9]|'
>   + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>   + '[0-5]?[0-9]{0,3}[0-9]))|'
>   + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>   + '4294967[01][0-9]{2}|'
>   + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>   + '4294[0-8][0-9]{5}|'
>   + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>   + '[0-3]?[0-9]{0,8}[0-9]):'
>   + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>   + '6[0-4][0-9]{3}|'
>   + '[0-5]?[0-9]{0,3}[0-9]))|'
>   + '(6(:[a-fA-F0-9]{2}){6})|'
>   + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>   + '[0-9a-fA-F]{1,12})';
> }
>
> But I think that it would be much easier to read, and quite possibly
> more performant to execute, if the pattern regex was written something
> like the following:
>
>   pattern:
>  '(0:[0-9]{1,5}:[0-9]{1,10})|
>   (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>   (2:[0-9]{1,10}:0:[0-9]{1,5})|
>   (6(:[a-fA-F0-9]{2}){6})';
>
> Of course, this would allow more invalid values, but most servers
would
> be expected to reject those when it converts them into an internal
> binary format any way.
>
> What do you, and others, think?

Simplify!

Bear in mind that the regex for an IPv6 address was wrong for a long
time in base YANG before anyone noticed - it was just too complex.

And ABNF learnt long ago that just because something could be expressed
in code does not mean that it is a good idea to do so.  If a simple
English statement replaces many lines of ABNF, then that is a good
tradeoff.

Pragmatically I am not sure what the cutoff for complexity should be but
it should be less than we have now.

Paradoxically, given the original thread, the time when large
expressions may work ok is when they have a 'sub-module' like structure,
when I can look at a group of lines in isolation and form a view of what
it does then move on to the next group and so on, building up an overall
picture piece by piece.

Tom Petch

> Thanks,
> Rob
>
>
> On 21/08/2017 15:01, Acee Lindem (acee) wrote:
> > Hi William, Rob, Andy,
> >
> > Given their limited usefulness and the detriments, perhaps we should
> > discourage the creation of new submodules in RFC6087Bis.
> >
> > Thanks,
> > Acee
> >
> > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
> > 
wrote:
> >
> >> Hi Rob,
> >>
> >> That would make it very hard to update existing 1.x YANG models to
use
> >> new features in YANG 2.x if they used submodules.  Maybe that's
something
> >> that no one would ever consider doing anyway, or maybe YANG 1.1
already
> >> has similar differences to 1.0?  I had (perhaps naively) assumed
that you
> >> could migrate a namespace / model from YANG 1.0 to 2.0?
> >>
> >> Regards,
> >>
> >> William
> >>
> >> -Original Message-
> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert
Wilton
> >> Sent: 21 August 2017 11:24
> >> To: netmod@ietf.org
> >> Subject: Re: [netmod] Query about augmenting module from submodule
in
> >> YANG 1.0
> >>
> >>
> >>
> >> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> >>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>  I remember that in early stages of YANG there was some irrational
>  fear of introducing too many namespaces, and submodules may be a
>  consequence of it. As you write, submodules provide no benefits
>  whatsoever in terms of modularity, but the overhead in terms of
>  metadata, IANA registration etc. is pretty much the same as for
>  modules.
> >>> In case YANG 2.0 is ever done, I suggest someone files a proposal
to
> >>> remove submodules if the cost/benefit ratio is at odds. There is
> >>> nothing wrong with removing stuff that has been found problematic.
> >> I agree.
> 

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 references

[t.petch]

Clyde

What  concerns me most is that AFAICT anything that is referenced in a
YANG module is a Normative Reference in the RFC that defines it and you
do not have those two I-D in the list of references.

Since they have not been published, then they would appear as I-Ds in
the references and the RFC Editor knows to on the one hand, hold up the
publication of the referring I-D until until the references become RFC,
and on the other hand insert the RFC number when they do.

I note that in other modules, I see no RFC for an import.  Strictly one
is not needed since the name should be unique and can be derefenced but
it is nice to have (SNMP usually has it).

But as I say, it is the lack of Normative Reference that worries me
most.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
To: "t.petch" <ie...@btconnect.com>; "Kent Watsen"
<kwat...@juniper.net>; <netmod@ietf.org>
Sent: Wednesday, August 09, 2017 5:53 PM

> Tom,
>
> The agreement was that I should use “” until the two unapproved
RFCs that the model depends on are assigned numbers.
>
>  RFC : Keystore Management
>  RFC : Transport Layer Security (TLS) Client";
>
> Imported are:
>
>   import ietf-tls-client {
> prefix tlsc;
>   }
>
>   import ietf-keystore {
> prefix ks;
>   }
>
>
> Have numbers been assigned?
>
> Thanks,
>
> Clyde
>
> On 8/9/17, 4:32 AM, "t.petch" <ie...@btconnect.com> wrote:
>
> Clyde
>
> You use  as a placeholder for three different RFC and two of
these
> do not appear AFAICT in the list of References.
>
> This might be a challenge for the RFC Editor.
>
> Tom Petch
>
>
> - Original Message -
> From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
> Sent: Wednesday, July 19, 2017 6:48 PM
>
>
> > Hi Alex,
> >
> > Answers inline as [clyde]…
> >
> > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
> <netmod-boun...@ietf.org on behalf of alex.campb...@aviatnet.com>
wrote:
> >
> > I am considering to implement the data model in this draft.
> (dependent on business priorities of course)
> > I have reviewed this draft and found the following issues.
> >
> > * I see pattern-match is specified to use POSIX 1003.2
regular
> expressions. This is presumably for compatibility with existing
> implementations; however it is inconsistent with most of YANG
(which is
> specified to use XPath regular expressions) - unless these are the
same.
> >
> > [clyde] I believe that my answer in the other thread explains
why we
> used Posix 1003.2 – it is commonly used.
> >
> > * pattern-match is inside the facility-filter container;
common
> sense says this is wrong as pattern-match has nothing to do with
> facilities.
> >
> > [clyde] I will move pattern-match up one level in the next
version of
> the draft. Thanks for catching this!
> >
> > * The advanced-compare container groups together two nodes
that
> share a common "when" and "if-feature" statement, but don't seem
to have
> any semantic relation to each other. Are there general guidelines
on
> when to use a container?
> >
> > [clyde] The confusion may come as a result of the when clause
> appearing before the if-feature clause which is set by the IETF
> statement order recommendation.
> >
> > The when construct was suggested by Martin Björklund as a way of
> solving the case that advanced-compare does not apply for the ‘all
’ and
> ‘none’ case.
> >
> > The if-feature applies to the entire container – it is either
> supported or not.
> >
> > * The advanced-compare container has a description starting
with
> "This leaf ..." even though it is not a leaf.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * The examples are missing  nodes.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * Perhaps there should be more consistent terminology for
> receivers of syslog messages; both "collectors" and "actions" are
used
> in the draft. RFC 5424 uses "collector" for the ultimate recipient
of a
> log message - which might not be applicable, because the sending
system
> has no idea whether the receiving system is a collector or a
relay.
> >
> > [clyde] T

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[t.petch]

Clyde

As Kent says, I would prefer to see only one  with others being 
or some such.

Further, I think that this RFC  to be should be in the list of
References.

Adding it there would then solve my additional problem of which I-D you
have in mind.  There are two relating to key management and neither are
titled Keystore Management:-(  I can guess which you mean but I do not
think that I should be guessing!

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
To: "t.petch" <ie...@btconnect.com>; "Kent Watsen"
<kwat...@juniper.net>; <netmod@ietf.org>
Sent: Wednesday, August 09, 2017 5:53 PM
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15


> Tom,
>
> The agreement was that I should use “” until the two unapproved
RFCs that the model depends on are assigned numbers.
>
>  RFC : Keystore Management
>  RFC : Transport Layer Security (TLS) Client";
>
> Imported are:
>
>   import ietf-tls-client {
> prefix tlsc;
>   }
>
>   import ietf-keystore {
> prefix ks;
>   }
>
>
> Have numbers been assigned?
>
> Thanks,
>
> Clyde
>
> On 8/9/17, 4:32 AM, "t.petch" <ie...@btconnect.com> wrote:
>
> Clyde
>
> You use  as a placeholder for three different RFC and two of
these
> do not appear AFAICT in the list of References.
>
> This might be a challenge for the RFC Editor.
>
> Tom Petch
>
>
> - Original Message -
> From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
> Sent: Wednesday, July 19, 2017 6:48 PM
>
>
> > Hi Alex,
> >
> > Answers inline as [clyde]…
> >
> > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
> <netmod-boun...@ietf.org on behalf of alex.campb...@aviatnet.com>
wrote:
> >
> > I am considering to implement the data model in this draft.
> (dependent on business priorities of course)
> > I have reviewed this draft and found the following issues.
> >
> > * I see pattern-match is specified to use POSIX 1003.2
regular
> expressions. This is presumably for compatibility with existing
> implementations; however it is inconsistent with most of YANG
(which is
> specified to use XPath regular expressions) - unless these are the
same.
> >
> > [clyde] I believe that my answer in the other thread explains
why we
> used Posix 1003.2 – it is commonly used.
> >
> > * pattern-match is inside the facility-filter container;
common
> sense says this is wrong as pattern-match has nothing to do with
> facilities.
> >
> > [clyde] I will move pattern-match up one level in the next
version of
> the draft. Thanks for catching this!
> >
> > * The advanced-compare container groups together two nodes
that
> share a common "when" and "if-feature" statement, but don't seem
to have
> any semantic relation to each other. Are there general guidelines
on
> when to use a container?
> >
> > [clyde] The confusion may come as a result of the when clause
> appearing before the if-feature clause which is set by the IETF
> statement order recommendation.
> >
> > The when construct was suggested by Martin Björklund as a way of
> solving the case that advanced-compare does not apply for the ‘all
’ and
> ‘none’ case.
> >
> > The if-feature applies to the entire container – it is either
> supported or not.
> >
> > * The advanced-compare container has a description starting
with
> "This leaf ..." even though it is not a leaf.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * The examples are missing  nodes.
> >
> > [clyde] This will be fixed in the next draft.
> >
> > * Perhaps there should be more consistent terminology for
> receivers of syslog messages; both "collectors" and "actions" are
used
> in the draft. RFC 5424 uses "collector" for the ultimate recipient
of a
> log message - which might not be applicable, because the sending
system
> has no idea whether the receiving system is a collector or a
relay.
> >
> > [clyde] The definition of “collector” in RFC 5424 is: A
"collector"
> gathers syslog content for further analysis.
> >
> > actions relate to the “further analysis” taken by the
 “collector”.
> >
>   

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[t.petch]

Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.

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

Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[t.petch]

- Original Message -
From: "Juergen Schoenwaelder" 
Sent: Tuesday, June 20, 2017 8:40 PM

> On Tue, Jun 20, 2017 at 02:19:32PM -0400, Joel M. Halpern wrote:
> > I was going to just watch this, but I can't.
> >
> > To call protocol negotiated values "configuration" is to create a
usage
> > which will confuse MANY people.
>
> There are people who have a broad concept of configuration and there
> are people who have a narrow concept of configuration. There is not
> way to resolve this. All we can do is come up with a terminology that
> is consistent and can be used consistently.

Juergen, Robert,

This is what triggered my post (which I have been mulling ever since
ietf-netmod-revised-datastores appeared).

There has been a narrow (IMHO) definition in use for over a decade to
whit

'Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  '

which I have accepted as the basis of this work (having previously used
a much wider definition) .

'Data that determines how a device behaves' seems to me a much wider
definition encompassing much of 'state' as has been defined for the past
decade.

I don't expect to have to read the rest of the I-D (about the kinds of
configuration) to find out that the definition does not mean what it
appears to say; I may have to read on to fully understand it but the
words as written seem to brook no misunderstanding!

Having ' This data is modeled in YANG using "config true" nodes ' sort
of suggests that the original definition holds sway and so contradicts
the previous sentence.  And for this sentence to make sense, a reader
would really have to understand the debates over configuration, state
and how to model them that have been going on for so long which means
that regardless of how true it is, it does not really belong in a
definition.

There is no reference back to the previous definition, as to whether or
not the latest definition is meant to be the same or not.  I find this
confusing.

I think that the previous definition has to appear in this I-D, since it
has influenced so much work, and this I-D then needs to go on to say

'We are revising it ..
or
'We are not revising it ...

I have read the later posts but this one seemed to catch the crux of my
discontent.

Tom Petch

> > Even worse, configuring protocol learned
> > values is liable to break things.  To use one example, many
protocols
> > negotiate timers.  The value that a given systems starts with is the
> > configured value.  The value that it learns from the protocol
exchange is
> > the operational value.  In fact, you better not try to configure
that value
> > or you are liable to break the protocol.
>
> Nobody proposed this, please take a look at the figure in the document
> to understand the information flow and where the distinction is made.
>
> /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] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[t.petch]

--- Original Message -
From: "Phil Shafer" 
To: "Andy Bierman" 
Cc: 
Sent: Tuesday, June 20, 2017 7:05 AM

> Andy Bierman writes:
> >This draft addresses all remaining open issues, include the rewrite
of the
> >opstate section.
>
> >>In YANG, any data that has a "config" statement value of "false"
> >>could be considered operational data.  The relationship between
> >>configuration (i.e., "config" statement has a value of "true") and
> >>operational data can be complex.
>
> The NMDA draft includes the following in its terminology section:
>
>   - configuration: Data that determines how a device behaves.  This
> data is modeled in YANG using "config true" nodes.  Configuration
> can originate from different sources.
>
>   - operational state: The combination of applied configuration and
> system state.
>
> It would be nice to use matching terms, either by importing the
> NMDA terms directly, or by mimicing them in this draft.  If your
> "operational data" means "config false" and NMDA's "operational state"
> means both config true and config false, readers will be confused.

Phil

Well, it would if the definitions in NMDA brought clarity but I think
the opposite.

'Data that determines how a device behaves' seems clear until you read
on and find that this excludes data learnt from the system or data
learnt from routing protocols.

I find the idea that the behaviour of a device is not determined by
routing protocols or a hot-plugged card an odd one.

This definition is rather different to that in NETCONF and seems
unlikely to bring clarity so I think it would be a mistake to
incorporate it in rfc6087bis..

Tom Petch


> Also you say "operational state and other data such as statistics"
> which inconsisent.  Under either set of terms, statistics are
> part of operational state.
>
> >>The original set of datastores defined in NETCONF (i.e., candidate,
> >>unning, and startup) are not sufficient to fully manage a device
> >>ith multiple sources of configuration data.  In additional, a
> >>separate datastore is needed to store operational state and other
> >>data such as statistics.  Refer to
> >>[I-D.ietf-netmod-revised-datastores] for details on this new
"revised
> >>datastore" architecture.  Guidelines for usage of the new datastores
> >>(including the operational datastore) is defined in
> >>[I-D.dsdt-nmda-guidelines].
>
> "not sufficient to fully manage" is too broad a claim.  Can I suggest
> a more positive spin:
>
>   The Network Management Datastore Architecture (NMDA) defines a
>   new set of datastores that improve visibility into the device,
>   both in terms of the "intended" configurations values and the
>   true operationally "in use" values.  Refer to
>   [I-D.ietf-netmod-revised-datastores] for details.  Guidelines for
>   moving existing data modules to the NMDA are defined in
>   [I-D.dsdt-nmda-guidelines].
>
> Thanks,
>  Phil
>
> ___
> 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