Re: [netmod] module update rules

[Ladislav Lhotka]

> On 18 Dec 2015, at 19:42, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
>>> Hi,
>>> 
>>> if we want people to take YANG modules appearing in I-Ds seriously and 
>>> implement them, then we should apply the revisioning rules to them. That 
>>> is, if a module changes between two I-D revisions, then its revision-date 
>>> has to be bumped and a new entry added to the revision history. As it is 
>>> now, the I-D-based modules are esentially revisionless.
>>> 
>>> 
>>> 
>>> The revision rules only apply to published modules.
>> 
>> Update rules of sec. 10 offer no such excuse.
> 
> It says:
> 
>  For any published change, ...

Well, sec. 10 (and 11 in 6020bis) only says: "For any published change, a new 
"revision" statement (Section 7.1.9) MUST be included in front of the existing 
"revision" statements." The update rules aren't conditional in any way.

Lada

> 
> 
> I agree w/ Andy that 6087bis could clarify what this means in terms of
> IETF.
> 
> 
> /martin
> 
> 
>>> In IETF-speak, that means an RFC.  An Internet Draft
>>> is a work-in-progress.  We update the revision date every time
>>> the module changes, but the numerous incremental changes
>>> for a work-in-progress should not be recorded in the module
>>> revision history.  They should be recorded in the Change Log appendix.
>> 
>> Revision numbers are critical for interoperability. If we want
>> vendors to implement modules such as ietf-routing now, the
>> revisions must be solid and reliable.
>> 
>>> 
>>> I will try to make this procedure more clear in the YANG guidelines draft.
>> 
>> I think it should be the other way around: YANG spec should not
>> contain the update rules (because we all ignore them for I-D-based
>> modules, right?), but the IETF guidelines should specify the
>> policy you describe. 
>> 
>> Lada
>> 
>>> 
>>> 
>>> 
>>> Lada
>>> 
>>> 
>>> Andy
>>> 
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

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




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

Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01

[Mahesh Jethanandani]

My preference would also be to leave #5 out. 

> On Dec 18, 2015, at 12:56 PM, Kent Watsen  wrote:
> 
> [As a contributor]
> 
> Hi Juergen,
> 
> I agree with you that req #5 sticks out as the odd ball in the bunch.  I 
> suggested once to remove it a long time back, but I guess it fell on deaf 
> ears then.  Anyway, given where we are with this document, I’m unsure what to 
> do, but here are our options:
> 
> 1. Leave requirement #5 in the document, but spend time improving it to WG 
> satisfaction.
> 
> 2. Take requirement #5 out, declaring it an unwanted distraction from the 
> primary opstate focus.  We’d have to be sure to get sign-off from the OC 
> folks too...
> 
> So far it sounds like Juergen and I are with #2, how about others?
> 
> Thanks,
> Kent
> 
> 
> 
> 
> 
> On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" 
>  wrote:
> 
>> On Thu, Dec 17, 2015 at 09:27:12PM +, Kent Watsen wrote:
>>> [As a contributor]
>>> 
>>> Thank you for the review Juergen.
>>> 
>>> Great suggestions.  If no one objects, I’ll incorporate them into the next 
>>> revision of the document after last call.
>>> 
>>> My one comment is that I don’t believe the document is limited to the 
>>> introduction of applied configuration. For instance, the relating of config 
>>> to derived state and also the model structure requirement are not related 
>>> to applied config.  In all fairness, Requirement #5 (model structure) isn’t 
>>> even about operational state.
>> 
>> Reading #5 again I must admit that I do not really understand what
>> this requirement tries to accomplish:
>> 
>>  5.  Ability for distinct modules to leverage a common model-structure
>> 
>>  A.  Focus on the IETF-defined modules, and ideally provides
>>  guidance to other SDOs
>> 
>>  B.  Multiple domain-specific model-structure trees are okay
>> 
>>  C.  Model-structures may be defined in multiple modules with
>>  distinct namespaces
>> 
>> At this level of abstraction, #5 really does not mean anything or N
>> people will have at least N different interpretations of it. I
>> actually think this should be taken out and moved into a different
>> document and then it requires to be developed into something much more
>> concrete.
>> 
>> /js
>> 
>>> So your title and abstract suggestions might define too narrow a scope.  So 
>>> how about:
>>> 
>>> Title: Terminology and Requirements for Operational State and Model 
>>> Structure
>>> 
>>> Abstract:
>>> This document defines requirements for enhancing the support
>>> of operational state through the introduction of a conceptual
>>> "applied configuration".  The document also defines requirements
>>> enabling distinct modules to leverage a common model structure.
>>> 
>>> …and add an Introduction section that expands on this theme further?
>> 
>> I think this is getting into the wrong direction and as explained
>> above #5 is by far underspecified to be of any value. I suggest to
>> take it out so that we can publish the rest in a timely manner. The
>> alternative is to hold off this document in an attempt to replace #5
>> with something that is concrete and actionable.
>> 
>> /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

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Mahesh Jethanandani]

Agree with Andy and Randy.

> On Dec 17, 2015, at 3:45 PM, Randy Presuhn  
> wrote:
> 
> Hi -
> 
>> From: Robert Wilton
>> Sent: Dec 17, 2015 1:12 PM
>> To: Andy Bierman
>> Cc: "netmod@ietf.org"
>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> ...
>>Your requirement is a bit too strong for my liking.
>> 
>>To paraphrase your requirement text, it is forcing that all
>>compliant NETCONF/RESTCONF servers MUST support any clients that do
>>not want to differentiate between intended config and applied
>>config.
> 
> Do do otherwise sound to me like an interoperability disaster,
> and would encourage the "siloization" of toolsets.
> 
>>However, this requires all opstate aware servers:
>> 
>> - To handle a mix of clients, some of which are opstate aware, and
>> some that are not.
> 
> This seems perfectly reasonable.  To do otherwise torpedoes the very
> notion of interoperability.
> 
>> - To potentially handle a mix of requests, some of which are
>> opstate aware requests, and some are not.
> 
> Ditto. 
> 
>>It also prevents:
>> 
>> - Having a server that is implemented to only support opstate aware
>> clients.
> 
> Avoiding the creation of such servers sounds like a *good* thing to me.
> 
>> - Having a server side configuration knob to control the behaviour
>> (since it would affect the semantics for all clients).
> 
> This also sounds like something which it would be desireable to prevent.
> 
> I think I'm squarely with Andy on this one.
> 
> Randy
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Sterne, Jason (Jason)]

I'm not a fan of adding something like that in the base model.  Let's get a 
basic model done and then we can consider an extension draft.  I'd think that 
things like TCP flags, for example, would be a more natural & common thing to 
add to an ACL model than a host name match so I can't see host name being in 
there before TCP flags (which I'm not advocating for in the base model).

I also don't think the metadata interface match should be in this base model 
either.  That is out of place IMO.  The base model provides an ACL that can 
then get associated with objects like interfaces (as in the example in section 
A.3).

I'd also suggest we consider making the actions 'deny' and 'permit' presence 
containers instead of empty leafs.  That would allow easier augmentations (e.g. 
additional 'permit' parameters for policy based forwarding for example).

Regards,
Jason

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Nadeau Thomas
Sent: Thursday, December 17, 2015 10:53
To: Lear Eliot
Cc: Benoit Claise; RTG YANG Design Team; netmod WG
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06


You raise a good point. Do the contributors/editors have any thoughts 
on this suggestion?

—Tom


> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  wrote:
> 
> 
> 
> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>  Do you mean an ASCII DNS name (versus an IP address w a mask)?
> 
> I was thinking of "host" in RFC 6021.
> 
> Eliot
> 
> 

___
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] module update rules

[Andy Bierman]

On Fri, Dec 18, 2015 at 1:08 PM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
> > On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps 
> wrote:
> >
> >>
> >> Martin Bjorklund  writes:
> >>
> >> > Christian Hopps  wrote:
> >> >>
> >> >>
> >> >> Versioning has come up in previous conversations I've been a part of,
> >> >> and I was led to believe that it does not really exist for yang
> >> >> modules. That is, if you update a published module it's a completely
> new
> >> >> model with no-expectation of compatibility with previous models.
> >> >
> >> > Please see section 10 of RFC 6020.
> >>
> >> Ok, so I either misunderstood, or was misled. :)
> >>
> >> So my reading of section 10 is that a new revision is the "bump the
> >> minor" action, and a new module is required for "bump the major".
> >>
> >>
> >
> > There are no major or minor revision numbers in YANG.
> > There are on revision date strings -MM-DD.
>
> I thought that was the point I was making (the ""s being a reference
> to my earlier mail), sorry for being confusing.
>
>

YANG is a bit confusing, because it is not code, even though
we use it that way.  Major revisions do not exist because major changes
are simply not allowed to existing definitions.  You introduce new
definitions
to make major changes.  This can be in the same module or a new module.





> Chris.
>
>
Andy


>
> >
> >
> >
> >> Thanks,
> >> Chris.
> >>
> >>
> > Andy
> >
> >
> >>
> >> >
> >> >> Is it the case that there's no way to "bump the minor version" of a
> >> >> model (i.e., you make only additions, but no deletions or changes to
> >> >> meaning so that the model can be considered backward compatible)?
> >> >
> >> > All rules in section 10 of RFC 6020 are backwards compatible.
> >> >
> >> > Also note that you can deprecate and obsolete nodes and define new
> >> > nodes in the same module.
> >> >
> >> >
> >> >
> >> > /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] module update rules

[Christian Hopps]

Andy Bierman  writes:

> On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps  wrote:
>
>>
>> Martin Bjorklund  writes:
>>
>> > Christian Hopps  wrote:
>> >>
>> >>
>> >> Versioning has come up in previous conversations I've been a part of,
>> >> and I was led to believe that it does not really exist for yang
>> >> modules. That is, if you update a published module it's a completely new
>> >> model with no-expectation of compatibility with previous models.
>> >
>> > Please see section 10 of RFC 6020.
>>
>> Ok, so I either misunderstood, or was misled. :)
>>
>> So my reading of section 10 is that a new revision is the "bump the
>> minor" action, and a new module is required for "bump the major".
>>
>>
>
> There are no major or minor revision numbers in YANG.
> There are on revision date strings -MM-DD.

I thought that was the point I was making (the ""s being a reference
to my earlier mail), sorry for being confusing.

Chris.


>
>
>
>> Thanks,
>> Chris.
>>
>>
> Andy
>
>
>>
>> >
>> >> Is it the case that there's no way to "bump the minor version" of a
>> >> model (i.e., you make only additions, but no deletions or changes to
>> >> meaning so that the model can be considered backward compatible)?
>> >
>> > All rules in section 10 of RFC 6020 are backwards compatible.
>> >
>> > Also note that you can deprecate and obsolete nodes and define new
>> > nodes in the same module.
>> >
>> >
>> >
>> > /martin
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01

[Kent Watsen]

[As a contributor]

Hi Juergen,

I agree with you that req #5 sticks out as the odd ball in the bunch.  I 
suggested once to remove it a long time back, but I guess it fell on deaf ears 
then.  Anyway, given where we are with this document, I’m unsure what to do, 
but here are our options:

1. Leave requirement #5 in the document, but spend time improving it to WG 
satisfaction.

2. Take requirement #5 out, declaring it an unwanted distraction from the 
primary opstate focus.  We’d have to be sure to get sign-off from the OC folks 
too...

So far it sounds like Juergen and I are with #2, how about others?

Thanks,
Kent





On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" 
 wrote:

>On Thu, Dec 17, 2015 at 09:27:12PM +, Kent Watsen wrote:
>> [As a contributor]
>> 
>> Thank you for the review Juergen.
>> 
>> Great suggestions.  If no one objects, I’ll incorporate them into the next 
>> revision of the document after last call.
>> 
>> My one comment is that I don’t believe the document is limited to the 
>> introduction of applied configuration. For instance, the relating of config 
>> to derived state and also the model structure requirement are not related to 
>> applied config.  In all fairness, Requirement #5 (model structure) isn’t 
>> even about operational state.
>
>Reading #5 again I must admit that I do not really understand what
>this requirement tries to accomplish:
>
>   5.  Ability for distinct modules to leverage a common model-structure
>
>   A.  Focus on the IETF-defined modules, and ideally provides
>   guidance to other SDOs
>
>   B.  Multiple domain-specific model-structure trees are okay
>
>   C.  Model-structures may be defined in multiple modules with
>   distinct namespaces
>
>At this level of abstraction, #5 really does not mean anything or N
>people will have at least N different interpretations of it. I
>actually think this should be taken out and moved into a different
>document and then it requires to be developed into something much more
>concrete.
>
>/js
>
>> So your title and abstract suggestions might define too narrow a scope.  So 
>> how about:
>> 
>> Title: Terminology and Requirements for Operational State and Model Structure
>>
>> Abstract:
>>  This document defines requirements for enhancing the support
>>  of operational state through the introduction of a conceptual
>>  "applied configuration".  The document also defines requirements
>>  enabling distinct modules to leverage a common model structure.
>> 
>> …and add an Introduction section that expands on this theme further?
>
>I think this is getting into the wrong direction and as explained
>above #5 is by far underspecified to be of any value. I suggest to
>take it out so that we can publish the rest in a timely manner. The
>alternative is to hold off this document in an attempt to replace #5
>with something that is concrete and actionable.
>
>/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] module update rules

[Andy Bierman]

On Fri, Dec 18, 2015 at 12:23 PM, Nadeau Thomas 
wrote:

>
> On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman 
> wrote:
>
>
>
> On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas 
> wrote:
>
>>
>> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman 
>> wrote:
>>
>>
>>
>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
>>
>>> Hi,
>>>
>>> if we want people to take YANG modules appearing in I-Ds seriously and
>>> implement them, then we should apply the revisioning rules to them. That
>>> is, if a module changes between two I-D revisions, then its revision-date
>>> has to be bumped and a new entry added to the revision history. As it is
>>> now, the I-D-based modules are esentially revisionless.
>>>
>>>
>>
>> The revision rules only apply to published modules.
>> In IETF-speak, that means an RFC.  An Internet Draft
>> is a work-in-progress.  We update the revision date every time
>> the module changes, but the numerous incremental changes
>> for a work-in-progress should not be recorded in the module
>> revision history.  They should be recorded in the Change Log appendix.
>>
>> I will try to make this procedure more clear in the YANG guidelines draft.
>>
>>
>> The question is one of “published”.  So at the IETF that means an RFC
>> today, but Lada makes a good point in that in our new rapid development
>> environment we may never get to RFCs for most of the models being worked
>> on today - or not for some time. If we want those I-Ds to be used in
>> production, it might make sense to define an I-D as “published”.
>>
>> As I pointed out earlier, for other organizations, they have different
>> definitions of “published”, so we should consider a more flexible
>> definition of
>> “published” to encompass those.  Its probably not a big deal to just say
>> something like, “other organizations that define models will define their
>> own definition of stable/published, and in those cases, that will
>> suffice as the threshold for a version and following the updating
>> rules described herein."
>>
>
>
> I think we should just try to focus on our own standards development
> process.
> Other organizations can adopt or reject IETF practices if they want.
> We are using the same definition of published for about 25 years.
> It means RFC in our process.  In a vendor environment, it means modules
> released to customers.
>
> We don't have a rapid development environment in the IETF.
> If people want to implement half-baked YANG modules, that is their
> business.
> They should be commended if they actually provide implementation feedback
> into the RFC, but a work-in-progress is not a published module.
>
>
> That isn’t the point; the rest of the Yang universe looks to the IETF
> to standardize and manage the Yang lanague and also looks here
> for rules or best practices on building modules.
>


I don't really understand the confusion here.
Modules under development change constantly.
Almost all the changes are illegal for published modules.

