From brian.e.carpenter@gmail.com Tue Dec 8 17:49:04 2009 Return-Path: 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 B8C973A6A8A for ; Tue, 8 Dec 2009 17:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 6uYX+CvSQoad for ; Tue, 8 Dec 2009 17:49:04 -0800 (PST) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id 12B9F3A6A51 for ; Tue, 8 Dec 2009 17:49:01 -0800 (PST) Received: by pxi7 with SMTP id 7so402719pxi.31 for ; Tue, 08 Dec 2009 17:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=17Tq9lKf4UBej6ppCaD5ntPChKRnraCGV1zOdLRydc0=; b=qsSxCwcvZcw9Vwpa+QYH2XaIdHWhq+HvIrq4fZQ8FLVl2fEVoRuBSb27EwvxP4+7Fo urXrlSgPWPiJvXU65UfBHyTXsB7FO9+XYVC1rdDp+x6dUsT1uDubjLRNHapz689mDBZJ NtLvOwVSpVc0FPm10yEbxoHGtWWhbMbGi7hlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=rsTEMbft6yNf0HW17aShzZRz3iBBpmHHJKaTHVno1z/TxTggHvNtoLYTgSoNIMdXDR Kj1q1nq+GuZRkNwDSYCn3E0JLwTIE97+ibT8NG5hkm9t2vaTEWHkUZkoGv+XRxRslnuN zYj6hRGUvNLWPOKOjCORlAJ4Vc14iFxz8nws8= Received: by 10.114.23.4 with SMTP id 4mr17160753waw.28.1260323324917; Tue, 08 Dec 2009 17:48:44 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm608788pzk.11.2009.12.08.17.48.43 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Dec 2009 17:48:44 -0800 (PST) Message-ID: <4B1F0203.5050600@gmail.com> Date: Wed, 09 Dec 2009 14:48:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: grobj@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 01:49:04 -0000 If we want to progress the referrals topic in Anaheim, we'll need to have a draft problem statement well in advance, and even better, some requirements analysis. So let me suggest a few points that should be covered. Please comment: 1. Terminology At least, we need a clear definition of what a referral is. I would expect that would lead to other terms that need definition. 2. Problems Addresses are no longer unique. Addresses are no longer globally reachable. Addresses are no longer all in the same format. Hosts in a transaction may "see" different addresses and ports at each end. Not all hosts (interfaces?) have FQDNs. Not all FQDNs are globally visible. Not all FQDNs are globally reachable by any of their addresses. Visibility and reachability scopes overlap in an arbitrary way. Addresses have finite lifetimes. DNS records have finite lifetimes. 3. Requirements Carry information between hosts [application instances?] in generic standard format. Self-describing object, can be interpreted by any host. Compact, efficient format for the normal case. Carry multiple types of reference. Carry scope and lifetime information as well as basic reference. Extensible. Carried over channel protected against error and forgery. Optionally encrypted. -- Regards Brian Carpenter From shengjiang@huawei.com Tue Dec 8 18:01:13 2009 Return-Path: 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 951F83A6A82 for ; Tue, 8 Dec 2009 18:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=1.585, BAYES_00=-2.599] 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 nOnNO9MSpaqU for ; Tue, 8 Dec 2009 18:01:12 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 938903A6A11 for ; Tue, 8 Dec 2009 18:01:12 -0800 (PST) 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 <0KUD00G3149OHP@szxga01-in.huawei.com> for grobj@ietf.org; Wed, 09 Dec 2009 10:01:00 +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 <0KUD0089D49OA4@szxga01-in.huawei.com> for grobj@ietf.org; Wed, 09 Dec 2009 10:01:00 +0800 (CST) Received: from j66104a ([10.111.12.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUD00B4E49NDL@szxml04-in.huawei.com> for grobj@ietf.org; Wed, 09 Dec 2009 10:01:00 +0800 (CST) Date: Wed, 09 Dec 2009 10:00:59 +0800 From: Sheng Jiang In-reply-to: <4B1F0203.5050600@gmail.com> To: 'Brian E Carpenter' , grobj@ietf.org Message-id: <001701ca7873$7467c3d0$4a0c6f0a@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: Acp4ccZ5bYytfUX4Sz6XnZZQP9+7ZQAAEDMg Subject: Re: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 02:01:13 -0000 Hi, Brian, Thanks for your abstract work. It looks great. The problems you listed here are for basic direct connectivity purpose. I am thinking GROBJ could go a little bit further: for the best choice among multiple possible paths. I guess this could be splitted into second level problems/requirements. What I am not sure is whether we should have additional section in a general ps draft or have two ps drafts, one for basic connectivity, one for the best path, Regards, Sheng > -----Original Message----- > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] > On Behalf Of Brian E Carpenter > Sent: Wednesday, December 09, 2009 9:49 AM > To: grobj@ietf.org > Subject: [grobj] Thoughts about the problem statement and > requirement analysis > > If we want to progress the referrals topic in Anaheim, we'll > need to have a draft problem statement well in advance, and > even better, some requirements analysis. So let me suggest a > few points that should be covered. Please comment: > > 1. Terminology > > At least, we need a clear definition of what a referral is. I > would expect that would lead to other terms that need definition. > > 2. Problems > > Addresses are no longer unique. > Addresses are no longer globally reachable. > Addresses are no longer all in the same format. > Hosts in a transaction may "see" different addresses and > ports at each end. > Not all hosts (interfaces?) have FQDNs. > Not all FQDNs are globally visible. > Not all FQDNs are globally reachable by any of their addresses. > Visibility and reachability scopes overlap in an arbitrary way. > Addresses have finite lifetimes. > DNS records have finite lifetimes. > > 3. Requirements > > Carry information between hosts [application instances?] in > generic standard format. > Self-describing object, can be interpreted by any host. > Compact, efficient format for the normal case. > Carry multiple types of reference. > Carry scope and lifetime information as well as basic reference. > Extensible. > Carried over channel protected against error and forgery. > Optionally encrypted. > > -- > Regards > Brian Carpenter > > > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj From mohamed.boucadair@orange-ftgroup.com Wed Dec 9 23:16:56 2009 Return-Path: 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 75B143A659C for ; Wed, 9 Dec 2009 23:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 S4zqKbwxFRio for ; Wed, 9 Dec 2009 23:16:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 3375D3A6A2A for ; Wed, 9 Dec 2009 23:16:55 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 21B88134308; Thu, 10 Dec 2009 08:16:43 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0963E35C01C; Thu, 10 Dec 2009 08:16:43 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 10 Dec 2009 08:16:42 +0100 From: To: Brian E Carpenter , "grobj@ietf.org" Date: Thu, 10 Dec 2009 08:16:41 +0100 Thread-Topic: [grobj] Thoughts about the problem statement and requirement analysis Thread-Index: Acp4ccVMTOHOcriZT0GCvPRcMqgwuQA87L3g Message-ID: <11061_1260429403_4B20A05B_11061_117_1_94C682931C08B048B7A8645303FDC9F30EF2BBC9C6@PUEXCB1B.nanterre.francetelecom.fr> References: <4B1F0203.5050600@gmail.com> In-Reply-To: <4B1F0203.5050600@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.10.40326 Subject: Re: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 07:16:56 -0000 Dear Brian, all, Please see in line. -----Message d'origine----- De : grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] De la part de B= rian E Carpenter Envoy=E9 : mercredi 9 d=E9cembre 2009 02:49 =C0 : grobj@ietf.org Objet : [grobj] Thoughts about the problem statement and requirement analys= is If we want to progress the referrals topic in Anaheim, we'll need to have a draft problem statement well in advance, and even better, some requirements analysis. So let me suggest a few points that should be covered. Please comment: 1. Terminology At least, we need a clear definition of what a referral is. I would expect that would lead to other terms that need definition. 2. Problems Addresses are no longer unique. Med: I guess you mean: - Public IP addresses may not be used as "identifier"=20 - The same IP address may be assigned to several customers/devices (e.g., o= veralpping private IPv4 @ zones, shared IPv4 address behind a NAT) =20 Addresses are no longer globally reachable. Med: Do you mean: - Not all IP addresses are globally reachable Addresses are no longer all in the same format. Med: Are you referring to IPv4/IPv6? Hosts in a transaction may "see" different addresses and ports at each end. Not all hosts (interfaces?) have FQDNs. Not all FQDNs are globally visible. Not all FQDNs are globally reachable by any of their addresses. Med: I guess you mean: "Not all resources identified with an FQDN are globa= lly reachable by any of their addresses." Visibility and reachability scopes overlap in an arbitrary way. Addresses have finite lifetimes. DNS records have finite lifetimes. Med: I suggest the followings: - Some answers from DNS may be *fake* IP addresses (e.g., synthetic records= sent by DNS64). The hots does not have any means to detect that this addre= ss represents an IPv4 host. These addresses should not be interpreted as na= tive IPv6 address.=20 - Hosts may be identified by URI per service: no unique URI scheme - Having the address of the source and destination in the same IP version d= oes not mean that the path will be using that IP version - IP addresses may have a "context" (VoIP VC, IP TV, etc.): the visibility = of that address depends on that "context" 3. Requirements Carry information between hosts [application instances?] in generic standar= d format. Self-describing object, can be interpreted by any host. Compact, efficient format for the normal case. Carry multiple types of reference. Carry scope and lifetime information as well as basic reference. Extensible. Carried over channel protected against error and forgery. Optionally encrypted. Med: I suggest to add: - not specific to any application - trust information: the orgin of the ref should be included - the preference order is optional (even not required. It is up the the rem= ote party to decide)=20 Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From zhouboyj@gmail.com Wed Dec 9 23:57:29 2009 Return-Path: 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 E52AE3A6822 for ; Wed, 9 Dec 2009 23:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 ZbcaXBRL4Eun for ; Wed, 9 Dec 2009 23:57:28 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id BF2973A62C1 for ; Wed, 9 Dec 2009 23:57:28 -0800 (PST) Received: by iwn33 with SMTP id 33so5434724iwn.29 for ; Wed, 09 Dec 2009 23:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sxavjwPjsuFGKTGgHnOjrSdklxujqiUt0QQsMkFGX4E=; b=koI2+OVUdhpCoq50o3Ne8NbCofB2pz3gqww0izdjlQZINod6p0iyYNxOBY8fLVGDsB dkxXA3N/ieS0hAeRDIyMNSPp8FQrXL8nf6fW4MIqUPe9t1SS6n+PRBTff/TrEijG/bRE yCqs/CdLZtbgPMziJnW7D14LSM0YHmJjRopfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uWUyMBVbpspeoCjY3ZlvAoEkTuGO0tYFzmYB9N6YB6wDAzgN1nkZkgX4+i/Ws3egTf FQ1jvGPEYw6oPTZKfLUVS9cdc1uyCq09tb1DTf4tCK2BlsXDJjkxIXmLPAabr3yZtk7L cBvYvYi37ebhrNmmo2lpwv2GJbQHBR1MYfSb4= MIME-Version: 1.0 Received: by 10.231.167.212 with SMTP id r20mr712519iby.7.1260431834305; Wed, 09 Dec 2009 23:57:14 -0800 (PST) In-Reply-To: <001701ca7873$7467c3d0$4a0c6f0a@china.huawei.com> References: <4B1F0203.5050600@gmail.com> <001701ca7873$7467c3d0$4a0c6f0a@china.huawei.com> Date: Thu, 10 Dec 2009 15:57:14 +0800 Message-ID: <36a593230912092357h371f3ca2of0b4c4173f04c6b3@mail.gmail.com> From: bo zhou To: Sheng Jiang Content-Type: multipart/alternative; boundary=001636c5a4bdbf56ad047a5b276f Cc: grobj@ietf.org Subject: Re: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 07:57:30 -0000 --001636c5a4bdbf56ad047a5b276f Content-Type: text/plain; charset=ISO-8859-1 Hi Sheng, How the host know the path is the best? On Wed, Dec 9, 2009 at 10:00 AM, Sheng Jiang wrote: > Hi, Brian, > > Thanks for your abstract work. It looks great. > > The problems you listed here are for basic direct connectivity purpose. I > am > thinking GROBJ could go a little bit further: for the best choice among > multiple possible paths. I guess this could be splitted into second level > problems/requirements. What I am not sure is whether we should have > additional section in a general ps draft or have two ps drafts, one for > basic connectivity, one for the best path, > > Regards, > > Sheng > > > -----Original Message----- > > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] > > On Behalf Of Brian E Carpenter > > Sent: Wednesday, December 09, 2009 9:49 AM > > To: grobj@ietf.org > > Subject: [grobj] Thoughts about the problem statement and > > requirement analysis > > > > If we want to progress the referrals topic in Anaheim, we'll > > need to have a draft problem statement well in advance, and > > even better, some requirements analysis. So let me suggest a > > few points that should be covered. Please comment: > > > > 1. Terminology > > > > At least, we need a clear definition of what a referral is. I > > would expect that would lead to other terms that need definition. > > > > 2. Problems > > > > Addresses are no longer unique. > > Addresses are no longer globally reachable. > > Addresses are no longer all in the same format. > > Hosts in a transaction may "see" different addresses and > > ports at each end. > > Not all hosts (interfaces?) have FQDNs. > > Not all FQDNs are globally visible. > > Not all FQDNs are globally reachable by any of their addresses. > > Visibility and reachability scopes overlap in an arbitrary way. > > Addresses have finite lifetimes. > > DNS records have finite lifetimes. > > > > 3. Requirements > > > > Carry information between hosts [application instances?] in > > generic standard format. > > Self-describing object, can be interpreted by any host. > > Compact, efficient format for the normal case. > > Carry multiple types of reference. > > Carry scope and lifetime information as well as basic reference. > > Extensible. > > Carried over channel protected against error and forgery. > > Optionally encrypted. > > > > -- > > Regards > > Brian Carpenter > > > > > > _______________________________________________ > > grobj mailing list > > grobj@ietf.org > > https://www.ietf.org/mailman/listinfo/grobj > > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj > -- Regards, Bo Zhou China Mobile --001636c5a4bdbf56ad047a5b276f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sheng,
=A0
How the host know the path is the best?

