Thank you for commenting, Xiaohu. See my reply below. > > The Domain Name System identifies a node by its fully > > qualified domain name, which: > > - is topology�independent; > > - is stable, and has a defined lifetime; > > - is unambiguous; > > - is distinguishable (two for same object); > > - has hierarchical structure; > > - is generated, distributed, managed. > > > > But domain names are meaningful to humans, and therefore are > > network eccentric. > > > > On the other hand, Internet Protocol addresses are easily > > issuable, because they consist of numbers. > > > > So let us take a numeric fully qualified identifier. > > The innermost part is a number of a node, and any previous > > numbers denote authorities that have issued sublevel numbers. > > Sound interesting. By the way, taken the following items mentioned by Tony > in his previous email together into account, the identifiers should have > the same length as IPv6 address (or IPv4 address) and be capable of > asserting ownership. Fixed length has led to lack of scalability. Also, keeping identifier where locator resides is no decoupling of roles of the two assets. If we want significant change, we must take outstanding action. Solutions are variable length and protocol options. > - facilitate session�level referrals Definitely, identifier is going to be an important component of connection/session identification. What facilitation is needed? > - stable, at discretion of owner Within a numeric fully qualified identifier the final node number can be negotiated. Furthermore, a node can change its identification provider. Thus identifier can be stable/changeable at discretion of owner. > Xiaohu > > > We put a news that the identified sublevel knows locator of > > its parent. So acquaintance is mutual, and bidirectionally is > > to be used. > > > > Toni > > _______________________________________________ > > rrg mailing list > > rrg at irtf.org > > http://www.irtf.org/mailman/listinfo/rrg > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.