Re: [ippm] Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
Francesca Palombini <francesca.palombini@ericsson.com> Fri, 26 March 2021 14:20 UTC
Return-Path: <francesca.palombini@ericsson.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429903A1FAC; Fri, 26 Mar 2021 07:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 DM8rNjErHpzE; Fri, 26 Mar 2021 07:20:31 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2085.outbound.protection.outlook.com [40.107.20.85]) (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 AFD383A1FAA; Fri, 26 Mar 2021 07:20:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZXH165IuoUvOGiABN6D7gc9ME5MwcT5FiNsBxr5ztafPIqIFeGe0KANdakMgjuslCW1P9/xXxNynWVmbn4hKFDJBYb957DacOEXv3KW3xGZihMMfipW7p588FvIIw5Vhhuq/MgCfunRlQUGLMaVYXYL7e4GPn+3zQamCCEvQWx9W3XjU2t9BP6t9efYZaHnlfvO5Vzp8euKOWlFyHvTcUNLhzmqIb9+R+yx8psmjvrYQ2DgH+sG6NtfQyaZoZ28kodJhLiEqQK8GWUpsJ+rGnFglegf5d+otJtoOAarTqOCU5AE8n477S2acZjMeNdC/9jl3cjG8ENN7nLsR1S+daA==
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=cwp/0K+Rj3OeitksSJX6Z9C0v7X3Oo9nUN7nckfIi7s=; b=JgRK6VPPVj0QAAMVeXtZBwr43aiyy29k/Gq0gFfmGTj8szIZ2cZyuv+pEq6Sh8jvdEzH5zDdYXZ7P9tzfM5bWSoKe5ylNMAgxrpEDVe7SpBT0zueEI9brvDu8clEIBpzGhWWIGwqEMqiWwy+EbZO2vETmYuj0PaNMJiHaGJ1A8VMlWR96LW5ff+hvaeXaZqzld2SthWuRKFAZMiZ9TQnWYtNH5Y18D3xXhN0/1Sp64oqBEokHqroV9LNFjlceL0CUq/DKkYWs0M8p5H3GUxq9mCO377GvRQf8+lZrdlPDAeGLEjkTYNXWXD48lDY5xAe+eDKuCyaXmGQ6M/zZoseAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cwp/0K+Rj3OeitksSJX6Z9C0v7X3Oo9nUN7nckfIi7s=; b=D9kgP5t3Z3YEjJGVyauqJmPVyl0LnQjPHrWVKvEIkE8Q0PVOlYXpb4RttIcz0FhHWoaB9OOM+a8wzdNIskWRXzss29+/d77PMQIr4T6T4sRHoeMEUNgoRrx1lTV/Ge2HJr+OnBC0vaEuj2oD+LV2JHebqLp8nkmu2rebz5L8T+A=
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2347.eurprd07.prod.outlook.com (2603:10a6:3:6f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.16; Fri, 26 Mar 2021 14:20:28 +0000
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::e922:5ae8:48bb:b796]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::e922:5ae8:48bb:b796%3]) with mapi id 15.20.3977.024; Fri, 26 Mar 2021 14:20:28 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, Martin Duke <martin.h.duke@gmail.com>
CC: "MORTON, ALFRED C (AL)" <acm@research.att.com>, IPPM Chairs <ippm-chairs@ietf.org>, The IESG <iesg@ietf.org>, IETF IPPM WG <ippm@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>
Thread-Topic: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
Thread-Index: AQHXIOChp/rv0XF0uUqsGPevCDRj5KqU/JoAgAEx14CAADbngA==
Date: Fri, 26 Mar 2021 14:20:27 +0000
Message-ID: <5CF3F626-41D9-4821-9A05-85B605B20F74@ericsson.com>
References: <161661268673.916.16348206674906302793@ietfa.amsl.com> <CAM4esxSYaE27gPRjAuWuZkimW5TLW2J+jrm-7R5r-Wah6OvEsA@mail.gmail.com> <E715D54E-1BCE-4B81-84E1-BCB42407AB36@ericsson.com>
In-Reply-To: <E715D54E-1BCE-4B81-84E1-BCB42407AB36@ericsson.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21031401
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:1ba8:147a:c100:d0d6:e209:7a1:6bf0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f3730eb9-40b1-4ee8-fe50-08d8f0624e24
x-ms-traffictypediagnostic: HE1PR0701MB2347:
x-microsoft-antispam-prvs: <HE1PR0701MB2347C4D7565D5BD66903338598619@HE1PR0701MB2347.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RMKIIGtWGdpGbZ5pdAgYVDDD+C+7jHlVh7j9OUQbyKKklIGnKspna+/u4sRdSlYRRBTA2e8kS3NGtI98sasY/F8IRWfL6wgSCTVhSKAVBWrORnqq9kN8treg5Gr18+uVRKjjJrbffzyPPVSQa58VuY5oGMFk0fHapL5HE5kqlVkBf9OxblHg+BfJnQUFz84dDdMXZBsrx9UKs8VVc9NFJOyrsik1hc4novo1GAOlwGDDKlsvrmsSRaOCTTamJDdIise0K1uTF1jDDpqy3HVXYllMyt99O2ddaajNXlPEV/xM+oHQJ/lYk7LKfxFpRsR85TzS3glUA/ds37RgiS2jAw68Hy7KVf++7k6xf233FE4jAXn6A0sK5tGomaY+mxkC9wHpYQ8YFWenfPdyMd1SIrS8D2OxKXJtjG+FxMrx0A/x3IS852o3ZCCAeoZ6tTU3nKoLv7x0mKUziq2aFYyoXBnwf+JtFPMMjQkhI4MSySfbG4UdhbpD/T3ZDF0X3ENFnUO/e6AaQ0aWuBT+DTJjLfwqkTP4HKA9Qe2z68NR1XSid2lGLWuc851GNEgdgjg/fPdHnoCoNSEylakKn3vuIJ9hTK4aeUd4Lb4Ru2TXacgT9nEoO4WPOo2hPbgEMJ0NnzOEP6MzzpHgAFBfpfGOrhI9IfxYTQczVUddAy7g6FPaQ7rKfdwVWkfZ8pk+Q0vS7tBHZMzXBeDEkZAqJMqVLp442STabayPcXdD4BYiqSt7FAOnUU0MeMLNmyXAj+g+sXiVLcESTqC6p2v5x0rdQg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(396003)(376002)(39860400002)(346002)(64756008)(66556008)(76116006)(66476007)(8936002)(66446008)(44832011)(9326002)(83380400001)(166002)(8676002)(6512007)(66946007)(21615005)(71200400001)(6486002)(110136005)(316002)(86362001)(54906003)(53546011)(6506007)(4326008)(478600001)(5660300002)(966005)(36756003)(2616005)(38100700001)(186003)(33656002)(2906002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: onNYqtUzlr0J9ylanAJpolpCs3cCW77bp6kJsXyRMHvd8/Mq0a+gnrFr+vwFbclfTSj0H3NDE2ZXuPAZfq7+CIXyVmxLwGRsLr/or8k4Su494E42Bl4b1AHav8dMKk/KSzWZV1h1f72kXaDDZDXKCQmyGokIIoxjh4cWLsVFG+zhhRBzM3uRMEChNl8ewVYZV1WPZtvI/qGJzdZMGlm3KFEpSQMklIRxMMaqeFfLDPILP7VwVDSD0t5qfTYayFXCcSQx4bD8yyxGj1cNrw+rcvT7nFe7ieChem1UVQwGKHU+6nroy0Um824Poaj4PFy4/XWd1rAQOAf5aNxYM794WhF8rGHAX9BpO3YmdCf3eqsbPu5RZUoiOyUXWStOZNfQrcQ4ZEdaEcZ027T1hGz7xu4ST5UUxZOTuHcMHXs0etrN4SLbfOchf6UH/2jc1azus6JMjEViTN6uiRH/44cf7C2pqPKl1n4wLriQfrPkrgJI56cvqiLJ+sOf67ZbwU4wrDerC6XoQDsq1TYS0p3Dm4VTYzhTPVEHPH/F7m2YX4ifjTfJOSKE/mSHkoAaO+jMLV9t4uJ3DRM0GyjIdXjd01JOTtAAzQZKl2dugGjNF7ggFnHPkVC+UwmCU+zVZomnv1dirsWXpn/EeSXw/Nkrfl3p+5b/tN74LK4hPnGdFY83bWf75iMSXBy2TQUAwKzq0zaF1YmmvclD5w8N7MyhqUCwFZqswvgLYVtd6o/H12keUHtRXLax5ccxYIYoV+95xchu+/3Hq8rUrwJFnk0KlU24gFTwKuyQmkEk7m8ZjbDT/WCPHx0jNCHwFUuT9w07Gl1ykBk21FfFILj4/Y59LdxX1nMMqlRxb5/rbxvFDGbFkPmuvkYARSp2HagRJHXw9Ryj9ZKuvyncPBfqJEGCSTJ+aBP+7f6nYlynRFgYM8UexFTLtA8ajxpuZ70+XOYiHeO86N8mevA4Eebw8NEmmoJSwf8FKyCnKER2DGt6GA39nWtwCPaPMaI66F6i1qPtyiJgX0UlkCKQjhQjyj4kM5Xx0OscOjJT3LdGz1mxrxm5uJwSi6ctU5ZDVvr9zf8FOah7sQqxFctDyo8igQlgxwxTh2ZIDG15mfxNFNnvAtfwHEIguAcKQG3YJoQuA4w7mZII3YyhdG6L5gR4Np5k4p1D8kVCUQiqPTwj71H66FHzxqXfXyOWVpbliuI0M+Hy8h8YSF8QUlHx8lLSqx/ZZ15qbHvAeM7Gj12iSHPEvsPTEOQNXG+4zbEnYyCgSzbFMzKb9hy4D7kZVL95wp0u/OyGX4hDu7xlGnnEnmsYIdarwfQc431DiVcPQQEPPU7BL5nHyJMmtvkLTSCK4jX9/KzsHA+Vh2IP7d9YDV5tPst21LY/YT8BQ302GOnYUatPcEXm2aPCDcBGphJaBSXwLQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_5CF3F62641D948219A0585B605B20F74ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f3730eb9-40b1-4ee8-fe50-08d8f0624e24
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2021 14:20:27.9824 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uLcyU1KvZcLV/60+bmQ62MN6sWwIYwlNK+e7/2eTMsbO855uA8QvlnNIur+HLg+G0qQ6fp0y1UD+q8LLtG8JO3bHv12dqP16vhhHdg2sIr9j399NUGOuVa0FZa5Z1n2a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2347
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/wZCmMiNzxrEXeEnyyd0QI1_SSG4>
Subject: Re: [ippm] Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2021 14:20:36 -0000
Hi Martin, Re my sentence below “I do think it is worth considering in this document if the normative reference is necessary, as it feels optional by context.” Thanks to an offline discussion, I take back the question about the reference being normative – my reason for questioning it in the first place was that the PTP is in fact optional in this specification. However, I didn’t consider that even optional features need normative references – you have to read the reference to understand if you want that feature and, in case, implement it. Anyway, I am going to update my ballot to reflect this. Thanks for the patience and sorry for the double post! Francesca From: iesg <iesg-bounces@ietf.org> on behalf of Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org> Date: Friday, 26 March 2021 at 12:04 To: Martin Duke <martin.h.duke@gmail.com> Cc: "MORTON, ALFRED C (AL)" <acm@research.att.com>, IPPM Chairs <ippm-chairs@ietf.org>, The IESG <iesg@ietf.org>, IETF IPPM WG <ippm@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org> Subject: Re: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT) Hi Martin, Yes, 5. In the COMMENT, about referencing normatively IEEE 15888. This was a “discuss” DISCUSS: as I said yesterday in the telechat, I do believe there is unfinished business about normatively referencing documents behind a paywall and wanted to bring this to the IESG attention, but I will not block the document because of it. I do think it is worth considering in this document if the normative reference is necessary, as it feels optional by context. 11. to me feels more important to fix. Also I did not include 8. In the DISCUSS part, but I’d really like a response to that one as well. The rest are less important – clarifications and points raised to make sure the WG had a discussion about them. Francesca From: Martin Duke <martin.h.duke@gmail.com> Date: Thursday, 25 March 2021 at 18:49 To: Francesca Palombini <francesca.palombini@ericsson.com> Cc: The IESG <iesg@ietf.org>, "MORTON, ALFRED C (AL)" <acm@research.att.com>, IPPM Chairs <ippm-chairs@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, IETF IPPM WG <ippm@ietf.org> Subject: Re: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT) Hi Francesca, Which "Point 5" are you referring to in your DISCUSS? Is it the fifth item in your COMMENT? On Wed, Mar 24, 2021 at 12:05 PM Francesca Palombini via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Francesca Palombini has entered the following ballot position for draft-ietf-ippm-ioam-data-12: Discuss 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-ippm-ioam-data/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for this document. I think that the discussion on point 5. about referencing normatively IEEE 1588, and 11. about IANA Expert guidelines are worth having, and hope we can get them cleared before the document moves forward. Also, please find some minor comments below. Francesca ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. ----- document are to be interpreted as described in [RFC2119]. FP: Please update the boilerplate as per RFC 8147. 2. ----- The specification of how IOAM-Data-Fields are encapsulated into "parent" protocols, like e.g., NSH or IPv6 is outside the scope of this document. FP: This sentence (or equivalent) appears several times - at least 2 times in section 4 and once more in 5.1 - please consider removing the repetition. 3. ----- For example, if 3 IOAM-Trace-Type bits are set and none of them are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are FP: As this is the first time the term "wide" appears, it would be good to define it and add a reference. Alternatively, a sentence in the terminology might have helped too. 4. ----- Bit 3 When set, indicates presence of timestamp subseconds in FP: Same as for 3. - please add a reference to where "subsecond" is defined. 5. ----- formats; based on either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX]. The three timestamp formats are specified in Section 6. In FP: Is the normative reference to IEEE 1588 (behind a paywall) absolutely necessary? Rob Wilton pointed out that maybe a normative reference to RFC 8877 would be enough, however that would create a downref since 8877 is informational. Also (minor) if kept, please consider updating to IEEE 1588-2019. 6. ----- computation, indicates which POT-profile is used. The two profiles are numbered 0, 1. FP: (just a comment) I found strange at this point that although two profiles are mentioned, only one is defined in this document. 7. ----- Namespace-ID: 16-bit identifier of an IOAM-Namespace. The FP: Each option-type starts with Namespace-ID: couldn't this be optimized, or what is the reasoning behind this? 8. ----- IOAM domain. Within the IOAM encapsulating node, the time that the timestamp is retrieved can depend on the implementation. Some possibilities are: 1) the time at in one of three possible timestamp formats. It is assumed that the management plane is responsible for determining which timestamp format is used. FP: This is worrying for interoperability within different implementations. Maybe more details or guidelines about how the management plane deals with this (or references to relevant specification for which this is in scope) would help. 9. ----- New registries in this group can be created via RFC Required process as per [RFC8126]. FP: (asking as this was not included in the shepherd review, and just want to make sure this was addressed) For this and following registries: what is the reasoning for not going for IETF Review? 10. ----- The meaning for Bits 1 - 7 are available for assignment via RFC Required process as per [RFC8126]. FP: From section 5.5 the bits 1-7 are indicated as Reserved. 11. ----- of the current document. Registry entries for the values 0x8000 to 0xFFFF are to be assigned via the "Expert Review" policy defined in [RFC8126]. Upon a new allocation request, the responsible AD will appoint a designated expert, who will review the allocation request. The expert will post the request on the mailing list of the IPPM working group in the IETF (ippm@ietf.org<mailto:ippm@ietf.org>), and possibly on other relevant mailing lists, to allow for community feedback. Based on the review, the expert will either approve or deny the request. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the designated expert can approve allocations once it seems clear that an RFC will be published. FP: The text above indicates Expert review for the registry. According to RFC 8126: The required documentation and review criteria, giving clear guidance to the designated expert, should be provided when defining the registry. It is particularly important to lay out what should be considered when performing an evaluation and reasons for rejecting a request. Although the paragraph above gives some indication of process for the experts, it does not give clear review criteria or guidance. I would suggest this to be expanded to give more indication to experts on what criteria to consider - these same criteria will be considered by the working group as well.
- [ippm] Francesca Palombini's Discuss on draft-iet… Francesca Palombini via Datatracker
- Re: [ippm] Francesca Palombini's Discuss on draft… Martin Duke
- Re: [ippm] Francesca Palombini's Discuss on draft… Francesca Palombini
- Re: [ippm] Francesca Palombini's Discuss on draft… Francesca Palombini
- Re: [ippm] Francesca Palombini's Discuss on draft… Frank Brockners (fbrockne)
- Re: [ippm] Francesca Palombini's Discuss on draft… Frank Brockners (fbrockne)
- Re: [ippm] Francesca Palombini's Discuss on draft… Francesca Palombini
- Re: [ippm] Francesca Palombini's Discuss on draft… Frank Brockners (fbrockne)