Subject: Re: WGLC: Name Server Identifier Option

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Oct 2005 13:49:54 +0000

# > OPTION-DATA field as opaque implicitly violates the assumption of  
# > 2671 that OPTION-DATA be comprised of attribute/value pairs.  Might  
# > make this explicit.
# 
# my reading of 2671 is that the (CODE/LEBGTH/DATA) container described in
# section 4.4 already *is* the "attribute,value" pair.

yes.

# Otherwise there's nothing said about the separator between attribute and
# value and the charset issues. Maybe a clarification to 2671 is needed when
# it goes to Draft.

suggestions welcome.  but i think drc wanted the NSID option to have its own
interior attr:value segmentation structure, in which case the clarification
should be in drc's proposal rather than in 2671.

# Will the EDNS version to be announced remain "0"?

yes.  implementations of EDNS are expected to ignore options they don't
recognize.  THAT is something we can clarify when 2671 goes to draft.
the version number is about the message format and message field meanings;
it doesn't have to do with content like OPT options.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Oct 2005 10:20:38 -0700

On Oct 7, 2005, at 5:44 AM, Peter Koch wrote:
> my reading of 2671 is that the (CODE/LEBGTH/DATA) container  
> described in
> section 4.4 already *is* the "attribute,value" pair.

D'oh.  Needed more caffeine.  Apologies.

> But as you mention the length: what is the responding server  
> supposed to do
> if putting in the requested information would exceed either 512 octets
> or the maximum available payload size as "negotiated" between the
> requestor and itself?

Set the truncate bit?

> Will the EDNS version to be announced remain "0"?

I'd wouldn't think there would be a need...

Rgds,
-drc