> > Martin - you have stated you have a problem with an ID, it's on you
> > to offer an alternative -- preferably in the form of text that can be
> > pasted into the ID. It's been this way in the IETF for more than a
> > decade. Please... ask Brian, as I know you don't/won't believe me.
>
>I'm not interested in getting into arguments of that nature.
>
>If you want suggested text, here's some:
>
> This location URI operates under the "authorization by
> possession" model, described in [lbyr-requirements].
lbyr-reqjuirements is rooted from a HELD ID, I believe. HELD has the
concept of identity and of TLS to protect that HTTP based protocol in
transit. DHCP has no such protection, therefore possession of a
location URI shouldn't grant access to a DHCP client's location
without a challenge from the requested resource/entity. I don't
believe a possession model works when there is no change of secure
communication to a Target.
>That's my preference, and I've not seen good arguments that support
>your selected model.
>
> > >Why wait until WGLC? I have concerns now, but I've not had them
> > >addressed to my satisfaction.
> >
> > then you bring them to the other WG, if you feel so strongly. No one
> > is holding you back.
>
>There's nothing stopping you from addressing my concerns, either.
I am addressing them, at least for the valid ones.
But you're right, this isn't just about you and me. The trick is, I'm
not hearing from the rest of that WG that supports your points. I
might hear from 1 other person, but the two of you do not represent
the WG either (I've heard from a few that support the way it is). It
takes more than 2 to reach consensus of a WG. Surely that's obvious
to all concerned. Right now, there is no consensus this WG document
needs to change, and it shouldn't until such consensus is reached.
> > >RAIO can't provide a DHCP server with information about the current
> > >point of attachment of a Device when a URI is dereferenced.
> >
> > nor can it ever, that's why it becomes the burden of the client to
> > request for a fresh location URI whenever its attachment changes, or
> > the device power cycles.
> >
> > >It only provides information when the Device makes a DHCP
> > >request. Thus, making it mandatory is largely pointless for this
> > scenario.
> >
> > in the above sentence, what is "it" referring to (the device, the
> > server, the location URI or the RAIO)?
>
>It == RAIO
thanks for clarifying
Here's an issue with HELD too, it's only valid if the Target doesn't
move since it last requested location; else, the location is
invalid/stale. There is no difference with DHCP (by value or with a
locaition URI).
> > >It might be helpful, but since we're making location determination
> > >out of scope, it's not really necessary to describe these sorts of
> > details.
> >
> > same question as above -- in fact, it seems you have "it" in the
> > above sentence describing two different things, which I can't make out.
>
> > Directly quoted from Section 3.:
> >
> > "It is RECOMMENDED to avoid building URIs, with any parameters,
> > larger than what a single DHCP response can be. However, if a
> > message is larger than 255 bytes, concatenation is allowed, per RFC
> > 3396 [RFC3396]."
> >
> > >It would be nice if the draft said this directly.
> >
> > hmmm .... guess it does after all... ;-)
>
>That's not what I'm talking about. I'm talking about a statement like:
>
> 'A URI included in this option is constrained to 255 octets in length.'
without the exception - which I quoted - it is constrained to
255. Perhaps I can either say something like:
Location URIs are normally or RECOMMENDED to be less than
255, to comply with existing DHCP practices. Exceptions can be met by
following RFC 3396."
> > So, in Section 1, there's this text about the LS and the Rule Holder:
> >
> > "A Location Server (LS) stores the Target's location as a presence
> > document, called a Presence Information Date Format - Location
> > Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location
> > Server
> > is the entity contacted during the act of dereferencing a Target's
> > location. If the dereferencing entity has permission, defined in
> > [ID-GEO-POL], the location of the target will be received. The LS
> > will grant permission to location inquires based on the rules
> > established by a Rule Holder [RFC3693]. The LS has the ability to
> > challenge any request for a target's location, thereby providing
> > additive security properties before location revelation. "
> >
> > You're saying that the Rule Holder doesn't "establish" the rules, but
> > contains the rules, right?
>
>Right.
ok
> > If I did a s/establish/contained
>
>I think that it would be more helpful to use Rule Maker than Rule
>Holder. I personally don't find Rule Holding to be especially
>relevant to the discussion. It's a necessary function, with real
>security and privacy considerations, but it's a passive rather than
>active role.
The Rule Holder is who is asked for the location, or for the
policy(ies) for location distribution by Location Servers (per RFC
3693 - which the -arch- isn't obsoleting BTW. Therefore I'm going to
have to think a little more about how to use the terms in a consistent way.
James
>...
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
