Re: [tsvwg] draft-ietf-tsvwg-transport-encrypt-20: (with COMMENT)

[Gorry Fairhurst <[e-mail]>]

The editors have just posted a new revision of the draft on 
Considerations around Transport Header Confidentiality, Network 
Operations, and the Evolution of Internet Transport Protocols.

Revision 21 follows the IESG review and includes revised text after 
comments from Zahed, Erik Kline, Rob Wilton, Eric Vyncke, Roman Danyliw, 
and Benjamin Kaduk. We're greatful for the comments and the new 
suggestions and think we have new text which might address these 
comments. A checklist follows, in case those making comments wish to 
also follow-up.

Besy wishes,

Gorry and Colin


---

    Erik Kline:

    [ section 1 ] * "Current uses of transport header information in the
    network are explained, which can be beneficial or malicious. " I
    suppose it's the "uses of..." that might be seen as beneficial or
    malicious, but I briefly read it as the explanation that was
    beneficial or malicious. - changed.

    * "provide information can support" -> "provide information that can
    support" - Changed.

    [ section 2.2.1 ] * "inferred from a measure the variation" ->
    "inferred from a measure of the variation", - changed.

    [ section 2.2.2 ] * "that they does not recognise" -> "that they do
    not recognise" - Changed.

    [ section 2.3.4 ] * "the network the path" -> "the network path" -
    changed.

    [ section 2.3.6 ] * "A variety and open source and proprietary tools"
    -> "A variety of open source and proprietary tools" - changed,
    updated also by BK.

    [ section 2.4 ] * "to cause the header compression to a fall back" ->
    "to cause the header compression to fall back" - changed.

    [ section 3 ] * "provides data need to" -> "provides data needed to"
    - changed.

    [ section 4 ] * "In some case," -> "In some cases,"- changed.

    [ section 6.1 ] * "part of encapsulation protocol" -> "part of the
    encapsulation protocol", - Changed.

    [ section 7 ] * "make informed choice" -> "make informed choices"-
    Changed.

    Lars/Joel: - Already resolved.

    Rob Wilton:

    * A couple of other minor nits that I spotted: caries -> carries -
    Changed.

    * Example considered -> example that considered - Changed.

    Eric Vyncke:

    * First a generic comment (close to be a DISCUSS): what about the
    impact on ECMP (or even LAG) ? Many ECMP hashes are based on a
    5-tuple and encrypting the transport header will force the use of a
    3-tuple.  There should be a section on the important of getting some
    field with entropy per 'flow'.  ECMP looks for ports but aren't port
    part of the (encrypted) transport header ? This is the ambiguity that
    concerns me.  IPv6 flow labels can be used (section 2.2.2 text is
    good on this), then ECMP problem is solved but 1) not all traffic is
    IPv6 (and I regret it).  - Done.

    * "Common issues concerning IP address sharing are described in
    [RFC6269]." - Done.  Moved.

    * Section 2.2.1 -- This is an impressive text by its clarity while
    being short and dense.  I just wonder about the absence of in-band/
    in-situ measurements, only active/passive probing is mentioned (see
    other IETF works such as draft-ietf-ippm-ioam-data or draft-ietf-
    6man-ipv6-alt-mark -- the former only briefly cited in section 3.3
    and in more details in section 6, but should section 2.2.1 already
    touch the topic ?) - Done. added intro to iOAM.

    * Section 2.2.1 -- Should the part about IPv6 extension headers
    mention draft-ietf-ippm-ioam-data? - Done

    * Section 2.2.1 -- Should the part about IPv6 extension headers
    mention draft-ietf-6man-ipv6-alt-mark? - Done.

    *Section 2.3.4 -- The DoS attack aspect is possibly too brief...
    (notably because it is only against the infrastructure and not a
    volumetric DoS attack against a end-user node).  How to "scrub"
    suspicious traffic if the traffic in "uncharacterized" ? - Done.
    Added a sentence.

    * Section 2.4 --- For many constrained network, compression is really
    important as well as QoS/precedence of some traffic.  Should there be
    a dedicated section about such constrained network ? (for header
    compression and precedence/QoS setting) -Done.  Added a section.

    * -- Please add LPWAN WG RFC 8724 in the compression section - Done.

    * Section 6.1 -- Please consider defining a "Maintenance Domain" - Done

    * OAM has already been expanded - Done in -21.

    Roman Danyliw :

     - Slightly longer list - covered by another email.

    Benjamin Kaduk:

    - All NiTs accepted and applied.

    - Comments incorporated, except where questions raised that could not
    be answered.

Zahed:

    * It has been mentioned number of times that traffic volume, traffic
    patterns can be used to perform network measurements (section 2.2.1
    and section 2.3.6). how solid are these claims? - We did not add text
    on ML, and other methods.

    * "on-path" and "in-network" both have been used to indicate
    particular network devices.  This creates some confusion to me. If
    they are interchangeably used in this document and indicate same
    network devices then I would recommend to use only one.  If they are
    supposed to indicate different devices then please include the
    definition of those.  This will help readers like me. - Done. 
reviewed use
    of "network" and clarified to remove one term and consistently say
    when devices need to be on path.

    * Section 2.2.2 : The utility of these measurements depends on the
    type of bearer and number of mechanisms used by network devices. -
  Done  replaced /bearer/ with segment/link.

    * Section 3.2 : what is DCTP? /DCTCP/ - Done.