Subject: [netmod] yang-03, sec. 9.9, leafref

From: andy <[email-masked]>
Date: Thu, 05 Feb 2009 09:49:49 -0800

Hi,

sec. 9.9:

   The leafref type is used to reference a particular leaf instance in
   the data tree.  Its value is constrained to be the same as the value
   of an existing leaf.

   If the leaf with the leafref type represents configuration data, and
   the "require-instance" property (Section 9.9.3) is "true", the leaf
   it refers to MUST also represent configuration.  Such a leaf puts a
   constraint on valid data.  All leafref nodes MUST reference existing
   leaf instances for the data to be valid.  This constraint is enforced
   according to the rules in Section 8.

The require-instance section (9.9.3) does not really
address leafref issues.

   The "require-instance" statement, which is a substatement to the
   "type" statement, MAY be present if the type is "leafref" or
   "instance-identifier".  It takes as an argument the string "true" or
   "false".  If this statement is not present, it defaults to "true".

   If "require-instance" is "true", it means that the instance being
   referred MUST exist for the data to be valid.  This constraint is
   enforced according to the rules in Section 8.

I object to the current 9.9, para 2 text.
The require-instance flag should not have anything
to do with config = true/false.  The agreement I think
was reached at the last IETF was :

   If require-instance is true for a leafref, then the value set (determined
   by the path-stmt) is restricted to existing instance values.

  If require-instance=false, then a leafref is constrained by
  the type or typedef associated with the object indicated by the path-stmt.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Feb 2009 21:07:02 +0100 (CET)

>    by the path-stmt) is restricted to existing instance values.

Yes, but w/o this rule you might have a pointer from config data to
state data, and there is no guarantee that the state data does not
change.  If the state instance is removed by the system, you would
have a dangling 'require-instance' pointer in the config, which makes
the config invalid!

If you need a pointer from config to state data, require-instance must
be set to false.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Feb 2009 13:19:26 -0800

> If you need a pointer from config to state data, require-instance must

The YANG draft states in several places that
config=false is not even part of the database.
I do not see how sometimes it is part of the database,
and other times it isn't.  Very confusing.
If it is not part of the datbase, then why do
we even allow must/when on config=false?
It is not very important to support that IMO.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Feb 2009 22:38:04 +0100 (CET)

> config=false is not even part of the database.

Right.

> and other times it isn't.  Very confusing.

When is config false part of the database?

> It is not very important to support that IMO.

Well, I agree with you that it's not very important, but this was the
consensus from the interim, and there's also a ML thread called
"Proposed consensus mail on yang-00172".

/martin