Yes, I think that would cover all my issues.
Many thanks,
Adrian
----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Adrian Farrel" <Adrian.Farrel@huawei.com>; <iesg@ietf.org>
Cc: <geopriv@ietf.org>
Sent: Friday, February 19, 2010 2:24 AM
Subject: RE: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
> Hi Adrian,
>
> I had a discussion on this point some time back with our WG chair. He had
> exactly the same comment.
>
> This issue can be complicated. Using DDDS with DNS can produce multiple
> results. The means of discriminating between DDDS results is the same as
> for DNS. It just that this happens at a different layer. Note also that
> choices occur at multiple stages of the iterative process, not just the
> terminal stage.
>
> If multiple values are provided in DNS, load distribution seems to be the
> most common reason. Any algorithm that advocates "going around for
> another try" is only going to make this worse by having clients hit every
> server, especially for "notLocatable" responses.
>
> The good news is that a DDDS implementation should hide this complexity
> and produce only one answer. If you accept the above, altering DDDS
> resolver behaviour is probably unnecessary.
>
> My conclusion was that this sort of detail is more likely to do harm than
> good. Instead, relying on an understanding of U-NAPTR and DDDS would be
> preferable. I did prepare some text for this case, as follows:
>
>>>
>
> OLD:
> Diagram (step 3, N goes to step 1)
> NEW:
> Diagram (step 3, N goes to step 2)
>
> Section 4, between two paragraphs after the figure, ADD:
> U-NAPTR resolution might produce multiple results from each iteration of
> the algorithm. Order and preference values determine which value is
> chosen. A device MAY attempt to use alternative choices if the first
> choice is not successful. However, if a request to the resulting URI
> produces a HELD "notLocatable" response, or equivalent, the device SHOULD
> NOT attempt to use any alternative choices from the same domain name.
>
> <<
>
> Thanks for the text suggestion, that's much clear. I'll fix the nits.
>
> --Martin
>
>> -----Original Message-----
>> From: Adrian Farrel [mailto:adrian.farrel@huawei.com]
>> Sent: Friday, 19 February 2010 12:56 AM
>> To: iesg@ietf.org
>> Cc: geopriv-chairs@tools.ietf.org; draft-ietf-geopriv-lis-
>> discovery@tools.ietf.org
>> Subject: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
>>
>> Discuss:
>> A relatively small Discuss that I hope will cause you no trouble.
>>
>> It might be valuable to note that there could be more than one LIS
>> for any access network and that the device makes the choice based on
>> local policy.
>>
>> In particular, in step 2 of figure 1 the result may be more than one
>> URI. Or the "N" path from step 3 should return to step 2.
>>
>> Comment:
>> Section 2.2 begins
>>
>> A Device MUST avoid performing LIS discovery over a VPN network
>> interface unless discovery on other interfaces is unsuccessful. A
>> LIS discovered in this way is unlikely to have the information
>> necessary to determine an accurate location.
>>
>> I find this use of RFC 2119 a little vague. In trying to parse it, I
>> think I concluded...
>>
>> A device MUST NOT attempt LIS discovery over a VPN network interface
>> until it has attempted and failed to perform discovery on all other
>> non-VPN interfaces. A device MAY perform discovery over a VPN
>> network
>> interface if it has first attempted discovery on non-VPN interfaces,
>> but a LIS discovered in this way is unlikely to have the information
>> necessary to determine an accurate location.
>>
>> Note s/Device/device/
>>
>> ---
>>
>>
>> Nits:
>>
>> Section 1
>>
>> for providing that location information to devices with an access
>> network. The LIS uses knowledge of the access network and its
>>
>> This is hard to parse and it is only when we get to the definitions
>> later that we discover it means:
>>
>> for providing that location information to devices with attached
>> access networks used to provide Internetr access. The LIS uses
>> knowledge of the access network and its
>>
>>
>> ---
>>
>> Section 1.1
>> The bulk of DHCP information is largely static
>>
>> That looks like a double vagueness :-)
>> Either
>> The bulk of DHCP information is static
>> Or
>> The DHCP information is largely static
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
