Subject: Re: [rrg] Constraints due to the need for widespread voluntary adoption

From: [email-masked] (Noel Chiappa)
Date: Thu, 3 Dec 2009 18:23:31 -0500 (EST)

> From: Dae Young KIM <[email-masked]>

    > to me, ID = IP address = node address)

We tend not to use the term 'address', because it does not have a clear
definition that everyone agrees on.

    > DNS names -> ID (here to me, ID = IP address = node address)

Since "address" to most people does mean a 'name' (in the generic sense of
"name") with some location information in it, I am going to assume that your
"ID" means a name which is location dependent.

That means the "ID" will have to change if the host is attached to the
network in a different place; and the experience of the past decade or two is
that this is not acceptable to the users. They want something _in addition_
to DNS names which does not have to change when the host is attached in a new
location.

    > ID -> locator; this is not the job of Internet layer. In this context,
    > the locator here is to me the address of the underlying layer,

To most of us, 'locator' means a 'name' with global semantics; i.e. it can
name a location anywhere in the internetwork, and it can be understood
anywhere in the network, and things everwhere will interpret a given locator
to mean the same location.

Redefining terms to your own private definition is not very useful for clear
communication. Terms that mean what you seem to mean here are things like
'MAC address' or 'physical network address'.

    > To me, they're one and the same thing. There's no routing without
    > identifying your partner. There's no identifying your partner without
    > routing to, i.e., without locating it. The two are one and the same.

Ah, no. I am "J. Noel Chiappa" no matter where I am, and you can identify
me without knowing either i) where I am, or ii) how to get there.

You might be interested in reading IEN-19, "Inter-Network Naming, Addressing,
and Routing"; although it is very old (and thus somewhat out of date), it is
still full of useful insight on these ideas. RFC-1498, "On the Naming and
Binding of Network Destinations", is also very important.

	Noel

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 09:20:35 +0900

> "ID" means a name which is location dependent.

No, my 'ID' means a name which is location 'independent'.

> to DNS names which does not have to change when the host is attached in a

No, in one preferred model, ID does not change along the networks. If I'd
try to stick to the 'usual usage of terms' in this community, only the
'locator' changes according to the network which they attach to.

> to mean the same location.

Here, we're clearly apart. To me, locator need not be globally unique. It
can change across networks. Each 'enterprise network' may use its own local
locator name space. At each network boundaries through routing, you just
change to a new locator in the new (transit or stub) network. All along,
however, your ID will remain constant.

> communication.

OK, agree. Will refrain from doing that as long as I'm discussing in this
community.

> Terms that mean what you seem to mean here are things like

Yes. In fact, now that you have an ID, there's no need to have something
like 'PoA' address separately in the same layer. You just rely on your
underlying layer to deliver your packet through it's underlying layer to my
next hop in my routing table. So, all I need is

     - mapping from my (source) ID to the subnetwork address (or MAC addr or
physical addr according to your examples)

     - and also mapping from the ID of my next hop in my 'internet layer'
routing table to the subnetwork address (MAC or physical address) of that
very next hop

     - at reception of my packet, my next hop (router) will look into the ID
of my intended final destination ID and decide to which next hop (node or
router) the packet has to be relayed

      - and the whole process above repeats.

> me without knowing either i) where I am, or ii) how to get there.

OK, you're talking about DNS name(or URI?). Noel is the 'DNS' name which, of
course, is unique independently of whatsovever.

Then, we said DNS name should be mapped to ID. (Noel to 234 Madison Ave.).
There's no routing (or better said locating?) without identifying your
house. There's no identifying your house without successfully locating it.

> Binding of Network Destinations", is also very important.

Thank you for the reference. Only that who wrote it, and whether I buy that
concept.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 09:33:06 +0900

Put it in another way using the terms in this community:

    - Do routing with ID.
    - Do away with Locator. It's redundant. It should belong to the layer
below. And locator's change in every segment of networks.

On Fri, Dec 4, 2009 at 9:20 AM, Dae Young KIM <[email-masked]> wrote:

>      - mapping from my (source) ID to the subnetwork address (or MAC addr
> or physical addr according to your examples)
>
>      - at reception of my packet, my next hop (router) will look into the
> ID of my intended final destination ID and decide to which next hop (node or
> OK, you're talking about DNS name(or URI?). Noel is the 'DNS' name which,
> of course, is unique independently of whatsovever.
>
> http://cnu.kr/~dykim <http://cnu.kr/%7Edykim>
>

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Florin Coras <[email-masked]>
Date: Fri, 04 Dec 2009 02:13:51 +0100

Hello,

> On Fri, Dec 4, 2009 at 9:20 AM, Dae Young KIM <[email-masked]> wrote:
Well, then, speaking in IEN-19 terminology your doing name/address
separation through DNS, no? Or, considering the previous example you are
using DNS for mapping between the name (Noel) and what you call ID (the
mentioned address). I now suppose that in order to provide mobility the
name (Noel) will be used in sockets instead of what you call ID. If this
is the case the first foreseeable problem is that you break all the
current applications.

Also I think that "locator" would better describe what you call an "ID"
for the simple reason that it indicates a fixed destination in the
network ( in your example was the address of a house).
>> No, my 'ID' means a name which is location 'independent'.
Correct me if I'm wrong but your example with the mail considered the
address of the house as the ID so how can it be location independent?
>> house. There's no identifying your house without successfully locating it.
I'm inclined to believing that your statement here agrees with my
assertion from above

Regards,
Florin
> ------------------------------------------------------------------------
>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 10:44:04 +0900

> is the case the first foreseeable problem is that you break all the

No, I use ID. Mobile devices possess unchanging ID.

> network ( in your example was the address of a house).

Well, I think I'm from a total foreign world than the community here, and
also maybe not consistent in my own statement in compromising with
terminology.

Talking about DNS. In one model of mine, ID is also globally unique. (note:
in further elaboration if situations permit, I can argue that there's no
architectural reason why ID should be globally unique. It can also be local.
But, not to scare or annoy people too much which I've already have, I'll
stick to my model #1 where ID is globally unique).

So, there's one-to-one correspondence between the name (URI) given to DNS
and the ID it returns. Redundant. However, using ling string text of DNS
names is not a convenient way of carrying all along. You use ID instead.

Or seen in another way, I'm looking for an application or a content by the
DNS name. But that App or content should reside in some tengable(?) box to
reach to. So, the address (or ID) of that tangible box (or the abstract
stack construct or the host or the node..) is the ID that I use in my
communication. Once I get their with my ID, then a local pointers (like
port-id, socket ect.) will point me exactly to the App entity or content I'm
trying to reach.

(Was then my analogy of Noel vs name and ID vs street address already a
wrong one..?)

-- 
Regards,

DY
http://cnu.kr/~dykim