> > It is my (possibly mistaken) understanding that the nature of an > "endpoint" depends on the mode of operation. So why not use a more > concrete definition? The definition just gets more verbose with every iteration, the underlying problematic is that it tries to unify different concepts that are usually not unified ;)
Also, the reverse is true. The modes that may be used depend on the type of endpoint. I personally think the socket metaphor more or less fits: if you have a socket bound / connected to some global address, you just cannot do link-local multicast with it, though if you've bound your socket to a link-local address of an interface, you can probably use (link-local) mc as well as uc. What makes sense here of course depends on what you are trying to achieve, if your DNCP-based protocol is supposed to communicate to something a few (non-DNCP) hops away then using link-locals or allowing multicast mode is probably not sensible, for HNCP we don't need globally scoped unicast so for the sake of simplicity we define that endpoints must be mc-capable. > In all modes, an endpoint identifier is an arbitrary non-zero integer > that, at any given time, MUST uniquely identify a particular endpoint. > Endpoint identifiers SHOULD NOT be reused too soon after a given endpoint > ceases to exist, but if that happens, DNCP will reconverge after a short > period of chaos. Yeah, I guess the reuse-clause makes sense. > > (I don't think that DNCP requires endpoint identifiers to be non-zero, but > HNCP does, so you might as well make that a requirement of DNCP.) The terminology defines 0 to be reserved for internal purposes. Thanks, Steven _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
