Skip to main content

A YANG Data Model for Static Context Header Compression (SCHC)
draft-ietf-lpwan-schc-yang-data-model-21

Yes

Éric Vyncke

No Objection

Warren Kumari
(Alvaro Retana)
(Andrew Alston)

Note: This ballot was opened for revision 15 and is now closed.

Éric Vyncke
Yes
Erik Kline
No Objection
Comment (2022-08-22 for -15) Sent
# Internet AD comments for {draft-ietf-lpwan-schc-yang-data-model-15}
CC @ekline

## Comments

### S3.5

* Should the "position of the field" be relative to something?

### S5

* The mailto: URI is slightly truncated.  It seems like it should be
  "mailto:lp-wan@ietf.org" rather than "mailto:p-wan@ietf.org".

* "Field Length : Either a positive integer of a function." doesn't quite
  parse easily for me.

  Perhaps: "Field Length : Either a positive integer or a CDA function."?

## Nits

### S3

* s/definied/defined/

* s/serveur/server/

### S3.4

* s/giving in bits/given in bits/

### S3.7

* s/contains a text/contains text/?

### S3.10.2

* s/field in optional/field is optional/

### S3.10.5

* s/sould be/should be/
John Scudder
No Objection
Comment (2022-08-24 for -15) Sent
Nits:

- s/serveur/server/
- I suggest "an informal" as a more idiomatic option where "a non formal" is used.
Murray Kucherawy
No Objection
Comment (2022-08-25 for -15) Sent
Question 20 on the shepherd writeup says there were no IANA actions here, but in fact there were two.
Paul Wouters
(was Discuss) No Objection
Comment (2022-08-30 for -17) Sent
The -17 version addresses my discuss. Thanks!

Old DISCUSS:

Probably an easy thing to fix,

I see an identity defined as "rcs-rfc8724". Using RFC numbers as names can
be confusing if such and RFC is obsoleted for another RFC. Couldn't this
entry be called "rcs-crc32" ?


NITS:

- Section 1 [I-D.ietf-lpwan-architecture] is a broken reference

- Many sections contain [RFC8724] as a broken reference
Roman Danyliw
(was Discuss) No Objection
Comment (2022-09-28 for -18) Sent for earlier
Thank you to Carl Wallace for the SECDIR review.

Thanks for addressing my feedback in -17 and -18.  I leave to the WG if clarifying this is possible:

** Section 8.
   Therefore, the identity of
   the requester must be validated.  This can be done through
   certificates or access lists.

Is there a particular way which this should be done, or is it expected to follow NACM, and associated NETCONF and RESTCONF?
Warren Kumari
No Objection
Zaheduzzaman Sarker
No Objection
Comment (2022-08-24 for -15) Not sent
Thanks for working on the specification. I have found number of typos but those seems like well covered by Lars's comments.
Alvaro Retana Former IESG member
No Objection
No Objection (for -15) Not sent

                            
Andrew Alston Former IESG member
No Objection
No Objection (for -15) Not sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (2022-08-24 for -15) Sent
# GEN AD review of draft-ietf-lpwan-schc-yang-data-model-15

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/RVzFMuO5DCPzLz7tJnYk9J9NEPk).

## Comments

In general, the writing in this document is quite poor, making it often
difficult to immediately understand the intended technical content. I wish the
WG had spent some more efforts here before sending this forward for publication.

### Section 1, paragraph 4
```
     *  ...
```
Should this placeholder be removed?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3, paragraph 2
```
-    UDP[RFC0768], CoAP [RFC7252] including options definied for no
-                                                        -
```

#### Section 3, paragraph 2
```
-    serveur response [RFC7967] and OSCORE [RFC8613].  For the latter
-         -
```

#### Section 3.7, paragraph 4
```
-    same enconding.
-             -
```

#### Section 3.10.1, paragraph 2
```
-    *  No Ack: this mode is unidirectionnal, no acknowledgment is sent
-                                        -
```

#### Section 3.10.5, paragraph 4
```
-    recommends a duration of 12 hours.  In fact, the value range sould be
+    recommends a duration of 12 hours.  In fact, the value range should be
+                                                                  +
```

#### Section 3.10.5, paragraph 6
```
-       1.0 sec and 19 hours covering [RFC9011] recommandation.
-                                                     ^
+       1.0 sec and 19 hours covering [RFC9011] recommendation.
+                                                     ^
```

#### Section 4, paragraph 1
```
-    A rule is idenfied by a unique rule identifier (rule ID) comprising
+    A rule is identified by a unique rule identifier (rule ID) comprising
+                  ++
```

#### Section 4, paragraph 4
```
-       packet in extenso when no compression rule was found (see
+       packet in extension when no compression rule was found (see
+                       + +
```

Or what else is "in extenso" supposed to mean?

#### Section 4, paragraph 6
```
-    The YANG data model introduces repectively these three identities :
-                                   ------------                      -
```

#### Section 4, paragraph 7
```
-    *  nature-compresion
+    *  nature-compression
+                     +
```

#### Section 4.3, paragraph 123
```
-           Note that the smallest value is also the incrementation step,
-                                                             ^^ ^^^^^ ^
-           so the timer precision.
-          ---
+           Note that the smallest value is also the increment, i.e.,
+                                                             ^^ ^ ^
```

#### Section 4.3, paragraph 127
```
-             occurences.
+             occurrences.
+                  +
```

#### Section 4.3, paragraph 127
```
-             irrespective of its position of occurence in the
+             irrespective of its position of occurrence in the
+                                                  +
```

#### Section 4.3, paragraph 127
```
-             direction (bi directionnal, only uplink, or only
-                          ^        -
+             direction (bi-directional, only uplink, or only
+                          ^
```

#### Section 8, paragraph 5
```
-    The rule contains some sensible informations such as the application
-                                               ^
+    The rule contains some sensible information, such as the application
+                                               ^
```

### Grammar/style

#### "Table of Contents", paragraph 1
```
ed network. [RFC8724] provides a non formal representation of the rules used
                                 ^^^^^^^^^^
```
This expression is usually spelled with a hyphen. (Also elsewhere.)

#### Section 3.5, paragraph 1
```
ression Action). The index allows to specify several values: * For Equal and
                                  ^^^^^^^^^^
```
Did you mean "specifying"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

#### Section 3.10.2, paragraph 3
```
can include a tile. The parameters defines the behavior: * all-1-data-no: th
                                   ^^^^^^^
```
You should probably use "define".

#### Section 3.10.4, paragraph 5
```
mer is disabled. [RFC8724] do not specified any range for these timers. [RFC9
                                  ^^^^^^^^^
```
After the auxiliary verb "do", use the base form of a verb. Did you mean
"specify"?

#### Section 3.10.5, paragraph 1
```
C fragmentation protocol specifies the the number of attempts before aborting
                                   ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 3.10.5, paragraph 4
```
ket-size: defines the maximum size of a uncompressed datagram. By default, t
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 2
```
C 8724 describes compression rules in a abstract way through a table. |-----
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 13
```
ation address prefix of RFC 8200. Depending if it is respectively an uplink o
                                  ^^^^^^^^^
```
The verb "depend" requires the preposition "on" (or "upon"). (Also elsewhere.)

#### Section 4.3, paragraph 89
```
t, index is 0. Otherwise, index is the the order in the matching list, starti
                                   ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 4.3, paragraph 89
```
 description "Target Value content as a untyped binary value."; } reference "
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 96
```
tor, indicate if this field must be consider for rule selection or ignored ba
                                 ^^^^^^^^^^^
```
There may an error in the verb form "be consider".

#### Section 4.3, paragraph 96
```
gnored based on the direction (bi-directional, only uplink, or only downlink
                               ^^^^^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 4.3, paragraph 127
```
siderations This document registers one URIs and one YANG modules. 7.1. URI R
                                    ^^^^^^^^
```
Don't use the number "one" with plural words. Did you mean "one URI", "a URI",
or simply "URIs"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
Robert Wilton Former IESG member
(was Discuss) No Objection
No Objection (2022-10-06 for -18) Sent
Thanks for addressing my comments, I've cleared my discuss. I've put one further suggestion related to the descriptions/references in my email response.