Reviewer: Qin Wu
Review result: Almost Ready
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
other.
5. Please follow guidance in section 4.23.3.1 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
appendix.
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 8.2.2.4. of [RFC8724]).
"
Besides specifying max-ack-request parameter, do we need to specify other
parameters defined in the fragmentation schema tree snippet such as
'max-interleaved-frames'.
7. Security section, please follows YANG security guidance to consider
rewriting the paragraphs in section 8.
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Nits:
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
