Subject: RE: [dhcwg] Incorporation of WG last call comments in draft-aboba -dhc-domsearch-06.txt

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 26 Sep 2001 15:17:33 -0500

Please do note that there is no way a client (or server) can know if the other entity supports this concat behavior.

I think what Bernard was trying to assure is that anyone that implements the domsearch option must also implement the concat behavior.

Since this is perhaps an option that could result in an option longre than 255 bytes, it makes sense to do this.

One thing that does concern me about the concat option (really belongs to the other thread on that matter) is that there is no way a client (or server) can know if the other entity support the concat behavior. And, suppose a server sends an domsearch option which is concat, what if the client doesn't do the concat and uses the last (or first) instance. The domain search list that client uses would be very broken.

Another issue for concat option is what happens if an option is split because it crosses a buffer boundry - in this case, it isn't even long options that are affected. And, again, if a client doesn't concat that option ...

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 3:26 PM
To: Bernard Aboba
Cc: Thomas Narten; [email-masked]
Subject: Re: [dhcwg] Incorporation of WG last call comments in
draft-aboba-dhc-domsearch-06.txt 

RFC2131 allows for options that can carry
data values longer than 255 bytes, so my understanding,
too, is that the option concatenation standard would
apply to all DHCP options.

- Ralph

At 11:55 AM 9/26/2001 -0700, Bernard Aboba wrote:
> > > >Not sure the reference is normative. This option can use the long option
> > > >encoding if available, but doesn't require it.
> >
> > > Agreed; in fact, I think you could eliminate references to
> > > the long option encoding draft w/o harming your spec...
> >
> > This make sense to me. I will note, however, that current wording in
> > the concat draft could be interpret to suggest that it's intended for
> > future options and maybe less so for existing options. If the intent
> > is in fact that it the concat draft should apply to *all* DHCP
> > options, then taking out the reference would be fine.
> >
> > If that is the intent, I'll go ahead and start the IETF last call on
> > domsearch.
>
>I had thought that concat would apply to all DHCP options that could
>potentially run over the current limit.

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2001 18:01:41 -0700

I have to agree with Bernie here - the point of referencing the concat
option is to make *sure* that a client that does domsearch (or csr)
also supports concat.   A client that implements domsearch or csr but
not concat then becomes non-conforming.   If domsearch or csr doesn't
*require* concat, then this is not the case, and the server doesn't
know whether or not it can do concat.   So domsearch and csr *must*
require concat.   And this is why concat is worded the way it is - if
it were required across the board, it would be useless, because there
would be no way of telling DHCP agents that support it from DHCP
agents that don't.

			       _MelloN_