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

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

There is a significant difference because, as I said, repeating the same
sub option multiple times is not something that has been used to date.
And, it avoids the problem of multiple URIs because per RFC 3396,
multiple instances of the same option are CONCATENATED (RFC 3396 does
not apply to sub options). This also allows you to have potentially have
much longer URIs (>255 bytes).

<option (uri)><length><LIS uri>
<option (fp)><length><hash name 1 length><hash name 1><fingerprint 1
len><fingerprint 1>[<hash name 2 length>...]

Do not put 0's to terminate the hash name. You have a length, no need
for a null byte.

This gives you very long URIs, and you could have fingerprints that are
big too (they can't be more then 255).

Though of course, having options this long will likely cause issues
between clients and servers (and possibly IP fragmentation).

I'd use the same approach for v6. Unless you feel you need hash names or
fingerprints that are longer than 255 bytes, you can probably leave
these as byte fields.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Thomson, Martin
Sent: Wednesday, January 28, 2009 11:03 PM
To: Bernie Volz (volz); Bud Millwood; [e-mail]
Subject: Re: [dhcwg] dhc WG review of
draft-ietf-geopriv-lis-discovery-05

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
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg