> Recapitulating, I see basically two potential issues where we do not yet have
> resolution:
>
> oVersioning
> oAddress/Endpoint terminology
>
We have changed the IANA section like this now:
<t>11-31: Free - policy of 'standards action' should be used</t>
<t>32-511: Reserved for per-DNCP profile use</t>
<t>512-767: Free - policy of 'standards action' should be used</t>
<t>768-1023: Private use</t>
<t>1024-65535: Reserved for future protocol evolution (for example, DNCP
version 2)</t>
This gives us 6-bits to play with later on (e.g. versioning, flags, etc.) and
also a broader pre-defined range for DNCP and per-profile TLVs.
We also did another rewrite of address and endpoint to make them less verbose.
The following is
what at least passed our "internal review" ;)
<c>Address</c>
<c>an identifier used as source or destination of a DNCP message flow,
e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport.</c>
<c /><c />
<c>Endpoint</c>
<c>a locally configured termination point for (potential or established)
DNCP message flows. An endpoint is the source and destination for separate
unicast message flows to individual nodes and optionally for multicast
messages to all thereby reachable nodes (e.g., for node discovery).
Endpoints are usually in one of the transport modes specified in <xref
target="dt" />.
Besides that all instances of "broadcast" should be gone now and have been,
replaced by "multicast" or "multicast enabled" or similar since that seemed to
be more accurate in most cases anyway.
Please let us know what you think ;)
Cheers,
Steven
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