Each SDO has a concept of unfinished work and finished work.
It should be easy to understand that the change rules apply
to finished work.





> —Tom
>
>
>

Andy


>
>
>
>> —Tom
>>
>
>
> Andy
>
>
>>
>>
>>
>>
>>
>>
>>> Lada
>>>
>>>
>> Andy
>>
>>
>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> ___
>>> 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] module update rules

[Nadeau Thomas]

> On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas  > wrote:
> 
>> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman > > wrote:
>> 
>> 
>> 
>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka > > wrote:
>> Hi,
>> 
>> if we want people to take YANG modules appearing in I-Ds seriously and 
>> implement them, then we should apply the revisioning rules to them. That is, 
>> if a module changes between two I-D revisions, then its revision-date has to 
>> be bumped and a new entry added to the revision history. As it is now, the 
>> I-D-based modules are esentially revisionless.
>> 
>> 
>> 
>> The revision rules only apply to published modules.
>> In IETF-speak, that means an RFC.  An Internet Draft
>> is a work-in-progress.  We update the revision date every time
>> the module changes, but the numerous incremental changes
>> for a work-in-progress should not be recorded in the module
>> revision history.  They should be recorded in the Change Log appendix.
>> 
>> I will try to make this procedure more clear in the YANG guidelines draft.
> 
>   The question is one of “published”.  So at the IETF that means an RFC
> today, but Lada makes a good point in that in our new rapid development
> environment we may never get to RFCs for most of the models being worked
> on today - or not for some time. If we want those I-Ds to be used in
> production, it might make sense to define an I-D as “published”.
> 
>   As I pointed out earlier, for other organizations, they have different
> definitions of “published”, so we should consider a more flexible definition 
> of
> “published” to encompass those.  Its probably not a big deal to just say
> something like, “other organizations that define models will define their
> own definition of stable/published, and in those cases, that will 
> suffice as the threshold for a version and following the updating
> rules described herein."
> 
> 
> I think we should just try to focus on our own standards development process.
> Other organizations can adopt or reject IETF practices if they want.
> We are using the same definition of published for about 25 years.
> It means RFC in our process.  In a vendor environment, it means modules
> released to customers.
> 
> We don't have a rapid development environment in the IETF.
> If people want to implement half-baked YANG modules, that is their business.
> They should be commended if they actually provide implementation feedback
> into the RFC, but a work-in-progress is not a published module.

That isn’t the point; the rest of the Yang universe looks to the IETF
to standardize and manage the Yang lanague and also looks here
for rules or best practices on building modules. 

—Tom


> 
> 
> 
>   —Tom
> 
> 
> Andy
>  
> 
> 
>> 
>> 
>>  
>> Lada
>> 
>> 
>> Andy
>> 
>>  
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> 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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen  wrote:

>
> Hi Robert,
>
> I agree that -01 doesn’t add much on top of -00.  This is expected as
> we’re in the fit and finish phase.  If you want to help finish the draft,
> then please consider responding to one of these threads:
>
>   http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re:
> rollback-on-error)
>   http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re:
> model-structure)
>
> As for this thread:
>
> 1. Regarding adding an explicit backwards-compatibility requirement,
> please note that what was written here is still in effect:
> http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note
> that no objections have been raised yet, so this will likely happen.
>
> 2. Regarding adding an applicability statement, there is currently only
> one voice asking for it, which isn’t enough to warrant a change.
>
>
I did not ask to add an AS to the charter.
I don't think the WG agrees enough on the problem to write such a document.




> Thanks,
> Kent
>

Andy


>
>
>
> On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" <
> netmod-boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>
> >Hi,
> >
> >On 17/12/2015 23:45, Randy Presuhn wrote:
> >> Hi -
> >>
> >>> From: Robert Wilton
> >>> Sent: Dec 17, 2015 1:12 PM
> >>> To: Andy Bierman
> >>> Cc: "netmod@ietf.org"
> >>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> >> ...
> >>>  Your requirement is a bit too strong for my liking.
> >>>
> >>>  To paraphrase your requirement text, it is forcing that all
> >>>  compliant NETCONF/RESTCONF servers MUST support any clients that
> do
> >>>  not want to differentiate between intended config and applied
> >>>  config.
> >> Do do otherwise sound to me like an interoperability disaster,
> >> and would encourage the "siloization" of toolsets.
> >>
> >>>  However, this requires all opstate aware servers:
> >>>
> >>>   - To handle a mix of clients, some of which are opstate aware,
> and
> >>>   some that are not.
> >> This seems perfectly reasonable.  To do otherwise torpedoes the very
> >> notion of interoperability.
> >>
> >>>   - To potentially handle a mix of requests, some of which are
> >>>   opstate aware requests, and some are not.
> >> Ditto.
> >>
> >>>  It also prevents:
> >>>
> >>>   - Having a server that is implemented to only support opstate
> aware
> >>>   clients.
> >> Avoiding the creation of such servers sounds like a *good* thing to me.
> >>
> >>>   - Having a server side configuration knob to control the
> behaviour
> >>>   (since it would affect the semantics for all clients).
> >> This also sounds like something which it would be desireable to prevent.
> >>
> >> I think I'm squarely with Andy on this one.
> >
> >Taking a step back ...
> >
> >I am probably way off the mark, but my perception is that some (perhaps
> >many) of the folks in the WG still perceive that the opstate
> >requirements are niche requirements for some unusual scenarios, and that
> >everyone else is happy with the status quo and don't want/need them.
> >
> >Alas, I don't share that view.  For me, the opstate requirements can be
> >summarized as saying that the operators just want to know what
> >configuration the device is actually running in a format that is
> >convenient for them to use.  This really doesn't appear to be
> >unreasonable request to me, and if I was writing to a network
> >manageability API then I would choose to use opstate because I perceive
> >that it is a more robust and easier to use API.  The counter arguments
> >appear to be that it is too hard for devices to provide this
> >information, and that the operators have historically managed without it.
> >
> >However, I think that several things have changed, and hence negate
> >these counter arguments: (i) the operators want to have much more
> >automation and management over their devices, (ii) they have found a way
> >to group together and have a more vocal voice about what they need and
> >want, (iii) the operators have realized that they don't need to wait for
> >the SDOs and can create defacto standard models on their own if they
> >have to.
> >
> >Personally, I would like us to stop spending time churning on the
> >requirements and actually get on to discussing the solutions.  To be
> >honest, there has been relatively little change in my understanding of
> >the requirements from reading draft-openconfig-netmod-opstate-01 back in
> >July, and I was expecting to discuss the solution drafts back in
> >September.  Here we are in December, and I'm not convinced that we have
> >truly made significant progress.
> >
> >The only reason that I submitted a solution draft to this problem was
> >because I thought it unlikely that OpenConfig would support a multiple
> >datastore solution, and I could see strong resistance amongst the IETF
> >engineers to the proposed OpenConfig 

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Kent Watsen]

Hi Robert,

I agree that -01 doesn’t add much on top of -00.  This is expected as we’re in 
the fit and finish phase.  If you want to help finish the draft, then please 
consider responding to one of these threads:

  http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re: 
rollback-on-error)
  http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re: 
model-structure)

As for this thread:

1. Regarding adding an explicit backwards-compatibility requirement, please 
note that what was written here is still in effect: 
http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note that 
no objections have been raised yet, so this will likely happen.

2. Regarding adding an applicability statement, there is currently only one 
voice asking for it, which isn’t enough to warrant a change.

Thanks,
Kent



On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" 
 wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware, and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>>   - Having a server side configuration knob to control the behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some (perhaps 
>many) of the folks in the WG still perceive that the opstate 
>requirements are niche requirements for some unusual scenarios, and that 
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements can be 
>summarized as saying that the operators just want to know what 
>configuration the device is actually running in a format that is 
>convenient for them to use.  This really doesn't appear to be 
>unreasonable request to me, and if I was writing to a network 
>manageability API then I would choose to use opstate because I perceive 
>that it is a more robust and easier to use API.  The counter arguments 
>appear to be that it is too hard for devices to provide this 
>information, and that the operators have historically managed without it.
>
>However, I think that several things have changed, and hence negate 
>these counter arguments: (i) the operators want to have much more 
>automation and management over their devices, (ii) they have found a way 
>to group together and have a more vocal voice about what they need and 
>want, (iii) the operators have realized that they don't need to wait for 
>the SDOs and can create defacto standard models on their own if they 
>have to.
>
>Personally, I would like us to stop spending time churning on the 
>requirements and actually get on to discussing the solutions.  To be 
>honest, there has been relatively little change in my understanding of 
>the requirements from reading draft-openconfig-netmod-opstate-01 back in 
>July, and I was expecting to discuss the solution drafts back in 
>September.  Here we are in December, and I'm not convinced that we have 
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was 
>because I thought it unlikely that OpenConfig would support a multiple 
>datastore solution, and I could see strong resistance amongst the IETF 
>engineers to the proposed OpenConfig solution.  I was hoping that my 
>proposed solution might be seen for the compromise that it is between 
>the two opposing positions.  But I care less on what the solution is, 
>and more whether we can agree on one and move forward.
>
>As someone that is quite new to SDO processes, my main concern is that 
>IETF (and other standards bodies) are moving too slowly here, and that 
>by the time that IETF have produced a sufficien

Re: [netmod] module update rules

[Andy Bierman]

On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas 
wrote:

>
> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman 
> wrote:
>
>
>
> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
>
>> Hi,
>>
>> if we want people to take YANG modules appearing in I-Ds seriously and
>> implement them, then we should apply the revisioning rules to them. That
>> is, if a module changes between two I-D revisions, then its revision-date
>> has to be bumped and a new entry added to the revision history. As it is
>> now, the I-D-based modules are esentially revisionless.
>>
>>
>
> The revision rules only apply to published modules.
> In IETF-speak, that means an RFC.  An Internet Draft
> is a work-in-progress.  We update the revision date every time
> the module changes, but the numerous incremental changes
> for a work-in-progress should not be recorded in the module
> revision history.  They should be recorded in the Change Log appendix.
>
> I will try to make this procedure more clear in the YANG guidelines draft.
>
>
> The question is one of “published”.  So at the IETF that means an RFC
> today, but Lada makes a good point in that in our new rapid development
> environment we may never get to RFCs for most of the models being worked
> on today - or not for some time. If we want those I-Ds to be used in
> production, it might make sense to define an I-D as “published”.
>
> As I pointed out earlier, for other organizations, they have different
> definitions of “published”, so we should consider a more flexible
> definition of
> “published” to encompass those.  Its probably not a big deal to just say
> something like, “other organizations that define models will define their
> own definition of stable/published, and in those cases, that will
> suffice as the threshold for a version and following the updating
> rules described herein."
>


I think we should just try to focus on our own standards development
process.
Other organizations can adopt or reject IETF practices if they want.
We are using the same definition of published for about 25 years.
It means RFC in our process.  In a vendor environment, it means modules
released to customers.

We don't have a rapid development environment in the IETF.
If people want to implement half-baked YANG modules, that is their business.
They should be commended if they actually provide implementation feedback
into the RFC, but a work-in-progress is not a published module.



> —Tom
>


Andy


>
>
>
>
>
>
>> Lada
>>
>>
> Andy
>
>
>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> ___
>> 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] module update rules

[Nadeau Thomas]

> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman  
> wrote:
> 
> 
> 
> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  > wrote:
> Hi,
> 
> if we want people to take YANG modules appearing in I-Ds seriously and 
> implement them, then we should apply the revisioning rules to them. That is, 
> if a module changes between two I-D revisions, then its revision-date has to 
> be bumped and a new entry added to the revision history. As it is now, the 
> I-D-based modules are esentially revisionless.
> 
> 
> 
> The revision rules only apply to published modules.
> In IETF-speak, that means an RFC.  An Internet Draft
> is a work-in-progress.  We update the revision date every time
> the module changes, but the numerous incremental changes
> for a work-in-progress should not be recorded in the module
> revision history.  They should be recorded in the Change Log appendix.
> 
> I will try to make this procedure more clear in the YANG guidelines draft.

The question is one of “published”.  So at the IETF that means an RFC
today, but Lada makes a good point in that in our new rapid development
environment we may never get to RFCs for most of the models being worked
on today - or not for some time. If we want those I-Ds to be used in
production, it might make sense to define an I-D as “published”.

As I pointed out earlier, for other organizations, they have different
definitions of “published”, so we should consider a more flexible definition of
“published” to encompass those.  Its probably not a big deal to just say
something like, “other organizations that define models will define their
own definition of stable/published, and in those cases, that will 
suffice as the threshold for a version and following the updating
rules described herein."

—Tom


> 
> 
>  
> Lada
> 
> 
> Andy
> 
>  
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] module update rules

[Andy Bierman]

On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps  wrote:

>
> Martin Bjorklund  writes:
>
> > Christian Hopps  wrote:
> >>
> >>
> >> Versioning has come up in previous conversations I've been a part of,
> >> and I was led to believe that it does not really exist for yang
> >> modules. That is, if you update a published module it's a completely new
> >> model with no-expectation of compatibility with previous models.
> >
> > Please see section 10 of RFC 6020.
>
> Ok, so I either misunderstood, or was misled. :)
>
> So my reading of section 10 is that a new revision is the "bump the
> minor" action, and a new module is required for "bump the major".
>
>

There are no major or minor revision numbers in YANG.
There are on revision date strings -MM-DD.



> Thanks,
> Chris.
>
>
Andy


>
> >
> >> Is it the case that there's no way to "bump the minor version" of a
> >> model (i.e., you make only additions, but no deletions or changes to
> >> meaning so that the model can be considered backward compatible)?
> >
> > All rules in section 10 of RFC 6020 are backwards compatible.
> >
> > Also note that you can deprecate and obsolete nodes and define new
> > nodes in the same module.
> >
> >
> >
> > /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] module update rules

[Nadeau Thomas]

It would help to define this outside of the IETF context.
As we are all well aware, there are many organizations outside
of the IETF such as ODL, OpenConfig, IEEE, MEF, etc… that are now creating 
modules.

—Tom



> On Dec 18, 2015:1:42 PM, at 1:42 PM, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
>>> Hi,
>>> 
>>> if we want people to take YANG modules appearing in I-Ds seriously and 
>>> implement them, then we should apply the revisioning rules to them. That 
>>> is, if a module changes between two I-D revisions, then its revision-date 
>>> has to be bumped and a new entry added to the revision history. As it is 
>>> now, the I-D-based modules are esentially revisionless.
>>> 
>>> 
>>> 
>>> The revision rules only apply to published modules.
>> 
>> Update rules of sec. 10 offer no such excuse.
> 
> It says:
> 
>  For any published change, ...
> 
> 
> I agree w/ Andy that 6087bis could clarify what this means in terms of
> IETF.
> 
> 
> /martin
> 
> 
>>> In IETF-speak, that means an RFC.  An Internet Draft
>>> is a work-in-progress.  We update the revision date every time
>>> the module changes, but the numerous incremental changes
>>> for a work-in-progress should not be recorded in the module
>>> revision history.  They should be recorded in the Change Log appendix.
>> 
>> Revision numbers are critical for interoperability. If we want
>> vendors to implement modules such as ietf-routing now, the
>> revisions must be solid and reliable.
>> 
>>> 
>>> I will try to make this procedure more clear in the YANG guidelines draft.
>> 
>> I think it should be the other way around: YANG spec should not
>> contain the update rules (because we all ignore them for I-D-based
>> modules, right?), but the IETF guidelines should specify the
>> policy you describe. 
>> 
>> Lada
>> 
>>> 
>>> 
>>> 
>>> Lada
>>> 
>>> 
>>> Andy
>>> 
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> 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] module update rules

[Christian Hopps]

Martin Bjorklund  writes:

> Christian Hopps  wrote:
>> 
>> 
>> Versioning has come up in previous conversations I've been a part of,
>> and I was led to believe that it does not really exist for yang
>> modules. That is, if you update a published module it's a completely new
>> model with no-expectation of compatibility with previous models.
>
> Please see section 10 of RFC 6020.

Ok, so I either misunderstood, or was misled. :)

So my reading of section 10 is that a new revision is the "bump the
minor" action, and a new module is required for "bump the major".

Thanks,
Chris.


>
>> Is it the case that there's no way to "bump the minor version" of a
>> model (i.e., you make only additions, but no deletions or changes to
>> meaning so that the model can be considered backward compatible)?
>
> All rules in section 10 of RFC 6020 are backwards compatible.
>
> Also note that you can deprecate and obsolete nodes and define new
> nodes in the same module.
>
>
>
> /martin



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] module update rules

[Martin Bjorklund]

Christian Hopps  wrote:
> 
> 
> Versioning has come up in previous conversations I've been a part of,
> and I was led to believe that it does not really exist for yang
> modules. That is, if you update a published module it's a completely new
> model with no-expectation of compatibility with previous models.

Please see section 10 of RFC 6020.

> Is it the case that there's no way to "bump the minor version" of a
> model (i.e., you make only additions, but no deletions or changes to
> meaning so that the model can be considered backward compatible)?

All rules in section 10 of RFC 6020 are backwards compatible.

Also note that you can deprecate and obsolete nodes and define new
nodes in the same module.



/martin

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

Re: [netmod] module update rules

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
> > Hi,
> > 
> > if we want people to take YANG modules appearing in I-Ds seriously and 
> > implement them, then we should apply the revisioning rules to them. That 
> > is, if a module changes between two I-D revisions, then its revision-date 
> > has to be bumped and a new entry added to the revision history. As it is 
> > now, the I-D-based modules are esentially revisionless.
> > 
> > 
> > 
> > The revision rules only apply to published modules.
> 
> Update rules of sec. 10 offer no such excuse.

It says:

  For any published change, ...


I agree w/ Andy that 6087bis could clarify what this means in terms of
IETF.


/martin


> > In IETF-speak, that means an RFC.  An Internet Draft
> > is a work-in-progress.  We update the revision date every time
> > the module changes, but the numerous incremental changes
> > for a work-in-progress should not be recorded in the module
> > revision history.  They should be recorded in the Change Log appendix.
> 
> Revision numbers are critical for interoperability. If we want
> vendors to implement modules such as ietf-routing now, the
> revisions must be solid and reliable.
> 
> > 
> > I will try to make this procedure more clear in the YANG guidelines draft.
> 
> I think it should be the other way around: YANG spec should not
> contain the update rules (because we all ignore them for I-D-based
> modules, right?), but the IETF guidelines should specify the
> policy you describe. 
> 
> Lada
> 
> > 
> > 
> >  
> > Lada
> > 
> > 
> > Andy
> > 
> >  
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> > 
> > 
> > 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] module update rules

[Andy Bierman]

On Fri, Dec 18, 2015 at 8:32 AM, Ladislav Lhotka  wrote:

>
> > On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
> >
> >
> >
> > On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
> > Hi,
> >
> > if we want people to take YANG modules appearing in I-Ds seriously and
> implement them, then we should apply the revisioning rules to them. That
> is, if a module changes between two I-D revisions, then its revision-date
> has to be bumped and a new entry added to the revision history. As it is
> now, the I-D-based modules are esentially revisionless.
> >
> >
> >
> > The revision rules only apply to published modules.
>
> Update rules of sec. 10 offer no such excuse.
>


That is a flaw in the draft



>
> > In IETF-speak, that means an RFC.  An Internet Draft
> > is a work-in-progress.  We update the revision date every time
> > the module changes, but the numerous incremental changes
> > for a work-in-progress should not be recorded in the module
> > revision history.  They should be recorded in the Change Log appendix.
>
> Revision numbers are critical for interoperability. If we want vendors to
> implement modules such as ietf-routing now, the revisions must be solid and
> reliable.
>


Vendors implement work-in-progress at their own risk.
IMO we should do a better job publishing RFCs on time,
and implement RFCs.



>
> >
> > I will try to make this procedure more clear in the YANG guidelines
> draft.
>
> I think it should be the other way around: YANG spec should not contain
> the update rules (because we all ignore them for I-D-based modules,
> right?), but the IETF guidelines should specify the policy you describe.
>
>
This is a closed issue in YANG 1.1



> Lada
>
>

Andy



> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] module update rules

[Christian Hopps]

Versioning has come up in previous conversations I've been a part of,
and I was led to believe that it does not really exist for yang
modules. That is, if you update a published module it's a completely new
model with no-expectation of compatibility with previous models.

Is it the case that there's no way to "bump the minor version" of a
model (i.e., you make only additions, but no deletions or changes to
meaning so that the model can be considered backward compatible)?

Thanks,
Chris.


Ladislav Lhotka  writes:

> Hi,
>
> if we want people to take YANG modules appearing in I-Ds seriously and 
> implement them, then we should apply the revisioning rules to them. That is, 
> if a module changes between two I-D revisions, then its revision-date has to 
> be bumped and a new entry added to the revision history. As it is now, the 
> I-D-based modules are esentially revisionless.
>
> Lada



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] module update rules

[Ladislav Lhotka]

> On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
> Hi,
> 
> if we want people to take YANG modules appearing in I-Ds seriously and 
> implement them, then we should apply the revisioning rules to them. That is, 
> if a module changes between two I-D revisions, then its revision-date has to 
> be bumped and a new entry added to the revision history. As it is now, the 
> I-D-based modules are esentially revisionless.
> 
> 
> 
> The revision rules only apply to published modules.

Update rules of sec. 10 offer no such excuse.

> In IETF-speak, that means an RFC.  An Internet Draft
> is a work-in-progress.  We update the revision date every time
> the module changes, but the numerous incremental changes
> for a work-in-progress should not be recorded in the module
> revision history.  They should be recorded in the Change Log appendix.

Revision numbers are critical for interoperability. If we want vendors to 
implement modules such as ietf-routing now, the revisions must be solid and 
reliable.

> 
> I will try to make this procedure more clear in the YANG guidelines draft.

I think it should be the other way around: YANG spec should not contain the 
update rules (because we all ignore them for I-D-based modules, right?), but 
the IETF guidelines should specify the policy you describe.

Lada

> 
> 
>  
> Lada
> 
> 
> Andy
> 
>  
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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




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

Re: [netmod] module update rules

[Andy Bierman]

On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:

> Hi,
>
> if we want people to take YANG modules appearing in I-Ds seriously and
> implement them, then we should apply the revisioning rules to them. That
> is, if a module changes between two I-D revisions, then its revision-date
> has to be bumped and a new entry added to the revision history. As it is
> now, the I-D-based modules are esentially revisionless.
>
>

The revision rules only apply to published modules.
In IETF-speak, that means an RFC.  An Internet Draft
is a work-in-progress.  We update the revision date every time
the module changes, but the numerous incremental changes
for a work-in-progress should not be recorded in the module
revision history.  They should be recorded in the Change Log appendix.

I will try to make this procedure more clear in the YANG guidelines draft.




> Lada
>
>
Andy



> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> ___
> 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] module update rules

[Ladislav Lhotka]

Hi,

if we want people to take YANG modules appearing in I-Ds seriously and 
implement them, then we should apply the revisioning rules to them. That is, if 
a module changes between two I-D revisions, then its revision-date has to be 
bumped and a new entry added to the revision history. As it is now, the 
I-D-based modules are esentially revisionless.

Lada

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




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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Fri, Dec 18, 2015 at 04:16:04PM +0100, Ladislav Lhotka wrote:
> 
> > On 18 Dec 2015, at 15:49, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
> >> 
> >> Is it not? I would say it severely restricts the workflow for the data 
> >> model development. The ultra-conservative update rules essentially permit 
> >> only incremental changes to published modules. This would be fine if the 
> >> data model landscape already was reasonably stable. We are not that far 
> >> though, and everything is in flux. So I believe we would be much better 
> >> off with "release early - release often" strategy, which is made 
> >> impossible by the existing update rules.
> >> 
> > 
> > There is a "release early - release often cycle" in the IETF process -
> > it is called the Internet Drafts stage. Unfortunately, often people
> > wait for things to stabilize (becoming an RFC) before implementing. I
> 
> There are other disadvantages to I-Ds, for example that they have to be 
> updated every six months. It is actually funny: RFC used to mean "request for 
> comments", then later I-D acquired this role, so now we probably need a 
> "drafty draft" category.
> 
> > assume we would have fewer but more solid data models if they would
> > all come along with running code behind them (and ideally > 1
> > independent implementations). The problem might be "us" and not the
> > update rules.
> 
> The update rules mean that it is risky to publish a data model in an RFC. And 
> indeed, if there is a need, for one reason or another, to restructure, for 
> example, ietf-interfaces, it will have to become a new module 
> (ietf-interfaces-dash?) and the revision history will be broken. Doing this 
> more than once would turn the data model ecosystem into a mess.

No, it does not.
 
> Backward compatibility is nice, but making it an absolute requirement, which 
> is even ingrained in the data modelling language specification, is IMO absurd.
>

I can grab interface statistics from pretty much all devices on my
network using a single data model and SNMP. This is a feature, not a
bug. You may find this not worth the effort or you might even find
this absurd in todays world. I do not have to share this view.

Can we stop here and get back to the I-D discussed in this thread? If
you want to complain about absurd YANG update rules, please do so
using a separate thread.

/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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Acee Lindem (acee)]

Hi Rob, 
Thanks for authoring the comprehensive response. I’m in complete agreement
and support publication of the document.
Thanks,
Acee 

On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>> ...
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that
>>>do
>>>  not want to differentiate between intended config and applied
>>>  config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware,
>>>and
>>>   some that are not.
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>> Ditto.
>>
>>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate
>>>aware
>>>   clients.
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>>   - Having a server side configuration knob to control the
>>>behaviour
>>>   (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some (perhaps
>many) of the folks in the WG still perceive that the opstate
>requirements are niche requirements for some unusual scenarios, and that
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view.  For me, the opstate requirements can be
>summarized as saying that the operators just want to know what
>configuration the device is actually running in a format that is
>convenient for them to use.  This really doesn't appear to be
>unreasonable request to me, and if I was writing to a network
>manageability API then I would choose to use opstate because I perceive
>that it is a more robust and easier to use API.  The counter arguments
>appear to be that it is too hard for devices to provide this
>information, and that the operators have historically managed without it.
>
>However, I think that several things have changed, and hence negate
>these counter arguments: (i) the operators want to have much more
>automation and management over their devices, (ii) they have found a way
>to group together and have a more vocal voice about what they need and
>want, (iii) the operators have realized that they don't need to wait for
>the SDOs and can create defacto standard models on their own if they
>have to.
>
>Personally, I would like us to stop spending time churning on the
>requirements and actually get on to discussing the solutions.  To be
>honest, there has been relatively little change in my understanding of
>the requirements from reading draft-openconfig-netmod-opstate-01 back in
>July, and I was expecting to discuss the solution drafts back in
>September.  Here we are in December, and I'm not convinced that we have
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was
>because I thought it unlikely that OpenConfig would support a multiple
>datastore solution, and I could see strong resistance amongst the IETF
>engineers to the proposed OpenConfig solution.  I was hoping that my
>proposed solution might be seen for the compromise that it is between
>the two opposing positions.  But I care less on what the solution is,
>and more whether we can agree on one and move forward.
>
>As someone that is quite new to SDO processes, my main concern is that
>IETF (and other standards bodies) are moving too slowly here, and that
>by the time that IETF have produced a sufficiently complete set of YANG
>models to manage network devices it will be too late because the
>industry will already have converged on the OpenConfig models, which
>although not perfect, are close to being usable now, and are being
>evolved at a much quicker pace ...
>
>So my hope for the early new year is that we can reach common ground
>with OpenConfig and converge on a single set of YANG modules for
>managing network devices, and that includes having a solution to the
>Opstate problem.
>
>Finally, if my acquiescing to Andy's requirement is helpful to move this
>process forward then that is fine with me.  As I have previously
>indicated, I don't really think that it helps with framing or

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 18 Dec 2015, at 15:49, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
>> 
>> Is it not? I would say it severely restricts the workflow for the data model 
>> development. The ultra-conservative update rules essentially permit only 
>> incremental changes to published modules. This would be fine if the data 
>> model landscape already was reasonably stable. We are not that far though, 
>> and everything is in flux. So I believe we would be much better off with 
>> "release early - release often" strategy, which is made impossible by the 
>> existing update rules.
>> 
> 
> There is a "release early - release often cycle" in the IETF process -
> it is called the Internet Drafts stage. Unfortunately, often people
> wait for things to stabilize (becoming an RFC) before implementing. I

There are other disadvantages to I-Ds, for example that they have to be updated 
every six months. It is actually funny: RFC used to mean "request for 
comments", then later I-D acquired this role, so now we probably need a "drafty 
draft" category.

> assume we would have fewer but more solid data models if they would
> all come along with running code behind them (and ideally > 1
> independent implementations). The problem might be "us" and not the
> update rules.

The update rules mean that it is risky to publish a data model in an RFC. And 
indeed, if there is a need, for one reason or another, to restructure, for 
example, ietf-interfaces, it will have to become a new module 
(ietf-interfaces-dash?) and the revision history will be broken. Doing this 
more than once would turn the data model ecosystem into a mess.

Backward compatibility is nice, but making it an absolute requirement, which is 
even ingrained in the data modelling language specification, is IMO absurd.

Lada

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

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




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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
> 
> Is it not? I would say it severely restricts the workflow for the data model 
> development. The ultra-conservative update rules essentially permit only 
> incremental changes to published modules. This would be fine if the data 
> model landscape already was reasonably stable. We are not that far though, 
> and everything is in flux. So I believe we would be much better off with 
> "release early - release often" strategy, which is made impossible by the 
> existing update rules.
>

There is a "release early - release often cycle" in the IETF process -
it is called the Internet Drafts stage. Unfortunately, often people
wait for things to stabilize (becoming an RFC) before implementing. I
assume we would have fewer but more solid data models if they would
all come along with running code behind them (and ideally > 1
independent implementations). The problem might be "us" and not the
update rules.

/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] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> The minutes for IETF 95 show that there was in-room support for
> adopting draft-wilton-netmod-intf-ext-yang as a WG draft.  The minutes
> also show that this decision would be confirmed on the mailing list,
> which I am doing now.
> 
> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item
> and correspondingly add this to the WG charter as a milestone?  Please
> comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG
> Chairs will gauge whether or not there is consensus to move forward
> with the document.

I support the adoption of this draft and I will review and discuss it.


/martin

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

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Ladislav Lhotka]

