[core] (Chair's review) TR: New Version Notification for draft-ietf-core-hop-limit-03.txt

<mohamed.boucadair@orange.com> Tue, 26 February 2019 14:40 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D57C9130E5D for <core@ietfa.amsl.com>; Tue, 26 Feb 2019 06:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N-kX-KtQrjnr for <core@ietfa.amsl.com>; Tue, 26 Feb 2019 06:40:26 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDDF128CE4 for <core@ietf.org>; Tue, 26 Feb 2019 06:40:26 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4481gr68P9zCrq0; Tue, 26 Feb 2019 15:40:24 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 4481gr5VknzDq7h; Tue, 26 Feb 2019 15:40:24 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([fe80::f04d:ad3c:61de:a175%21]) with mapi id 14.03.0435.000; Tue, 26 Feb 2019 15:40:24 +0100
From: <mohamed.boucadair@orange.com>
To: "Carsten Bormann (cabo@tzi.org)" <cabo@tzi.org>
CC: "core@ietf.org" <core@ietf.org>
Thread-Topic: (Chair's review) TR: New Version Notification for draft-ietf-core-hop-limit-03.txt
Thread-Index: AdTN4TH0Ek4X9B27QZ2qxYSm69RoRg==
Date: Tue, 26 Feb 2019 14:40:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA257C6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/V5zG0wvBj8NqrGhBZmZFLgA0qC8>
Subject: [core] (Chair's review) TR: New Version Notification for draft-ietf-core-hop-limit-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 26 Feb 2019 14:40:29 -0000

Hi Carsten, 

This new version takes into account your review. More details are provided below: 

# Major

1. Is adding a hop-limit option now a recommendation that applies to
   all CoAP proxies?

The text is updated to clarify the scope, that is "CoAP proxies which understand the hop limit option". No "SHOULD deploy" level statement is included; such statement may be considered in future BCPs. 

2. I don't understand the rule about using cached copies.  As a
   general observation, rules like this should not simply be stated
   without a rationale why they are the way they are.

Added a clarification text which basically points to 5.6 of 7252.

# Minor

1. The text could include a sentence about what happens when a proxy
   does not understand the option (nothing bad, but loops consisting
   entirely of such proxies will not be terminated).

Added NEW text to describe the implications. 

2. The way the diagnostic payloads are formed seems to rely on a space
   separator, but does not exclude its use inside the separated items.

Added a NEW sentence to call out this. 

# Editorial

1. The terminology could be aligned some more (e.g., avoid "agent",
   use "request" or "response" instead of "message" where
   possible). Details in the editorial comments.

All your edits were implemented. 


> -----Message d'origine-----
> De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Envoyé : mardi 26 février 2019 15:31
> À : Tirumaleswar Reddy; Reddy K; BOUCADAIR Mohamed TGI/OLN; Jon Shallow
> Objet : New Version Notification for draft-ietf-core-hop-limit-03.txt
> A new version of I-D, draft-ietf-core-hop-limit-03.txt
> has been successfully submitted by Mohamed Boucadair and posted to the
> IETF repository.
> Name:		draft-ietf-core-hop-limit
> Revision:	03
> Title:		Constrained Application Protocol (CoAP) Hop Limit Option
> Document date:	2019-02-26
> Group:		core
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-core-hop-
> limit-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-core-hop-limit-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-core-hop-
> limit
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-core-hop-limit-
> 03
> Abstract:
>    The presence of Constrained Application Protocol (CoAP) proxies may
>    lead to infinite forwarding loops, which is undesirable.  To prevent
>    and detect such loops, this document specifies the Hop-Limit CoAP
>    option.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF Secretariat