Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04

[Lou Berger]

Hi John,

    Thank you (and Janos, the group) for the agenda time and the 
message.  There was also a request for a single c-type vlan example.  I 
see that there is already one on page 22 as part of the match container.


See below for inline responses.

Rob/WG,
    The plan is to address the comments raised in this mail, update the 
draft and then go to LC.  Please note that the document status should be 
changed Informational to Standards Track.


On 11/13/2018 11:55 AM, John Messenger wrote:

Hi,

At the 802.1 TSN meeting this morning, Lou Berger made a presentation on behalf 
of Rob Wilton summarising the recent changes in this draft.  I like the changes 
to the structure which are intended to align the VLAN tag structure to that 
specified in 802.1Q.  I notice that the draft retains clause 2.2 
(Extensibility) but I think that's a bug, because it's not reflected in the 
model (which is a fixed structure of one or two tags).

I agree.

Right now, it says that the Ethertypes are taken from dot1q-tag-type.  Would 
this allow tags other than 802.1QTagType (81-00) and 802.1QSTagType (88-A8)?  
That shouldn't be allowed.
I read this as just trying to use the IEEE defined types.  We certainly 
can restrict this to just c-vlan and s-vlan values, but perhaps you want 
to consider defining an enumeration for this case (valid-qtag-types).


Rob (wg)

    Do you see any issue with restricting tag-types to 
dot1q-types:c-vlan and dot1q-types:s-vlan?



My preference would be to remove the forward-looking statement quoted here 
because it implies a willingness to extend to 3 tags:
The structure of the model is currently limited to matching or
rewriting a maximum of two 802.1Q tags in the frame header but has
been designed to be easily extensible to matching/rewriting three or
more VLAN tags in future, if required.


sure. (at least from my perspective.)


It looks like you could parse an untagged frame as either :(untagged) or 
:(dot1q-vlan-tagged) (without either of the optional tags).  Is that a bug?


I may be missing something, but I think you're right - i,e., why would 
dot1q-vlan-tagged be present without an outer-tag, but I may be missing 
something...


Thanks again.

Lou


Thanks,
-- John

-Original Message-
From: List HELP only  On Behalf Of Robert Wilton
Sent: 05 November 2018 16:16
To: stds-802-...@listserv.ieee.org
Subject: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - 
draft-ietf-netmod-sub-intf-vlan-model-04

Ballot due Nov. 6: P802.1Qcx/D0.4
For particulars see
   https://1.ieee802.org/active-ballots/
802.1 list help: https://1.ieee802.org/email-lists/
List archives (access-controlled) by date:
www.ieee802.org/1/private/email2/mail1.html
-

Dear esteemed 802.1 WG members,

A few years back, at the start of my IETF and IEEE standards journey I wrote a 
draft defining a sub-interface based VLAN termination YANG model.  After 
discussion and presentations in both IETF NETMOD WG and IEEE 802.1 WG, there 
was a general agreement that it would be acceptable for IETF to publish this 
YANG model as an informational RFC, with the acknowledgement that 802.1Q VLAN 
technology is owned by IEEE, and in future the IEEE 802.1 WG may choose to 
publish a VLAN termination model.

As part of that IETF NETMOD WG process, and after IEEE 802.1 WG had reviewed 
the model, I made a small change in structure of the YANG model with the sole 
aim of making the model simpler to use. In particular, the older model required 
a slightly clunky indexed list of VLAN tags, and that is replaced with a 
simpler structure supporting two explicit named VLAN tags ('outer-tag' and 
'second-tag').  A while back, Glenn requested that I pass these changes by the 
IEEE 802.1 WG to ensure that the changes are acceptable to the IEEE 802.1 WG, 
hence this email.

The change is perhaps best illustrated via the following change in the YANG 
tree output.

The*older format* of the YANG model (that members of the 802.1Q WG previously 
saw) was like this:

*if-cmn:encaps-type: +--:(vlan) +--rw vlan +--rw tags +--rw tag* [index]
+--rw index uint8 +--rw dot1q-tag +--rw tag-type dot1q-tag-type +--rw
vlan-id dot1q-vlan-id*

The *updated format *of YANG model in the current draft is like this:

 +--:(dot1q-vlan)
+--rw dot1q-vlan
   +--rw outer-tag!
   |  +--rw tag-typedot1q-tag-type
   |  +--rw vlan-id ieee:vlanid
   +--rw second-tag!
  +--rw tag-typedot1q-tag-type
  +--rw vlan-id ieee:vlanid

The same equivalent change has been made for L2 sub-interfaces as well.

The latest internet draft is
https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04

In particular, it may also be useful to look at the instance data
examples in chapter 7, that give a couple of examples of how the YANG
model is expected to be used both for L3 termination, and also when used
in 

Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04

[John Messenger]

Hi,

At the 802.1 TSN meeting this morning, Lou Berger made a presentation on behalf 
of Rob Wilton summarising the recent changes in this draft.  I like the changes 
to the structure which are intended to align the VLAN tag structure to that 
specified in 802.1Q.  I notice that the draft retains clause 2.2 
(Extensibility) but I think that's a bug, because it's not reflected in the 
model (which is a fixed structure of one or two tags).

Right now, it says that the Ethertypes are taken from dot1q-tag-type.  Would 
this allow tags other than 802.1QTagType (81-00) and 802.1QSTagType (88-A8)?  
That shouldn't be allowed.

My preference would be to remove the forward-looking statement quoted here 
because it implies a willingness to extend to 3 tags:
The structure of the model is currently limited to matching or
   rewriting a maximum of two 802.1Q tags in the frame header but has
   been designed to be easily extensible to matching/rewriting three or
   more VLAN tags in future, if required.

It looks like you could parse an untagged frame as either :(untagged) or 
:(dot1q-vlan-tagged) (without either of the optional tags).  Is that a bug?

Thanks,
-- John 

-Original Message-
From: List HELP only  On Behalf Of Robert Wilton
Sent: 05 November 2018 16:16
To: stds-802-...@listserv.ieee.org
Subject: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - 
draft-ietf-netmod-sub-intf-vlan-model-04

Ballot due Nov. 6: P802.1Qcx/D0.4
For particulars see
  https://1.ieee802.org/active-ballots/
802.1 list help: https://1.ieee802.org/email-lists/
List archives (access-controlled) by date:
   www.ieee802.org/1/private/email2/mail1.html
-

Dear esteemed 802.1 WG members,

A few years back, at the start of my IETF and IEEE standards journey I wrote a 
draft defining a sub-interface based VLAN termination YANG model.  After 
discussion and presentations in both IETF NETMOD WG and IEEE 802.1 WG, there 
was a general agreement that it would be acceptable for IETF to publish this 
YANG model as an informational RFC, with the acknowledgement that 802.1Q VLAN 
technology is owned by IEEE, and in future the IEEE 802.1 WG may choose to 
publish a VLAN termination model.

As part of that IETF NETMOD WG process, and after IEEE 802.1 WG had reviewed 
the model, I made a small change in structure of the YANG model with the sole 
aim of making the model simpler to use. In particular, the older model required 
a slightly clunky indexed list of VLAN tags, and that is replaced with a 
simpler structure supporting two explicit named VLAN tags ('outer-tag' and 
'second-tag').  A while back, Glenn requested that I pass these changes by the 
IEEE 802.1 WG to ensure that the changes are acceptable to the IEEE 802.1 WG, 
hence this email.

The change is perhaps best illustrated via the following change in the YANG 
tree output.

The*older format* of the YANG model (that members of the 802.1Q WG previously 
saw) was like this:

*if-cmn:encaps-type: +--:(vlan) +--rw vlan +--rw tags +--rw tag* [index] 
+--rw index uint8 +--rw dot1q-tag +--rw tag-type dot1q-tag-type +--rw
vlan-id dot1q-vlan-id*

The *updated format *of YANG model in the current draft is like this:

+--:(dot1q-vlan)
   +--rw dot1q-vlan
  +--rw outer-tag!
  |  +--rw tag-typedot1q-tag-type
  |  +--rw vlan-id ieee:vlanid
  +--rw second-tag!
 +--rw tag-typedot1q-tag-type
 +--rw vlan-id ieee:vlanid

The same equivalent change has been made for L2 sub-interfaces as well.

The latest internet draft is 
https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04

In particular, it may also be useful to look at the instance data 
examples in chapter 7, that give a couple of examples of how the YANG 
model is expected to be used both for L3 termination, and also when used 
in conjunction with the IETF L2VPN YANG model to provision a 
point-to-point L2 service.

I hope to submit this draft to the NETMOD WG chairs for WG last call 
after the current IETF 103 meeting.  So if anyone has any concerns then 
please may I ask that you raise them.  ideally I would like to get them 
informally addressed before this document progresses.  Alternatively if 
you need more time to review this change, or need this as a formal 
liaison then please let me know, and I'll do my best.

Thank you for your time,
Rob Wilton


===
Unsubscribe link: mailto:stds-802-1-l-signoff-requ...@listserv.ieee.org
IEEE. Fostering technological innovation and excellence for the benefit of 
humanity.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

> On Nov 12, 2018, at 15:36, Alex Campbell  wrote:
> 
> Perhaps my opinion also carries less weight, as someone who's only on the 
> mailing list and didn't actually attend the IETF meeting.
> 


So, the reason we take the discussion back to the list is precisely to insure 
that we capture the opinions of those not present in the working group meeting. 
I think that is a point to be addressed separately from the question of whether 
the document is ready to go or not.

Thanks
Joel

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

Re: [netmod] missing YANG versioning requirements

[Andy Bierman]

On Mon, Nov 12, 2018 at 9:20 AM, Robert Wilton  wrote:

>
>
> On 12/11/2018 16:15, Andy Bierman wrote:
>
>
>
> On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  wrote:
>
>>
>>
>> On 09/11/2018 18:35, Andy Bierman wrote:
>>
>> Hi,
>>
>> I think the requirements doc should state that
>>
>> 1) there are many more readers, operators, and client developers than
>> server developers so the solution MUST take into account the numbers
>> of people affected when finding a balance between client and server
>> complexity.
>>
>> OK.  So you would like the solution to be weighted towards clients, but
>> yet you do not want servers to have to implement any sort of version
>> selection, instead pushing the problem on to the client? :-)
>>
>>
>
> I support some aspects of this work:
>   - SEMVER
>   - import-stmt
>   - status-stmt
>
> OK
>
>
> I strongly oppose the simultaneous implemented revisions requirement
> because it is actually
> a solution, not a requirement at all, and a bad solution.
>
>
>
> For any given buggy data node, a replacement sibling can be created so the
> new node and the deprecated
> buggy node can both be implemented.
>
> So, I regard this as a potential solution to requirement 3.2.
>
> However, I still do not understand a scheme for how this works for config
> items, either covering all of the various corner cases of clients at
> different versions, or at least states under what assumptions that solution
> works.
>
> Please can someone who thinks that this is a solution explain how this
> solution works.  I think that there are quite a lot of potential
> questions/issues:
>
>
I think model transformation is a flawed solution and not worth doing,
especially since the goal is to map NBC changes that do not work well with
this solution.
It is designed to map 1 disjoint subtree to another one, not really 2
revisions of the same nodes.
To be clear: I am not proposing that this solution be standardized at all.



> Are there two version entirely independent of are they connected (i.e.
> updating one, updates the other)?
>

no


> If they are dependent then does writing one value also update the other
> one?
>

no


> If they are independent they can two different values be written (perhaps
> for a pair of leaves this could be enforced with a must statement), but
> with more complex models this is not possible?
>


The  and  datastores would have the configured values,
and 
would have the value in use.

   start: foo = bar = 5
   config: foo=5, bar=5
   operational: foo=5, bar=5

  set bar to 10
  config: foo=5, bar=10
  operational: foo=10, bar=10

the 'origin' value is 'intended' for bar.
Not sure what it should be for foo.






> Does this solution support 2 clients interacting with the server using
> different versions of the leaf, or is it assumed that all clients will
> interact using the same version?
> What happens if both leaves have different default values (perhaps this
> can just be avoided)?
> What happens when the new value cannot be represented in the old leaf used
> by client A?  It now has a configuration that it cannot change because it
> doesn't know about the new leaf.
> What leaf values are updated in operational?  Is it both of them, or just
> one of them?
>
>
>
> YANG represents a customer-facing API, like the CLI.  Vendors understand
> that customers
> don't like it when CLI keywords change meaning from release to release.
> Vendors are careful
> to introduce new keywords so the old ones keep working.
>
>
> For our CLI, we generally accept the old, but always return the config
> using the new CLI.  However, I would expect that approach would probably
> break clients using YANG.  They would be confused that the configuration
> returned via get-config does not match what they programmed via edit-config.
>


