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