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)"?