=A0
On Wed, Dec 9, 2009 at 10:00 AM, Sheng Jiang <shengjiang@huaw= ei.com> wrote:
Hi, Brian,

Thanks for you= r abstract work. It looks great.

The problems you listed here are fo= r basic direct connectivity purpose. I am
thinking GROBJ could go a little bit further: for the best choice among
= multiple possible paths. I guess this could be splitted into second levelproblems/requirements. What I am not sure is whether we should have
additional section in a general ps draft or have two ps drafts, one for
= basic connectivity, one for the best path,

Regards,

Sheng

> -----Original Message-----
> From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org]
> On= Behalf Of Brian E Carpenter
> Sent: Wednesday, December 09, 2009 9:49 AM
> To: grobj@ietf.org
> Subject: [grobj] Thoughts abo= ut the problem statement and
> requirement analysis
>
> I= f we want to progress the referrals topic in Anaheim, we'll
> need to have a draft problem statement well in advance, and
> ev= en better, some requirements analysis. So let me suggest a
> few poin= ts that should be covered. Please comment:
>
> 1. Terminology >
> At least, we need a clear definition of what a referral is. I<= br>> would expect that would lead to other terms that need definition.>
> 2. Problems
>
> Addresses are no longer unique.<= br> > Addresses are no longer globally reachable.
> Addresses are no l= onger all in the same format.
> Hosts in a transaction may "see&= quot; different addresses and
> ports at each end.
> Not all ho= sts (interfaces?) have FQDNs.
> Not all FQDNs are globally visible.
> Not all FQDNs are globally= reachable by any of their addresses.
> Visibility and reachability s= copes overlap in an arbitrary way.
> Addresses have finite lifetimes.=
> DNS records have finite lifetimes.
>
> 3. Requirements
= >
> Carry information between hosts [application instances?] in> generic standard format.
> Self-describing object, can be inter= preted by any host.
> Compact, efficient format for the normal case.
> Carry multiple = types of reference.
> Carry scope and lifetime information as well as= basic reference.
> Extensible.
> Carried over channel protecte= d against error and forgery.
> Optionally encrypted.
>
> --
> Regards
> =A0 = =A0Brian Carpenter
>
>
> ________________________________= _______________
> grobj mailing list
> grobj@ietf.org
> https://www.ietf.org/mailman/listinfo/grobj

________________= _______________________________
grobj mailing list
grobj@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/grobj
=



--
Regards,

Bo Zhou
China Mob= ile
--001636c5a4bdbf56ad047a5b276f-- From swb@employees.org Thu Dec 10 04:34:33 2009 Return-Path: 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 00EFC3A6B37 for ; Thu, 10 Dec 2009 04:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 i5MAt5e2pKkl for ; Thu, 10 Dec 2009 04:34:32 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B921E3A69C1 for ; Thu, 10 Dec 2009 04:34:31 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GAId5IEtAZnwM/2dsb2JhbACZCaVglyCELAQ X-IronPort-AV: E=Sophos;i="4.47,375,1257120000"; d="scan'208";a="73404543" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Dec 2009 12:34:20 +0000 Received: from sbrim-mbp.local ([10.86.252.61]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBACYJlY015889; Thu, 10 Dec 2009 12:34:19 GMT Message-ID: <4B20EACB.6080306@employees.org> Date: Thu, 10 Dec 2009 07:34:19 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: bo zhou References: <4B1F0203.5050600@gmail.com> <001701ca7873$7467c3d0$4a0c6f0a@china.huawei.com> <36a593230912092357h371f3ca2of0b4c4173f04c6b3@mail.gmail.com> In-Reply-To: <36a593230912092357h371f3ca2of0b4c4173f04c6b3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: grobj@ietf.org Subject: Re: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 12:34:33 -0000 bo zhou allegedly wrote on 12/10/2009 2:57 AM: > Hi Sheng, > > How the host know the path is the best? Right. A referral should provide _identification_ information, and leave path determination to the referral receiver. (In some cases the only identification information available is an IP address.) From alan.ford@roke.co.uk Thu Dec 10 07:53:12 2009 Return-Path: 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 576663A6A9E for ; Thu, 10 Dec 2009 07:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 WG-6ArTI96it for ; Thu, 10 Dec 2009 07:53:11 -0800 (PST) Received: from rsys001x.roke.co.uk (rsys001x.roke.co.uk [193.118.201.108]) by core3.amsl.com (Postfix) with ESMTP id 1BAA13A69FD for ; Thu, 10 Dec 2009 07:53:10 -0800 (PST) Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nBAFqp19030564; Thu, 10 Dec 2009 15:52:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 15:52:23 -0000 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680907B4CA@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <4B1F0203.5050600@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [grobj] Thoughts about the problem statement and requirementanalysis Thread-Index: Acp4cctlpGrdpLIERrePVD49Vb1HsABOY+tQ References: <4B1F0203.5050600@gmail.com> From: "Ford, Alan" To: "Brian E Carpenter" , X-roke-co-uk-MailScanner: Found to be clean X-roke-co-uk-MailScanner-SpamCheck: X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk Subject: Re: [grobj] Thoughts about the problem statement and requirementanalysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:53:12 -0000 Hi Brian, all, Seems like a good starting list. > -----Original Message----- > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: 09 December 2009 01:49 > To: grobj@ietf.org > Subject: [grobj] Thoughts about the problem statement and requirementanalysis >=20 > If we want to progress the referrals topic in Anaheim, we'll need to > have a draft problem statement well in advance, and even better, > some requirements analysis. So let me suggest a few points that > should be covered. Please comment: >=20 > 1. Terminology >=20 > At least, we need a clear definition of what a referral is. I would > expect that would lead to other terms that need definition. "Referral: a piece of information that provides a peer with sufficient information to utilise one or more methods by which the sender can be reached." > 2. Problems >=20 > Addresses are no longer unique. > Addresses are no longer globally reachable. > Addresses are no longer all in the same format. _May_ no longer be! > Hosts in a transaction may "see" different addresses and ports at each end. > Not all hosts (interfaces?) have FQDNs. > Not all FQDNs are globally visible. > Not all FQDNs are globally reachable by any of their addresses. > Visibility and reachability scopes overlap in an arbitrary way. > Addresses have finite lifetimes. > DNS records have finite lifetimes. ... and for both those finite lifetimes, whilst this may be the declared lifetimes (e.g. DNS, v6 valid/preferred lifetimes), an address or DNS record may become unexpectedly invalid too. So do we need to cope with withdrawal as well as declaration of referral? (Which may also encompass your third-from-bottom point). > 3. Requirements >=20 > Carry information between hosts [application instances?] in generic standard > format. > Self-describing object, can be interpreted by any host. > Compact, efficient format for the normal case. > Carry multiple types of reference. > Carry scope and lifetime information as well as basic reference. > Extensible. > Carried over channel protected against error and forgery. > Optionally encrypted. The last two would seem out of scope for the definition of a referral object itself. It should be agnostic of any transport channel, encoding, etc. Indeed, as a self-describing object it should be usable as a component in any wider protocol/solution, and should not be specific to any one in particular. The grey area would be things like: if the GROBJ provides prioritisation of referrals, do we mandate how endpoints handle that or is that up to the application that uses the GROBJ? Regards, Alan From shengjiang@huawei.com Thu Dec 10 17:28:07 2009 Return-Path: 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 93A1D3A6925 for ; Thu, 10 Dec 2009 17:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, 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 cBAByiEuWyY5 for ; Thu, 10 Dec 2009 17:28:06 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B2D883A6900 for ; Thu, 10 Dec 2009 17:28:06 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG007JWS28EC@szxga03-in.huawei.com> for grobj@ietf.org; Fri, 11 Dec 2009 09:27:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG00DQNS285P@szxga03-in.huawei.com> for grobj@ietf.org; Fri, 11 Dec 2009 09:27:44 +0800 (CST) Received: from j66104a ([10.111.12.74]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUG0056LS28QT@szxml06-in.huawei.com> for grobj@ietf.org; Fri, 11 Dec 2009 09:27:44 +0800 (CST) Date: Fri, 11 Dec 2009 09:27:45 +0800 From: Sheng Jiang In-reply-to: <4B20EACB.6080306@employees.org> To: 'Scott Brim' , 'bo zhou' Message-id: <000901ca7a01$245819f0$4a0c6f0a@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: Acp5lSdO9nwq0a3TT5+WnfFPPI3g7gAaeBQg Cc: grobj@ietf.org Subject: Re: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 01:28:07 -0000 First of all, this is a potential requirements for us to work on it. So, the don't think we are discussing a solution here. We just need to make sure whether there is such requirement in the reality or not. The referral object should include all/most information which can be used to build direct connection with the host. That means the referral should include multiple addresses if there are more than one available. Scott is right. The path determination should be the job of the referral receiver. What we need to make sure is the referral object should provide enough information for the receiver to make the right decision. An familiar example here: a host has two physical interface, WiFi and 3G, which charge very differently. For the basic connectivity requirement, a correpondent hode can use either interface and its associated address. For the simplest referral, any one of the addresses could work well. For the enhanced requirements, mutliple addresses and their preference should also be provided. Regards, Sheng > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Thursday, December 10, 2009 8:34 PM > To: bo zhou > Cc: Sheng Jiang; grobj@ietf.org > Subject: Re: [grobj] Thoughts about the problem statement and > requirement analysis > > bo zhou allegedly wrote on 12/10/2009 2:57 AM: > > Hi Sheng, > > > > How the host know the path is the best? > > Right. A referral should provide _identification_ > information, and leave path determination to the referral > receiver. (In some cases the only identification information > available is an IP address.) From zhangdong_rh@huaweisymantec.com Thu Dec 10 17:44:54 2009 Return-Path: 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 292FD3A68E4 for ; Thu, 10 Dec 2009 17:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.845 X-Spam-Level: * X-Spam-Status: No, score=1.845 tagged_above=-999 required=5 tests=[AWL=-2.427, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, MIME_BASE64_TEXT=1.753, 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 uxhImweKuha0 for ; Thu, 10 Dec 2009 17:44:53 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B7A4B3A6848 for ; Thu, 10 Dec 2009 17:44:49 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KUG00M66SU3EA80@hstga01-in.huaweisymantec.com> for grobj@ietf.org; Fri, 11 Dec 2009 09:44:27 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KUG00D7HSU3LF10@hstml02-in.huaweisymantec.com> for grobj@ietf.org; Fri, 11 Dec 2009 09:44:27 +0800 (CST) Date: Fri, 11 Dec 2009 09:44:26 +0800 From: Dong Zhang To: Sheng Jiang , 'Scott Brim' , 'bo zhou' References: <000901ca7a01$245819f0$4a0c6f0a@china.huawei.com> Message-id: <200912110944261415039@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-transfer-encoding: base64 Cc: "grobj@ietf.org" Subject: Re: [grobj] Thoughts about the problem statement and requirementanalysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 01:44:54 -0000 SGksDQoNClNoZW5nIEppYW5nIDIwMDktMTItMTEgV3JvdGU6DQouLi4NCj5TY290dCBpcyByaWdo dC4gVGhlIHBhdGggZGV0ZXJtaW5hdGlvbiBzaG91bGQgYmUgdGhlIGpvYiBvZiB0aGUgcmVmZXJy YWwNCj5yZWNlaXZlci4gV2hhdCB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSBpcyB0aGUgcmVmZXJyYWwg b2JqZWN0IHNob3VsZCBwcm92aWRlDQo+ZW5vdWdoIGluZm9ybWF0aW9uIGZvciB0aGUgcmVjZWl2 ZXIgdG8gbWFrZSB0aGUgcmlnaHQgZGVjaXNpb24uDQpJZiBzbywgaXMgaXQgbmVjZXNzYXJ5IHRv IGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlIHJlY2VpdmVyPyBJIG1lYW4gaG93IA0KdGhlIHJl dmVpdmVyIHVzZXMgdGhlIHJlZmVycmFsIGluZm9ybWF0aW9uIHRvIG1ha2UgdGhlIGRlY2lzaW9u LiBJIGd1ZXNzIA0KcmZjMzQ4NCBtYXkgbm90IGJlIGVub3VnaC4NCg0KVGhhbmsgeW91Lg0KPg0K PkFuIGZhbWlsaWFyIGV4YW1wbGUgaGVyZTogYSBob3N0IGhhcyB0d28gcGh5c2ljYWwgaW50ZXJm YWNlLCBXaUZpIGFuZCAzRywNCj53aGljaCBjaGFyZ2UgdmVyeSBkaWZmZXJlbnRseS4gRm9yIHRo ZSBiYXNpYyBjb25uZWN0aXZpdHkgcmVxdWlyZW1lbnQsIGENCj5jb3JyZXBvbmRlbnQgaG9kZSBj YW4gdXNlIGVpdGhlciBpbnRlcmZhY2UgYW5kIGl0cyBhc3NvY2lhdGVkIGFkZHJlc3MuIEZvcg0K PnRoZSBzaW1wbGVzdCByZWZlcnJhbCwgYW55IG9uZSBvZiB0aGUgYWRkcmVzc2VzIGNvdWxkIHdv cmsgd2VsbC4gRm9yIHRoZQ0KPmVuaGFuY2VkIHJlcXVpcmVtZW50cywgbXV0bGlwbGUgYWRkcmVz c2VzIGFuZCB0aGVpciBwcmVmZXJlbmNlIHNob3VsZCBhbHNvDQo+YmUgcHJvdmlkZWQuDQo+DQo+ UmVnYXJkcywNCj4NCj5TaGVuZw0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IFNjb3R0IEJyaW0gW21haWx0bzpzd2JAZW1wbG95ZWVzLm9yZ10gDQo+PiBTZW50OiBU aHVyc2RheSwgRGVjZW1iZXIgMTAsIDIwMDkgODozNCBQTQ0KPj4gVG86IGJvIHpob3UNCj4+IENj OiBTaGVuZyBKaWFuZzsgZ3JvYmpAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbZ3JvYmpdIFRo b3VnaHRzIGFib3V0IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgDQo+PiByZXF1aXJlbWVudCBh bmFseXNpcw0KPj4gDQo+PiBibyB6aG91IGFsbGVnZWRseSB3cm90ZSBvbiAxMi8xMC8yMDA5IDI6 NTcgQU06DQo+PiA+IEhpIFNoZW5nLA0KPj4gPiAgDQo+PiA+IEhvdyB0aGUgaG9zdCBrbm93IHRo ZSBwYXRoIGlzIHRoZSBiZXN0Pw0KPj4gDQo+PiBSaWdodC4gIEEgcmVmZXJyYWwgc2hvdWxkIHBy b3ZpZGUgX2lkZW50aWZpY2F0aW9uXyANCj4+IGluZm9ybWF0aW9uLCBhbmQgbGVhdmUgcGF0aCBk ZXRlcm1pbmF0aW9uIHRvIHRoZSByZWZlcnJhbCANCj4+IHJlY2VpdmVyLiAgKEluIHNvbWUgY2Fz ZXMgdGhlIG9ubHkgaWRlbnRpZmljYXRpb24gaW5mb3JtYXRpb24gDQo+PiBhdmFpbGFibGUgaXMg YW4gSVAgYWRkcmVzcy4pDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5ncm9iaiBtYWlsaW5nIGxpc3QNCj5ncm9iakBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ3JvYmoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0JCQkJIA0KRG9uZyBaaGFuZw0KSHVhd2VpIFN5bWFudGVjIFRlY2hub2xvZ2llcyBDby4s IEx0ZA0KVEVMo7o4Ni0xMC02MjcyMTI4Nw0KRkFYo7o4Ni0xMC02MjcyMTM0Nw0KQUREUkVTU6O6 M3JkIEZsb29yLFNlY3Rpb24gRCwgS2VzaGkgQnVpbGRpbmcsIE5vLjI4LCBYaW54aSBSZC4sIFNo YW5nZGksIEhhaWRpYW4gRGlzdC4sIEJlaWppbmcsIENoaW5hLiAxMDAwODUgDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUkgU1lNQU5URUMsIHdoaWNoIGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMg bGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0 aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29u cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYg eW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KMjAwOS0xMi0xMQ0K From shengjiang@huawei.com Thu Dec 10 18:50:35 2009 Return-Path: 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 8393B3A68E4 for ; Thu, 10 Dec 2009 18:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, 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 qeLyGHceJEPz for ; Thu, 10 Dec 2009 18:50:34 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8CCC03A6862 for ; Thu, 10 Dec 2009 18:50:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG004EZVVJE4@szxga04-in.huawei.com> for grobj@ietf.org; Fri, 11 Dec 2009 10:50:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUG00HSLVVJWW@szxga04-in.huawei.com> for grobj@ietf.org; Fri, 11 Dec 2009 10:50:07 +0800 (CST) Received: from j66104a ([10.111.12.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUG006VSVVJVU@szxml04-in.huawei.com> for grobj@ietf.org; Fri, 11 Dec 2009 10:50:07 +0800 (CST) Date: Fri, 11 Dec 2009 10:50:06 +0800 From: Sheng Jiang In-reply-to: <200912110944261415039@huaweisymantec.com> To: 'Dong Zhang' , 'Scott Brim' , 'bo zhou' Message-id: <001301ca7a0c$a5de3580$4a0c6f0a@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=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acp6A3uPpfVBplQBRAGSlu16++A7FAAB9n+A Cc: grobj@ietf.org Subject: Re: [grobj] Thoughts about the problem statement and requirementanalysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 02:50:35 -0000 > Sheng Jiang 2009-12-11 Wrote: > ... > >Scott is right. The path determination should be the job of the=20 > >referral receiver. What we need to make sure is the referral object=20 > >should provide enough information for the receiver to make=20 > the right decision. > If so, is it necessary to define the behavior of the=20 > receiver? I mean how the reveiver uses the referral=20 > information to make the decision. I guess > rfc3484 may not be enough. Yes, RFC 3484, even the address selection work currently in 6man WG is = not enough. However, in my opinion, we could/should NOT define the behavior = of the receiver in very details. It is mainly implementation work, I guess. However, we may produce a principle or recomendation document regarding = it. Sheng > >An familiar example here: a host has two physical interface,=20 > WiFi and=20 > >3G, which charge very differently. For the basic connectivity=20 > >requirement, a correpondent hode can use either interface and its=20 > >associated address. For the simplest referral, any one of=20 > the addresses=20 > >could work well. For the enhanced requirements, mutliple=20 > addresses and=20 > >their preference should also be provided. > > > >Regards, > > > >Sheng > > > >> -----Original Message----- > >> From: Scott Brim [mailto:swb@employees.org] > >> Sent: Thursday, December 10, 2009 8:34 PM > >> To: bo zhou > >> Cc: Sheng Jiang; grobj@ietf.org > >> Subject: Re: [grobj] Thoughts about the problem statement and=20 > >> requirement analysis > >>=20 > >> bo zhou allegedly wrote on 12/10/2009 2:57 AM: > >> > Hi Sheng, > >> > =20 > >> > How the host know the path is the best? > >>=20 > >> Right. A referral should provide _identification_=20 > information, and=20 > >> leave path determination to the referral receiver. (In some cases=20 > >> the only identification information available is an IP address.) > > > >_______________________________________________ > >grobj mailing list > >grobj@ietf.org > >https://www.ietf.org/mailman/listinfo/grobj >=20 >=20 > ------------------ =20 > Dong Zhang > Huawei Symantec Technologies Co., Ltd > TEL=A3=BA86-10-62721287 > FAX=A3=BA86-10-62721347 > ADDRESS=A3=BA3rd Floor,Section D, Keshi Building, No.28, Xinxi=20 > Rd., Shangdi, Haidian Dist., Beijing, China. 100085=20 >=20 > ************************************************************** > ********************* > This email and its attachments contain confidential=20 > information from HUAWEI SYMANTEC, which is intended only for=20 > the person or entity whose address is listed above. Any use=20 > of the information contained herein in any way (including,=20 > but not limited to, total or partial disclosure,=20 > reproduction, or dissemination) by persons other than the=20 > intended recipient(s) is prohibited. If you receive this=20 > e-mail in error, please notify the sender by phone or email=20 > immediately and delete it! > ************************************************************** > ******************** > 2009-12-11 >=20 From zhangdong_rh@huaweisymantec.com Thu Dec 10 19:27:39 2009 Return-Path: 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 C430E3A69AB for ; Thu, 10 Dec 2009 19:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.053 X-Spam-Level: ** X-Spam-Status: No, score=2.053 tagged_above=-999 required=5 tests=[AWL=-1.664, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, MIME_BASE64_TEXT=1.753, 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 ol7m4wmIaI5X for ; Thu, 10 Dec 2009 19:27:38 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 3EE4D3A69C2 for ; Thu, 10 Dec 2009 19:27:38 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KUG00J6WXLGHJ80@hstga02-in.huaweisymantec.com> for grobj@ietf.org; Fri, 11 Dec 2009 11:27:16 +0800 (CST) Received: from z90001956 ([10.27.154.173]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KUG00DFFXLEXF10@hstml02-in.huaweisymantec.com> for grobj@ietf.org; Fri, 11 Dec 2009 11:27:16 +0800 (CST) Date: Fri, 11 Dec 2009 11:27:14 +0800 From: Dong Zhang To: Sheng Jiang , 'Scott Brim' , 'bo zhou' References: <001301ca7a0c$a5de3580$4a0c6f0a@china.huawei.com> Message-id: <200912111127141959284@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-transfer-encoding: base64 Cc: "grobj@ietf.org" Subject: Re: [grobj] Thoughts about the problem statement andrequirementanalysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 03:27:40 -0000 SGksDQoNClNoZW5nIEppYW5nIDIwMDktMTItMTEgV3JvdGU6DQo+PiBTaGVuZyBKaWFuZyAyMDA5 LTEyLTExIFdyb3RlOg0KPj4gLi4uDQo+PiA+U2NvdHQgaXMgcmlnaHQuIFRoZSBwYXRoIGRldGVy bWluYXRpb24gc2hvdWxkIGJlIHRoZSBqb2Igb2YgdGhlIA0KPj4gPnJlZmVycmFsIHJlY2VpdmVy LiBXaGF0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIGlzIHRoZSByZWZlcnJhbCBvYmplY3QgDQo+PiA+ c2hvdWxkIHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uIGZvciB0aGUgcmVjZWl2ZXIgdG8gbWFr ZSANCj4+IHRoZSByaWdodCBkZWNpc2lvbi4NCj4+IElmIHNvLCBpcyBpdCBuZWNlc3NhcnkgdG8g ZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUgDQo+PiByZWNlaXZlcj8gSSBtZWFuIGhvdyB0aGUg cmV2ZWl2ZXIgdXNlcyB0aGUgcmVmZXJyYWwgDQo+PiBpbmZvcm1hdGlvbiB0byBtYWtlIHRoZSBk ZWNpc2lvbi4gSSBndWVzcw0KPj4gcmZjMzQ4NCBtYXkgbm90IGJlIGVub3VnaC4NCj4NCj5ZZXMs IFJGQyAzNDg0LCBldmVuIHRoZSBhZGRyZXNzIHNlbGVjdGlvbiB3b3JrIGN1cnJlbnRseSBpbiA2 bWFuIFdHIGlzIG5vdA0KPmVub3VnaC4gSG93ZXZlciwgaW4gbXkgb3Bpbmlvbiwgd2UgY291bGQv c2hvdWxkIE5PVCBkZWZpbmUgdGhlIGJlaGF2aW9yIG9mDQo+dGhlIHJlY2VpdmVyIGluIHZlcnkg ZGV0YWlscy4gSXQgaXMgbWFpbmx5IGltcGxlbWVudGF0aW9uIHdvcmssIEkgZ3Vlc3MuDQo+SG93 ZXZlciwgd2UgbWF5IHByb2R1Y2UgYSBwcmluY2lwbGUgb3IgcmVjb21lbmRhdGlvbiBkb2N1bWVu dCByZWdhcmRpbmcgaXQuDQpBZ3JlZS4gQW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCBvbiByZWNv bW1lbmRhdGlvbiB3aGljaCBpcyBhY2NvcmRhbnQgd2l0aCANCmFkZHJlc3Mgc2VsZWN0aW9uIG1p Z2h0IGJlIHVzZWZ1bC4NCj4NCj5TaGVuZw0KPg0KPj4gPkFuIGZhbWlsaWFyIGV4YW1wbGUgaGVy ZTogYSBob3N0IGhhcyB0d28gcGh5c2ljYWwgaW50ZXJmYWNlLCANCj4+IFdpRmkgYW5kIA0KPj4g PjNHLCB3aGljaCBjaGFyZ2UgdmVyeSBkaWZmZXJlbnRseS4gRm9yIHRoZSBiYXNpYyBjb25uZWN0 aXZpdHkgDQo+PiA+cmVxdWlyZW1lbnQsIGEgY29ycmVwb25kZW50IGhvZGUgY2FuIHVzZSBlaXRo ZXIgaW50ZXJmYWNlIGFuZCBpdHMgDQo+PiA+YXNzb2NpYXRlZCBhZGRyZXNzLiBGb3IgdGhlIHNp bXBsZXN0IHJlZmVycmFsLCBhbnkgb25lIG9mIA0KPj4gdGhlIGFkZHJlc3NlcyANCj4+ID5jb3Vs ZCB3b3JrIHdlbGwuIEZvciB0aGUgZW5oYW5jZWQgcmVxdWlyZW1lbnRzLCBtdXRsaXBsZSANCj4+ IGFkZHJlc3NlcyBhbmQgDQo+PiA+dGhlaXIgcHJlZmVyZW5jZSBzaG91bGQgYWxzbyBiZSBwcm92 aWRlZC4NCj4+ID4NCj4+ID5SZWdhcmRzLA0KPj4gPg0KPj4gPlNoZW5nDQo+PiA+DQo+PiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogU2NvdHQgQnJpbSBbbWFpbHRv OnN3YkBlbXBsb3llZXMub3JnXQ0KPj4gPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDEwLCAy MDA5IDg6MzQgUE0NCj4+ID4+IFRvOiBibyB6aG91DQo+PiA+PiBDYzogU2hlbmcgSmlhbmc7IGdy b2JqQGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBSZTogW2dyb2JqXSBUaG91Z2h0cyBhYm91dCB0 aGUgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIA0KPj4gPj4gcmVxdWlyZW1lbnQgYW5hbHlzaXMNCj4+ ID4+IA0KPj4gPj4gYm8gemhvdSBhbGxlZ2VkbHkgd3JvdGUgb24gMTIvMTAvMjAwOSAyOjU3IEFN Og0KPj4gPj4gPiBIaSBTaGVuZywNCj4+ID4+ID4gIA0KPj4gPj4gPiBIb3cgdGhlIGhvc3Qga25v dyB0aGUgcGF0aCBpcyB0aGUgYmVzdD8NCj4+ID4+IA0KPj4gPj4gUmlnaHQuICBBIHJlZmVycmFs IHNob3VsZCBwcm92aWRlIF9pZGVudGlmaWNhdGlvbl8gDQo+PiBpbmZvcm1hdGlvbiwgYW5kIA0K Pj4gPj4gbGVhdmUgcGF0aCBkZXRlcm1pbmF0aW9uIHRvIHRoZSByZWZlcnJhbCByZWNlaXZlci4g IChJbiBzb21lIGNhc2VzIA0KPj4gPj4gdGhlIG9ubHkgaWRlbnRpZmljYXRpb24gaW5mb3JtYXRp b24gYXZhaWxhYmxlIGlzIGFuIElQIGFkZHJlc3MuKQ0KPj4gPg0KPj4gPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+Z3JvYmogbWFpbGluZyBsaXN0 DQo+PiA+Z3JvYmpAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2dyb2JqDQo+PiANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tCQkJCSANCj4+IERv bmcgWmhhbmcNCj4+IEh1YXdlaSBTeW1hbnRlYyBUZWNobm9sb2dpZXMgQ28uLCBMdGQNCj4+IFRF TKO6ODYtMTAtNjI3MjEyODcNCj4+IEZBWKO6ODYtMTAtNjI3MjEzNDcNCj4+IEFERFJFU1OjujNy ZCBGbG9vcixTZWN0aW9uIEQsIEtlc2hpIEJ1aWxkaW5nLCBOby4yOCwgWGlueGkgDQo+PiBSZC4s IFNoYW5nZGksIEhhaWRpYW4gRGlzdC4sIEJlaWppbmcsIENoaW5hLiAxMDAwODUgDQo+PiANCj4+ ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQo+PiAqKioqKioqKioqKioqKioqKioqKioNCj4+IFRoaXMgZW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCANCj4+IGluZm9ybWF0aW9uIGZyb20gSFVB V0VJIFNZTUFOVEVDLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciANCj4+IHRoZSBwZXJzb24g b3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIA0KPj4gb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCAN Cj4+IGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCANCj4+ IHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRo ZSANCj4+IGludGVuZGVkIHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZSB0aGlzIA0KPj4gZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkg cGhvbmUgb3IgZW1haWwgDQo+PiBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KPj4gKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cj4+ICoqKioqKioqKioqKioqKioqKioqDQo+PiAyMDA5LTEyLTExDQo+PiANCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0JCQkJIA0KRG9uZyBaaGFuZw0KSHVhd2VpIFN5bWFudGVjIFRlY2hub2xvZ2ll cyBDby4sIEx0ZA0KVEVMo7o4Ni0xMC02MjcyMTI4Nw0KRkFYo7o4Ni0xMC02MjcyMTM0Nw0KQURE UkVTU6O6M3JkIEZsb29yLFNlY3Rpb24gRCwgS2VzaGkgQnVpbGRpbmcsIE5vLjI4LCBYaW54aSBS ZC4sIFNoYW5nZGksIEhhaWRpYW4gRGlzdC4sIEJlaWppbmcsIENoaW5hLiAxMDAwODUgDQoNCioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUkgU1lNQU5URUMsIHdo aWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJl c3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBv ciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkg cGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgaXMgcHJvaGliaXRl ZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KMjAwOS0xMi0xMQ0K From mohamed.boucadair@orange-ftgroup.com Wed Dec 16 22:05:44 2009 Return-Path: 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 E8C7C3A6936 for ; Wed, 16 Dec 2009 22:05:44 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 tE6zjmDBmjFx for ; Wed, 16 Dec 2009 22:05:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id A9A863A6840 for ; Wed, 16 Dec 2009 22:05:43 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4FFBA1044E6 for ; Thu, 17 Dec 2009 07:05:27 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3859527C057 for ; Thu, 17 Dec 2009 07:05:27 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.14]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 17 Dec 2009 07:05:27 +0100 From: To: "grobj@ietf.org" Date: Thu, 17 Dec 2009 07:05:25 +0100 Thread-Topic: New referral use case: widthraw CGN from the path (draft-boucadair-softwire-cgn-bypass) Thread-Index: Acp+bQUMRr26Vh7eTxe0xILbwuXvEQAcVYcw Message-ID: <24667_1261029927_4B29CA27_24667_29388_1_94C682931C08B048B7A8645303FDC9F30EF2C3FC6E@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F30EF2C3FC6EPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.12.17.51516 Subject: [grobj] New referral use case: widthraw CGN from the path (draft-boucadair-softwire-cgn-bypass) X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 06:05:45 -0000 --_002_94C682931C08B048B7A8645303FDC9F30EF2C3FC6EPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, Please find below a link to a new submitted draft which describes another r= eferral use case (not between end host but between involved CGN devices). T= he objective is to avoid crossing CGN devices. Comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : mercredi 16 d=E9cembre 2009 17:30 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-softwire-cgn-bypass-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Procedure to bypass DS-lite AFTR Author(s) : M. Boucadair Filename : draft-boucadair-softwire-cgn-bypass-00.txt Pages : 16 Date : 2009-12-16 This document proposes a solution to avoid the use of two stateful CGN (a.k.a., AFTR in [I-D.ietf-softwire-dual-stack-lite]) devices when both participants (a.k.a., B4 element) are located behind different CGN devices. For this purpose a new IPv6 extension header, called Tunnel Endpoint Extension Header (TEEH), is defined. The proposed procedure encourages the use of IPv6 between AFTR nodes as a means to avoid the unnecessary crossing of AFTR devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-softwire-cgn-bypass-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_002_94C682931C08B048B7A8645303FDC9F30EF2C3FC6EPUEXCB1Bnante_ Content-Type: message/external-body; name="draft-boucadair-softwire-cgn-bypass-00.url" Content-Description: draft-boucadair-softwire-cgn-bypass-00.url Content-Disposition: attachment; filename="draft-boucadair-softwire-cgn-bypass-00.url"; size=103; creation-date="Wed, 16 Dec 2009 17:30:03 GMT"; modification-date="Wed, 16 Dec 2009 17:30:03 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItc29mdHdpcmUtY2duLWJ5cGFzcy0wMC50eHQNCg== --_002_94C682931C08B048B7A8645303FDC9F30EF2C3FC6EPUEXCB1Bnante_-- From brian.e.carpenter@gmail.com Thu Dec 17 11:42:18 2009 Return-Path: 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 B640828C154 for ; Thu, 17 Dec 2009 11:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] 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 hskFAF0nlOtp for ; Thu, 17 Dec 2009 11:42:17 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A9EC328C0F5 for ; Thu, 17 Dec 2009 11:42:17 -0800 (PST) Received: by yxe30 with SMTP id 30so2661352yxe.29 for ; Thu, 17 Dec 2009 11:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aS9Vf3OJWzu29ZTXSdhQ9G2r+PX8PWKOXZCHSmvMgLA=; b=emcbk4kUV5pCz400aqYzr7+EB/yQBHS1eeh9GUcOReKAxHO45Nvo9t+3+28dxwrmSp /xE88c6ALnuQ0PxdkvJ+G2pDiRYD131cKt9fXUGl/kDpGUeGNwV36mZ/KIv52vvbIP3u a4mZLL+KCoqqYif6CBddNe2qDmB8BSQ9yAJZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=LHaO2XLHX16B9IzK9c7SPH7Y+nsnINgH4ePqjgxNkzGSwhdIrixG1cgX7Wb+TnEbd7 WW8XSMcWJFN/AtZf4b6wdQgWBTUCOjs02gPgkKK/dr1qu5uY1EXHKCf9TEPKjohghqDS rZ9hJDGE/44OsokgffFPhs0Jg6+wN3EGJoqiE= Received: by 10.90.62.4 with SMTP id k4mr3191019aga.56.1261078920503; Thu, 17 Dec 2009 11:42:00 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 4sm847547ywg.13.2009.12.17.11.41.58 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Dec 2009 11:41:59 -0800 (PST) Message-ID: <4B2A897C.4000707@gmail.com> Date: Fri, 18 Dec 2009 08:41:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <24667_1261029927_4B29CA27_24667_29388_1_94C682931C08B048B7A8645303FDC9F30EF2C3FC6E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <24667_1261029927_4B29CA27_24667_29388_1_94C682931C08B048B7A8645303FDC9F30EF2C3FC6E@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "grobj@ietf.org" Subject: Re: [grobj] New referral use case: widthraw CGN from the path (draft-boucadair-softwire-cgn-bypass) X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:42:18 -0000 Hi Med, Have you thought about how this relates to the definition of scope (or what RSIP calls an addressing realm)? Any case where we want to avoid hairpinning is a bit the same, I think. Can you extract any additional requirements from this? I could start work on a problem + requirements draft soon. Regards Brian Carpenter On 2009-12-17 19:05, mohamed.boucadair@orange-ftgroup.com wrote: > =20 > Dear all, >=20 > Please find below a link to a new submitted draft which describes anoth= er referral use case (not between end host but between involved CGN devic= es). The objective is to avoid crossing CGN devices. >=20 > Comments are more than welcome. >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] De la part de Internet-Drafts@ietf.org > Envoy=C3=A9 : mercredi 16 d=C3=A9cembre 2009 17:30 > =C3=80 : i-d-announce@ietf.org > Objet : I-D Action:draft-boucadair-softwire-cgn-bypass-00.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >=20 > Title : Procedure to bypass DS-lite AFTR > Author(s) : M. Boucadair > Filename : draft-boucadair-softwire-cgn-bypass-00.txt > Pages : 16 > Date : 2009-12-16 >=20 > This document proposes a solution to avoid the use of two stateful > CGN (a.k.a., AFTR in [I-D.ietf-softwire-dual-stack-lite]) devices > when both participants (a.k.a., B4 element) are located behind > different CGN devices. For this purpose a new IPv6 extension header, > called Tunnel Endpoint Extension Header (TEEH), is defined. The > proposed procedure encourages the use of IPv6 between AFTR nodes as a > means to avoid the unnecessary crossing of AFTR devices. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-boucadair-softwire-cgn-bypass= -00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > ********************************* > This message and any attachments (the "message") are confidential and i= ntended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if altered, ch= anged or falsified. > If you are not the intended addressee of this message, please cancel it= immediately and inform the sender. > ******************************** >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj From brian.e.carpenter@gmail.com Fri Dec 18 12:59:51 2009 Return-Path: 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 5B2633A6AC2 for ; Fri, 18 Dec 2009 12:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] 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 H8rERWJKQp7c for ; Fri, 18 Dec 2009 12:59:42 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 3EFAF3A67A1 for ; Fri, 18 Dec 2009 12:59:40 -0800 (PST) Received: by gxk28 with SMTP id 28so3377460gxk.9 for ; Fri, 18 Dec 2009 12:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=JP91u1o5WdaTFTVB+QVBQKww35XDVt99HyfsTA/KrC0=; b=qIDt8y0fEHmzUnDhDOgB/PqLS9L6wIWmox27u1s6LGhZhzHzWSdGREMfM6O95dDfQH 35x5Mbo1/vmJgEgfSBgEjL/loCQFL1jirxsOwg3/wTX2tTL331KY3kVtBa2QBRZF5mW7 H4QAJp1C3k2haUmXSNpLriNGYip01VoVnKY3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=RAc2/UTZXCsx4ErGkLqHpGrFrOfUGhXo1ZKSjuG0EGmxOny4M1LWcB0hSTkc5INpah rYNdLXpEsIfx10pfDVDIXID/eYkriaKkt3ldIBwnJVEqcYdktA6S4ao3rmSwaQMfToLd 5SOt/Qyr4VDNC67TVfM9v/JlUTwjNZo/iahI8= Received: by 10.150.102.37 with SMTP id z37mr7260102ybb.69.1261169961257; Fri, 18 Dec 2009 12:59:21 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 4sm1247877ywi.12.2009.12.18.12.59.19 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 12:59:20 -0800 (PST) Message-ID: <4B2BED20.7050800@gmail.com> Date: Sat, 19 Dec 2009 09:59:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: grobj@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [grobj] [Fwd: reminder about BOF proposals] X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 20:59:52 -0000 A timely warning. I will try to generate a problem/requirements draft in the coming weeks, but if we want a second BOF, I think we'll need a bit more life on this list, and clear ideas about a work plan. Brian -------- Original Message -------- Subject: reminder about BOF proposals Date: Fri, 18 Dec 2009 14:02:25 +0200 From: Jari Arkko To: IETF Discussion This is an early reminder that if you are planning to submit a BOF proposal for the next IETF meeting, its time to start acting. The requests must be submitted in little over five weeks. Or six weeks if you do it in UTC time, but I think that is an error on the web site :-) Of course, much of the real work needs to happen before submitting a request -- writing Internet Drafts, working on a charter proposal, having a list discussion with the interested parties, etc. Also, the ADs would like to know if you are thinking of something, as early as possible. Talk to your ADs. http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77 says: 2010-01-25 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PST (01:00 Tuesday, February 2 UTC). To request a BOF, please see instructions on Requesting a BOF 2010-02-08 (Monday): Cutoff date for Area Directors to approve BOFs at 17:00 PST (01:00 Tuesday, February 9 UTC). Jari _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From brian.e.carpenter@gmail.com Tue Dec 22 14:36:30 2009 Return-Path: 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 48B933A68F6 for ; Tue, 22 Dec 2009 14:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] 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 gBDvYYp+iaAP for ; Tue, 22 Dec 2009 14:36:29 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id D46813A6A82 for ; Tue, 22 Dec 2009 14:36:28 -0800 (PST) Received: by ywh15 with SMTP id 15so6922922ywh.5 for ; Tue, 22 Dec 2009 14:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=drYTie0R8QsmIemugeOVk4+kKHM6sS7cm8dJbAPqUkY=; b=ZSx7uXGfPK7i+SdxwwWdLl8Xj+EldBwbP3hSt8Yp8q1wp7NYWW2KIJmZp1uvNI0GNu EM85niOViTzSIT7HtYY1/OHVstZS46LIF7E1U65RoCAs7mNUTMyluhhhEawzNGRtak9G axtT+X0MESagEsdfzjX2fENwtnIlAk6lM6TVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=SLpb20HUYKEylOG4/dQZLczyhwtWEt+ZcbojxCymXKNiWZMXWFakPPIgnfx68DxVpM 4JwNRtudINPlXI7pT/Z7F6FTVTiKFiq9zbxLidax3rH7lco/iBvs5K8yPz/KZVkab+SM swCQGTN/VrlBSok8O+kGXuGRd6pkSaVXMaRbs= Received: by 10.101.141.4 with SMTP id t4mr14650492ann.129.1261521369058; Tue, 22 Dec 2009 14:36:09 -0800 (PST) Received: from ?10.1.1.4? ([121.98.142.15]) by mx.google.com with ESMTPS id 4sm2566519ywi.42.2009.12.22.14.36.07 (version=SSLv3 cipher=RC4-MD5); Tue, 22 Dec 2009 14:36:08 -0800 (PST) Message-ID: <4B3149D0.6070005@gmail.com> Date: Wed, 23 Dec 2009 11:36:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: grobj@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [grobj] [Fwd: WG Action: Multiple AoR reachabiliTy InformatioN Indication (martini)] X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 22:36:30 -0000 Hi, Does anyone here understand the WG charter below well enough to extract some GRO requirements from it? Brian -------- Original Message -------- Subject: WG Action: Multiple AoR reachabiliTy InformatioN Indication (martini) Date: Tue, 22 Dec 2009 14:00:01 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org CC: bernard_aboba@hotmail.com, martini@ietf.org A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Multiple AoR reachabiliTy InformatioN Indication (MARTINI) --------------------------------------------------------- Last Modified: 2009-12-08 Proposed Chair(s): Spencer Dawkins Bernard Aboba Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Mailing Lists: General Discussion: martini@ietf.org To Subscribe: martini-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/martini/index.html Description of Working Group The MARTINI working group is chartered to specify a means by which an entity that is authoritative for SIP URIs can dynamically register reachability information for multiple Addresses of Record ("AORs") with a service provider. The SIP protocol [RFC 3261 and its extensions] supports multiple means of obtaining the connection information necessary to deliver out-of-dialog SIP requests to their intended targets. When a SIP Proxy needs to send a request to a target AOR within its domain, it can use a location service to obtain the registered contact URI, together with any associated path information [RFC 3327], and build a route set to reach the target UA(s). The SIP REGISTER method can be used to register contact URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism to cater for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a request to a target for which it is not authoritative, the UA/Proxy can use RFC3263 procedures for using DNS to resolve the next-hop connection information. In practice, many small and medium-sized businesses use a SIP-PBX that is authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as a registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service Provider (SSP) provides SIP peering/trunking capability to the SIP PBX. The SIP-PBX must be reachable from the SSP so that the SSP can route inbound SIP requests for the AoRs addressed to the SIP PBX, routing these requests to the SIP-PBX itself for onward delivery to registered UAs. Experience has shown that existing mechanisms are not always sufficient to support SIP-PBXs for small/medium businesses. Since a single SSP may support multiple thousands of such SMB SIP-PBX's, it is impractical and cost-prohibitive to manually provision their IP addresses in every SIP node along paths to those SIP-PBXs. Furthermore, IP addresses can be dynamically assigned and therefore can potentially change relatively frequently. In current deployments, dynamic reachability mechanisms based on the SIP REGISTER method are commonly used. Effectively, a single REGISTER request registers the AoR of the SIP-PBX, so that any out-of-dialog request targeted at a SIP URI for which the SIP-PBX is authoritative can be delivered from the SSP to the SIP-PBX. However, implementations of this mechanism vary in details, leading to interoperability issues between SIP-PBXs and SSPs, and the need for equipment to support different variants. The task of this working group is to to standardize a multiple-AoR registration mechanism for SIP that can be widely deployed by service providers at large scale. The solution will support AoRs with E.164 addresses at a minimum, although support for other classes of AoRs may be included. The solution will utilize existing SIP mechanisms to the extent possible, although it is anticipated that small protocol extensions are likely to be required, and hence a standards track (rather than BCP) deliverable is expected. The solution will accommodate existing SIP extensions relating to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by ensuring that they are not precluded from use in the context of multiple AoR registrations. The solution will incorporate a compatibility mechanism to ensure a deterministic outcome when interworking with entities that do not support multiple AoR registration. The working group will coordinate with SIP Forum and other industry groups on requirements and will coordinate its work with other IETF working groups including DRINKS and SIPCORE. Goals and Milestones Dec 2009 Solicit solution-space drafts Jan 2010 Interim meeting Jan 2010 Adopt Working Group draft Feb 2010 First Working Group Last Call Mar 2010 Second Working Group Last Call Apr 2010 Multiple AoR Registration specification to IESG (PS) Jul 2010 Close or recharter working group _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From zhouboyj@gmail.com Mon Dec 28 00:37:55 2009 Return-Path: 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 A818C3A67EA for ; Mon, 28 Dec 2009 00:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 5WSGdh7El-Ib for ; Mon, 28 Dec 2009 00:37:54 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 9A2D13A67A5 for ; Mon, 28 Dec 2009 00:37:54 -0800 (PST) Received: by iwn33 with SMTP id 33so7105883iwn.29 for ; Mon, 28 Dec 2009 00:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=l6fVd9absd6K9J6DsE3HQHD9o9+P8rPVm90Iy6HJYGM=; b=GXg9tnhp5BirvIYo7BJgCAsbPLM4nfChyX0xQcUj7LZuOgZvkZaNPEzNw7PIGjH9nf 4A8hi1PmCmjxGjLB93dHtOsiP+WjjdQ1CzHkIF2R+l8JJT0XzV/4FbLkaTyIF1z4AFAN 1nXT+EYUWy4APDszy03FljFHuv+jH1JfHpu6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=luRuV4u+QYnWa2aRdQuF4kt/MqcYsfhWY4GDAPUTIfLSY5tRyrIgghP1fziv550cHO 45wDlFVJvjj8jEAKLc8xKUnDJ1Md9xvlMq9fp8TTZsBqwIzo+Wd6ZVrxxCWcE6rPW8KK ZDemNS/UrSSEqR3KmI6lkHDbJr0oK1PGpaMw0= MIME-Version: 1.0 Received: by 10.231.153.69 with SMTP id j5mr5594343ibw.33.1261989453114; Mon, 28 Dec 2009 00:37:33 -0800 (PST) In-Reply-To: <4B1F0203.5050600@gmail.com> References: <4B1F0203.5050600@gmail.com> Date: Mon, 28 Dec 2009 16:37:33 +0800 Message-ID: <36a593230912280037pbdfb828o26fabf12c9fdbca@mail.gmail.com> From: bo zhou To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001636d33c7c102cb7047bc5d1ed Cc: grobj@ietf.org Subject: Re: [grobj] Thoughts about the problem statement and requirement analysis X-BeenThere: grobj@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discuss Generic Referral Objects List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 08:37:55 -0000 --001636d33c7c102cb7047bc5d1ed Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, I think I can contribute to some parts of requirements, for example based on draft-bo-behave-ref-req-01.txt. How about you think? Regards, Bo On Wed, Dec 9, 2009 at 9:48 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > If we want to progress the referrals topic in Anaheim, we'll need to > have a draft problem statement well in advance, and even better, > some requirements analysis. So let me suggest a few points that > should be covered. Please comment: > > 1. Terminology > > At least, we need a clear definition of what a referral is. I would > expect that would lead to other terms that need definition. > > 2. Problems > > Addresses are no longer unique. > Addresses are no longer globally reachable. > Addresses are no longer all in the same format. > Hosts in a transaction may "see" different addresses and ports at each end. > Not all hosts (interfaces?) have FQDNs. > Not all FQDNs are globally visible. > Not all FQDNs are globally reachable by any of their addresses. > Visibility and reachability scopes overlap in an arbitrary way. > Addresses have finite lifetimes. > DNS records have finite lifetimes. > > 3. Requirements > > Carry information between hosts [application instances?] in generic > standard format. > Self-describing object, can be interpreted by any host. > Compact, efficient format for the normal case. > Carry multiple types of reference. > Carry scope and lifetime information as well as basic reference. > Extensible. > Carried over channel protected against error and forgery. > Optionally encrypted. > > -- > Regards > Brian Carpenter > > > _______________________________________________ > grobj mailing list > grobj@ietf.org > https://www.ietf.org/mailman/listinfo/grobj > -- Regards, Bo Zhou China Mobile --001636d33c7c102cb7047bc5d1ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Brian,
=A0
I think I can contribute to=A0some parts of requirements, for example = based on =A0draft-bo-behave-ref-req-01.txt.
How about you think?
=A0
Regards,
=A0
Bo

On Wed, Dec 9, 2009 at 9:48 AM, Brian E Carpente= r <bria= n.e.carpenter@gmail.com> wrote:
If we want to progress the refer= rals topic in Anaheim, we'll need to
have a draft problem statement = well in advance, and even better,
some requirements analysis. So let me suggest a few points that
should b= e covered. Please comment:

1. Terminology

At least, we need a= clear definition of what a referral is. I would
expect that would lead = to other terms that need definition.

2. Problems

Addresses are no longer unique.
Addresses are no = longer globally reachable.
Addresses are no longer all in the same forma= t.
Hosts in a transaction may "see" different addresses and po= rts at each end.
Not all hosts (interfaces?) have FQDNs.
Not all FQDNs are globally visib= le.
Not all FQDNs are globally reachable by any of their addresses.
V= isibility and reachability scopes overlap in an arbitrary way.
Addresses= have finite lifetimes.
DNS records have finite lifetimes.

3. Requirements

Carry info= rmation between hosts [application instances?] in generic standard format.<= br>Self-describing object, can be interpreted by any host.
Compact, effi= cient format for the normal case.
Carry multiple types of reference.
Carry scope and lifetime information = as well as basic reference.
Extensible.
Carried over channel protecte= d against error and forgery.
Optionally encrypted.

--
Regards<= br> =A0 Brian Carpenter


____________________________________________= ___
grobj mailing list
grobj@ietf.o= rg
https://www.ietf.org/mailman/listinfo/grobj



--
Regards,

Bo Zhou=
China Mobile
--001636d33c7c102cb7047bc5d1ed--