Return-Path: X-Original-To: tictoc@ietfa.amsl.com Delivered-To: tictoc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211EFC15108F; Wed, 15 May 2024 14:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg-usa.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40uiVMhS8Y0T; Wed, 15 May 2024 14:00:26 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2117.outbound.protection.outlook.com [40.107.7.117]) (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 1E303C1CADFD; Wed, 15 May 2024 14:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AUXcWiWcrjODrJIuQUqj5Y4/hpkkXxOET8ReBgxBx/67HoqQgkeyUeTufzv9tZUum6Ge+Zhsak8peWR48NHZrSAu/IoOkvEwkch6dRKMLnkZtfov4hyuD615hV1VduwEEHVaPEt1CgBE10qW8oimFZeHvQKGBgsSQBHZmnx9IXyNZ4yRpYb0kGpKH+HjZzZYfzGhKoPmraM79zysL+7WcNQricBuHW3bDaBzZQbgU4+tGJ6oXHCHbTSoLYtzfxa1J6ve5VZDbiiDVzM7Z8RZ9UOYzKYFdAx0wbK8dqoSClOyxo0hBpYhE2W0H24/nj1wi1BWsB04cXULDHH/ytib2Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fQyBYpy+WLwsMsUN4sJ+fkR3qpf2AtdFTOZQajjYMNw=; b=dcLNmUDeSDWBKe3YfcNDOaUT7B1emB/CZhxwDfi0MgJ9z2IVDVBnGBuziL/tMLpt0Hfsp11xfYUfudPQmVBN/6z+fLfS9Z/HPwFreRxLhKyBXC477oOg8tzZBKu7KkPft0gH3Y1lNSjCeYkN+fcyhVuc4PM17aCgin0Wc3cA2uIAE7JR4wNrLHNBAOJpWe6fygI0a67F6G4VnppuQwSHnc/GZwRPwPLu6uAcm049IWkh95MCPLo1eIcERB6K6g1otv9OuM05cRHHUOZAReHrp79LZz4FsTuPjZFox+ZG1lmGHpjDYD2d8epBzPwjfFA0SDKpI5IMpHllEDTY3sH0sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=meinberg-usa.com; dmarc=pass action=none header.from=meinberg-usa.com; dkim=pass header.d=meinberg-usa.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg-usa.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fQyBYpy+WLwsMsUN4sJ+fkR3qpf2AtdFTOZQajjYMNw=; b=SJH3cYM2iAaeU8kOnTbQLtIyRoaPzrShFBS0oJlvIZwJi1CpZ5+py/3UTbz4UTXEgVvkluhIVe47u6N/mKp7QbTimKQMPWHpAKs8Ddd+rVyBAMIrMg4cUJddO+LBpxsw0E1atsGdKjS5jscBVW/tbRZUnCklaZnZp65W3hqaZV1QMrtPYXUOUDDY9IJfx1356elN14X9GP7HsUY73IWhuf4drj3RF0a8zhzO0iyBvaKN7ch5XYBkk7f31iKainaLigiYNvM5aIUkvTLODIfk4c5sOicVIYdYslYqFEqh/Ad93eIf921aDUg/2rUB7aHfYykB00OcC78CaDt/2o/CrA== Received: from AM7PR02MB5765.eurprd02.prod.outlook.com (2603:10a6:20b:102::15) by PAVPR02MB9379.eurprd02.prod.outlook.com (2603:10a6:102:308::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.55; Wed, 15 May 2024 21:00:17 +0000 Received: from AM7PR02MB5765.eurprd02.prod.outlook.com ([fe80::f9d9:cd85:99a8:d18a]) by AM7PR02MB5765.eurprd02.prod.outlook.com ([fe80::f9d9:cd85:99a8:d18a%4]) with mapi id 15.20.7587.028; Wed, 15 May 2024 21:00:17 +0000 From: Doug Arnold To: The IESG , Deb Cooley Thread-Topic: [TICTOC] Deb Cooley's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT) Thread-Index: AQHanyFqKQmhgwVxE06JbTM7CX8Nc7GY1Nc0 Date: Wed, 15 May 2024 21:00:17 +0000 Message-ID: References: <171493686211.55606.4078690425298244591@ietfa.amsl.com> In-Reply-To: <171493686211.55606.4078690425298244591@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=meinberg-usa.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM7PR02MB5765:EE_|PAVPR02MB9379:EE_ x-ms-office365-filtering-correlation-id: cab02a2e-f089-474e-1184-08dc7522061d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230031|376005|1800799015|366007|38070700009; x-microsoft-antispam-message-info: =?Windows-1252?Q?ntU/OxWb/y+cUuOmYAvijQ5xCsT1jxw0/3TYpaXtr0GKXB6cjzHvN7/L?= =?Windows-1252?Q?hT56yE/F0lLdVGKxRtfCjGkl11wMDLJIpA3zPhxGDOuUvjDuE77aDHdz?= =?Windows-1252?Q?RfwavRUlzCCTZl1SskD7E1LZCm94MCBoDc0v5JeRTc3ixIygmL7ZWPaR?= =?Windows-1252?Q?YL2xmDgSKuBzOMNu4sBVJN3kaR/IBd6do03vIsBmlHNJWabhNwjbdc+t?= =?Windows-1252?Q?x2J7aY2fK6S5cmaaBYaVPRzt7bY47SBi6WteuY88NgePZMNdGJownwEK?= =?Windows-1252?Q?1Cfhwim2JgouZ1/v68GJhzoEQzkTerajvG34jFDXN8+64dWWg/n5HPG9?= =?Windows-1252?Q?3fIQ63QnWpngGm8IxyPmCrEsJbcIZjTI1NtMbiG3m0E6ylURVur/DTS9?= =?Windows-1252?Q?TbAe8dNO8YES7gAkxAcOT9AD0R8405EA1APZqnCzhGogTY0gVl2FUH4I?= =?Windows-1252?Q?ijSkBxQpXvJQHDpz2L91ikOON3iFVBI4Trw9GfYdPzFJl/Bvx4VFfilj?= =?Windows-1252?Q?AuJaVYSQitpMZYNsOFMkZeZe++4o89lnDH4yG3LnINdtrYeb8i4FN5xU?= =?Windows-1252?Q?mc0g1AHmtIq38DGRJS66sHNKGagOQMGSsM2CxpCUhAsj4cIy1scfuhsS?= =?Windows-1252?Q?qJUmTb1UPGP5+BLZfN838qOIRTdEPUjGDNNoDa3JxjS6eCM+/+8LGJSM?= =?Windows-1252?Q?vtpiattDNFPYVPEIiiqAA4SaERBQ7s9m9auq33kNREHbCx+zVfAog3cR?= =?Windows-1252?Q?fC59E44snV9lvqXNL8u8bPtAqt4lTxgv4aT/vg26x8afOsRQJP7MSSIp?= =?Windows-1252?Q?koP0Q+agLVjtbn6JeGCqtTFQWodpkrUsC27FQ2vDNXnqDiPcylTA7iMv?= =?Windows-1252?Q?uaWDyhICK+Xplrkew7xbm81WohlnIAA/CgsDJwBKpCf0xQu7DmAwrRKo?= =?Windows-1252?Q?7skT/Pi3VbMDrmKLdlI0CyNupjFYUaXxtfoxGB75dos1TK0rqUkWn2Sw?= =?Windows-1252?Q?5StwL1B68EI3NqTg0X7TiZEhQd0KAMfjunXNj7XuhXB1EhRe/G7Jsqw5?= =?Windows-1252?Q?dJRJ8kadEyYhivyiN4DqgXc5SGg/wmI7Dcy9lB6r4s+EqwyX9tcBlLIs?= =?Windows-1252?Q?gX4CnSqbHo/53fdllB3gtXHpDuiv0fimx+7MZn3Dm4glrq90TY1qM2qi?= =?Windows-1252?Q?2zJaZxaMMRoWxhyKrBzy6bo4cjOS95P4oXQQyRroCTsfMvdSbREohNTq?= =?Windows-1252?Q?IXo95zR0pBpxshNI1EY9uqtmd4BJrGcF0Qa+BU5MZFidlEogD2naZvBF?= =?Windows-1252?Q?DMmi0fQxSV3RswwUNKZj6zAFOyirwpwBhcUY2Ib1eSc93qm+rauc3S+h?= =?Windows-1252?Q?frmfxOSKmgcd6g=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM7PR02MB5765.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?g38rOVsKBhPkTtDAaaPkszQ/HTiLRdsNrLqFGcNvYEKoShKRYqXffrrm?= =?Windows-1252?Q?eTaEbWX1P8oxmcVFZDmDeR9YhJMB4dqs5CZU16Jv7ExhoXG+9d1deSUe?= =?Windows-1252?Q?zJPe+EHP8EdnDUFSvj7XZstiNwXklo6zPArF2Cmne6VB4aBLNpA60lBw?= =?Windows-1252?Q?FH3TCBjYNX+sHTmyjmFjaqqzSIAYjvizg2ZnsxEqTQbwXfrAfvwyXFK7?= =?Windows-1252?Q?tkTeDLC7JM/mrljdNJ7iN4RfHLO3KQwxcYxaZkOq9L9fqIehU5MvJHaM?= =?Windows-1252?Q?OcV9hTLgTTRa+qHIS9Sn2n8sleNj/RgvmPjB6rFvHQ1llsMM5nAUa93Y?= =?Windows-1252?Q?SJPMdtJlSA035huF0lqaGnfc1pwZZCuVsuLhQnMGzwEfcwq/jq/bIGUv?= =?Windows-1252?Q?A3obbTJUZs52dg29r7RPF2MEOKVOebDmprJjynbwJhxFDXfeoLqRwWHS?= =?Windows-1252?Q?CB+DppFehIs3kteu5StadaOSgE2jo+t5qrbFgMYbE9afkc5jUgQe08Il?= =?Windows-1252?Q?CVNyFQRYOUMNxM2qV23+yi0IKImujvVxFuVofHmG5m9Y1+3bP2+6oQ2B?= =?Windows-1252?Q?+iccHIO/pLlq3H8FIx8aYjjDyIn1ZWVABo96gZjvfjj8omNxJyCltFNu?= =?Windows-1252?Q?t8myG0oc45eme/KjbtjAa/rq34Ejl3hCnJwaVXFxyOhC0msqEgXpN7u8?= =?Windows-1252?Q?9xGYQpK7cyBh4nH2Z/yO/V+HXfR9JNdFVnKAxKZQ/J/Bx1rwH+76NfGU?= =?Windows-1252?Q?bNOki7zzlRg61h9mKmMOqMY0ZZg4pP3DfrMUjAoGz52LChXXugK2vMa2?= =?Windows-1252?Q?pC0kEPZcipVseDRrrn9qQUevU1t2p0RT9YGiApX9KlDacufTaN6iUV8F?= =?Windows-1252?Q?F+dUlq2vUV112toE+IoPn8RteHcDeu+GxnFHA3/F5rpVDdbq4PsOX8j0?= =?Windows-1252?Q?X7ivxUcWo+BBoKi66B/yxxkUzS9zVAbVgHLfK4FJuz4ftAWL3UK2KFzi?= =?Windows-1252?Q?Tv96tg0tTAqmtVIGtJgHNtMgyMeSDNfwuoz+5O4bxHdXPX+IzhbeagwA?= =?Windows-1252?Q?sRCn7xKGa2oCTTYmoGTo84RGwMFjKziWe2xgjYJZVnvsXtDFSQh/gOXb?= =?Windows-1252?Q?cumsDcmfsPZDNpkxJQNrrEwxkXfsJ80FK7QCoKu3/dDga3d/nz/SwOoD?= =?Windows-1252?Q?OFvz3dSC2sKyoozS3tulZVUarUUF9dm6DMMo+RVYIcl9kjqbdmftLjtn?= =?Windows-1252?Q?QVygQfRIF4fC4XtAFaShZbGg1j+vMHVY/g8LY5rO4fLcBT8nrpliQXza?= =?Windows-1252?Q?0RcMNwXzKUpcE6NztmdCVSSx4brlKOgju79vCwMEef0rXPVZPbIaqiT0?= =?Windows-1252?Q?3wZGlhSvgCYxy5mio9s66drT2HAjPXy6cGAppSHCqflT+BrCXvDAIa3t?= =?Windows-1252?Q?Odlr3a/MrQtzwnaJdumo8oQLiONumcg1YWWkyHf2jI7+CtU/S7PZlqHf?= =?Windows-1252?Q?T3w6k6TkJda3b8rWAdXA8jMXgopEBcCPvzwcPsbpT45eJ5MNWL6wVO5S?= =?Windows-1252?Q?ZV+VZe86O8DffWtj4RbJzXCNlezL+HWLQ0wsTTp55XZ7QWNeRl+5IIoC?= =?Windows-1252?Q?SOEPGKFsKzdkmOUst6NbGAisF7mUdOwR26cRwP2QAlL+HCeEYOvvBs0C?= =?Windows-1252?Q?eoftddlpyH6+GW8/jXm9cTncCiVnAayRdGR1mWoC8FfxJZuP17STjw?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM7PR02MB57655E824B5B278D528E5560CFEC2AM7PR02MB5765eurp_" MIME-Version: 1.0 X-OriginatorOrg: meinberg-usa.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR02MB5765.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cab02a2e-f089-474e-1184-08dc7522061d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2024 21:00:17.1215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d59904cd-769f-4368-8bd0-f5f435893a38 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FKEUuC/bScWf/dtTZ8dPKmdWBrOYlepqV4XxWK6qH6fb0UBJPi1BWh127e1IBppG7RbIeBncZ+WKa4Kj61EnWWhBXIzUZY5JKRvvNSamzfg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR02MB9379 Message-ID-Hash: AA57HNK4VNLZY3B44XYYIKHARTEABEY6 X-Message-ID-Hash: AA57HNK4VNLZY3B44XYYIKHARTEABEY6 X-MailFrom: doug.arnold@meinberg-usa.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tictoc.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tictoc-chairs@ietf.org" , "tictoc@ietf.org" , "draft-ietf-tictoc-ptp-enterprise-profile@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BTICTOC=5DRe=3A_Deb_Cooley=27s_No_Objection_on_draft-ietf-tictoc?= =?utf-8?q?-ptp-enterprise-profile-26=3A_=28with_COMMENT=29?= List-Id: Timing over IP Connection and Transfer of Clock BOF Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_AM7PR02MB57655E824B5B278D528E5560CFEC2AM7PR02MB5765eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Deb, Thanks for pointing out the unaddressed comments by Tero Kivinen. I agree that section 12 and section 18 have to be consistent, and that the = use of SHOULD NOT is best. In section 12, Change: =93PTP management messages MAY be used.=94 To: =93PTP management messages SHOULD NOT be used.=94 Regarding the preference MUST over MUST NOT: I believe it can be clear eith= er way, but I don't mind changing: Below are the proposed changes to addre= ss this. In section 7, change: =93The Announce message rate MUST NOT be changed from the default value.=94 To: =93The Announce message rate MUST be the default value.=94 In section 8 change: =93A PTP Port of a clock MUST NOT be in the timeTransmitter state unless th= e clock has a current value for the number of UTC leap seconds.=94 To: =93A PTP Port of a clock MUST have a current value for the number of UTC le= ap seconds before transitioning to the timeTransmitter state.=94 In section 9, change: =93If a timeTransmitter is not an Acceptable timeTransmitter, then the time= Receiver MUST NOT synchronize to it.=94 To: =93A timeReceiver MUST only synchronize to an Acceptable timeTransmitter.= =94 In section 10, change: =93Transparent Clocks MUST NOT change the transmission mode of an Enterpris= e Profile PTP message. For example, a Transparent Clock MUST NOT change a u= nicast message to a multicast message.=94 To: =93Transparent Clocks MUST maintain the transmission mode of an Enterprise = Profile PTP message. For example, a Transparent Clock that receives a unica= st message MUST retransmit the message as unicast.=94 In section 11, change: =93Boundary Clocks MUST NOT combine timing information from different domai= ns.=94 To: =93Boundary Clocks MUST process information from different domains independ= ently.=94 The entire section 13, =93Clocks operating in the Enterprise Profile MUST NOT use Peer-to-Peer tim= ing for delay measurement. Grandmaster Clusters are NOT ALLOWED. The Altern= ate TimeTransmitter option is also NOT ALLOWED. Clocks operating in the Ent= erprise Profile MUST NOT use Alternate Timescales. Unicast discovery and un= icast negotiation MUST NOT be used. Clocks operating in the Enterprise Prof= ile MUST NOT use any optional feature that requires Announce messages to be= altered by Transparent Clocks, as this would require the Transparent Clock= to change the source address and prevent the timeReceiver nodes from disco= vering the protocol address of the timeTransmitter.=94 Is changes to: =93The following PTP options are NOT ALLOWED: * Peer-to-Peer timing for delay measurement * Grandmaster Clusters * Alternate TimeTransmitters * Alternate Timescales * Unicast discovery * Unicast negotiation * Any optional feature that requires Announce messages to be altered by= Transparent Clocks, as this would require the Transparent Clock to change = the source address and prevent the timeReceiver nodes from discovering the = protocol address of the timeTransmitter.=94 In section 14, Change: =93These rules MUST NOT be changed to achieve interoperability with other P= TP Profiles.=94 To: =93Clocks operating in the Enterprise Profile MUST conform to the requireme= nts of the profile even if it prevents interoperability with other PTP Prof= iles.=94 Regards, Doug ________________________________ From: TICTOC on behalf of Deb Cooley via Datatrac= ker Sent: Sunday, May 5, 2024 3:21 PM To: The IESG Cc: tictoc-chairs@ietf.org ; tictoc@ietf.org ; draft-ietf-tictoc-ptp-enterprise-profile@ietf.org Subject: [TICTOC] Deb Cooley's No Objection on draft-ietf-tictoc-ptp-enterp= rise-profile-26: (with COMMENT) Deb Cooley has entered the following ballot position for draft-ietf-tictoc-ptp-enterprise-profile-26: 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/about/groups/iesg/statements/handling-= ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Tero Kivinen for his careful review of draft 24. While some o= f his of his points were addressed, there are still some that remain in draft= 26. I will only highlight a few of these: - The use of MUST NOT in cases where a positive requirement could be used= , where a direct requirement of MUST can be used. Often MUST is clearer to understand. - For PTP Management messages, the discrepency of 'MAY' in Section 12 and SHOULD NOT in Section 18 need to be reconciled. (My recommendation would be to change Section 12 to 'SHOULD NOT') _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc --_000_AM7PR02MB57655E824B5B278D528E5560CFEC2AM7PR02MB5765eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Deb,

Thanks for pointing out the unaddressed comments by Tero Kivinen. &nbs= p;

I agree that section 12 and section 18 have to be consistent, and that the = use of SHOULD NOT is best.

In section 12, Change:

=93PTP management mes= sages MAY be used.=94

To:

=93PTP management messages SHOULD NOT be used.=94


Regarding the preference MUST over MUST NOT: I believe it can be clear = either way, but I don't mind changing:  Below are the proposed changes to address this.


In section 7,= change:

=93The Announce message rate MUST NOT = be changed from the default value.=94

To:

=93The Announce message rate MUST be t= he default value.=94

 

In section 8 change:

=93A PTP Port of a clock MUST NOT be i= n the timeTransmitter state unless the clock has a current value for the nu= mber of UTC leap seconds.=94

To:

=93A PTP Port of a clock MUST have a c= urrent value for the number of UTC leap seconds before transitioning to the= timeTransmitter state.=94

 

In section 9, change:

=93If a timeTransmitter is not an Acce= ptable timeTransmitter, then the timeReceiver MUST NOT synchronize to it.= =94

To:

=93A timeReceiver MUST only synchroniz= e to an Acceptable timeTransmitter.=94

 

In section 10, change:

=93Transparent Clocks MUST NOT change = the transmission mode of an Enterprise Profile PTP message. For example, a = Transparent Clock MUST NOT change a unicast message to a multicast message.=94

To:

=93Transparen= t Clocks MUST maintain the transmission mode of an Enterprise Profile PTP m= essage. For example, a Transparent Clock that receives a unicast message MUST retransmit the message as unicast.=94=

 

In section 11, change:

=93Boundary Clocks MUST NOT combine ti= ming information from different domains.=94

To:

=93Boundary Clocks MUST process inform= ation from different domains independently.=94

 

The entire section 13,

=93Clocks operating in the Enterprise = Profile MUST NOT use Peer-to-Peer timing for delay measurement. Grandmaster= Clusters are NOT ALLOWED. The Alternate TimeTransmitter option is also NOT ALLOWED. Clocks operating in the Enterp= rise Profile MUST NOT use Alternate Timescales. Unicast discovery and unica= st negotiation MUST NOT be used. Clocks operating in the Enterprise Profile= MUST NOT use any optional feature that requires Announce messages to be altered by Transparent Clocks, as th= is would require the Transparent Clock to change the source address and pre= vent the timeReceiver nodes from discovering the protocol address of the timeTransmitte= r.=94

 

Is changes to:

=93The following PTP options are NOT A= LLOWED:

  • Peer-to-Peer timing for delay measurement
  • Grandmaster Clusters
  • Alternate TimeTransmitters
  • Alternate Timescales
  • Unicast discovery
  • Unicast negotiation
  • Any optional feature that requires Announce messages to be alter= ed by Transparent Clocks, as this would require the Transparent Clock to ch= ange the source address and prevent the timeReceiver nodes from discovering the protocol = address of the timeTransmitter.=94
 

In section 14, Change:

=93These rules MUST NOT be changed to = achieve interoperability with other PTP Profiles.=94

To:

=93Clocks ope= rating in the Enterprise Profile MUST conform to the requirements of the pr= ofile even if it prevents interoperability with other PTP Profiles.=94


Regards,

Doug

 

 

 

 =

From: TICTOC <tictoc-bou= nces@ietf.org> on behalf of Deb Cooley via Datatracker <noreply@ietf.= org>
Sent: Sunday, May 5, 2024 3:21 PM
To: The IESG <iesg@ietf.org>
Cc: tictoc-chairs@ietf.org <tictoc-chairs@ietf.org>; tictoc@ie= tf.org <tictoc@ietf.org>; draft-ietf-tictoc-ptp-enterprise-profile@ie= tf.org <draft-ietf-tictoc-ptp-enterprise-profile@ietf.org>
Subject: [TICTOC] Deb Cooley's No Objection on draft-ietf-tictoc-ptp= -enterprise-profile-26: (with COMMENT)
 
Deb Cooley has entered the following ballot positi= on for
draft-ietf-tictoc-ptp-enterprise-profile-26: 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/about/groups/iesg/statements/handling-ballot-positions= /
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterpri= se-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you to Tero Kivinen for his careful review of draft 24.  While s= ome of
his of his points were addressed, there are still some that remain in draft= 26.
 I will only highlight a few of these:
  - The use of MUST NOT in cases where a positive requirement could be= used,
  where a direct requirement of MUST can be used.  Often MUST is = clearer to
  understand. - For PTP Management messages, the discrepency of 'MAY' = in
  Section 12 and SHOULD NOT in Section 18 need to be reconciled. = (My
  recommendation would be to change Section 12 to 'SHOULD NOT')



_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.o= rg/mailman/listinfo/tictoc
--_000_AM7PR02MB57655E824B5B278D528E5560CFEC2AM7PR02MB5765eurp_--