Re: 2nd part Re: revision of architecture draft is now published

Hi Geoff,

sorry for being unclear,

El 07/07/2004, a las 0:20, Geoff Huston escribió:

> (still working through your comments...)
>
> - in section 5.3.3
>
>> when considering opportunistic identifiers to initiate the 
>> communication.
>> note that non of the proposals AFAIK, use opportunistic identifiers 
>> for the server side. imho this is very difficult, because, the client 
>> side needs to know the identifier in order to initiate the 
>> communication. It would be possible that the client side would select 
>> the servers identity beforehand, but this may imply collisions if the 
>> server is already using it. imho opportunistic ids are only suitable 
>> for clients (if any), but not for servers.
>
> Hi Marcelo,
>
> I'm unsure of what you are saying here. Could you describe in a bit 
> more detail the point so that I can understand what changes may be 
> necessary for the draft?
>

In section 5.3.3. it is stated that

    "If opportunistic identities are used, where the identity is not a
    fixed discoverable value but one that is generated in the context of
    a session then additional actions must be performed at session
    startup.  In this case there is still the need for defined locators
    that are used to establish a session, but then an additional step is
    required to generate session keys and exchange these values in order
    to support the identity equivalence of multiple locators within the
    ensuing session.  This may take the form of a capability exchange and
    an additional handshake and associated token value exchange within
    the transport protocol if an in-band approach is being used, or it
    may take the form of a distinct protocol exchange at the level of the
    identity protocol element, performed out-of-band from the transport
    session."

Now, i wonder how such a solution would be, in the case that both 
initiator and responder use ephemeral ids.

The case where the initiator uses ephemeral ids is clear to me, and 
wimp_v1 is a example of how this would work.

However, if the receiver wants to use an ephemeral id, things get less 
clear (at least to me)

In this case, the app at the initiator's end needs to use a stable 
identifier to indicate the end that it wants to communicate with.

It could be possible to say that the apps will try to communicate with 
a fqdn.
If this is the case, i guess that the resolver at the initiators end 
will have to negotiate with the receiver the ephemeral id that the 
receiver will use, so that the initiator's resolver can return the 
ephemeral id back to the app, so that the app can use it to initiate 
the communication. However, if this is the case, i would say that the 
fqdn is the identifier really being used for initial contact, perhaps 
in this scenario we are using two identifiers, the fqdn and the 
ephemeral one?

bottom line is that the receiver always needs a stable identifier that 
the initiator can refer to, if not the initiator won't be able to 
indicate the target of the communication.

regards, marcelo



> thanks,
>
>   Geoff
>
>
>