Re: Inverse queries on EID; autoconfiguration

[Paul Francis--formerly Tsuchiya <[e-mail]>]

Sorry I'm late on answering this.  Somehow I overlooked it......

>  
>  Ok, I've read the new near-term document, and the new DNS document,
>  and I still can't figure out how you can efficiently (read: at least
>  as efficiently as IPv4) do inverse mapping in the DNS.  Although this
>  is practically useless with respect to security, it is still extremely
>  useful for management(*).  Since the near-term document states that 802
>  numbers are to be used, how would this work?  (Should I make a list of
>  all my 802 numbers and mail it to Paul Francis?)

Clearly a "flat" ID can't be used as effeciently as a hierarchical one
for inverse lookups.  My hope is that the Pip address would nearly 
always be carried around with a pip id and therefore inverse lookups
could usually be done on pip address.

>  
>  I think the answer is that it wouldn't work.  Furthermore, I don't see
>  that Paul's stated concerns about the effect of organizational EIDs on
>  autoconfiguration are really borne out by reality.  Here's my model of
>  autoconfiguration, which is a bit different from Paul's...

I agree that the autoconfiguration of hierarchical IDs isn't that bad, but
it can be avoided altogether if the IDs are flat.  Also, with flat IDs
you don't have to worry about changing them when the host joins a new
organization.  Also, if the ID has organizational significance, what is
the meaning of a mobile host temporarily moving to another
organization?  Does it get a new ID?  Of course it shouldn't, but what
if the organization is filtering based on ID?  The hierarchical ID
introduces a number of questions that I didn't find easy answers for.....

>  
>  OBTW, I think we really need a link-level binding document to go along
>  with the Near-Term document.  Reading through some of the
>  sections---especially the multicast bits---I began to wonder how this
>  is going to actually be implemented over an Ethernet...  (Is somebody
>  still going to re-write things to use an ESIS-like model for the
>  final-hop address resulution?)

Well, it is still not going to be me, but I'm open to an ESIS model that
is virtually identical to the existing one......

>  
>  Another question.  The current spec looks like the transit part
>  includes one or more FTIFs.  Since two systems in the same area/LAN
>  don't need any of this, shouldn't it be more like zero or more FTIFs?

You're right.....

PF