If the transformation is 2-way then get-config can return the outer model.
You have to do that if the client implements only the
outer model and the server does not even advertise the inner model.



>
>
>
>
>> More seriously, I'm looking for a solution where we it up to the market
>> to decide whether the complexity should be pushed to client, server, or a
>> 3rd party controller.  I think that some sort of version selection should
>> be able to achieve this.
>>
>>
>>
> I do not agree the standards should be changed to support this solution
> approach.
>
>
>
>
>>
>> 2) if existing protocol and YANG solutions exist then they MUST be used
>> in favor of developing new solutions.
>>
>> If you replace the "MUST" with a "SHOULD" then I sort of think that this
>> one is obvious.  I think that we are only trying to develop next solutions
>> where the existing ones do not appear to be working well.  There are
>> examples in the earlier text in the requirements draft, and also
>> draft-clacla-netmod-yang-model-update to provide the background and
>> justify why we need to do something different than the status quo.
>>
>>
>
> It would help to have real examples where 

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[Alex Campbell]

Hi,

I was not at the IETF meeting unfortunately.

I see that the technical issues raised in the WGLC have been fixed, which is 
good.

However I still have reservations about the utility of the proposed standard. 
It seems to me like a solution in search of a problem, and I can't understand 
why it should be pushed forward to an RFC. Maybe there is some context I am 
missing. The use-cases that have been described to me so far seem like they 
would be better served by a client-side mechanism. Perhaps the client-side data 
store can still be modelled in YANG, but in that case, I think the document 
should say so.

I asked why the server should hold the data. The reason I am given is "so that 
clients can read it." Why is the data not on the client in the first place?
The client can make modifications to the data, so that the client can read it 
back later. Why does the client need to store these modifications outside of 
itself?

I am told this is a general-purpose tool. In that case, I would like to see at 
least two or three separate use-cases so that I can be sure this is actually a 
*useful general-purpose abstraction*, and not something specific to the one (or 
zero!) use-cases the authors seem to envision. I am aware that the cost of 
creating bad standards can be quite high, if the next person who wants some 
YANG module metadata feels obligated to use the existing tag mechanism instead 
of something new, but finds it doesn't quite fit their needs. See also 
https://blog.codinghorror.com/rule-of-three/ and 
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

I think the draft could also do with describing how this module is supposed to 
be used. A YANG module in isolation means nothing. Most of the YANG modules I 
am familiar with are to define configuration and/or state data to be stored on 
a network element or a provisioning/orchestration system, and accessed over 
NETCONF. I believe it is implicit that unless otherwise specified, YANG modules 
are intended for NETCONF use, but I am unclear on which kinds of NETCONF 
servers should implement this module.

Perhaps my opinion also carries less weight, as someone who's only on the 
mailing list and didn't actually attend the IETF meeting.




From: netmod  on behalf of joel jaeggli 

Sent: Tuesday, 13 November 2018 5:46 a.m.
To: NETMOD Working Group
Subject: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

During the Thursday nov 8 session of netmod, we asked if there were any 
objections to the publication of the Draft-03 version of 
draft-ietf-netmod-module-tags which addresses comments and concerns raised 
during the WGLC. In the meeting there were none. This commences a comment 
period to confirm that call. As this follows closely on the heels of the IETF 
103 meeting we’ll let the call run through Monday the 26th of November.

https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt


Thanks
Joel
___
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] Deviations and augmentations

[Ebben Aries]

On Nov 12 17:33 PM, Martin Bjorklund wrote:
> Robert Wilton  wrote:
> > In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> > describe how deviations and augmentations are used in OpenConfig to
> > add functionality into an older YANG model where the semver rules
> > prevent the version number from being incremented.
> > 
> > Further, I think that someone (Martin?) stated on the audio bridge
> > that this was an intended/allowed behavior for deviations.
> 
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
> 
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
> 
> 

Does this not already somewhat exist today by way of each vendors
augments and deviations to OC models?  While branching doesn't exist
within OC directly, each implementation today supports *a* version at a
given point in time and deviations and augments exist within these
"branches". Occasionally the need arises to introduce changes in the
vendor provided modules as a stopgap that are ultimately mapped to a sw
release.

This could be fixes or additional functionality not previously there to
satisfy not having a customer have to upgrade their network element
and/or move to more recent modules

> 
> 
> > This surprised me, because I thought that RFC 7950 was quite explicit
> > that this is not what deviations are intended for.  My reading of RFC
> > 7950 is that the deviation statement represents the case where the
> > server *implementation* does not match the *specification*.  However,
> > the versioning issue that we are discussing are bug fixes/changes in
> > the specification rather than the bug fixes in the implementation.
> > 
> > Personally, I'm really not keen on using deviations to represent bug
> > fixes to older YANG models for three reasons:
> > 
> > (i) It is changing the meaning of deviation.  It is much cleaner to
> > keep the meaning of deviation statements as they are defined today,
> > and not conflate their semantics.
> > (ii) A different mechanism is used to put a bug fix into an older
> > branch rather than in the head of the development.
> > (iii) For clients to track the lifecycle of modules they would not
> > only need to know the module version number but would also need to
> > find and track all associated deviation modules.  This seems
> > significantly more complex for clients than the modified semver that
> > was proposed.
> > 
> > ---
> > 
> > I think that has also been some suggestion that augmentations (or
> > duplicate YANG modules with their major version number changed) can be
> > used to make bug fixes in a completely backwards compatible way. 
> > However, I still don't understand a robust scheme of how this works.
> > 
> > ---
> > 
> > Finally, there were some comments about using augmentation modules for
> > enhancements.  This is fine, where appropriate (e.g. a non trivial
> > number of data nodes are being added as an enhancement) then a
> > separate module may be the right way to go. But here, I presume that
> > the new functionality will always be tracked by that separate module. 
> > If that functionality folds back into the original module at some
> > point in the future, then obviously a non backwards compatible version
> > change is being forced on to the client, along with additional work on
> > the server as well.
> > 
> > I think that there are also many cases where the number of data nodes
> > being added via an enhancement is small compared to the size of the
> > module being updated.  In this case I believe that it better to add
> > these data nodes into the module itself, perhaps predicated under
> > if-feature if appropriate.
> > 
> > Thanks,
> > Rob
> > 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIFAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=GIehbDpQlo31lSi6WbnEkA=8si7cLdi3y5avgA6Nvi0V0TixjVoKFudWwp3mJNat5I=4OHPx7mvkQdY9-M_M5HEOcYS566LOUuNecztVjp_NFw=
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIFAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=GIehbDpQlo31lSi6WbnEkA=8si7cLdi3y5avgA6Nvi0V0TixjVoKFudWwp3mJNat5I=4OHPx7mvkQdY9-M_M5HEOcYS566LOUuNecztVjp_NFw=

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

[netmod] Limitations of semver

[Robert Wilton]

Although, we may like to think otherwise, I do not believe that semver 
is a silver bullet that will solve all YANG versioning problems.


Yes, it is popular and used, perhaps quite successfully, in lots of 
projects.  But there are many other large scale projects that have not 
adopted semver, e.g. 
https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e states that none 
of the following properly use semver: Node doesn't follow SemVer, Rails 
doesn't do it, Python doesn't do it, Ruby doesn't do it, jQuery doesn't 
(really) do it, even npm doesn't follow SemVer.


The reason why I don't think that vanilla semver works for YANG is for 
two reasons:
(1) Semver is often used where API and implementation are versioned 
together (e.g. code libraries).  I.e. the "patch" field is semver is 
really about fixes to the implementation that do not change the API in 
anyway.  But a YANG module definition is really defining an API contract 
between client and server.
(2) Semver makes the assumption that all changes can be made to the head 
of the development branch, and that clients are able to relatively 
easily update to the latest version if required.  In fact, for an open 
source project it is a beneficial feature if you can force your clients 
to migrate to the latest API and code because there are less different 
versions to support.


But when applied to YANG modules there are two significant differences:
(1) The server implementations are not being versioned with the YANG 
API.  They may be multiple vendor products implementing the same YANG 
module, or there may be multiple products across multiple vendors 
implementing the same YANG module.  Asking a customer to move to the 
latest release to pick up a bug fix is not a realistic option, since the 
vendor/device may not even implement the latest version of the YANG 
module.  Also moving to the latest version of one particular YANG module 
could have cascading dependencies on other YANG modules.


(2) I would expect YANG modules, and the requirements to support them, 
to be much more long lived than open source projects that are using 
semver.  Where vendors are being paid to support software releases that 
have shipped with particular modules, customer have an expectation that 
they can get point fixes to those releases without being forced to 
update to major versions.


Hence, the proposal for modified semver.  Its aim is to be semver plus 
the minimal added changes to allow it to primarily support bug fixes 
(including nbc ones) to older releases.


The alternative, of using vanilla semver, looks similar to what we have 
today:
- vendors will increment the major version number for every release so 
that they they can increment the minor version number for bug fixes.
- or vendors will use deviations as a mechanism to get round where the 
API is wrong,
- or most likely, vendors will just fix the bug and increment the 
"patch" version number anyway breaking the semver rules, just as they 
ignore the YANG module updated rules today.


Perhaps this will all lead to the schema diff tool that I also like, if 
clients reach the point where they cannot trust the semver version 
numbers because it cannot actually encode the changes that are happening 
to the module.


As a vendor, I know that we have bug fixes going into older modules, Rob 
S indicated that OpenConfig does as well.  So, I think that the key 
question is whether we want the versioning scheme to be able to sensibly 
label bug fixes.  If we do, then I don't think that vanilla semver will 
meet the requirement.


Thanks,
Rob

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

Re: [netmod] missing YANG versioning requirements

[Robert Wilton]

On 12/11/2018 16:15, Andy Bierman wrote:



On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton > wrote:




On 09/11/2018 18:35, Andy Bierman wrote:

Hi,

I think the requirements doc should state that

1) there are many more readers, operators, and client developers than
server developers so the solution MUST take into account the numbers
of people affected when finding a balance between client and
server complexity.

OK.  So you would like the solution to be weighted towards
clients, but yet you do not want servers to have to implement any
sort of version selection, instead pushing the problem on to the
client? :-)



I support some aspects of this work:
  - SEMVER
  - import-stmt
  - status-stmt

OK



I strongly oppose the simultaneous implemented revisions requirement 
because it is actually

a solution, not a requirement at all, and a bad solution.





For any given buggy data node, a replacement sibling can be created so 
the new node and the deprecated

buggy node can both be implemented.

So, I regard this as a potential solution to requirement 3.2.

However, I still do not understand a scheme for how this works for 
config items, either covering all of the various corner cases of clients 
at different versions, or at least states under what assumptions that 
solution works.


Please can someone who thinks that this is a solution explain how this 
solution works.  I think that there are quite a lot of potential 
questions/issues:


Are there two version entirely independent of are they connected (i.e. 
updating one, updates the other)?

If they are dependent then does writing one value also update the other one?
If they are independent they can two different values be written 
(perhaps for a pair of leaves this could be enforced with a must 
statement), but with more complex models this is not possible?
Does this solution support 2 clients interacting with the server using 
different versions of the leaf, or is it assumed that all clients will 
interact using the same version?
What happens if both leaves have different default values (perhaps this 
can just be avoided)?
What happens when the new value cannot be represented in the old leaf 
used by client A?  It now has a configuration that it cannot change 
because it doesn't know about the new leaf.
What leaf values are updated in operational?  Is it both of them, or 
just one of them?





YANG represents a customer-facing API, like the CLI. Vendors 
understand that customers
don't like it when CLI keywords change meaning from release to 
release.  Vendors are careful

to introduce new keywords so the old ones keep working.


For our CLI, we generally accept the old, but always return the config 
using the new CLI.  However, I would expect that approach would probably 
break clients using YANG.  They would be confused that the configuration 
returned via get-config does not match what they programmed via edit-config.




More seriously, I'm looking for a solution where we it up to the
market to decide whether the complexity should be pushed to
client, server, or a 3rd party controller.  I think that some sort
of version selection should be able to achieve this.



I do not agree the standards should be changed to support this 
solution approach.




2) if existing protocol and YANG solutions exist then they MUST
be used
in favor of developing new solutions.

If you replace the "MUST" with a "SHOULD" then I sort of think
that this one is obvious.  I think that we are only trying to
develop next solutions where the existing ones do not appear to be
working well.  There are examples in the earlier text in the
requirements draft, and also draft-clacla-netmod-yang-model-update
to provide the background and justify why we need to do something
different than the status quo.



It would help to have real examples where deprecate-and-replace was an 
unworkable solution.
I would happy to start with an example where you think it does work, 
taking into consideration the questions that I provided previously.


IMO it is OK to update a data node because sub-statements are 
incorrect (e.g. pattern, type).

In this case, the old definition is not worth preserving.

This can still break some clients.



Note that changes between I-Ds are not interesting. Only changes from 
RFC to RFC are interesting.
Vendors need to review their own modules and do a better job 
identifying stable vs. unstable releases.

I agree to both of these.

But lets not pretend that all code that we ever produce will be perfect 
the first time, contain no bugs, and never need to be changed.  We have 
seen the industry push for us to be more reactive and get changes out 
more quickly.  I would argue that a natural side effect of that is that 
there are likely to be more bugs that will need fixing.


Thanks,
Rob





Thanks,
Rob



Andy





Andy

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Robert Wilton]

On 12/11/2018 16:29, Martin Bjorklund wrote:

Robert Wilton  wrote:

Hi Martin,


On 09/11/2018 16:31, Martin Bjorklund wrote:

Juergen Schoenwaelder  wrote:

On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.


Here is what 3.2 says:

 3.2  The solution MUST provide a mechanism to allow servers to
  simultaneously support clients using different revisions of
  modules.  A client's choice of particular revision of one or
  more modules may restrict the particular revision of other
  modules that may be used in the same request or session.

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more
attractive.

Ok, but that's not what I wrote.  I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.

One way to think of this is as YANG data models defining an API
between client and server.

There seem to be lots of REST APIs that implement versioning of their
API by having a version number in the URL.

Yes, but that doesn't mean that a given server supports more than one
version seamlessly.
I agree.  But if a set of translations are being defined between old and 
new it should be possible to identify those cases where the mapping does 
not work.


At the end of the day, if the schema has been expanded in any way, then 
an old client isn't going to understand new functionality used by a new 
client.



  As you wrote, it works fine for operational
state, but it is less obvious how it should work in the general case
for config data.
Even for operational data (if we are discussing mapping different 
versions of a schema) then it is not guaranteed that it is possible to 
map between different representations.  If they are two far apart then a 
good mapping may not be possible.






In fact, I think that
RESTCONF adopts this approach to allow versioning of the protocol.

One solution is as Andy describes.  The underlying server only
implements one version of the a given YANG module, but they may
provide other views on to this data using different versions of YANG
modules.  E.g. the same as how Vendor YANG models, IETF YANG models,
and OpenConfig YANG models might be treated as their own views, mapped
to the same internal YANG modules.

Yes, but this solution is also problematic; it is not always the case
that clients can pick and choose from these different "views" and get
consistent results, simply b/c the mappings are not 100% one-to-one.
But a device performing that mapping should be able to report the 
paths/values that it has not been able to map.


Thanks,
Rob




/martin


Thanks,
Rob




/martin



I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.

/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] Deviations and augmentations

[Robert Wilton]

On 12/11/2018 16:33, Martin Bjorklund wrote:

Robert Wilton  wrote:

In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
describe how deviations and augmentations are used in OpenConfig to
add functionality into an older YANG model where the semver rules
prevent the version number from being incremented.

Further, I think that someone (Martin?) stated on the audio bridge
that this was an intended/allowed behavior for deviations.

I said that using augmentations (not deviations) was one idea we
originally had for solving the "branching problem".

Ah, OK. I agree that makes sense.



I think that this works for OC b/c they don't branch their modules.
Hence I think it is important that we decide if branching is a
requirement or not.
So, I think that this probably works for adding enhancements, but not 
for the (arguably more important) bug fix case, unless there is a 
reasonable solution to having two config data nodes both modifying the 
same underlying property.  Perhaps under some reasonable constraints 
this could be made to work - but I don't know.


Of course, even for enhancements it is not necessarily a perfect 
solution.  E.g. backporting some subset of a module already 
coded/implemented in latest to an older release.  And yes, we really do 
get asked to do this sometimes, although it is relatively rare.


Thanks,
Rob




/martin



This surprised me, because I thought that RFC 7950 was quite explicit
that this is not what deviations are intended for.  My reading of RFC
7950 is that the deviation statement represents the case where the
server *implementation* does not match the *specification*.  However,
the versioning issue that we are discussing are bug fixes/changes in
the specification rather than the bug fixes in the implementation.

Personally, I'm really not keen on using deviations to represent bug
fixes to older YANG models for three reasons:

(i) It is changing the meaning of deviation.  It is much cleaner to
keep the meaning of deviation statements as they are defined today,
and not conflate their semantics.
(ii) A different mechanism is used to put a bug fix into an older
branch rather than in the head of the development.
(iii) For clients to track the lifecycle of modules they would not
only need to know the module version number but would also need to
find and track all associated deviation modules.  This seems
significantly more complex for clients than the modified semver that
was proposed.

---

I think that has also been some suggestion that augmentations (or
duplicate YANG modules with their major version number changed) can be
used to make bug fixes in a completely backwards compatible way.
However, I still don't understand a robust scheme of how this works.

---

Finally, there were some comments about using augmentation modules for
enhancements.  This is fine, where appropriate (e.g. a non trivial
number of data nodes are being added as an enhancement) then a
separate module may be the right way to go. But here, I presume that
the new functionality will always be tracked by that separate module.
If that functionality folds back into the original module at some
point in the future, then obviously a non backwards compatible version
change is being forced on to the client, along with additional work on
the server as well.

I think that there are also many cases where the number of data nodes
being added via an enhancement is small compared to the size of the
module being updated.  In this case I believe that it better to add
these data nodes into the module itself, perhaps predicated under
if-feature if appropriate.

Thanks,
Rob


___
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] Deviations and augmentations

[Andy Bierman]

On Mon, Nov 12, 2018 at 8:33 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> > describe how deviations and augmentations are used in OpenConfig to
> > add functionality into an older YANG model where the semver rules
> > prevent the version number from being incremented.
> >
> > Further, I think that someone (Martin?) stated on the audio bridge
> > that this was an intended/allowed behavior for deviations.
>
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
>
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
>
>
Branching is a solution, not a requirement.
IMO deviate(not-supported) is intended to let the server describe what it
supports
without requiring branching. Clients already support deviations.



