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

Ben Campbell <ben@nostrum.com> Thu, 03 August 2017 02:15 UTC

Return-Path: <ben@nostrum.com>
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 EDF4B1321B8; Wed, 2 Aug 2017 19:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 eblF4KhNVQN8; Wed, 2 Aug 2017 19:15:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02581321B9; Wed, 2 Aug 2017 19:15:44 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v732ElvG049535 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 21:15:44 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <60d0c8a5-e20e-a5f1-0482-56183aed4a74@stpeter.im>
Date: Wed, 02 Aug 2017 21:15:43 -0500
Cc: John C Klensin <john@jck.com>, The IESG <iesg@ietf.org>, urn@ietf.org, urnbis-chairs@ietf.org, Barry Leiba <barryleiba@computer.org>, draft-ietf-urnbis-ns-reg-transition@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E2161F0-2460-4767-94CD-5BBF8C652A33@nostrum.com>
References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> <D63753FAD3AED4C4AC5820D6@PSB> <60d0c8a5-e20e-a5f1-0482-56183aed4a74@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/PCAQTDn-DaciI6l-C8WlG5Vm_-g>
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 02:15:46 -0000

> On Aug 2, 2017, at 8:40 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 
> 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).
> 

Yes, that was a mistake on my part (see my response to John). In my defense, I’ve reviewed a lot of documents over the past couple of days and my brain was tired :-)

Ben.