[netmod] I-D Action: draft-ietf-netmod-revised-datastores-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : Network Management Datastore Architecture
Authors : Martin Bjorklund
  Juergen Schoenwaelder
  Phil Shafer
  Kent Watsen
  Rob Wilton
Filename: draft-ietf-netmod-revised-datastores-01.txt
Pages   : 44
Date: 2017-03-13

Abstract:
   Datastores are a fundamental concept binding the data models written
   in the YANG data modeling language to network management protocols
   such as NETCONF and RESTCONF.  This document defines an architectural
   framework for datastores based on the experience gained with the
   initial simpler model, addressing requirements that were not well
   supported in the initial model.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01

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


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] security considerations boilerplate updates to cover RESTCONF

[Juergen Schoenwaelder]

Hi,

this came up during IESG processing of a YANG module - is there a new
security guideline boilerplate text covering RESTCONF? This was
briefly discussed on the yang-doctors but somehow the discussion
stopped because RESTCONF was not published yet at that time. I think
this affects draft-ietf-netmod-rfc6087bis-12.txt.

draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
online documents - why do we need several points? I think some are
also not working. Ideally, there should be a single stable URL.

/js

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

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

Re: [netmod] stable reference for tree diagram notation

[Lou Berger]

Andy,


On 3/13/2017 3:07 PM, Andy Bierman wrote:
>
>
> On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger  > wrote:
>
> FYI - just slapped together and published:
>
> https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00
> 
>
> Lou
>
> (as contributor)
>
> PS I'm happy with the definition being in 6780bis or in a
> standalone doc
> (as above), but really think we as a WG need to decide ASAP so as
> not to
> hold up 6780bis any further...
>
>
>
>
> standalone doc is fine.
>
> does this mean the contents of the tree diagram and the syntax for the
> tree diagram are subject to WG consensus?
>

As contained in RFCs - I would think so. 

As available from tools -- This is for the tools author IMO.

Lou

>
> Andy
>  
>
> On 3/13/2017 2:20 PM, Robert Wilton wrote:
> > Hi Andy,
> >
> > Would it make sense to update 6087bis section 4.4 to reference
> this new
> > pyang option for generated tree diagrams?
> >
> > Thanks,
> > Rob
> >
> >
> > On 11/03/2017 21:49, Martin Bjorklund wrote:
> >> "Acee Lindem (acee)" mailto:a...@cisco.com>>
> wrote:
> >>> Hi Juergen,
> >>>
> >>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
> >>> mailto:netmod-boun...@ietf.org> on
> behalf of
> >>> j.schoenwael...@jacobs-university.de
> > wrote:
> >>>
>  On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:
> > This way, reader can focus more quickly on the diffs, but
> also this
> > likely mimics what happened in reality (start with `pyang -f
> tree`
> > and then manually edit from there).  What do you think?
> >
>  Manually edited tree diagrams? I hope not.
> >>> I frequently have to manually edit the pyang-generated trees
> to get them
> >>> to fit in the xml2rfc output. Is there a work around for this
> that I don¹t
> >>> know about?
> >> In the latest pyang, I have added --tree-line-length.  Use:
> >>
> >>pyang -f -tree --tree-line-length 69 ...
> >>
> >> to fit RFCs.
> >>
> >>
> >> /martin
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/netmod
> 
> >> .
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> >
>
>

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

[netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : Sub-interface VLAN YANG Data Models
Authors : Robert Wilton
  David Ball
  Tapraj Singh
  Selvakumar Sivaraj
Filename: draft-ietf-netmod-sub-intf-vlan-model-01.txt
Pages   : 27
Date: 2017-03-13

Abstract:
   This document defines YANG modules to add support for classifying
   traffic received on interfaces as Ethernet/VLAN framed packets to
   sub-interfaces based on the fields available in the Ethernet/VLAN
   frame headers.  These modules allow configuration of Layer 3 and
   Layer 2 sub-interfaces (e.g. attachment circuits) that can
   interoperate with IETF based forwarding protocols; such as IP and
   L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN.  The
   sub-interfaces also interoperate with VLAN tagged traffic orginating
   from an IEEE 802.1Q compliant bridge.  Primarily the classification
   is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
   also has support for matching on some other layer 2 frame header
   fields and is designed to be extensible to match on other arbitrary
   header fields.

   The model differs from an IEEE 802.1Q bridge model in that the
   configuration is interface/sub-interface based as opposed to being
   based on membership of an 802.1Q VLAN bridge.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-01


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-syslog-model-13.txt

[Clyde Wildes (cwildes)]

Hi,

In this revision of the draft published today:

1. Update Kiran’s contact info.
2. Incorporate Andy’s feedback from 2/21/17: minor changes.
3. Incorporate Kent’s feedback from 2/22/17: minor changes; change from two 
models to one model.
4. Incorporate Alex’s feedback from 2/23/17: prefixing max-delay, 
number-resends, resend-delay, and resend-count with“sig-“. 
5. Incorporate Tom Petch’s feedback from 3/1/17: the explanation of the YANG 
tree diagram is not that in RFC6087bis; confusion on the variation in the 
references to RFC in the modules.
6. Incorporate Dale’s feedback from 3/6/17: suggestion regarding pseudocode.

Thanks,

Clyde

On 3/13/17, 11:49 AM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-13.txt
Pages   : 27
Date: 2017-03-13

Abstract:
   This document describes a data model for the configuration of syslog.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-13

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


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

Re: [netmod] stable reference for tree diagram notation

[Robert Wilton]

On 13/03/2017 19:07, Andy Bierman wrote:



On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger > wrote:


FYI - just slapped together and published:

https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00


Lou

(as contributor)

PS I'm happy with the definition being in 6780bis or in a
standalone doc
(as above), but really think we as a WG need to decide ASAP so as
not to
hold up 6780bis any further...




standalone doc is fine.

does this mean the contents of the tree diagram and the syntax for the
tree diagram are subject to WG consensus?
That would seem to make sense, given that they are used in all drafts 
describing YANG models.


Rob





Andy

On 3/13/2017 2:20 PM, Robert Wilton wrote:
> Hi Andy,
>
> Would it make sense to update 6087bis section 4.4 to reference
this new
> pyang option for generated tree diagrams?
>
> Thanks,
> Rob
>
>
> On 11/03/2017 21:49, Martin Bjorklund wrote:
>> "Acee Lindem (acee)" mailto:a...@cisco.com>>
wrote:
>>> Hi Juergen,
>>>
>>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
>>> mailto:netmod-boun...@ietf.org> on
behalf of
>>> j.schoenwael...@jacobs-university.de
> wrote:
>>>
 On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:
> This way, reader can focus more quickly on the diffs, but
also this
> likely mimics what happened in reality (start with `pyang -f
tree`
> and then manually edit from there). What do you think?
>
 Manually edited tree diagrams? I hope not.
>>> I frequently have to manually edit the pyang-generated trees
to get them
>>> to fit in the xml2rfc output. Is there a work around for this
that I don¹t
>>> know about?
>> In the latest pyang, I have added --tree-line-length.  Use:
>>
>>pyang -f -tree --tree-line-length 69 ...
>>
>> to fit RFCs.
>>
>>
>> /martin
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod

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

>




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

Re: [netmod] stable reference for tree diagram notation

[Andy Bierman]

On Mon, Mar 13, 2017 at 11:26 AM, Lou Berger  wrote:

> FYI - just slapped together and published:
>
> https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00
>
> Lou
>
> (as contributor)
>
> PS I'm happy with the definition being in 6780bis or in a standalone doc
> (as above), but really think we as a WG need to decide ASAP so as not to
> hold up 6780bis any further...
>
>
>

standalone doc is fine.

does this mean the contents of the tree diagram and the syntax for the
tree diagram are subject to WG consensus?


Andy


> On 3/13/2017 2:20 PM, Robert Wilton wrote:
> > Hi Andy,
> >
> > Would it make sense to update 6087bis section 4.4 to reference this new
> > pyang option for generated tree diagrams?
> >
> > Thanks,
> > Rob
> >
> >
> > On 11/03/2017 21:49, Martin Bjorklund wrote:
> >> "Acee Lindem (acee)"  wrote:
> >>> Hi Juergen,
> >>>
> >>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
> >>>  >>> j.schoenwael...@jacobs-university.de> wrote:
> >>>
>  On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:
> > This way, reader can focus more quickly on the diffs, but also this
> > likely mimics what happened in reality (start with `pyang -f tree`
> > and then manually edit from there).  What do you think?
> >
>  Manually edited tree diagrams? I hope not.
> >>> I frequently have to manually edit the pyang-generated trees to get
> them
> >>> to fit in the xml2rfc output. Is there a work around for this that I
> don¹t
> >>> know about?
> >> In the latest pyang, I have added --tree-line-length.  Use:
> >>
> >>pyang -f -tree --tree-line-length 69 ...
> >>
> >> to fit RFCs.
> >>
> >>
> >> /martin
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >> .
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] stable reference for tree diagram notation

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> It looks like it needs a further tweak to also wrap augments.  I just
> tried (with the latest master off github) and hasn't wrapped the
> augment line.