>
> /martin
>

Andy


>
>
> > This surprised me, because I thought that RFC 7950 was quite explicit
> > that this is not what deviations are intended for.  My reading of RFC
> > 7950 is that the deviation statement represents the case where the
> > server *implementation* does not match the *specification*.  However,
> > the versioning issue that we are discussing are bug fixes/changes in
> > the specification rather than the bug fixes in the implementation.
> >
> > Personally, I'm really not keen on using deviations to represent bug
> > fixes to older YANG models for three reasons:
> >
> > (i) It is changing the meaning of deviation.  It is much cleaner to
> > keep the meaning of deviation statements as they are defined today,
> > and not conflate their semantics.
> > (ii) A different mechanism is used to put a bug fix into an older
> > branch rather than in the head of the development.
> > (iii) For clients to track the lifecycle of modules they would not
> > only need to know the module version number but would also need to
> > find and track all associated deviation modules.  This seems
> > significantly more complex for clients than the modified semver that
> > was proposed.
> >
> > ---
> >
> > I think that has also been some suggestion that augmentations (or
> > duplicate YANG modules with their major version number changed) can be
> > used to make bug fixes in a completely backwards compatible way.
> > However, I still don't understand a robust scheme of how this works.
> >
> > ---
> >
> > Finally, there were some comments about using augmentation modules for
> > enhancements.  This is fine, where appropriate (e.g. a non trivial
> > number of data nodes are being added as an enhancement) then a
> > separate module may be the right way to go. But here, I presume that
> > the new functionality will always be tracked by that separate module.
> > If that functionality folds back into the original module at some
> > point in the future, then obviously a non backwards compatible version
> > change is being forced on to the client, along with additional work on
> > the server as well.
> >
> > I think that there are also many cases where the number of data nodes
> > being added via an enhancement is small compared to the size of the
> > module being updated.  In this case I believe that it better to add
> > these data nodes into the module itself, perhaps predicated under
> > if-feature if appropriate.
> >
> > Thanks,
> > Rob
> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli]

During the Thursday nov 8 session of netmod, we asked if there were any 
objections to the publication of the Draft-03 version of 
draft-ietf-netmod-module-tags which addresses comments and concerns raised 
during the WGLC. In the meeting there were none. This commences a comment 
period to confirm that call. As this follows closely on the heels of the IETF 
103 meeting we’ll let the call run through Monday the 26th of November. 

https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt


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

Re: [netmod] Deviations and augmentations

[Martin Bjorklund]

Robert Wilton  wrote:
> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> describe how deviations and augmentations are used in OpenConfig to
> add functionality into an older YANG model where the semver rules
> prevent the version number from being incremented.
> 
> Further, I think that someone (Martin?) stated on the audio bridge
> that this was an intended/allowed behavior for deviations.

I said that using augmentations (not deviations) was one idea we
originally had for solving the "branching problem".

I think that this works for OC b/c they don't branch their modules.
Hence I think it is important that we decide if branching is a
requirement or not.


/martin


> This surprised me, because I thought that RFC 7950 was quite explicit
> that this is not what deviations are intended for.  My reading of RFC
> 7950 is that the deviation statement represents the case where the
> server *implementation* does not match the *specification*.  However,
> the versioning issue that we are discussing are bug fixes/changes in
> the specification rather than the bug fixes in the implementation.
> 
> Personally, I'm really not keen on using deviations to represent bug
> fixes to older YANG models for three reasons:
> 
> (i) It is changing the meaning of deviation.  It is much cleaner to
> keep the meaning of deviation statements as they are defined today,
> and not conflate their semantics.
> (ii) A different mechanism is used to put a bug fix into an older
> branch rather than in the head of the development.
> (iii) For clients to track the lifecycle of modules they would not
> only need to know the module version number but would also need to
> find and track all associated deviation modules.  This seems
> significantly more complex for clients than the modified semver that
> was proposed.
> 
> ---
> 
> I think that has also been some suggestion that augmentations (or
> duplicate YANG modules with their major version number changed) can be
> used to make bug fixes in a completely backwards compatible way. 
> However, I still don't understand a robust scheme of how this works.
> 
> ---
> 
> Finally, there were some comments about using augmentation modules for
> enhancements.  This is fine, where appropriate (e.g. a non trivial
> number of data nodes are being added as an enhancement) then a
> separate module may be the right way to go. But here, I presume that
> the new functionality will always be tracked by that separate module. 
> If that functionality folds back into the original module at some
> point in the future, then obviously a non backwards compatible version
> change is being forced on to the client, along with additional work on
> the server as well.
> 
> I think that there are also many cases where the number of data nodes
> being added via an enhancement is small compared to the size of the
> module being updated.  In this case I believe that it better to add
> these data nodes into the module itself, perhaps predicated under
> if-feature if appropriate.
> 
> Thanks,
> Rob
> 
> 
> ___
> 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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Robert Wilton  wrote:
> Hi Martin,
> 
> 
> On 09/11/2018 16:31, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> >> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
>  I think we need to distinguish between the agreement on the
>  requirement, namely that a server should be able to provide support
>  for an old and a new definition, and agreement on the solution.
> 
>  Do you disagree with the requirement? Or do you disagree with the
>  consequences of implementing multiple versions of the same module
>  for some of the proposed new versioning schemes? Or both?
> >>> I do not agree with the requirement that a server MUST be able to
> >>> support multiple revisions of the same module, which is how I
> >>> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> >>> clarified.
> >>>
> >> Here is what 3.2 says:
> >>
> >> 3.2  The solution MUST provide a mechanism to allow servers to
> >>  simultaneously support clients using different revisions of
> >>  modules.  A client's choice of particular revision of one or
> >>  more modules may restrict the particular revision of other
> >>  modules that may be used in the same request or session.
> >>
> >> This does _not_ say servers MUST implement this.
> >>
> >> Item 3.2 establishes a requirement and for some solutions it may be
> >> easy to satisfy this requirement, for others it may be more costly to
> >> satisfy this requirement.
> >>
> >> The whole requirements exercise becomes a rather pointless exercise if
> >> we remove requirements so that certain solutions look more
> >> attractive.
> > Ok, but that's not what I wrote.  I don't agree with this requirement
> > which says that it MUST be possible for a server to support
> > different revisions of a given module (again, if this is not the
> > intention of the text, please clarify).  I simply don't think that
> > this is a good requirement.
> One way to think of this is as YANG data models defining an API
> between client and server.
> 
> There seem to be lots of REST APIs that implement versioning of their
> API by having a version number in the URL.

Yes, but that doesn't mean that a given server supports more than one
version seamlessly.  As you wrote, it works fine for operational
state, but it is less obvious how it should work in the general case
for config data.

> In fact, I think that
> RESTCONF adopts this approach to allow versioning of the protocol.
> 
> One solution is as Andy describes.  The underlying server only
> implements one version of the a given YANG module, but they may
> provide other views on to this data using different versions of YANG
> modules.  E.g. the same as how Vendor YANG models, IETF YANG models,
> and OpenConfig YANG models might be treated as their own views, mapped
> to the same internal YANG modules.

Yes, but this solution is also problematic; it is not always the case
that clients can pick and choose from these different "views" and get
consistent results, simply b/c the mappings are not 100% one-to-one.


/martin

> 
> Thanks,
> Rob
> 
> 
> >
> >
> > /martin
> >
> >
> >> I have not seen a proposal that addresses all requirements and hence
> >> at the end the WG needs to decide which tradeoffs make sense.
> >>
> >> /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

[netmod] Deviations and augmentations

[Robert Wilton]

In the Thursday Netmod meeting, it was interesting to hear Rob Shakir 
describe how deviations and augmentations are used in OpenConfig to add 
functionality into an older YANG model where the semver rules prevent 
the version number from being incremented.


Further, I think that someone (Martin?) stated on the audio bridge that 
this was an intended/allowed behavior for deviations.


This surprised me, because I thought that RFC 7950 was quite explicit 
that this is not what deviations are intended for.  My reading of RFC 
7950 is that the deviation statement represents the case where the 
server *implementation* does not match the *specification*.  However, 
the versioning issue that we are discussing are bug fixes/changes in the 
specification rather than the bug fixes in the implementation.


Personally, I'm really not keen on using deviations to represent bug 
fixes to older YANG models for three reasons:


(i) It is changing the meaning of deviation.  It is much cleaner to keep 
the meaning of deviation statements as they are defined today, and not 
conflate their semantics.
(ii) A different mechanism is used to put a bug fix into an older branch 
rather than in the head of the development.
(iii) For clients to track the lifecycle of modules they would not only 
need to know the module version number but would also need to find and 
track all associated deviation modules.  This seems significantly more 
complex for clients than the modified semver that was proposed.


---

I think that has also been some suggestion that augmentations (or 
duplicate YANG modules with their major version number changed) can be 
used to make bug fixes in a completely backwards compatible way.  
However, I still don't understand a robust scheme of how this works.


---

Finally, there were some comments about using augmentation modules for 
enhancements.  This is fine, where appropriate (e.g. a non trivial 
number of data nodes are being added as an enhancement) then a separate 
module may be the right way to go. But here, I presume that the new 
functionality will always be tracked by that separate module.  If that 
functionality folds back into the original module at some point in the 
future, then obviously a non backwards compatible version change is 
being forced on to the client, along with additional work on the server 
as well.


I think that there are also many cases where the number of data nodes 
being added via an enhancement is small compared to the size of the 
module being updated.  In this case I believe that it better to add 
these data nodes into the module itself, perhaps predicated under 
if-feature if appropriate.


Thanks,
Rob


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

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Juergen Schoenwaelder]

On Mon, Nov 12, 2018 at 05:21:55PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > > > 
> > > > > > I think we need to distinguish between the agreement on the
> > > > > > requirement, namely that a server should be able to provide support
> > > > > > for an old and a new definition, and agreement on the solution.
> > > > > > 
> > > > > > Do you disagree with the requirement? Or do you disagree with the
> > > > > > consequences of implementing multiple versions of the same module
> > > > > > for some of the proposed new versioning schemes? Or both?
> > > > > 
> > > > > I do not agree with the requirement that a server MUST be able to
> > > > > support multiple revisions of the same module, which is how I
> > > > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > > > clarified.
> > > > >
> > > > 
> > > > Here is what 3.2 says:
> > > > 
> > > >3.2  The solution MUST provide a mechanism to allow servers to
> > > > simultaneously support clients using different revisions of
> > > > modules.  A client's choice of particular revision of one or
> > > > more modules may restrict the particular revision of other
> > > > modules that may be used in the same request or session.
> > > > 
> > > > This does _not_ say servers MUST implement this.
> > > > 
> > > > Item 3.2 establishes a requirement and for some solutions it may be
> > > > easy to satisfy this requirement, for others it may be more costly to
> > > > satisfy this requirement.
> > > > 
> > > > The whole requirements exercise becomes a rather pointless exercise if
> > > > we remove requirements so that certain solutions look more
> > > > attractive.
> > > 
> > > Ok, but that's not what I wrote.  I don't agree with this requirement
> > > which says that it MUST be possible for a server to support
> > > different revisions of a given module (again, if this is not the
> > > intention of the text, please clarify).  I simply don't think that
> > > this is a good requirement.
> > >
> > 
> > I can't follow you or I do not understand what you are after.
> > 
> >   In some versioning schemes, providing support for different
> >   'versions' is relatively easy. If I have modules foo-1 and foo-2,
> >   then I can implement foo-1 and foo-2 (or proper workable subsets of
> >   them) easily. And older clients expecting foo-1 may continue to work
> >   while newer clients move to foo-2. In other versioning schemes,
> >   providing the same possibility to migrate from foo version 1 to foo
> >   version 2, would lead to the support of foo in two different
> >   versions.
> 
> But module 'foo-2' is not a new revision of module 'foo-1'.  It might
> be that 'foo-2' represents a new version of the underlying "function"
> that 'foo-1' represents; but that is a different issue.

This depends on the versioning solution or what we consider a versioning
solution.

> > The requirement tries to express that it must be possible to have a
> > transition path where old clients can continue to function with the
> > old version while new clients start using the new version. The idea is
> > to state this as a requirement without making any assumptions about
> > the solutions.
> > 
> > Are you saying that a requirement saying that there should be a
> > possibility of a transition path is in general a bad requirement?
> 
> No (but I agree w/ Rob Wilton that it is unclear how this should be
> done in non-trivial examples), but again, that is not what I think 3.2
> says.  IMO 3.2 doesn't allow a solution that requires a new module for
> new NBC stuff, since it says that a client should be able to pick a
> particular revision of a module.
>

