Re: [core] Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Mon, 14 October 2019 14:20 UTC

Return-Path: <evyncke@cisco.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 CA23F12002F; Mon, 14 Oct 2019 07:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=J8uCHFer; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dAglmM9K
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 5muWisv7lC8M; Mon, 14 Oct 2019 07:20:31 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A1812013A; Mon, 14 Oct 2019 07:20:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7078; q=dns/txt; s=iport; t=1571062831; x=1572272431; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LFHg3arDPH7zMHt1MTBHYlolDJYALCLbR2WfFSH8tWw=; b=J8uCHFerr3ZpjksSGJoBseFitmIlKcse7qX9u/uKcqwe50qbtLnFeqrL qoEjA1o5hN0DW0PfhV5cPUR3ADSJBK2ky9olpa1SpaMLOOFuLtOwnuNZ/ iMNO8TJLLbQFN/jTLLsT/TONCuuvwvOs5gpXvUw3dKoxNs+H5u1MFnqBg g=;
IronPort-PHdr: 9a23:L7/GlhKcQLRVlefBItmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXEDlPfjhbCESF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CvAABWg6Rd/40NJK1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gUtQBWxXIAQLKoQkg0cDikmCXJd+gUKBEANUCQEBAQwBASMKAgEBhEACF4JHJDgTAgMJAQEEAQEBAgEFBG2FLQyFTAEBAwESEREMAQElEgEPAgEIGgIREgMCAgIwFAEFCwIEAQ0FIoMAAYJGAw4gAQIMpDcCgTiIYXWBMoJ9AQEFgUhBgnsYghcDBoEMKIUWhngYgUA/gREnH4JMPoJhAgECAYEYEgEBCwYBHxcogk8ygiyNCYJmjmWOcwqCIocIig2EBBuCOodOhCyLDINCimuIIpEVAgQCBAUCDgEBBYFpImdYEQhwFWUBgkFQEBSBT4NzhRSFP3QBgSiNWA4Xgi4BAQ
X-IronPort-AV: E=Sophos;i="5.67,295,1566864000"; d="scan'208";a="342917400"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2019 14:20:29 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x9EEKTRU022125 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Oct 2019 14:20:29 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 09:20:29 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 14 Oct 2019 10:20:28 -0400
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 14 Oct 2019 10:20:27 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BD+lKWPZxLMpG/hGO21RqZWnAsUrignFkuZPSuS2kydiePyMQvr55wLzoFoTDiJkhaiYzaQm+TZEE0cUUBsbopNGMgPm7rh9Vpb35Y0onUE978sSFFHLhNsJZGhMwJAd17pBIk3hJlNNZtSl45gXaL0E21K6uUz/TEFXBm9nN3xVmDSD0OkI42hzbljTb0Cevw7VWN+1F3pGwquXjnOqjQuRVzSDkT2mzQkwQAgqSu4JjaMp5YJbaMKEMqG9oFXkbjzuX7sk7hXTqIkYD09GfrizrHlWDiHqqiZUAy67yjvaLEhwiCJMRSyatQ2l7DILm0s03hQK1Etp6ZtzC0OOOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LFHg3arDPH7zMHt1MTBHYlolDJYALCLbR2WfFSH8tWw=; b=PvIAiBWx3e4W5vH9QZBVf3IbenOVKXJTyroWb3jpOMEM9UJWnHGkV1YdFfsK8QVROlO+bbLeIr0aPm8jyMZPl5wKf/LSTvstDufMNUzxr73k3jFL+akzJcwQ68tMGRBdUrqiDhMn+d4hI5xmxVRGO1GTel1v1xM6hlfU8Ok92HP/eRqwO9FF3Clk7cFLY4BO9jWl8fpOBrb0LRyANoAdW6ncQl+5Gqn7Xh4VXpxk6WhGwAJTIFBnQU2D+ZmoV92lQ6mGP5fEPd28u8y6e2wszREb+Biq/Lj5iaZxhCMd0HlwhzDTZYR6dybgD96CQ3Btg8GqvI7a6C5IkOziUKuxQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LFHg3arDPH7zMHt1MTBHYlolDJYALCLbR2WfFSH8tWw=; b=dAglmM9K/daztpVvzj/0raTUu5Og2EuRH23FmGifCBBWEp8eBX+MAShydzlOR4OkVGT2XjDyIiCW0QaNv3DglJT8urDSQA7I8uD1m8GXdqhuqg1QkSciKPgUpPDpdDuwlqmE8lSTZWTf4rB20TlwAlo9kFn21akJm7fTLX/G1VU=
Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4381.namprd11.prod.outlook.com (52.135.37.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Mon, 14 Oct 2019 14:20:25 +0000
Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2347.021; Mon, 14 Oct 2019 14:20:25 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-core-hop-limit@ietf.org" <draft-ietf-core-hop-limit@ietf.org>, Jaime Jimenez <jaime@iki.fi>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)
Thread-Index: AQHVf/7lP7ilONYH8k2b5+ciVLx2UqdVE3gAgAVDGgA=
Date: Mon, 14 Oct 2019 14:20:25 +0000
Message-ID: <BCF94F5A-3CE3-4BA3-B4A0-A8B97AECCD5C@cisco.com>
References: <157077606125.20455.11752074619038685184.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303133C8B1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93303133C8B1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com;
x-originating-ip: [2001:420:c0c1:36:e9f7:9043:77eb:a55c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f48ef38a-2dbe-4b24-0407-08d750b1a832
x-ms-traffictypediagnostic: MN2PR11MB4381:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB4381CD1BEAFF63082B3CDBE9A9900@MN2PR11MB4381.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01901B3451
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(366004)(376002)(136003)(199004)(189003)(110136005)(54906003)(6246003)(486006)(6506007)(58126008)(6512007)(6306002)(66556008)(478600001)(81166006)(81156014)(71190400001)(71200400001)(6436002)(476003)(33656002)(316002)(102836004)(186003)(66946007)(91956017)(6116002)(86362001)(64756008)(229853002)(66476007)(2616005)(76116006)(46003)(66446008)(305945005)(446003)(11346002)(76176011)(7736002)(256004)(14444005)(2906002)(14454004)(99286004)(966005)(224303003)(4326008)(25786009)(6486002)(8936002)(36756003)(5660300002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4381; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: i/kvmGEX2NpNGur6bhc53u95Lig+9WKaihgxGbpYpjuNyZsPN7kTu2TJJUbAQfiHi27+tMdw7WKksnK9YXzce818nYT4RKmCaci5wPgknFWVP+4Px78sdUpIsVLaf+tEFKjZjd5F99QBDtgwzWABgTxS5YmrPn+XbD9V++f8HX4yILHBLg/a6aOUI0zJuZjPwTy729Nc3socX5H7DAhSCVFh3LSirLJYTWKGDcybj6HPdXhrUgkq64iARQeKC7XNUIHzrnTMiqovqZwIPlRjN8JqWc3F28gKtQweu+AorGy6bUJ96+J6rLddTdowwryFVb/Uj4/Tt6qdRgEboAwVS55+WIigUyMCFfb327rBrmrZeAfkkqUOBiej2LYD4+5Jmbex2DawAn3rw3OAIz7U1kmKDTOR82M8Y9coHr87qQNT3YEVk9aOyPbRBLEfrR1GxwVUWuImtWt83eatj7msBA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <D5E8F721924B5042B573C1C4654663F5@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f48ef38a-2dbe-4b24-0407-08d750b1a832
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 14:20:25.6018 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2t/PypOYM4AxnJXSHIr5rH7Ngu0g7Pto5hKj97eV21NZ5aJs9FLkT9jwmwgllECZMez2+5K2s9TeWe14XJJdVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4381
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/mrRCBniJvz5L4Nx_gZkVDhCzLGM>
Subject: Re: [core] Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with COMMENT)
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: Mon, 14 Oct 2019 14:20:34 -0000

Hello Mohamed,

Thank you for your reply.

Look inline for EVY> (and feel free to ignore)

-éric

On 11/10/2019, 09:59, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

    Hi Eric, 
    
    Thank you for the review. 
    
    Please see inline. 
    
    Cheers,
    Med
    
    > -----Message d'origine-----
    > De : Éric Vyncke via Datatracker [mailto:noreply@ietf.org]
    > Envoyé : vendredi 11 octobre 2019 08:41
    > À : The IESG
    > Cc : draft-ietf-core-hop-limit@ietf.org; Jaime Jimenez; core-
    > chairs@ietf.org; jaime@iki.fi; core@ietf.org
    > Objet : Éric Vyncke's No Objection on draft-ietf-core-hop-limit-06: (with
    > COMMENT)
    > 
    > Éric Vyncke 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:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document. I have a couple of COMMENTs
    > (that I would appreciate to see a reply of yours) and one NIT.
    > 
    > Regards,
    > 
    > -éric
    > 
    > == DISCUSS ==
    > 
    > == COMMENTS ==
    > 
    > -- Section 3 --
    > C.1) "Because forwarding errors may occur if inadequate Hop-Limit values
    >    are used, proxies at the boundaries of an administrative domain MAY
    >    be instructed to remove or rewrite the value of Hop-Limit carried in
    >    received messages" Isn't this remove all usefulness of the Hop-Limit
    > option ?
    
    [Med] This is warranted in the next sentence: "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."
    
    Basically, the decision will be deployment-specific. E.g., if the boundary proxy is the only proxy to be invoked before reaching the ultimate CoAP endpoint, striping the option may be OK. 

EVY> still looks like defeating the whole purpose because how one proxy would know FOR SURE that it is the last one?
    
    > 
    > C.2) table 1, suggest to state the value of the C, U, N, R properties
    
    [Med] The option is elective, safe-to-forward, part of the cache, and not repeatable. So, none of C, U, N, R is marked with "x" in the table. 
    
EVY> LoL __ but a little unclear at first sight. Unsure whether other documents use a "0" or "." to specify 'not-set' ? My point is that this document should really align with others.
    > 
    > -- Section 4 --
    > C.3) while I understand why a proxy should not add its own diagnostic
    > information when packet should become larger than the MTU of the next link,
    > I
    > wonder what will happen downstream when the MTU will be exceeded...
    
    [Med] The behavior of the proxy will take into account the "Path" MTU not the link MTU:
    
       Note that an
       intermediate proxy prepends its information only if there is enough
       space as determined by the Path MTU (Section 4.6 of [RFC7252]).
                                  ^^^^^^^^  
    
    With that assumption, I don't see any MTU issue when forwarding the packet downstream. No?

EVY> my bad, I should learn to read...
    
    > 
    > C.4) suggest to use normative language (uppercase MAY, MUST, ...)
    > 
    
    [Med] We used to have more normative language in that section but cleaned it as a result of this WGLC comment:
    
    ========
    > > 3. "To ease debugging and troubleshooting, the CoAP proxy which
    > > detects a loop SHOULD include its information ... Each intermediate
    > > proxy involved in relaying a TBA1 (Hop Limit Reached) error message
    > > SHOULD prepend its own information" - Is it really a protocol
    > > violation if I want to configure my proxy not to include any
    > > information?
    > >
    >
    > [Med] It is not a protocol violation if the information is not included - hence the SHOULD. However it makes diagnosing the issue more difficult.
    
    We briefly discussed this in the interim yesterday and came to the
    conclusion that having a normative requirement here isn't needed. It
    seems more like a suggestion for a good quality of implementation. I
    propose to remove any use of KEYWORDs here.
    ==========
    
    > == NITS ==
    > 
    > -- Section 3 --
    > N.1) s/if a less value/if a smaller value/ ?
    
    [Med] Fixed. Thank you.