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

[Bud Millwood <[e-mail]>]

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