Robert Wilton's No Objection on draft-ietf-quic-manageability-16: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 21 April 2022 13:51 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 471913A1592; Thu, 21 Apr 2022 06:51:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-quic-manageability@ietf.org, quic-chairs@ietf.org, quic@ietf.org, matt.joras@gmail.com, matt.joras@gmail.com
Subject: Robert Wilton's No Objection on draft-ietf-quic-manageability-16: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 8.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <165054910626.9480.17078690803429133558@ietfa.amsl.com>
Date: Thu, 21 Apr 2022 06:51:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iGJaVk9Nueb8v-hPuRRq6S94xlw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2022 13:51:46 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-quic-manageability-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document that is well written and gives a lot of detail about
various aspects of the QUIC.  I would also like to thank Al Morton for his
review and for the authors diligently working with Al to reach a consensus
position.

I have to confess that I find some aspects of this document to be a bit of a
odd duck, which I think that is based on the underlying design goals of QUIC to
maximize privacy and prevent interference.  I.e., a lot of the sections seem to
end up implying that "you can't really do that in easy/reliable way with QUIC,
or you shouldn't do it".  From my reading of this doc, I get the overriding
feeling that QUIC is not really designed to be easily distinguishable from
regular UDP traffic, and at the same time, there seem to be some
recommendations or suggestions about how QUIC traffic should be handled
potentially differently from other UDP traffic under some circumstances.  It
will be interesting to see how QUIC deployment evolves over time, and whether
some operators will restrict its usage to a few well known ports.  Hopefully
not.

A few specific minor comments:

1.
Section 1 states:

   No information in the
   protocol header, even that which can be inspected, is mutable by the
   network.  This is enforced through integrity protection of the wire
   image [WIRE-IMAGE].

Section 2.1 states:

   Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation
   (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or
   protected in any way.

Do these two statements conflict: re protection?

2.
      On long header
      packets, the length of the connection IDs is also present; on
      short header packets, the length of the destination connection ID
      is implicit.

I presume that it is implicit in the sense that each endpoint knows how long
the connection IDs are?

3.
   2.6.  Connection ID and Rebinding

   Further it can be
   used by in-network devices to ensure that related 5-tuple flows are
   appropriately balanced together.

When I read this, I thought that you were talking about ECMP and L2
load-balancing over LAG, but I presume that is not the intention here, and that
you are referring to application layer load balancing?

Regards,
Rob