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

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

Excuse me, I must been having another one of my "thick" moments.

As I understand, RFC 3396 concatenation occurs at a lower layer - a client that supports RFC 3396 can present arbitrarily large values to its users.  If there is indeed no established convention for concatenation of suboptions, then it might be reasonable to assume concatenation.  If you assume concatenation is the method for dealing with repeated sub-options, then your suggestion works for me.  Without that assumption, I missed what you were getting at.  (For my benefit, I'm not aware of a use of sub-options post 3396, is there no use of concatenation with any of these?)

As for size of the length fields within the fingerprint, I might be willing to go out on a limb and suggest that a >2040 bit hash is a little way off and stick with a single byte each.  Given that there are already 512 bit hashes, I think that I will play it safe and use the full 16 bits for v6.  At least with IPv4 it might have gone away by the time we care about really strong hashes, not that there isn't a workaround.

Ta,
Martin

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]]
> Sent: Thursday, 29 January 2009 3:30 PM
> To: Thomson, Martin; Bud Millwood; [e-mail]
> Subject: RE: [dhcwg] dhc WG review of draft-ietf-geopriv-lis-discovery-
> 05
> 
> 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

------------------------------------------------------------------------------------------------
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