Subject: Re: [IPSECKEY] Unknown format handling

From: Sam Weiler <[email-masked]>
Date: Wed, 4 Jun 2003 23:40:07 -0400 (EDT)

On Fri, 30 May 2003, Sam Weiler wrote:

> Does the document need to specify the handling of unknown gateway
> types/formats (section 2.4)?

We've heard no feedback on this.  Anyone care?

-- Sam

-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Jean-Jacques Puig <[email-masked]>
Date: Thu, 5 Jun 2003 11:19:46 +0200

> We've heard no feedback on this.  Anyone care?

I care, but I lack knowledge of practices for RRs design.

Is this point closely tied to DNS / Resolvers operations or is it up to
a user scenario of the RR to tackle it ?

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

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 ?

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

--
Jean-Jacques Puig
-

---

From: Rob Austein <[email-masked]>
Date: Thu, 05 Jun 2003 15:20:50 -0400

> 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

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

> 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

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 [email-masked] list.
Email to [email-masked] to be removed.