Re: [netmod] schema mount and YANG library

[Ladislav Lhotka]

On Mon, 2017-12-18 at 15:30 -0500, Lou Berger wrote:
> lada,
> 
> See below.
> 
> 
> On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> > Hi,
> > 
> > unfortunately, using an action for querying embedded YANG library data
> > (needed for the "inline" case of schema mount) doesn't work either
> > because now under NMDA actions can be used only on instances in the
> >  datastore.
> 
> but the inline/embedded library would (only) be present in the in the
> operational datastore, so what's the issue?

Well, the issue is described in my initial mail of this thread: the current text
requires that every instance of an inline mount point contains the embedded 
YANG library. Tha latter is state data, so the above requirement cannot be 
satisfied if the mount point instance is in a configuration datastore.

> 
> > However, a good alternative seems to be a metadata annotation along the
> > lines of RFC 7952, for example with the alternative B of the newly
> > proposed YANG library schema:
> > 
> >  md:annotation schema-ref {
> >type leafref {
> >  path "/yanglib:yang-library/yanglib:schema/yanglib:name";
> >}
> >  }
> > 
> > In other words, all inline mounted schemas would be included in the
> > top-level YANG library, and mount point instances in all datastores
> > would be annotated with leafref pointing to the actual schema.
> > 
> > Unlike regular state data, it is IMO no problem to permit such
> > annotations in configuration datastores.
> > 
> > Opinions?
> 
> I'm not sure this will work for all architectures of LNEs as well as
> other possible future use cases.  In short, this seems *very* restrictive.

I don't understand, IMO it is not restrictive at all. What kind of restrictions
do you see?

Lada

> 
> Lou
> 
> > 
> > Thanks, Lada
> > 
> > Ladislav Lhotka  writes:
> > 
> > > Hi,
> > > 
> > > the following text in sec. 3.2 of schema-mount-08 is wrong for traditional
> > > datastores, and even more so for NDMA:
> > > 
> > >In case 1 ["inline"], the mounted schema is determined at run time:
> > > every
> > >instance of the mount point that exists in the parent tree MUST
> > >contain a copy of YANG library data [RFC7895] that defines the
> > >mounted schema exactly as for a top-level data model.  A client is
> > >expected to retrieve this data from the instance tree, possibly after
> > >creating the mount point.  Instances of the same mount point MAY use
> > >different mounted schemas.
> > > 
> > > An instance of the mount point in any *configuration* datastores cannot
> > > contain
> > > YANG library (being state data), and so the MUST cannot hold.
> > > 
> > > It is not clear to me how to repair this without considerable
> > > complications
> > > and/or a lot of handwaving. There is actually one good solution but it has
> > > impact on YANG library: the server could provide it in a reply to an
> > > operation,
> > > say "get-yang-library" rather than as state data. Then everything would be
> > > fine
> > > - this operation would turn into an action for the mount point, and it can
> > > be
> > > used equally well for config true and false mount points.
> > > 
> > > So my proposal is to move from YANG library as state data to an operation.
> > > It
> > > could be done along with changing the YANG library structure, so there
> > > will be
> > > little extra impact on implementations. 
> > > 
> > > Lada 
> > > 
> > > -- 
> > > 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] I-D Action: draft-ietf-netmod-rfc6087bis-15.txt

[internet-drafts]

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   : Guidelines for Authors and Reviewers of YANG Data 
Model Documents
Author  : Andy Bierman
Filename: draft-ietf-netmod-rfc6087bis-15.txt
Pages   : 70
Date: 2017-12-18

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-15


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] Joel Jaeggli as a third NETMOD co-chair

[Susan Hares]

Joel:

Thank you for helping out the netmod group!  

Terry

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Benoit Claise
Sent: Friday, December 15, 2017 12:21 PM
To: NETMOD Working Group
Cc: Joel jaeggli
Subject: [netmod] Joel Jaeggli as a third NETMOD co-chair

Dear all,

A lot is happening these days in the world of data modeling-driven management 
at the IETF:
 NMDA architecture, NETCONF, RESTCONF
 NMDA-compliant YANG modules: some RFC bis modules but also new ones
 Guidelines: RFC6087bis and the tree diagram
 The interaction with NETCONF: The schema mount, IETF-YANG-LIBRARY, 
telemetry
 The interaction with routing, where many YANG modules come from.
 etc.
There are a lot of dependencies between all these tasks, which must take place 
in parallel, and, obviously, be completed ASAP.

Kent and Lou have a lot on their shoulders these days.
To help with the situation and proactively progress documents, I'm happy to 
announce that Joel Jaeggli accepted to serve as a third NETMOD co-chair. Thank 
you Joel.

Please welcome Joel.

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] Publication has been requested for draft-ietf-netmod-entity-06

[Lou Berger]

Lou Berger has requested publication of draft-ietf-netmod-entity-06 as Proposed 
Standard on behalf of the NETMOD working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-06.txt

[Lou Berger]

On 12/18/2017 4:11 PM, Andy Bierman wrote:
>
>
> On Mon, Dec 18, 2017 at 1:03 PM, Lou Berger  > wrote:
>
> On 12/18/2017 04:01 PM, Andy Bierman wrote:
> >
> >
> > On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder
> >  
> >  >> wrote:
> >
> >     On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote:
> >     >
> >     > Given the context (YANG module, and this WG), I think it
> should be
> >     > 6087bis (which is the same as 6087 in this respect).
> >
> >     Does RFC 6087 formally update RFC 3688?
> >
> >
> > Not intentionally.
> > The 3688 text  should probably be used instead of 6087bis.
> >
> yikes.  really? so you think rfc6087 and the netmod RFCs were wrong?
>
>
> Not wrong, but the more generic text applies to all WGs,
> not just NETMOD WG.  The YANG module contact info
> has the WG details. Since the NETMOD WG is long-lived,
> it may be better to list NETMOD WG.  It doesn't seem to matter
> since this info is not in the registry anyway.
>

Sigh.  Sounds like a useless line.  I guess the most important thing on
this inconsequential point is that we be consistent.  So, I guess this
means another update to 6087bis, I know you have one in the works in any
case.  How about publishing this change and other's that have been
discussed on the list so that we can all see the current state.  I'll
push submit on entity and we can always update it during IESG processing
if needed...

Thanks,
Lou

...

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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-06.txt

[Andy Bierman]

On Mon, Dec 18, 2017 at 1:03 PM, Lou Berger  wrote:

> On 12/18/2017 04:01 PM, Andy Bierman wrote:
> >
> >
> > On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder
> >  > > wrote:
> >
> > On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote:
> > >
> > > Given the context (YANG module, and this WG), I think it should be
> > > 6087bis (which is the same as 6087 in this respect).
> >
> > Does RFC 6087 formally update RFC 3688?
> >
> >
> > Not intentionally.
> > The 3688 text  should probably be used instead of 6087bis.
> >
> yikes.  really? so you think rfc6087 and the netmod RFCs were wrong?
>
>
Not wrong, but the more generic text applies to all WGs,
not just NETMOD WG.  The YANG module contact info
has the WG details. Since the NETMOD WG is long-lived,
it may be better to list NETMOD WG.  It doesn't seem to matter
since this info is not in the registry anyway.




> Thanks,
> Lou
>


Andy


>
> >
> > Andy
> >
> >
> >
> >Registrant Contact
> >   The individual/organization that is the registration contact
> for
> >   the component being registered.  Ideally, this will be the name
> >   and pertinent physical and network contact information.  In the
> >   case of IETF developed standards, the Registrant will be the
> IESG.
> >
> > /js
> >
> > > I'll put in the publication request as soon as this update is made.
> > >
> > > > Interestingly, it seems the "Registrant Contact" is not stored
> > in the
> > > > IANA maintained registry...
> > > >
> > >
> > > true.
> > >
> > > Thanks,
> > > Lou
> > >
> > > > /martin
> > > >
> > > >
> > > >> Lou
> > > >>
> > > >>
> > > >>> /js
> > > >>>
> > > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
> > >  Martin, Authors,
> > > 
> > >  is there a reason that the draft says:
> > > 
> > >  Registrant Contact: The IESG.
> > > 
> > >  vs the typical:
> > > 
> > > Registrant Contact: The NETMOD WG of the IETF.
> > > 
> > >  Thanks,
> > > 
> > >  Lou
> > > 
> > >  On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> > > > Hi,
> > > >
> > > > This version addresses the WGLC comments received.
> > Specifically, I
> > > > have added ietf-hardware-state, a config false version of
> > > > ietf-hardware for non-NMDA implementations, in an Appendix.
> > Please
> > > > review the new text and the description statement in that
> > module.
> > > >
> > > > I have also added a reference to the tree diagram draft and
> > use the
> > > > latest security guidelines template text.
> > > >
> > > >
> > > > /martin
> > > >
> > > > 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 Hardware
> > Management
> > > >> Authors : Andy Bierman
> > > >>   Martin Bjorklund
> > > >>   Jie Dong
> > > >>   Dan Romascanu
> > > >>Filename: draft-ietf-netmod-entity-06.txt
> > > >>Pages   : 54
> > > >>Date: 2017-12-18
> > > >>
> > > >> Abstract:
> > > >>This document defines a YANG data model for the
> > management of
> > > >>hardware on a single server.
> > > >>
> > > >>
> > > >> The IETF datatracker status page for this draft is:
> > > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> > 
> > > >>
> > > >> There are also htmlized versions available at:
> > > >> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
> > 
> > > >>
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> > 
> > > >>
> > > >> A diff from the previous version is available at:
> > > >>
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-06
> > 
> > > >>
> > > >>
> > > >> Please note that it may take a couple of minutes from the
> > time of submission
> > 

Re: [netmod] I-D Action: draft-ietf-netmod-entity-06.txt

[Lou Berger]

On 12/18/2017 04:01 PM, Andy Bierman wrote:
> 
> 
> On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder
>  > wrote:
> 
> On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote:
> >
> > Given the context (YANG module, and this WG), I think it should be
> > 6087bis (which is the same as 6087 in this respect).
> 
> Does RFC 6087 formally update RFC 3688?
> 
> 
> Not intentionally.
> The 3688 text  should probably be used instead of 6087bis.
> 
yikes.  really? so you think rfc6087 and the netmod RFCs were wrong?

Thanks,
Lou

> 
> Andy
> 
> 
> 
>    Registrant Contact
>       The individual/organization that is the registration contact for
>       the component being registered.  Ideally, this will be the name
>       and pertinent physical and network contact information.  In the
>       case of IETF developed standards, the Registrant will be the IESG.
> 
> /js
> 
> > I'll put in the publication request as soon as this update is made.
> >
> > > Interestingly, it seems the "Registrant Contact" is not stored
> in the
> > > IANA maintained registry...
> > >
> >
> > true.
> >
> > Thanks,
> > Lou
> >
> > > /martin
> > >
> > >
> > >> Lou
> > >>
> > >>
> > >>> /js
> > >>>
> > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
> >  Martin, Authors,
> > 
> >  is there a reason that the draft says:
> > 
> >      Registrant Contact: The IESG.
> > 
> >  vs the typical:
> > 
> >     Registrant Contact: The NETMOD WG of the IETF.
> > 
> >  Thanks,
> > 
> >  Lou
> > 
> >  On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> > > Hi,
> > >
> > > This version addresses the WGLC comments received. 
> Specifically, I
> > > have added ietf-hardware-state, a config false version of
> > > ietf-hardware for non-NMDA implementations, in an Appendix. 
> Please
> > > review the new text and the description statement in that
> module.
> > >
> > > I have also added a reference to the tree diagram draft and
> use the
> > > latest security guidelines template text.
> > >
> > >
> > > /martin
> > >
> > > 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 Hardware
> Management
> > >>         Authors         : Andy Bierman
> > >>                           Martin Bjorklund
> > >>                           Jie Dong
> > >>                           Dan Romascanu
> > >>        Filename        : draft-ietf-netmod-entity-06.txt
> > >>        Pages           : 54
> > >>        Date            : 2017-12-18
> > >>
> > >> Abstract:
> > >>    This document defines a YANG data model for the
> management of
> > >>    hardware on a single server.
> > >>
> > >>
> > >> The IETF datatracker status page for this draft is:
> > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> 
> > >>
> > >> There are also htmlized versions available at:
> > >> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
> 
> > >>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> 
> > >>
> > >> A diff from the previous version is available at:
> > >>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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
> 
> > >>
> > > 

Re: [netmod] I-D Action: draft-ietf-netmod-entity-06.txt

[Andy Bierman]

On Mon, Dec 18, 2017 at 12:56 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote:
> >
> > Given the context (YANG module, and this WG), I think it should be
> > 6087bis (which is the same as 6087 in this respect).
>
> Does RFC 6087 formally update RFC 3688?
>
>
Not intentionally.
The 3688 text  should probably be used instead of 6087bis.


Andy



   Registrant Contact
>   The individual/organization that is the registration contact for
>   the component being registered.  Ideally, this will be the name
>   and pertinent physical and network contact information.  In the
>   case of IETF developed standards, the Registrant will be the IESG.
>
> /js
>
> > I'll put in the publication request as soon as this update is made.
> >
> > > Interestingly, it seems the "Registrant Contact" is not stored in the
> > > IANA maintained registry...
> > >
> >
> > true.
> >
> > Thanks,
> > Lou
> >
> > > /martin
> > >
> > >
> > >> Lou
> > >>
> > >>
> > >>> /js
> > >>>
> > >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
> >  Martin, Authors,
> > 
> >  is there a reason that the draft says:
> > 
> >  Registrant Contact: The IESG.
> > 
> >  vs the typical:
> > 
> > Registrant Contact: The NETMOD WG of the IETF.
> > 
> >  Thanks,
> > 
> >  Lou
> > 
> >  On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> > > Hi,
> > >
> > > This version addresses the WGLC comments received.  Specifically, I
> > > have added ietf-hardware-state, a config false version of
> > > ietf-hardware for non-NMDA implementations, in an Appendix.  Please
> > > review the new text and the description statement in that module.
> > >
> > > I have also added a reference to the tree diagram draft and use the
> > > latest security guidelines template text.
> > >
> > >
> > > /martin
> > >
> > > 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 Hardware
> Management
> > >> Authors : Andy Bierman
> > >>   Martin Bjorklund
> > >>   Jie Dong
> > >>   Dan Romascanu
> > >>Filename: draft-ietf-netmod-entity-06.txt
> > >>Pages   : 54
> > >>Date: 2017-12-18
> > >>
> > >> Abstract:
> > >>This document defines a YANG data model for the management of
> > >>hardware on a single server.
> > >>
> > >>
> > >> The IETF datatracker status page for this draft is:
> > >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> > >>
> > >> There are also htmlized versions available at:
> > >> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
> > >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> > >>
> > >> A diff from the previous version is available at:
> > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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
>
> --
> 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-entity-06.txt

