[Gen-art] Review Assignments

[Jean Mahoney via Datatracker]

Hi all,

The following reviewers have assignments:

Last calls:

Reviewer   Type  LC end Draft
Matt Joras Last Call 2022-11-20 draft-ietf-sfc-oam-packet-02
Matt Joras Last Call 2022-11-03 draft-ietf-stir-messaging-06
Meral Shirazipour  Last Call 2023-01-17 draft-ietf-avtcore-rfc7983bis-07

Next in the reviewer rotation:

  Suhas Nandakumar
  Pete Resnick
  Gyan Mishra
  Reese Enghardt
  Paul Kyzivat
  Stewart Bryant
  Roni Even
  Thomas Fossati
  Dan Romascanu
  Joel Halpern

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End LC Template --

-- Begin Telechat Template --
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-lpwan-schc-over-sigfox-20

[Eric Vyncke (evyncke)]

Hello Elwyn,

Let me chime in as the responsible AD for the LPWAN WG.

First, "better late than never" ;-) I.e., thank you very much for your review. 
All reviews always help to improve the quality of the IETF work.

About the review major issues, I do not intend to request another WG Last Call 
as the changes in the document have not heavily changed the technical aspects. 
Please also note that the larger than 5 authors count is explained in the 
shepherd's write-up and has been approved by me: there is a Ph.D. student and 
his associated academia, which usually leads to a more lenient approach to the 
authors count (else it is indeed a valid observation).

Also, the LPWAN charter contains “The Working Group will focus on enabling IPv6 
connectivity over the following selection of Low-Power Wide-Area technologies: 
SIGFOX, LoRa, WI-SUN and NB-IOT. These technologies will be used as the 
baseline technologies for future work.”. I.e., it is not the role of the IETF 
to review the Sigfox specifications in details (about the points about 
geolocation and other fields), but is limited to specify SCHC over Sigfox.

I will let the authors reply to your other points as they look valid. Thanks 
again.

Regards

-éric


On 05/01/2023, 01:38, "Elwyn Davies via Datatracker" mailto:nore...@ietf.org>> wrote:


Reviewer: Elwyn Davies
Review result: Not Ready


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.


For more information, please see the FAQ at


 
.


Document: draft-ietf-lpwan-schc-over-sigfox-20
Reviewer: Elwyn Davies
Review Date: 2023-01-04
IETF LC End Date: 2022-12-20
IESG Telechat date: 2023-01-05


Summary:
Not ready. I notice that major edits have been done to this document since the
IESG reviews raised some serious Discuss points. Aside from some serious
points about the scope of the profile(s) in this review and whether there are
multiple profiles involved, I think that the scope of the changes made deserve
working group level review to ensure that the changes are technically accurate.
I apologize for the late delivery of this review. I contracted Covid during
the Last Call period and it has taken me some time to recover.


Major issues:


s1, para 4: It should be made explicit whether the document sets out a single
set of parameters, etc., forming a single profile or whether variations are
available so that more than one profile is possible. The word 'recommended'
implies that there could be variations. If so how would an implementation/user
know which profile was in use. It has been noted elsewhere in reviews that
there are several versions of the Sigfox specification mentioned on the web
page which gives access to the [sigfox-spec]. Does this profile apply to all
versions of the specification? If not how does a device know which profile is
used with which specification? This comment reflects inpart a Comment point
raised by Roman Danyliw


s3.2: This section states:


"Messages sent from the Device to the Network are delivered by the
Sigfox network (NGW) to the Network SCHC C/D + F/R through a
callback/API with the following information:


* Device ID


* Message Sequence Number


* Message Payload


* Message Timestamp


* Device Geolocation (optional)


* Received Signal Strength Indicator (RSSI) (optional)


* Device Temperature (optional)


* Device Battery Voltage (optional)"


As far as I can see, the [sigfox-spec] makes no mention of how or where the
timestamp, geolocation information, device temperature and battery voltage are
encoded and the format used. I take it Message Counter and Message Sequence are
related in some way. How?


Minor issues:


Header: More than 5 authors are listed. This may now have been approved.


s1: Before embarking on descriptions that refer to elements of the Sigfox
network infrastructure, the document should tell the reader where s/he can find
a definitive description of the elements. Referring to the relevant section of
RFC 8376 would be useful, but a reference to a Sigfox document with an
overview of the system would be very useful. The Sigfox Radio Specifications
document is at too detailed a level to cover this requirement. [Aside: I found
this document very hard work!]


s2: The reader is also expected to be familiar with the Sigfox terminology.


s3.2, para 1: "The uplink message size is 12 bytes in size.". Firstly: Uplink
messages are variable in size depending on the requested payload. The payload
can be up to 12 bytes. Secondly: This is the application level size. Six bytes
of header are added in the link layer together with authentication if used. 
Further bytes are added in the physical layer.


s8.2: I think RFC8376 is normative as the terminology used there is required