Endpoint Identifier BOF (EID) Reported by Robert Elz/University of Melbourne A BOF was held at the Toronto IETF to consider the concept of endpoint identifiers. The meeting was nominally chaired by Robert Elz. Frank Solensky took notes for the minutes and Dave Clark also supplied his notes of the meeting. Before the BOF, a proposed agenda was sent to the Big-Internet list (subscription requests should be sent to Big-Internet-Request@munnari.OZ.AU, which formed the starting point of the meeting. The agenda was: o Administrative tedium o EIDs - definition o Terminology - what name should these things have o Uses - certain, likely and possible o Structure - including or excluding manufacturer provided tags (e.g., MAC addresses) - structure for directory lookups o Allocation (including autoconfiguration) o Is a working group required o Draft a charter if so o Are EIDs useful? Do we need them? This agenda fell by the wayside quite quickly after the administrivia was dealt with. The meeting opened with Noel Chiappa, as the inventor of the concept, giving his definition of an EID, which amounted to the name of an endpoint---being something that can form one end of a connection, which might be a host, but need not be. The term ``fate sharing region'' applies. Discussion on exactly what this meant followed, without making any significant progress. It was suggested that a better approach might be to construct a list of the uses to which the attendees believed that EIDs might be put, with the aim that from this list the essence of what is required might be distilled. The list constructed contained: o Realign existing end-to-end context and transport connections o Maintain connections during fail-over or instability o Identify a ``security context,'' even when no connection present o ``Index'' into database o Transition abstraction o Provider-independent identifier of host interface o Re-acquire path (underlying connection) after service disruption o Use, e.g., within a MIB, for referring to an end-point o Labelling a connection (independent of movement) o Cluster aliasing o Better software fastpath o Avoid semantic overload o Accounting o Transport (and above) completely independent of network layer o Selectors shorter (and still globally unique) It should be pointed out that this list does not represent the opinions of any particular individual, nor of the meeting itself, but was merely compiled from suggestions from the floor. Discussion of these points, as they were added, continued for some time. Many points in the list were felt to be merely special cases of other points, others were felt to simply be inappropriate. As this discussion was also getting nowhere particularly useful, a third approach was tried. This comprised building a list of the distinguishing attributes that may apply to EIDs, and asking particular people to indicate which of the attributes applied to their model of EIDs. The attributes were 1. Are EIDs short (generally perceived as no longer than about 64 bits)? 2. Are EIDs binary (as opposed to printable text)? 3. Are EIDs globally unique? 4. Do EIDs exist at the network level? 5. Do EIDs exist in the transport layer? 6. Are EIDs used to identify transport connections? 7. Are EIDs used as a key into any kind of database? 8. Do EIDs have any internal (administrative) structure? It was assumed that EIDs have no topological or geographical meaning. 9. Are EIDs present in every packet ? Without attribution, the models suggested were: model 1 2 3 4 5 6 7 8 9 A ? ? Y Y? N Y N N? ? B ? Y Y Y? N Y Y Y ? C N N Y N ? Y Y Y N D Y Y Y N Y Y Y Y Y? E Y Y Y Y Y Y Y Y Y F Y Y Y Y N Y Y Y? Y G Y Y N Y N Y N N ? H1 Y Y Y N Y ? Y Y N H2 N Y Y N Y ? N N N J Y Y Y? N Y Y Y Y Y K Y Y Y Y N Y Y Y Y For comparison, treating IPv4 addresses as EIDs, and noting that they have topological significance, the model for IPv4 was constructed as: IPv4 Y Y Y Y N Y Y Y Y In the above, ``Y'' indicates a ``yes'' answer to the corresponding question, ``N'' indicates ``no,'' ``?'' one of ``don't know'' or ``uncertain,'' or ``either way would work,'' or ``sometimes,'' or similar. ``Y?'' indicates ``probably yes,'' or ``something like that,'' ``N?'' probably no. Respondent H believed that two different forms of EIDs were required, with different attributes, the two sets listed as H1 and H2. This list was constructed comparatively quickly, as no discussion of the models was entertained. Instead their proponents, or some of them, will write a short submission supporting their view of what an EID should be like, and why, and submit it to the Big-Internet mailing list for public review. Some of those may become Internet-Drafts. It was decided that a new mailing list was not warranted immediately, and that Big-Internet@munnari.OZ.AU will continue to be used, however a specific list may be established at some later time. The submissions on this topic to the list will be considered, and from those, if it seems necessary and useful, a charter for a working group will be created and submitted. It was noted however that IPv6 (or IP6, or IPng as desired) is currently planned to be to Proposed Standard stage by the time of the next IETF, if EIDs are to play any part in IPv6 the work needs to be done well before then.