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
- [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Keith Moore
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Dong Zhang
- Re: [grobj] Referral definition and its purpose? Keith Moore
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Brian E Carpenter
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Dan Wing
- Re: [grobj] Referral definition and its purpose? Keith Moore
- Re: [grobj] Referral definition and its purpose? Dan Wing
- Re: [grobj] Referral definition and its purpose? Keith Moore
- Re: [grobj] Referral definition and its purpose? bo zhou
- Re: [grobj] Referral definition and its purpose? bo zhou
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Keith Moore
- Re: [grobj] Referral definition and its purpose? Scott Brim
- Re: [grobj] Referral definition and its purpose? Scott Brim
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Sheng Jiang
- Re: [grobj] Referral definition and its purpose? Brian E Carpenter