Hi, > 1. Changed DNCP "messages" into series of TLV streams, allowing optimized > round-trip saving synchronization.
So, I have a couple of questions about the new text: A DNCP message in and of itself is just an abstraction; when using reliable stream transport, the whole stream of TLVs can be considered a single message, with new TLVs becoming gradually available once they have been fully received. On datagram transport, each individual datagram is a separate message. In order to facilitate fast comparing of local state with that in a received update, TLVs in every container TLV MUST be placed in ascending order based on the binary comparison of both TLV header and value. Firstly how do I know when I have received the end of "the whole stream of TLVs"? It's presumably not infinite, but with no clear notion of a "message" how do I know when to stop processing? Secondly, please define the phrase "container TLV". It's quite unclear to me whether your model is simply a sequence of separate TLVs or whether TLVs are encapsulated, i.e. does the length field of the first TLV include the size of some embedded TLVs? Of course I could go and read the code to find out what you really mean, but this should really be specified at the beginning of section 7 "Type-Length-Value Objects". > 2. Added fragmentation extension for bigger node data and for chunking in > absence of reliable L2 and L3 fragmentation. Hmm. For GDNP we are thinking of simply saying "use a conservative MTU and TLS" to avoid fragmentation. Regards Brian Carpenter _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
