Skip to main content

Early Review of draft-ietf-lpwan-schc-yang-data-model-04

Request Review of draft-ietf-lpwan-schc-yang-data-model
Requested revision No specific revision (document currently at 21)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2021-03-08
Requested 2021-02-15
Requested by Pascal Thubert
Authors Ana Minaburo , Laurent Toutain
I-D last updated 2021-04-13
Completed reviews Yangdoctors Early review of -04 by Carl Moberg (diff)
Yangdoctors Last Call review of -14 by Joe Clarke (diff)
Intdir Last Call review of -15 by Donald E. Eastlake 3rd (diff)
Genart Last Call review of -14 by Meral Shirazipour (diff)
Secdir Last Call review of -14 by Carl Wallace (diff)
Iotdir Telechat review of -15 by Qin Wu (diff)
The authors are new to Yang and need help to structure their work. Happy to get feedback on how this would be best expressed in Yang.
Assignment Reviewer Carl Moberg
State Completed
Request Early review on draft-ietf-lpwan-schc-yang-data-model by YANG Doctors Assigned
Posted at
Reviewed revision 04 (document currently at 21)
Result On the Right Track
Completed 2021-04-13
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?