Ok.  In general, it will not be possible to cover all cases.  An
example would be if you have a deeply nested module and some long leaf
names in the end.  In such cases it might be better to split the
diagram into many smaller diagrams, using --tree-path and maybe
--tree-depth.

But this particular case should be possible to handle.  I'll have a
look.  Meanwhile you'll have to tweak this manually.


/martin


> 
> E.g.
> 
> module: ietf-if-l3-vlan
>   augment
>   /if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type:
> +--:(vlan)
>+--rw vlan
>   +--rw tag* [index]
>  +--rw indexuint8
>  +--rw dot1q-tag
> +--rw tag-typedot1q-tag-type
> +--rw vlan-id ieee:vlanid
> 
> Thanks,
> Rob
> 
> 
> On 11/03/2017 21:49, Martin Bjorklund wrote:
> > "Acee Lindem (acee)"  wrote:
> >> Hi Juergen,
> >>
> >> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
> >>  >> j.schoenwael...@jacobs-university.de> wrote:
> >>
> >>> On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:
>  This way, reader can focus more quickly on the diffs, but also this
>  likely mimics what happened in reality (start with `pyang -f tree`
>  and then manually edit from there).  What do you think?
> 
> >>> Manually edited tree diagrams? I hope not.
> >> I frequently have to manually edit the pyang-generated trees to get
> >> them
> >> to fit in the xml2rfc output. Is there a work around for this that I
> >> don¹t
> >> know about?
> > In the latest pyang, I have added --tree-line-length.  Use:
> >
> >pyang -f -tree --tree-line-length 69 ...
> >
> > to fit RFCs.
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-13.txt
Pages   : 27
Date: 2017-03-13

Abstract:
   This document describes a data model for the configuration of syslog.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-13

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


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] stable reference for tree diagram notation

[Lou Berger]

FYI - just slapped together and published:

https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00

Lou

(as contributor)

PS I'm happy with the definition being in 6780bis or in a standalone doc
(as above), but really think we as a WG need to decide ASAP so as not to
hold up 6780bis any further...


On 3/13/2017 2:20 PM, Robert Wilton wrote:
> Hi Andy,
>
> Would it make sense to update 6087bis section 4.4 to reference this new 
> pyang option for generated tree diagrams?
>
> Thanks,
> Rob
>
>
> On 11/03/2017 21:49, Martin Bjorklund wrote:
>> "Acee Lindem (acee)"  wrote:
>>> Hi Juergen,
>>>
>>> On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
>>> >> j.schoenwael...@jacobs-university.de> wrote:
>>>
 On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:
> This way, reader can focus more quickly on the diffs, but also this
> likely mimics what happened in reality (start with `pyang -f tree`
> and then manually edit from there).  What do you think?
>
 Manually edited tree diagrams? I hope not.
>>> I frequently have to manually edit the pyang-generated trees to get them
>>> to fit in the xml2rfc output. Is there a work around for this that I don¹t
>>> know about?
>> In the latest pyang, I have added --tree-line-length.  Use:
>>
>>pyang -f -tree --tree-line-length 69 ...
>>
>> to fit RFCs.
>>
>>
>> /martin
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

Re: [netmod] stable reference for tree diagram notation

[Robert Wilton]

Hi Martin,

It looks like it needs a further tweak to also wrap augments.  I just 
tried (with the latest master off github) and hasn't wrapped the augment 
line.


E.g.

module: ietf-if-l3-vlan
  augment 
/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type:

+--:(vlan)
   +--rw vlan
  +--rw tag* [index]
 +--rw indexuint8
 +--rw dot1q-tag
+--rw tag-typedot1q-tag-type
+--rw vlan-id ieee:vlanid

Thanks,
Rob


On 11/03/2017 21:49, Martin Bjorklund wrote:

"Acee Lindem (acee)"  wrote:

Hi Juergen,

On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:


On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:

This way, reader can focus more quickly on the diffs, but also this
likely mimics what happened in reality (start with `pyang -f tree`
and then manually edit from there).  What do you think?


Manually edited tree diagrams? I hope not.

I frequently have to manually edit the pyang-generated trees to get them
to fit in the xml2rfc output. Is there a work around for this that I don¹t
know about?

In the latest pyang, I have added --tree-line-length.  Use:

   pyang -f -tree --tree-line-length 69 ...

to fit RFCs.


/martin

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



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

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

[Clyde Wildes (cwildes)]

Dale,

Thanks for the simplification. I have incorporated this in the next 
draft-ietf-netmod-syslog-model revision.

Regards,

Clyde


On 3/6/17, 12:53 PM, "Dale R. Worley"  wrote:

(We seem to be well beyond the original LC date, but this is only an
editorial comment...)

The algorithm in section 3 isn't clear to me (possibly because I'm not
very familiar with syslog in practice):

   Selector processing (input is syslog message):

   1. Loop through facility-list
  a. Facility match processing - continue to the next entry in
 the list if no match
  b. Severity compare processing - continue to the next list
 entry if no match
  c. Match - proceed with the action and exit further processing
   2. Process pattern match if specified and if a match proceed with
  the action

If I understand correctly, a message is processed if it matches any one
element of facility-list OR the regexp.  In that case, I think you could
it clearer by writing the pseudocode in a style that is more functional
than imperative:

   A syslog message is processed if
   there is an element of facility-list (F, S) where
   the message facility matches F (if it is present)
   and the message severity matches S (if it is present)
   or the message text matches the pattern (if it is present)

Dale


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

Re: [netmod] stable reference for tree diagram notation

[Robert Wilton]

Hi Andy,

Would it make sense to update 6087bis section 4.4 to reference this new 
pyang option for generated tree diagrams?


Thanks,
Rob


On 11/03/2017 21:49, Martin Bjorklund wrote:

"Acee Lindem (acee)"  wrote:

Hi Juergen,

On 3/8/17, 2:34 PM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:


On Wed, Mar 08, 2017 at 06:56:20PM +, Kent Watsen wrote:

This way, reader can focus more quickly on the diffs, but also this
likely mimics what happened in reality (start with `pyang -f tree`
and then manually edit from there).  What do you think?


Manually edited tree diagrams? I hope not.

I frequently have to manually edit the pyang-generated trees to get them
to fit in the xml2rfc output. Is there a work around for this that I don¹t
know about?

In the latest pyang, I have added --tree-line-length.  Use:

   pyang -f -tree --tree-line-length 69 ...

to fit RFCs.


/martin

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



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

Re: [netmod] draft-ietf-netmod-syslog-model-12

[Clyde Wildes (cwildes)]

Tom,

The next revision of the draft-ietf-netmod-syslog-model includes a change to 
the Yang tree diagram explanation to include the text from RFC6087bis.

RFC5426 is referenced in the model where "Transmission of Syslog Messages over 
UDP” occurs:

  case udp {
 container udp {
   description
 "This container describes the UDP transport
  options.";
   reference
 "RFC 5426: Transmission of Syslog Messages over UDP";

This is a correct reference.
  
Thanks,

Clyde

On 3/1/17, 4:20 AM, "netmod on behalf of t.petch"  wrote:

The explanation of the YANG tree diagram is not that in RFC6087; I think
that it should be (or else explain why not)

I am confused by the variation in the references to RFC in the modules.

I see
RFC 5424
[RFC5426]
RFC5424

I think the first correct

Tom Petch

- Original Message -
From: "Alexander Clemm" 
To: "Kent Watsen" ;

Cc: 
Sent: Friday, February 24, 2017 12:25 AM
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

___
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-yang-model-classification-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : YANG Module Classification
Authors : Dean Bogdanovic
  Benoit Claise
  Carl Moberg
Filename: draft-ietf-netmod-yang-model-classification-05.txt
Pages   : 11
Date: 2017-03-13

Abstract:
   The YANG data modeling language is currently being considered for a
   wide variety of applications throughout the networking industry at
   large.  Many standards-defining organizations (SDOs), open source
   software projects, vendors and users are using YANG to develop and
   publish YANG modules for a wide variety of applications.  At the same
   time, there is currently no well-known terminology to categorize
   various types of YANG modules.

   A consistent terminology would help with the categorization of YANG
   modules, assist in the analysis of the YANG data modeling efforts in
   the IETF and other organizations, and bring clarity to the YANG-
   related discussions between the different groups.

   This document describes a set of concepts and associated terms to
   support consistent classification of YANG modules.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-05


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] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

Adrian,

I just want to clarify one issue on BSS. Order management is part of the BSS 
and when external customer is ordering a new service, it talks to the order 
management system (either through a sales person or directly via self ordering 
application). The BSS then sends request to the provisioning system to create 
the service, essentially the service orchestrator. So I would argue that BSS is 
exposed to the external consumers of the service, but those systems are 
developed by internal teams.

I will update the draft according to some of your comments, but will leave this 
for the moment in the draft and we can have a discussion on this at the WG 
session or offline before or after.

Dean

> On Feb 14, 2017, at 11:23 AM, Adrian Farrel  wrote:
> 
> Hi Tianran,
> 
> Nice summary.
> 
> I think some of the confusion may be that 
> draft-ietf-netmod-yang-model-classification shows "Network Service YANG 
> Modules" on the interface between OSS/BSS and the network. But the "customer 
> service model" is at a different place in the hierarchy as shown in Figure 4 
> of draft-wu-opsawg-service-model-explained.
> 
> To attend to your specific questions:
>> 1. Whether it's necessary to further classify the "Network Service YANG
>> Module"?
> 
> I'm not particularly interested in doing that except so far as is necessary 
> to avoid conflict between the two I-Ds. In 
> draft-wu-opsawg-service-model-explained we introduced "customer service 
> module" and "service delivery module" because it seemed (to us) that there 
> were two different groups of people using the term "service model" to 
> describe very different modules.
> 
>> 2. What's the well definition of "Network Service YANG Module", "customer
>> service module", "service delivery module"?
> 
> Since draft-wu-opsawg-service-model-explained introduces the terms "customer 
> service module" and "service delivery module" I am going to say that I am 
> happy with the definitions in that document. I can say that "customer service 
> module" is used consistently with the L3SM and L2SM work and so it is 
> probably a stable definition. "Service delivery module" is a term we invented 
> to match the definition in draft-wu-opsawg-service-model-explained: I don't 
> think the term is used anywhere else, so maybe a better question is "is this 
> a useful/meaningful term?"
> 
> If the answer to Q1 is that draft-wu-opsawg-service-model-explained should 
> not try to resolve any overlap with 
> draft-ietf-netmod-yang-model-classification, then I think the definition of 
> "Network Service YANG Module" in draft-ietf-netmod-yang-model-classification 
> is fine (with the few tweaks Dean and I discussed on the list).
> 
>> 3. What's the well position of the above terms in the management 
>> architecture?
> 
> Ah, I like that question. But it makes me ask: where should I look for the 
> definitive, state-of-the art management architecture?
> 
> Thanks for continuing to drive this issue.
> 
> Adrian
> 
>> -Original Message-
>> From: Tianran Zhou [mailto:zhoutian...@huawei.com]
>> Sent: 14 February 2017 09:54
>> To: Carl Moberg (camoberg); adr...@olddog.co.uk
>> Cc: ops...@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org;
>> netmod@ietf.org; Dean Bogdanovic
>> Subject: RE: Question on draft-ietf-netmod-yang-model-classification
>> 
>> Hi,
>> 
>> Based on the discussion, here I try to clean up the confusion of the two 
>> I-Ds.
>> 
>> [draft-ietf-netmod-yang-model-classification] classifies the yang modules 
>> into
>> "Network Service YANG Module" and the "Network Element YANG Module".
>> And usually, it uses "service module" to imply the "Network Service YANG
>> Module", i.e., "Network" here only want to limit the scope to network related
>> modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm-
>> l3vpn-service-model].
>> The authors do not want to further classify the service module into more 
>> layers,
>> until more operational practice comes.
>> 
>> [draft-wu-opsawg-service-model-explained] further classifies the service 
>> module
>> into "customer service module" and the "service delivery module". I think 
>> this is
>> based on the chair work on L3SM and L2SM WG and discussion with operators.
>> But the document think the "Network Service YANG Module" defined in [draft-
>> ietf-netmod-yang-model-classification] is "service delivery module" not 
>> include
>> the "customer service module". The [draft-ietf-l3sm-l3vpn-service-model] is
>> actually the "customer service module".
>> 
>> Here comes the question:
>> 1. Whether it's necessary to further classify the "Network Service YANG
>> Module"?
>> 2. What's the well definition of "Network Service YANG Module", "customer
>> service module", "service delivery module"?
>> 3. What's the well position of the above terms in the management 
>> architecture?
>> 
>> Good to see if we can solve the conflicts, these two I-Ds can complement each
>> other.
>> 
>> Best,
>> Tianran
>> 
>>> --

[netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : Common Interface Extension YANG Data Models
Authors : Robert Wilton
  David Ball
  Tapraj Singh
  Selvakumar Sivaraj
Filename: draft-ietf-netmod-intf-ext-yang-04.txt
Pages   : 26
Date: 2017-03-13

Abstract:
   This document defines two YANG modules that augment the Interfaces
   data model defined in the "YANG Data Model for Interface Management"
   with additional configuration and operational data nodes to support
   common lower layer interface properties, such as interface MTU.
   These properties are common to many types of interfaces on network
   routers and switches and are implemented by multiple network
   equipment vendors with similar semantics, even though some of the
   features are not formally defined in any published standard.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-04


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] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt

[Dean Bogdanovic]

Here is the new version of the ACL draft. Since December and some additional 
comments about the ACL model, I spoke with many operators and how they use 
ACLs. I have also received lot of detailed ACL configurations. In most cases, 
the model is easily adapted to the current use cases in operations. But to 
answer the comments, the authors have added a detailed example in the addendum 
section how the model can be extended and how this model can be used.

Cheers,

Dean


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt
> Date: March 13, 2017 at 10:52:38 AM GMT+1
> To: , "Kiran Koushik" , "Lisa 
> Huang" , "Dean Bogdanovic" , "Dana 
> Blair" , "Kiran Agrahara Sreenivasa" 
> 
> 
> A new version of I-D, draft-ietf-netmod-acl-model-10.txt
> has been successfully submitted by Dean Bogdanovic and posted to the
> IETF repository.
> 
> Name: draft-ietf-netmod-acl-model
> Revision: 10
> Title:Network Access Control List (ACL) YANG Data Model
> Document date:2017-03-13
> Group:netmod
> Pages:32
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-10.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-10
> 
> Abstract:
>   This document describes a data model of Access Control List (ACL)
>   basic building blocks.
> 
>   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.  Please note
>   that no other RFC Editor instructions are specified anywhere else in
>   this document.
> 
>   Artwork in this document contains shorthand references to drafts in
>   progress.  Please apply the following replacements
> 
>   o  "" --> the assigned RFC value for this draft.
> 
>   o  Revision date in model (Oct 12, 2016) needs to get updated with
>  the date the draft gets approved.  The date also needs to get
>  reflected on the line with .
> 
> 
> 
> 
> 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
> 

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

[netmod] I-D Action: draft-ietf-netmod-acl-model-10.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : Network Access Control List (ACL) YANG Data Model
Authors : Dean Bogdanovic
  Kiran Agrahara Sreenivasa
  Lisa Huang
  Dana Blair
Filename: draft-ietf-netmod-acl-model-10.txt
Pages   : 32
Date: 2017-03-13

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   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.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "" --> the assigned RFC value for this draft.

   o  Revision date in model (Oct 12, 2016) needs to get updated with
  the date the draft gets approved.  The date also needs to get
  reflected on the line with .


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10

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


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

[Martin Bjorklund]

Benoit Claise  wrote:
> Hi Martin,
> 
> ietf-hardw...@2017-03-07.yang fails yanglint validation.
> See http://www.claise.be/IETFYANGPageCompilation.html

This is a bug in yanglint.  The leafref is marked as 'require-instance
false', which means it can refer to a non-config leaf.


/martin


> 
> Regards, Benoit
> > Hi,
> >
> > This version addresses the comments from Bart and Juergen.
> >
> > I think that this document is now ready for WGLC.
> >
> >
> > /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 NETCONF Data Modeling Language 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-03.txt
> >>Pages   : 40
> >>Date: 2017-03-13
> >>
> >> 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's also a htmlized version available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-entity-03
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 

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

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

[Benoit Claise]

Hi Martin,

ietf-hardw...@2017-03-07.yang fails yanglint validation.
See http://www.claise.be/IETFYANGPageCompilation.html

Regards, Benoit

Hi,

This version addresses the comments from Bart and Juergen.

I think that this document is now ready for WGLC.


/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 NETCONF Data Modeling Language 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-03.txt
Pages   : 40
Date: 2017-03-13

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-03

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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



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

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

[Martin Bjorklund]

Hi,

This version addresses the comments from Bart and Juergen.

I think that this document is now ready for WGLC.


/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 NETCONF Data Modeling Language 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-03.txt
>   Pages   : 40
>   Date: 2017-03-13
> 
> 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's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-entity-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-03
> 
> 
> 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-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language 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-03.txt
Pages   : 40
Date: 2017-03-13

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's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-entity-03

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


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