Re: [grobj] BoF in coming IETF 78

Sheng Jiang <shengjiang@huawei.com> Mon, 21 June 2010 01:38 UTC

Return-Path: <shengjiang@huawei.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 E64CE3A69A5 for <grobj@core3.amsl.com>; Sun, 20 Jun 2010 18:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.105
X-Spam-Level: **
X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 0xsjrkzaLz8g for <grobj@core3.amsl.com>; Sun, 20 Jun 2010 18:38:13 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C7BDC3A697D for <grobj@ietf.org>; Sun, 20 Jun 2010 18:38:12 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4C00LMICJI2H@szxga01-in.huawei.com> for grobj@ietf.org; Mon, 21 Jun 2010 09:38:07 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4C005O3CJHIW@szxga01-in.huawei.com> for grobj@ietf.org; Mon, 21 Jun 2010 09:38:06 +0800 (CST)
Received: from j66104a ([10.110.98.171]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4C00CTGCJHZG@szxml06-in.huawei.com> for grobj@ietf.org; Mon, 21 Jun 2010 09:38:05 +0800 (CST)
Date: Mon, 21 Jun 2010 09:38:05 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <4BF13350.6050103@gmail.com>
To: grobj@ietf.org
Message-id: <001801cb10e2$6511cdb0$ab626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acr1urYFr8x8SC7kTtCbs3q5yxo1rgbJteLA
Subject: Re: [grobj] BoF in coming IETF 78
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: Mon, 21 Jun 2010 01:38:14 -0000

Hi,

For your information, our BoF request for coming IETF 78 did not approved by IESG. The major
concern was whether there was community consensus that the problem needed solving. However, the
application community appeared to have little interest in such a solution.

Althrough our BoF request was not approved, we are continuing our efforts. The PS is almost ready
to be submitted. We are willing to attract more contributors, both for this PS draft and future
relevant work.

Regards,

Sheng

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
> Sent: Monday, May 17, 2010 8:15 PM
> To: Sheng Jiang
> Cc: grobj@ietf.org
> Subject: Re: [grobj] BoF in coming IETF 78
> 
> Thanks Sheng. For everyone's information, I am taking a few 
> weeks unpaid leave so will not be as active on this list as I 
> would have wished.
> 
> We had some discussion back in January about different views 
> of the requirements, which was left unresolved. See January 
> 28 in the archive:
>  http://www.ietf.org/mail-archive/web/grobj/current/maillist.html
> To fix that, it seems very important to get some real 
> precision in the problem statement.
> 
> Med, you sent some comments on 
> draft-carpenter-grobj-reqts-00, maybe you can repeat for the 
> list the high-level comments that affect the problem statement aspect?
> 
> Regards
>    Brian Carpenter
> 
> 
> 
> 
> On 2010-05-17 19:15, Sheng Jiang wrote:
> 
> > Hi everybody,
> > 
> > We are now intenting to hold a BoF in the coming IETF 78, 
> Maastricht, 
> > Netherlands.
> > 
> > At IETF 76 Hiroshima, we had a BOF on Generic Referral 
> Objects, hosted 
> > by the Applications area. See 
> http://www.ietf.org/proceedings/76/grobj.html.
> > This BOF showed considerable interest sin the topic but no 
> coherence 
> > of opinion, so it seems that more systematic work is needed on the 
> > problem statement and requirements. Also, it seemed that 
> most of the 
> > interest and knowledge is actually in the Transport area 
> (for the same 
> > reasons that BEHAVE is in the Transport area).
> > 
> > So, after IETF 76, a problem statement and requirements draft is 
> > produced 
> (http://bgp.potaroo.net/ietf/html/ids/draft-carpenter-grobj-re
> qts-00.txt).
> > 
> > However, up to now, it is pretty clear that we need a very precise 
> > problem statement to act as the basis. We are working on an 
> individual 
> > PS draft, targeting to submit end of May. Comments on the problem 
> > statement aspect of draft-carpenter-grobj-reqts-00 would become the 
> > input for this individual PS draft. We are going to discuss 
> the referral issues in the mail list to.
> > 
> > The targeting refer WG is first chartered to analyse this 
> problem in 
> > detail and to establish consensus on the requirements for a 
> generic solution.
> > 
> > Best regards,
> > 
> > Sheng
> > 
> > Description of Referral Scenario:
> > 
> > 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. 
> Originally 
> > this could be achieved simply by passing the relevant IP 
> address from 
> > A to B, but today this is not possible in the general case, due to 
> > existence of disjoint addressing realms caused by NAT or by 
> IPv4-IPv6 
> > coexistence. In some cases, this problem may be readily solved by 
> > passing a Fully Qualified Domain Name (FQDN) instead of an 
> IP address. 
> > Indeed, that is an architecturally preferred solution 
> according to RFC 
> > 1958. However, it is not sufficient in many cases of dynamic 
> > referrals, for a variety of reasons.
> > 
> > _______________________________________________
> > grobj mailing list
> > grobj@ietf.org
> > https://www.ietf.org/mailman/listinfo/grobj
> >