Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT)

Peter Saint-Andre <stpeter@stpeter.im> Thu, 03 August 2017 01:40 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3F8129B2A; Wed, 2 Aug 2017 18:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Whmj7v9F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aIKMqZxG
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 GS1YLs5w4j5O; Wed, 2 Aug 2017 18:40:56 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EF2131CE8; Wed, 2 Aug 2017 18:40:56 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9EB1920984; Wed, 2 Aug 2017 21:40:55 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 02 Aug 2017 21:40:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=IDC3C2pa7WNQaCW8ni muhxq46jAIjZiHw8VOCYf0hSY=; b=Whmj7v9Fy4hQyaK9Gq60u2zfiQ2OKYgbbs sv3t93CIFx6U5ZZMScDwVFliE/BrmpbOfpl37JTtkjE/XFhK0Ah57hYZ6Qn+trpL O7KdQKkC403ZeYI/gJ3o+6McR6fh0AnOB9XyOsViCtG0H8NpRSCCn9PIpXG1bEo6 Bj3+d5SMOw7uLBd+jBC3UOWBItAX7cemytivUHZkATo/CQw1xDjyWj8UMSe9WQii QI1ZKYpp2mCaLykGFpWwguI8QI8omj7GvJu8CViIX3lrH6YdCcmrZewTm0KXn+YS geNTV6tObk4I+x06qScwpukDtAEDqdBQjR3z5y+8w1m1sF/WCfZQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=IDC3C2pa7WNQaCW8nimuhxq46jAIjZiHw8VOCYf0hSY=; b=aIKMqZxG LCR3PDLF/q33VtVQ/k3BlaIJTst+UfjauZvMm55mG9nTsfNTCy4rRjaKgYyJ5Lcn 96WSNFXkKrpb9sqxPN//BTBLMi6Grvo9w7diMHgod0CkUx08bbnEq9MoPFDKwwVZ +ziI6hg5azs6XPHulnawb5TcwTWu6FHbfaFhaB19sv+p6KpliP9I+C2BmJqQE7KM 2gaJMlI4q9lTYjU8TX+Gpv71zeR8B77GyteazN6JCFb22ppeu+Kt8zrneDdaTlmC htrIabnZ+n89DyTDuJ9NIoXdeMGda1DhwIqBFzZZQe9sTE35HLdyIYE7Pd7K5H7d 4EoX6pRQLg1+8g==
X-ME-Sender: <xms:J3-CWabhncdCNdqHYGv7V49MXBxGI6opP1_u57H9As8BJXacxeoLkA>
X-Sasl-enc: 5G5dtI8FywKF0WVnvLOxNUg/AQLUlnbNJ+EAyGyMvNa6 1501724455
Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9082224515; Wed, 2 Aug 2017 21:40:54 -0400 (EDT)
To: John C Klensin <john@jck.com>, Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> <D63753FAD3AED4C4AC5820D6@PSB>
Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <60d0c8a5-e20e-a5f1-0482-56183aed4a74@stpeter.im>
Date: Wed, 02 Aug 2017 19:40:52 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <D63753FAD3AED4C4AC5820D6@PSB>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/rv73dI2brdkftNR4b-7trtz0-G0>
Subject: Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2017 01:40:58 -0000

A small comment on one point...

On 8/2/17 6:39 PM, John C Klensin wrote:
> 
> 
> --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell
> <ben@nostrum.com> wrote:

<snip/>

>> And
>> since IANA may have to deal with a mix of old and new
>> templates for some transition period, it doesn't remove the
>> need for them.
> 
> Whoops!   I either don't understand what you are saying above or
> it indicates one or more series editorial or explanatory
> problems in this I-D, RFC 8141, or both.  For any given
> namespace, there is only one template at any given time and IANA
> has only one such template registered.  There is no transition
> in IANA's scope and no need (or opportunity) for IANA to deal
> with an old template and a new one at the same time for any
> given namespace.    I assume that a template (again for a
> particular namespace) could discuss transitions from an earlier
> form, but that would be an intra-namespace issue, not anything
> IANA needs to deal with or even be aware of.  The sense in which
> IANA needs to deal with both old and new templates is that there
> are namespaces defined under RFC 2611 or 3406 for which new
> templates have not yet been provides (and may never be), but
> that isn't a transition topic that IANA has to manage either
> (and the procedures for having some older registrations
> conforming to the old template and mechanisms and some
> conforming to the new ones was carefully sorted out with IANA as
> part of RFC 8141, so, if there is an issue, it isn't with this
> document.

With my RFC 8141 co-author hat on, I concur. There is no transition
period in general, and there is no transition period for any particular
namespace because if the registration is updated (e.g., from version 1
to version 2) then the old registration is immediately outdated as soon
as the new registration is placed in the registry by IANA. IMHO this is
clearly spelled out in RFC 8141 (and RFC 3406 before that).

Peter