Re: [netmod] draft netmod charter update proposal

2017-03-20 Thread Lou Berger 
Benoit,

Okay - we'll add the intended status to the milestones. 

Lou

On 3/20/2017 7:09 AM, Benoit Claise wrote:
> Lou,
>
> In all my WGs, we consistently documented the intended status in the
> milestones, expressing the _intended _status at the time of the
> charter discussion
>
> Regards, Benoit
>> Juergen,
>>
>> Thank you for the input.  I think your point highlights how the
>> technical  contents of a document drives the intended status of a
>> document.
>>
>> Lou
>>
>> PS as a reminder to all, intended status of documents is *not*
>> typically included in charters and are not included in the
>> distributed version.
>>
>>
>>
>>
>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder
>>  wrote:
>>
>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:
>>>
 That said different people including Netconf WG co-chairs think the DS
 concept document is Informational in nature and should be published
 as an
 Informational concept to be used in and adopted for the needs in
 diverse
 protocol WGs. This is as I think also important to avoid an
 overlapping
 between NETCONF and NETMOD charters.
>>>
>>> The current datastore draft includes concrete YANG idenity definitions
>>> for datastores and origins and these definitions better be standards
>>> track.
>>>
>>> /js
>>>
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>

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

Re: [netmod] some comments on revised-datastores-01

2017-03-20 Thread Andy Bierman 
Hi,

Not sure I like the YANG module with all the datastore identities
because it makes datastore discovery more complicated.
I prefer the server advertise capabilities in the  message.

More importantly, all the existing NETCONF operations use
a container with a choice in it to select the source and target for various
operations.
It is trivial for a YANG module to simply augment these choices with new
leafs,
rather than forcing all client and server implementations to duplicate
these operations
with identifyref leafs for these parameters.


Andy



On Mon, Mar 20, 2017 at 10:09 AM, Kent Watsen  wrote:

>
> > I believe this is the wrong direction, even if we rewrite the module
> > in the revised datastores document and split it into multiple modules.
> > A simple list of implemented datastores is cheap. It is flexible. It
> > does not require explanations and rules how definitions must be split
> > into modules that finally must be remembered and checked still in 5-10
> > years from now. I firmly believe that these types of 'optimizations'
> > lead to creeping complexity down the road. Lets not create CLRs how
> > modules must be structued, named, etc.
>
> That's a better answer.  At least now I get the sense that you actually
> understood what I was saying.
>
> As for your proposal, I agree with you that it would be best to have an
> explicit list.  I assume that this would be another proposed change to
> YANG Library (i.e., Section D.2 in the revised-datastores draft).  It
> will be tricky to enforce the use of this version of YANG Library in
> RESTCONF without a -bis document...
>
> K.
>
>
> ___
> 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 netmod charter update proposal

2017-03-20 Thread Susan Hares 
Kent and Lada: 
 

I agree that we need some parameters in yang.  I agree with version 1 of the
revised datastores.   

In my proposal regarding I2RS Yang, I tried to start suggesting some
parameters for control plane datastores, and ephemeral control plane
datastores.   In this I also suggest a "validation" key word that will
provide additional validation sequences for the control plane datastores.
There may be better ways to do this in Yang, but I hope it is a start. 

https://datatracker.ietf.org/doc/draft-hares-i2nsf-capability-yang/

If we start with this yang, I thought it made the capabilities easier to
define for NETCONF and RESTCONF.
https://datatracker.ietf.org/doc/draft-hares-netconf-i2rs-netconf/

I welcome any change or fixes.  I tried to make things concrete so it would
help the discussion. 

Sue 


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
Sent: Friday, March 17, 2017 11:40 AM
To: Ladislav Lhotka; Robert Wilton
Cc: netmod@ietf.org
Subject: Re: [netmod] draft netmod charter update proposal

Hi Lada,

I think some of what you're getting at is in these guidelines:

 
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01#section-
5

But you're thinking about something more generalized?

Kent  // contributor


-ORIGINAL MESSAGE-

> On 17 Mar 2017, at 15:46, Robert Wilton  wrote:
> 
> 
> 
> On 17/03/2017 14:32, Ladislav Lhotka wrote:
>>> On 17 Mar 2017, at 15:04, Robert Wilton  wrote:
>>> 
>>> Hi,
>>> 
>>> Would 7950bis be allowed to have a normative reference to an
Informational RFC that defined the YANG datastores?
>> My idea is that 7950bis should be made independent of any particular set
of datastores, so such a normative reference shouldn't be needed.
> OK, if 70590bis was entirely datastore agnostic, then there would need 
> to be a description of how YANG applies to a particular set of 
> datastores (in particular the config: true|false statement), and which 
> datastores are validated.  Would that go in the revised