[Juergen Schoenwaelder]

On Mon, Dec 18, 2017 at 03:35:55PM -0500, Lou Berger wrote:
> 
> Given the context (YANG module, and this WG), I think it should be
> 6087bis (which is the same as 6087 in this respect).

Does RFC 6087 formally update RFC 3688?

   Registrant Contact
  The individual/organization that is the registration contact for
  the component being registered.  Ideally, this will be the name
  and pertinent physical and network contact information.  In the
  case of IETF developed standards, the Registrant will be the IESG.

/js
 
> I'll put in the publication request as soon as this update is made.
> 
> > Interestingly, it seems the "Registrant Contact" is not stored in the
> > IANA maintained registry...
> >
> 
> true.
> 
> Thanks,
> Lou
> 
> > /martin
> >
> >
> >> Lou
> >>
> >>
> >>> /js
> >>>
> >>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
>  Martin, Authors,
> 
>  is there a reason that the draft says:
> 
>      Registrant Contact: The IESG.
> 
>  vs the typical:
> 
>     Registrant Contact: The NETMOD WG of the IETF.
> 
>  Thanks,
> 
>  Lou
> 
>  On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > This version addresses the WGLC comments received.  Specifically, I
> > have added ietf-hardware-state, a config false version of
> > ietf-hardware for non-NMDA implementations, in an Appendix.  Please
> > review the new text and the description statement in that module.
> >
> > I have also added a reference to the tree diagram draft and use the
> > latest security guidelines template text.
> >
> >
> > /martin
> >
> > 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 Hardware Management
> >> Authors : Andy Bierman
> >>   Martin Bjorklund
> >>   Jie Dong
> >>   Dan Romascanu
> >>Filename: draft-ietf-netmod-entity-06.txt
> >>Pages   : 54
> >>Date: 2017-12-18
> >>
> >> Abstract:
> >>This document defines a YANG data model for the management of
> >>hardware on a single server.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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

-- 
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-entity-06.txt

[Lou Berger]

On 12/18/2017 3:22 PM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote:
>>> See RFC 3688 section 4.
>> cool, dueling BCPs.
> cool indeed.
>
>> Is there a reason
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5
>> doesn't apply?
> Should we follow 3688 or 6087bis?
Given the context (YANG module, and this WG), I think it should be
6087bis (which is the same as 6087 in this respect).

I'll put in the publication request as soon as this update is made.

> Interestingly, it seems the "Registrant Contact" is not stored in the
> IANA maintained registry...
>

true.

Thanks,
Lou

> /martin
>
>
>> Lou
>>
>>
>>> /js
>>>
>>> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
 Martin, Authors,

 is there a reason that the draft says:

     Registrant Contact: The IESG.

 vs the typical:

    Registrant Contact: The NETMOD WG of the IETF.

 Thanks,

 Lou

 On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> Hi,
>
> This version addresses the WGLC comments received.  Specifically, I
> have added ietf-hardware-state, a config false version of
> ietf-hardware for non-NMDA implementations, in an Appendix.  Please
> review the new text and the description statement in that module.
>
> I have also added a reference to the tree diagram draft and use the
> latest security guidelines template text.
>
>
> /martin
>
> 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 Hardware Management
>> Authors : Andy Bierman
>>   Martin Bjorklund
>>   Jie Dong
>>   Dan Romascanu
>>  Filename: draft-ietf-netmod-entity-06.txt
>>  Pages   : 54
>>  Date: 2017-12-18
>>
>> Abstract:
>>This document defines a YANG data model for the management of
>>hardware on a single server.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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] schema mount and YANG library

[Lou Berger]

lada,

    See below.


On 12/15/2017 8:59 AM, Ladislav Lhotka wrote:
> Hi,
>
> unfortunately, using an action for querying embedded YANG library data
> (needed for the "inline" case of schema mount) doesn't work either
> because now under NMDA actions can be used only on instances in the
>  datastore.

but the inline/embedded library would (only) be present in the in the
operational datastore, so what's the issue?

> However, a good alternative seems to be a metadata annotation along the
> lines of RFC 7952, for example with the alternative B of the newly
> proposed YANG library schema:
>
>  md:annotation schema-ref {
>type leafref {
>  path "/yanglib:yang-library/yanglib:schema/yanglib:name";
>}
>  }
>
> In other words, all inline mounted schemas would be included in the
> top-level YANG library, and mount point instances in all datastores
> would be annotated with leafref pointing to the actual schema.
>
> Unlike regular state data, it is IMO no problem to permit such
> annotations in configuration datastores.
>
> Opinions?
I'm not sure this will work for all architectures of LNEs as well as
other possible future use cases.  In short, this seems *very* restrictive.

Lou

>
> Thanks, Lada
>
> Ladislav Lhotka  writes:
>
>> Hi,
>>
>> the following text in sec. 3.2 of schema-mount-08 is wrong for traditional
>> datastores, and even more so for NDMA:
>>
>>In case 1 ["inline"], the mounted schema is determined at run time: every
>>instance of the mount point that exists in the parent tree MUST
>>contain a copy of YANG library data [RFC7895] that defines the
>>mounted schema exactly as for a top-level data model.  A client is
>>expected to retrieve this data from the instance tree, possibly after
>>creating the mount point.  Instances of the same mount point MAY use
>>different mounted schemas.
>>
>> An instance of the mount point in any *configuration* datastores cannot 
>> contain
>> YANG library (being state data), and so the MUST cannot hold.
>>
>> It is not clear to me how to repair this without considerable complications
>> and/or a lot of handwaving. There is actually one good solution but it has
>> impact on YANG library: the server could provide it in a reply to an 
>> operation,
>> say "get-yang-library" rather than as state data. Then everything would be 
>> fine
>> - this operation would turn into an action for the mount point, and it can be
>> used equally well for config true and false mount points.
>>
>> So my proposal is to move from YANG library as state data to an operation. It
>> could be done along with changing the YANG library structure, so there will 
>> be
>> little extra impact on implementations. 
>>
>> Lada 
>>
>> -- 
>> 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] I-D Action: draft-ietf-netmod-entity-06.txt

[Juergen Schoenwaelder]

On Mon, Dec 18, 2017 at 03:15:46PM -0500, Lou Berger wrote:
> 
> 
> On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote:
> > See RFC 3688 section 4.
> cool, dueling BCPs.
> 
> Is there a reason
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5
> doesn't apply?
>

