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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Thomson, Martin
Sent: Wednesday, January 28, 2009 10:21 PM
To: Bernie Volz (volz); Bud Millwood; dhcwg@ietf.org
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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
> Of Bernie Volz (volz)
> Sent: Thursday, 29 January 2009 2:02 PM
> To: Bud Millwood; dhcwg@ietf.org
> 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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
> Of Bud Millwood
> Sent: Wednesday, January 28, 2009 3:52 AM
> To: dhcwg@ietf.org
> 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
> > > dhcwg@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dhcwg
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> 
> --
> Bud Millwood
> Weird Solutions, Inc.
> http://www.weird-solutions.com
> tel: +46 8 758 3700
> fax: +46 8 758 3687
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> 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
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg