Re: [Geopriv] On civic extensions

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Wed Dec 01 2010 - 18:19:38 EST

While I consider it part of my life's mission to always do what you expect me to do, I don't expect to be recognized for doing it.

I did read the email, and didn't see where "tl;dr" was mentioned, whatever "tl" and "dr" mean.

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.

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.

Since we have mechanisms to pass two new CAtypes with the associated registries through DHCP, there is no problem there, and I think we have no disagreement (save the one or two registry issue).

LoST validation is also not in play - we understand how to do that with any of the proposals on the table.

I had the suggestion to have two generic parameters in the one or two CAtypes. You could weigh in on that.

I'm pretty lost, no pun intended, on why the service boundary is any issue at all. 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 t
 o me to work, and not be dependent on representation.

Brian

On Dec 1, 2010, at 4:52 PM, Thomson, Martin wrote:

> Thank you Brian for doing exactly what I predicted and de-railing the conversation onto registries again.
>
> If you didn't read the email, "tl;dr" is an acceptable response, I wont be offended.
>
> On 2010-12-02 at 00:07:49, Brian Rosen wrote:
>> My notion is that you have two registries, the existing one, and one
>> that only attempts to avoid duplication. With registries come two
>> things: a label and a number.
>>
>> The label is what you use with LoST. The number is what you use with
>> DHCP. If you are worried about running out of DHCP number space,
>> create one new number that has the label as it's first parameter.
>>
>> For the new namespace, LoST works already. Create one new DHCP option
>> with the namespace as the first parameter and the label (tag) as the
>> second.
>>
>> Brian
>>
>> On Nov 30, 2010, at 8:01 PM, Thomson, Martin wrote:
>>
>>> Robert asked a question about how the various extension scheme affect
>>> LoST service boundaries (as opposed to the validation we've already
>>> discussed). I think that this is another consideration we need to
>> deal
>>> with in designing a solution.
>>>
>>> Ultimately, questions of the effect of our decisions on other
>> protocols
>>> and users of the civic address format are the most important.
>>> Discussions on registries and associated concerns is - at this stage
>> -
>>> an wasteful distraction.
>>>
>>> Service boundary evaluation is a simple process that treats each
>> address
>>> label as opaque (see draft-thomson-ecrit-civic-boundary for a more
>>> thorough discussion). This would make things easy if there were only
>>> one possible way an extension could find its way into the system.
>>>
>>> Here are my collected thoughts on the real problem.
>>>
>>> --
>>>
>>> There are two formats that can be used to introduce an extension:
>> DHCP
>>> and XML.
>>>
>>> Those two entry points could lead to an increased number of
>>> representations for extensions.
>>>
>>> Most of the problems occur at the point where conversions occur
>> between
>>> formats. If an originator (LG) and ultimate recipient both
>> understand
>>> the extension, conversions between different formats are the only
>>> serious cause of problems.
>>>
>>> If all intermediaries understood all extensions, we have no problem.
>>> That's not a reasonable precondition though. We have to deal with
>>> certain intermediaries who are ignorant of extensions.
>>>
>>> An extension that finds its way into the system by way of DHCP (or
>>> DHCP-based formats) is going to appear as a new, unknown CAtype to
>>> recipients. This can be translated to an XML format in two ways:
>> when
>>> the translator understands the DHCP form and the equivalent XML form;
>>> and when the translator does not. We need to deal with both cases.
>>>
>>> An extension that finds its way into the system by way of an XML
>> format
>>> has a similar problem. The specific qualified name that identifies
>> the
>>> type of the extension can't be carried by DHCP. The same concerns
>> apply
>>> to this sort of conversion.
>>>
>>> Though a specific piece of location information might not need to
>> be
>>> converted to DHCP format, it's genesis in XML might ultimately
>>> dictate that DHCP clients be able to convey this to clients for it
>> to
>>> be represented in XML. The idea being that data is forced to go
>> XML
>>> -> DHCP -> XML and the goal is not to lose the extension.
>>>
>>> This leads to the following truth table for converting
>> intermediaries:
>>>
>>> | Intermediary | Intermediary
>>> | Understands | Ignorant
>>> ------------+--------------+--------------
>>> DHCP -> XML | A | B
>>> XML -> DHCP | C | D
>>>
>>> Note: Existing software is forced to discard extensions when
>>> translating in either direction. Thus, it's safe to ignore that in
>>> this analysis. I assume that software is compliant with whatever
>>> specification we produce.
>>>
>>> -local-civic allows for two expressions of the same data in either
>> basic
>>> format to deal with the problem cases "B" and "D". This does add two
>>> different representations of the same information in both XML and
>> DHCP;
>>> one representation for each of the four cases.
>>>
>>> This could cause a problem for LoST service boundaries (or any other
>>> application that uses civic addresses). If a particular extension
>> can
>>> be represented in different ways, the LoST server that relies on an
>>> extension for its boundaries has to produce 2^n different service
>>> boundaries if it wants to be understood (where 2 = the number of
>>> different representations for each extension, and n = the number of
>>> extensions).
>>>
>>> In practice, I expect that such reliance on extensions will be rare
>>> for LoST. This problem is rendered moot if the extensions are
>> safely
>>> ignored, but it's something we need to consider for the general
>> case.
>>>
>>> If we want to solve the problem of multiple representations - and we
>>> should really evaluate the impact if we do not - then we need to
>>> legislate to remove one of the options. Since we can do nothing to
>>> rectify the ignorance (or not) of translators, the only real option
>> is
>>> to restrict where extensions are defined.
>>>
>>> Removing the XML extension point would force all civic address
>>> extensions to acquire a CAtype from the registry. Extensions are
>> only
>>> ever natively defined as one octet CAtypes. To carry extensions in
>> XML,
>>> we'd define an element that can carry unknown CAtypes. <ext:EXT
>>> CAtype="192">Value</ext:EXT> as suggested in -local-civic would be
>>> a representative implementation of this option.
>>>
>>> Removing the DHCP extension point was actually something suggested in
>> a
>>> previous version of -local-civic. That got some fairly strong
>>> objections, but it should be tabled again. In this option extensions
>>> are natively defined in XML and we define a way to convey an XML-
>> based
>>> extension in DHCP. The two new CAtypes in -local-civic are
>>> representative implementations of this option.
>>>
>>> Thus we have the solution matrix:
>>>
>>> Extend DHCP?
>>> | Yes | No
>>> ------+-----------------+-----------------
>>> Extend Yes | -local-civic-03 | -local-civic-02
>>> XML? No | *C | *D
>>>
>>> *C is what (I think) Brian is advocating (Brian: correct me if I am
>>> wrong, I've heard you support this).
>>>
>>> I don't think that anyone is advocating *D, though it's effectively
>>> where we are at the moment.
>>>
>>> Keith is partly right about a do-over always being a final failsafe
>>> option: we do always have the option of a complete do-over. However,
>>> the main problem will just carry over into the new format if we don't
>>> resolve it. A do-over is just a decision we might make in the course
>> of
>>> implementing one of these four options.
>>>
>>> We should resolve this issue before we get into discussions on
>>> registration policies and so forth. Those discussions are wasteful
>> as
>>> long as we each have different fundamental solutions in mind. I hope
>>> that we can agree that each of these works with wild west, fcfs,
>> expert
>>> review or standards action with similar efficacy, though different
>>> levels of accessibility and interoperability.
>>>
>>> --Martin
>>>
>>> _______________________________________________
>>> 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
Received on Wed, 1 Dec 2010 18:19:38 -0500

This archive was generated by hypermail 2.1.8 : Wed Dec 01 2010 - 18:20:11 EST