Subject: [grobj] Thoughts about the problem statement and requirement analysis

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Dec 2009 14:48:51 +1300

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: Sheng Jiang <[email-masked]>
Date: Wed, 09 Dec 2009 10:00:59 +0800

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian E Carpenter
> Sent: Wednesday, December 09, 2009 9:49 AM
> To: [email-masked]
> 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
> 
> _______________________________________________
> grobj mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grobj

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 08:16:41 +0100

Dear Brian, all,

Please see in line.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Brian E Carpenter
Envoyé : mercredi 9 décembre 2009 02:49
À : [email-masked]
Objet : [grobj] Thoughts about the problem statement and requirement analysis

1. Terminology

2. Problems

Addresses are no longer unique.
Med: I guess you mean:
- Public IP addresses may not be used as "identifier" 
- The same IP address may be assigned to several customers/devices (e.g., overalpping private IPv4 @ zones, shared IPv4 address behind a NAT)

Med: Do you mean:
- Not all IP addresses are globally reachable

Med: Are you referring to IPv4/IPv6?

Med: I guess you mean: "Not all resources identified with an FQDN are globally reachable by any of their addresses."

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 address represents an IPv4 host. These addresses should not be interpreted as native IPv6 address. 
- 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 does 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

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 remote party to decide) 

Cheers,
Med
*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: bo zhou <[email-masked]>
Date: Thu, 10 Dec 2009 15:57:14 +0800

Hi Sheng,

How the host know the path is the best?

-- 
Regards,

Bo Zhou
China Mobile

---

From: Scott Brim <[email-masked]>
Date: Thu, 10 Dec 2009 07:34:19 -0500

> 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: "Ford, Alan" <[email-masked]>
Date: Thu, 10 Dec 2009 15:52:23 -0000

Hi Brian, all,

Seems like a good starting list.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Brian E Carpenter
> Sent: 09 December 2009 01:49
> To: [email-masked]
requirementanalysis
> 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."

> Addresses are no longer all in the same format.

_May_ no longer be!

> 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
> 
> Carry information between hosts [application instances?] in generic
standard
> format.

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: Sheng Jiang <[email-masked]>
Date: Fri, 11 Dec 2009 09:27:45 +0800

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

> From: Scott Brim [mailto:[email-masked]] 
> Sent: Thursday, December 10, 2009 8:34 PM
> To: bo zhou
> Cc: Sheng Jiang; [email-masked]
> Subject: Re: [grobj] Thoughts about the problem statement and 
> requirement analysis
> 
> 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: Dong Zhang <[email-masked]>
Date: Fri, 11 Dec 2009 09:44:26 +0800

Hi,

Sheng Jiang 2009-12-11 Wrote:
...
>enough information for the receiver to make the right decision.
If so, is it necessary to define the behavior of the receiver? I mean how 
the reveiver uses the referral information to make the decision. I guess 
rfc3484 may not be enough.

Thank you.
>> available is an IP address.)

------------------				 
Dong Zhang
Huawei Symantec Technologies Co., Ltd
TEL：86-10-62721287
FAX：86-10-62721347
ADDRESS：3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi, Haidian Dist., Beijing, China. 100085 

***********************************************************************************
This email and its attachments contain confidential information from HUAWEI SYMANTEC, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
**********************************************************************************
2009-12-11

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 11 Dec 2009 10:50:06 +0800

> >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.
> If so, is it necessary to define the behavior of the 
> receiver? I mean how the reveiver uses the referral 
> information to make the decision. I guess

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, 
> 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
> >
> information, and 
> >> leave path determination to the referral receiver.  (In some cases 
> >> the only identification information available is an IP address.)
> >
> ADDRESS：3rd Floor,Section D, Keshi Building, No.28, Xinxi 
> Rd., Shangdi, Haidian Dist., Beijing, China. 100085 
> 
> This email and its attachments contain confidential 
> information from HUAWEI SYMANTEC, which is intended only for 
> the person or entity whose address is listed above. Any use 
> of the information contained herein in any way (including, 
> but not limited to, total or partial disclosure, 
> reproduction, or dissemination) by persons other than the 
> intended recipient(s) is prohibited. If you receive this 
> e-mail in error, please notify the sender by phone or email 
> immediately and delete it!

---

From: Dong Zhang <[email-masked]>
Date: Fri, 11 Dec 2009 11:27:14 +0800

Hi,

>However, we may produce a principle or recomendation document regarding it.
Agree. An informational document on recommendation which is accordant with 
address selection might be useful.

------------------				 
Dong Zhang

---

From: bo zhou <[email-masked]>
Date: Mon, 28 Dec 2009 16:37:33 +0800

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 <
[email-masked]> wrote:

> standard format.

-- 
Regards,

Bo Zhou
China Mobile