Subject: [netmod] equality of keys

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Sep 2008 08:47:47 +0200

Hi,

related to the discussion of edit-config behaviour on lists and
leaf-list is the following question: Is the equality of list keys or
leaf-list items decided in the value or lexical space? The correct
answer is probably "value space" but this could be problematic for types
that do not define what equality in value space means. An example are IP
addresses: how do we know that '::1' is the same as '::0:1' if the
ipv6-address type is defined just using regular expressions?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Sep 2008 09:11:04 +0200

> ipv6-address type is defined just using regular expressions?

There is hopefully a description statement explaining that this is an
IPv6 address. In my view, a pattern augments a description but does
not replace it.

A pattern may allow for multiple lexical representations of the same
value - and perhaps this needs to be spelled out with a recommendation
that in such cases the description clause needs to define what the
canonical representation is and whether conversions are allowed, that
is whether an implementation has to maintain '::0:1' as supplied by
the user or it can convert silently to '::1'. Perhaps this also scares
people away from allowing multiple representations of the same value
in the first place...

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 24 Sep 2008 09:36:51 +0200

In my naive view when you define something as an IPv6 address you don't just mean it conforms 
to a pattern. It really means it is an IPv6 address meaning that if a router would consider two 
addresses equivalent then they are the same (independent of how many zeros are abbreviated). So 
for me you don't even need a description, just by saying

type inet:ipv6address;

you sad it all.

I strongly believe that the equality must be in the value space. The node might not even know 
which exact lexical format the address was in in Netconf. Comparing in the lexical space would 
force the node to store the string format of the IPv6 address as well, additional hassle.

Imagine an IPv4 address that can be configured as a patterned string on Netconf, but on another 
interface as a simple int32. Comparing in the lexical space could mean that a value set as an 
int32 would never be equal to anything on Netconf.

Comparing in lexical space would mean that 1.0 and 1.00 are different numbers.

What problems do you foresee with comparing in value space?
Do we need something about this in the draft? Maybe one general statement valid for all data types?

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Sep 2008 09:54:00 +0200

> people away from allowing multiple representations of the same value

Since YANG modules may potentially use many specific datatypes, wouldn't
it make sense to consider implementing a better datatype system in YANG?
Perhaps something similar to DTLL:
http://www.idealliance.org/papers/extreme/proceedings/html/2006/Tennison01/EML2006Tennison01.html

DTLL handles the value space equality, but also ordering of values etc.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Sep 2008 10:11:05 +0200

I would add to this that relying on text in the description clauses
means duplication and a possible source of errors. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
> Sent: Wednesday, September 24, 2008 10:37 AM
> To: Ladislav Lhotka; NETMOD Working Group
> Subject: Re: [netmod] equality of keys
> 
> In my naive view when you define something as an IPv6 address 
> you don't just mean it conforms to a pattern. It really means 
> it is an IPv6 address meaning that if a router would consider 
> two addresses equivalent then they are the same (independent 
> of how many zeros are abbreviated). So for me you don't even 
> need a description, just by saying
> 
> type inet:ipv6address;
> 
> you sad it all.
> 
> I strongly believe that the equality must be in the value 
> space. The node might not even know which exact lexical 
> format the address was in in Netconf. Comparing in the 
> lexical space would force the node to store the string format 
> of the IPv6 address as well, additional hassle.
> 
> Imagine an IPv4 address that can be configured as a patterned 
> string on Netconf, but on another interface as a simple 
> int32. Comparing in the lexical space could mean that a value 
> set as an
> Do we need something about this in the draft? Maybe one 
> general statement valid for all data types?
> 
> Balazs
> 
> >> answer is probably "value space" but this could be problematic for 
> >> types that do not define what equality in value space means. An 
> >> example are IP

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Sep 2008 10:19:22 +0200

> for me you don't even need a description, just by saying

If it was so, the 'typedef ipv6-address' could contain only the
description statement saying that it is an IPv6 address. I believe a
formal specification is important, especially for new types that are not
so ubiquitous as IP addresses.
 
> Comparing in lexical space would mean that 1.0 and 1.00 are different numbers.

This is a built-in type, so equality in value space is well-defined for
it. It is a problem of derived types defined by YANG, such as IP
addresses, date-and-time, counter etc.

> What problems do you foresee with comparing in value space?

That the concepts of equality and ordering in the value space and
multiple representations can be addressed only in descriptions.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Sep 2008 11:49:33 +0200

On Wed, Sep 24, 2008 at 09:36:51AM +0200, Balazs Lengyel wrote:

> So for me you don't even need a description, just by saying
>
> type inet:ipv6address;
>
> you sad it all.

Yes, but the definition of inet:ipv6address should still say that it
is an IPv6 address.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Sep 2008 11:58:10 +0200

On Wed, Sep 24, 2008 at 09:54:00AM +0200, Ladislav Lhotka wrote:
 
> Since YANG modules may potentially use many specific datatypes,
> wouldn't it make sense to consider implementing a better datatype
> system in YANG?

Write up a concrete proposal and convince the working group that (a)
there is a problem worth to be solved and (b) that the proposal is an
appropriate solution for the problem worth to solve.

Until this is done, I suggest we continue with what we have on the
table and experience with.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 24 Sep 2008 12:41:21 +0200

> Yes, but the definition of inet:ipv6address should still say that it
Agreed. Also for datatypes that are not so well defined in external documents, longer 
descriptions will still be needed.

Balazs

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Sep 2008 09:42:01 -0700

Hi -

> From: "Balazs Lengyel" <[email-masked]>
> To: "Ladislav Lhotka" <[email-masked]>; "NETMOD Working Group" <[email-masked]>
> Sent: Wednesday, September 24, 2008 12:36 AM
...
> Do we need something about this in the draft? Maybe one general statement valid for all data types?
...

This may or may not be a consideration in the netconf architecture, but
I think a historical reminder might be in order here.

CMIP did comparisons in what is here being called the "value space"
rather than the "lexical space."  SNMP comparisons are in clearly
in the lexical space.  This is one of the things SNMP got right, in
my opinion.  The reason becomes clear if you consider the mechanics
of master/subagent implementation.  Using the "value space" requires
that the master be able to dynamically acquire whatever the ad hoc
comparison rules for a particular bit of information might happen to be.
This is not just of concern for operation dispatch, but also for access
control.  The problem isn't as bad as it *could* be because this is
really only necessary for distinguishing attributes (scoping), since
(CMIP) filtering can be delegated to subagents without any loss
of efficiency.  Of course, for this to work the wire format needs to
have been canonicalized, which only really makes sense if it's a
machine-to-machine protocol rather than something that humans
are intended to be typing in by hand.

Again, I don't know whether these issues are of any relevance to netconf,
but they *did* make a big difference in CMIP / SNMP implementation.

Randy

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Fri, 26 Sep 2008 09:17:15 +0800

Hi, 
> multiple representations can be addressed only in descriptions.
why say "only in descriptions"? does it mean it is only a implementation thing?

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 26 Sep 2008 09:39:18 +0200

> why say "only in descriptions"? does it mean it is only a implementation thing?

Yes, implementors have to read these verbal descriptions and write the
code accordingly. This information is not accessible to future generic
YANG validators and the DSDL mapping will translate it only to
documentation annotations as well.

Lada
 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C