[Gen-art] Genart last call review of draft-ietf-mpls-rfc8287-len-clarification-02

[Ines Robles via Datatracker]

Reviewer: Ines Robles
Review result: Ready with Issues

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-mpls-rfc8287-len-clarification-02
Reviewer: Ines Robles
Review Date: 2019-07-30
IETF LC End Date: 2019-07-31
IESG Telechat date: Not scheduled for a telechat

Summary:

I believe the draft is technically good. This document is well written.

The document updates RFC8287 by clarifying the length for the following Segment
ID Sub-TLVs: IPv4 IGP-Prefix Segment ID Sub-TLV, IPv6 IGP-Prefix Segment ID
Sub-TLV and IGP-Adjacency Segment ID Sub-TLV.

There are some minor issues detailed below that should be addressed.

Major issues: Not found

Minor issues:

1- Section 3 - Requirements notation is not complete, it should be added:  "NOT
RECOMMENDED" and "...are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown here."

2- Figure of Section 4.2: Type = 35 (IPv4 IGP-Prefix SID) ---> Type = 35 (IPv6
IGP-Prefix SID)

2.1- It would be nice if the figures have a caption where we can point to the
figure number, and the figure number is referenced in the text. The same for
the table of Section 4.3.

3- Question: What do you think?

I think it would be nice to explain a bit more the length for the different
combinations of the table of Section 4.3, e.g. with tables as detailed below:

+-+---+
|Field   | Parallel (octets) |
| rfc8287#section-5.3+-+--+--+
|   | Any | OSPF | ISIS |
+-+-+--+--+
|  Local Interface ID|  4  |   4  |   4  |
+-+-+--+--+
| Remote Interface ID |  4  |   4  |   4  |
+-+-+--+--+
| Advertising Node Identifier  |  4  |   4  |   6  |
+-+-+--+--+
|  Receiving Node Identifier |  4  |   4  |   6  |
+-+-+--+--+
|   Reserved |  2  |   2  |   2  |
+-+-+--+--+
| Adj. Type + Protocol |  2  |   2  |   2  |
+-+-+--+--+
|   Sum Total octets =  |  20 |  20  |  24  |
+-+-+--+--+

+-+---+
|Field|   IPv4 (octets)   |
| rfc8287#section-5.3 +-+--+--+
|| Any | OSPF | ISIS |
+-+-+--+--+
|  Local Interface ID |  4  |   4  |   4  |
+-+-+--+--+
| Remote Interface ID |  4  |   4  |   4  |
+-+-+--+--+
| Advertising Node Identifier   |  4  |   4  |   6  |
+-+-+--+--+
|  Receiving Node Identifier |  4  |   4  |   6  |
+-+-+--+--+
|   Reserved  |  2  |   2  |   2  |
+-+-+--+--+
| Adj. Type + Protocol |  2  |   2  |   2  |
+-+-+--+--+
|   Sum Total octets = |  20 |  20  |  24  |
+-+-+--+--+

+-+---+
|Field|   IPv6 (octets)  |
| rfc8287#section-5.3   +-+--+--+
|   | Any | OSPF | ISIS |
+-+-+--+--+
|  Local Interface ID|  16 |  16  |  16  |
+-+-+--+--+
| Remote Interface ID  |  16 |  16  |  16  |
+-+-+--+--+
| Advertising Node IdentifieR   |  4  |   4  |   6  |
+-+-+--+--+
|  Receiving Node Identifier  |  4  |   4  |   6  |
+-+-+--+--+
|   Reserved  |  2  |   2  |   2  |
+-+-+--+--+
| Adj. Type + Protocol |  2  |   2  |   2  |
+-+-+--+--+
| s

[Gen-art] Genart last call review of draft-ietf-oauth-resource-indicators-05

[Stewart Bryant via Datatracker]

Reviewer: Stewart Bryant
Review result: 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-oauth-resource-indicators-05
Reviewer: Stewart Bryant
Review Date: 2019-07-30
IETF LC End Date: 2019-08-05
IESG Telechat date: Not scheduled for a telechat

Summary: A well written document ready for publication.  It has one very minor
nit that needs to be addressed at some point.

Major issues: None

Minor issues: None

Nits/editorial comments:  JWT is not in the well known list and does not seem
to be expanded on first use,


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

[Gen-art] Genart last call review of draft-ietf-iasa2-rfc7776bis-02

[Stewart Bryant via Datatracker]

Reviewer: Stewart Bryant
Review result: 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-iasa2-rfc7776bis-02
Reviewer: Stewart Bryant
Review Date: 2019-07-30
IETF LC End Date: 2019-08-14
IESG Telechat date: Not scheduled for a telechat

Summary: This is a well written document making an administrative update to RFC
7776 and it is ready for publication in this format.

However, given that RFC 7776 may be read by someone who is distressed having
been harassed, and who may not know about errata, I wonder if it would be
better to issue a clean copy of the main RFC with these (and no other) changes.
 If needed the RFC Editor could simply apply these edits to their master copy.

Major issues: None

Minor issues: None

Nits/editorial comments:
  == Outdated reference: A later version (-09) exists of
 draft-ietf-iasa2-rfc7437bis-06

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

[Gen-art] Genart last call review of draft-ietf-lamps-cms-mix-with-psk-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Issues

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-lamps-cms-mix-with-psk-05
Reviewer: Robert Sparks
Review Date: 2019-07-30
IETF LC End Date: 2019-08-06
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard, but with an
issue to address before publication.

Issue: The instructions for IANA are unclear. IANA has to infer what to add to
the registries. I think they _can_ infer what to do for the IANA-MOD registry.
It's harder (though still possible) to guess what to do for IANA-SMIME. They
also have to infer the structure of the new registry this document intends to
create. Explicit would be better. Also, the document anticipates the currently
non-existing anchor to the new registry in the references (security-smime-13).
That generally should also be a tbd to be filled by IANA when the anchor is
actually created.

Nits/editorial comments:

Section 5, 1st paragraph, last sentence: "make use fo" should be "makes use of"

Section 9, 1st sentence : "in the Section 5" should be "in Section 6". (That's
two changes - the removal of a word, and a correction to the section number).

Micronit: In the introduction, you say "can be invulnerable to an attacker".
"invulnerable" is maybe stronger than you mean?


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