On 29.7.2015, at 15.01, Pierre Pfister <pie...@darou.fr> wrote: > Hello Markus, > > I could not find-out what french-guy-living-in-Paris you are referring to, so > I wanted to make sure I at least have the 3rd position. ;)
You probably do. It is clearly a conspiracy. > I think the complexity about the Endpoint definition mostly comes from the > fact that a DNCP Endpoint is half-defined by configuration and half-defined > by the profile. Some parameters such as trickle parameters are defined as > Profile parameters, while they should, IMHO, be defined "per-endpoint". > > This may require some work but I think the document should specify on one > side what are the global parameters that must be shared by all participating > nodes (the global profile), and on another side what are the different > endpoint parameters that must (or sometimes not, as Trickle parameters) be > shared by all DNCP nodes on a given ‘’’’’link’’’’’ (with lots of ‘’’), i.e., > the endpoint profile, and allow them to exchange packets and establish a > durable neighboring relationship. > > With that approach it looks to me that a Endpoint could be defined this way > (Probably not best wording, but you will get the idea): > > Endpoint: Set of rules and parameters associated with a unique Endpoint > identifier which: > - Determines how to send DNCP packets toward other DNCP nodes. > - Determines how to establish, keep and teardown neighboring > relationships between two DNCP nodes. > - Classifies a received DNCP packet as received on a given Endpoint (If > a received packet can’t be associated with any Endpoint, it MUST be ignored). > > Now, adopting such an approach in the document may have significant impact > over its organization, but at least it would help separate what is globally > unique from what is local to neighboring relationships. I think this is overriding (or perhaps compressing) terminology too much; I believe you are describing an instance of a ’endpoint profile’ (and how one maps to endpoint identifiers), which does not describe what _is being identified_, i.e. the endpoint itself. At least to me, your description of ‘endpoint’ is actually less clear than Steven’s (in the current dncp-08 text), and I find both unclear. Given a protocol that uses actually two types of transport (e.g. someday-updated SHSP draft will have both [some scope] unicast-only and link-local unicast+multicast endpoints - I have some of the code but not the updated spec yet), it gets even more murky. While the profile may specify that this is the transport, how it maps to the particular endpoint identifiers (and what those identifiers identify) becomes rather painful. Not to mention if we want to provide per-link type handling guidance on Trickle k value.. sigh. :p > On a different topic, I think reserving 32 TLV types to DNCP is far from > being enough. > If DNCP is successful, it may be used by many different profiles. There could > be a need to extend DNCP in order to improve all profiles at once. Limiting > DNCP extensions to only 21 new TLVs is unnecessary and would make that > process harder. Reserving more TLVs would be virtually free and help in the > future. > I guess that comment joins Thomas’ comment about version numbers, with which > I agree (that we should add one). It’s not because DNCP is not a protocol > that we should not think about how it could be improved and extended such > that all already-defined profiles profit from the improvement. Sure it would > not be *impossible* to do it with the current document. But it costs nothing > to make it easier. I guess I have to discuss this with Steven; the original idea was to essentially leave 8 bits in the type unused for e.g. bit vector use at some point, when I chose the 16-bit T size, but it did not make it to the DNCP draft. Current texts we have are wrong at any rate, as 256+ are specified as available _both_ in DNCP and HNCP registry (based on the current .xml texts we have for not-yet-published dncp-09 and hncp-08), and that is not optimal situation either if there is a conflict. Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
