Subject: [netmod] yang 1.1 webex on wednesday october 29th

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Oct 2014 23:06:15 +0100

During the last YANG 1.1 virtual interim meeting, we discussed to have
another meeting to talk about the conformance related issues.
Unfortunately, the series of virtual interim meetings allocated for
YANG 1.1 work did end last Wednesday and since scheduling a virtual
interim meeting requires two weeks of advance notice, we can't have an
official virtual interim meeting on Wednesday.

However, in order to not loose traction, I like to invite all people
interested in this topic to an inofficial webex meeting taking place
on Wednesday at 16:00 CET, which will run for at most two hours. While
I will write the usual minutes, this is not an official virtual
interim meeting. But hopefully this ad-hoc webex helps to come to a
clearer view on how to move forward with the conformance related
issues.

I am attaching the webex information. The webex information is
different from the previous virtual interim meeting webex info - so
please make sure to join the correct webex meeting.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Oct 2014 06:55:59 -0700

Hi,

I just noticed this is an hour later than the usual NETMOD conf-call.
16:00 CET is 8:00AM PDT.

Andy

On Mon, Oct 27, 2014 at 3:06 PM, Juergen Schoenwaelder
<[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 29 Oct 2014 16:06:30 +0100

Hi,

we are using this etherpad for note taking:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2014-10-29

/js

> ******* DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE *******
> 
> -----------------------------------------------------------------------
> JOIN USING WebEx
> 
> Go To:
> https://cisco.webex.com/cisco/j.php?MTID=m6ea214f8e097453994e88aa706a7bcad
> 
> Meeting Password ----- 1234
> Meeting Number ----- 201 602 421
> 
> ----------------------------------------------------------------
> ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES
> ----------------------------------------------------------------
> Please dial the local access number for your area from the list below:
> -  San Jose/Milpitas (408) area:  525-6800
> -  RTP (919) area:  392-3330
> 
> Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones).  " If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number." Please use the call-back option whenever possible and otherwise dial local numbers only.  The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.
> 
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> 1. Dial into Cisco WebEx (view all Global Access Numbers at
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.
> 
> San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330
> 
> US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117
> 
> India: +91.80.4350.1111  Germany: +49.619.6773.9002
> 
> Japan: +81.3.5763.9394  China: +86.10.8515.5666
> 
> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Oct 2014 13:19:12 -0700

Hi,

Thanks for running this meeting.
I think we made some progress on conformance.

There is still 1 major detail we have not addressed,
which is changing a status-stmt to 'obsolete' in the
revision of a module supported by the server.

This is why the draft originally had "min-revision" and "max-revision".

In SMIv2 conformance,  a "current" MODULE-COMPLIANCE macro cannot
reference any deprecated or obsolete definitions. Does YANG need
similar guidelines or rules?

So what does it mean if the server uses some modules that reference
external meta-data (or augment an object) that was current when
written, but later changes to obsolete:

Start:

  module A {
     revision 2014-01-01;
     import B { prefix B; revision-date 2014-01-01; }
     leaf broken { type B:t1; }
  }

  module B {
     revision 2014-01-01;
     typedef t1 { type string; }
  }

Later:

  module B {
     revision 2014-10-01;
     typedef t1 { type string; status obsolete; }
     typedef t2 { type int32; }
  }

The vendor want to implement a new module that imports type t2
from the updated module B.

So what happens to a server implementing module A?
Does import-by-revision make any difference?
According to the meeting today, the server must pick 1 revision
of module B to advertise (which must be >= 2014-10-01).
That means the leaf "A:broken" cannot be implemented with its current definition
and module A needs to be updated in order to change module B
in the server.

IMO, the server vendor is responsible for providing a cohesive module set.
This doesn't happen automatically and it is a huge problem for open systems,
but clearly no implemented object can use an obsolete typedef.
The new YANG guidelines draft says a module should stay in "deprecated" status
for at least a year. That just delays this problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Oct 2014 00:32:36 +0100

> for at least a year. That just delays this problem.

As long as you control all your modules, this may be achievable. If
you, however, implement a mix of modules, some under your control and
some not, then I assume you may have a hard time.

Suppose the IETF updates a common module like lets say ietf-yang-types
by adding a new type and deprecating / obsoleting an old type. Lets
further assume that the IETF manages to update all modules that used
the now obsolete type definition - so all IETF modules are fine using
the new version of ietf-yang-types. Lets further assume that some
other organization, say IEEE, uses ietf-yang-types as well in their
modules but they do not update as quickly as the IETF does it in the
future. Your customers now want both IETF and IEEE modules to be
implemented. What do you do?

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Oct 2014 17:04:31 -0700

> implemented. What do you do?

I was going to add to the last email that I don't see any way the IETF can set
a status-stmt in reusable definitions to obsolete. Maybe for objects,
but not typedefs or groupings.

Deprecated just means the definition might go away someday.
Even if we use the old definition of import-by-revision, what does it
mean to honor status=current in ver. 1 and status = obsolete in ver. 2,
at  the same time?

The tree of dependency trees gets complicated very fast.
None of the SNMP server code I worked on supported multiple revisions
of any module in the agent.  There was 1 module loaded for each module name.
SMIv2 has no way to import a specific revision of a definition.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Oct 2014 08:35:32 +0100

> similar guidelines or rules?

In SMIv2, you explicitly declare the set of objects that are required
for a certain compliance level. With YANG, the current idea is that
this can be avoided by having compliance fall out of the modules
themself. This is tricky, in particular when

(a) a device implements modules not under change control of the device
    manufacturer and
(b) a device that allows to plugin data model implementations
    maintained by 3rd parties.

Concerning deprecated and obsolete, there is also a difference between
what a module maintainer wants to see happening and what the real
world is going to do. For example, a bunch of basic SNMP counters
became 'obsolete' in SNMPv2-MIB (RFC 3418 - published ~12 years ago)
and it is likely that your SNMP agents still implements them. Now,
this is monitoring but then updating instrumentation for configuration
is even more effort.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 30 Oct 2014 12:01:59 +0100 (CET)

> some not, then I assume you may have a hard time.

Yes, but consider the alternative.  Suppose we have two versions of a
typedef, one with an expanded range.  We also have a bunch of leafs in
various data models that reference this typedef.  If we also have
something like the proposed mount mechanism (or some subagent
mechanism), then it means that potentially the client somehow needs to
figure out which version of the type is used for every single instance
of these leafs in the *data store*.  I.e., it is not sufficient to say
that a certain module uses a certain revision of a typedef; it can be
different for different data instances as well.

The only (?) 100% safe thing to do would be to never allow any changes
in the value space for a typedef or grouping.  Then we'll see
constructs like this:

   typedef foo { ... }
   typedef foo-v2 { ... }
   typedef foo-v3 { ... }

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 30 Oct 2014 16:57:33 +0100

> different for different data instances as well.

In the case of mount, I think the only reasonable solution is to forward somehow to the client the information about exact versions of modules used for mounted subtrees. Perhaps this could be attached as metadata to each mount point.

The format of capabilities in hello doesn’t scale well for complex data model specifications.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2014 10:00:35 -0700

> The format of capabilities in hello doesn’t scale well for complex data model specifications.

I don't agree that the <hello> message scales are worse than retrieving the
same information with a <get> operation.  I don't understand the value
of replicating all the server data models in a controller (or is it a
glorified cache?),
but that is a different issue.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2014 10:14:12 -0700

> different for different data instances as well.

Consider the possibility that we never really experienced lifecycle
complexity before,
because monitoring is trivial compared to configuration.  The notion that an
application writer can code to a set of fixed modules and that set will never
change over the years is flawed.  It was never achievable in SNMP, but we didn't
really notice because it was 98% monitoring.

The equipment or systems vendor is providing a system, not some random
collection of sub-agents.  It is their responsibility to maintain a
cohesive system
even if that means some code needs to be touched.

> in the value space for a typedef or grouping.  Then we'll see

Sometimes this is the best approach -- I do it all the time in C code,
because it is safer and less work than re-coding and retesting all
the components using the existing definition.

This approach preserves the original API contract until it
is updated manually and intentionally.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2014 10:44:08 -0700

...
> in the value space for a typedef or grouping.  Then we'll see

Let's think about why one would ever change a typedef or grouping.

1) defect:
The definition needs to be corrected.  In this case, we don't want
the old definition used at all. Forcing all modules to upgrade at once
is not unreasonable.

2) enhancement:
New functionality is being added.  It may be OK for existing usage
to continue unchanged.  If so, then a new typedef or grouping is
needed, so the old usage remains valid and represented correctly
in the schema.  If not, then the old functionality is somehow obsolete
and we don't want the old definition used anymore.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 31 Oct 2014 10:16:25 +0100

> I don't agree that the <hello> message scales are worse than retrieving the

It does, because all information has to be packed as URI parameters. I don’t understand the design decision to use URI as the format for capabilities, it could have been a nicely structured XML snippet with content specific for each capability.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Oct 2014 10:21:57 +0100

> It does, because all information has to be packed as URI parameters. I don’t understand the design decision to use URI as the format for capabilities, it could have been a nicely structured XML sni…

The format is not the issue; the issue is that the long <hello> is
unavoidable - you get it whether you need it or not. With a separate
well designed RPC, the client can request things as needed and it
hopefully can cache things.

I do not think a different encoding really makes a lot of a
difference. I think the key is to send the information only when
really needed rather than every time an application connects.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 31 Oct 2014 10:34:45 +0100

> really needed rather than every time an application connects.

Right, but it is also true that URI parameters are not terribly suitable for representing structured information. They are needed in Request-URIs of HTTP methods but it not the case here.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Oct 2014 10:46:41 +0100

> Right, but it is also true that URI parameters are not terribly suitable for representing structured information. They are needed in Request-URIs of HTTP methods but it not the case here.

Lada, we are not re-designing the protocol here. If you want to do
that, please post to the NETCONF mailing list.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 31 Oct 2014 11:04:36 +0100

> that, please post to the NETCONF mailing list.

I just replied to Andy’s claim that hello capabilities are as scalable as retrieving the same information via <get>.

Thank you, Lada