[netmod] I-D Action: draft-ietf-netmod-syslog-model-20.txt
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 Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename: draft-ietf-netmod-syslog-model-20.txt Pages : 34 Date: 2018-02-09 Abstract: This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft- ietf-netconf-keystore o "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value for draft-ietf-netconf-tls-client-server o "" --> the assigned RFC value for this draft The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-20 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-20 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
Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02
On Fri, Feb 9, 2018 at 7:19 AM, t.petch wrote:
> Oppose adoption
>
> As others have said, there is a lack of a problem to solve.
>
>
Actually, I see eventual value in the tags themselves if:
- each tag is defined with a YANG identity
- there is standard filtering based on derived-from-or-self
- the standard tags are maintained in an IANA module (iana-yang-tags)
- there is a standard YANG extension yt:module-tag that can be used to
assign
tags to an entire module
- there is a standard YANG extension yt:data-tag that can be used to
assign
tags to a YANG data subtree
- standard YANG modules include appropriate tagging
IMO it is similar to iana-if-types, which is much better than each vendor or
each operator assigning all the code-points.
It would be a lot of work to come up with a good set of standard tags
but it seems there are people willing to work on that.
Andy
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/list
Re: [netmod] draft-ietf-netmod-rfc6087bis-16
Hi Tom,
I know where you're going with this, and I agree, but as we're past AD-review,
maybe this is a good candidate for guidelines-next?
https://github.com/netmod-wg/guidelines-next/issues
Kent // shepherd
- Original Message -
From: "Andy Bierman"
Sent: Wednesday, February 07, 2018 5:48 PM
> On Wed, Feb 7, 2018 at 4:58 AM, t.petch 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=CT9Hf4F4H2prnOg0sLp9WvPE51q0zSwxAufnFGEFI38&s=rKLyZFgHK884Wvw2Xj2gu2_xu6PRJDZekh3FgzhTzI0&e=
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [OPSAWG] Minor change in ietf-access-control-l...@2018-02-02.yang
Yes, it may be a bug in ODL, but I also think that there is something wrong to use such a long relative path. In that case, the relative path is actually longer than the absolute path! That said, there is no guidance in rfc6087bis currently, so we may need to let it go this time. K. // shepherd = original message = This may be. bug in OpenDaylight that is being tickled. Ranga is chasing it a bit. On 09.02.18 10:20, Jan Lindblad wrote: > Eliot, > >> In order to compile the published YANG model with OpenDaylight Yangtools I >> had to make the following change ( diff published file vs. changed file is >> below ): >> >> 583c583 >> < path "../../../../../../acl/name"; >> --- >>> path "/access-lists/acl/name"; >> 597c597 >> < path "../../../../../../../acl/aces/ace/name"; >> --- >>> path "/access-lists/acl/aces/ace/name"; >> >> I am not sure (don't have enough YANG experience) to know if the error is >> with Yangtools or with the published YANG model but I thought I'd send this >> information to the list just in case. >> >> Thank you for your attention. > Both the old and the new path look valid to me. Even if you can always > replace a relative path with an absolute from a YANG validity perspective, > changing from relative to absolute paths often *changes the semantics*, so > that is not generally safe. In this case, however, they do amount to the same > thing (since they both end up going all the way up to the top level > container). > > /jan > > ___ 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
Thank you, Tom. That's an interesting bit of history there. Of course, you would know, as I see you listed in the Acknowledgments section in RFC 6587. David Harrington's points are very compelling. The chairs want to get this draft to Benoit before he steps down. But looking at the draft right now, I can see that it is a very easy fix to remove the TCP transport layer support entirely, not much more than just moving the reference to Informative. So, yes, let's bin it. FWIW, I asked before if it were important to anyone, giving them a chance to speak up first. But now, given how easy I see the fix is, that we should remove it without waiting for an answer. If it is important to someone, let them speak up now. Clyde, please let this be the update you plan to post today. Thanks, Kent // all hats = original message = Kent The TCP syslog started out as Standards Track, after the syslog WG had concluded, but David Harrington objected, as the extract below shows, that it would never pass the IESG; and so it became Informational. Further, the author, in 2013, described it as "there is also historic RFC6587 on industry standard plain tcp, but this is just for interoperating with legacy systems, not for new implementation. It is strongly discouraged to use that in new systems. " Bin it IMHO. Tom Petch == Many of the changes were made at my request. I believe the document as written would not have made it through IESG approval. 1) the IETF has defined a standard syslog; how to make your legacy proprietary version work is not an IETF problem. 2) the syslog WG was created to develop a secure syslog solution with secure transport and signing capability. How to make your legacy proprietary version work over non-secure transport is not an IETF problem. 3) Publishing this as a proposed standard seems to violate BCP 61. syslog/tls already provides "strong security" over tcp, so syslog/tcp is not needed to meet IETF goals. Under what circumstances is it **desirable** to use this specification (with no strong security available) in the Internet? Why not use the syslog/TLS specification, with the security features administratively turned off within secure environments? You cannot justify implementing this by saying things like "syslog/TLS is required and this is optional", and not explain WHY this additional non-bcp61-compliant specification is needed. 4) The aim of this IETF specification should be to document "how TCP MAY be used as a transport for standardized syslog", when the standard secure transport may not apply. (But I expect serious pushback from the IESG on this; see #3) Because this might have to work with legacy deployments, we also include as an appendix "how to correlate the legacy and standard usages." 5) RFC3164 is just a survey, not a specification. 6) RFC2119 language needed to be cleaned up. David Harrington Director, IETF Transport Area ietf...@comcast.net (preferred for ietf) dbharring...@huaweisymantec.com +1 603 828 1401 (cell) > -Original Message- > From: syslog-boun...@ietf.org > [mailto:syslog-boun...@ietf.org] On Behalf Of t.petch > Sent: Tuesday, November 02, 2010 1:02 AM > > Chris > > I had not noticed before but this seems to have changed > direction during the > summer; Informational not Standards Track, and stressing > byte-counting more, > byte-stuffing less. > > I do find it less clear. I think that the Introduction needs > more work in the > light of the changes to the rest of the document. I read > "This specification includes descriptions of both >format options in an attempt to ensure that standardized syslog >transport receivers can receive and properly interpret > messages sent >from legacy syslog senders." > got to the end of the document and thought 'oh no it does > not!' and then > realised that this is now an Appendix whereas before it was > in the main body. > Of course, if you never knew it was in the body, you might > not be as confused as > I. > > But really, the emphasis on standardised and legacy syslog > seems misplaced. The > carriage over TCP is the same whether the carried is > SYSLOG-3164 or SYSLOG-MSG > so the distinction seems spurious. And SYSLOG-3164 does not > appear in any RFC > or I-D I can find. > > Rather, you have two forms of adaptation to carry a message, > and what that > message is is mostly academic. > > Separately, I think that more is needed on Security. It is > easier to sabotage > TCP than it is UDP; spurious FIN, RST etc. > > And I think more is needed on closing the session. The > transport receiver > detects a format error (well, the transport sender is not > going to) sends FIN, > gets FIN-ACK and the transport sender carries merrily > on. I think that > there should be a recommendation that the transport sender > closes the connection > and reopens it if it wants to. > > Tom Petch > - Original Message - > From: "Chris Lonvick" > > Sen
Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
How do I know which datastore the data belongs to? Would it not make sense to carry that information inline? If we do not carry this information inline, how is that information supposed to be provided if for example this format is used to validate examples included in documentation? /js On Fri, Feb 09, 2018 at 04:07:11PM +0100, Balazs Lengyel wrote: > Hello Jurgen, > > I will gladly add NMDA to the draft. However could you please be more > specific. Which part of NMDA are you missing? > Is it the example of yanglib that you would like updated? > > As the instance-data can be used to document and/or load both config=true > and false data it is IMHO relevant to the candidate/running/operational > datastores. However whether it should be used to just document data or also > to load data, and how exactly such a load should be implemented is out of > scope. And yes using one SW kit config=false data can be loaded from file > too. > > regards Balazs > > > On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote: > > [Removing NETCONF since the I-D says -netmod-.] > > > > I flipped through the I-D yesterday and I think a common format for > > instance data trees should be NMDA aware these days. > > > > /js > > > > On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote: > > > Hello, > > > > > > With Benoit I prepared a draft about how to document and use YANG > > > defined > > > instance data. It could be useful for documenting server > > > capabilities or > > > preloading data defined in implementation time and probably for other > > > purposes as well. > > > > > > regards Balazs > > > > > > Forwarded Message > > > > > > Subject: New Version Notification for > > > draft-lengyel-netmod-yang-instance-data-00.txt > > >Date: Wed, 7 Feb 2018 09:28:50 -0800 > > >From: [1]internet-dra...@ietf.org > > > To: Benoit Claise [2], Balazs Lengyel > > > [3] > > > > > > A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt > > > has been successfully submitted by Balazs Lengyel and posted to the > > > IETF repository. > > > > > > Name: draft-lengyel-netmod-yang-instance-data > > > Revision: 00 > > > Title: YANG Instance Data Files and their use for Documenting > > > Server Capabilities > > > Document date: 2018-02-06 > > > Group: Individual Submission > > > Pages: 10 > > > URL: > > > [4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt > > > Status: > > > [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ > > > Htmlized: > > > [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 > > > Htmlized: > > > [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 > > > > > > > > > Abstract: > > > This document specifies a standard file format for YANG instance > > > data, that is data that could be stored in a datastore and whose > > > syntax and semantics is defined by YANG models. Instance data files > > > can be used to provide information that is defined in design time. > > > There is a need to document Server capabilities (which are often > > > specified in design time), which should be done using instance data > > > files. > > > > > > > > > > > > > > > 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. > > > > > > The IETF Secretariat > > > > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > Mobile: +36-70-330-7909 email: > > > [8]balazs.leng...@ericsson.com > > > > > > References > > > > > > Visible links > > > 1. mailto:internet-dra...@ietf.org > > > 2. mailto:bcla...@cisco.com > > > 3. mailto:balazs.leng...@ericsson.com > > > 4. > > > https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt > > > 5. > > > https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ > > > 6. > > > https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 > > > 7. > > > https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 > > > 8. mailto:balazs.leng...@ericsson.com > > > ___ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwael
Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02
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
- Original Message -
From: "Andy Bierman"
Sent: Wednesday, February 07, 2018 5:48 PM
> On Wed, Feb 7, 2018 at 4:58 AM, t.petch 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] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
Hello Jurgen, I will gladly add NMDA to the draft. However could you please be more specific. Which part of NMDA are you missing? Is it the example of yanglib that you would like updated? As the instance-data can be used to document and/or load both config=true and false data it is IMHO relevant to the candidate/running/operational datastores. However whether it should be used to just document data or also to load data, and how exactly such a load should be implemented is out of scope. And yes using one SW kit config=false data can be loaded from file too. regards Balazs On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote: [Removing NETCONF since the I-D says -netmod-.] I flipped through the I-D yesterday and I think a common format for instance data trees should be NMDA aware these days. /js On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote: Hello, With Benoit I prepared a draft about how to document and use YANG defined instance data. It could be useful for documenting server capabilities or preloading data defined in implementation time and probably for other purposes as well. regards Balazs Forwarded Message Subject: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt Date: Wed, 7 Feb 2018 09:28:50 -0800 From: [1]internet-dra...@ietf.org To: Benoit Claise [2], Balazs Lengyel [3] A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt has been successfully submitted by Balazs Lengyel and posted to the IETF repository. Name: draft-lengyel-netmod-yang-instance-data Revision: 00 Title: YANG Instance Data Files and their use for Documenting Server Capabilities Document date: 2018-02-06 Group: Individual Submission Pages: 10 URL: [4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt Status: [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ Htmlized: [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 Htmlized: [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 Abstract: This document specifies a standard file format for YANG instance data, that is data that could be stored in a datastore and whose syntax and semantics is defined by YANG models. Instance data files can be used to provide information that is defined in design time. There is a need to document Server capabilities (which are often specified in design time), which should be done using instance data files. 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. The IETF Secretariat -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: [8]balazs.leng...@ericsson.com References Visible links 1. mailto:internet-dra...@ietf.org 2. mailto:bcla...@cisco.com 3. mailto:balazs.leng...@ericsson.com 4. https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt 5. https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ 6. https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 7. https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 8. mailto:balazs.leng...@ericsson.com ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] LL review of draft-ietf-netconf-rfc7895bis-04
Hi, here is my review of the rfc7895bis document: *** General comments - This revision is a significant improvement necessary for supporting NMDA. However, it is also flexible enough in that it allows for implementing the NMDA rules in an effective way but doesn't preclude the use of other datastores and datastore architectures. - Another benefit is that the new YANG library schema can be easily integrated with schema mount information. *** Specific comments Sec. 1 - backward compatibility Given that the old YANG library schema is carried over as a deprecated subtree, how can a server implementor actually cater for backward compatibility of e.g. RESTCONF clients supporting only RFC 8040? Could the same YANG modules that comprise NMDA datastore schemas be advertized also via the old YANG library? Or is it necessary to also have pre-NMDA versions of all modules? Some more explanation might be useful here. Sec. 1 - YANG library stability The text basically says that the YANG library information can change at any time. This has been recently discussed but I haven't seen any conclusion yet. I understand it is difficult to enumerate all the situations when this information can change, but it should also be emphasized that YL info is not just another subtree of state data and that it should not change haphazardly. It is like with database schemas, REST APIs and the like. Of course, these can change as well, but everybody has to understand that doing so means transition problems, broken clients etc. For this reason, it might be useful to set YL and schema mount data aside and call them metadata or schema information - even if we continue modelling them with YANG. Sec. 3 - semantic versioning Some placeholders for future inclusion of semantic versions in YANG library information might be useful. To this end, I would suggest to introduce a new choice node and make "revision" (or, even better, "revision-date") its only case. This way, other versioning schemes such as semver could be easily added via augmentation. Sec. 4 - checksum I think it would be very useful (even if not immediately) to standardize the procedure for computing the checksum. What I envision are systems that construct and process YANG schemas (such as the YANG Catalog). They could benefit from having a universal hash string as a characteristic of any particular schema. Just consider how useful the universal hashes are e.g. in git. Nits - sec 1. paragraph 2: s/informaton/information/ Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Missing references
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" To: "t.petch" ; "Henrik Levkowetz" ; "NETMOD Working Group" 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
Re: [netmod] [OPSAWG] Minor change in ietf-access-control-l...@2018-02-02.yang
This may be. bug in OpenDaylight that is being tickled. Ranga is chasing it a bit. On 09.02.18 10:20, Jan Lindblad wrote: > Eliot, > >> In order to compile the published YANG model with OpenDaylight Yangtools I >> had to make the following change ( diff published file vs. changed file is >> below ): >> >> 583c583 >> < path "../../../../../../acl/name"; >> --- >>> path "/access-lists/acl/name"; >> 597c597 >> < path "../../../../../../../acl/aces/ace/name"; >> --- >>> path "/access-lists/acl/aces/ace/name"; >> >> I am not sure (don't have enough YANG experience) to know if the error is >> with Yangtools or with the published YANG model but I thought I'd send this >> information to the list just in case. >> >> Thank you for your attention. > Both the old and the new path look valid to me. Even if you can always > replace a relative path with an absolute from a YANG validity perspective, > changing from relative to absolute paths often *changes the semantics*, so > that is not generally safe. In this case, however, they do amount to the same > thing (since they both end up going all the way up to the top level > container). > > /jan > > signature.asc Description: OpenPGP digital signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [OPSAWG] Minor change in ietf-access-control-l...@2018-02-02.yang
Eliot, > In order to compile the published YANG model with OpenDaylight Yangtools I > had to make the following change ( diff published file vs. changed file is > below ): > > 583c583 > < path "../../../../../../acl/name"; > --- > > path "/access-lists/acl/name"; > 597c597 > < path "../../../../../../../acl/aces/ace/name"; > --- > > path "/access-lists/acl/aces/ace/name"; > > > I am not sure (don't have enough YANG experience) to know if the error is > with Yangtools or with the published YANG model but I thought I'd send this > information to the list just in case. > > Thank you for your attention. Both the old and the new path look valid to me. Even if you can always replace a relative path with an absolute from a YANG validity perspective, changing from relative to absolute paths often *changes the semantics*, so that is not generally safe. In this case, however, they do amount to the same thing (since they both end up going all the way up to the top level container). /jan ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
