Ladislav Lhotka <lhotka@xxxxxx> wrote: > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund wrote: > > Hi, > > > > Ladislav Lhotka <lhotka@xxxxxx> wrote: > > > Hi Acee, > > > > > > > > > > please see inline. > > > > > > > > > > On Mon, 2018-01-08 at 19:28 +0000, Acee Lindem (acee) wrote: > > > > > > Hi Lada, > > > > > > > > > > > > Apologies for the delay. We somewhat got hung up on 4 and 6. See inline. > > > > > > > > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lhotka@xxxxxx> wrote: > > > > > > > > > > > > > Reviewer: Ladislav Lhotka > > > > > > > Review result: Ready with Issues > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > 3. Maybe the draft could mention that implementations should supply a > > > > > > > default routing domain as a system-controlled resource. > > > > > > > > > > > > Isn’t this more of an RFC8022BIS statement? I guess we could state this as > > > > > > an assumption. > > > > > > > > > > Probably, but it is not a YANG issue, so I'd leave it to you routing folks > > to > > > > > decide. > > > > > > > > > > > > > > > > > > > > > > > > 4. In "when" expressions, the module uses literal strings for > > > > > > > identities. This is known to be problematic, the XPath functions > > > > > > > derived-from() or derived-from-or-self() should be used instead. > > > > > > > > > > > > Why is this problematic? Is it because the types can be extended? > > > > > > > > > > That's one reason: derived identities should often also satisfy the > > constraint. > > > > > > > > > > But the more serious problem is that things like > > > > > > > > > > when "../../../../../../../rt:type = 'ospf:ospfv3'" > > > > > > > > > > rely on plain string comparison that depends od the actual prefix used for > > the > > > > > "rt:type" value. For one, according to RFC 7951 the JSON encoding of this > > value > > > > > would be "ietf-ospf:ospfv3" so the above expression is always false. > > > > > > This is not correct; the when expression is not evaluated on the JSON > > encoding. See the last paragraph of section 9.10.3 in RFC 7950: > > > > The string value of a node of type "identityref" in a "must" or > > "when" XPath expression is the referred identity's qualified name > > with the prefix present. If the referred identity is defined in an > > imported module, the prefix in the string value is the prefix defined > > in the corresponding "import" statement. Otherwise, the prefix in > > the string value is the prefix for the current module. > > This is weird, to say the least. The leafref instance may have an identity value > that is defined in a module that (has to be implemented by the server but) > needn't be imported in the module that contains the XPath expression. So I don't > know what 'corresponding "import" statement' this paragraph is talking about. It has to import the module in order to give a prefix, which then can be used in the XPath expression. > Also, potentially there can be a collision in prefixes and then this also breaks > down. No, two modules cannot be imported with the same prefix. > A moral of the namespace/prefix story in XML was that relying of namespace > prefixes having a particular value is a really bad idea. I know that the cited > paragraph was intended to make such XPath string comparisons more deterministic, > but it is also problematic and should be avoided if possible. Note that this prefix is under the control of the module designer writing the XPath expression. The same identityref value might use a different prefix in some other module. /martin > > Lada > > > > > So the equality test of the identityref is correct. > > > > However, I agree that in most cases 'derived-from-or-self' should be > > used, in order to handle derived identities. > > > > > > /martin > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >