Subject: [netmod] Constraining instance-identifiers

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jan 2016 15:56:13 +0100

Hello,
We have some instance identifiers in our model but we want to contrain 
what they can point at. What is the best method for that?
- the referenced object can be in 3 different locations in the tree
- the referenced object is contained by lists, so we must be able to 
match any key values (e.g. need a wildcard)
- designers don't want to use leafrefs for internal reasons, and because 
we need the full XPath pointing to the object in the reference leaf

I wanted to do:

leaf pointer-to-thing {
     type instance-identifier {
         require-instance false;
     }
     must match (current(), regular-expression)
}

Some issues:
- instance-identifiers don't have a canonical format, so what is their 
value in an XPath expression?
- I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
- if I have all the needed namespace prefixes in imports, can I just use 
them?

Any ideas? Thanks for any help.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 21 Jan 2016 16:17:33 +0100 (CET)

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> We have some instance identifiers in our model but we want to
> contrain what they can point at. What is the best method for that?

Unfortunately, there is no standard way of doing this.  (There are
vendor extensions available...)

[...]

> Some issues:
> - instance-identifiers don't have a canonical format, so what is
> their value in an XPath expression?

This is not defined.

> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?

In YANG 1.1, there is a function re-match() for this purpose.  For
your use case, it *may* work to match just the local names of all
nodes, i.e., using wildcards for the prefixes.  It is not a generic
solution though.

> - if I have all the needed namespace prefixes in imports, can I just
>   use them?

No, these prefixes are local to the module that is doing the import,
and they may or may not match the prefixes used by the implementation
when it construct the instance-identifier value.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jan 2016 17:51:05 +0100

Hello Martin,
If the RFC would define that in XPath expressions an instance identifier 
MUST be evaluated to a string that complies to the lexical format, using 
the rematch function, we could do everything we need. In real life 
prefix clashes are a rare problem.
regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Jan 2016 09:53:17 -0800

Hi,

There is no need to change the XML encoding or YANG encoding
of an instance-identifier.  The prefixes are completely different
in each.  Prefixes clashes do happen, especially since
there is no expectation that they are unique.  They are short strings
with no naming conventions at all.  E.g., I have seen "if" for
interfaces in multiple modules.

Andy

On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <[email-masked]
> wrote:

> the rematch function, we could do everything we need. In real life prefix
> clashes are a rare problem.
> regards Balazs
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jan 2016 09:27:04 +0100

Hello,

I agree we don't need to change the encoding, but we need to define
how that encoding is visible/available when evaluating Xpath
expressions. Today the draft says:

- instance-identifier does not have a canonical format

- XPath uses the canonical format

The two together make it impossible to use it in Xpath, even though
there are people that would like to do that.

- Martin mentioned a proprietary extension

- we would like it.

So I would propose to

---- change to 9.1

Old: In particular, any XPath expression evaluations are done using the canonical form.

New:  In particular, whenever a canonical form exists, any XPath
expression evaluations are done using the canonical form.

--- add to 9.13.2

For instance-identifiers XPath expression evaluations are done using the lexical form.

regards Balazs

On 2016-01-21 18:53, Andy Bierman
wrote:

Hi,

There is no need to change the XML encoding or YANG
encoding

of an instance-identifier.  The prefixes are completely
different

there is no expectation that they are unique.  They are
short strings

with no naming conventions at all.  E.g., I have seen "if"
for

Andy

On Thu, Jan 21, 2016 at 8:51 AM,
Balazs Lengyel <[email-masked]>
wrote:

Hello
Martin,

If the RFC would define that in XPath expressions an
instance identifier MUST be evaluated to a string that
complies to the lexical format, using the rematch
function, we could do everything we need. In real life
prefix clashes are a rare problem.

regards Balazs

Balazs Lengyel <[email-masked]>
wrote:

Hello,

We have some instance identifiers in our model but
we want to

contrain what they can point at. What is the best
method for that?

