[core] Review Comments on draft-boucadair-core-hop-limit

Jim Schaad <ietf@augustcellars.com> Thu, 23 August 2018 04:19 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8C01277D2; Wed, 22 Aug 2018 21:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 sf9yechWsTMN; Wed, 22 Aug 2018 21:19:38 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03FA1271FF; Wed, 22 Aug 2018 21:19:34 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Aug 2018 21:15:42 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-boucadair-core-hop-limit@ietf.org
CC: 'core' <core@ietf.org>
Date: Wed, 22 Aug 2018 21:19:26 -0700
Message-ID: <008c01d43a98$7beb5f90$73c21eb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdQ6lZtWzVfWrqOXTka5fHNwSfnzLw==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/_t6CGyKcMY-9DQzVqTaa_4_EdDI>
Subject: [core] Review Comments on draft-boucadair-core-hop-limit
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2018 04:19:40 -0000

Section 3 - para 2 - It would be clearer to me to say that the Hop-Limit
value is between 0 and 255 inclusive rather than talk about the length of
the option because I don't know if that includes all of the option encoding
bytes or not.

Section 3 - para 4 - Probably does not matter, but the current algorithm
wastes one bit.  Check for 0 and then decrement would give one addition
possible field.  It would also compress down the size of the encoded option
faster.

Section 3 - I don't know that you only want to have a proxy information
appearing once.  If it appears multiple times then you can easily spot the
loop.  No real option one way or the other.

Section 3 - Last paragraph - I presume that a border proxy could remove
rather than re-write the option as well.  This would be esp. true if for
example it was changing transports.

Section 4.2 - Someplace there needs to be a discussion on why the values of
C, U and N

I would have expected the values to be
- Critical - no
- Unsafe - no - a proxy which does not understand the option should still
forward it on.  At worst you will get the same behavior as if the option was
not included. 
- NoCacheKey - yes - If you get two gets for the same resource with
different hop counts the proxy should still be able to return the currently
cached value.

Section 5 - There is a potential privacy consideration that may need to be
covered.  The return value is going to provide an eavesdropper a large
amount of information on the configuration of the network.  Is there value
to configuring so that the error but not the trace stack is provided?