Subject: [grobj] Referral definition and its purpose?

From: Sheng Jiang <[email-masked]>
Date: Tue, 18 May 2010 17:01:27 +0800

Hi, all,

We are now working on an referral PS draft, targeting to submit end of May
or the beginning of June. We'd like to discuss the relevant contents/topic
publicly in the mail list during our writing. Comments or contributions are
more than welcome.

The first target is to understand what is referral and its purpose. There
may be different understanding, our goal here is to find a common definition
for our PS draft. The following is my understanding and what's in the draft
now.

In abstract: The purpose of a referral is to enable a given entity in a
multiparty Internet application to pass information to another party. It
enables a communication initiator to aware relevant information of its
destination entity before launching the communication.

In the introduction: A frequently occurring situation is that one entity A
connected to the Internet (or to some private network using the Internet
protocol suite) needs to inform another entity B how to reach either A
itself or some third-party entity C. This is known as a referral.

Does everyone can agree on this Referral definition and its purpose? Only if
consensus can reach here, our next discussion for referral scenarios can
make sense.

Best regards,

Sheng

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 May 2010 08:26:31 -0400

> consensus can reach here, our next discussion for referral scenarios can
I would define the scope as somewhat broader than that.  I think it's
quite reasonable to want to make referrals across application
boundaries.  If one application provides a service that's useful to
another application, I think it's reasonable to pass a referral object
from one application to another.    To say this another way, I think
that these days the boundary between one application and another is
rather arbitrary.

I also think that part of the purpose for standardizing referral objects
is to facilitate referrals between one application and another.  If all
referrals were within the same application, there would be less need to
standardize the object, as each application could develop its own.

Another purpose in standardizing referral objects is to allow
standardized APIs to manipulate referral objects and to allow those APIs
to be reusable across multiple applications. However IETF doesn't
usually standardize APIs.  So this by itself might be seen as a weak
justification in IETF circles.

Keith

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 19 May 2010 13:17:51 +0800

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]] 
> Sent: Tuesday, May 18, 2010 8:27 PM
> To: Sheng Jiang
> Cc: [email-masked]
> Subject: Re: [grobj] Referral definition and its purpose?
> 
> I would define the scope as somewhat broader than that.  I 
> think it's quite reasonable to want to make referrals across 
> application boundaries.  If one application provides a 
> service that's useful to another application, I think it's 
> reasonable to pass a referral object from one application to 
> another.    To say this another way, I think that these days 
> the boundary between one application and another is rather arbitrary.

Hi, Keith,

Fully agree. The approach we are discussing is application independent. So, natually, the solution
we may produce will have the ability to traverse application boundaries. My ideal model is the
referral will happen in transport layer to serve all applications.
 
> I also think that part of the purpose for standardizing 
> referral objects is to facilitate referrals between one 
> application and another.  If all referrals were within the 
> same application, there would be less need to standardize the 
> object, as each application could develop its own.

The same with above. We are going to standardize application independent referral, both referral
objects and referral behaviors. However, the WG, if we gets approved, only aims to understand the
referral problems and requirements. Only after we finish ps and requirements, if we find that
defining referral objects and referral behaviors is needed, we may recharter to work on it.
 
> standardized APIs to manipulate referral objects and to allow 
> those APIs to be reusable across multiple applications.

Abosolutely.

> However IETF doesn't usually standardize APIs.  So this by 
> itself might be seen as a weak justification in IETF circles.

We can find out only after we complete the study in new WG.

Cheers,

Sheng

---

From: Dong Zhang <[email-masked]>
Date: Wed, 19 May 2010 14:18:24 +0800

Hi,

>referral will happen in transport layer to serve all applications. 
Why not in IP layer? I mean using the extension header, such as destination options header.

Thanks.
------------------				 
Dong Zhang
2010-05-19

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 May 2010 02:35:30 -0400

> referral will happen in transport layer to serve all applications.
I don't understand how the referral belongs in the transport layer.  For
one thing, it might be used across different kinds of transport protocols.
> defining referral objects and referral behaviors is needed, we may recharter to work on it.
Ah, yes.  I've seen that formula in other charters.  I used it myself
once or twice when I was on IESG.   It's usually intended to keep a
working group from going off into the weeds.  What it usually
accomplishes, in reality, is prevent the working group from producing
useful output. 

The problem is that no matter how much or little is within the scope of
a working group, it generally takes about 18-24 months to reach FIN-WAIT
state.   People will always find something to argue about (it's just a
matter of how minute the details are).  They'll argue finer and finer
points until so many participants are exhausted that the few remaining
active participants reach consensus.   That generally takes about a year
and a half, unless the number of participants is very small.  At that
point, the group can be rechartered to widen its scope.  But by that
time, there's not much energy left to actually do a good job defining
the protocol.

The other thing is that IETF working groups are actually pretty lousy at
nailing down requirements.  They're often quite good at getting a shared
understanding of the problem space, and a shared vocabulary with which
to discuss the problem.  But when it comes down to actually setting
requirements, they fail, for at least two reasons.  One is that many of
the people contributing to the discussion have no idea of the cost
associated with any particular requirement.  Another is that some of the
participants try to use the requirements discussion as a proxy for the
actual protocol discussion - i.e. they insist on certain requirements
because those requirements, not because there are actually real
requirements there, but because those requirements have implications for
what the protocol looks like.  At best a lot of effort is wasted trying
to nail down requirements that really aren't needed at all; and at
worst, the protocol is so constrained by the dubious "requirements" that
it becomes much more complex (and generally less reliable/interoperable)
than it needs to be.

So I guess I'm pretty pessimistic about the likelihood of success of
this group if IESG constrains its charter in this way.  IMO it would be
far better to have an informal group develop an experimental protocol
and a reference implementation and document those.  Then if people find
it useful, it can be standardized later in light of actual experience.

Keith

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 19 May 2010 18:15:29 +0800

> Sent: Wednesday, May 19, 2010 2:36 PM
> To: Sheng Jiang
> Cc: [email-masked]
> 	Fully agree. The approach we are discussing is 
> application independent. So, natually, the solution
> 	we may produce will have the ability to traverse 
> application boundaries. My ideal model is the
> I don't understand how the referral belongs in the transport 
> layer.  For one thing, it might be used across different 
> kinds of transport protocols.

All right. I was assuming most of referral information is from IP layer, such as IP addresses,
hostnames, etc. So, it is beyond the IP layer. If you want to use referral across different kinds
of transport protocols, it is beyond transport layer. I am fine with it. I guess, we have shared
one common understanding here: a generic referral approach should be application independent.
 
> 	The same with above. We are going to standardize 
> application independent referral, both referral
> 	objects and referral behaviors. However, the WG, if we 
> gets approved, only aims to understand the
> 	referral problems and requirements. Only after we 
> finish ps and requirements, if we find that
> Ah, yes.  I've seen that formula in other charters.  I used 
> it myself once or twice when I was on IESG.   It's usually 
> intended to keep a working group from going off into the 
> weeds.  What it usually accomplishes, in reality, is prevent 
> the working group from producing useful output.  
> 
> The problem is that no matter how much or little is within 
> the scope of a working group, it generally takes about 18-24 
> months to reach FIN-WAIT state.   People will always find 
> something to argue about (it's just a matter of how minute 
> the details are).  They'll argue finer and finer points until 
> so many participants are exhausted that the few remaining 
> active participants reach consensus.   That generally takes 
> about a year and a half, unless the number of participants is 
> very small.  At that point, the group can be rechartered to 
> widen its scope.  But by that time, there's not much energy 
> left to actually do a good job defining the protocol.

I understand your worries here. However, the current situation we get is that many participants did
not understand referral scenarios and what referral can do. So we need to start from describe the
problems first. What we need here is enough motivation and well understanding to start the work.
Also there was to little discussion to help us to understand the problems and requirements
correctly. At this moment, I am not worrying too much argument at all.
 
> The other thing is that IETF working groups are actually 
> pretty lousy at nailing down requirements.  They're often 
> quite good at getting a shared understanding of the problem 
> space, and a shared vocabulary with which to discuss the 
> problem.  But when it comes down to actually setting 
> requirements, they fail, for at least two reasons.  One is 
> that many of the people contributing to the discussion have 
> no idea of the cost associated with any particular 
> requirement.  Another is that some of the participants try to 
> use the requirements discussion as a proxy for the actual 
> protocol discussion - i.e. they insist on certain 
> requirements because those requirements, not because there 
> are actually real requirements there, but because those 
> requirements have implications for what the protocol looks 
> like.  At best a lot of effort is wasted trying to nail down 
> requirements that really aren't needed at all; and at worst, 
> the protocol is so constrained by the dubious "requirements" 
> that it becomes much more complex (and generally less 
> reliable/interoperable) than it needs to be.

Again, at this moment, I am not worrying too much argument at all. The mail list was quite quiet
for a while. What I am worrying is we may not have enough energy to start the work.
 
> So I guess I'm pretty pessimistic about the likelihood of 
> success of this group if IESG constrains its charter in this 
> way.  IMO it would be far better to have an informal group 
> develop an experimental protocol and a reference 
> implementation and document those.  Then if people find it 
> useful, it can be standardized later in light of actual experience.

Personally, I don't against this appoarch. But from our early discussion, many pariticipants did
not understand referral scenarios. It seems clear that we need a very precise problem statement to
act as the basis

Cheers,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 19 May 2010 18:17:39 +0800

> >Fully agree. The approach we are discussing is application 
> independent. 
> >So, natually, the solution we may produce will have the ability to 
> >traverse application boundaries. My ideal model is the 

As the same answer in another thread, many referral information is from IP layer, such as IP
addresses, hostnames, etc. The referral information may carried as IP payload. So, it is beyond the
IP layer. 

Cheers,

Sheng

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 May 2010 19:23:40 +1200

Two or three general comments on this discussion:

1. I think it's too soon to discuss which layer the
referral takes place at. In fact, in the general case,
we don't know - what we do know is that a network layer
referral *will* fail in many cases. If that wasn't true,
we would just be able to pass IP addresses around, like
we did in 1990. So the problem statement needs to talk about
layer (in)dependence as part of the problem. A related issue
is the problem of fragmented scope, which is an acute problem
at the network layer.

2. It's also too soon to discuss whether the solution
direction is a referral object, as I originally suggested,
or a generalised equivalent of ICE, which Simon suggested.
That's the main reason we need to start with a problem
definition IMHO.

3. As for whether the charter should immediately include
specifying a solution as well as the problem and requirements,
this really depends on how well the next BOF works out
and how the prospective AD wants to handle it. I think we
should keep an open mind on that for now.

    Brian

On 2010-05-19 22:17, Sheng Jiang wrote:
> _______________________________________________
> grobj mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grobj
>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 21 May 2010 08:55:56 +0800

Yes, we are too early to make decisions or recommendations. That's why we start the discussion from
very basic conception and try to reach common understanding on the basic issues

Currently, the charter is only a start point. We start from PS and requirement discussion. Whether
we set milestones for followups will depend on BoF participants and AD's instruction. What we can
do now is to discuss the scenarios and issues, then try to make a PS as mature as we can.

Cheers,

Sheng

> 1. I think it's too soon to discuss which layer the referral 
> takes place at. In fact, in the general case, we don't know - 
> what we do know is that a network layer referral *will* fail 
> in many cases. If that wasn't true, we would just be able to 
> pass IP addresses around, like we did in 1990. So the problem 
> statement needs to talk about layer (in)dependence as part of 
> the problem. A related issue is the problem of fragmented 
> scope, which is an acute problem at the network layer.
> 
> direction is a referral object, as I originally suggested, or 
> a generalised equivalent of ICE, which Simon suggested.
> specifying a solution as well as the problem and 
> requirements, this really depends on how well the next BOF 
> works out and how the prospective AD wants to handle it. I 
> think we should keep an open mind on that for now.
> 
>     Brian
> 
> 
> > As the same answer in another thread, many referral information is 
> > from IP layer, such as IP addresses, hostnames, etc. The referral 
> > information may carried as IP payload. So, it is beyond the 
> IP layer.
> > 
> > Cheers,
> > 
> > Sheng
> >  
> >> Thanks.
> >> ------------------				 
> >> Dong Zhang
> >> 2010-05-19
> >>
> >

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 26 May 2010 17:21:01 -0700

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Sheng Jiang
> Sent: Tuesday, May 18, 2010 2:01 AM
> To: [email-masked]
> Subject: [grobj] Referral definition and its purpose?
> 
> Hi, all,
> 
> consensus can reach here, our next discussion for referral 
> scenarios can make sense.

The definition of referral should be tightened up slightly
that the parties are exchanging the information via one
channel (e.g., SIP signaling) but want to communicate (as)
directly (as possible) with each other *not* using that 
channel.  I often get asked "if they can communicate referral
information with each other, why don't they just use that
communication channel for everything else?".

In SIP, this is often called the "SIP trapezoid".
We can generalize this a bit resulting in the following
figure:

   +-----------+       +-----------+
   |application|       |application|
   | server(s) +.......+ server(s )|
   +---+-------+       +-------+---+   
      /                         \       
     |                           |
     |   referral information    |
     |                           |
     |                           |
   +-+-+                       +-+-+  
   | A +-----------------------+ B |
   +---+ direct communication  +---+

The application server(s) might be one single server, a distributed hash
table, two servers, or any sort of combination.  The referral data is carried
on bewtween A and B on the top, through those servers.  A and B are trying to
communicate directly with one another, using the communication line at the
bottom.

A simplier model which is good to think about is a simple protocol which
collapses the model above, such as FTP.  FTP follows the same model as above,
except the 'application server' is the FTP server and FTP control channel
(TCP/21) is what carries the referral (PASV, EPSV, PORT, EPRT).  TFTP is
another example of a collapsed model.

   +-+-+                            +-+-+  
   |   |   FTP control connection   |   |
   |   |   (referral information)   |   |
   |   +............................+   |
   |   |                            |   |
   | A |                            | B |
   |   |    FTP data connection     |   |
   |   +----------------------------+   |
   |   |                            |   |
   +---+                            +---+

-d

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 May 2010 00:22:44 -0400

> channel. 
that's certainly one case.  another case is when parties A and B
exchange information about how either A or B can contact one or more
other parties.

also, the referred-to path doesn't have to be more direct than the path
over which the referral is taking place.  say, for instance, the initial
exchange between A and B is taking place using an ephemeral address for
B.  B might like to inform A of a more stable and/or more reachable
address for itself, so that in the future A could contact B at the
"better" address.  however the more stable/reachable address for B might
conceivably even be via some sort of tunnel (e.g. mobileIP).

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 26 May 2010 21:31:33 -0700

> Sent: Wednesday, May 26, 2010 9:23 PM
> To: Dan Wing
> Cc: 'Sheng Jiang'; [email-masked]
> that's certainly one case.  another case is when parties A 
> and B exchange information about how either A or B can 
> contact one or more other parties.

Two party case is easier to understand and conceptualize.
This covers a *huge* number of important cases.

Then, in a later section number of the same document, we
can explain 3 party case.

> also, the referred-to path doesn't have to be more direct 
> than the path over which the referral is taking place. 

Sure.

But my point is that it is a *different* path than the
signaling path.   I agree the path could be longer and 
could go around the moon - twice.

Do you have a better way to represent that in ASCII that
gets the point across?  Picture worth a thousand words
and all..

-d

> say, 
> for instance, the initial exchange between A and B is taking 
> place using an ephemeral address for B.  B might like to 
> inform A of a more stable and/or more reachable address for 
> itself, so that in the future A could contact B at the 
> "better" address.  however the more stable/reachable address 
> for B might conceivably even be via some sort of tunnel (e.g. 
> mobileIP).
> 
> Keith
> 
> 
> 
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 May 2010 00:49:47 -0400

> This covers a *huge* number of important cases.
agree.
> can explain 3 party case.
I think I'd rather have the various examples together in the document,
but I won't try to nail down the document outline just yet.
> could go around the moon - twice.
it's _probably_ a different path because if it were the same path,
there'd be little need for the referral.  just reuse the same source
address, destination address, destination port as seen by the initiator
of the connection (though that might not work if the new connection
needed to be initiated by the receiver of the original connection).

