Re: [grobj] Referral definition and its purpose?

Keith Moore <moore@network-heretics.com> Wed, 19 May 2010 06:35 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: grobj@core3.amsl.com
Delivered-To: grobj@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30613A6B0E for <grobj@core3.amsl.com>; Tue, 18 May 2010 23:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3VWmOe3DjiE for <grobj@core3.amsl.com>; Tue, 18 May 2010 23:35:47 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id F05093A6ADB for <grobj@ietf.org>; Tue, 18 May 2010 23:35:45 -0700 (PDT)
Received: from lust.indecency.org (108-117-97-230.pools.spcsdns.net [108.117.97.230] (may be forged)) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id BST70199 (AUTH admin@network-heretics.com); Tue, 18 May 2010 23:35:31 -0700
X-Mirapoint-Received-SPF: 108.117.97.230 lust.indecency.org <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.117.97.230 lust.indecency.org <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.117.97.230 lust.indecency.org <moore@network-heretics.com> 5 none
Message-ID: <4BF386B2.80007@network-heretics.com>
Date: Wed, 19 May 2010 02:35:30 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Sheng Jiang <shengjiang@huawei.com>
References: <004f01caf712$a0defa00$730c6f0a@china.huawei.com>
In-Reply-To: <004f01caf712$a0defa00$730c6f0a@china.huawei.com>
Content-Type: multipart/alternative; boundary="------------070307030100040800030509"
Cc: grobj@ietf.org
Subject: Re: [grobj] Referral definition and its purpose?
X-BeenThere: grobj@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss Generic Referral Objects <grobj.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grobj>
List-Post: <mailto:grobj@ietf.org>
List-Help: <mailto:grobj-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 06:35:48 -0000

>>
>> 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.
>> 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.

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