Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
On 13/07/2015 03:05, Steven Barth wrote: Hello Ole, ... = Add a reference to Merkle trees? I'm not certain what would be a good source to quote here, maybe Merkle's paper from '87 or the ‘92 patent? At least there doesn't seem to be a really appropriate reference. His PhD thesis seems to be the best formal reference: www.merkle.com/papers/Thesis1979.pdf http://dl.acm.org/citation.cfm?id=909000 If you want to actually know what a Merkle tree is: https://en.wikipedia.org/wiki/Merkle_tree Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
It is my (possibly mistaken) understanding that the nature of an endpoint depends on the mode of operation. So why not use a more concrete definition? The definition just gets more verbose with every iteration, the underlying problematic is that it tries to unify different concepts that are usually not unified ;) Also, the reverse is true. The modes that may be used depend on the type of endpoint. I personally think the socket metaphor more or less fits: if you have a socket bound / connected to some global address, you just cannot do link-local multicast with it, though if you've bound your socket to a link-local address of an interface, you can probably use (link-local) mc as well as uc. What makes sense here of course depends on what you are trying to achieve, if your DNCP-based protocol is supposed to communicate to something a few (non-DNCP) hops away then using link-locals or allowing multicast mode is probably not sensible, for HNCP we don't need globally scoped unicast so for the sake of simplicity we define that endpoints must be mc-capable. In all modes, an endpoint identifier is an arbitrary non-zero integer that, at any given time, MUST uniquely identify a particular endpoint. Endpoint identifiers SHOULD NOT be reused too soon after a given endpoint ceases to exist, but if that happens, DNCP will reconverge after a short period of chaos. Yeah, I guess the reuse-clause makes sense. (I don't think that DNCP requires endpoint identifiers to be non-zero, but HNCP does, so you might as well make that a requirement of DNCP.) The terminology defines 0 to be reserved for internal purposes. Thanks, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
a locally configured communication endpoint of a DNCP node, such as a network socket. An endpoint may be bound to a set of predefined unicast Addresses representing remote DNCP nodes to individually connect to or to accept connections from whereby communication with each node is separated (e.g., an individual unicast UDP message flow per remote node). An endpoint may also be bound to a whole network interface, then multicast communication is used (in addition to individual unicast flows) to send certain messages to all DNCP nodes connected therewith at once as well as to automatically discover new DNCP nodes. I'm not sure I understand this paragraph. It uses words with many syllables. It is my (possibly mistaken) understanding that the nature of an endpoint depends on the mode of operation. So why not use a more concrete definition? * in both multicast modes of operation, an endpoint is just a local interface; * in both unicast modes of operation, an endpoint is a connected socket, or, equivalently, a pair of a local socket and a remote socket (or perhaps a pair of a local socket and one or more remote sockets, I'm not sure). In all modes, an endpoint identifier is an arbitrary non-zero integer that, at any given time, MUST uniquely identify a particular endpoint. Endpoint identifiers SHOULD NOT be reused too soon after a given endpoint ceases to exist, but if that happens, DNCP will reconverge after a short period of chaos. (I don't think that DNCP requires endpoint identifiers to be non-zero, but HNCP does, so you might as well make that a requirement of DNCP.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IntDir review: draft-ietf-homenet-dhcp-07
Hello Ole, thanks again for your review and sorry for the delay. Please find replies inline. Cheers, Steven Markus Given that it is an Abstract protocol specification, that must be combined with a profile specification to be a fully implementable, it is somewhat difficult to predict if the specification is complete or not. Juliusz Chroboczek is writing an independent implementation, and I'd recommend incorporating the very informative replies the authors have made to his comments on the homenet list into the document. -07 already included some of them and we've staged a few more for -08. General comments: = = Replace no affiliation with Independent. If that's the case. Done. = It is unclear to me how multiple instances of DNCP is run on a link. Is that something that must be specified in the profile document, and each profile must support multiple instances? Given draft-stenberg-shsp, and the way it hijacks the HNCP profile, it appears that more formal multiple instance support would be needed. Hmm, I think this is up to the specific protocol. Reuse of profiles is in theory possible but for standardisation would require either one protocol updating the other OR distinct TLV-spaces. The latter sounds a bit awkward e.g. IANA-wise. In any case , when sharing transport details such as port numbers, then a shared registry would need to be done anyway. SHSP should probably not be seen as a good example here. Since DNCP does not define defaults here an extra identifier seems unncessary and could or should probably be specified by the derived protocol. = I can't help being left with the impression that fragmentation (section 6.3) is underspecified. Can fragmentation be left out of the protocol for now (and profiles requiring large TLVs can require a transport layer supporting segmentation and reassembly?) Agreed. = I do find the text on transport modes somewhat confusing, U, M+U and MulticastListen+U. I'd like to see more descriptive text Okay, we will prepare something for -08. Abstract: = OLD: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. NEW: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses Trickle and Merkle trees. DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol. Done. = Add a reference to Merkle trees? I'm not certain what would be a good source to quote here, maybe Merkle's paper from '87 or the ‘92 patent? At least there doesn't seem to be a really appropriate reference. Section 4.2: = This is confusing: o If using a stream transport, the TLV MUST be sent at least once, and it SHOULD be sent only once. I staged If using a stream transport, the TLV MUST be sent at least once per connection, but SHOULD NOT be sent more than once. for now. OLD: * If only unreliable unicast transport is employed, Trickle state is kept per each peer and it is used to send Network State TLVs every now and then, as specified in Section 4.3. NEW: * If only unreliable unicast transport is used, Trickle state is kept per peer and it is used to send Network State TLVs intermittently, as specified in Section 4.3. s/every now and then/now and then/ s/employed/used/ Section 4.3: = reference to rfc6206? All done. o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast. o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast. = What do an implementation do if the endpoint is not in M+U transport mode, and the unicast transport is reliable? Section 4.2 states If only reliable unicast transport is employed, Trickle is not used at all. for unicast mode and ML+U mode references that as well. (I do find the transport modes confusing, and I'm not sure I understand the MulticastListen mode). These modes, especially the listen one is only used for Dense Broadcast Link optimization. It is essentially the same as unicast, however the node listens for multicast traffic to detect the presence or abscence of a node with higher identifier on the underlying multicast-capable link. s/when using also secure unicast/when using secure unicast/ Done. Section 4.4: = What is meant by: link with shared bandwidth? I changed it to multiple access link for now, I think that makes it more clear. o Any other TLV: TLVs not
[homenet] IntDir review: draft-ietf-homenet-dhcp-07
I have been selected as the Internet Directorate reviewer for this draft. The purpose of the review is to provide assistance to the Internet ADs. Although these comments are primarily for the use of the Internet ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-homenet-dncp-07.txt Reviewer: Ole Troan Review Date: July 7 16, 2015 The document now reads much better. I do get the impression that the text is reverse engineered from code in a few places though. Given that it is an Abstract protocol specification, that must be combined with a profile specification to be a fully implementable, it is somewhat difficult to predict if the specification is complete or not. Juliusz Chroboczek is writing an independent implementation, and I'd recommend incorporating the very informative replies the authors have made to his comments on the homenet list into the document. General comments: = = Replace no affiliation with Independent. If that's the case. = It is unclear to me how multiple instances of DNCP is run on a link. Is that something that must be specified in the profile document, and each profile must support multiple instances? Given draft-stenberg-shsp, and the way it hijacks the HNCP profile, it appears that more formal multiple instance support would be needed. = I can't help being left with the impression that fragmentation (section 6.3) is underspecified. Can fragmentation be left out of the protocol for now (and profiles requiring large TLVs can require a transport layer supporting segmentation and reassembly?) = I do find the text on transport modes somewhat confusing, U, M+U and MulticastListen+U. I'd like to see more descriptive text Abstract: = OLD: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. NEW: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses Trickle and Merkle trees. DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol. = The purpose of that change would be to make it clear what this is. A framework? A component that protocols can be built out of? = Add a reference to Merkle trees? Section 4.2: = This is confusing: o If using a stream transport, the TLV MUST be sent at least once, and it SHOULD be sent only once. OLD: * If only unreliable unicast transport is employed, Trickle state is kept per each peer and it is used to send Network State TLVs every now and then, as specified in Section 4.3. NEW: * If only unreliable unicast transport is used, Trickle state is kept per peer and it is used to send Network State TLVs intermittently, as specified in Section 4.3. s/every now and then/now and then/ s/employed/used/ Section 4.3: = reference to rfc6206? o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast. o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast. = What do an implementation do if the endpoint is not in M+U transport mode, and the unicast transport is reliable? (I do find the transport modes confusing, and I'm not sure I understand the MulticastListen mode). s/when using also secure unicast/when using secure unicast/ Section 4.4: = What is meant by: link with shared bandwidth? o Any other TLV: TLVs not recognized by the receiver MUST be silently ignored. = doesn't that mean it isn't stored in the Merkle tree? and the hashes don't compute? Section 4.6: = First mention of a topology graph. Section 5: == o Endpoint identifier: the 32-bit opaque value uniquely identifying it within the local node. = it? I think I'm still confused what is an endpoint, what is a peer and what is a node. o Range of addresses: the DNCP nodes that are allowed to connect. = How does a range of addresses look like and how is it used? I find only one occurence in the document. Section 6.1: A DNCP profile MAY specify either per-endpoint or per-peer keep-alive support. = Again I'm confused over the usage of endpoint versus peer. What's the difference between per-peer and per-endpoint keepalives? Section 6.2: s/actually uses/uses/ signature.asc Description: Message signed with OpenPGP using GPGMail
