Re: [IPSECKEY] Unknown format handling

Rob Austein <sra+ipseckey@hactrn.net> Thu, 05 June 2003 19:23 UTC

Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13161 for <ipseckey-archive@lists.ietf.org>; Thu, 5 Jun 2003 15:23:21 -0400 (EDT)
Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h55JMQH29071 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 5 Jun 2003 15:22:28 -0400 (EDT)
Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) id h55JNPd01033 for ipseckey-outgoing; Thu, 5 Jun 2003 15:23:25 -0400 (EDT)
Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h55JNOi01028 for <ipseckey@sandelman.ca>; Thu, 5 Jun 2003 15:23:24 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 75DD218EC for <ipseckey@sandelman.ca>; Thu, 5 Jun 2003 15:20:50 -0400 (EDT)
Date: Thu, 05 Jun 2003 15:20:50 -0400
From: Rob Austein <sra+ipseckey@hactrn.net>
To: ipseckey@sandelman.ca
Subject: Re: [IPSECKEY] Unknown format handling
In-Reply-To: <20030605091946.GA10387@ivan.int-evry.fr>
References: <Pine.NEB.3.96L.1030530153519.60084G-100000@fledge.watson.org> <Pine.NEB.3.96L.1030604233939.8368F-100000@fledge.watson.org> <20030605091946.GA10387@ivan.int-evry.fr>
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20030605192050.75DD218EC@thrintun.hactrn.net>
Sender: owner-ipseckey@sandelman.ottawa.on.ca
Precedence: bulk
X-List: ipseckey@sandelman.ottawa.on.ca

At Thu, 5 Jun 2003 11:19:46 +0200, Jean-Jacques Puig wrote:
> 
> > On Fri, 30 May 2003, Sam Weiler wrote:
> > > Does the document need to specify the handling of unknown gateway
> > > types/formats (section 2.4)?
> 
> Is this point closely tied to DNS / Resolvers operations or is it up to
> a user scenario of the RR to tackle it ?

It's just payload as far as DNS is concerned.

> Do RR proposals usually specify handling of unknown values for fields of
> this kind ?

Since this RR is just DNS payload, the main thing here is the set of
constraints documented in draft-ietf-dnsext-unknown-rrs.

> Isn't it implicit that in case of the occurence of such an event, the RR
> should be ignored ? Is it implicit in cases where other fields (algo
> type, etc) have unknow values ?

Some people think that a spec should constrain as little as possible
(but no less).  Others think that a spec should specify how to handle
unknown values ("ignore any such RR" would appear to be the only sane
candidate in this case, since the gateway type determines the length
of the gateway field (and no, I don't think we want to change that)).

In either case, this is a general question of what a protocol spec
ought to say about unassigned values in an enumerated field, and is
not particularly specific to DNS.

> Is there a need to define RESERVED or VENDOR SPECIFIC ranges for this
> field ?

Unless there's consensus right now to do this, I'd suggest just
leaving it alone.  It's easy to allocate a portion of the space at
some later date, much more painful to take it back.
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.