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

[Andy Bierman]

On Tue, Mar 1, 2022 at 8:15 AM Carsten Bormann  wrote:

> (Removing RFC-editor from the list:)
>
> On 2022-03-01, at 16:42, SADOVNIKOV, ALEXEI  wrote:
> >
> > I continue to doubt if this optimization continues to have value in
> presence of JSON processing, where such optimization is not possible.   I
> am expecting an implementation these days to implement both XML and JSON,
> and then it either implements something which can deal with unordered for
> both, or have two different implementations one of which is optimized.
>
> This is very interesting also for YANG-CBOR.  We modeled our
> representation after that used in YANG-JSON, but of course CBOR can be much
> more efficient (in particular in conjunction with YANG-SIDs).
> If there is a performance problem with the YANG-JSON approach that we
> could work around on the CBOR side, I would certainly like to hear about it!
>
>
IMO JSON is too stateful, making it fragile (e.g., missing or extra comma).
It is also unordered, making implementation of annotations defined in RFC
7952 much more difficult.

The issues with JSON are more pronounced for a streaming server, where
there is
no JSON document in memory, just a lot of internal API calls to get data.
The API calls are easier if "what came before" and "what comes next" are
irrelevant (like for XML).

I am very interested in the CBOR encoding of YANG annotations (still TBD in
the drafts).




> Grüße, Carsten
>

Andy


>
> ___
> 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

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

[Jürgen Schönwälder]

On Tue, Mar 01, 2022 at 03:42:34PM +, SADOVNIKOV, ALEXEI wrote:
> 
> I continue to doubt if this optimization continues to have value in presence 
> of JSON processing, where such optimization is not possible.   I am expecting 
> an implementation these days to implement both XML and JSON, and then it 
> either implements something which can deal with unordered for both, or have 
> two different implementations one of which is optimized.
>

If you want to process data in a streaming fashion, you simply have to
buffer data until you have the keys of list elements. The XML encoding
rules kind of force efficient behaviour, the JSON encoding rules do
not.  However, if you have control over your JSON serializer, it may
still make sense to send the list keys early.

/js

-- 
Jürgen Schönwälder  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 (6855)

[Carsten Bormann]

(Removing RFC-editor from the list:)

On 2022-03-01, at 16:42, SADOVNIKOV, ALEXEI  wrote:
> 
> I continue to doubt if this optimization continues to have value in presence 
> of JSON processing, where such optimization is not possible.   I am expecting 
> an implementation these days to implement both XML and JSON, and then it 
> either implements something which can deal with unordered for both, or have 
> two different implementations one of which is optimized.

This is very interesting also for YANG-CBOR.  We modeled our representation 
after that used in YANG-JSON, but of course CBOR can be much more efficient (in 
particular in conjunction with YANG-SIDs).
If there is a performance problem with the YANG-JSON approach that we could 
work around on the CBOR side, I would certainly like to hear about it!

Grüße, Carsten

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

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Andy Bierman]

On Tue, Mar 1, 2022 at 4:54 AM William Lupton 
wrote:

> All,
>
> Sorry if (as is quite likely) this is a duplicate.
>
> I noticed from
> https://yangcatalog.org/private-page/BBFYANGPageCompilation.html that
> there's a (long-standing?) problem in iana-if-type.yang
> :
> it has multiple revision statements with the same date:
>
>   revision 2018-06-28 {
> description
>   "Registered ifType 294.";
>   }
>
>   revision 2018-06-28 {
> description
>   "Registered ifType 293.";
>   }
>
> This has presumably happened as a result of an automated update script
> that doesn't check for this case (*)? From a quick scan, I didn't see
> anything in RFC 7950 banning duplicate revision dates, but RFC 8407 section
> 4.8 says "*If the module contents have changed, then the revision date of
> that new module version MUST be updated to a date later than that of the
> previous version*" and of course yangdump-pro is checking this.
>
> I think that this should be fixed. What's the best way to achieve this?
>

I think this issue should be resolved as well.
The YANG library identifies each module by a [name, date] tuple.
The  operation uses this tuple to identify a specific revision
to retrieve.
The import-by-revision mechanism uses this tuple to identify a specific
revision to import.

