Re: [Last-Call] [sfc] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Insufficient" is not an acceptable answer from a reviewer. it is not even an acceptable answer from an AD.

I do understand that your review is on behalf of the TSV Area Directors. If you are not willing to be more clear about what (within the constraints that we are NOT rewriting 8300) is going to be helpful, then we will leave it to the Transport ADs.

We will not play "fetch a rock" / "no not that rock" until you are happy.

Yours,
Joel

On 7/29/2021 11:21 AM, Joseph Touch wrote:
Joel,

I performed this review for the transport area.

An IETF document should never attempt to redefine the word “transport” in a single sentence and refer to an unpublished draft (even mine) to explain. It takes more than that.

On Jul 29, 2021, at 8:01 AM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:

If you want the terminology usage clarified, then what they have proposed is sufficient.

If you want to change RFC 8300, this is not the place to do that.

Agreed, but we cannot continue to propagate the error. At a minimum, the sentence should clarify that the term is being used inconsistently with the rest of IETF as a whole and explain what it means in a stand-alone way. That either warrants a separate (even if brief) section or at least a terminology section entry.

Additionally, it is not feasible to review how their approach - which makes packets bigger, necessarily - without understanding how that tunneling works.

Joe

On 7/29/2021 12:41 AM, Joe Touch wrote:
Insufficient.
On Jul 28, 2021, at 7:09 AM, tirumal reddy <kondtir@xxxxxxxxx> wrote:


Thanks Joseph for the detailed comment and explanation. We plan to add the following text to address the issue:

Note that the term “transport encapsulation” used in this document is equivalent to the term “tunnel encapsulation” used In [ietf-intarea-tunnel].


Cheers,

-Tiru


On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:

    Reviewer: Joseph Touch
    Review result: Not Ready

    This document has been reviewed as part of the transport area
    review team's
    ongoing effort to review key IETF documents. These comments were
    written
    primarily for the transport area directors, but are copied to the
    document's
    authors and WG to allow them to address any issues raised and also
    to the IETF
    discussion list for information.

    When done at the time of IETF Last Call, the authors should
    consider this
    review as part of the last-call comments they receive. Please
    always CC
    tsv-art@xxxxxxxx <mailto:tsv-art@xxxxxxxx> if you reply to or
    forward this review.

    It was very difficult to review this document for IETF transport
    protocol
    considerations.

    Although "transport encapsulation" is indicated repeatedly, it is
    never
    referred to directly or described either in this document or its
    citations. It
    appears to be using this term in the sense of RFC8300, which too
    never defines
    it, but uses examples that are more accurately referred to in the
    IETF as link
    layer protocols or either network or link tunnel protocols (IP in
    IP, GRE,
    VXLAN, Ethernet).

    Regardless of the fact that this confusion originates in RFC8300,
    it needs to
    be addressed here and corrected before this document can be
    reviewed to
    determine if there are any IETF transport area issues.

    The remainder of these notes provide detail of this issue.

    -----

    The document refers back to RFC8300 to define the NSH itself; that
    document
    discusses transport issues just as vaguely (never mentioning a
    particular
    transport protocol), and when it discusses fragmentation, it
    refers to section
    9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had
    expired prior
    to the publication of RFC8300.  Because transport fragmentation
    is, IMO, a
    normative issue, this should not have been permitted.

    Further, Section 9 of that draft incorrectly recommends reliance
    on ICMP
    feedback to address MTU failures when not under a single
    operator’s management.
    That was widely known even then to be insufficient due to
    blackholing; this had
    motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300
    compounds this
    error by simply asserting that the operator should ensure that
    ICMPs are not
    blocked, overlooking the need to address when this is not the case.

    This document cannot ignore that issue and simply refer to RFC8300
    on this
    issue.

    Note that one of the only places an actual encapsulation protocol
    is mentioned
    is RFC8300, in which Section 5 mentions IP and  Section 6.1 Table
    1 describes
    VXLAN-GPE, GRE, and Ethernet – all of which are described as
    “transport
    encapsulation”.

    If, in fact, IETF transport protocols are being used, at some
    point the use of
    an actual IETF transport protocol should be described (e.g., TCP,
    UDP, SCTP,
    DCCP). At that point, the transport issues would be reviewable. As
    the document
    currently stands, it completely ignores such transport issues and
    should not
    proceed until this is addressed and re-reviewed.

    If instead, as I suspect, the term “transport encapsulation”
    actually refers to
    “network layer encapsulation” or “link layer encapsulation” and
    really implies
    some sort of tunnel, there would be no transport area issues to
    review unless
    that tunnel were to include a transport protocol as part of the
    layers of
    encapsulation. If that is the case, the document should be revised
    to replace
    the term “transport” with something that more accurately describes
    VXLAN-GPE,
    GRE, Ethernet, and IP encapsulation using IETF terminology. Note that
    draft-ietf-intarea-tunnels never uses the term “transport” except when
    referring to the use of IETF transport protocols as a tunnel
    layer, e.g. (i.e.,
    the last sentence of Sec 8 of this doc is incorrect in implying
    otherwise).

    (I would also note that neither this doc nor RFC8300 define “transport
    encapsulation” in their terminology; even if they would, they
    should not
    attempt to define it in a way inconsistent with widespread use in
    the IETF).



--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

_______________________________________________
sfc mailing list
sfc@xxxxxxxx
https://www.ietf.org/mailman/listinfo/sfc


--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux