Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

"Salz, Rich" <rsalz@akamai.com> Fri, 12 August 2022 14:44 UTC

Return-Path: <rsalz@akamai.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 C4635C14792F for <ntp@ietfa.amsl.com>; Fri, 12 Aug 2022 07:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.686
X-Spam-Level:
X-Spam-Status: No, score=-7.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=akamai.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 ZRLleP2nE5hk for <ntp@ietfa.amsl.com>; Fri, 12 Aug 2022 07:44:41 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 8D0F0C157902 for <ntp@ietf.org>; Fri, 12 Aug 2022 07:44:39 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27CD2mor029217; Fri, 12 Aug 2022 15:44:39 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4/V+0oEwqv6wf+O+5IsDTGr0ZBYDBaWM8vs3QKPuhSA=; b=Dp4Tmylws2cEcKz7RP8wvrd5hwmpGq5O6j8EcynJPs8bgkWFO+FvTdpDd6CkejPWhBUX 5TRa5GysZWbecg8UkpSy8h3fyroEVF75pXGix3vrKV0Wcpx7EM3Q1AuHip564Ew5Efn8 8bcpv9e6tbXL6AyA1Ab9BMV2l81JYl0tNUsz6WaNzH9wWTh7MDdJxWiVSjzyCjruh4rJ SiFZcet0ERTGtDet4gB9Q4neUkxwJLfcKJll6DcjwyPUo2ncEcjaRv1HXw232opvux21 RwK3yZ7ZyyUdLoUoTJt7aZvUsv+HqW5Lf6+x9bsnbgOJs9w3uurL1YxpQ9wCorotBzdj Jw==
Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3hwqcxc184-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Aug 2022 15:44:39 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.17.1.5/8.17.1.5) with ESMTP id 27CD7w4J003844; Fri, 12 Aug 2022 10:44:38 -0400
Received: from email.msg.corp.akamai.com ([172.27.50.204]) by prod-mail-ppoint4.akamai.com (PPS) with ESMTPS id 3hw4rk4vhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Aug 2022 10:44:38 -0400
Received: from ustx2ex-dag4mb4.msg.corp.akamai.com (172.27.50.203) by ustx2ex-dag4mb7.msg.corp.akamai.com (172.27.50.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Fri, 12 Aug 2022 07:44:37 -0700
Received: from ustx2ex-dag4mb4.msg.corp.akamai.com ([172.27.50.203]) by ustx2ex-dag4mb4.msg.corp.akamai.com ([172.27.50.203]) with mapi id 15.02.1118.009; Fri, 12 Aug 2022 07:44:37 -0700
From: "Salz, Rich" <rsalz@akamai.com>
To: Harlan Stenn <stenn@nwtime.org>, Miroslav Lichvar <mlichvar@redhat.com>
CC: "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries
Thread-Index: AQHYo3iklRsxrQl4lkuQ3OozvjI9ta2WK30AgAADLQCAAA2mgIAACTUAgA7zdoCAAAZvgIAAFDIAgAAigYCAANvngIAAop8AgAMdcYCAADkJgIABLRuAgAAnNwA=
Date: Fri, 12 Aug 2022 14:44:37 +0000
Message-ID: <B0A738B6-37A7-420A-97ED-EA6E9D995FE3@akamai.com>
References: <PH0PR06MB7061FA7A5B338D262B3A2963C2999@PH0PR06MB7061.namprd06.prod.outlook.com> <6a187a2f-9883-2fb5-1f51-1593591ddebb@nwtime.org> <PH0PR06MB706126984E4442EF32F8242AC2999@PH0PR06MB7061.namprd06.prod.outlook.com> <da155c84-2c70-2e3b-59eb-03e380806cf2@nwtime.org> <PH0PR06MB70611F2331D8255F7E2B6604C2999@PH0PR06MB7061.namprd06.prod.outlook.com> <0b4c7efa-3977-b588-0974-33b6a9437e52@nwtime.org> <YvDWC27qKnODlD52@localhost> <0b57b7db-772e-f5e6-e6a0-a433673f3d77@nwtime.org> <YvED7T5R0UsRWbv3@localhost> <b64c6a0a-ea2e-0a19-4bb9-38bfaa2e5032@nwtime.org> <656D355F-E06A-4005-B9D6-90885FA8509D@akamai.com> <1a4bae28-f0f3-e675-899a-bad597b4ee29@nwtime.org> <F74A7B5B-3D77-42AF-BD7E-1A874CCD2D66@akamai.com> <67545c9a-3291-bbe6-c876-4c762c80c710@nwtime.org>
In-Reply-To: <67545c9a-3291-bbe6-c876-4c762c80c710@nwtime.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.61.22050700
x-originating-ip: [172.27.118.139]
Content-Type: text/plain; charset="utf-8"
Content-ID: <55BB63333FA24745A0D69653B5A2A119@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-12_09,2022-08-11_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 bulkscore=0 spamscore=0 phishscore=0 suspectscore=0 adultscore=0 mlxlogscore=776 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208120040
X-Proofpoint-GUID: uTleDHEFNlzDaUzsEN4KX6OTEDjr6Dwj
X-Proofpoint-ORIG-GUID: uTleDHEFNlzDaUzsEN4KX6OTEDjr6Dwj
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-12_08,2022-08-11_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 phishscore=0 adultscore=0 mlxlogscore=729 clxscore=1015 malwarescore=0 suspectscore=0 spamscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208120040
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Kqx2QOeC43ULoL06k3Ake4OhD1I>
Subject: Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 12 Aug 2022 14:44:45 -0000

>    I believe I have asked about the costs and benefits of each approach 
    before, and I have never seen you or anybody else respond to that request.

I believe this is not a question that can be answered. I can only, yet again, point out that I have seen multiple experiments in TLS and DNS and they worked fine.

>    You have also not said anything about the long-tail cleanup of your 
    approach.

There is no long-tail cleanup. Using the experimental area is for experiments. There are no registry actions. Experiments often happen among one, or maybe a few, parties. If they want to put their code into production for interoperable implementations, they have to document the protocol and change the number that they use. If they quietly stop their experiment, that's fine. They don't have to tell anyone what they are doing. Perhaps the NTF penciled-in registry could be used to track such experiments. But it's not necessary, and no harm will be done if not.

    >>     NTF has maintained a "penciled in" registry for folks to test out EFs,
    > 
    > So you are okay with a registry, you just don't like that it's in IANA and not at NTF :)

>    Please be serious.

I am serious.

    > The other difference is that the NTF list will assign numbers in the standard space, and the WG doesn't want that.

>    Some of the WG does.

To the extent that the mailing list reflects the WG feelings, using "some" instead of "I" is not clear. Please avoid ambiguities.

>    And I'm not totally clear on what you mean when you say "will assign 
    numbers."  Please be complete and clear with what you want to communicate.

Sorry, when talking about an IANA registry, I thought it was obvious.  Since your organization maintains a "penciled-in" registry I thought you knew. Someone adds an extension to NTP. They write up an internet draft and post it, or the work is done in another SDO and the standard is freely available. They approach IANA and say "I would like a number for my extension." The designated experts read the draft, see if it is complete enough to implement, etc., and say "okay, you can have 0xXXXX" and IANA updates the web page. If this is not clear to you, I suggest that you read RFC 5226.

>    I don't care where the registry lives.  I have long mentioned the 
    "penciled in" registry, and Karen and others have said "There's no real 
    way to do that with IANA".  Are you now saying that IANA will allow this?

No I am not saying that.  Please see my previous messages on this, and the "no long-tail" paragraph above. I am sorry if you still do not understand, I've reached the limits on my ability to explain.

>    Does anybody really think rough consensus will produce a high-quality 
    result?

It's worked for the IETF for the past 30 years. :)  Sure there have been mistakes, but overall, the process works.

>    I would be REALLY happy if the folks who think NTP should be taken in 
    backward-incompatible directions and be driven by rough consensus would 
    start a new WG and use a new port and come up with their results in a 
    way that didn't destroy the existing NTP framework.

Interesting observation, and perhaps a clue to your motivation, but I don't see how this draft helps that come about.