Searching through a number of RFCs containing YANG modules, I must say
that we are consistently inconsistent. I would give RFC 3688 section 4
authority here since RFC 3688 defined the registry.  (Note also that
WGs come and go, the IESG may have a longer lifetime.  That said, I
assume that the responsibility for the registration falls into the
hands of the IESG anyway when a WG ceases to exist.)

/js

PS: The IANA registry seems to maintain a pointer to the RFC, there is
not really a registrant column. ;-)

-- 
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-entity-06.txt

[Martin Bjorklund]

Lou Berger  wrote:
> 
> 
> On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote:
> > See RFC 3688 section 4.
> cool, dueling BCPs.

cool indeed.

> Is there a reason
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5
> doesn't apply?

Should we follow 3688 or 6087bis?

Interestingly, it seems the "Registrant Contact" is not stored in the
IANA maintained registry...


/martin


> 
> Lou
> 
> 
> > /js
> >
> > On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
> >> Martin, Authors,
> >>
> >> is there a reason that the draft says:
> >>
> >>     Registrant Contact: The IESG.
> >>
> >> vs the typical:
> >>
> >>    Registrant Contact: The NETMOD WG of the IETF.
> >>
> >> Thanks,
> >>
> >> Lou
> >>
> >> On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> >>> Hi,
> >>>
> >>> This version addresses the WGLC comments received.  Specifically, I
> >>> have added ietf-hardware-state, a config false version of
> >>> ietf-hardware for non-NMDA implementations, in an Appendix.  Please
> >>> review the new text and the description statement in that module.
> >>>
> >>> I have also added a reference to the tree diagram draft and use the
> >>> latest security guidelines template text.
> >>>
> >>>
> >>> /martin
> >>>
> >>> 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 Hardware Management
>  Authors : Andy Bierman
>    Martin Bjorklund
>    Jie Dong
>    Dan Romascanu
>   Filename: draft-ietf-netmod-entity-06.txt
>   Pages   : 54
>   Date: 2017-12-18
> 
>  Abstract:
> This document defines a YANG data model for the management of
> hardware on a single server.
> 
> 
>  The IETF datatracker status page for this draft is:
>  https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> 
>  There are also htmlized versions available at:
>  https://tools.ietf.org/html/draft-ietf-netmod-entity-06
>  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> 
>  A diff from the previous version is available at:
>  https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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] I-D Action: draft-ietf-netmod-entity-06.txt

[Lou Berger]

On 12/18/2017 3:06 PM, Juergen Schoenwaelder wrote:
> See RFC 3688 section 4.
cool, dueling BCPs.

Is there a reason
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14#section-5
doesn't apply?

Lou


> /js
>
> On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
>> Martin, Authors,
>>
>> is there a reason that the draft says:
>>
>>     Registrant Contact: The IESG.
>>
>> vs the typical:
>>
>>    Registrant Contact: The NETMOD WG of the IETF.
>>
>> Thanks,
>>
>> Lou
>>
>> On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> This version addresses the WGLC comments received.  Specifically, I
>>> have added ietf-hardware-state, a config false version of
>>> ietf-hardware for non-NMDA implementations, in an Appendix.  Please
>>> review the new text and the description statement in that module.
>>>
>>> I have also added a reference to the tree diagram draft and use the
>>> latest security guidelines template text.
>>>
>>>
>>> /martin
>>>
>>> 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 Hardware Management
 Authors : Andy Bierman
   Martin Bjorklund
   Jie Dong
   Dan Romascanu
Filename: draft-ietf-netmod-entity-06.txt
Pages   : 54
Date: 2017-12-18

 Abstract:
This document defines a YANG data model for the management of
hardware on a single server.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

 There are also htmlized versions available at:
 https://tools.ietf.org/html/draft-ietf-netmod-entity-06
 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06

 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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] WG Last Call: draft-ietf-netmod-acl-model-14

[Eliot Lear]

Presuming this issue is behind us, are all WGLC comments addressed?  Can
we expect to see a new draft soon?

Eliot


On 18.12.17 13:31, Eliot Lear wrote:
>
> So long as nobody expects an interface construct in a MUD file, I'm happy.
>
>
> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
>> Eliot,
>>
>> Nothing can force an implementation to have to implement either
>> the ietf-interfaces model or the augmentation in the
>> ietf-access-control-list model. I appreciate your desire for
>> modularity and cohesiveness, but I would resist #1, because I feel
>> that the majority of users will be targeting interface-based
>> attachment over time. I’ve adde back in use of the
>> “interface-attachment” feature (which I took out as part of
>> refactoring interface attachment). Part of:
>>
>> https://github.com/netmod-wg/acl-model/pull/21
>>
>>
>> The augments part of the tree now looks like:
>>
>>   augment /if:interfaces/if:interface:
>>     +--rw acls *{interface-attachment}*?
>>        +--rw ingress
>>        |  +--rw acl-sets
>>        |     +--rw acl-set* [name]
>>        |        +--rw name              -> /access-lists/acl/name
>>        |        +--rw type?             -> /access-lists/acl/type
>>        |        +--ro ace-statistics* [name] {interface-stats}?
>>        |           +--ro name               ->
>> /access-lists/acl/aces/ace/name
>>        |           +--ro matched-packets?   yang:counter64
>>        |           +--ro matched-octets?    yang:counter64
>>        +--rw egress
>>           +--rw acl-sets
>>              +--rw acl-set* [name]
>>                 +--rw name              -> /access-lists/acl/name
>>                 +--rw type?             -> /access-lists/acl/type
>>                 +--ro ace-statistics* [name] {interface-stats}?
>>                    +--ro name               ->
>> /access-lists/acl/aces/ace/name
>>                    +--ro matched-packets?   yang:counter64
>>                    +--ro matched-octets?    yang:counter64
>>
>> Cheers,
>>
>> Einar
>>
>>
>>> On 17 Dec 2017, at 11:29, Eliot Lear >> > wrote:
>>>
>>> Einar,
>>>
>>> I think this change is fine, with one exception.  I would rather the
>>> augment to the interface not be required for implementations that
>>> don't actually have interfaces.  I understand that there may be two
>>> ways to go about this:
>>>
>>>  1. Separate out the augment into a separate module (same doc is
>>> fine); or
>>>  2. Somehow "feature-ize" the augment.
>>>
>>> I don't know how to do (2) but if you do, that's okay by me.
>>>
>>> Eliot
>>>
>>>
>>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
 All,

 After a series of discussions on- and off-list, I have a candidate
 PR that includes the changes in the PR Mahesh sent out plus some
 more edits. Please see consolidated PR here:

 https://github.com/netmod-wg/acl-model/pull/21


 Main changes in addition to Mahesh’s PR are:

   * Moved interface attachment to be via an interface augmentation.
   * Restructured port matches slightly under both IPv4 and IPv6
 containers.
   * Removed unnecessary identity 'interface-acl-aggregate’.
   * Removed action ‘icmp-off’, can be augmented later.


 For reference, here is the current YANG tree plus “--ietf” logs:

 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
 ietf-access-control-list.yang:51: error: bad value "-MM-DD"
 (should be date)
 module: ietf-access-control-list
     +--rw access-lists
        +--rw acl* [name]
           +--rw name    string
           +--rw type?   acl-type
           +--rw aces
              +--rw ace* [name]
                 +--rw name          string
                 +--rw matches
                 |  +--rw (l2)?
                 |  |  +--:(eth)
                 |  |     +--rw eth {match-on-eth}?
                 |  |        +--rw destination-mac-address?      
  yang:mac-address
                 |  |        +--rw destination-mac-address-mask?  
 yang:mac-address
                 |  |        +--rw source-mac-address?            
 yang:mac-address
                 |  |        +--rw source-mac-address-mask?      
  yang:mac-address
                 |  |        +--rw ethertype?                    
  eth:ethertype
                 |  +--rw (l3)?
                 |  |  +--:(ipv4)
                 |  |  |  +--rw ipv4 {match-on-ipv4}?
                 |  |  |     +--rw dscp?                       inet:dscp
                 |  |  |     +--rw ecn?                        uint8
                 |  |  |     +--rw length?                     uint16
                 |  |  |     +--rw ttl?                        uint8
                 |  |  |     +--rw protocol?                   uint8
                 |  |  |     +--rw 

Re: [netmod] I-D Action: draft-ietf-netmod-entity-06.txt

[Juergen Schoenwaelder]

See RFC 3688 section 4.

/js

On Mon, Dec 18, 2017 at 03:00:26PM -0500, Lou Berger wrote:
> Martin, Authors,
> 
> is there a reason that the draft says:
> 
>     Registrant Contact: The IESG.
> 
> vs the typical:
> 
>    Registrant Contact: The NETMOD WG of the IETF.
> 
> Thanks,
> 
> Lou
> 
> On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > This version addresses the WGLC comments received.  Specifically, I
> > have added ietf-hardware-state, a config false version of
> > ietf-hardware for non-NMDA implementations, in an Appendix.  Please
> > review the new text and the description statement in that module.
> >
> > I have also added a reference to the tree diagram draft and use the
> > latest security guidelines template text.
> >
> >
> > /martin
> >
> > 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 Hardware Management
> >> Authors : Andy Bierman
> >>   Martin Bjorklund
> >>   Jie Dong
> >>   Dan Romascanu
> >>Filename: draft-ietf-netmod-entity-06.txt
> >>Pages   : 54
> >>Date: 2017-12-18
> >>
> >> Abstract:
> >>This document defines a YANG data model for the management of
> >>hardware on a single server.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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

-- 
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-entity-06.txt

[Lou Berger]

Martin, Authors,

is there a reason that the draft says:

    Registrant Contact: The IESG.

vs the typical:

   Registrant Contact: The NETMOD WG of the IETF.

Thanks,

Lou

On 12/18/2017 4:39 AM, Martin Bjorklund wrote:
> Hi,
>
> This version addresses the WGLC comments received.  Specifically, I
> have added ietf-hardware-state, a config false version of
> ietf-hardware for non-NMDA implementations, in an Appendix.  Please
> review the new text and the description statement in that module.
>
> I have also added a reference to the tree diagram draft and use the
> latest security guidelines template text.
>
>
> /martin
>
> 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 Hardware Management
>> Authors : Andy Bierman
>>   Martin Bjorklund
>>   Jie Dong
>>   Dan Romascanu
>>  Filename: draft-ietf-netmod-entity-06.txt
>>  Pages   : 54
>>  Date: 2017-12-18
>>
>> Abstract:
>>This document defines a YANG data model for the management of
>>hardware on a single server.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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

Re: [netmod] AD review of draft-ietf-netmod-rfc7223bis-01

[Benoit Claise]

Perfect.
Thank you.

Regards, B.

Benoit Claise  wrote:

Dear all,

In order not to be the bottleneck in the process, here is my AD review
of draft-ietf-netmod-rfc7223bis-01


Editorial:

-
An interface is identified by its name, which is unique within the
server.  This property is captured in the "interface-ref"_and_
typedef, which other YANG modules SHOULD use when they need to
reference an interface.

NEW:
An interface is identified by its name, which is unique within the
server.  This property is captured in the "interface-ref"
typedef, which other YANG modules SHOULD use when they need to
reference an interface.

Ok, now fixed.



-
Note that NETCONF and SNMP may
differ in the time granularity in which they provide access to the
counters.

I guess we want to remove the reference to NETCONF?
Proposal:
Note the server that implements the YANG module and the SNMP Agent may
differ in the time granularity in which they provide access to the
counters.

Ok, fixed.


  -
We want to mention that "or:" comes from "ietf-ori...@2017-08-17.yang"
in draft-ietf-netmod-revised-datastores

I added:

   This example uses the "origin" annotation, which is defined in the
   module "ietf-origin" [I-D.ietf-netmod-revised-datastores].


(I added this text to rfc7277bis as well).



/martin




  
http://example.com/vlan;
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

  
eth0
ianaift:ethernetCsmacd
false
down
down
2
00:01:02:03:04:05

  
2013-04-01T03:00:00+00:00
  
  

  

Regards, Benoit (as OPS AD)


.



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

Re: [netmod] AD review of draft-ietf-netmod-rfc7223bis-01

[Martin Bjorklund]

Benoit Claise  wrote:
> Dear all,
> 
> In order not to be the bottleneck in the process, here is my AD review
> of draft-ietf-netmod-rfc7223bis-01
> 
> 
> Editorial:
> 
> -
>An interface is identified by its name, which is unique within the
>server.  This property is captured in the "interface-ref"_and_
>typedef, which other YANG modules SHOULD use when they need to
>reference an interface.
> 
> NEW:
>An interface is identified by its name, which is unique within the
>server.  This property is captured in the "interface-ref"
>typedef, which other YANG modules SHOULD use when they need to
>reference an interface.

Ok, now fixed.


> 
> -
>Note that NETCONF and SNMP may
>differ in the time granularity in which they provide access to the
>counters.
> 
> I guess we want to remove the reference to NETCONF?
> Proposal:
>Note the server that implements the YANG module and the SNMP Agent may
>differ in the time granularity in which they provide access to the
>counters.

Ok, fixed.

>  -
> We want to mention that "or:" comes from "ietf-ori...@2017-08-17.yang"
> in draft-ietf-netmod-revised-datastores

I added:

  This example uses the "origin" annotation, which is defined in the
  module "ietf-origin" [I-D.ietf-netmod-revised-datastores].


(I added this text to rfc7277bis as well).



/martin


> 
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
>message-id="101">
>  
>xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
>xmlns:vlan="http://example.com/vlan;
>xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
> 
>  
>eth0
>ianaift:ethernetCsmacd
>false
>down
>down
>2
>00:01:02:03:04:05
>
>  
>2013-04-01T03:00:00+00:00
>  
>  
>
>  
> 
> Regards, Benoit (as OPS AD)
> 

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

[netmod] AD review of draft-ietf-netmod-rfc7277bis-01

[Benoit Claise]

Dear all,

In order not to be the bottleneck in the process, here is my AD review 
of draft-ietf-netmod-rfc7277bis-01 


All looks good. Thank you.

