Am 17. September 2015 17:22:55 GMT+01:00, schrieb Benoit Claise <bcla...@cisco.com>: >Markus, > >Instead of focusing on the specific questions/answers, the key message >is. >The applicability section doesn't answer my questions: when to (re-)use > >this protocol? > >Regards, Benoit >> On 17.9.2015, at 12.11, Benoit Claise <bcla...@cisco.com> wrote: >>> >---------------------------------------------------------------------- >>> DISCUSS: >>> >---------------------------------------------------------------------- >>> >>> Other ADs focused on the protocol specific points. So let me focus >on >>> something else. >>> The applicability section doesn't answer my questions: when to >(re-)use >>> this protocol? >>> Note that the write-up mentioned ANIMA. >>> >>> I see the protocol description: >>> >>> DNCP is designed to provide a way for each participating node to >>> publish a set of TLV (Type-Length-Value) tuples, and to provide a >>> shared and common view about the data published by every >currently or >>> recently bidirectionally reachable DNCP node in a network. >>> >>> I see, under the applicability section, under which conditions to >use >>> it. >>> Basically, suitable to exchange any TLV tuples, infrequently. >> This is the gist of it. Even more frequently is ok, but then you have >extra complexity without gaining from it. >> >> _That_ is what you have to determine if you want to use it; do you >want to synchronize a small set of TLV tuples, communicating >efficiently, across a set of nodes. >> >>> However, this applicability section doesn't tell me when to re-use >DNCP >>> (or define a profile for it). >>> What about the environment: home network versus LAN versus WAN? How >big >>> can the network be? >>> Does the technology matter? >>> Regarding transport, it's basically any transport, unicast or >multicast, >>> right? (DNCP can be used in networks where only unicast transport is >>> available. While DNCP uses the least amount of bandwidth when >multicast >>> is utilized) >> Guesses are correct, but given it is more of an algorithm than >concrete protocol, your questions are hard to respond in a generic way. >> >>> All devices in a DNCP network must be DNCP node? >> It is actually definition of DNCP network ; a set of DNCP nodes. >> >>> I have a DNCP network with profile 1, can I use the same DNCP >network >>> with profile 2? >> If the profiles’ transport details match and use a shared IANA TLV >space, then yes. >> >>> IANA and enterprise specific TLVs? >> I am not sure what you mean by this; ultimately actually used TLVs >are matter of (DNCP profile specific) IANA sub-registry, which should >reserve the space. While DNCP itself reserves some space for >DNCP-specific extensions (so far considered fragmentation, delta >synchronization, authentication/confidentiality of multicast traffic >using PSKs, and few other things), and leaves most of space open (for >e.g. to be used as bits later on), the rest is up to profile. >> >>> UDP is fine as a transport? >> There is another DISCUSS on this, I will reply to it there. >> >>> What if I know my topology already (I see later: "may use multicast >for >>> Trickle-based shared state dissemination and topology discovery") >>> etc. >> You can define a protocol that is solely TCP unicast based, for >example, and make it’s definition of peer liveliness depend only on the >TCP connections +- knowledge of topology graph changing. >> >> (This assuming you know which nodes need to communicate with each >other.) >> >>> Just reading the intro and the applicability, I scratched my head: >it's >>> so generic, should I even consider it for ANIMA? >> Funny, I get the opposite impression reading ANIMA mailing list, as I >wonder if it is too generic for DNCP. >> >> E.g. what if someone wants to share a DVD image to upgrade their >routers using the protocol? DNCP is _not_ the way. URL + hash of >content, or magnet link, perhaps, but not the image. >> >>> A few paragraphs, somewhere in the document, would solve my DISCUSS: >>> - this protocol should be used to exchange the following type of >data >>> ... >> See edit of first sentence of introduction in [1]. Still work in >progress, but emphasizing that a) set of TLVs published by a node is >small, and b) it has hard cap of 64kb. >> >>> - it's envisioned that this generic state synchronization protocol >will >>> be used in the following environments … >>> - potential DNCP-based protocols include … >> I do not really see where to stick these or what the exact content >would be; >> >> ‘anywhere you can use _a_ transport protocol’, ’to synchronize stuff >(home automation? configuration? cache synchronization? routing? you >name it, this can do it, although not necessarily well, and all have >_already been done_ although not necessarily documented in the IETF)’ >> >>> >---------------------------------------------------------------------- >>> COMMENT: >>> >---------------------------------------------------------------------- >>> >>> - I would agree with Alvaro, when he wrote: "In general, I found the >text >>> not straight forward or easy to understand." Potentially due to the >>> structure. >> Structure has been rewritten more than once due to various reviews >too. >> >>> - I hope that a document about manageability considerations (see >>> https://tools.ietf.org/html/rfc5706#appendix-A) will follow. >> Hm, I see value of having one for particular DNCP-based protocols but >not really DNCP itself. >> >>> - As reported by Victor, part of his OPS DIR review: >>> Found In Nits: >>> >>> >(https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-homenet-dncp-09.txt) >>> >>> - Use of lower case not with SHOULD statement (see Paragraph 2, >>> Section 4.5) >> Fixed in [1]. >> >>> - Flagged spacing items (Lines 197, 252, 256 and 260) >> In terminology. Fixing if someone tells me how, as I think it is just >idnits not understanding the extra spaces between (multi-line) term >being explained and it’s description. >> >>> Section 3: Overview >>> >>> paragraph 2: their addresses may be manually configured or they >may >>> >>> be found by some other means defined in a later specification >>> >>> ** This text is not quite clear. Is it the author’s intention >that >>> the reader assume the other means will be part of a specific >DNCP >>> profile specification, a revision of the DNCP document or a >>> different type of document.? *** >> Addressed in [1]. The text is not actually clear at all, as it should >REALLY say that that can be specified in a particular DNCP profile. >Rewrote and gave an example. Is it better? >> >>> Section 4.2: Data Transport >>> >>> Paragraph 4 / Part “Multicast+Unicast” >>> >>> <old> It is used to send Network State TLVs every now and >>> >>> then, as specified in Section 4.3 >>> >>> <suggested> It is used to send Network State TLVs >>> periodically, as specified in Section 4.3 >>> >>> <reason> Avoids using an idiom to express sending frequency >>> in text. >> Thanks, fixed. [1] >> >>> Section 8.1 Pre-Shared Kay Trust Method >>> >>> ** Would it be within the DNCP document to discuss how PSKs are >>> stored (as to not be externally accessed) or would it be to the >>> profile to defined that level? *** >> That is entirely implementation matter; I do not think any other >protocols that employ DTLS or TLS documents specify how that is done >either. >> >> (Given counter-example, I do not mind copying text.) >> >> Cheers, >> >> -Markus >> >> [1] >https://github.com/fingon/ietf-drafts/commit/6ba8c1b73e49d64667ae1dabc1113ce5c6673e34 >- to be published as dncp-10 at some point once we have DISCUSSes >addressed. >> >> . >> > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet
Hello Benoit, in addition to the new appendix in -10 we have now staged the following text for the next Revision https://github.com/fingon/ietf-drafts/commit/fa712e2a2935fe3f4b6383582913ca6f4bc9e9f0 Does this address your issue or do you think we should add further applicability explanations. Thanks, Steven -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet