Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 21 July 2021 11:19 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661B43A1179; Wed, 21 Jul 2021 04:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=HkPb2o7B; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MChzVlW4
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 yQijE-zzGr1u; Wed, 21 Jul 2021 04:19:45 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F553A1178; Wed, 21 Jul 2021 04:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6142; q=dns/txt; s=iport; t=1626866385; x=1628075985; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6vKaxHFu/9/vmfMiC33puiXaQHB0z7plyg2HP/68/pY=; b=HkPb2o7BD2BZBqekVEPHoX0aTffTzj/r1Z7zRtBczW+PRQxBWMscTYv8 IUP1WXj+YF0+j0unQMt4w3eSrM1Qj/xPcEUwSPVRQjUalx9HVVVlBc2Eh JVIIwkIW/uzMfRBv2ryzqg64M5KOSmqe6MDON6GDY551Wn0x7bqtJykz1 g=;
X-IPAS-Result: =?us-ascii?q?A0ADAACBAvhgl4gNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFFBQEBAQELAYFSUYFYNzGIEAOEWWCIXwOaMIEugSUDVAsBA?= =?us-ascii?q?QENAQFBBAEBhFcCgnQCJTQJDgIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBA?= =?us-ascii?q?QEBAQEBAXKFaA2GRQEBAQMBDgQoBgEBIxQBBAcEAgEIDgMEAQEBHgULMh0IA?= =?us-ascii?q?gQBDQUIEweCT4JWAw4hAZwzAYE6AoofeIE0gQGCBwEBBgQEhR8YgjMJgToBg?= =?us-ascii?q?nuKcCccgUlEgRVDgWGBAT6ELBqDS4Iugh0JARBCGQYuNgQ7OAI1Bh4WB0ZfA?= =?us-ascii?q?ikPkTeCc6hHCoMknlISg2OLXpcelgilCwIEAgQFAg4BAQaBWzmBW3AVgyRQG?= =?us-ascii?q?Q6BWIxHGR6DOopdAXM4AgYLAQEDCYt/AQE?=
IronPort-PHdr: A9a23:aUxidRP6MLy1S6g4PKsl6ncbWUAX0o4cdiYP55Yngq4IeaOmrNzuP 03asPNqilKBHYDW8OlNhOeetaf8EXcB7pCMvDFnEtRMWhYJhN9Qk1kmB8iIWlf2IP7jc2oxG 8ERHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA
IronPort-HdrOrdr: A9a23:AGyZhaC4bSwSO2flHej0sseALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UkssHFJo6HmBEDyewKjyXcT2/hQAV7CZnimhILMFuFfBOTZskbd8kHFh4tgPO JbAtRD4b7LfBtHZKTBkXOF+r8bqbHtms3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJba Z0iPA3wwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnb4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlRFtyssHftWG1SYczFgNkHmpD31L/sqq iVn/4UBbU115oWRBDvnfKi4Xi77N9k0Q6S9bbRuwqSnSW+fkNmNyKE7rgpLScwLCEbzY1BOe twrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfNsRKEkjQlo+a07bW/HAUEcYZ 9TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYIit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tHKyaRw4PvvdI0DzZM0lp iEWFREtXQqc0arEsGK1I0jyGGHfIx8Z0Wk9ih63ekPhlTRfsufDcSzciFmryL7mYRsPiTyYY fGBK5r
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.84,258,1620691200"; d="scan'208";a="747292124"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jul 2021 11:19:43 +0000
Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 16LBJhMk020769 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 21 Jul 2021 11:19:43 GMT
Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 21 Jul 2021 06:19:43 -0500
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 21 Jul 2021 07:19:42 -0400
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 21 Jul 2021 06:19:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V0mJQzYhKnapkBokBHKN2wX9fMjoqAC65BBpZ54NpN5nKqNyIS/WxHqYbhJ5rxrA4c+djmp68IcPEOEO0tGKnSjud/sdCkygwWH3aBTirWVesMFH9M+a7qFRJFHZBkHPntXzEIuFzIqlrpxir8Dyn+2n/97Pf4Gg7TAGefGvu4q8Ap0eecuXZOoM58vmaluivkJ4C59mv3tFZPbxRpz+Mn1yW9zTY09fOp5HIopSNYKLAGeUs2c6SJy7eV2MDHd65TyHrdUg4AW/JSbg4iXf9g32GTlUnp/afnDdbnGiNPuxgJ4IAlfTidk01r+90sWuwn0FcTWcR/C2Xu8kNXRozw==
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=1thOX7RrM+YhpIIxNd4ugxh5biUaReFM0aTkFUqegPg=; b=WgW0dk0iPV4qIzIsJ12nZr8MxiY8vRcuzS/L6RNODkX4M+6gydUrGZR4bviAbqrWYppFk3hHEPyqrIKD2w7/9uvfuqrXb4JDpFOM3HddbEWGhaT/YCWyR0i7As8hdOnw65/F6562GiBUiGECZJhAxfqE7KxgJEZ7pyJfGDS4nMBFI5Zempx3P5IgYx+4/JsUxebq2bNOv3DCGoeFRgS33hTOk8tC/6eb4God/d3DwXfv9Kwgb8G6JRyk2tJcmETq6HLDSAqCq0xyUL2VszoWHd3GsO7CF9kqBXIs6O2H4/pqVbqb6O5Wf96wUv9q3ev2gESZ3TNfRhWfm7CR4za8iQ==
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=1thOX7RrM+YhpIIxNd4ugxh5biUaReFM0aTkFUqegPg=; b=MChzVlW4E0Jgm6NS6EAVV5yYm4qzCx2yYhUeuxq+sgiM8XxQICbaplm0OeBGPdMo679fHfizzkW/EClWkQgqsS+qvlMMIUubkwpTyjYYMdEIGSk18LttBIIHwUNV4HYM9+zBzsGXz29T4WzmUCmMP15bswwWmnhK6ntEqKRKrKU=
Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3467.namprd11.prod.outlook.com (2603:10b6:5:8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.29; Wed, 21 Jul 2021 11:19:40 +0000
Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4352.025; Wed, 21 Jul 2021 11:19:39 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Miroslav Lichvar <mlichvar@redhat.com>, "odonoghue@isoc.org" <odonoghue@isoc.org>
CC: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>, "draft-ietf-ntp-interleaved-modes@ietf.org" <draft-ietf-ntp-interleaved-modes@ietf.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
Thread-Index: AQHXbord/l9A1AL6okGa5mIclAbM/qtFaabQgAfb5wCAAAJUYA==
Date: Wed, 21 Jul 2021 11:19:39 +0000
Message-ID: <DM4PR11MB5438B139954A35119B60ED0FB5E39@DM4PR11MB5438.namprd11.prod.outlook.com>
References: <YNw9fHMijDFIW9B4@localhost> <YNrbjCDF4/609dg/@localhost> <D999D237-5A25-4E84-99D0-EE5DB2B13411@cisco.com> <YN3ZzPN5LOsAjmz6@localhost> <DM4PR11MB5438D8450E7B90D363929640B5119@DM4PR11MB5438.namprd11.prod.outlook.com> <YPfmUK889qx7r5x2@localhost>
In-Reply-To: <YPfmUK889qx7r5x2@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2933f9b8-7ee9-4abb-21e0-08d94c396e73
x-ms-traffictypediagnostic: DM6PR11MB3467:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR11MB346740F4C92D07AE7581C990B5E39@DM6PR11MB3467.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2qy7X2FT13Xf7u0eAU3XAeO956LzwghtmVFTax2B2M7o36BUvCbacLEIhrr0AU0mfM0tU/NxbvVr6uwJ81rsiRgieYxRDfYsQEKY+pYthn1/g1+LN1mOmQqA5OqfL8r63DkyCKLTLJM6c2Gi3tekOL04lyIKGoegXk3HPk3AQPrJ3JClX1ap6gN5CGbWmrBg1YnmKQemSsm8htxiPW2WYOWzJVY4iApLbzrxvUmBLgTq62bZh8oDpamfU1P9XTzosO7mNm5K4anLFLxYOBOhdomYvAoT9j6LUXIxV3LsMkR1I+YtIRCbJiT2qj6slR6G/JxLu8E3FrUAZyQXG2bEdUyI8X/K52rUm/odCovuJ615JNgLZJogiEUKFCDO9a9dR1wCs56soOIRajd8BdjDttly/FeVu3ZdVzanuls38d5UuRsSFjSrmSub4bh+r68hQp/GpzcBstsCM80kB260sxFxRXn7hy65YcFPc+rtLZ8VopMVMmrvqR9QJe8Cl1PiNwsmXSHc0rXBDkNs0lQir6DIGZggppqpa4NCTxyFRrQvknD7EXA0CY2ID3c8VXfEGIwCTKGvaVdMsYgagn//KH0GcO/G3l436Ez22htUyKxhjYCBAo2chAjcpjHqwxvpbJhenzREWn9T5tfozP9hKwbd1ePGZHUPGLl7atMyEXR+ZFTHX6w3FZqS/wcafS7irnOjBShPnKsUq/SElb0OxA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(39860400002)(376002)(396003)(366004)(71200400001)(86362001)(55016002)(38100700002)(54906003)(8936002)(110136005)(9686003)(316002)(2906002)(53546011)(33656002)(6506007)(4326008)(83380400001)(478600001)(76116006)(7696005)(64756008)(66446008)(66556008)(5660300002)(122000001)(52536014)(66946007)(66476007)(8676002)(26005)(186003)(38070700004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4GvPQtj3P2xrqXoMEVAEybghb6k4jmyGVWFEddyAyrE5ndVhbdRb+jw4WkYp?= =?us-ascii?Q?4b3MT70+iP7/U+MpyI49KSG76oCcCIEqJ8fXs7od5T2yk+Fqa5jJrGSawemO?= =?us-ascii?Q?Gby99e867OblBmL6TEt+6kT1Z350QLgY2fnStOFmUp2/wS1im5GFAmE5ZewX?= =?us-ascii?Q?+CUPXvyP365ll6j6x1ZGxTNXobTSF7/7bspsbY2UnYeG0CEXyR9pmBKQ4oxi?= =?us-ascii?Q?0EKTNsvW+GtrUCSSZD9TxWq/F8lPCw/uWZ3D4qnfDPS8VabtxW0+bgUFF/Aw?= =?us-ascii?Q?BwfC1RFX0rVvDjMdwYEsWfxOjwY5nfdu3xY+vIwFaZD8ZqzFLIPlsqLqdUTV?= =?us-ascii?Q?g4hoQVo/51BY6bkbWuEyJ+9JwBQX75GVpe8j4jhXkMnhk9P5jQszQ0Qy187s?= =?us-ascii?Q?mcZW5HSoyOlOmOMJY+Hla0vJS5HkheiYGNU8WIMApAjyjVcb6s+u53nRlBbB?= =?us-ascii?Q?dGV55xW8qCVxJ34w89wenowI8bP7U6QkboueccwITl+uWbKapRf828rE6VOX?= =?us-ascii?Q?+5PQdKO0FI3et4fij8C0gODPhi/HYpDmhFa4vbcUl7l6X4sa/VyYkOeN+d35?= =?us-ascii?Q?Y0A9Y1z7Vt7uxPGBHyI2lopmvmz2y6TbeufEFg+C05z8X4uofUODD8kGqvn5?= =?us-ascii?Q?bYjP/0PNIAxPbdbLEVHohSoMiIIHZeTVSdpoMuTmQEMaoDxu8yyvIobqIer4?= =?us-ascii?Q?5u3I7HPs8qVeIk9ZA1NshCuD11VmWZywknXpwCb6n2MBgGLO/2A2YSVB0xmC?= =?us-ascii?Q?lnswo7cc5KAEYNpwbVNaLiB08GpnFyoJYaCvis0lJjKxQUK4iSCCNgHs0HFk?= =?us-ascii?Q?tmDKuiswoPC7JlNB2BUGmMWJEWKIDSI/+cu+SGgotUVAczjUaIyq3kOgDEzt?= =?us-ascii?Q?T9zvT0K0LGH682NrNgk+5941YFN6RzBO28Bsx0QGfzfSVjOSa5i7u3tnLdpR?= =?us-ascii?Q?pPAnXBRwMfGiBdaqkZpS4wXsXfvwI+km09NM77ig+B9T608wutKWbJGLIa1m?= =?us-ascii?Q?/XkBEo13XBpPshsCOnFBiwDhCWGyn5ZwQ+QIZGFcn7+dkH9P+dTnMT2yNlbo?= =?us-ascii?Q?GIJ4JsIoS+KC7CjvoXUMfPjGKhuK+pb0+6AeSGSHJCQE7xxDaRA8wjYBGDB1?= =?us-ascii?Q?D3w1saaZ4rOoJSF9XX9kMEXlfhUCQp0aunZb5I6eS0u5M69LSrS0++cuultA?= =?us-ascii?Q?FJMjHHTfuXW6+/+jvnpbQdfhbpXc2VctCccu3a2hAyC8rjZ31LhR3/M6OWSt?= =?us-ascii?Q?TQ3CAVcy2pGdUsjwE/hnoLi7sLRWpj3+XpoDNUBYvWs1aB3iYfZQ90Wa3iZG?= =?us-ascii?Q?Lgv1K2w6D4HyeWAiw5NNUsoF?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2933f9b8-7ee9-4abb-21e0-08d94c396e73
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 11:19:39.8287 (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: 3I7fURz0PuNRA5oTkPFutEJIYwIwQlTnrTCZ+npUYDjjHUHj3atMklERcmpTyf/wD8o/pQ6HdE22pY3dw2SHyA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3467
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jtjhtOSXgIw0gITJXEZsHSuSXZ4>
Subject: Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2021 11:19:53 -0000

Hi Miroslav,

Please see inline ...

> -----Original Message-----
> From: Miroslav Lichvar <mlichvar@redhat.com>
> Sent: 21 July 2021 10:18
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: Eric Vyncke (evyncke) <evyncke@cisco.com>om>; Warren Kumari
> <warren@kumari.net>et>; The IESG <iesg@ietf.org>rg>; draft-ietf-ntp-interleaved-
> modes@ietf.org; ntp-chairs@ietf.org; ntp@ietf.org; odonoghue@isoc.org
> Subject: Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-
> modes-05: (with DISCUSS and COMMENT)
> 
> On Fri, Jul 16, 2021 at 09:39:47AM +0000, Rob Wilton (rwilton) wrote:
> > Regarding the issue with the extension mechanism, another possible choice
> could be for the client to try and open two parallel sessions, one using a new
> extension field, and one without.  The client could then monitor the
> responses to the two sessions and choose whether to use the other with the
> extension or not.
> 
> To me that doesn't look like a very practical solution. It wastes
> bandwidth. SNTP clients use only one server and might not easily be
> modified to work with multiple associations. In case of a heavy packet
> loss, the client would be randomly switching between the two
> associations, or if it stuck to the interleaved mode once it was found
> working, it wouldn't fall back to RFC5905 if the server lost the
> support (e.g. after changing implementation implementation or
> reconfiguration), so it would have to restart the parallel association
> periodically.

I was assuming that a client would probably learn and maintain some historical state about whether a server at a given address has previously supported the new extension.  But I agree that it adds complexity.

> 
> Using a 28-octet extension field to convey a single bit of information
> is quite wasteful anyway.

Perhaps, but that is the mechanism that is available.


> 
> > Hence, I propose three possible alternatives:
> >
> > (1) Change this document to somehow make use of NTPs extension
> mechanism and continue down the path of publishing as a proposed
> standard.  This, I think, would probably entail taking the document back to
> the WG.
> >
> > (2) Change the document status to Informational rather than Standards
> Track, modifying the text to focus on documenting how some
> implementations work rather than as an endorsement from IETF that this is
> the right way to modify the NTP protocol.
> >
> > (3) Alternatively, if the authors/WG believe that publishing that document
> as proposed standard is definitely the right choice, then I would be willing to
> change my ballot position to abstain.  I.e., I don't agree with what is being
> done here, but neither will I block progression of the document, given that
> you say that this modification does not cause operational issues in practice.
> 
> If those are the only options, the preference of the WG seems to be
> the second one.

In case it is not clear, I'm only representing my individual view, not any sort of consensus of the IESG (but I am also aware that Ben and Warren have balloted abstain).  Hence, a 4th choice is to wait until the doc is on the telechat, all ADs have had a chance to ballot on it and perhaps verbally discuss it at the telechat.  I think this is waiting for Karen's shepherd writeup to be updated because it was for the wrong doc.  In fact, updating the shepherd writeup and waiting for all ADs to ballot and discuss is possibly the most sensible choice of action.  I.e., I don't want you to spend time updating it to informational only for some other ADs to decide that would not be sufficient, and hence you end up wasting your time.


> 
> Could you please clarify why you don't see the proposal as the right
> way?

I think that my objections really come down to two points:

(1) The protocol has an extension mechanism, but the solution is choosing not to use it.  I appreciate that the extension mechanism is deemed to be broken and NTPv5 is meant to fix it, but then I question why standardize this particular extension now, 10 years after NTPv4 was standardized.  I.e., presumably you could bake this enhancement into NTPv5 in a very clean way.

(2) It seems to be redefining the meaning of some of the protocol fields, not in a small way, and I'm not really sure that this is the right thing to be endorsing.  I.e., balloting "No objection" wouldn't really be right, because I do have an objection to what is being done here.

However, I balance those two points with:
 - I'm not familiar with NTP (but I noted that Daniel, who presumably does know NTP, seems to making similar arguments)
 - Some implementations are clearly doing this (and seemingly have been for a long time) and pretending otherwise doesn't really help.
 - You have explained/clarified that this interoperates with existing deployments.
 - You have explained that it doesn't cause additional operational complexity in practice.

... which is why I ended up with those suggestions above.


> Do you agree with the RFC5905 interpretation that Daniel Franke
> pointed out in his objection, that SNTP clients are free to put
> anything in the origin timestamp because the "An SNTP client can
> operate with any subset of the NTP on-wire protocol" doesn't have
> a MUST?

I really don't know the protocol, and I think that I would need to have a much better understanding of RFC5905 to give a properly meaningful answer here.  Looking back at Daniel's comments, I am somewhat persuaded that RFC5905 states that these fields can be ignored, and doesn't say what value field must contain if they are 'ignored'.  But equally, if the field had a non-zero value then would that not also mean that field is being used, assuming that there are no other bits in the packet to indicate whether the field has meaning?  Hopefully, clarifying this is in the plan for the next version of NTP ...
 
Regards,
Rob


> 
> Thanks,
> 
> --
> Miroslav Lichvar