[core] Roman Danyliw's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 15 October 2019 12:14 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B71631200DE; Tue, 15 Oct 2019 05:14:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-hop-limit@ietf.org, Jaime Jimenez <jaime@iki.fi>, core-chairs@ietf.org, jaime@iki.fi, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.105.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <157114165574.18182.16808947015511781451.idtracker@ietfa.amsl.com>
Date: Tue, 15 Oct 2019 05:14:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/dAnLfT4VqoQNGXkvhnCwYWAHwZU>
Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Oct 2019 12:14:16 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-core-hop-limit-06: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-hop-limit/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 1.0, What is an “involved application agent”? ** Section 1.1 Per “CoAP proxies that do not have specific knowledge that proxy loops are avoided in some way …”, how would a proxy know that? ** Section 7. Perhaps also add that a malicious proxy can induce more subtle failures than just straight packet drops by manipulating the Hop Limit value. ** Editorial Nits: -- Section 1.1. Editorial. s/ The Hop-Limit option has originally been designed for a/The Hop-Limit option was originally designed for a/ -- Section 3. Recommend being clearer on what it means for “Hop-Limit detection gets broken” when proxies on boundaries re-write the hop limit value. Perhaps something on the order of: s/ This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop and so Hop-Limit detection gets broken ./ This modification should be done with caution in case proxy-forwarded traffic repeatedly crosses the administrative domain boundary in a loop rendering negating the efficacy of loop detection through the Hop-Limit field. -- Section 4. Per “Only one information per proxy should appear in the diagnostic payload”, what is “one information” (it seems like a few words are missing here)? -- Section 4. Per “Doing so allows to limit the size of the TBA1 …”, this sentence doesn’t parse for me.
- [core] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
- Re: [core] Roman Danyliw's No Objection on draft-… mohamed.boucadair