Unfortunately, there is no standard way of doing
this.  (There are

[...]

Some issues:

- instance-identifiers don't have a canonical
format, so what is

This is not defined.

- I didn't find a way to evaluate a regexp in XPath
1.0. Is there a way?

In YANG 1.1, there is a function re-match() for this
purpose.  For

your use case, it *may* work to match just the local
names of all

nodes, i.e., using wildcards for the prefixes.  It is
not a generic

solution though.

- if I have all the needed namespace prefixes in
imports, can I just

use them?

No, these prefixes are local to the module that is
doing the import,

and they may or may not match the prefixes used by the
implementation

/martin

--

Balazs Lengyel                       Ericsson
Hungary Ltd.

Senior Specialist

ECN: 831 7320

netmod mailing list

[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Jan 2016 09:56:46 +0100 (CET)

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> I agree we don't need to change the encoding, but we need to define how that
> encoding is visible/available when evaluating Xpath expressions. Today the draft
> says:
>   XPath uses the canonical format
> The two together make it impossible to use it in Xpath, even though there are
> people that would like to do that.
>   we would like it.
> New:  In particular, whenever a canonical form exists, any XPath expression
> evaluations are done using the canonical form.

How about:

NEW:

  In particular, any XPath expression evaluations are done using the
  canonical form, if the data type has a canonical form.  If the data
  type does not have a canonical form, the format of the value MUST
  match the data type's lexical representation, but the exact format
  is implementation dependent.

/martin

> On 2016-01-21 18:53, Andy Bierman wrote:
> 
> > 
> 
> > 
> Hi,
> > 
> 
> > 
> 
> >

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jan 2016 11:29:52 +0100

Good for me. I agree.

Practically it allows me to use rematch() to control the name of the 
lists/containers/leafs appearing in an instance identifier.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jan 2016 04:14:37 -0800

Hi,

I am strongly against adding more features to YANG 1.1 at this time.
The deadline for new features has long passed.

Andy

On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <
[email-masked]> wrote:

> Hello,
> I agree we don't need to change the encoding, but we need to define how
> that encoding is visible/available when evaluating Xpath expressions. Today
> the draft says:
> The two together make it impossible to use it in Xpath, even though there
> are people that would like to do that.
> On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <
> <[email-masked]>[email-masked]> wrote:
>
>> Hello Martin,
>> Mobile: +36-70-330-7909              email: <[email-masked]>
>> [email-masked]
>>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jan 2016 13:33:36 +0100

Hello,

This is a clarification not a new feature. I am 100%  sure all
implementations already support the lexical representation of
instance-identifiers, otherwise they would not be able to read and
write them.

For new features I agree it is too late.

regards Balazs

On 2016-01-22 13:14, Andy Bierman
wrote:

Hi,

I am strongly against adding more features to YANG 1.1 at
this time.

Andy

On Fri, Jan 22, 2016 at 12:27 AM,
Balazs Lengyel <[email-masked]>
wrote:

Hello,

I agree we don't need to change the encoding, but we need
to define how that encoding is visible/available when
evaluating Xpath expressions. Today the draft says:

The two together make it impossible to use it in Xpath,
even though there are people that would like to do that.

- we would like it.

So I would propose to

---- change to 9.1

New:  In particular, whenever a canonical form exists, any
XPath expression evaluations are done using the canonical
form.

--- add to 9.13.2

regards Balazs

Hi,

There is no need to change the XML encoding or
YANG encoding

of an instance-identifier.  The prefixes are
completely different

in each.  Prefixes clashes do happen, especially
since

there is no expectation that they are unique.
They are short strings

with no naming conventions at all.  E.g., I have
seen "if" for

Andy

On Thu, Jan 21, 2016 at
8:51 AM, Balazs Lengyel <[email-masked]>
wrote:

Hello Martin,

If the RFC would define that in XPath
expressions an instance identifier MUST be
evaluated to a string that complies to the
lexical format, using the rematch function, we
could do everything we need. In real life
prefix clashes are a rare problem.

regards Balazs

Balazs Lengyel
<[email-masked]>

wrote:

Hello,

We have some instance identifiers in our
model but we want to

contrain what they can point at. What is
the best method for that?

Unfortunately, there is no standard way of
doing this.  (There are

[...]

Some issues:

- instance-identifiers don't have a
canonical format, so what is

This is not defined.

- I didn't
find a way to evaluate a regexp in XPath
1.0. Is there a way?

In YANG 1.1, there is a function re-match()
for this purpose.  For

your use case, it *may* work to match just
the local names of all

nodes, i.e., using wildcards for the
prefixes.  It is not a generic

solution though.

- if I have
all the needed namespace prefixes in
imports, can I just

use them?

No, these prefixes are local to the module
that is doing the import,

and they may or may not match the prefixes
used by the implementation

when it construct the instance-identifier
value.

/martin

--

Balazs Lengyel
Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320

Mobile: +36-70-330-7909
email: [email-masked]

netmod mailing list

[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Jan 2016 14:00:10 +0100 (CET)

Hi,

> I am strongly against adding more features to YANG 1.1 at this time.

Do you refer to the proprietary extension to restrict i-is?  If so, I
agree (and Balazs just did in a separate email as well) that this is
out of scope.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jan 2016 08:35:41 -0800

> agree (and Balazs just did in a separate email as well) that this is
How would such an extension work, given that a tool MAY ignore
this extension? A plain client thinks the instance-identifier can
hold any valid instance, and is surprised that valid values are rejected by
the server (which don't match the magic extension rules)

Use XPath to further restrict the instance, so a plain client can see it.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Jan 2016 19:42:07 +0100 (CET)

> the server (which don't match the magic extension rules)

The additional validation rule is (hopefully) specified in the
description.  The extension just tells the implementation to do the
validation automatically; the alternative is for the user to write
custom code.

> Use XPath to further restrict the instance, so a plain client can see it.

How?  (note how Balazs' "hack" uses a normal "must" statement).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jan 2016 11:18:22 -0800

Hi,

The description-stmt is good enough.
Let's stop the feature-creep and get YANG 1.1 done.
Just keep using your proprietary extensions that tells
your proprietary tools how to special process the i-i value.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Jan 2016 16:48:04 +0100

> interfaces in multiple modules.

I agree. We should make clear that prefixes should NEVER be hardcoded.

Lada

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