Excerpts from Tony Li on Wed, Apr 22, 2009 08:43:00AM -0700: > > Hi Scott, > >> Oh. Then I think we actually agree on procedure, but let's make it >> explicit: >> >> The goal is to figure out which classes of solutions are >> appropriate, and one input to that is to look at the implications >> each solution class has on properties of identifiers. > > Agree. > >> Some of us have been saying that you can't do "properties of >> identifiers" in general, you have to talk about which kinds of >> identifiers, in which context. I guess you agree. If so, sorry, I >> hadn't understood. > > No, I think it's reasonable to talk about the classes of solutions > and the reasonable properties of the (host, interface, stack, ...) > identifier that is bound to the locator within each class.
This demonstrates my point: You are assuming the identifier of interest is one that is "bound to the locator", i.e. the thing that just the locator gets you to is what you want to describe in this exercise. In this case one could just as easily envision having identifiers of interest name things at a finer level of granularity, where a locator gets you to a particular device (possibly virtual) but initial packets must include both locator and identifier, so that when the packet arrives at the device named by the locator, the device can figure out which particular communication endpoint (named by the identifier) you want to talk to. The "identifier that is bound to the locator" could name the device but would not be interesting to us and would not be used in normal communications, only by device management. I'm happy to look at properties for identifiers that are "bound to locators" but let's not assume that each class has such things. Also some classes do not say anything about endpoint identifiers at all. >> Yes, local identifiers are worthy of discussion. > > So I think that local identifiers are acceptable, but solutions > should always also provide global identifiers. The decision of > which to use should be left to the end station/stack/user. > >> Again, I would like the process to be explicit, otherwise we will >> probably ramble around and it will be hard to agree on whether we >> have reached any agreements. Do you want to start specifically >> with the class of solutions that includes ILNP, look specifically >> at "host" identifiers, and look at >> implications/possibilities/requirements? That would be fine with >> me. > > Again, I don't want this to devolve into another partisan bickering > match. I would much rather talk about general classes (ala Bill's > different strategies). Well, let's try it but we'll have to watch out for implicit assumptions. ... and I beg people to come up with different names than "B.3". I'll never remember the mappings from the outline headings to what they actually describe. It's like referring to a paper by its footnote reference, e.g. [17]. Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
