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