If this [name, date] tuple is not unique, then it cannot be mapped to a
single module revision.

Note that with multiple release trains and the new SERMVER, it is likely
that multiple [name, date, label] tuples resolve to the same [name, date]
pair,
making the uniqueness problem even worse.

This is quite significant if a client reads the YANG library from a server
and decides it already has the module cached (based on the [name, date]
tuple,
as defined in the standard.  Then it will not use the  operation
to retrieve the module from the server.

YANG artifacts and SID files also rely on this [name, date] tuple
uniqueness.

Even with the new versioning drafts, it is impossible for the client to know
"Do you mean the REAL module foo, version -xx-xx, or your private
version?"


> Thanks,
> William
>

 Andy


> (*) In the rare event that multiple changes are made in the same day,
> perhaps the second change should be (strictly wrongly) assigned to the
> following day. In theory this could cause revision dates to run far into
> the future but in practice I don't think this will happen :).
> ___
> 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

Re: [netmod] The "resolve-system" parameter in the new "with-system" I-D

[Jan Lindblad (jlindbla)]

Kent, WG,

> [As a contributor]
> 
> This message regards the value of the "resolve-system” parameter defined in 
> the latest “with-system” draft.
> 
> The "resolve-system” parameter is defined in its own optional-to-implement 
> module.  The question is if the WG believes the parameter is valuable or if 
> the module should be removed from the draft before adoption call?

I believe the resolve-system parameter has value in certain use cases. In 
particular I think the flag matches common expectations from the RESTCONF 
community, where a complete understanding of the server's configuration is 
rarely desired, and where injecting multiple, disjunct pieces of configuration 
is perceived as complicated by some.

To model the resolve-system flag as an optional capability is the best trade 
off in my opinion. For some device types it doesn't make sense to implement 
this flag, while for other device types, this might become the typical client 
behavior.

Best Regards,
/jan

> The "resolve-system” parameter is a convenience function, enabling clients to 
> NOT have “manually” copy/paste referenced system-defined nodes into 
> .  Instead, by including this parameter in , , 
> or equivalents, the client requests the server to itself copy/paste the 
> missing system nodes into . 
> 
> It is true that this work began with a goal of never having to copy/paste 
> system-defined nodes into .   The concern wasn’t about *how* the 
> referenced system-defined nodes came to be in , but *if* they needed 
> to be in  at all.   But now that the current draft says referenced 
> system-nodes MUST be in , the only remaining question regards *how* 
> they came to be in .  
> 
> Yes, there is convenience in using the “resolve-system” parameter, but there 
> is also some implementation complexity.   Ultimately, the question is, is the 
> convenience worth the complexity?   Thoughts?
> 
> Thanks,
> Kent
> 

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

[netmod] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

All,

Sorry if (as is quite likely) this is a duplicate.

I noticed from
https://yangcatalog.org/private-page/BBFYANGPageCompilation.html that
there's a (long-standing?) problem in iana-if-type.yang
:
it has multiple revision statements with the same date:

  revision 2018-06-28 {
description
  "Registered ifType 294.";
  }

  revision 2018-06-28 {
description
  "Registered ifType 293.";
  }

This has presumably happened as a result of an automated update script that
doesn't check for this case (*)? From a quick scan, I didn't see anything
in RFC 7950 banning duplicate revision dates, but RFC 8407 section 4.8 says
"*If the module contents have changed, then the revision date of that new
module version MUST be updated to a date later than that of the previous
version*" and of course yangdump-pro is checking this.

I think that this should be fixed. What's the best way to achieve this?

Thanks,
William

(*) In the rare event that multiple changes are made in the same day,
perhaps the second change should be (strictly wrongly) assigned to the
following day. In theory this could cause revision dates to run far into
the future but in practice I don't think this will happen :).
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jernej Tuljak]

On 28/02/2022 23:14, SADOVNIKOV, ALEXEI wrote:


On Mon, Feb 28, 2022 at 06:42:56PM +, Sterne, Jason (Nokia - 
CA/Ottawa) wrote:
> Thx.  I probably went too far in my statement about XML documents 
being unordered. But isn't it true that for YANG modelled data, the 
order of the XML *shouldn't* matter ?  It should ideally be processed 
atomically (i.e. after being fully processed/loaded it should be 
non-ambiguous if you assumed every statement was applied at the same 
instant) ?


In addition to what Andy said (which I agree with)…


Ordered-by-user, is a special case – this is where the order is 
significant.  For completeness it would be significant even in JSON 
encapsulation (arrays are ordered).  Unlike other XML ordering cases, 
the order in ordered-by-user is simply significant by itself.


In other scenarios of ordering of XML document as described in RFC 
7950 there are two different aspects (and sticking with your terminology):


 1. The way RFC 7950 stands, the order of XML does matter. 
Consequently, and XML document which is ordered differently does
not have to be “processed/ordered”; it is totally legitimate for
such XML document to be rejected.

This could also allow parser of XML document to be more efficient in 
processing data taking an account model order.


For example, in your earlier example of ,, vs to 
,,, one is correct ordering and will be 
“processed” correctly; the other one is wrong ordering and may result 
in processing failure.


 2. The second aspect, which I think you talking about, is the
significance of such ordering required by RFC.  I do agree with
you, there is nothing which prevents correct “processed/ordered”
to be done.  In other words, the processor knows what the keys are
and which order the keys are in, and he can get them from XML
document.  Further, if payload comes as JSON, the ordering is not
there, so if processor can consume both JSON and XML he is already
implementing order independent processing for JSON.

Another point relevant to this conversation hides in section *6.4 
. * XPath 
Evaluations, which states


   The data tree has no concept of document order.  An implementation

   needs to choose some document order, but how it is done is an

   implementation decision.  This means that XPath expressions in YANG

   modules SHOULD NOT rely on any specific document order.

Couple point to note here:

  * The XPATH has document order axes, e.g. ‘preceding-sibling’ hence
it can interrogate document order
  * RFC says that this is implementation specific (e.g. it does not
need to follow the order of XML encapsulation described elsewhere).

Consequently, in your keys example, it is implementation dependent 
which is preceding-sibling key-2, and it can be different from what it 
is in XML document encoding the data.


Not being an original contributor of this RFC, I really cannot tell 
why ordering requirements (other than ordered-by-user) are in RFC, nor 
what good do such requirements do.




These rules make XML encoded YANG instance documents more readable by 
human beings.


Jernej

I can say though that this ordering is not a discussion of RFC 7950, 
which sets the requirements, nor a discussion of this errata, which 
was about wording used to set requirements.  It could be part of YANG 
NEXT discussion :)


Best regards,

*Alexei Sadovnikov*

Principal System Architect

Business Solutions

AT&T Business

*AT&T Services, Inc.*

550 Cochituate Road, Framingham, MA 01701

m 781.249.1516 |  o  781.249.1516 | _as5...@att.com 
_


This e-mail and any files transmitted with it are AT&T property, are 
confidential, and are intended solely for the use of the individual or 
entity to whom this e-mail is addressed. If you are not one of the 
named recipient(s),  or otherwise have reason to believe that you have 
received this message in error, please notify the sender and delete 
this message immediately from your computer. Any other use, retention, 
dissemination, forwarding, printing, or copying of this e-mail is 
strictly prohibited.


*From: *Andy Bierman 
*Date: *Monday, February 28, 2022 at 2:06 PM
*To: *Jürgen Schönwälder , 
"Sterne, Jason (Nokia - CA/Ottawa)" , as549r 
, "Rob Wilton (rwilton)" , Andy 
Bierman , "m...@tail-f.com" , 
"war...@kumari.net" , "netmod@ietf.org" 
, RFC Errata System 

*Subject: *Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

On Mon, Feb 28, 2022 at 10:53 AM Jürgen Schönwälder 
 wrote:


RFC 7950 defines the ordering rules for the XML serialization of YANG
data (and it does not really matter what other uses of XML require). A
rough summary is that XML serializations of data trees are generally
unordered except that elements representing lists have to follow the
list ordering rules and that keys of list elements come first and in
the order they keys are defined.

-