[Schc] Re: draft-ietf-schc-8824-update-08 early Yangdoctors review

[Marco Tiloca <[e-mail]>]

Hello Dhruv,

Thanks a lot for your review!

After confirming the resolution with the SCHC WG at IETF 126, we have submitted the latest version -10 of this document [0] addressing your comments.

In particular, as per the (now closed) GitHub PR at [1], we have removed from the document the YANG module ietf-schc-coap and related text/references.

The file [e-mail] is still available on the GitHub repository [2], now also incorporating your specific comments about the content of the YANG module removed from this document. It is useful material for a possible separate document that obsoletes RFC 9363 and updates its original YANG module ietf-schc.

Best,
/Marco

[0] https://datatracker.ietf.org/doc/html/draft-ietf-schc-8824-update-10

[1] https://github.com/ietf-wg-schc/draft-ietf-schc-8824-update/pull/3

[2] https://github.com/ietf-wg-schc/draft-ietf-schc-8824-update/blob/main/ietf-schc-coap%402026-06-30.yang

________________________________
From: Dhruv Dhody via Datatracker <[e-mail]>
Sent: Monday, June 29, 2026 2:16 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Schc] draft-ietf-schc-8824-update-08 early Yangdoctors review

Document: draft-ietf-schc-8824-update
Title: Static Context Header Compression (SCHC) for the Constrained Application
Protocol (CoAP) Reviewer: Dhruv Dhody Review result: Not Ready

This review focuses on the YANG data model and the changes made to RFC 8824.
This is not a comprehensive review of the I-D.

This document obsoletes and replaces RFC 8824. RFC 8824 itself defined no YANG
data model; the SCHC YANG model (ietf-schc) was introduced later by RFC 9363,
which already includes CoAP-related FID identities. This document adds a new
module, ietf-schc-coap (Appendix A), that extends ietf-schc [RFC9363].

## Should there be a YANG model in this I-D?

CoAP FID identities are now split across two modules: the original set in
ietf-schc [RFC9363] and the new options in ietf-schc-coap (this document). The
module name "ietf-schc-coap" reads as "the CoAP module for SCHC" and would lead
a model consumer to expect it to be where CoAP definitions live. In fact, it
contains only the increment added by this bis.

Should this not be done via a bis for RFC9363 in this case? I know it is extra
work, but thinking from a consumer of YANG model POV, that makes more sense
than a separate YANG data model just because there was a bis of RFC at one
point.

I also note two editor's notes (Sections 4.3 and 4.6) requesting that the
reference for fid-coap-tkl and fid-coap-token be updated with an RFC 8974,
which can only be done by republishing that module, i.e., a 9363bis.

Note there is a proposed work draft-mahesh-opsawg-veloce-yang that hopes to
make doing things like this faster!

I am marking it as Not Ready mainly to resolve this.

## Review of the YANG Data Model

The YANG module is not an example; it is the normative YANG module that this
document requests IANA to register. Normative YANG modules should not be placed
in an appendix. Appendix is used for example YANG module.

The description in the YANG model should be aligned to
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9907.html%23appendix-B&data=05%7C02%7Cmarco.tiloca%40ri.se%7C5b370166e40f478b620608ded5d85f76%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639183322482324044%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RpsxoasnBkUgQsFPqrT001uG9f2arCmcO5SAepbdieo%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc9907.html#appendix-B>; there is no
description, the copyright is incorrect, and there is no reason to include BCP
14 template.

Fix the name "fl-oscore-oscore-piv-length" and avoid oscore twice.

Why is there no identity for var_bit related additions made in this I-D?

Security Considerations template for YANG should be followed as per
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9907.html%23name-security-considerations-sect&data=05%7C02%7Cmarco.tiloca%40ri.se%7C5b370166e40f478b620608ded5d85f76%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639183322482389189%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KERT0Xw%2FMihz%2BKatlFj2W8tRFl9NK9HyyZRNUCCTMcU%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc9907.html#name-security-considerations-sect>

IANA consideration template should be followed as per
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9907.html%23section-3.8.3.1&data=05%7C02%7Cmarco.tiloca%40ri.se%7C5b370166e40f478b620608ded5d85f76%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639183322482459007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gKFHf7aJKcCeyIBaya98f2XVfEShVj8O8dihiV1gmbw%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc9907.html#section-3.8.3.1>

Thanks!
Dhruv


--
Schc mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]