Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Am 17. September 2015 17:22:55 GMT+01:00, schrieb Benoit Claise : >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 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
Re: [homenet] Benoit Claise's Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
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. PS: Sorry for the resend i screwed up my mail client earlier. Thanks, Steven Am 17. September 2015 17:22:55 GMT+01:00, schrieb Benoit Claise : >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 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?
[homenet] Last call for signatures to the FCC on the wifi lockdown issue
The CeroWrt project's letter to the FCC on how to better manage the software on wifi and home routers vs some proposed regulations is now in last call for signatures. The final draft of our FCC submittal is here: https://docs.google.com/document/d/15QhugvMlIOjH7iCxFdqJFhhwT6_nmYT2j8xAscCImX0/edit?usp=sharing The principal signers (Dave Taht and Vint Cerf), are joined by many network researchers, open source developers, and dozens of developers of aftermarket firmware projects like OpenWrt. Prominent signers currently include: Jonathan Corbet, David P. Reed, Dan Geer, Jim Gettys, Phil Karn, Felix nFietkau, Corinna "Elektra" Aichele, Randell Jesup, Eric S. Raymond, Simon Kelly, Andreas Petlund, Sascha Meinrath, Joe Touch, Dave Farber, Nick Feamster, Paul Vixie, Bob Frankston, Eric Schultz, Brahm Cohen, Jeff Osborn, Harald Alvestrand, and James Woodyatt. If you would like to join our call for substituting sane software engineering practices over misguided regulations, the window for adding your signature to the letter closes at 11:59AM ET, today, Friday, 2015-10-08. Sign via webform here: http://goo.gl/forms/WCF7kPcFl9 We are at approximately 170 signatures as I write. For more details on the controversy we are attempting to address, or to submit your own filing to the FCC see: https://libreplanet.org/wiki/Save_WiFi https://www.dearfcc.org/ Sincerely, Dave Täht CeroWrt Project Architect Tel: +46547001161 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Last Call: (Home Networking Control Protocol) to Proposed Standard
The IESG has received a request from the Home Networking WG (homenet) to consider the following document: - 'Home Networking Control Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-10-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol which supports routing based on both source and destination address. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ballot/ No IPR declarations have been submitted directly on this I-D. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)
Hi Steven, On Thu, Oct 8, 2015 at 2:19 AM, Steven Barth wrote: > Hello Alia, > > unfortunately we haven't gotten any response from you wrt. your DISCUSS on > DNCP yet. > We would really like to address the issues you have raised, but would need > some feedback > from your side to do so. Please note that we have pushed a new revision in > the meantime > and tried to clear off the remaining issues in our mail from September > 17th which I have > quoted below again. > I was waiting for the updated version and have now read it. I did find the changes and extra text to be good improvements. What is missing is frequently absolute clarity on how to do various parts. If you want, I can take a pass at some more serious restructuring and writing some clarifications - but I will only do that if you feel it is helpful. > Please let us know how to proceed on the matter to resolve your DISCUSS. > > > > Thanks, > > > Steven > > > > On 17.09.2015 17:10, Steven Barth wrote: > > Hello Alia, > > > > > > please find replies inline. > > > > > > Cheers, > > > > Steven & Markus > > > > > >> -- > >> DISCUSS: > >> -- > >> > >> First, I have a number of specific comments. Some of these are > hazards > >> to technical interoperability; I've tried > >> to include those in my discuss - but the general point is that it is > very > >> hard to tell a number of details because the > >> structure is assumed. Having read this document, I do not think that I > >> could properly implement DNCP from scratch. > > > > Please note that an independent DNCP (or more specifically an HNCP) > > implementation has been successfully developed based on > > an earlier version of this draft and has been shown to be > > interoperable with the reference implementation of the draft authors. > > We used the implementer’s feedback afterwards to further refine the draft > > to avoid possible ambiguities. > I understand that but there were still a number of gaps. For instance, I see nothing that describes how to compute the network state hash. I would expect a section like: "4.1.1 Computing Node Data Hash To compute the data hash associated with a node, the TLVs are ordered first based on the lowest type and then numerically increasing based on the values. This creates a bit string that is input to the Hash Function specified by the DNCP application profile. The length of the output hash is dependent upon the DNCP application profile. The following gives an example using the fictitious profile given in Appendix C. . A Node Data Hash may be computed for a locally stored node or for a Node TLV that is received in the following cases 4.1.2 Computing a Network State Hash To compute the Local Network State Hash, only the nodes which are bidirectionally connected to the local node can be used. These nodes are determined by the algorithm given in Section 4.6 which determines the current network topology graph from the local computing node's perspective. As discussed in Section 4.6, any nodes which are not reachable may be removed from the local node's knowledge; at a minimum, such nodes MUST NOT be used in computing the Local Network State Hash. To compute a Received Network State Hash, the local node uses the information from the associated received Node TLVs. If Node Data is included in a Node TLV, then an updated Node Data Hash MUST be computed as described in Sec 4.1.1. Otherwise, the Node Data Hash contained in the Node TLV MUST be used. . It is assumed that all nodes included in the Network State TLV are considered to be bidirectionally reachable by the originating node. To compute either a Local or a Received network state hash, the nodes are ordered based upon their node identifiers in increasing numerical order. Each node is checked to see that it has an updated Node Data Hash. A node is considered to have an updated Node Data Hash if If a node doesn't have an updated Node Data Hash, then that must first be computed before the Network State Hash can be computed. Finally, the bit string created by taking the Node Data Hash of each node in the specified ordered is input to the Hash Function specified by the DNCP application profile. The length of the output hash is dependent upon the DNCP application profile. The following is an example using the fictitious profile given in Appendix C. ... The Local Network State Hash is recomputed when " >> a) What is a topology graph? When is it created, modified, or destroyed? > >> Is it a conceptual artifact constructed > >> from the various TLVs? I think a quick paragraph describing it would > >> help. > > > > The term “topology graph” is defined in the Terminology Section and based > > on bidirectional peer reachability which is defined right afterwards. In > the > > latter definition it is mentioned that the process is solely
