CCs trimmed. Thanks Joel. Good comments, we will deal with all of them. We have some basic questions to answer first, raised by Charlie Perkins' review*, so it will take a little while.
Regards Brian * https://mailarchive.ietf.org/arch/msg/ietf/PlJ9SgdwT5mdOPqF2fDDIfAeHMQ On 26/02/2017 08:41, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-anima-grasp-?? > Reviewer: Joel Halpern > Review Date: 2017-02-25 > IETF LC End Date: 2017-03-02 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Major issues: > > Minor issues: > Section 2.2 states that routing protocols mainly consider link > up/down and that "all nodes need a consistent view of the network > topology". the first seems an over-generalization, since all routing > protocols have metrics, and almost all modern routing protocols carry > significant additional information about the links and nodes. The > second statement about consistency is true for some protocols, but is > not true for external use of BGP nor, as I understand it, for Babel. > So it seems again too strong a characterization. The following > sentence about information not normally used also seems to be at odds > with current practice. > > Bullet 1 under SN7 in section 2.2 talks about the potential for > circular dependence, and then says that this protocol will not provide > any assistance for that. given that such dependence may be complex. > In particular, given that these dependencies result in separate > negotiations, the chain of efforts would continue even if the initial > impetus has timed out. If a single negotiation causes two dependent > negotiations, this would seem to have the potential to cause a work > explosion. > > It is probably considered obvious, but I did not see text > indicating that GRASP messages with unknown MESSAGE_TYPE should be > silently ignored. Or any other definition of the expected behavior > (should be logged?) > > Nits/editorial comments: > In section 3.1 in the definition of Technical Objective the text > starts by saying that it is a configurable parameter or set of > parameters. Most further text refers to a single value, with > indications that the value may be a complex structure. Hence, in the > first part of the definition, the same construction should be used, > rather than referring to a set of values. This gets slightly confused > when section 3.10.4 goes back to talking about multiple parameters for > an objective. Consistency please? > > The first paragraph of 3.5.4.1 states that upon receiving a > discovery request, a recipient will respond, either with the data or > with a divert. While this is eventually true, it is misleading. As > 3.5.4.2 states, the recipient, if it does not have an answer, will > relay the request in order to get an answer. Some mention of this in > 3.5.4.1 would seem helpful. > > Should the first line of 3.5.5 on negotiation include "(using > M_REQ_NEG)"? > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
