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

Harlan Stenn <stenn@nwtime.org> Fri, 12 August 2022 08:24 UTC

Return-Path: <stenn@nwtime.org>
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 B0524C157B3A for <ntp@ietfa.amsl.com>; Fri, 12 Aug 2022 01:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 LENPqKE5nsGS for <ntp@ietfa.amsl.com>; Fri, 12 Aug 2022 01:24:20 -0700 (PDT)
Received: from chessie.everett.org (unknown [IPv6:2001:470:1:205::234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8E7C14F74C for <ntp@ietf.org>; Fri, 12 Aug 2022 01:24:16 -0700 (PDT)
Received: from [10.208.75.149] (071-084-168-128.res.spectrum.com [71.84.168.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4M3xXw2PyVzMP3W; Fri, 12 Aug 2022 08:24:16 +0000 (UTC)
Message-ID: <67545c9a-3291-bbe6-c876-4c762c80c710@nwtime.org>
Date: Fri, 12 Aug 2022 01:24:15 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: "Salz, Rich" <rsalz@akamai.com>, Miroslav Lichvar <mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
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>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <F74A7B5B-3D77-42AF-BD7E-1A874CCD2D66@akamai.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Iuh1lDFnNeLGFaVK9ZVhTG3BhRo>
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 08:24:24 -0000

On 8/11/2022 11:26 AM, Salz, Rich wrote:
>>     I know this, and I believe the approach used by your proposal is wrong.
> 
> You are the only one who has posted against an experimental range, so you're in the rough here.

That doesn't really mean anything regarding the key issue: what is the 
better/cleaner solution.

I strongly disagree with your approach.

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.

>>   If folks don't "register" their choice of numbers, there can be conflicts.
> 
> But only with experiments, and only in the experimental area. And as you have pointed out the number of expansion fields has been pretty small over the years, which further reduces the chance of conflict. But I think the main point is that experiments *cannot conflict* with standards work.

What exactly are you saying here?  I find your statements to be ambiguous.

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

>>     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.

> 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.

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.

> Internet registries and Internet-scale experiments have changed a great deal in the way people use them, perform them, etc. A private web page separate from IANA is not the way things are done any more. What do you do if NTF has a "penciled in" value that the WG assigned? Does the WG have to check with NTF before doing that?
I thought the goal is to have IANA assign numbers, using "experts".  Not 
the WG (in general).

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?

If, indeed, the IANA registration will be changed to be "assigned by 
experts" then as long as the folks assigning the numbers are actually 
experts there should be no problem.

>>     So I still see problems with what you have described
> 
> That's okay.  Rough consensus after all. And BTW, working cleanly with an unadopted draft wasn't a goal of this draft.

Most disturbing.

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

>      > We have seen problems before with autokey implementation compared to documentation.
> 
>>     As I have repeatedly said, that's because autokey implemented/used the
>      V1 header layout and the IANA table documented the v2 layout.
> 
> I am not blaming any party.

I wasn't talking about blame.  Why are you mentioning it?

> And again, having these things documented *by the party interested in the implementation*, and having designated experts to review, WILL make this much less likely in the future.

If the experts are really experts, then I tend to agree with you.

>      > Making the public section of the registry "Specification Required" prevents that.
> 
>>     In theory I agree with you.  And in theory, theory and practice are the
>      same.  But in practice, they are not.
> 
> Shrug.  I've been a TLS designated expert for years and it works. I've helped people register MIME types, and it works.

NTP is not TLS or MIME.

>>     I have not seen any refutation of my observation.
>   
> https://mailarchive.ietf.org/arch/msg/ntp/rYrGnLSeP_ag1hILQTLjIUMOrmo/  It included several examples.  You quoted, and said "makes sense where appropriate." The WG thinks it is appropriate here, and you don't.

A handwave in a general direction is not a clear example.

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.

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!