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