Skip to main content

Telechat Review of draft-ietf-lpwan-schc-yang-data-model-15

Request Review of draft-ietf-lpwan-schc-yang-data-model
Requested revision No specific revision (document currently at 21)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2022-08-21
Requested 2022-08-08
Requested by Éric Vyncke
Authors Ana Minaburo , Laurent Toutain
I-D last updated 2022-08-12
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)
As SCHC is mainly used by constrained devices, a quick review by the IoT directorate will be welcome. No need to be a YANG expert as the YANG doctors have reviewed the YANG module.
Assignment Reviewer Qin Wu
State Completed
Request Telechat review on draft-ietf-lpwan-schc-yang-data-model by Internet of Things Directorate Assigned
Posted at
Reviewed revision 15 (document currently at 21)
Result Almost ready
Completed 2022-08-12
I am the IoT Directorate reviewer for this draft. Please treat these comments
as normal last call comments.

Regarding the scope of this work, it aligns with the Static Context Header
Compression and fragmentation (SCHC) framework in RFC8724 and focuses on policy
rules configuration model, it can only be used by the management system to
configure rules related to compression and fragmentation, but it can not be
used to monitor state changes, report these state to the management system.
This is a first document I have ever seen to mirror all the protocol fields in
the data plane and construct them into YANG files in the management plane.

Major Issues:
1. Suggest to create a terminology sub-sections within section 2 since readers
who are not familiar with SCHC background knowlege are harder to interpret many
terminologies defined in this document or some related documents.

2. Section 1 said:
The goal of this document is to formalize the
   description of the rules to offer:

   *  the same definition on both ends, even if the internal
      representation is different.

   *  an update of the other end to set up some specific values (e.g.
      IPv6 prefix, destination address,...)

   *  ...
So the question is what else goal of this document? I fail to see other
objective of defining YANG model in this document? Suggest to remove the third
bullet which seems to me meaningless.

3. See 3.10.1.  Fragmentation mode, three modes are defined in the SCHC
protocol, Have we considerd model 'ack-on-error', 'ack-always','no-ack' as
action statements defined in RFC7950, One typical example of action is
"set-operator-state" action defined in RFC8632.

4. In section 5, The descriptions for
fid-ipv6-devprefix,fid-ipv6-deviid,fid-ipv6-appprefix,fid-ipv6-appiid are same,
please refer to RFC8724 to make their description distinguishing between each

5. Please follow guidance in section to define a foo-state module in
the appendix.

6. Please provide an example to explain how
target-value,matching-operator-value,comp-decomp-action-value are used in the

Minor issues:

1. Section 3 mentions feature command, I am not sure feature is a command,
instead, I think it is just a YANG statement.
   S/the feature command/ the feature statement [RFC7950]

2. Section 3.5,  If my understanding is correct, the field position is referred
to occurrence times of a specific field,
   s/which gives the position of a field/ which gives the occurrence times of a
   specific field.

3. Section 3.7 said:
   *  For Equal and LSB, Target Value contains a single element.
      Therefore, the index is set to 0.

  Why LSB is defined as one of matching operators instead of MSB, see section
  7.3 of RFC8724, there is no LSB Matching operators. In addition, section 3.7
  only discuss how to specify value for 'Equal', 'MSB','Matching mapping'
  matching operators cases, what about other cases such as ignore,MSB?

4. Section 3.7 said:
"   *  For match-mapping, Target Value can contain several elements.
      Index values MUST start from 0 and MUST be contiguous."
index values rules for match-mapping case in section 3.7 is not consistent with
index value rules definition in section 5.
        See target-value list definition of section 5 as follows:
                For use as a matching list for the mo-match-mapping matching
            operator, positions should take consecutive values starting
            from 1.
        I am wondering what is relation between the position and index? I
        believe position should be replaced with the index. secondly, section 5
        stipulates that index values starting from 1 while section 3.7
        stipulates index value starting from 0, this should be consistent.

5. Section 3.7 said:
" If the header field contains a text, the binary sequence uses the
   same enconding."
how this last sentence related to YANG data model defined in this document? If
not relevant, please remove this sentence. 6. Section 3.10.6 said: "
   The SCHC fragmentation protocol specifies the the number of attempts
   before aborting through the parameter:

   *  max-ack-requests (cf. section of [RFC8724]).

Besides specifying max-ack-request parameter, do we need to specify other
parameters defined in the fragmentation schema tree snippet such as

7. Security section, please follows YANG security guidance to consider
rewriting the paragraphs in section 8.

1. Section 3,s/serveur response [RFC7967] /server response [RFC7967]
2. Section 3,s/allows to select the compression/ enables the compression and
the fragmentation selection 3. Section 3.4, For consistency between the first
paragraph and the last paragraph of section 3.4,
   s/giving in bits the size of the length/giving the size of the length in bits
4. Section 3.7,  s/The index allows to specify several values/The index allows
specify several values