Martin already noticed the Security Considerations template

Regards, Benoit (as OPS AD)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] AD review of draft-ietf-netmod-rfc7223bis-01

[Benoit Claise]

Dear all,

In order not to be the bottleneck in the process, here is my AD review 
of draft-ietf-netmod-rfc7223bis-01 



Editorial:

-
   An interface is identified by its name, which is unique within the
   server.  This property is captured in the "interface-ref"_and_
   typedef, which other YANG modules SHOULD use when they need to
   reference an interface.

NEW:
   An interface is identified by its name, which is unique within the
   server.  This property is captured in the "interface-ref"
   typedef, which other YANG modules SHOULD use when they need to
   reference an interface.

-
   Note that NETCONF and SNMP may
   differ in the time granularity in which they provide access to the
   counters.

I guess we want to remove the reference to NETCONF?
Proposal:
   Note the server that implements the YANG module and the SNMP Agent may
   differ in the time granularity in which they provide access to the
   counters.
 
-

We want to mention that "or:" comes from "ietf-ori...@2017-08-17.yang" in 
draft-ietf-netmod-revised-datastores


 
   http://example.com/vlan;
   xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

 
   eth0
   ianaift:ethernetCsmacd
   false
   down
   down
   2
   00:01:02:03:04:05
   
 
   2013-04-01T03:00:00+00:00
 
 
   
 

Regards, Benoit (as OPS AD)

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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01

[Acee Lindem (acee)]

Hi Lada, 

On 12/18/17, 7:19 AM, "Ladislav Lhotka"  wrote:

>Hi Acee,
>
>"Acee Lindem (acee)"  writes:
>
>> Hi Lou, et al, 
>>
>> The only issue we are struggling with is whether we need to specify the
>> version in the ietf-interfaces import. We have noted that
>> draft-ietf-netmod-rfc7277bis-01.txt does not import by revision.
>
>I would suggest to import *without* revision but add a description
>indicating that the NMDA-compatible revisions are needed.
>
>Importing by revision is clearly suboptimal. Hopefully a new mechanism
>such as semantic versioning will be introduced soon to alleviate this
>issue.

I agree and will update the description.
>
>>
>> We also have so nits:
>>
>>1. Add an informative reference for
>> [I-D.ietf-netmod-yang-tree-diagrams].
>>2. Based on a comment from Vladimir, we added the prefix for
>> ietf-routing.yang, “rt:”, to several references within
>>ietf-routing.yang.
>> Was this necessary? Of course, the model compiles with or without the
>> prefix.
>
>RFC6087bis has some rules in sec. 4.2, and these should be followed.

Will review these. 
>
>Also, the security considerations should IMO be changed, see my recent
>message:
>
>https://www.ietf.org/mail-archive/web/netmod/current/msg19610.html
>
>Of course, the NEW formulation needn't be exactly as I suggested, but
>the text "The YANG module [...] is designed to be accessed ..." is
>apparently wrong and shouldn't be used any more.

Ok - I will also review the “Security Considerations” template.

Thanks,
Acee 

>
>Thanks, Lada
>
>>
>> Thanks,
>> Acee
>>
>> On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger"
>>  wrote:
>>
>>>All,
>>> This last call is closed.
>>>
>>>We note that there was an update during the LC and that no comments were
>>>received during the LC period.  As this is simply a mechanical update
>>>that has been discussed in the WG we plan to proceed with the
>>>publication process.
>>>
>>>Authors,
>>> Please let/us the WG know when you have published a version ready for
>>>publication.  Also please let the WG know what has changed in the
>>>document since the start of LC (rev -01)
>>>
>>>Thank you,
>>>NetMod Chairs
>>>
>>>
>>>
>>>On 11/29/2017 12:26 PM, Lou Berger wrote:
 All,
 
 This starts a two-week working group last call on
 draft-ietf-netmod-rfc8022bis-01.
 
 Please recall that this update's intention is to
 modify the YANG module to be in line with the NMDA
 guidelines [1].  Reviewing the diff between the two
 drafts [2] should reveal just this.
 
 The working group last call ends on December 13.
 Please send your comments to the netmod mailing list.
 
 Positive comments, e.g., "I've reviewed this document
 and believe it is ready for publication", are welcome!
 This is useful and important, even from authors.
 
 [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
 [2] 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=rfc8022.txt=
dr
aft-ietf-netmod-rfc8022bis-01.txt
 
 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
>
>-- 
>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] WG Last Call: draft-ietf-netmod-rfc8022bis-01

[Ladislav Lhotka]

Hi Acee,

"Acee Lindem (acee)"  writes:

> Hi Lou, et al, 
>
> The only issue we are struggling with is whether we need to specify the
> version in the ietf-interfaces import. We have noted that
> draft-ietf-netmod-rfc7277bis-01.txt does not import by revision.

I would suggest to import *without* revision but add a description
indicating that the NMDA-compatible revisions are needed.

Importing by revision is clearly suboptimal. Hopefully a new mechanism
such as semantic versioning will be introduced soon to alleviate this
issue.

>
> We also have so nits:
>
>1. Add an informative reference for
> [I-D.ietf-netmod-yang-tree-diagrams].
>2. Based on a comment from Vladimir, we added the prefix for
> ietf-routing.yang, “rt:”, to several references within ietf-routing.yang.
> Was this necessary? Of course, the model compiles with or without the
> prefix.

RFC6087bis has some rules in sec. 4.2, and these should be followed.

Also, the security considerations should IMO be changed, see my recent
message:

https://www.ietf.org/mail-archive/web/netmod/current/msg19610.html

Of course, the NEW formulation needn't be exactly as I suggested, but
the text "The YANG module [...] is designed to be accessed ..." is
apparently wrong and shouldn't be used any more.

Thanks, Lada

>
> Thanks,
> Acee
>
> On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger"
>  wrote:
>
>>All,
>>  This last call is closed.
>>
>>We note that there was an update during the LC and that no comments were
>>received during the LC period.  As this is simply a mechanical update
>>that has been discussed in the WG we plan to proceed with the
>>publication process.
>>
>>Authors,
>>  Please let/us the WG know when you have published a version ready for
>>publication.  Also please let the WG know what has changed in the
>>document since the start of LC (rev -01)
>>
>>Thank you,
>>NetMod Chairs
>>
>>
>>
>>On 11/29/2017 12:26 PM, Lou Berger wrote:
>>> All,
>>> 
>>> This starts a two-week working group last call on
>>> draft-ietf-netmod-rfc8022bis-01.
>>> 
>>> Please recall that this update's intention is to
>>> modify the YANG module to be in line with the NMDA
>>> guidelines [1].  Reviewing the diff between the two
>>> drafts [2] should reveal just this.
>>> 
>>> The working group last call ends on December 13.
>>> Please send your comments to the netmod mailing list.
>>> 
>>> Positive comments, e.g., "I've reviewed this document
>>> and believe it is ready for publication", are welcome!
>>> This is useful and important, even from authors.
>>> 
>>> [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
>>> [2] 
>>>https://tools.ietf.org/rfcdiff?difftype=--hwdiff=rfc8022.txt=dr
>>>aft-ietf-netmod-rfc8022bis-01.txt
>>> 
>>> 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

-- 
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] WG Last Call: draft-ietf-netmod-rfc8022bis-01

[Acee Lindem (acee)]

Hi Vladimir, 

On 12/18/17, 6:24 AM, "Vladimir Vassilev"  wrote:

>
>
>On 12/17/2017 05:57 PM, Acee Lindem (acee) wrote:
>> Hi Lou, et al,
>>
>> The only issue we are struggling with is whether we need to specify the
>> version in the ietf-interfaces import. We have noted that
>> draft-ietf-netmod-rfc7277bis-01.txt does not import by revision.
>>
>> We also have so nits:
>>
>> 1. Add an informative reference for
>> [I-D.ietf-netmod-yang-tree-diagrams].
>> 2. Based on a comment from Vladimir, we added the prefix for
>> ietf-routing.yang, “rt:”, to several references within
>>ietf-routing.yang.
>> Was this necessary? Of course, the model compiles with or without the
>> prefix.
>I reverted this in a follow-up comment on the same thread. I believe the
>local prefixes are redundant.

I’d already updated the git repository and neglected to revert it. I will
revert after reviewing RFC6087BIS rules.

Thanks,
Acee

>
>Vladimir
>>
>> Thanks,
>> Acee
>>
>> On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger"
>>  wrote:
>>
>>> All,
>>> This last call is closed.
>>>
>>> We note that there was an update during the LC and that no comments
>>>were
>>> received during the LC period.  As this is simply a mechanical update
>>> that has been discussed in the WG we plan to proceed with the
>>> publication process.
>>>
>>> Authors,
>>> Please let/us the WG know when you have published a version ready for
>>> publication.  Also please let the WG know what has changed in the
>>> document since the start of LC (rev -01)
>>>
>>> Thank you,
>>> NetMod Chairs
>>>
>>>
>>>
>>> On 11/29/2017 12:26 PM, Lou Berger wrote:
 All,

 This starts a two-week working group last call on
 draft-ietf-netmod-rfc8022bis-01.

 Please recall that this update's intention is to
 modify the YANG module to be in line with the NMDA
 guidelines [1].  Reviewing the diff between the two
 drafts [2] should reveal just this.

 The working group last call ends on December 13.
 Please send your comments to the netmod mailing list.

 Positive comments, e.g., "I've reviewed this document
 and believe it is ready for publication", are welcome!
 This is useful and important, even from authors.

 [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
 [2]
 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=rfc8022.txt=
dr
 aft-ietf-netmod-rfc8022bis-01.txt

 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
>

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

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

[Eliot Lear]

So long as nobody expects an interface construct in a MUD file, I'm happy.


On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
> Eliot,
>
> Nothing can force an implementation to have to implement either
> the ietf-interfaces model or the augmentation in the
> ietf-access-control-list model. I appreciate your desire for
> modularity and cohesiveness, but I would resist #1, because I feel
> that the majority of users will be targeting interface-based
> attachment over time. I’ve adde back in use of the
> “interface-attachment” feature (which I took out as part of
> refactoring interface attachment). Part of:
>
> https://github.com/netmod-wg/acl-model/pull/21
>
>
> The augments part of the tree now looks like:
>
>   augment /if:interfaces/if:interface:
>     +--rw acls *{interface-attachment}*?
>        +--rw ingress
>        |  +--rw acl-sets
>        |     +--rw acl-set* [name]
>        |        +--rw name              -> /access-lists/acl/name
>        |        +--rw type?             -> /access-lists/acl/type
>        |        +--ro ace-statistics* [name] {interface-stats}?
>        |           +--ro name               ->
> /access-lists/acl/aces/ace/name
>        |           +--ro matched-packets?   yang:counter64
>        |           +--ro matched-octets?    yang:counter64
>        +--rw egress
>           +--rw acl-sets
>              +--rw acl-set* [name]
>                 +--rw name              -> /access-lists/acl/name
>                 +--rw type?             -> /access-lists/acl/type
>                 +--ro ace-statistics* [name] {interface-stats}?
>                    +--ro name               ->
> /access-lists/acl/aces/ace/name
>                    +--ro matched-packets?   yang:counter64
>                    +--ro matched-octets?    yang:counter64
>
> Cheers,
>
> Einar
>
>
>> On 17 Dec 2017, at 11:29, Eliot Lear > > wrote:
>>
>> Einar,
>>
>> I think this change is fine, with one exception.  I would rather the
>> augment to the interface not be required for implementations that
>> don't actually have interfaces.  I understand that there may be two
>> ways to go about this:
>>
>>  1. Separate out the augment into a separate module (same doc is
>> fine); or
>>  2. Somehow "feature-ize" the augment.
>>
>> I don't know how to do (2) but if you do, that's okay by me.
>>
>> Eliot
>>
>>
>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
>>> All,
>>>
>>> After a series of discussions on- and off-list, I have a candidate
>>> PR that includes the changes in the PR Mahesh sent out plus some
>>> more edits. Please see consolidated PR here:
>>>
>>> https://github.com/netmod-wg/acl-model/pull/21
>>>
>>>
>>> Main changes in addition to Mahesh’s PR are:
>>>
>>>   * Moved interface attachment to be via an interface augmentation.
>>>   * Restructured port matches slightly under both IPv4 and IPv6
>>> containers.
>>>   * Removed unnecessary identity 'interface-acl-aggregate’.
>>>   * Removed action ‘icmp-off’, can be augmented later.
>>>
>>>
>>> For reference, here is the current YANG tree plus “--ietf” logs:
>>>
>>> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
>>> ietf-access-control-list.yang:51: error: bad value "-MM-DD"
>>> (should be date)
>>> module: ietf-access-control-list
>>>     +--rw access-lists
>>>        +--rw acl* [name]
>>>           +--rw name    string
>>>           +--rw type?   acl-type
>>>           +--rw aces
>>>              +--rw ace* [name]
>>>                 +--rw name          string
>>>                 +--rw matches
>>>                 |  +--rw (l2)?
>>>                 |  |  +--:(eth)
>>>                 |  |     +--rw eth {match-on-eth}?
>>>                 |  |        +--rw destination-mac-address?      
>>>  yang:mac-address
>>>                 |  |        +--rw destination-mac-address-mask?  
>>> yang:mac-address
>>>                 |  |        +--rw source-mac-address?            
>>> yang:mac-address
>>>                 |  |        +--rw source-mac-address-mask?      
>>>  yang:mac-address
>>>                 |  |        +--rw ethertype?                    
>>>  eth:ethertype
>>>                 |  +--rw (l3)?
>>>                 |  |  +--:(ipv4)
>>>                 |  |  |  +--rw ipv4 {match-on-ipv4}?
>>>                 |  |  |     +--rw dscp?                       inet:dscp
>>>                 |  |  |     +--rw ecn?                        uint8
>>>                 |  |  |     +--rw length?                     uint16
>>>                 |  |  |     +--rw ttl?                        uint8
>>>                 |  |  |     +--rw protocol?                   uint8
>>>                 |  |  |     +--rw (source-port-range-or-operator)?
>>>                 |  |  |     |  +--:(range)
>>>                 |  |  |     |  |  +--rw source-port-lower          
>>> inet:port-number
>>>                 |  |  |     |  |  +--rw source-port-upper          
>>> inet:port-number
>>>                 |  

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Martin Bjorklund]

