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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
