Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

[Suresh Krishnan <suresh.krishnan at ericsson.com>]

Hi Vidya,

(Cc:ing Julien as well)

Narayanan, Vidya wrote:
> All,
> I'm passing along a comment from one of our developers.  Sorry, I have
> not closely read the draft myself. But, if more clarification is needed,
> I'll be happy to get more information.  
>
> In section 13, the draft describes a procedure applications should
> follow in case they require to use the address according to the
> selection preferences specified (they should not communicate with
> 'wrong' address and fail). The procedure requires the application to do
> a 'connect()' in step 3. The application may not even want to connect
> (may be a TCP application) in case it is not getting a non-preferred
> address. There should be a procedure described for such applications
> too.

From what I understood from the draft, the API is used for specifying 
only preferences and not hard requirements. This text from Section 1 of 
the draft explains the reasoning.

   Specifying hard requirements for address selection
   would be problematic for several reasons.  The major
   one is that in the vast majority of cases the
   application would like to be able to communicate
   even if an address with the 'optimal' attributes is
   not available.

The authors can correct me, but I personally don't see how it is 
possible to check this deterministically without actually using 
connect() or sendto(). For argument's sake let's assume such a solution 
exists and the application verifies that a preferred address exists. 
What is to say this preferred address will not vanish before it is 
actually used (connect or sendto)?

Cheers
Suresh


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf