Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT)

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 22 January 2020 01:08 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE31200C4; Tue, 21 Jan 2020 17:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv0eJlj6f2wx; Tue, 21 Jan 2020 17:08:15 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2D01200C3; Tue, 21 Jan 2020 17:08:12 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M18APG007638; Wed, 22 Jan 2020 01:08:10 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 832062203B; Wed, 22 Jan 2020 01:08:10 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 6DF242203A; Wed, 22 Jan 2020 01:08:10 +0000 (GMT)
Received: from LAPTOPK7AS653V (089144205018.atnat0014.highway.webapn.at [89.144.205.18]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00M189GI026112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 01:08:09 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Benjamin Kaduk' <kaduk@mit.edu>, 'The IESG' <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-flags@ietf.org, 'Hariharan Ananthakrishnan' <hari@netflix.com>, pce-chairs@ietf.org, pce@ietf.org
References: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com>
In-Reply-To: <157965240227.28983.6586692675642034521.idtracker@ietfa.amsl.com>
Date: Wed, 22 Jan 2020 01:08:08 -0000
Organization: Old Dog Consulting
Message-ID: <01ab01d5d0c0$694f4a80$3beddf80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGVwRM+aR0Bc0s3Gd8LHtraiajqN6h19eWA
Content-Language: en-gb
X-Originating-IP: 89.144.205.18
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25182.003
X-TM-AS-Result: No--14.512-10.0-31-10
X-imss-scan-details: No--14.512-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25182.003
X-TMASE-Result: 10--14.511900-10.000000
X-TMASE-MatchedRID: eVEkOcJu0F7xIbpQ8BhdbPHkpkyUphL9ekMgTOQbVFtGM2uNXRqsUm4R Zq5Bvfozw/UM+vlRppuLv76tv2biYCo5AFN8VXjwQz/LkQyz8mY9e7UvbyNKcfOW/sUTBY7L1GW bKN8y66//FTSTt61fe5vKavz+aosbRXNf1eTQ0puqDSBu0tUhrxlKjo8zguyKAv57j5eT9BbX6a ILJJMXlwUBks9NZRM+tfo+cp8qv6v7IXgURPQAHEVOF9zLtdyMzgjA0fz2uiDAJMh4mAwEGyfdT kfaZpbHQOaAfcvrs37xHXxxAO/d2d/+vxvQP253kUvc5mAlMkFt/p7hYq0idEIvWnnxlDGfZS/C gJhZe5bi8zVgXoAltkWL4rBlm20vt7DW3B48kkErN8z0HohG3voLR4+zsDTtJC9jS54qtzVDXjk TIiVB5fsGhO/r7k86go20aeSJzdcWEdnqV6kVYw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/AISesKmlfLFdSPU6AOixH_kpxl4>
Subject: Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 01:08:17 -0000

> Thanks for this clear and well-written document!  I just have a couple
> of editorial comments that probably don't even need a response.

Thanks for reading, Ben.

Every review comment deserves a response.

> Section 4
>
>  There will remain an issue with compatibility between implementations
>  of RFC 8231 that might set any of the unassigned flags, and current
> (such as [RFC8281]) and future (such as
>  [I-D.ietf-pce-lsp-control-request]) specifications.  That problem
>  cannot be fixed in old implementations by any amount of
>  documentation, and can only be handled for future specifications by
>  obsoleting the Flags field and using a new technique.  Fortunately,
>  however, most implementations will have been constructed to set
>  unused flags to zero which is consistent with the behavior described
>  in this document.
>
> I had a little bit of trouble reading this, as I keep expecting the
> first sentence to be saying that there is a legitimately-allocated flag
> value that is set with intent to change behavior, but it doesn't really
> say anything specifically about a flag value getting allocated (or
> used).

How about this becomes...

  There will remain an issue with compatibility between implementations
  of RFC 8231 that might set any of the unassigned flags, and current
 (such as [RFC8281]) and future (such as
  [I-D.ietf-pce-lsp-control-request]) specifications that assign specific
  meanings to flags if set.

> W.r.t. obsoleting Flags vs. relying on "most implementations" to be
> consistent with this document's recommendations, is it worth being more
> clear about the conclusion that this document is drawing, namely that
> the risk of bad interactions is sufficiently small that there is no
> desire to incur the cost of obsoleting/replacing the Flags field?

How about
OLD
   Fortunately,
   however, most implementations will have been constructed to set
   unused flags to zero which is consistent with the behavior described
   in this document.
NEW
   Fortunately,
   however, most implementations will have been constructed to set
   unused flags to zero which is consistent with the behavior described
   in this document and so the risk of bad interactions is sufficiently
   small that there is no need to obsolete the existing Flags field.
END

Thanks,
Adrian