but to be general, it shouldn't _have_ to be a different path.  it
should be possible to use a referral that specifies the same path used
by the connection used to send the referral.   (or to put it another
way, do you really want the API to say "sorry, you can't use this
referral because you received it over the very path that it specifies?")

here's an example: over path P1, A sends to B a referral that specifies
three paths by which A can be reached: P1, P2, and P3.  when B tries to
reconnect to A, its circumstances are such that P1 appears to be the
best of the three paths.  I don't know why B shouldn't use P1.
> gets the point across?  Picture worth a thousand words
I thought your picture was okay for the case you were describing, but I
probably didn't look at it too closely as this is all familiar to me
already.

Keith

---

From: bo zhou <[email-masked]>
Date: Thu, 27 May 2010 15:29:44 +0800

Sorry to jump in discussion.

On Thu, May 27, 2010 at 12:49 PM, Keith Moore <[email-masked]>wrote:

> I think I'd rather have the various examples together in the document, but
> I won't try to nail down the document outline just yet.
>
> it's _probably_ a different path because if it were the same path, there'd
> be little need for the referral.  just reuse the same source address,
> destination address, destination port as seen by the initiator of the
> connection (though that might not work if the new connection needed to be
> initiated by the receiver of the original connection).
>
> but to be general, it shouldn't _have_ to be a different path.  it should
> be possible to use a referral that specifies the same path used by the
> connection used to send the referral.   (or to put it another way, do you
> really want the API to say "sorry, you can't use this referral because you
> received it over the very path that it specifies?")
>
> reconnect to A, its circumstances are such that P1 appears to be the best of
> the three paths.  I don't know why B shouldn't use P1.
>

[bo] I am not sure why B will use P1 to connect to A, because it is hard for
B to understand which path is the best. A send B a referral over P1 is
bacause only P1 is known at the beginning of communication. A can tell B
there are three paths, but cannot tell B which one is the best.
And in the real world, could you give me an example why A will give B three
path. For my knowledge, A always tells B only one path. Or you want to say
the communication between A and B support MIF scenario?

-- 
Regards,

Bo Zhou
China Mobile

---

From: bo zhou <[email-masked]>
Date: Thu, 27 May 2010 15:39:59 +0800

Hi Dan,

Some comments inline.

> communication channel for everything else?".
[bo]The path which they communicate referral information maybe not the
"best" path for the information they really want to communicate. Many
today's peer-to-peer applications are working like this way, one reason
could be avoiding monitor from operator or others and protect privacy.

-- 
Regards,

Bo Zhou
China Mobile

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 27 May 2010 17:23:03 +0800

> directly (as possible) with each other *not* using that

Dan,

Your description is a subset of my definition of referral. At this very 
beginning, I do not want limit us that narrow.

You have described a specific way how referral information may be 
transferred - through an existing channel between two parties. 
Obviously, there are many ways to pass the referral information. I am 
not sure we are in the stage to discuss it in details now.

If your motivation here is to simplify my three-party decription into 
two-party model for easy understanding, I can agree. But I still prefer 
to leave the referral information transfer mechanism out of the referral 
basic definition.

Try the below description:

Referral enables a communication initiator to aware relevant information 
of its destination entity in order to launch a communication channel. 
This referral information can be obtained through existing communication 
channel between these two entities or from thrid-party entities.

Cheers,

Sheng

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 May 2010 06:48:30 -0400

On 5/27/10 3:29 AM, bo zhou wrote:
>
>
>     here's an example: over path P1, A sends to B a referral that
>     specifies three paths by which A can be reached: P1, P2, and P3. 
>     when B tries to reconnect to A, its circumstances are such that P1
>     appears to be the best of the three paths.  I don't know why B
>     shouldn't use P1.
>
>  
> [bo] I am not sure why B will use P1 to connect to A, because it is
> hard for B to understand which path is the best. A send B a referral
> over P1 is bacause only P1 is known at the beginning of
> communication. A can tell B there are three paths, but cannot tell B
> which one is the best.
It is indeed difficult for B to know which path is best.  And in many
cases "best" depends on the specific needs of the application.   One
application might need maximum bandwidth, another low delay, another
might prefer a stable address.  An IPv4 only host would want to use an
IPv4 address for its peer.  etc.

Last I knew there was a current IETF WG looking at a similar problem -
though its name escapes me at the moment and I haven't been following
their work.

But just for the sake of discussion, suppose that B tries each path and
picks the one that seems to work best.  Or suppose that it tries each
path in turn, in a random order, and sticks with one that seems to work
adequately.  There are other strategies that make sense in certain
situations; e.g. a file transfer program might use all paths and adjust
the amount of data transferred over each according to the measured
available bandwidth.
> And in the real world, could you give me an example why A will give B
> three path. For my knowledge, A always tells B only one path. Or you
> want to say the communication between A and B support MIF scenario?
If A has three IP addresses, it would presumably supply multiple
addresses in a referral.  There are many reasons why A might have
multiple IP addresses:

    * multiple network interfaces;
    * mobile IP;
    * A supports both IPv4 and IPv6;
    * there are multiple IPv6 prefixes advertised on one or more of the
      networks to which A attaches;
    * A is behind a NAT and thus have both an "external" and an
      "internal" address (and A won't know which will work better for
      its peers);
    * A has arranged to have "remote" IPv4 or IPv6 access via a tunnel
      to another network (which makes a very flexible transition strategy)

Note also that an _application_ can have multiple addresses because it
exists on multiple hosts.  So we don't necessarily want to think of
referrals as being tied to hosts, but rather, to applications or services.

Keith

---

From: Scott Brim <[email-masked]>
Date: Thu, 27 May 2010 09:02:30 -0400

> could go around the moon - twice.

I've been trying to figure out why.  At the IP layer it does not
necessarily _have_ to be a different path.

The term from transport is "path-decoupled signaling".  It's not that
the control packets take a different path, but that they _might_ and
that you don't know if they do or not.  I think it's wrong to assert
that it is a different path.

Keith is right that it could be the same path but the referring entity
doesn't know whether it will end up the same or not.  

Scott

---

From: Scott Brim <[email-masked]>
Date: Thu, 27 May 2010 09:07:00 -0400

> though its name escapes me at the moment and I haven't been following

IETF/IRTF work that I can think of that is relevant: NSIS, EME
research group, the MPLS one about using management entities to set up
LSPs, Shim6, MPTCP, LISP.  I'm sure there are more.  But those are all
about mechanisms for determining good paths.  GROBJ is about how to
represent referrals.  GROBJ shouldn't concern itself with how paths
are chosen, just with how to represent those results.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 27 May 2010 22:04:41 +0800

> are chosen, just with how to represent those results.

Oops... We are not discussing GROBJ anymore though we are still use 
grobj mail list. The new BoF we proposed for next IETF is Refer BoF. The 
current charter is to study the problem of referral and the 
correspondent requirements. (We may move to a nre refer mail list later 
if needed.)

The reason is when we had GROBJ BoF back in Horishima, we found out 
people, even ourselves, did not understand the referral scenarios deep 
enough. So, we took a step back to study the referral problems. After 
that, we may continue to define referral transfer mechanisms/protocols, 
and the format of referral information. By that time, we may choose 
GROBJ appoarch. But at this stage, we don't want and should not discuss 
Grobj as we have made choice.

I would like to draw our discussion back to referral definition, 
scenarios and how it can help.

Regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 27 May 2010 22:52:07 +0800

于 2010/5/27 18:48, Keith Moore 写道:
>> over P1 is bacause only P1 is known at the beginning of communication.
>> A can tell B there are three paths, but cannot tell B which one is the
>> best.
> might prefer a stable address.

I believe this is an information provisioning issue. If somehow, B has 
been provided enough information of A, it can make a right decision on 
its own behave.

There is no single standard what is best. One path may be fast, but 
expensive; while another is slow, but free. Which is the best depends on 
individual request.

There was discussion before how much information should be included in 
GROBJ. Some said minimum and necessary information with no clear 
definition what is necessary. Some other said put whatever may useful 
information (ALL) into GROBJ. Then it is a lot overhead and expensive, 
also maybe create many waste. This is still an open issue.

Cheers,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 27 May 2010 22:56:27 +0800

> doesn't know whether it will end up the same or not.

+1. The referral information received though an existing path may 
indicate the communication pair this is the best path out of many. Then 
it ends up remaining the same path. It is possible and reasonable.

Sheng

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 May 2010 03:53:12 +1200

On 2010-05-27 19:29, bo zhou wrote:
...
> the communication between A and B support MIF scenario?

The application entity may not know or care whether there is one or
multiple interfaces, so we certainly must not exclude MIF scenarios.
However, choice of interface, like choice of address, is something
that happens after the referral has been sent.

    Brian