[yang-doctors] Yangdoctors Early Review of draft-ietf-lpwan-schc-yang-data-model-04

[Mehmet Ersue <[e-mail]>]

I'm sending this on behalf of Carl Moberg.

It seems there was an issue and the review mail has not been generated.

Text copied from 

https://datatracker.ietf.org/doc/review-ietf-lpwan-schc-yang-data-model-04-y
angdoctors-early-moberg-2021-04-13/

 

Mehmet

 

Reviewer: Carl Moberg

Review result: On the Right Track

 

This is my YANG Doctors Early Review of
draft-ietf-lpwan-schc-yang-data-model-04

 

It is obviously challenging to provide early review feedback on how useful
and efficient the YANG model representation is for a set of technologies
that I am not an expert on, but here goes.

 

Understanding that it is still early in the lifecycle of the module, I have
not spent time on providing feedback on e.g. description texts,
capitalization and spelling but have focused on the general structure and
design of the module. I also haven't spent any time dissecting the output of
`pyang --ietf`, but I would suggest the authors start looking into that as
the content of the module moves ahead towards publication.

 

I would also suggest considering running the module through `pyang -f yang`
as that provides nice and consistent formatting and quoting.

 

As for the content itself. I believe to the best of my understanding that
the YANG module reflects the core data structures of RFC8724 well. I have a
couple of questions that may lead to broader discussion on _how_ to capture
certain aspects of these data structures in a way that makes it realistic to
implement while still easy to use.

 

As is right now, the YANG module assumes that all implementations support
all FID types defined to be derived from field-id-base-type. It includes
fields related IPv6, COAP/OSCORE, and ICMPv6 all in the same module. Is
there a possibility that some implementations won't implement all three of
those protocol groups? If so, it might be worth considering making FID type
groups either optional using YANG 'feature' statements or break them out
into separate modules to be advertised separately.

 

There is currently no correlation between field-id type and field-length
types in the same compression rule entry. I.e. the current YANG permits a
field-identifier 'fid-ipv6-version' combined with a field-length
'fl-token-length' in a rule entry, which I understand to be nonsensical. If
I am right in that it's an example of meaningless configuration, does the
authors think it important (and possible) to work towards a more stringent
validation of "meaningful" configuration by capturing the relationships
between fields like in this example?