> 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].
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.
> >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
> >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.'
> 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.
> 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.
...
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
