Subject: Re: [core] Editorial fix: "sorely" in draft-ietf-core-yang-cbor

From: Alexander Pelov <[email-masked]>
Date: Fri, 22 Jul 2016 09:31:13 +0200

Hi Sean,

Thanks for catching this.

On the IP address - it is actually an excellent question on how we solve this. The issue is that YANG defines an IPv6 address as a string with a regex pattern :

typedef ipv6-address {
       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(%[\p{N}\p{L}]+)?';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(%.+)?';
       }
}

So, this means that the basic YANG-CBOR machinery converts an IP address to a string… because it is a string. 

I see two options here:
1) Redefine the basic types, e.g. through SID + conversion functions
2) Find some generic RegEx_compatible_string-to-binary way of doing this
3) Define in YANG-CBOR a binary serialization for the types ietf-yang-types/ipv6-address, ietf-yang-types/ipv4-address, ietf-yang-types/date-and-time, ietf-yang-types/mac-address

1) would be pretty straight-forward. We specify a number of serialization/deserialization functions yang_type_TO_cbor_type and vice-versa cbor_type_TO_yang_type :
  - define a couple of useful basic functions (IP + date/time.. not sure other would be necessary for the moment)
  - in the SID file, when allocating a SID, the author of a file can specify serialization/deserialization function. Only standard SID functions should be supported, so a little caution here.

Not sure how the 2) would work.

3) seems the easiest, and least extensible

Of course, the simplest thing is to just do nothing in particular and send IP addresses and dates as strings.

Best,
Alexander

> Le 21 juil. 2016 à 18:47, Sean Leonard <[email-masked]> a écrit :
> 
> Editorial fix:
> For instance, CBOR tags are used sorely in the
>   case of the union datatype to distinguish explicitly the use of
>   different YANG datatypes encoded using the same CBOR major type.
> 
> 
> Should be “solely”.
> 
> Unless you are really sore about it. :)
> 
> Sean
> 
> PS The technical (non-editorial) part of this, is related to this text + the example about IP addresses. Think about that and how to encode IPv4 and IPv6 addresses more efficiently. Maybe a CBOR tag is useful; maybe not. However my view is that two different CBOR tags are not useful; it’s better to distinguish IPv4 vs. IPv6 by the length of the (byte) string.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jul 2016 01:09:20 -0700

On Fri, Jul 22, 2016 at 12:31 AM, Alexander Pelov <[email-masked]> wrote:

> On the IP address - it is actually an excellent question on how we solve
> this. The issue is that YANG defines an IPv6 address as a string with a
> regex pattern :
>
> typedef ipv6-address {
>        type string {

What if the shorthand notation of the IPv6 address is actually shorter than
the expanded binary format?

The WG seems much more comfortable than me wrt/ accepting massive
increases in code complexity  in order to save a few bytes once in awhile.
As it is, the client and server will need in-depth knowledge of all
revisions
of each YANG module -- much more than required for XML or JSON.
Any flaws in this schema knowledge lead directly to interoperability bugs.

Andy

So, this means that the basic YANG-CBOR machinery converts an IP address to
> a string… because it is a string.
>
> I see two options here:
> 3) Define in YANG-CBOR a binary serialization for the types
> ietf-yang-types/ipv6-address, ietf-yang-types/ipv4-address,
> ietf-yang-types/date-and-time, ietf-yang-types/mac-address
>
>
> 1) would be pretty straight-forward. We specify a number of
> serialization/deserialization functions yang_type_TO_cbor_type and
> vice-versa cbor_type_TO_yang_type :
>   - in the SID file, when allocating a SID, the author of a file can
> specify serialization/deserialization function. Only standard SID functions
> should be supported, so a little caution here.
>
> > PS The technical (non-editorial) part of this, is related to this text +
> the example about IP addresses. Think about that and how to encode IPv4 and
> IPv6 addresses more efficiently. Maybe a CBOR tag is useful; maybe not.
> However my view is that two different CBOR tags are not useful; it’s better
> to distinguish IPv4 vs. IPv6 by the length of the (byte) string.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Peter Saint-Andre - Filament <[email-masked]>
Date: Fri, 22 Jul 2016 07:11:33 -0400

On 7/22/16 4:09 AM, Andy Bierman wrote:
>
>
> On Fri, Jul 22, 2016 at 12:31 AM, Alexander Pelov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Sean,
>
>     On the IP address - it is actually an excellent question on how we
>     solve this. The issue is that YANG defines an IPv6 address as a
>     string with a regex pattern :
>
>     typedef ipv6-address {
>            type string {

+1!

Peter

-- 
Peter Saint-Andre
https://filament.com/