> On 18 Dec 2015, at 15:08, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton  wrote:
> Hi,
> 
> On 17/12/2015 23:45, Randy Presuhn wrote:
> Hi -
> 
> From: Robert Wilton
> Sent: Dec 17, 2015 1:12 PM
> To: Andy Bierman
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> ...
>  Your requirement is a bit too strong for my liking.
> 
>  To paraphrase your requirement text, it is forcing that all
>  compliant NETCONF/RESTCONF servers MUST support any clients that do
>  not want to differentiate between intended config and applied
>  config.
> Do do otherwise sound to me like an interoperability disaster,
> and would encourage the "siloization" of toolsets.
> 
>  However, this requires all opstate aware servers:
> 
>   - To handle a mix of clients, some of which are opstate aware, and
>   some that are not.
> This seems perfectly reasonable.  To do otherwise torpedoes the very
> notion of interoperability.
> 
>   - To potentially handle a mix of requests, some of which are
>   opstate aware requests, and some are not.
> Ditto.
> 
>  It also prevents:
> 
>   - Having a server that is implemented to only support opstate aware
>   clients.
> Avoiding the creation of such servers sounds like a *good* thing to me.
> 
>   - Having a server side configuration knob to control the behaviour
>   (since it would affect the semantics for all clients).
> This also sounds like something which it would be desireable to prevent.
> 
> I think I'm squarely with Andy on this one.
> 
> Taking a step back ...
> 
> I am probably way off the mark, but my perception is that some (perhaps many) 
> of the folks in the WG still perceive that the opstate requirements are niche 
> requirements for some unusual scenarios, and that everyone else is happy with 
> the status quo and don't want/need them.
> 
> Alas, I don't share that view.  For me, the opstate requirements can be 
> summarized as saying that the operators just want to know what configuration 
> the device is actually running in a format that is convenient for them to 
> use.  This really doesn't appear to be unreasonable request to me, and if I 
> was writing to a network manageability API then I would choose to use opstate 
> because I perceive that it is a more robust and easier to use API.  The 
> counter arguments appear to be that it is too hard for devices to provide 
> this information, and that the operators have historically managed without it.
> 
> However, I think that several things have changed, and hence negate these 
> counter arguments: (i) the operators want to have much more automation and 
> management over their devices, (ii) they have found a way to group together 
> and have a more vocal voice about what they need and want, (iii) the 
> operators have realized that they don't need to wait for the SDOs and can 
> create defacto standard models on their own if they have to.
> 
> Personally, I would like us to stop spending time churning on the 
> requirements and actually get on to discussing the solutions.  To be honest, 
> there has been relatively little change in my understanding of the 
> requirements from reading draft-openconfig-netmod-opstate-01 back in July, 
> and I was expecting to discuss the solution drafts back in September.  Here 
> we are in December, and I'm not convinced that we have truly made significant 
> progress.
> 
> The only reason that I submitted a solution draft to this problem was because 
> I thought it unlikely that OpenConfig would support a multiple datastore 
> solution, and I could see strong resistance amongst the IETF engineers to the 
> proposed OpenConfig solution.  I was hoping that my proposed solution might 
> be seen for the compromise that it is between the two opposing positions.  
> But I care less on what the solution is, and more whether we can agree on one 
> and move forward.
> 
> As someone that is quite new to SDO processes, my main concern is that IETF 
> (and other standards bodies) are moving too slowly here, and that by the time 
> that IETF have produced a sufficiently complete set of YANG models to manage 
> network devices it will be too late because the industry will already have 
> converged on the OpenConfig models, which although not perfect, are close to 
> being usable now, and are being evolved at a much quicker pace ...
> 
> So my hope for the early new year is that we can reach common ground with 
> OpenConfig and converge on a single set of YANG modules for managing network 
> devices, and that includes having a solution to the Opstate problem.
> 
> Finally, if my acquiescing to Andy's requirement is helpful to move this 
> process forward then that is fine with me.  As I have previously indicated, I 
> don't really think that it helps with framing or discussing the solutions, 
> but equally I can live with it since I suspect that the solutions are likely

Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Andy Bierman]

On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton  wrote:

> Hi,
>
> On 17/12/2015 23:45, Randy Presuhn wrote:
>
>> Hi -
>>
>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>>
>> ...
>>
>>>  Your requirement is a bit too strong for my liking.
>>>
>>>  To paraphrase your requirement text, it is forcing that all
>>>  compliant NETCONF/RESTCONF servers MUST support any clients that do
>>>  not want to differentiate between intended config and applied
>>>  config.
>>>
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>  However, this requires all opstate aware servers:
>>>
>>>   - To handle a mix of clients, some of which are opstate aware, and
>>>   some that are not.
>>>
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>   - To potentially handle a mix of requests, some of which are
>>>   opstate aware requests, and some are not.
>>>
>> Ditto.
>>
>>  It also prevents:
>>>
>>>   - Having a server that is implemented to only support opstate aware
>>>   clients.
>>>
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>   - Having a server side configuration knob to control the behaviour
>>>   (since it would affect the semantics for all clients).
>>>
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>>
>
> Taking a step back ...
>
> I am probably way off the mark, but my perception is that some (perhaps
> many) of the folks in the WG still perceive that the opstate requirements
> are niche requirements for some unusual scenarios, and that everyone else
> is happy with the status quo and don't want/need them.
>
> Alas, I don't share that view.  For me, the opstate requirements can be
> summarized as saying that the operators just want to know what
> configuration the device is actually running in a format that is convenient
> for them to use.  This really doesn't appear to be unreasonable request to
> me, and if I was writing to a network manageability API then I would choose
> to use opstate because I perceive that it is a more robust and easier to
> use API.  The counter arguments appear to be that it is too hard for
> devices to provide this information, and that the operators have
> historically managed without it.
>
> However, I think that several things have changed, and hence negate these
> counter arguments: (i) the operators want to have much more automation and
> management over their devices, (ii) they have found a way to group together
> and have a more vocal voice about what they need and want, (iii) the
> operators have realized that they don't need to wait for the SDOs and can
> create defacto standard models on their own if they have to.
>
> Personally, I would like us to stop spending time churning on the
> requirements and actually get on to discussing the solutions.  To be
> honest, there has been relatively little change in my understanding of the
> requirements from reading draft-openconfig-netmod-opstate-01 back in July,
> and I was expecting to discuss the solution drafts back in September.  Here
> we are in December, and I'm not convinced that we have truly made
> significant progress.
>
> The only reason that I submitted a solution draft to this problem was
> because I thought it unlikely that OpenConfig would support a multiple
> datastore solution, and I could see strong resistance amongst the IETF
> engineers to the proposed OpenConfig solution.  I was hoping that my
> proposed solution might be seen for the compromise that it is between the
> two opposing positions.  But I care less on what the solution is, and more
> whether we can agree on one and move forward.
>
> As someone that is quite new to SDO processes, my main concern is that
> IETF (and other standards bodies) are moving too slowly here, and that by
> the time that IETF have produced a sufficiently complete set of YANG models
> to manage network devices it will be too late because the industry will
> already have converged on the OpenConfig models, which although not
> perfect, are close to being usable now, and are being evolved at a much
> quicker pace ...
>
> So my hope for the early new year is that we can reach common ground with
> OpenConfig and converge on a single set of YANG modules for managing
> network devices, and that includes having a solution to the Opstate problem.
>
> Finally, if my acquiescing to Andy's requirement is helpful to move this
> process forward then that is fine with me.  As I have previously indicated,
> I don't really think that it helps with framing or discussing the
> solutions, but equally I can live with it since I suspect that the
> solutions are likely to comply with it an

[netmod] structural mount versus YSDL

[Ladislav Lhotka]

Hi,

we now have two drafts with pull-style mechanism of combining data
models:

- draft-bjorklund-netmod-structural-mount-00
- draft-lhotka-netmod-ysdl-00

In many aspects they are quite similar, yet there are also substantial
differences that deserve to be discussed. In believe the underlying
problem is really pressing, and we should probably try to merge both
approaches and come up with a single solution asap.

In my view, the main differences are the following:

1. Structural mount uses a YANG extension while YSDL doesn't require any
   changes in YANG.

2. Structural mount allows for attaching sub-models only to places
   identified with "mount-point" extension, in YSDL all container,
   list, case and anydata nodes are eligible as "mount points".

3. Structural mount provides the meta-schema as regular state data, YSDL
   assumes they will be available to clients as a separate resource, or
   perhaps as an (optional) part of yang-library.

4. Structural mount puts yang-library data into the meta-schema while
   YSDL just uses references to the "standard" yang-library.

5. Structural mount allows different entries of the same list to contain
   different mounted data models (via instances of yang-library), in
   YSDL this can be achieved indirectly by defining a choice in the
   "super-schema" and assigning different schemas to its cases.

6. If the same set of modules is to be mounted in several locations,
   then in structural mount the same yang-library information has to be
   copied to all locations. YSDL offers the "schema" construct as kind
   of "grouping of modules" that can be referred to from different
   locations.

