Hi Steven, The changes look good Thank you. I'd recommend putting H() in the terminology. I agree that it's defined at the start of Section 7 - but it is used earlier around Sec 4.2. You can also refer to H() where how to calculate the network hash is defined.
I think the draft is a lot more readable and easier to understand now. As I said in my discuss, I may have a few more comments from a Routing Directorate review (since I'm no longer a new reader), but you've nicely addressed all my concerns. thanks, Alia On Tue, Oct 20, 2015 at 7:31 AM, Steven Barth <[email protected]> wrote: > Hi Alia, > > thanks a lot for your continuous reviews. I have staged a few changes in > our Git to address your remaining issues. We will include it in a an > upcoming version with fixes for other remaining blockers left in -11. > > See: https://github.com/fingon/ietf-drafts/commit/374a4a3 > More replies inline below. > > Thanks, > > Steven > > > > 1) End of Sec 4.4, can you clarify what the behavior is for > > unrecognized TLV that is included in the Node Data field of a Node > > State TLV? I assume that its meaning is not processed, but it is > > included in the computation of the Node State Hash? > > Clarified. > > > > > I've also read this draft too many times at this point to be certain that > > I've picked up all the points of > > unclarity. I've requested another Routing Directorate review, from a new > > reviewer, so I may be modifying > > my ballot again before the telechat on Thursday. > > Thanks. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I also have a few more minor comments that affect readability. > > > > 2) On p. 6, Definition of Peer means that the same DNCP node using a > > different local and remote endpoint pair would be a different Peer?? > > Is that intentional? > > Changed to "at least one". > > > > 4) In Sec 4.5, it seems unfortunate to have old network and > > connectivity state stored. It seems to me that it'd be fairly trivial > > to describe a "polite neighbor" termination policy where a peer sends > > an Node Data TLV for itself with no data in it - including Node > > Endpoint TLVs. I am a bit nervous about bad side effects, but I do > > not have a specific example to mind and obviously, a neighbor can fail > > as well as gracefully shut down connections. Describing "polite > > neighbor" > > behavior may be too much of a technical change at this point, but I'd be > > happy if you think about it seriously. > > I think there are legitimate cases where this graceful termination is > redundant, i.e., because the derived protocol employs a transport or > link-layer that provides such events already. Nevertheless I guess a > derived protocol could probably with some care add such a mechanism > where it makes sense. I'm a bit reluctant to add it as that stage really. > > > > 5) In Sec 7.2.2, it says "This TLV contains the current locally > > calculated network state hash, see Section 4.1 for how it is calculated." > > This describes the value when sent. When received, it contains the > > Peer's network state hash. > > Changed to "contains the current network state hash calculated by its > sender" > > > 6) Please define H(...) in terminology, since Sec 7 uses it. > > Hmm, it is currently defined at the beginning of Section 7 just before > the first sub-paragraph so I am not sure if it will add more clarity to > also add it to the terminology. >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
