Re: [grobj] Referral definition and its purpose?

[Sheng Jiang <[e-mail]>]

> -----Original Message-----
> From: Keith Moore [mailto:[e-mail]] 
> Sent: Wednesday, May 19, 2010 2:36 PM
> To: Sheng Jiang
> Cc: [e-mail]
> 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 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.
 
> 		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.
> 	
> 
> 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
 
> Keith
> 
> 
>