IETF Logo Mail Archive

Re: [Ntp] New Version Notification for draft-rsalz-update-registries-00.txt

"Salz, Rich" <rsalz@akamai.com> Mon, 04 January 2021 14:59 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 707023A0DC2 for <ntp@ietfa.amsl.com>; Mon, 4 Jan 2021 06:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.449
X-Spam-Level:
X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdbq9r5njcXa for <ntp@ietfa.amsl.com>; Mon, 4 Jan 2021 06:59:25 -0800 (PST)
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 745933A0DC0 for <ntp@ietf.org>; Mon, 4 Jan 2021 06:59:24 -0800 (PST)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 104EsFa4005859; Mon, 4 Jan 2021 14:59:24 GMT
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=+kh7QSAaQfCSMy451IGWybFMYYBQ0O7DBljcSQ3/OLM=; b=ASsulQUFLg3td+grV7EU+XGm0WCSBa0IC2bMq5BcYvVgN84uNWMkbTgwabB3IB8klywd nTrZhqqGwb6m0mu/t1/u90WPRp59SX/ZGbAOFd2WPg68xfxDfBQhJDLfnQSyb8gVCaFI enWt2WoIYF58sTWM8ZZ7QIdefVTokETnD8GW4EdkZrLEOFYY88IC28o2LN6OaNDuJ0Pp NfAPoAa3UAwom3oz7eYecmQvL4p6V8TsBf3Z7WruH23ev4ldTruXgRuWwlX2JPPfr0NP GdfvQgskcOFifv8vPBZMszKy0pScyf8T1R5YjbqfZaD4HJu0Kl7tQ0Tb1XNiHRKyAR+3 Mg==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 35uj3h6y49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 14:59:24 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 104EoXDI032377; Mon, 4 Jan 2021 09:59:22 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 35tn22cn0r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 09:59:22 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 09:59:21 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Mon, 4 Jan 2021 09:59:22 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Miroslav Lichvar <mlichvar@redhat.com>
CC: "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] New Version Notification for draft-rsalz-update-registries-00.txt
Thread-Index: AQHW2J/m8vwbIM2enE6DpP13y96nnKoDkAWAgBRjoID//69mAA==
Date: Mon, 04 Jan 2021 14:59:21 +0000
Message-ID: <3FBAA9E7-A251-4C68-9231-A0271227EF6C@akamai.com>
References: <160866842930.12375.2768184613474168188@ietfa.amsl.com> <8E362353-B91C-445B-B16E-166BE3A9045A@akamai.com> <20210104144735.GA2992437@localhost>
In-Reply-To: <20210104144735.GA2992437@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.118.139]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0C0B8395835B8141A05AD3097357169E@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-04_08:2021-01-04, 2021-01-04 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 malwarescore=0 adultscore=0 mlxlogscore=811 suspectscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101040097
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-04_08:2021-01-04, 2021-01-04 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 adultscore=0 clxscore=1015 impostorscore=0 mlxlogscore=732 malwarescore=0 phishscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101040098
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint2
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/q-0U9vd0AybfjbMxsdiM0VSx6z0>
Subject: Re: [Ntp] New Version Notification for draft-rsalz-update-registries-00.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Mon, 04 Jan 2021 14:59:26 -0000

>    Is it ok to refer to RFC 5906 for the swapped values, when it's only
    used by the (one existing) implementation and not the specification?

I think so, but

 >   I liked the Daniel's idea to keep them both, the original values
    unchanged and then mark the swapped set as reserved, occupied, or
    similar.

If we're listing them as reserved, we should put them in the RFC.  I'll do that today or tomorrow.

>    I'm ok with the the proposed range 0xD000-0xFFFF for experimenal
    extension fields, but others here probably will not like it as it will
    randomly set the "response" and "error" flags in their interpretation
    of the value.


Is there a better way to word this (at least in the text, not necessarily in the registry) so that the response and error flags are maintained?  "PR's welcome" :)

v2.23.0 | Report a Bug | By Email