I don't think that config true/false is necessarily tied to a particular set
of datastores, it can be generalized to RW/RO.

>  datastores architecture or somewhere else?  It wouldn't make sense to
have to repeat this for every network configuration protocol.

I think the structure of datastores and validation workflow could be
supplied as extra info, see item #3 near the end of this message:

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

Lada

> 
> Thanks,
> Rob
> 
> 
>> 
>> Lada
>> 
>>> If we did a 7950bis document (and it isn't clear that one is actually
required to support the revised datastores draft) then does that mean we
would also need to have a new version of YANG?
>>> 
>>> That would potentially seem like a backwards step.  Also what would it
mean for an implementation that is aware of the new datastores but is using
a mix of YANG modules with different versions?
>>> 
>>> I don't understand why the revised datastores draft should not be
standards track once the various appendices have been moved out, noting that
they are really only in the one draft at this stage because it seemed like
that would make it easier for folks to review and comment on.
>>> 
>>> Is the only issue here which WG the draft is being worked on?
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>> On 17/03/2017 13:22, Mehmet Ersue wrote:
 I think YANG identities should be standardized with 7950bis.
 
 Mehmet
 
> -Original Message-
> From: Lou Berger [mailto:lber...@labn.net]
> Sent: Thursday, March 16, 2017 12:28 PM
> To: Juergen Schoenwaelder ;
> Mehmet Ersue 
> Cc: 'Kent Watsen' ; netmod@ietf.org
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Juergen,
> 
> Thank you for the input.  I think your point highlights how the 
> technical contents of a document drives the intended status of a
document.
> 
> Lou
> 
> PS as a reminder to all, intended status of documents is *not* 
> typically included in charters and are not included in the distributed
version.
> 
> 
> 
> 
> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder 
>  wrote:
> 
>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:
>> 
>>> That said different people including Netconf WG co-chairs think 
>>> the DS concept document is Informational in nature and should be 
>>> published as
> an
>>> Informational concept to be used in and adopted for the needs in
 diverse
>>> protocol WGs. This is as I think also important to avoid an 
>>> overlapping between NETCONF and NETMOD charters.
>> The current datastore draft includes concrete YANG idenity 
>> definitions for datastores and origins and these definitions

Re: [netmod] some comments on revised-datastores-01

2017-03-20 Thread Kent Watsen 

> I believe this is the wrong direction, even if we rewrite the module
> in the revised datastores document and split it into multiple modules.
> A simple list of implemented datastores is cheap. It is flexible. It
> does not require explanations and rules how definitions must be split
> into modules that finally must be remembered and checked still in 5-10
> years from now. I firmly believe that these types of 'optimizations'
> lead to creeping complexity down the road. Lets not create CLRs how
> modules must be structued, named, etc.

That's a better answer.  At least now I get the sense that you actually
understood what I was saying.

As for your proposal, I agree with you that it would be best to have an
explicit list.  I assume that this would be another proposed change to
YANG Library (i.e., Section D.2 in the revised-datastores draft).  It
will be tricky to enforce the use of this version of YANG Library in 
RESTCONF without a -bis document...

K.


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

Re: [netmod] some comments on revised-datastores-01

2017-03-20 Thread Juergen Schoenwaelder 
On Mon, Mar 20, 2017 at 02:28:53PM +, Kent Watsen wrote:
> 
> > But this logic is already broken for the datastores defined in the
> > revised datastores document. It defines an identity for startup but
> > not all systems implement startup. End of proof.
> 
> Ha ha, yes professor.  But recall this started as a discussion regarding
> what to do for the new dynamic datastores (not built-in datastores) and
> then someone said maybe we should support other datastores too.  I'm not
> sure we need to do this but, if we did, then we could create modules for
> them (i.e., ietf-startup).
>

I believe this is the wrong direction, even if we rewrite the module
in the revised datastores document and split it into multiple modules.
A simple list of implemented datastores is cheap. It is flexible. It
does not require explanations and rules how definitions must be split
into modules that finally must be remembered and checked still in 5-10
years from now. I firmly believe that these types of 'optimizations'
lead to creeping complexity down the road. Lets not create CLRs how
modules must be structued, named, etc.

/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] some comments on revised-datastores-01

2017-03-20 Thread Kent Watsen 

> But this logic is already broken for the datastores defined in the
> revised datastores document. It defines an identity for startup but
> not all systems implement startup. End of proof.

Ha ha, yes professor.  But recall this started as a discussion regarding
what to do for the new dynamic datastores (not built-in datastores) and
then someone said maybe we should support other datastores too.  I'm not
sure we need to do this but, if we did, then we could create modules for
them (i.e., ietf-startup).

K.


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

Re: [netmod] some comments on revised-datastores-01

2017-03-20 Thread Juergen Schoenwaelder 
On Mon, Mar 20, 2017 at 02:05:09PM +, Kent Watsen wrote:
> 
> Why are you mentioning identities here?  Yes, the module defines 
> identities, but that is beside the point to what I'm saying.  I'm
> only discussing the module (e.g. ietf-i2rs-solution) showing up
> in YANG Library and using the age-old logic of, if the server
> advertises it, then it means that it supports it, which in this
> case means that it supports all the datastores defined by the
> module.
>

But this logic is already broken for the datastores defined in the
revised datastores document. It defines an identity for startup but
not all systems implement startup. End of proof.

/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] some comments on revised-datastores-01

2017-03-20 Thread Kent Watsen 

 
>> It seems okay for more than one datastore to be represented by a single
>> module.  Presumably the set of them come together as a package (all or
>> none), right?  This could be a datastore-designer decision to make.
>>
>> For instance, I2RS talks about priority-ordered planes of glass, so maybe
>> they have a single "ietf-ds-ephemeral" module defining a package of 
>> datastores like: plane-1, plane-2, ... plane-8.
>> 
>> Yes, we could have a separate explicit list, but it'd be nice if we 
>> could reuse what we have...
>
>
> Sorry, overloading is bad. The definition of an identity does in
> general not mean an implementation of an identity.

Why are you mentioning identities here?  Yes, the module defines 
identities, but that is beside the point to what I'm saying.  I'm
only discussing the module (e.g. ietf-i2rs-solution) showing up
in YANG Library and using the age-old logic of, if the server
advertises it, then it means that it supports it, which in this
case means that it supports all the datastores defined by the
module.

K.


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

Re: [netmod] LL review of draft-ietf-netmod-intf-ext-yang-03

2017-03-20 Thread Robert Wilton 

Hi Acee,

On 17/03/2017 17:18, Acee Lindem (acee) wrote:

Hi Rob,

On 3/10/17, 9:46 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:


Lada,

Thanks for the comments, some further comments inline ...


On 10/03/2017 14:09, Ladislav Lhotka wrote:

Hi Rob,

please see inline.

Robert Wilton  writes:


Hi Lada,

To pick up an old thread, I'm updating the interface model per your
comments below, and I had a few questions that you might have an
opinion on.

On 22/12/2016 14:32, Robert Wilton wrote:

Hi Lada,

Thanks for the review and comments.


On 21/12/2016 13:08, Ladislav Lhotka wrote:

Hi,

I think this is a very useful addition to ietf-interfaces. In
general,
the document is clearly written and YANG modules nicely designed.
Here
are my comments:

*** Sec. 1
   - "This document defines two YANG RFC 7950 [RFC7950] modules Š"
 looks weird. I'd suggest "Š YANG 1.1 [RFC7950] Š" instead.

OK.

Fixed.

*** Sec. 2
   - first line: s/of of/of/

Fixed.


*** Sec. 3.1
   - If the "bandwidth" parameter is only used for tuning routing
 algorithms and has nothing to do with real bandwidth on the
 interface, I would suggest to use a different name
 (metric?). Perhaps it may indeed be better to leave this to
 routing protocol modules because they can also specify how
 exactly such a parameter is used.

Yes, possibility it would be better to define this as part of the
routing models.  The idea here is that the bandwidth would span across
the routing protocols rather than be tied to a specific protocol.

I think that we need a better name than just "bandwidth" since this
leaf
doesn't affect the actual bandwidth on the of the link, just the
bandwidth that is reported to routing protocols to implicitly adjust
their link metrics.  Hence, I was considering renaming this to
"reported-bandwidth"?

This looks like something for routing people to decide.

I believe this is referred to as maximum-reservable-bandwidth in RFC 3630.


2.5.7.  Maximum Reservable Bandwidth

The Maximum Reservable Bandwidth sub-TLV specifies the maximum
bandwidth that may be reserved on this link, in this direction, in
IEEE floating point format.  Note that this may be greater than the
maximum bandwidth (in which case the link may be oversubscribed).
This SHOULD be user-configurable; the default value should be the
Maximum Bandwidth.  The units are bytes per second.

Perhaps, reservable-bandwidth would suffice.

I like that suggestion.

I'll raise this on the rtgwg alias as well.







I also think that it would be good to follow up with the routing folks
to see if this leaf would be better covered in a general routing model.
Where do you think is the best place that I raise this, the routing
area
yang design team?

Maybe, or RTGWG?

OK.  I'll send an email that way, after I've published this next revision.


*** Sec. 3.6
   - The "l3-mtu" parameter is probably the same as "mtu" defined
in
 ietf-ip. Again, I would suggest to leave the definition of
MTU
 to each L3 protocol because there may be specific aspects and
 constraints.

The MTU being defined here is an "l2-mtu" parameter.  I.e. the maximum
size of the L2 frames that can be sent/received.  For some devices
this value is independent of a protocol specific L3 MTU that only
affects that particular protocol instance.

I've updated the text to make it clear that it is only a L2 MTU
configuration leaf, and if not configured, the system will
automatically
decide on the L2 MTU.

Shouldn't it have a "when" substatement to make it available only for
"layer-2" interfaces?

It can apply to all interfaces that use a layer 2 encapsulation, i.e.
most interfaces.

It seems that an L3 interface could still have an L2 MTU? Of course, the
IP or IPv6 MTU could not exceed the L2 MTU.
Yes, an L3 interface still has a L2 MTU, and on some systems this 
configuration item can be used to indirectly control the IP/IPv6 
protocol MTUs on the interface, or the MTUs of any sub-interfaces.


Some network OSes control their MTU from an L2 perspective, i.e. you 
normally configure the L2 MTU, and the system works out what L2 payload 
size is available to the L3 protocols.


Other network OSes control them MTU from an L3 perspective, i.e. you 
configure the L3 MTU, and the system calculates the L2 overhead, 
possibly with some extra slop space, to program into the Ethernet MAC 
chip to police the maximum size of frame that can be sent or received.



Perhaps it would be beneficial to add some text to explain the 
relationships between the MTUs values for L2 and the protocols to the 
draft?  Actually, it may be beneficial to cover the MTU relationship to 
sub-interfaces as well.













The only interfaces that it wouldn't apply to are:
  - interfaces that are performing optical switching - but then I

Re: [netmod] draft netmod charter update proposal

2017-03-20 Thread Ladislav Lhotka 
"t.petch"  writes:

> - Original Message -
> From: "Ladislav Lhotka" 
> To: "Robert Wilton" 
> Cc: 
> Sent: Friday, March 17, 2017 2:32 PM
>>
>> > On 17 Mar 2017, at 15:04, Robert Wilton  wrote:
>> >
>> > Would 7950bis be allowed to have a normative reference to an
> Informational RFC that defined the YANG datastores?
>>
>> My idea is that 7950bis should be made independent of any particular
> set of datastores, so such a normative reference shouldn't be needed.
>
> Lada
>
> You say 'set of datastores' which I would agree with but I would propose
> that the concept of a datastore, which could be a different term, just
> semantically equivalent to that of 'datastore', is still needed for
> validation.  The scope of validation is a closed set of data and the
> current term for that is datastore (as opposed to module, model or any
> other unit of data)..

Agreed, but I would suggest "data tree" as the subject of
validation. Something more general than datastore is probably needed
because already in RFC 7950 the tree that is validated sometimes
consists of multiple (two) datastores and/or payloads of operations or
notifications.

Lada

>
> Tom Petch
>
>
>
>
>
>
>>
>> Lada
>>
>> >
>> > If we did a 7950bis document (and it isn't clear that one is
> actually required to support the revised datastores draft) then does
> that mean we would also need to have a new version of YANG?
>> >
>> > That would potentially seem like a backwards step.  Also what would
> it mean for an implementation that is aware of the new datastores but is
> using a mix of YANG modules with different versions?
>> >
>> > I don't understand why the revised datastores draft should not be
> standards track once the various appendices have been moved out, noting
> that they are really only in the one draft at this stage because it
> seemed like that would make it easier for folks to review and comment
> on.
>> >
>> > Is the only issue here which WG the draft is being worked on?
>> >
>> > Thanks,
>> > Rob
>> >
>> >
>> > On 17/03/2017 13:22, Mehmet Ersue wrote:
>> >> I think YANG identities should be standardized with 7950bis.
>> >>
>> >> Mehmet
>> >>
>> >>> -Original Message-
>> >>> From: Lou Berger [mailto:lber...@labn.net]
>> >>> Sent: Thursday, March 16, 2017 12:28 PM
>> >>> To: Juergen Schoenwaelder ;
>> >>> Mehmet Ersue 
>> >>> Cc: 'Kent Watsen' ; netmod@ietf.org
>> >>> Subject: Re: [netmod] draft netmod charter update proposal
>> >>>
>> >>> Juergen,
>> >>>
>> >>> Thank you for the input.  I think your point highlights how the
> technical
>> >>> contents of a document drives the intended status of a document.
>> >>>
>> >>> Lou
>> >>>
>> >>> PS as a reminder to all, intended status of documents is *not*
> typically
>> >>> included in charters and are not included in the distributed
> version.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder
>> >>>  wrote:
>> >>>
>>  On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:
>> 
>> > That said different people including Netconf WG co-chairs think
> the DS
>> > concept document is Informational in nature and should be
> published as
>> >>> an
>> > Informational concept to be used in and adopted for the needs in
>> >> diverse
>> > protocol WGs. This is as I think also important to avoid an
> overlapping
>> > between NETCONF and NETMOD charters.
>>  The current datastore draft includes concrete YANG idenity
> definitions
>>  for datastores and origins and these definitions better be
> standards
>>  track.
>> 
>>  /js
>> 
>>  --
>>  Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>  Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen |
> Germany
>>  Fax:   +49 421 200 3103
> 
>> 
>> >>
>> >> ___
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >> .
>> >>
>> >
>> > ___
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>>
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] draft netmod charter update proposal

2017-03-20 Thread Ladislav Lhotka 
Kent Watsen  writes:

> Hi Lada,
>
> I think some of what you're getting at is in these guidelines:
>
>   
> https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01#section-5
>
> But you're thinking about something more generalized?

Most likely yes - what I have in mind is something like datastore
modelling mini-language. To some extent, NETCONF already does this via
capabilities: server implementors can choose and advertize different variants of
running-candidate-startup organization.

Lada

>
> Kent  // contributor
>
>
> -ORIGINAL MESSAGE-
>
>> On 17 Mar 2017, at 15:46, Robert Wilton  wrote:
>> 
>> 
>> 
>> On 17/03/2017 14:32, Ladislav Lhotka wrote:
 On 17 Mar 2017, at 15:04, Robert Wilton  wrote:
 
 Hi,
 
 Would 7950bis be allowed to have a normative reference to an Informational 
 RFC that defined the YANG datastores?
>>> My idea is that 7950bis should be made independent of any particular set of 
>>> datastores, so such a normative reference shouldn't be needed.
>> OK, if 70590bis was entirely datastore agnostic, then there would need to be 
>> a description of how YANG applies to a particular set of datastores (in 
>> particular the config: true|false statement), and which datastores are 
>> validated.  Would that go in the revised
>
> I don't think that config true/false is necessarily tied to a particular set 
> of datastores, it can be generalized to RW/RO.
>
>>  datastores architecture or somewhere else?  It wouldn't make sense to have 
>> to repeat this for every network configuration protocol.
>
> I think the structure of datastores and validation workflow could be supplied 
> as extra info, see item #3 near the end of this message:
>
> https://www.ietf.org/mail-archive/web/netmod/current/msg17673.html
>
> Lada
>
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> 
>>> Lada
>>> 
 If we did a 7950bis document (and it isn't clear that one is actually 
 required to support the revised datastores draft) then does that mean we 
 would also need to have a new version of YANG?
 
 That would potentially seem like a backwards step.  Also what would it 
 mean for an implementation that is aware of the new datastores but is 
 using a mix of YANG modules with different versions?
 
 I don't understand why the revised datastores draft should not be 
 standards track once the various appendices have been moved out, noting 
 that they are really only in the one draft at this stage because it seemed 
 like that would make it easier for folks to review and comment on.
 
 Is the only issue here which WG the draft is being worked on?
 
 Thanks,
 Rob
 
 
 On 17/03/2017 13:22, Mehmet Ersue wrote:
> I think YANG identities should be standardized with 7950bis.
> 
> Mehmet
> 
>> -Original Message-
>> From: Lou Berger [mailto:lber...@labn.net]
>> Sent: Thursday, March 16, 2017 12:28 PM
>> To: Juergen Schoenwaelder ;
>> Mehmet Ersue 
>> Cc: 'Kent Watsen' ; netmod@ietf.org
>> Subject: Re: [netmod] draft netmod charter update proposal
>> 
>> Juergen,
>> 
>> Thank you for the input.  I think your point highlights how the technical
>> contents of a document drives the intended status of a document.
>> 
>> Lou
>> 
>> PS as a reminder to all, intended status of documents is *not* typically
>> included in charters and are not included in the distributed version.
>> 
>> 
>> 
>> 
>> On March 16, 2017 2:44:53 AM Juergen Schoenwaelder
>>  wrote:
>> 
>>> On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:
>>> 
 That said different people including Netconf WG co-chairs think the DS
 concept document is Informational in nature and should be published as
>> an
 Informational concept to be used in and adopted for the needs in
> diverse
 protocol WGs. This is as I think also important to avoid an overlapping
 between NETCONF and NETMOD charters.
>>> The current datastore draft includes concrete YANG idenity definitions
>>> for datastores and origins and these definitions better be standards
>>> track.
>>> 
>>> /js
>>> 
>>> --
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>>> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
> 
 ___
 netmod mailing list
 netmod@ietf.org

Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00

2017-03-20 Thread Ladislav Lhotka 
Robert Wilton  writes:

> On 17/03/2017 15:08, Ladislav Lhotka wrote:
>>> On 17 Mar 2017, at 15:11, Robert Wilton  wrote:
>>>
>>>
>>>
>>> On 17/03/2017 12:55, Ladislav Lhotka wrote:
 Hi Rob,

 thank you for reading the draft.

> On 17 Mar 2017, at 13:30, Robert Wilton  wrote:
>
> Hi Lada,
>
> I've had a quick scan of your YANG markup extension draft and I have a 
> few comments:
>
> Allowing description, and similar descriptive statements, to use 
> something other than text seems like it could be useful in some cases.
>
> I'm not sure that allowing the statements to use any text-like
> media type is a good idea, this could increase the burden on tool
> makers if each module author chooses their own preferred format.
>
> Instead, I think that it might be better to restrict it to a very small 
> set of media types, that could be extended in future.  I would think that 
> initially just allowing plain text and one particular flavour of markdown 
> would be a reasonable starting point.
 I agree although I am not sure that we can easily find an agreement on the 
 particular flavour. So maybe we can leave it open and let the "market" 
 decide.
>>> I think that would be a mistake.  How would device/tools vendors know which 
>>> versions to spend time implementing?
>> I would agree to have a fixed choice in 6087bis, but there may be niche 
>> communities or special cases that need something else, so YANG IMO shouldn't 
>> preclude it a priori.
> I think that this idea works quite well as a YANG extension, and that 
> would be a better path than baking it into YANG at this time.
>
> I'm still not convinced that allowing an arbitrary encoding is a good idea.
>

The burden on tool makers wouldn't be much less if authors use only
lightweight markups - for example, markdown and reStructuredText would
still need two parsers.

>>
> I think that the only formats that should be allowed are those that are 
> still readily readable as plain text, so that tools that don't want to 
> parse the formatted text can still sensibly display the descriptive 
> statements.  I.e. I don't think that it would be helpful to allow things 
> like text/xml since it isn't easy to read.
 Sure, and the draft says:

 It is RECOMMENDED to use only media types representing "lightweight"
 markup that is easy to read even in the unprocessed source form, such
 as "text/markdown".
>>> I was proposing REQUIRED instead of RECOMMENDED.
>> I usually write my modules in the YIN format with a very restricted set of 
>> HTML tags that are used in the text arguments:
>>
>> https://gitlab.labs.nic.cz/labs/yang-tools/wikis/editing_yang#yin-schema-extensions
> OK.  I had assumed that nobody was using YIN ;-)

I do, because the nxml mode of Emacs is so great.

>>
>> It would be useful to indicate "text/html" media type, and a YIN->YANG 
>> convertor could translate it e.g. to "text/markdown".
> Isn't that just part of the YIN conversion to YANG. I.e. by the time the 
> file is YANG it would be text/markdown.

That's how I do it now, but I assume modules in YIN syntax could
possibly exist on their own. For example, if they are intended for HTML
rendering, or including in formats like xml2rfc, then YIN could make
sense.

A YIN -> YANG conversion tool would change "text/html" e.g. to
"text/markdown".

Of course, it can be argued that one could use markdown right away in YIN
descriptions but it it often handier to have everything in XML - validators
(such as Emacs) or XSL processors can then also effectively work with
contents of descriptions.

>
>>
> Allowing this extension on particular descriptive statements may also be 
> helpful.  It seems plausible that the vast majority of these statements 
> in a module might just be written in plain text with just a few of them 
> using more advanced formatting like markdown.
 Yes, I was thinking about this. On the other hand, plain text is typically 
 compatible with any markup format, so this would probably be useful only 
 if somebody wanted to use multiple different markup formats in the same 
 module, which sounds crazy. But we can discuss it.
>>> I was only thinking of a mix of some plain text descriptions and some using 
>>> markup.
>>>
>>> Tooling may choose to format raw text differently from markup text (e.g. 
>>> converting lines into a paragraph).  Also a markup processor would be extra 
>>> work, and may not warn or error on the structure of a plain text 
>>> description that doesn't conform to the markup rules.
>> Actually, the design philosophy behind markdown is that there is no formal 
>> concept of validity and so processors should never complain.
> But how does an implementation know what it needs to support so that it 
> works with all descriptions?  I think that

[netmod] NETCONF/NETMOD charters and the revised-datastores draft

2017-03-20 Thread Benoit Claise 

Dear all,

The NETMOD chairs, the NETCONF chairs, and I had a call regarding 
draft-ietf-netmod-revised-datastores & charters.


First of, we must stress that this piece of work is an essential 
building block in the world of data model-driven management.

We also believe we have the right set of people working on this. Good.
So, in the end, the location (NETMOD or NETCONF) has been of lesser 
importance to me.
I believe that we've been spending too much time debating where to 
develop this work, NETMOD or NETCONF.  Now it's time to make a decision.


While the NETMOD WG charter focuses on the YANG language developments & 
encodings & some generic YANG modules, while the NETCONF WG charter 
focuses on the protocol constructs, we've been having blurry boundaries 
at times. Ex: is the YANG library a generic YANG module or an element of 
YANG module discovery, replacing the NETCONF hello message?
We now deal with a third aspect: the non-protocol specific aspects of 
YANG or the operating context of the YANG language. With the 
draft-ietf-netmod-revised-datastores in mind, data stores can be 
considered as views on YANG data models.


After much discussion, the decisions are that the 
draft-ietf-netmod-revised-datastores should be worked in the NETMOD WG 
and that the targeted status of standard track is right (to be described 
in the milestone, as guideline).


Unless there are new arguments, not yet brought up to the two lists, 
let's now devote our energy to the specifications work.


Regards, Benoit (OPS AD).







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

Re: [netmod] draft netmod charter update proposal

2017-03-20 Thread Benoit Claise 

Lou,

In all my WGs, we consistently documented the intended status in the 
milestones, expressing the _intended _status at the time of the charter 
discussion


Regards, Benoit

Juergen,

Thank you for the input.  I think your point highlights how the 
technical  contents of a document drives the intended status of a 
document.


Lou

PS as a reminder to all, intended status of documents is *not* 
typically included in charters and are not included in the distributed 
version.





On March 16, 2017 2:44:53 AM Juergen Schoenwaelder 
 wrote:



On Wed, Mar 15, 2017 at 02:50:06PM +0100, Mehmet Ersue wrote:


That said different people including Netconf WG co-chairs think the DS
concept document is Informational in nature and should be published 
as an
Informational concept to be used in and adopted for the needs in 
diverse

protocol WGs. This is as I think also important to avoid an overlapping
between NETCONF and NETMOD charters.


The current datastore draft includes concrete YANG idenity definitions
for datastores and origins and these definitions better be standards
track.

/js

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




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



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

Re: [netmod] draft netmod charter update proposal

2017-03-20 Thread Benoit Claise 

On 3/1/2017 9:40 PM, Juergen Schoenwaelder wrote:

On Wed, Mar 01, 2017 at 04:56:12PM +, Kent Watsen wrote:

Hi Lada,

I understand your intention here, but I'm inclined to agree with others
that it's better to stick with the term we're using in the documents.
I'm open to the idea of changing the term used in our RFCs, and I believe
that such a change would likely have to begin with the YANG spec, from
which it could flow into other drafts.  With this in mind, I've added an
item to the yang-next tracker:

   https://github.com/netmod-wg/yang-next/issues/17

and I plan to revert this change in the charter text.

Kent,

there either is a decision and plan to change terminology everywhere
or this proposal is in my view a no go. Right now, we seem to use
consistent terminology everywhere - I do not want to loose this
property lightly.

This consistency is an important feature of our documents set IMO.
And adding a sentence, somewhere, sometime, is easy: "the term encoding 
is also known as representation or serialization"


Regards, Benoit


/js



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

Re: [netmod] “case” shorthand

2017-03-20 Thread Martin Bjorklund 
"Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco)"  
wrote:
> Hi,
> 
> RFC7950 section 7.9.2. says that if a “case” statement is omitted
> (i.e. “case” shorthand) and implicit “case” node is created, schema
> node identifiers MUST always explicitly include the implicit “case”
> node identifiers. So the following snippet from yang model (below) is
> valid for Yang 1.1. However, is it also valid for Yang 1.0 ? RFC6020
> is not clear about this and there is no section saying that schema
> node identifiers MUST always explicitly include the implicit “case”
> node identifiers…

Yes, this works the same way in both YANG 1 and 1.1.  The new sentence
was added as a clarification to 7950.



/martin



> 
> choice my-choice {
> container implicit-case-container {
> }
> }
> 
> augment "/my-choice/implicit-case-container" {
> leaf leaf-after-container {
> type empty;
> }
> }
> 
> augment "/my-choice/implicit-case-container/implicit-case-container" {
> leaf leaf-inside-container {
> type empty;
> }
> }
> 
> Thanks.
> [http://wwwin.cisco.com/c/dam/cec/organizations/gmcc/services-tools/signaturetool/images/logo/logo_Cisco_Blue.png]
> 
> 
> 
> Peter Kajsa
> Engineer - Software
> pka...@cisco.com
> Tel:
> 
> Cisco Systems, Inc.
> 
> 
> 
> Slovakia
> cisco.com
> 
> 
> [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think
> before you print.
> 
> This email may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the
> intended recipient (or authorized to receive for the recipient),
> please contact the sender by reply email and delete all copies of this
> message.
> Please click
> here
> for Company Registration Information.
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] “case” shorthand

2017-03-20 Thread Peter Kajsa -X (pkajsa - PANTHEON TECHNOLOGIES at Cisco) 
Hi,

RFC7950 section 7.9.2. says that if a “case” statement is omitted (i.e. “case” 
shorthand) and implicit “case” node is created, schema node identifiers MUST 
always explicitly include the implicit “case” node identifiers. So the 
following snippet from yang model (below) is valid for Yang 1.1. However, is it 
also valid for Yang 1.0 ? RFC6020 is not clear about this and there is no 
section saying that schema node identifiers MUST always explicitly include the 
implicit “case” node identifiers…

choice my-choice {
container implicit-case-container {
}
}

augment "/my-choice/implicit-case-container" {
leaf leaf-after-container {
type empty;
}
}

augment "/my-choice/implicit-case-container/implicit-case-container" {
leaf leaf-inside-container {
type empty;
}
}

Thanks.
[http://wwwin.cisco.com/c/dam/cec/organizations/gmcc/services-tools/signaturetool/images/logo/logo_Cisco_Blue.png]



Peter Kajsa
Engineer - Software
pka...@cisco.com
Tel:

Cisco Systems, Inc.



Slovakia
cisco.com


[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here for 
Company Registration Information.


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

Re: [netmod] some comments on revised-datastores-01

2017-03-20 Thread Juergen Schoenwaelder 
On Sun, Mar 19, 2017 at 07:49:05PM +, Kent Watsen wrote:
> 
> > Obviously, relying on module names does not work if a module defines
> > multiple datastores. So either the set of datastores is identified
> > from reading the whole yang-library list or we provide a separate list
> > (and I think we should provide a separate list).
> 
> It seems okay for more than one datastore to be represented by a single 
> module.  Presumably the set of them come together as a package (all or none), 
> right?  This could be a datastore-designer decision to make.   
> 
> For instance, I2RS talks about priority-ordered planes of glass, so maybe 
> they have a single "ietf-ds-ephemeral" module defining a package of 
> datastores like: plane-1, plane-2, ... plane-8.
> 
> Yes, we could have a separate explicit list, but it'd be nice if we could 
> reuse what we have...
>

Sorry, overloading is bad. The definition of an identity does in
general not mean an implementation of an identity.

/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