[netmod] minutes from Wednesday's YANG Next meeting

[Kent Watsen]

Attendees:

  - Martin Bjorklund
  - Mahesh Jethanandani
  - Balazs Lengyel
  - Reshad Rahman
  - Xufeng Lu
  - Juergen Schoenwaelder
  - Kent Watsen
  - Robert Wilton
  - Qin Wu

We quickly scored four new issues, and then spent remaining time placing issues 
into four categories:

  - Definitely Dos (MUST Solve)
  - Further Discuss
  - If Time/Energy Left
  - Not Now

We are using a GitHub "Project" to help with this part of the analysis:
- https://github.com/netmod-wg/yang-next/projects/2 



Cheers,
Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang next issue #46 binary encoding support

[Mahesh Jethanandani]

Based on this discussion, I think we should reopen and change the title of this 
issue as “binary encoding in YANG support”, while I open a new issue in 
netconf-next for “support for binary encoding in NETCONF”.

> On Mar 29, 2019, at 11:57 AM, Andy Bierman  wrote:
> 
> 
> 
> On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder 
>  > wrote:
> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de 
> > > wrote:
> > 
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de 
> > > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. I have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type binary {
> > > length 4; }. Doing this is only meaningful for some types but it would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow modelers to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to be
> > > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, so it it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding and how 
> > > > the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > https://tools.ietf..org/html/draft-mahesh-netconf-binary-encoding-01 
> > > > 
> > > >
> > > > For every type T that they agree on, there are standard T.b2y() and
> > > T.y2b()
> > > > conversion functions.
> > > > There are also some extensions to define conversion templates so vendors
> > > > can add their own types.
> > > >
> > > > The YANG modules do not need to actually be altered.  The peers will
> > > > negotiate the
> > > > set of types that will be sent as binary when the session starts.
> > > > The receiver knows T and the SID for each object, and will accept either
> > > > the YANG or binary encoding.
> > >
> > > Sounds complex for me to negotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length 16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a binary
> > type.
> >
> > This forces all implementations of that type to support the binary variant.
> > That breaks old clients that worked with the version before the binary
> > variant.
> > 
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> > 
> 
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
> 
>  typedef ipv4-address {
>

Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting

[Mahesh Jethanandani]

> On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:
>> 
>> The combination of these bullet items, and maybe other bullet items does not 
>> make clear if there was any consensus in allowing (or maybe even preventing) 
>> vendors from using a versioning system to keep track of NBC changes on other 
>> (non-latest) branches of the model. I think I heard from multiple vendors 
>> (outside of this meeting) that making NBC changes was needed on the 
>> non-latest branches, whatever IETF or other SDOs decide. Has that sentiment 
>> changed?
>> 
>> If it is the case, the split between the requirements of SDO and the vendors 
>> is inevitable.
>> 
> 
> If there is a solution that can handle multiple branches, then the
> same solution should work for SDOs that choose to use only a single
> branch. I do not see why a split is inevitable.

If a single solution works for both SDO and the vendor, that is great. And I 
think that was the point of the third bullet in the list I send.

But that does mean the requirements of SDO and the vendor community cannot be 
different. There is a strong requirement that SDOs make NBC changes only on the 
most recent version of the YANG models. In the vendor community, NBC changes 
are going to be made on non-latest branches also.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

Mahesh Jethanandani
mjethanand...@gmail.com



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang next issue #46 binary encoding support

[Andy Bierman]

On Fri, Mar 29, 2019 at 11:46 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > > j.schoenwael...@jacobs-university.de> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > this is issue is closed but I wonder whether this is correct. I
> have
> > > > > several questions looking at the issue on github:
> > > > >
> > > > > - Why is this not a YANG issue?
> > > > > - Which workaround is better?
> > > > > - Why is this tagged as a NETCONF issue?
> > > > >
> > > > >
> > > > Did you mean this should be NETCONF issue?
> > > > It is more of a protocol problem then a modeling problem.
> > > > The goal is to use the model unaltered.
> > >
> > > I think it would be valuable if say the definition of ipv4-address
> > > could state that a canonical binary representation is of type binary {
> > > length 4; }. Doing this is only meaningful for some types but it would
> > > allow to add more binary representations over time.
> > >
> > > > > If we want to support binary encodings, we need to allow modelers
> to
> > > > > define which types map to a canonical binary representation in
> > > > > addition to the canonical string representation. As stated in the
> > > > > issue description, hard-wiring some types in the encoding
> > > > > specifications is very limited.
> > > > >
> > > > > In terms of backwards compatibility, this issue should IMHO be
> tagged
> > > > > high (adding binary encoding for some types does not cause any
> > > > > backwards compatibility problem since so far we have only strings).
> > > > >
> > > > >
> > > > Not so sure.
> > > > The base64 encoding could look like a valid string.
> > > > The receiver must know a binary type is being sent (XML and JSON both
> > > fail
> > > > here, but not CBOR).
> > >
> > > I am talking about CBOR, not about XML or JSON. I want to provide
> > > hints to CBOR (or similar binary encodings) that values can be
> > > represented in a different format. I do not expect these hints to be
> > > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > > instead of JSON.
> > >
> > > > > While I do not have a solution proposal, I think this issue is
> worth
> > > > > to look at and we should not close it right now.
> > > > >
> > > > >
> > > > I have a solution proposal, but I have not implemented it yet, so it
> it
> > > not
> > > > detailed...
> > > >
> > > > Both sender and receiver need to agree on the binary encoding and
> how the
> > > > data is tagged as binary.
> > > >
> > > > This expired draft should address that problem:
> > > > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> > > >
> > > > For every type T that they agree on, there are standard T.b2y() and
> > > T.y2b()
> > > > conversion functions.
> > > > There are also some extensions to define conversion templates so
> vendors
> > > > can add their own types.
> > > >
> > > > The YANG modules do not need to actually be altered.  The peers will
> > > > negotiate the
> > > > set of types that will be sent as binary when the session starts.
> > > > The receiver knows T and the SID for each object, and will accept
> either
> > > > the YANG or binary encoding.
> > >
> > > Sounds complex for me to negotiate this. I rather say once that a
> > > binary encoding can ship an IPv6 address as type binary { length 16; }
> > > and then CBOR will simply do the right thing.
> > >
> > >
> > OK, but this would require new type names.
> > You cannot simply change some standard type to be a union with a binary
> > type.
> >
> > This forces all implementations of that type to support the binary
> variant.
> > That breaks old clients that worked with the version before the binary
> > variant.
> >
> > The ripple effect on the models changing types would be non-trivial.
> > Using this union-type approach forces every protocol to support the
> binary
> > encoding,
> > yet base64 in a union with strings is very error-prone.
> >
>
> I am not proposing do change the type definitions we have. My idea was
> to have an optional additional definition for binary encodings. Here
> is an ad-hoc example (I do not like the details of the syntax, but
> perhaps this helps to understand the idea):
>
>  typedef ipv4-address {
>type string {
>  pattern
>'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>  +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>}
>description
>  "The ipv4-address type represents an IPv4 address in
>   dotted-quad notation.";
>
>binary-representation {
>  type binary {
>length 4;
>  }
>  description
>"The binary representa

Re: [netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder]

On Fri, Mar 29, 2019 at 09:30:19AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > > j.schoenwael...@jacobs-university.de> wrote:
> > >
> > > > Hi,
> > > >
> > > > this is issue is closed but I wonder whether this is correct. I have
> > > > several questions looking at the issue on github:
> > > >
> > > > - Why is this not a YANG issue?
> > > > - Which workaround is better?
> > > > - Why is this tagged as a NETCONF issue?
> > > >
> > > >
> > > Did you mean this should be NETCONF issue?
> > > It is more of a protocol problem then a modeling problem.
> > > The goal is to use the model unaltered.
> >
> > I think it would be valuable if say the definition of ipv4-address
> > could state that a canonical binary representation is of type binary {
> > length 4; }. Doing this is only meaningful for some types but it would
> > allow to add more binary representations over time.
> >
> > > > If we want to support binary encodings, we need to allow modelers to
> > > > define which types map to a canonical binary representation in
> > > > addition to the canonical string representation. As stated in the
> > > > issue description, hard-wiring some types in the encoding
> > > > specifications is very limited.
> > > >
> > > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > > high (adding binary encoding for some types does not cause any
> > > > backwards compatibility problem since so far we have only strings).
> > > >
> > > >
> > > Not so sure.
> > > The base64 encoding could look like a valid string.
> > > The receiver must know a binary type is being sent (XML and JSON both
> > fail
> > > here, but not CBOR).
> >
> > I am talking about CBOR, not about XML or JSON. I want to provide
> > hints to CBOR (or similar binary encodings) that values can be
> > represented in a different format. I do not expect these hints to be
> > used by XML or JSON. If you need binary encoding efficiency, use CBOR
> > instead of JSON.
> >
> > > > While I do not have a solution proposal, I think this issue is worth
> > > > to look at and we should not close it right now.
> > > >
> > > >
> > > I have a solution proposal, but I have not implemented it yet, so it it
> > not
> > > detailed...
> > >
> > > Both sender and receiver need to agree on the binary encoding and how the
> > > data is tagged as binary.
> > >
> > > This expired draft should address that problem:
> > > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> > >
> > > For every type T that they agree on, there are standard T.b2y() and
> > T.y2b()
> > > conversion functions.
> > > There are also some extensions to define conversion templates so vendors
> > > can add their own types.
> > >
> > > The YANG modules do not need to actually be altered.  The peers will
> > > negotiate the
> > > set of types that will be sent as binary when the session starts.
> > > The receiver knows T and the SID for each object, and will accept either
> > > the YANG or binary encoding.
> >
> > Sounds complex for me to negotiate this. I rather say once that a
> > binary encoding can ship an IPv6 address as type binary { length 16; }
> > and then CBOR will simply do the right thing.
> >
> >
> OK, but this would require new type names.
> You cannot simply change some standard type to be a union with a binary
> type.
>
> This forces all implementations of that type to support the binary variant.
> That breaks old clients that worked with the version before the binary
> variant.
> 
> The ripple effect on the models changing types would be non-trivial.
> Using this union-type approach forces every protocol to support the binary
> encoding,
> yet base64 in a union with strings is very error-prone.
> 

I am not proposing do change the type definitions we have. My idea was
to have an optional additional definition for binary encodings. Here
is an ad-hoc example (I do not like the details of the syntax, but
perhaps this helps to understand the idea):

 typedef ipv4-address {
   type string {
 pattern
   '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
 +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
   }
   description
 "The ipv4-address type represents an IPv4 address in
  dotted-quad notation.";

   binary-representation {
 type binary {
   length 4;
 }
 description
   "The binary representation uses as 4-byte binary string
in network byte ordering.";
   }
 }

The CBOR encoder (or other binary encoders) would then encode the
value as a 4 byte binary value, the XML and JSON encoder would use the
canonical string representation.  If the binary-representation is not
specified, then the generic CBOR encoding rules app

Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting

[Juergen Schoenwaelder]

On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani wrote:
> 
> The combination of these bullet items, and maybe other bullet items does not 
> make clear if there was any consensus in allowing (or maybe even preventing) 
> vendors from using a versioning system to keep track of NBC changes on other 
> (non-latest) branches of the model. I think I heard from multiple vendors 
> (outside of this meeting) that making NBC changes was needed on the 
> non-latest branches, whatever IETF or other SDOs decide. Has that sentiment 
> changed?
> 
> If it is the case, the split between the requirements of SDO and the vendors 
> is inevitable.
>

If there is a solution that can handle multiple branches, then the
same solution should work for SDOs that choose to use only a single
branch. I do not see why a split is inevitable.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting

[Mahesh Jethanandani]

Hi Robert,

Thanks for putting the minutes together. 

> On Mar 28, 2019, at 1:43 AM, Rob Wilton (rwilton)  wrote:
> 
> -These was agreement that IETF models should be limited to a linear 
> revision history, with changes only in the most recent revision.  It was 
> agreed that in some cases it is necessary to make NBC changes (in a new most 
> recent revision) in IETF YANG modules to fix bugs.
>  
> -There was discussion that an applicability statement could be added, 
> or some of the requirements could be split between SDO vs Vendor 
> requirements, but there did not seem to be strong consensus either for or 
> against this change.  In anything, there seemed to be a slight preference to 
> trying not to make this split.
>  
> -It was agreed that YANG should have a single versioning scheme that 
> is capable of covering both SDO requirements and vendor requirements.  There 
> was agreement that guidelines text could be used to provide guidance on how 
> IETF models should be versioned.


The combination of these bullet items, and maybe other bullet items does not 
make clear if there was any consensus in allowing (or maybe even preventing) 
vendors from using a versioning system to keep track of NBC changes on other 
(non-latest) branches of the model. I think I heard from multiple vendors 
(outside of this meeting) that making NBC changes was needed on the non-latest 
branches, whatever IETF or other SDOs decide. Has that sentiment changed?

If it is the case, the split between the requirements of SDO and the vendors is 
inevitable.

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang next issue #46 binary encoding support

[Andy Bierman]

On Fri, Mar 29, 2019 at 9:17 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> > On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > Hi,
> > >
> > > this is issue is closed but I wonder whether this is correct. I have
> > > several questions looking at the issue on github:
> > >
> > > - Why is this not a YANG issue?
> > > - Which workaround is better?
> > > - Why is this tagged as a NETCONF issue?
> > >
> > >
> > Did you mean this should be NETCONF issue?
> > It is more of a protocol problem then a modeling problem.
> > The goal is to use the model unaltered.
>
> I think it would be valuable if say the definition of ipv4-address
> could state that a canonical binary representation is of type binary {
> length 4; }. Doing this is only meaningful for some types but it would
> allow to add more binary representations over time.
>
> > > If we want to support binary encodings, we need to allow modelers to
> > > define which types map to a canonical binary representation in
> > > addition to the canonical string representation. As stated in the
> > > issue description, hard-wiring some types in the encoding
> > > specifications is very limited.
> > >
> > > In terms of backwards compatibility, this issue should IMHO be tagged
> > > high (adding binary encoding for some types does not cause any
> > > backwards compatibility problem since so far we have only strings).
> > >
> > >
> > Not so sure.
> > The base64 encoding could look like a valid string.
> > The receiver must know a binary type is being sent (XML and JSON both
> fail
> > here, but not CBOR).
>
> I am talking about CBOR, not about XML or JSON. I want to provide
> hints to CBOR (or similar binary encodings) that values can be
> represented in a different format. I do not expect these hints to be
> used by XML or JSON. If you need binary encoding efficiency, use CBOR
> instead of JSON.
>
> > > While I do not have a solution proposal, I think this issue is worth
> > > to look at and we should not close it right now.
> > >
> > >
> > I have a solution proposal, but I have not implemented it yet, so it it
> not
> > detailed...
> >
> > Both sender and receiver need to agree on the binary encoding and how the
> > data is tagged as binary.
> >
> > This expired draft should address that problem:
> > https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> >
> > For every type T that they agree on, there are standard T.b2y() and
> T.y2b()
> > conversion functions.
> > There are also some extensions to define conversion templates so vendors
> > can add their own types.
> >
> > The YANG modules do not need to actually be altered.  The peers will
> > negotiate the
> > set of types that will be sent as binary when the session starts.
> > The receiver knows T and the SID for each object, and will accept either
> > the YANG or binary encoding.
>
> Sounds complex for me to negotiate this. I rather say once that a
> binary encoding can ship an IPv6 address as type binary { length 16; }
> and then CBOR will simply do the right thing.
>
>
OK, but this would require new type names.
You cannot simply change some standard type to be a union with a binary
type.
This forces all implementations of that type to support the binary variant.
That breaks old clients that worked with the version before the binary
variant.

The ripple effect on the models changing types would be non-trivial.
Using this union-type approach forces every protocol to support the binary
encoding,
yet base64 in a union with strings is very error-prone.


/js
>

Andy



>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (5663)

[Martin Bjorklund]

Ebben Aries  wrote:
> On Mar 19 23:27 PM, Robert Varga wrote:
> > On 19/03/2019 19:12, Rob Wilton (rwilton) wrote:
> > > Hi Ebben,
> > > 
> > > I've always taken the ABNF to list the definitive sub-statements that are 
> > > allowed for the various deviate "add", "replace", or "delete" options.  
> > > Perhaps the RFC could state this more explicitly.  Perhaps raise an issue 
> > > on the YANG Next issue tracker to clarify this 
> > > (https://github.com/netmod-wg/yang-next/issues) and it might get 
> > > discussed tomorrow.
> > 
> > I agree.
> > 
> > Proposed statements are simple cases, for which 'deviate replace' can be
> > used to specify the correct value -- for example remove 'min-elements'
> > by replacing it with 'min-elements 0'.
> 
> Sure - my point was rather that in either case we have an issue.  The
> table of substatements in 7.20.3.2 is either not accurate or we modify
> the grammar to match.

I agree that the document needs clarification, and the yang-next issue
will take care of that.  The document needs a clarification that the
refers to the grammar, or perhaps different substatement tables for
add/replace/delete.

Meanwhile, I think that this errata should be rejected.


/martin




> 'deviate replace' can be used to 'reverse' these
> substatements much like a 'delete' would as you point out but the
> wording in this section should state this - I'll raise an issue on the
> tracker
> 
> FWIW - pyang does not honor the grammar and allows for a mandatory
> substatement of 'deviate delete' while yanglint appears to follow the
> ABNF strictly
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder]

On Fri, Mar 29, 2019 at 09:07:18AM -0700, Andy Bierman wrote:
> On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > Hi,
> >
> > this is issue is closed but I wonder whether this is correct. I have
> > several questions looking at the issue on github:
> >
> > - Why is this not a YANG issue?
> > - Which workaround is better?
> > - Why is this tagged as a NETCONF issue?
> >
> >
> Did you mean this should be NETCONF issue?
> It is more of a protocol problem then a modeling problem.
> The goal is to use the model unaltered.
 
I think it would be valuable if say the definition of ipv4-address
could state that a canonical binary representation is of type binary {
length 4; }. Doing this is only meaningful for some types but it would
allow to add more binary representations over time.
 
> > If we want to support binary encodings, we need to allow modelers to
> > define which types map to a canonical binary representation in
> > addition to the canonical string representation. As stated in the
> > issue description, hard-wiring some types in the encoding
> > specifications is very limited.
> >
> > In terms of backwards compatibility, this issue should IMHO be tagged
> > high (adding binary encoding for some types does not cause any
> > backwards compatibility problem since so far we have only strings).
> >
> >
> Not so sure.
> The base64 encoding could look like a valid string.
> The receiver must know a binary type is being sent (XML and JSON both fail
> here, but not CBOR).

I am talking about CBOR, not about XML or JSON. I want to provide
hints to CBOR (or similar binary encodings) that values can be
represented in a different format. I do not expect these hints to be
used by XML or JSON. If you need binary encoding efficiency, use CBOR
instead of JSON.

> > While I do not have a solution proposal, I think this issue is worth
> > to look at and we should not close it right now.
> >
> >
> I have a solution proposal, but I have not implemented it yet, so it it not
> detailed...
> 
> Both sender and receiver need to agree on the binary encoding and how the
> data is tagged as binary.
> 
> This expired draft should address that problem:
> https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01
> 
> For every type T that they agree on, there are standard T.b2y() and T.y2b()
> conversion functions.
> There are also some extensions to define conversion templates so vendors
> can add their own types.
>
> The YANG modules do not need to actually be altered.  The peers will
> negotiate the
> set of types that will be sent as binary when the session starts.
> The receiver knows T and the SID for each object, and will accept either
> the YANG or binary encoding.

Sounds complex for me to negotiate this. I rather say once that a
binary encoding can ship an IPv6 address as type binary { length 16; }
and then CBOR will simply do the right thing.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang next issue #46 binary encoding support

[Andy Bierman]

On Fri, Mar 29, 2019 at 4:19 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Hi,
>
> this is issue is closed but I wonder whether this is correct. I have
> several questions looking at the issue on github:
>
> - Why is this not a YANG issue?
> - Which workaround is better?
> - Why is this tagged as a NETCONF issue?
>
>
Did you mean this should be NETCONF issue?
It is more of a protocol problem then a modeling problem.
The goal is to use the model unaltered.



> If we want to support binary encodings, we need to allow modelers to
> define which types map to a canonical binary representation in
> addition to the canonical string representation. As stated in the
> issue description, hard-wiring some types in the encoding
> specifications is very limited.
>
> In terms of backwards compatibility, this issue should IMHO be tagged
> high (adding binary encoding for some types does not cause any
> backwards compatibility problem since so far we have only strings).
>
>
Not so sure.
The base64 encoding could look like a valid string.
The receiver must know a binary type is being sent (XML and JSON both fail
here, but not CBOR).



> While I do not have a solution proposal, I think this issue is worth
> to look at and we should not close it right now.
>
>
I have a solution proposal, but I have not implemented it yet, so it it not
detailed...

Both sender and receiver need to agree on the binary encoding and how the
data is tagged as binary.

This expired draft should address that problem:
https://tools.ietf.org/html/draft-mahesh-netconf-binary-encoding-01

For every type T that they agree on, there are standard T.b2y() and T.y2b()
conversion functions.
There are also some extensions to define conversion templates so vendors
can add their own types.

The YANG modules do not need to actually be altered.  The peers will
negotiate the
set of types that will be sent as binary when the session starts.
The receiver knows T and the SID for each object, and will accept either
the YANG or binary encoding.



> /js
>
>
Andy


> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 6991bis: host

[Ladislav Lhotka]

Hi,

the inet:host type should not use the inet:domain-name as its member because the
latter type doesn't satisfy the requirements of RFC 952 and 1123 on host names.
For example, the type now permits a single dot (".") as the value or the
underscore character.

I propose to change the "host" type as follows:

OLD

typedef host {
  type union {
type inet:ip-address;
type inet:domain-name;
  }
  ...
}

NEW

typedef host {
  type union {
type inet:ip-address;
type inet:host-name;
  }
  ...
}

A reasonable definition of "host-name" is IMO a domain name whose labels are NR-
LDH (non-registered letter-digit-hyphen label) [RFC 5890]:

typedef host-name {
  type string {
pattern
  '((([a-zA-Z0-9]([a-zA-Z0-9\-]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9]([a-zA-Z0-9\-]){0,61})?[a-zA-Z0-9]\.?)';
pattern '(.*\.)?..\-\-.*' {
  modifier invert-match;
}
length "2..253";
...
  }
}

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6991bis: domain-name

[Ladislav Lhotka]

Rob Wilton (rwilton) píše v Pá 29. 03. 2019 v 11:15 +:
> Hi Lada,
> 
> For a domain name that supports wildcard, I wonder whether that wouldn't be
> better as a separate type.  I can imagine that in a lot of places a wildcard
> domain name isn't appropriate.

But the description says:

It is designed to hold various types of domain names, including names used for A
or  records (host names) and other records, such as SRV records.

And in DNS resource records, wilcard names are possible.

It is true that wildcards are not permitted in host names and such, but then the
"inet:host" type should not have domain-name as its member type. Even with the
existing version the "host" type permits "." which is not good either.

The "inet:host" type should IMO adhere to a stricter syntax of RFC 952. I will
send another message to address this.

Lada

> 
> Thanks,
> Rob
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Ladislav Lhotka
> > Sent: 29 March 2019 10:20
> > To: NETMOD WG 
> > Subject: [netmod] 6991bis: domain-name
> > 
> > Hi,
> > 
> > as a follow-up to my comment during the NETMOD session, I want to propose
> > the following update to the the inet:domain-name type. The aim is to include
> > use cases that are currently rejected:
> > 
> > - classless in-addr.arpa delegations [RFC 2317], i.e. labels like "128/26"
> > 
> > - wildcards [RFC 4592], e.g. "*.example.net"
> > 
> > OLD
> > 
> > pattern
> >   '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
> > + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
> > + '|\.';
> > 
> > NEW
> > 
> > pattern
> >   '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
> > + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
> > + '|\.';
> > 
> > Lada
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > 
> > 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] yang next issue #46 binary encoding support

[Juergen Schoenwaelder]

Hi,

this is issue is closed but I wonder whether this is correct. I have
several questions looking at the issue on github:

- Why is this not a YANG issue?
- Which workaround is better?
- Why is this tagged as a NETCONF issue?

If we want to support binary encodings, we need to allow modelers to
define which types map to a canonical binary representation in
addition to the canonical string representation. As stated in the
issue description, hard-wiring some types in the encoding
specifications is very limited.

In terms of backwards compatibility, this issue should IMHO be tagged
high (adding binary encoding for some types does not cause any
backwards compatibility problem since so far we have only strings).

While I do not have a solution proposal, I think this issue is worth
to look at and we should not close it right now.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6991bis: domain-name

[Rob Wilton (rwilton)]

Hi Lada,

For a domain name that supports wildcard, I wonder whether that wouldn't be 
better as a separate type.  I can imagine that in a lot of places a wildcard 
domain name isn't appropriate.

Thanks,
Rob


> -Original Message-
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 29 March 2019 10:20
> To: NETMOD WG 
> Subject: [netmod] 6991bis: domain-name
> 
> Hi,
> 
> as a follow-up to my comment during the NETMOD session, I want to propose
> the following update to the the inet:domain-name type. The aim is to include
> use cases that are currently rejected:
> 
> - classless in-addr.arpa delegations [RFC 2317], i.e. labels like "128/26"
> 
> - wildcards [RFC 4592], e.g. "*.example.net"
> 
> OLD
> 
> pattern
>   '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
> + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
> + '|\.';
> 
> NEW
> 
> pattern
>   '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
> + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
> + '|\.';
> 
> Lada
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 6991bis: domain-name

[Ladislav Lhotka]

Hi,

as a follow-up to my comment during the NETMOD session, I want to propose the
following update to the the inet:domain-name type. The aim is to include use
cases that are currently rejected:

- classless in-addr.arpa delegations [RFC 2317], i.e. labels like "128/26"

- wildcards [RFC 4592], e.g. "*.example.net"

OLD

pattern
  '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.';

NEW

pattern
  '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.';

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod