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

["Thomson, Martin" <[e-mail]>]

Yes, the reason for multiple fingerprints is to allow for multiple hash functions.

I can't see how your suggestion avoids the problem.  It looks no different to multiple suboptions to me.

What about:

<subopt (uri)><length><LIS uri>
<subopt (fp)><length><hash name length><hash name><hash length><hash>
<subopt (fp)><length><hash name length><hash name><hash length><hash>

Or:

<subopt (uri)><length><LIS uri>
<subopt (fp)><length><hash name><0><hash>
<subopt (fp)><length><hash name><0><hash>

Preferences?

The first seems to be the more common method for variable length data.  The second is a little more frugal.  However, the both run into a little size restriction problem...for v4, the URI cannot be longer than 255 characters.  That means that we'd have to allow for concatenation of that particular suboption.  URIs have this ugly tendency to get long quickly - the current solution transparently allows for that.

That means text along the lines of:

  This option MUST have at least one instance of the URI suboption.  Multiple instances of the URI suboption are permitted to allow for URIs longer than 255(v4)/65535(v6!) characters, the value of each is concatenated to determine the final value.  The option MAY have zero or more instances of the fingerprint suboption, each containing a fingerprint that is derived using a different hash function.

Does that work for you?  Or am I being unreasonable?

Cheers,
Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Bernie Volz (volz)
> Sent: Thursday, 29 January 2009 2:41 PM
> To: Thomson, Martin; Bud Millwood; [e-mail]
> Subject: Re: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-
> 05
> 
> So, perhaps best to have two options ...
> 
> One for the URI.
> 
> One for the fingerprints. The fingerprints option would be formatted
> something like:
>   <option><length><f-0-len><f-0-data>[<f-1-len><f-1-data>[...]]
> 
> The hash stuff (length and data) is either part of the f-<n>-data or is
> before <f-0-len>, I'm presume the reason to have multiple fingerprints
> would be to support different hashes.
> 
> This does mean a server could return a URI without a fingerprint (or
> vice versa), but the client would then ignore the single option (as it
> is meaningless).
> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Thomson, Martin
> Sent: Wednesday, January 28, 2009 10:21 PM
> To: Bernie Volz (volz); Bud Millwood; [e-mail]
> Subject: Re: [dhcwg] dhc WG review of
> draft-ietf-geopriv-lis-discovery-05
> 
> The intent is to have one (only) URI, and 0..n fingerprints.
> 
> I didn't choose suboptions originally because I didn't want to have to
> deal with the case that the client receives multiple URIs.  I really
> don't want to deal with the problem of working out which fingerprint
> goes with which URI.  If there is a feeling that this can be addressed
> by the judicious application of the "MUST"-hammer, then I'm more than
> happy to go with suboptions.
> 
> Cheers,
> Martin
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Bernie Volz (volz)
> > Sent: Thursday, 29 January 2009 2:02 PM
> > To: Bud Millwood; [e-mail]
> > Subject: Re: [dhcwg] dhc WG review of
> draft-ietf-geopriv-lis-discovery-
> > 05
> >
> > 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
> 
> -----------------------------------------------------------------------
> -
> ------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> -----------------------------------------------------------------------
> -
> ------------------------
> [mf2]
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg