Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-05

["Bernie Volz (volz)" <[e-mail]>]

I agree with Bud and Damien (and David) ... Defining suboptions would be
far better way to go.

Suboption 1 - URI
Suboption 2 - Fingerprint

(You could start with suboption 0, but as most sub-option users avoid
suboption 0, I would not recommend it.)

Now, if the intent is to allow multiple URI instances ... That should be
OK as I don't recall that option concatentation extends to suboptions.
Therefore, two instances of the same suboption are technically possible.
Though hopefully that is not the case as it complicates servers (and
clients) and is likely not supported by most servers today?

The same should be done for DHCPv6 (though of course the suboptions are
16-bit sub-option code and length fields).

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Bud Millwood
Sent: Wednesday, January 28, 2009 3:52 AM
To: [e-mail]
Subject: Re: [dhcwg] dhc WG review of
draft-ietf-geopriv-lis-discovery-05

On Tuesday 27 January 2009, Ralph Droms wrote:
> David - if, indeed, the idea is for one URI, with an optional
> fingerprint, would the following format be sensible and simpler to
> parse?

This option would be much better served as a subencoded option IMO. It's
going 
through terrible contortions to encode both fixed-field settings and
variable 
length settings.

I think a better approach would be to encode everything as suboptions,
and 
then to simply dictate which options should be present under the
different 
circumstances.

- Bud

>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |    LIS_URI    |    Length     | Hash-Type-Len | Hash-Type   ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |                           Hash-Type (cont.)                 ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |  Fprint-Len   |           Fingerprint-Value                 ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |                           URI                               ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     |                           URI (cont.)                       ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> where Hash-Type-Len and Fprint-Len are both either zero (no
> fingerprint) or greater than 0 (fingerprint included).
>
> - Ralph
>
> On Jan 27, 2009, at 2:39 PM 1/27/09, David W. Hankins wrote:
> > On Tue, Jan 27, 2009 at 06:41:06AM -0500, Ralph Droms wrote:
> >> Can there be more than one fingerprint and more than one URI
> >> carried in the
> >> LIS-URI option?  I don't think the draft explicitly restricts the
> >> option.
> >> Because the URI does not include a length field, it would seem to
> >> limit the
> >> option to one URI, and the fingerprint MUST come before the URI.  I
> >> think
> >> the text should be explicit on this point.
> >>
> >> If I understand this restriction correctly, it may be possible to
> >> simplify
> >> the option syntax by assuming the order and number of fields in the
> >> option.
> >> I'll defer to dhc WG members for opinions on whether there might be
a
> >> modification to the syntax that would be more in line with existing
> >> options
> >> and implementations.
> >
> > I presumed the intent was to provide only one URI.
> >
> > I think that if you squint and turn your head sideways, the 'f-code,
> > f-length' looks like a suboption (except that the URI's f-code
implies
> > no length octet, evidently a format size optimization).
> >
> > I want to ask if the idea is to intentionally make a distinction
> > between 'f-code's and suboptions, such as in order to support
multiple
> > instances of one f-code (and not provoke option concatenation as
would
> > happen with multiple sub-option codes of the same value).
> >
> > If they can be suboptions, then why not multiple regular options?
> > I think the answer is that the certificate is useless without the
URI,
> > and vice versa, so if a DHCP server omitted one due to running out
of
> > space it is better to omit both.  Containering them together solves
> > this neatly.
> >
> >> The DHCPv6 option doesn't have the 253 byte length restriction.  It
> >> would
> >> be good to mention that difference between the two option versions.
> >
> > I was curious what you meant (253, not 255?), so went back to
re-read
> > the draft.  I don't see the number 253 mentioned, nor 255!
> >
> > It /does/ mention '225'.  This appears to be a typo?
> >
> > My only suggestion for the mention of the option size is to refer
> > specifically to the 'length field value', and not to terms like 'URI
> > length' or 'option length', which can be misinterpreted from
different
> > starting positions.
> >
> > Otherwise I like this approach of referring to the extension of
option
> > space as a DHCPv4 protocol feature, and not trying to reinvent its
> > specification.
> >
> > --
> > David W. Hankins	"If you don't do it right the first time,
> > Software Engineer		     you'll just have to do it again."
> > Internet Systems Consortium, Inc.		-- Jack T. Hankins
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: [phone]
fax: [phone]
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg