[Gen-art] Review Assignments

[Jean Mahoney via Datatracker]

Hi all,

The following reviewers have assignments:

Last calls:

Reviewer   Type  LC end Draft
Elwyn Davies   Last Call 2019-09-05 draft-ietf-cbor-array-tags-07
Meral Shirazipour  Last Call 2019-09-02 draft-ietf-tls-sni-encryption-05
Dale WorleyLast Call 2019-09-03 draft-ietf-ippm-stamp-07
Peter Yee  Last Call 2019-09-03 draft-ietf-pim-reserved-bits-03

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Roni Even
  Tim Evens
  Fernando Gont
  Vijay Gurbani
  Wassim Haddad
  Joel Halpern
  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen

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-pce-stateful-path-protection-08

[Pete Resnick]

Hi Dhruv,

On 29 Aug 2019, at 5:17, Dhruv Dhody wrote:


Hi Pete,

Thanks for your review and nits. Just snipping to two points...


OLD
 |   PT  | Path Protection Association Flags 
|S|P|

NEW
 |   PT  |Unassigned 
|S|P|




I feel it is important to keep the name "flags" in the figure to match
with the text following the figure. Also this seems to be our usual
practice in past documents as well. We can change to just "flags" if
you would prefer that?

For context ->

   The format of the Path Protection Association TLV (Figure 1) is as
   follows:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = TBD2 |  Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   PT  | Path Protection Association Flags |S|P|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 1: Path Protection Association TLV format

   Path Protection Association Flags (32 bits) - The following flags 
are

   currently defined -


So this is what confused me about the diagram: "Path Protection 
Association Flags" is the entire 32-bit field, which includes PT, S, and 
P. But in the diagram, you have the unassigned 24 bits labeled "Path 
Protection Association Flags", which seems incorrect. Perhaps 
"Unassigned Flags" would be best.



Section 6:

At the top of the section, I suggest putting in the following:

[Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain 
"TBD1" through
"TBD5" those should be replaced by the values that IANA assigns. 
Also, Section
4.5 includes several occurrences of the phrase "(Early allocation by 
IANA)";
please confirm that the value mentioned there is correct and delete 
that phrase

from the document before publication.]



I would suggest the authors to remove the phrase "(Early allocation by
IANA)" in the document now as the referenced draft is in RFC-EDITOR
queue and the early allocation tag is removed in the IANA page -
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects


That's fine too.

pr
--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best

___
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-core-senml-etch-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Nits

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-core-senml-etch-05
Reviewer: Robert Sparks
Review Date: 2019-08-29
IETF LC End Date: 2019-09-02
IESG Telechat date: 2019-09-05

Summary: Ready for publication as a Proposed Standard RFC, but with nits to
consider before publication

Nits:

Since the string "-etch-" is in the media type, it might be nice to say in the
document where it came from.

I think the text in the interoperability considerations sections of the
registrations could be improved. You mean to talk about unrecognized keys, not
unrecognized key-value pairs. I also think the body of the RFC should have a
very short extensibility section that explicitly says you're doing a similar
thing as 8424 section 4.4 and point to that section.

I am a little uncomfortable with the "Fragment Identification" section (4) of
this document - it feels like a "do what we mean" statement. I don't have text
to suggest. It may well be that it will be dead-obvious to an implementer what
to do, but it makes me uneasy.


___
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-pce-stateful-path-protection-08

[Dhruv Dhody]

Hi Pete,

Thanks for your review and nits. Just snipping to two points...

> OLD
>  |   PT  | Path Protection Association Flags |S|P|
> NEW
>  |   PT  |Unassigned |S|P|
>

I feel it is important to keep the name "flags" in the figure to match
with the text following the figure. Also this seems to be our usual
practice in past documents as well. We can change to just "flags" if
you would prefer that?

For context ->

   The format of the Path Protection Association TLV (Figure 1) is as
   follows:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type = TBD2 |  Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   PT  | Path Protection Association Flags |S|P|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 1: Path Protection Association TLV format

   Path Protection Association Flags (32 bits) - The following flags are
   currently defined -

  Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
  [RFC4872] to indicate if the LSP is working or protection LSP.

  Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
  [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
  S flag is ignored if the P flag is not set.

  Protection Type (PT): 6 bits - This field is as defined in
  Section 14.1 of [RFC4872] to indicate the LSP protection type in
  use.

  Unassigned bits are considered reserved.  They MUST be set to 0 on
  transmission and MUST be ignored on receipt.


> Section 6:
>
> At the top of the section, I suggest putting in the following:
>
> [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" 
> through
> "TBD5" those should be replaced by the values that IANA assigns. Also, Section
> 4.5 includes several occurrences of the phrase "(Early allocation by IANA)";
> please confirm that the value mentioned there is correct and delete that 
> phrase
> from the document before publication.]
>

I would suggest the authors to remove the phrase "(Early allocation by
IANA)" in the document now as the referenced draft is in RFC-EDITOR
queue and the early allocation tag is removed in the IANA page -
https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects

Thanks!
Dhruv

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