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

[Ralph Droms <[e-mail]>]

David - if, indeed, the idea is for one URI, with an optional  
fingerprint, would the following format be sensible and simpler to  
parse?

     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