Hi,

Vladimir Vassilev  wrote:
> On 12/16/2017 10:46 AM, Martin Bjorklund wrote:
> 
> > Hi,
> >
> > Vladimir Vassilev  wrote:
> >> On 12/13/2017 04:26 PM, Vladimir Vassilev wrote:
> >>> Hi,
> >>>
> >>> On 12/13/2017 03:47 PM, Martin Bjorklund wrote:
> >>>
>  Hi,
> 
>  Thanks for reporting this.  I'll add the missing origin.  But why did
>  you think forwarding and mtu should be removed?
> >>> 1. IMO since  is not present in the  container in the
> >>> Appendix A () example and does not have default value in
> >>> the model I still think it should be removed.
> >> Alternatively the ipv4/mtu node can be a good example of a
> >> origin="or:system" configuration.
> > Yes.
> >
>      In fact, I think I
>  missed ,
> >>> 2. IMO both fixes adding  or removing  should be
> >>> OK depending on the RFC6243 defined with-defaults capability
> >>> 'basic-mode' parameter advertised by the server. I was running the
> >>> example with basic-mode=explicit
> > Right.  I now have this:
> >
> >
> >
> >
> >  true
> >  false
> >  1500
> >  
> >192.0.2.1
> >24
> >static
> >  
> >  
> >192.0.2.2
> >00:01:02:03:04:05
> >  
> >
> >
> >  true
> >  false
> >  1280
> >  ...
> >
> > Do you think this is ok?
> Yes. The or:default data makes the example even better.
> 
> 1. However there is one more default value missing
> (/interfaces/interface[name='eth0']/enabled) for the example to be
> consistent

Note that the example has:

   

This covers the 'enabled' leaf (and more).  The idea is to let this
document focus on the ip parameters.

> 2. ... and in the last diff I unintentionally omitted the get-data
> output node  required namespace addition (this is also
> applicable to draft-ietf-netmod-7223bis-01):

Good catch!  I have applied this in both documents.

I also realized that the drafts don't use text from the latest
Security Considerations template; I have fixed that as well.


/martin




> 
> diff -u before2.xml after2.xml
> --- before2.xml    2017-12-18 11:41:54.029279321 +0100
> +++ after2.xml    2017-12-18 11:36:25.973850340 +0100
> @@ -1,4 +1,4 @@
> - 
> +  xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-datastores">
>          xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>     xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
> @@ -7,6 +7,7 @@
>   
>     eth0
>     ianaift:ethernetCsmacd
> +   true
>     
>     
>   true
> 
> 
> Vladimir
> >
> >
> > /martin
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01

[Vladimir Vassilev]

On 12/17/2017 05:57 PM, Acee Lindem (acee) wrote:

Hi Lou, et al,

The only issue we are struggling with is whether we need to specify the
version in the ietf-interfaces import. We have noted that
draft-ietf-netmod-rfc7277bis-01.txt does not import by revision.

We also have so nits:

1. Add an informative reference for
[I-D.ietf-netmod-yang-tree-diagrams].
2. Based on a comment from Vladimir, we added the prefix for
ietf-routing.yang, “rt:”, to several references within ietf-routing.yang.
Was this necessary? Of course, the model compiles with or without the
prefix.
I reverted this in a follow-up comment on the same thread. I believe the 
local prefixes are redundant.


Vladimir


Thanks,
Acee

On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger"
 wrote:


All,
This last call is closed.

We note that there was an update during the LC and that no comments were
received during the LC period.  As this is simply a mechanical update
that has been discussed in the WG we plan to proceed with the
publication process.

Authors,
Please let/us the WG know when you have published a version ready for
publication.  Also please let the WG know what has changed in the
document since the start of LC (rev -01)

Thank you,
NetMod Chairs



On 11/29/2017 12:26 PM, Lou Berger wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc8022bis-01.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

The working group last call ends on December 13.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=rfc8022.txt=dr
aft-ietf-netmod-rfc8022bis-01.txt

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


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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Vladimir Vassilev]

On 12/16/2017 10:46 AM, Martin Bjorklund wrote:


Hi,

Vladimir Vassilev  wrote:

On 12/13/2017 04:26 PM, Vladimir Vassilev wrote:

Hi,

On 12/13/2017 03:47 PM, Martin Bjorklund wrote:


Hi,

Thanks for reporting this.  I'll add the missing origin.  But why did
you think forwarding and mtu should be removed?

1. IMO since  is not present in the  container in the
Appendix A () example and does not have default value in
the model I still think it should be removed.

Alternatively the ipv4/mtu node can be a good example of a
origin="or:system" configuration.

Yes.


    In fact, I think I
missed ,

2. IMO both fixes adding  or removing  should be
OK depending on the RFC6243 defined with-defaults capability
'basic-mode' parameter advertised by the server. I was running the
example with basic-mode=explicit

Right.  I now have this:

   

   
 true
 false
 1500
 
   192.0.2.1
   24
   static
 
 
   192.0.2.2
   00:01:02:03:04:05
 
   
   
 true
 false
 1280
 ...

Do you think this is ok?

Yes. The or:default data makes the example even better.

1. However there is one more default value missing 
(/interfaces/interface[name='eth0']/enabled) for the example to be 
consistent
2. ... and in the last diff I unintentionally omitted the get-data 
output node  required namespace addition (this is also applicable 
to draft-ietf-netmod-7223bis-01):


diff -u before2.xml after2.xml
--- before2.xml    2017-12-18 11:41:54.029279321 +0100
+++ after2.xml    2017-12-18 11:36:25.973850340 +0100
@@ -1,4 +1,4 @@
- 
+ 
    
    eth0
    ianaift:ethernetCsmacd
+   true
    
    
  true


Vladimir



/martin


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

Re: [netmod] I-D Action: draft-ietf-netmod-entity-06.txt

[Martin Bjorklund]

Hi,

This version addresses the WGLC comments received.  Specifically, I
have added ietf-hardware-state, a config false version of
ietf-hardware for non-NMDA implementations, in an Appendix.  Please
review the new text and the description statement in that module.

I have also added a reference to the tree diagram draft and use the
latest security guidelines template text.


/martin

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 Hardware Management
> Authors : Andy Bierman
>   Martin Bjorklund
>   Jie Dong
>   Dan Romascanu
>   Filename: draft-ietf-netmod-entity-06.txt
>   Pages   : 54
>   Date: 2017-12-18
> 
> Abstract:
>This document defines a YANG data model for the management of
>hardware on a single server.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-06
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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] I-D Action: draft-ietf-netmod-entity-06.txt

[internet-drafts]

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 Hardware Management
Authors : Andy Bierman
  Martin Bjorklund
  Jie Dong
  Dan Romascanu
Filename: draft-ietf-netmod-entity-06.txt
Pages   : 54
Date: 2017-12-18

Abstract:
   This document defines a YANG data model for the management of
   hardware on a single server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-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