In response to the other bits of this response...
On 2010-12-02 at 10:19:38, Brian Rosen wrote:
> I think we're very close to agreement. We have an open issue on how to
> represent the namespace in DHCP for a local extension, and we have two
> proposals: two DHCP options or one.
See my other response, and my explanation below for why I think we're not actually making progress.
> If you are okay with the second registry, with it's accompanying CAtype
> and DHCP option, then we should be able to close the one or two DHCP
> options issues with a couple of other people expressing their opinions;
> I certainly don't feel very strongly about that, since the result is
> the same: any local extension can be passed through DHCP.
I don't want to talk about one registry or two. That's like discussing what colour to paint the baby's room before you've made the fundamental procreation decision.
> LoST validation is also not in play - we understand how to do that with
> any of the proposals on the table.
At least we agree on that. There might be hacks, but that's OK.
> I had the suggestion to have two generic parameters in the one or two
> CAtypes. You could weigh in on that.
I think that it's a terrible idea. But then, I don't know what a generic parameter is or what it gains me, so I could be convinced otherwise. What semantics did you want to attach to these parameters?
> I'm pretty lost, no pun intended, on why the service boundary is any
> issue at all.
This is the fundamental technical issue in question. This is not about the LIS or DHCP server and the LoST server having a conversation in full awareness of all the extensions, it's about what the guy in the middle does with those extensions.
If an extension only ever has a single representation, then there is no problem. However, imagine that you define a CAtype (192) and a corresponding XML element <pfx:STP>. A generic client that gets the CAtype translates that to an extension element in XML: <ext:EXT CAtype="192">; and a client that knows about the extension produces <pfx:STP>.
That's two different representations for the same logical element. A service boundary needs to identify _either_ form in order to guarantee that a client can match their address to the boundary. Add multiple extensions and you have an exponential problem.
Now, in LoST at least the server can tailor responses based on what elements it sees (maybe), so that a client that produces one form gets service boundaries in the same form. If a client produces <pfx:STP>, then that's what is in the boundary. However, LoST has the advantage of seeing the client's location first. And that all assumes that the client is the one doing the conversion - if it's getting the extension from another entity, that entity could change and start producing the other form.
Other uses of addresses don't necessarily have that luxury. We can decide that we don't care about that, but that decision needs to be made in full cognizance of the consequences.
> There are 3 entities, and some can either pass data
> without understanding it, or drop it. If the LoST server gets some LI
> it doesn't understand, it ignores it, which means it doesn't appear in
> a service boundary. If the LoST client got LI elements it didn't
> understand, and passes them through to LoST, it may get that element
> back in the service boundary if the LoST server does understand the
> extension. If the server sends something back, it would have to be the
> value it got sent in. Take bridge: if getting off the bridge is out of
> the service area, then bridge id is part of the service boundary -- the
> client can compare the bridge id it gets from a location update even if
> it doesn't know anything about bridge and requery LoST if it changed.
> If bridge ID is not part of the service boundary, it's not in the
> return and the LoST client won't miss it. I am missing the problem.
> It appears to me to work, and not be dependent on representation.
>
> Brian
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
