[Gen-art] Review Assignments

[Jean Mahoney via Datatracker]

Hi all,

The following reviewers have assignments:

For telechat 2021-02-25

Reviewer   Type  LC end Draft
Christer Holmberg  Last Call 2021-02-19 draft-ietf-cdni-uri-signing-21

Last calls:

Reviewer   Type  LC end Draft
Theresa Enghardt   Last Call 2021-02-22 draft-ietf-tcpm-2140bis-09
Suhas Nandakumar   Last Call 2021-01-26 
draft-ietf-mpls-lsp-ping-registries-update-08
Meral Shirazipour  Last Call 2021-02-25 draft-ietf-ntp-port-randomization-06
Robert Sparks  Last Call 2021-02-25 
draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Next in the reviewer rotation:

  Wassim Haddad
  Jouni Korhonen
  Mohit Sethi
  Pete Resnick
  Suhas Nandakumar
  Elwyn Davies
  Dale Worley
  Peter Yee
  Linda Dunbar
  Gyan Mishra

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

[Gen-art] Genart last call review of draft-ietf-tcpm-2140bis-09

[Theresa Enghardt via Datatracker]

Reviewer: Theresa Enghardt
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-tcpm-2140bis-09
Reviewer: Theresa Enghardt
Review Date: 2021-02-19
IETF LC End Date: 2021-02-22
IESG Telechat date: Not scheduled for a telechat

Summary: This document is fairly clear and concise, however there are a few
minor issues and nits that should be addressed before publishing.

Major issues: None.

Minor issues:

Abstract:

"This memo provides guidance to TCP implementers that are intended to
   help improve convergence to steady-state operation without affecting
   interoperability."
I think it'd be good to clarify what "steady-state operation" or "steady-state
behavior" means in this context, either here or in the introduction where this
term is used again. Assuming both terms refer to the same concept, please
consider unifying the terms.

Introduction:

"Path information shared across
   SYN destination port numbers assumes that TCP segments having the
   same host-pair experience the same path properties, irrespective of
   TCP port numbers."
Does this mean that one should rather avoid sharing information between
connections with different SYN destination port numbers? If there is a
recommendation, I think it'd be good to be explicit about it. If no
recommendation is being made, maybe the doc should state that these are
assumptions that implementers should be aware of. I think it's also worth
noting that, even if connections share the same host-pair and SYN destination
port numbers, paths and path conditions can always change over time. It'd be
good to put in a reference to Section 8.1 here, where there's more discussion
about these assumptions.

4. The TCP Control Block (TCB)

As Appendix B mentions that it may be unsafe to share other state, perhaps it's
good to add a sentence about this here and refer to Appendix B for more details.

"One class is clearly host-pair dependent (#, e.g., MSS, MMS, PMTU, RTT)..."
Please consider adding a brief explanation why it's "clearly" host-pair
dependent. Discussion on this could also be added to Section 8.1 and then
refered to here. Also, isn't this information path-dependent rather than
host-dependent? If the doc is making an assumption about host pairs and paths
here, please make it explicit.

6.1 Initialization of the new TCB

In the table "TEMPORAL SHARING - TCB Initialization", "or not cached" is added
for old_MMS_S and old_MMS_R, but not for other information in this table.
Please consider adding a brief explanation and/or clarifying this point here.

Is there any notion on information being outdated or expiring, as path
conditions might change over time?

"Note that PMTU feedback is cached at the IP layer" - Is this true even with
PLPMTUD? I think it's worth putting in a brief clarification of whether this
depends on the mechanism, as PMTUD and PLPMTUD are explicitly introduced in
Section 3.

7.2. Updates to the new TCB

Here, the row with old_PMTU and curr_PMTU says "PMTUD+ / PLPMTUD". In Section
6.2, a similar row only says "PMTUD+". Is this intentional, i.e., with PLPMTU,
can PMTU only be shared with Temporal Sharing and not with Ensemble Sharing?

8. Compatibility Issues

What kind of compatibility is meant here? Is it compatibility between
implementations? If not, please consider renaming this section, e.g., to
"Issues with TCB information sharing".

8.1. Traversing the same network path
"When TCB information is shared across different SYN destination ports,
   path-related information can be incorrect"
Please consider adding an explanation here. Why is this true specifically for
SYN destination ports?

11. Updates to RFC 2140

"addressing RSS in both the send and receive direction"
RSS is not defined in this doc.

12. Security Considerations
"These presented implementation methods do not have additional
   ramifications for explicit attacks."
What are explicit attacks, and are denial-of-service attacks not explicit?

"TCB sharing may be susceptible to denial-of-service attacks […]"
Please consider clarifying the attack scenario here: Is it that an attacker
opens many connections, and then each new connection gets state from the other
ones, so the denial-of-service attack's impact is increased due to TCB sharing?
Is there a potential for a denial-of-service attack preventing TCB sharing?

Can there be any privacy implications of sharing connection state, e.g.,
between connections of different applications, or within the same application
such as between browser tabs?

Nits/editorial comments:

3. Terminology:

Some terms appear to be named inconsistenly: MMS_S uses "_S" suffix, but
sendMSS uses "send" prefix to denote send direction. Can th

[Gen-art] Genart last call review of draft-ietf-cdni-uri-signing-21

[Christer Holmberg via Datatracker]

Reviewer: Christer Holmberg
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-cdni-uri-signing-21
Reviewer: Christer Holmberg
Review Date: 2021-02-19
IETF LC End Date: 2021-02-19
IESG Telechat date: 2021-02-25

Summary: The document is ready for publication. A very minor comment is that I
do think that some of the paragraphs were quite long a detailed, and could
perhaps have been split into separate paragraphs in order to make the text more
clear.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A



___
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-v6ops-ipv6-ehs-packet-drops-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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-v6ops-ipv6-ehs-packet-drops-05
Reviewer: Robert Sparks
Review Date: 2021-02-19
IETF LC End Date: 2021-02-25
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC



___
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-cdni-uri-signing-21

[Barry Leiba]

Thanks for the review, Christer!

Barry

On Fri, Feb 19, 2021 at 4:39 PM Christer Holmberg via Datatracker
 wrote:
>
> Reviewer: Christer Holmberg
> 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-cdni-uri-signing-21
> Reviewer: Christer Holmberg
> Review Date: 2021-02-19
> IETF LC End Date: 2021-02-19
> IESG Telechat date: 2021-02-25
>
> Summary: The document is ready for publication. A very minor comment is that I
> do think that some of the paragraphs were quite long a detailed, and could
> perhaps have been split into separate paragraphs in order to make the text 
> more
> clear.
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments: N/A
>
>
>

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