Re: draft remarks

Eliot Lear <[email protected]>
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>

Kurt Erik Lindqvist wrote:
> While I agree that a must would imply that the document have some form 
> or requirements status, referrals are of such a strong demand from 
> applications that I think this needs to be addressed one way or the 
> other. But at the interim meeting we already said that we would try and 
> cover applications requirements in some way. So I agree with Iljitsch 
> but I do think that the question should be in the document. Perhaps we 
> could also come up with some more sub-questions for this point for 
> helping describing exactly how referrals would work.

Right.  What I was aiming for was something along these lines:

Referrals

    How will your solution handle referrals, such as those within FTP or
    various conferencing or other peer to peer systems?

    Referrals exist within various other protocols, such as so-called
    "peer to peer" applications.  Note that referrals might suffer three
    types of failure:
       firewall and NAT - just as FTP active mode experiences today with
       relatively simple firewalls?
       time-based - is there something ephemeral about the nature of the
       solution that might cause a referral (such as a URL) to fail over
       time, more so than what we have today?
       location-based - if the binding varies based on where the parties
       are in the network, if one moves will they no longer be able to
       find one another?

And the following:

What application/API changes are needed?

    Will old code just work with the new mechanism? For instance, what
    about code that uses gethostbyname()?

    Will getaddrinfo() need to change?

    What about other API calls?

    There are several possible approaches.  For instance, a multihoming
    service could attempt to require no changes to the API, in which case
    it is possible that IP addresses might become opaque blobs that work
    with the API, but might break operational assumptions at the
    application layers.  Consider the case of a web server that wants to
    log IP addresses.  How will it accomplish this task?

    One useful exercise would be to provide code fragments that
    demonstrate any API changes.

Eliot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.