IETF Logo Mail Archive

Re: [kitten] Updating IANA krb5 GSSAPI token type registry

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 04 March 2014 21:44 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DEF1A0139 for <kitten@ietfa.amsl.com>; Tue, 4 Mar 2014 13:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 AlQI9ecXz3pA for <kitten@ietfa.amsl.com>; Tue, 4 Mar 2014 13:44:32 -0800 (PST)
Received: from smtp01.srv.cs.cmu.edu (smtp01.srv.cs.cmu.edu [128.2.217.200]) by ietfa.amsl.com (Postfix) with ESMTP id 297BF1A00F0 for <kitten@ietf.org>; Tue, 4 Mar 2014 13:44:32 -0800 (PST)
Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s24LiQWe029849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 16:44:27 -0500 (EST)
Message-ID: <1393969466.4395.211.camel@minbar.fac.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Simo Sorce <simo@redhat.com>
Date: Tue, 04 Mar 2014 16:44:26 -0500
In-Reply-To: <1393968964.22047.99.camel@willson.li.ssimo.org>
References: <20130806223553.CD3401A8EC@ld9781.wdf.sap.corp> <29F4D66E-3E8F-4033-8779-8EA158C1B72A@padl.com> <alpine.GSO.1.10.1308062018070.24720@multics.mit.edu> <alpine.GSO.1.10.1309041148130.16692@multics.mit.edu> <alpine.GSO.1.10.1403041135510.1213@multics.mit.edu> <1393968964.22047.99.camel@willson.li.ssimo.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on 128.2.217.200
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/JHpYwIox5OVR_IN_9RnFoSpm0WU
Cc: kitten@ietf.org, jhutz@cmu.edu
Subject: Re: [kitten] Updating IANA krb5 GSSAPI token type registry
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 21:44:34 -0000

On Tue, 2014-03-04 at 16:36 -0500, Simo Sorce wrote:
> On Tue, 2014-03-04 at 11:49 -0500, Benjamin Kaduk wrote:
> > 
> > To me, this seems like a(nother) bug in RFC 7055, but of course it is
> > not one that can be reasonably fixed.  I guess that the easiest way
> > forward is to publish a quick document that reserves 0405 and 0501
> > noting that they were in use before the registry was established.
> 
> +1 if there is a registry we must avoid errors in allocations, and
> allocating 0405 or 0501 to something else would definitely cause
> standards issues.

No, you have it backwards.  The registry doesn't create the requirement
to avoid conflicting allocations; it is a tool for helping to meet that
requirement.

We probably don't actually need to publish a document; it ought to be
sufficient to point out to IANA that there is a conflict and ask that
the relevant numbers be marked reserved.

-- Jeff

v2.23.0 | Report a Bug | By Email