Lada

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

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

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Eliot Lear]

I should point out that there's some related IPR in this space that
Cisco has.  Depending on how this gets resolved, we'll file appropriately.

On 12/17/15 3:44 PM, Eliot Lear wrote:
>
> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>  Do you mean an ASCII DNS name (versus an IP address w a mask)?
> I was thinking of "host" in RFC 6021.
>
> Eliot
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Einar Nilsen-Nygaard (einarnn)]

I have been involved in some discussions within Cisco relating to our 
contributions to this draft, and I can say that we did not spend much time 
discussing such an addition within Cisco. I am not sure what discussions the 
ACL model design team may have had as a group.

However, I think the addition of hostname-based matching would be a great one, 
but I think that, if added, it should be made optional via a feature due to the 
potential complexities of implementation. It would be great to see if we can 
get this added.

Cheers,

Einar

> On Dec 17, 2015, at 3:53 PM, Nadeau Thomas  wrote:
> 
> 
>   You raise a good point. Do the contributors/editors have any thoughts on
> this suggestion?
> 
>   —Tom
> 
> 
>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  wrote:
>> 
>> 
>> 
>> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>> Do you mean an ASCII DNS name (versus an IP address w a mask)?
>> 
>> I was thinking of "host" in RFC 6021.
>> 
>> Eliot
>> 
>> 
> 
> ___
> 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] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

[Robert Wilton]

Hi,

On 17/12/2015 23:45, Randy Presuhn wrote:

Hi -


From: Robert Wilton
Sent: Dec 17, 2015 1:12 PM
To: Andy Bierman
Cc: "netmod@ietf.org"
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

...

 Your requirement is a bit too strong for my liking.

 To paraphrase your requirement text, it is forcing that all
 compliant NETCONF/RESTCONF servers MUST support any clients that do
 not want to differentiate between intended config and applied
 config.

Do do otherwise sound to me like an interoperability disaster,
and would encourage the "siloization" of toolsets.


 However, this requires all opstate aware servers:

  - To handle a mix of clients, some of which are opstate aware, and
  some that are not.

This seems perfectly reasonable.  To do otherwise torpedoes the very
notion of interoperability.


  - To potentially handle a mix of requests, some of which are
  opstate aware requests, and some are not.

Ditto.


 It also prevents:

  - Having a server that is implemented to only support opstate aware
  clients.

Avoiding the creation of such servers sounds like a *good* thing to me.


  - Having a server side configuration knob to control the behaviour
  (since it would affect the semantics for all clients).

This also sounds like something which it would be desireable to prevent.

I think I'm squarely with Andy on this one.


Taking a step back ...

I am probably way off the mark, but my perception is that some (perhaps 
many) of the folks in the WG still perceive that the opstate 
requirements are niche requirements for some unusual scenarios, and that 
everyone else is happy with the status quo and don't want/need them.


Alas, I don't share that view.  For me, the opstate requirements can be 
summarized as saying that the operators just want to know what 
configuration the device is actually running in a format that is 
convenient for them to use.  This really doesn't appear to be 
unreasonable request to me, and if I was writing to a network 
manageability API then I would choose to use opstate because I perceive 
that it is a more robust and easier to use API.  The counter arguments 
appear to be that it is too hard for devices to provide this 
information, and that the operators have historically managed without it.


However, I think that several things have changed, and hence negate 
these counter arguments: (i) the operators want to have much more 
automation and management over their devices, (ii) they have found a way 
to group together and have a more vocal voice about what they need and 
want, (iii) the operators have realized that they don't need to wait for 
the SDOs and can create defacto standard models on their own if they 
have to.


Personally, I would like us to stop spending time churning on the 
requirements and actually get on to discussing the solutions.  To be 
honest, there has been relatively little change in my understanding of 
the requirements from reading draft-openconfig-netmod-opstate-01 back in 
July, and I was expecting to discuss the solution drafts back in 
September.  Here we are in December, and I'm not convinced that we have 
truly made significant progress.


The only reason that I submitted a solution draft to this problem was 
because I thought it unlikely that OpenConfig would support a multiple 
datastore solution, and I could see strong resistance amongst the IETF 
engineers to the proposed OpenConfig solution.  I was hoping that my 
proposed solution might be seen for the compromise that it is between 
the two opposing positions.  But I care less on what the solution is, 
and more whether we can agree on one and move forward.


As someone that is quite new to SDO processes, my main concern is that 
IETF (and other standards bodies) are moving too slowly here, and that 
by the time that IETF have produced a sufficiently complete set of YANG 
models to manage network devices it will be too late because the 
industry will already have converged on the OpenConfig models, which 
although not perfect, are close to being usable now, and are being 
evolved at a much quicker pace ...


So my hope for the early new year is that we can reach common ground 
with OpenConfig and converge on a single set of YANG modules for 
managing network devices, and that includes having a solution to the 
Opstate problem.


Finally, if my acquiescing to Andy's requirement is helpful to move this 
process forward then that is fine with me.  As I have previously 
indicated, I don't really think that it helps with framing or discussing 
the solutions, but equally I can live with it since I suspect that the 
solutions are likely to comply with it anyway.


Apologies for the long email, and given I may not be actively reading 
the WG emails over the next couple of weeks, I'll wish you all happy 
holidays!


Thanks,
Rob



Randy

___
netmod mailing list
netmod@ietf

[netmod] Fw: New Version Notification for draft-bjorklund-netmod-structural-mount-00.txt

[Martin Bjorklund]

Hi,

This draft proposes a mechanism for mounting YANG models in other
models.  It focuses on the *schema* only, not on the underlying
mechanism to implement the data (like "peer mount").


/martin
--- Begin Message ---

A new version of I-D, draft-bjorklund-netmod-structural-mount-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Name:   draft-bjorklund-netmod-structural-mount
Revision:   00
Title:  YANG Structural Mount
Document date:  2015-12-18
Group:  Individual Submission
Pages:  12
URL:
https://www.ietf.org/internet-drafts/draft-bjorklund-netmod-structural-mount-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bjorklund-netmod-structural-mount/
Htmlized:   
https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-00


Abstract:
   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.


  


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

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

Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01

[Juergen Schoenwaelder]

On Thu, Dec 17, 2015 at 09:27:12PM +, Kent Watsen wrote:
> [As a contributor]
> 
> Thank you for the review Juergen.
> 
> Great suggestions.  If no one objects, I’ll incorporate them into the next 
> revision of the document after last call.
> 
> My one comment is that I don’t believe the document is limited to the 
> introduction of applied configuration. For instance, the relating of config 
> to derived state and also the model structure requirement are not related to 
> applied config.  In all fairness, Requirement #5 (model structure) isn’t even 
> about operational state.

Reading #5 again I must admit that I do not really understand what
this requirement tries to accomplish:

   5.  Ability for distinct modules to leverage a common model-structure

   A.  Focus on the IETF-defined modules, and ideally provides
   guidance to other SDOs

   B.  Multiple domain-specific model-structure trees are okay

   C.  Model-structures may be defined in multiple modules with
   distinct namespaces

At this level of abstraction, #5 really does not mean anything or N
people will have at least N different interpretations of it. I
actually think this should be taken out and moved into a different
document and then it requires to be developed into something much more
concrete.

/js

> So your title and abstract suggestions might define too narrow a scope.  So 
> how about:
> 
> Title: Terminology and Requirements for Operational State and Model Structure
>
> Abstract:
>  This document defines requirements for enhancing the support
>  of operational state through the introduction of a conceptual
>  "applied configuration".  The document also defines requirements
>  enabling distinct modules to leverage a common model structure.
> 
> …and add an Introduction section that expands on this theme further?

I think this is getting into the wrong direction and as explained
above #5 is by far underspecified to be of any value. I suggest to
take it out so that we can publish the rest in a timely manner. The
alternative is to hold off this document in an attempt to replace #5
with something that is concrete and actionable.

/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