Subject: [netmod] undecided Y09 introduce optional keys

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jun 2014 10:14:33 +0200

We need to decide whether this is in scope of YANG 1.1 or not.

The implications of this seem to be somewhat unclear. Does this only
work if there are defaults or the leaf is initialized by system?

/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: Mon, 2 Jun 2014 08:31:47 -0700

> work if there are defaults or the leaf is initialized by system?

This issue states that the problem to be solved is removal of a
redundant leaf in a list entry.  If the key leaf has a YANG default
then it can be used instead (just like a non-key leaf).

The creation of 1 list entry (per optional key) is optimized by solving
this problem.  IMO that is not enough benefit to make this change.
This change would also break YANG 1.0 because a YANG 1.0 client
sending an <edit-config> with a missing key expects to get an error, not
<ok>.

Issue Y09 should be rejected.

/js

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Jun 2014 08:25:04 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> > work if there are defaults

No, it would work also if the key leaf does not have a default.

> or the leaf is initialized by system?

I think that if we do Y12, initialized-by system would apply to
non-key leafs only.  Otherwise the client can't tell which value the
server used w/o reading the entire list.  (hmm, maybe not...)

> then it can be used instead (just like a non-key leaf).

You mean the client needs to provide the default value?

This is less user-friendly, and more error prone, since the operator
(e.g., CLI user) must remember the correct default and type it in.

> this problem.  IMO that is not enough benefit to make this change.

This assumes that there is a value to use for the optional key.  It's
not very elegant to have to put in some otherwise illegal value just
to work around this apparent limitation.  For example:

  list server {
    key "ip port";
    leaf ip {
      type inet:ip-address;
    }
    leaf port {
      type union {
        type int8 {
          range "-1";
        }
        type inet:port-number;
      }
      description
        "Use -1 to indicate that the port really is not set.";
    }
    ...
  }
    
> sending an <edit-config> with a missing key expects to get an error, not

I disagree with this interpretation of backwards incompatibility.  If
all old clients must work with *new* modules, we can't do almost any
changes at all.

> Issue Y09 should be rejected.

I think this issue needs more discussion.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2014 08:50:10 +0200

> No, it would work also if the key leaf does not have a default.

But which value is then used? You seem to assume there is no value at
all. What would be a good example for this? A configured service with
an arbitrary port number seems somewhat strange to me - hence I am
looking for a better example.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Jun 2014 09:02:02 +0200 (CEST)

> looking for a better example.

Recently there was the discussion about vrfs.  Something like this:

  key "ip port vrf";

where vrf would be an optional key.

Another use case is for extending models.  Maybe you start with:

  key "ip port";

and later you add the vrf concept.  Adding an optional key would be a
nice way to extend this model.  Currently we have to use an arbitrary
key to handle this extensibilty problem.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Jun 2014 02:15:16 -0700

> where vrf would be an optional key.

So the list would have either 2 keys or 3 keys, depending on what the
client decides to provide.  It isn't that the server picks the default value
or even some ad-hoc value unknown to the client.

IMO variable number of keys is too complicated.
It is better to keep YANG list naming stable.

> key to handle this extensibilty problem.

Add a new list if the number of keys changes over time.
Use leafref for the keys being duplicated.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Jun 2014 11:54:57 +0200 (CEST)

> IMO variable number of keys is too complicated.

In what way is this complicated?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Jun 2014 13:50:02 +0200

> server used w/o reading the entire list.  (hmm, maybe not...)

Well, in the case of user database, the key is often the (system generated) uid.

> all old clients must work with *new* modules, we can't do almost any

+1. The backward compatibility requirement for 1.1 states that old modules must not become invalid, and this is satisfied here.

> I think this issue needs more discussion.

Yes, and I think it should therefore be OPENed.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Jun 2014 07:13:46 -0700

> In what way is this complicated?
This creates multiple ways for a list entry to be named.
I think it is much simpler if all list entries of the same object
have the same number of key components.

Can I rename an entry by adding or deleting keys after it is created?
This adds complexity.

IMO it is better to only have lists that use the same naming.
This corner case should be rare enough that simply picking a special value
for the keys that can mean "applies to all entries".

SQL seems to allow NULL foreign keys but not inline keys, so
this change would not be compatible with an implementation that
converts YANG to SQL.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jun 2014 21:29:36 +0200

> where vrf would be an optional key.

But for this example, I would argue that there is again a default. If
you send something without a vrf leaf, the system will pick a default
vrf, no?

> key to handle this extensibilty problem.

Yes, we have to design for extensibility. While optional keys may help
in certain situations, we likely still need to design for extensibility.

You can find many discussions of the pros and cons of natural keys
vs. artificial keys on the Internet. (I personally probably lean a bit
towards the artificial keys camp since if used wisely, they can help
to decouple things and hence I find arbitrary keys probably not such a
bad idea.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:18:42 +0200

> work if there are defaults or the leaf is initialized by system?

Interim proposal:

  Proposal: Move this to open for now. Some concerns from KW and
  AB. We might revisit this issue later if the complexity/cost of a
  solution is too high. Action item for MB to provide a detailed
  solution proposal.

If you disagree, please speak up by June 18th.

/js