Subject: [netmod] conformance

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 02 Mar 2015 11:22:08 +0100

Hi,

I have two questions/comments regarding conformance as discussed in
Andy's and Martin's drafts:

1. Value set for identityrefs

   RFC 6020 says in sec. 9.10.2: "On a particular server, the valid
   values are further restricted to the set of identities defined in the
   modules supported by the server."

   I think "modules supported by the server" is unclear. So far, I've
   assumed that it means "modules *advertised* by the server" - this was
   also the conclusion of a discussion back in 2009, see Martin's mail

   http://www.ietf.org/mail-archive/web/netmod/current/msg02761.html

--------------------------------------------------------------------
 > - Sec. 9.10.5:
 >   * Since module "des" is not imported, how can an
 >     implementation know that such a module exists and defines the
 >     "des3" identity?

 des:des3 will only be valid on the device if the device implements
 (and adertises) the des module.
--------------------------------------------------------------------

   If it is so, then the set of permitted values of any identityref is
   IMO precisely defined and there is no ambiguity.

2. Revision hell

   Would it help if the revision of the module that's imported without
   revision is determined from the revision of the importing module?
   That is, it will be the highest revision of the imported module
   that's less or equal to the revision of the importing module.

   For example, if we have

   - module A, revision 2014-01-01
   - module A, revision 2014-02-01
   - module B, revision 2014-01-02

   and module B imports A without specifying a revision, then all A:*
   typedefs and groupings used in module B have to be taken from
   revision 2014-01-01 of module A, even if the server advertises the
   new revision 2014-02-01 of A. This would avoid the ripple effect.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Mar 2015 13:41:22 +0100 (CET)

>    http://www.ietf.org/mail-archive/web/netmod/current/msg02761.html

Agreed.

>    new revision 2014-02-01 of A. This would avoid the ripple effect.

This gives the same problems as if explicit import-by revision was used
everywhere.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 2 Mar 2015 14:05:29 +0100

> On 02 Mar 2015, at 13:41, Martin Bjorklund <[email-masked]> wrote:
> 

In the minutes of the last interim telco I read:

  MB: P2 is showing that import-by-revision can lead to unresolvable
      conflicts requiring import updates (revision update ripple problem)

However, I really don't see any unresolvable conflict, provided the server only advertises modules whose nodes and identities it implements (which is how I understand the current rules). Revisions of imported modules will be controlled exclusively by importing modules, either by specifying revision-date or by my rule.

What’s wrong with this? There are no ripple effects, as far as I can tell.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Mar 2015 05:48:46 -0800

>>    IMO precisely defined and there is no ambiguity.

IMO this does not work because designers put many identities together
in the same module that are not intended to all be implemented
by every device.

Let's say we have a super simple device with 1 ethernet port.

1) Does the server advertise iana-if-type?
1a) If so, is the server supposed to implement every identity
  in iana-if-type.yang (of course not)
1b) If the iana-if-type.yang module is not advertised then how
  does the client know where the 'ethernet' identity came from?

I am not convinced the module-based conformance mechanisms
are worth fixing.  We can claim they are generally useful.
It is useful to know the module name and revision dates
from all the modules and submodules.  The ietf-yang-library
module does that.

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 2 Mar 2015 14:52:20 +0100

> On 02 Mar 2015, at 14:48, Andy Bierman <[email-masked]> wrote:
> 

FWIW, I have repeatedly objected against the design of iana-if-type, exactly because of these reasons. If the ‘ethernet’ identity was defined in the same module where Ethernet data nodes are defined, this problem wouldn’t exist.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Mar 2015 16:45:22 +0100 (CET)

> in the same module that are not intended to all be implemented

Yes, this is why your get-allowed-identities rpc is needed.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 2 Mar 2015 17:06:05 +0100

> On 02 Mar 2015, at 16:45, Martin Bjorklund <[email-masked]> wrote:
> 

I don’t agree, it isn't needed at all if identities are defined in a distributed way as they should be, and not in an enumeration-like mode.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Mar 2015 08:14:29 -0800

> I don’t agree, it isn't needed at all if identities are defined in a distributed way as they should be, and not in an enumeration-like mode.

This would mean that each identity would need to be in its own YANG module
so it could be advertised by the server.  Not a workable solution.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Mar 2015 11:53:11 -0500

>so it could be advertised by the server.  Not a workable solution.

Worse than that, isn't it?  How would I know that a particular
identity is allowed in one leaf but not allowed in another?  My
server might support a new identity for a new knob, but not for
an older one.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Mar 2015 09:52:03 -0800

> server might support a new identity for a new knob, but not for

That's why I think a run-time RPC is needed.
We are making some progress just by realizing the
limitations of schema-based conformance mechanisms.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Mar 2015 10:52:27 +0100

> server might support a new identity for a new knob, but not for

But you can have the same problem for an enumeration or even for a type
like inet:ip-address, right? In fact, identities are more flexible in
this respect.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 04 Mar 2015 18:22:27 +0100

> This gives the same problems as if explicit import-by revision was used

After the interim discussion it seems to me there are actually two problems here:

1. If module B imports A without revision, we have to avoid the
   situation that an old revision of B is used with groupings and
   typedefs from a new revision of A that the author od B didn't intend
   to use. This problem is IMO easily solved by fixing the revision that
   is used when no revision is specified in the import statement:

   OLD

   If no "revision-date" substatement is present, it is undefined from
   which revision of the module they are taken.

   NEW

   If no "revision-date" substatement is present, they are taken from
   the most recent revision that preceded the revision of the importing
   module.

2. Module B wants to use definitions from two revisions of A at the same
   time. This would require a new concept of modularity, so I don't
   think it can be solved in 1.1. A reasonable workaround for the author of
   B is to import the old version of A and copy-and-paste needed
   definitions from the new version of A.

Lada