We apparently lack words for modules that may be versioned by new
module names.

/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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > > 
> > > > > I think we need to distinguish between the agreement on the
> > > > > requirement, namely that a server should be able to provide support
> > > > > for an old and a new definition, and agreement on the solution.
> > > > > 
> > > > > Do you disagree with the requirement? Or do you disagree with the
> > > > > consequences of implementing multiple versions of the same module
> > > > > for some of the proposed new versioning schemes? Or both?
> > > > 
> > > > I do not agree with the requirement that a server MUST be able to
> > > > support multiple revisions of the same module, which is how I
> > > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > > clarified.
> > > >
> > > 
> > > Here is what 3.2 says:
> > > 
> > >3.2  The solution MUST provide a mechanism to allow servers to
> > > simultaneously support clients using different revisions of
> > > modules.  A client's choice of particular revision of one or
> > > more modules may restrict the particular revision of other
> > > modules that may be used in the same request or session.
> > > 
> > > This does _not_ say servers MUST implement this.
> > > 
> > > Item 3.2 establishes a requirement and for some solutions it may be
> > > easy to satisfy this requirement, for others it may be more costly to
> > > satisfy this requirement.
> > > 
> > > The whole requirements exercise becomes a rather pointless exercise if
> > > we remove requirements so that certain solutions look more
> > > attractive.
> > 
> > Ok, but that's not what I wrote.  I don't agree with this requirement
> > which says that it MUST be possible for a server to support
> > different revisions of a given module (again, if this is not the
> > intention of the text, please clarify).  I simply don't think that
> > this is a good requirement.
> >
> 
> I can't follow you or I do not understand what you are after.
> 
>   In some versioning schemes, providing support for different
>   'versions' is relatively easy. If I have modules foo-1 and foo-2,
>   then I can implement foo-1 and foo-2 (or proper workable subsets of
>   them) easily. And older clients expecting foo-1 may continue to work
>   while newer clients move to foo-2. In other versioning schemes,
>   providing the same possibility to migrate from foo version 1 to foo
>   version 2, would lead to the support of foo in two different
>   versions.

But module 'foo-2' is not a new revision of module 'foo-1'.  It might
be that 'foo-2' represents a new version of the underlying "function"
that 'foo-1' represents; but that is a different issue.


> The requirement tries to express that it must be possible to have a
> transition path where old clients can continue to function with the
> old version while new clients start using the new version. The idea is
> to state this as a requirement without making any assumptions about
> the solutions.
> 
> Are you saying that a requirement saying that there should be a
> possibility of a transition path is in general a bad requirement?

No (but I agree w/ Rob Wilton that it is unclear how this should be
done in non-trivial examples), but again, that is not what I think 3.2
says.  IMO 3.2 doesn't allow a solution that requires a new module for
new NBC stuff, since it says that a client should be able to pick a
particular revision of a module.


/martin




> 
> /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] missing YANG versioning requirements

[Andy Bierman]

On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  wrote:

>
>
> On 09/11/2018 18:35, Andy Bierman wrote:
>
> Hi,
>
> I think the requirements doc should state that
>
> 1) there are many more readers, operators, and client developers than
> server developers so the solution MUST take into account the numbers
> of people affected when finding a balance between client and server
> complexity.
>
> OK.  So you would like the solution to be weighted towards clients, but
> yet you do not want servers to have to implement any sort of version
> selection, instead pushing the problem on to the client? :-)
>
>

I support some aspects of this work:
  - SEMVER
  - import-stmt
  - status-stmt

I strongly oppose the simultaneous implemented revisions requirement
because it is actually
a solution, not a requirement at all, and a bad solution.

For any given buggy data node, a replacement sibling can be created so the
new node and the deprecated
buggy node can both be implemented.

YANG represents a customer-facing API, like the CLI.  Vendors understand
that customers
don't like it when CLI keywords change meaning from release to release.
Vendors are careful
to introduce new keywords so the old ones keep working.



> More seriously, I'm looking for a solution where we it up to the market to
> decide whether the complexity should be pushed to client, server, or a 3rd
> party controller.  I think that some sort of version selection should be
> able to achieve this.
>
>
>
I do not agree the standards should be changed to support this solution
approach.


>
> 2) if existing protocol and YANG solutions exist then they MUST be used
> in favor of developing new solutions.
>
> If you replace the "MUST" with a "SHOULD" then I sort of think that this
> one is obvious.  I think that we are only trying to develop next solutions
> where the existing ones do not appear to be working well.  There are
> examples in the earlier text in the requirements draft, and also
> draft-clacla-netmod-yang-model-update to provide the background and
> justify why we need to do something different than the status quo.
>
>

It would help to have real examples where deprecate-and-replace was an
unworkable solution.
IMO it is OK to update a data node because sub-statements are incorrect
(e.g. pattern, type).
In this case, the old definition is not worth preserving.

Note that changes between I-Ds are not interesting.  Only changes from RFC
to RFC are interesting.
Vendors need to review their own modules and do a better job identifying
stable vs. unstable releases.


Thanks,
> Rob
>
>

Andy


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

Re: [netmod] missing YANG versioning requirements

[Robert Wilton]

On 09/11/2018 18:35, Andy Bierman wrote:

Hi,

I think the requirements doc should state that

1) there are many more readers, operators, and client developers than
server developers so the solution MUST take into account the numbers
of people affected when finding a balance between client and server 
complexity.
OK.  So you would like the solution to be weighted towards clients, but 
yet you do not want servers to have to implement any sort of version 
selection, instead pushing the problem on to the client? :-)


More seriously, I'm looking for a solution where we it up to the market 
to decide whether the complexity should be pushed to client, server, or 
a 3rd party controller.  I think that some sort of version selection 
should be able to achieve this.





2) if existing protocol and YANG solutions exist then they MUST be used
in favor of developing new solutions.
If you replace the "MUST" with a "SHOULD" then I sort of think that this 
one is obvious.  I think that we are only trying to develop next 
solutions where the existing ones do not appear to be working well.  
There are examples in the earlier text in the requirements draft, and 
also draft-clacla-netmod-yang-model-update to provide the background and 
justify why we need to do something different than the status quo.


Thanks,
Rob





Andy



___
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