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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]