Subject: Re: [grobj] BoF in coming IETF 78

From: Sheng Jiang <[email-masked]>
Date: Mon, 21 Jun 2010 09:38:05 +0800

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:[email-masked]] 
> Sent: Monday, May 17, 2010 8:15 PM
> To: Sheng Jiang
> Cc: [email-masked]
> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/grobj
> >