Skip to main content

Last Call Review of draft-ietf-anima-grasp-09

Request Review of draft-ietf-anima-grasp
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-03-02
Requested 2017-02-16
Authors Carsten Bormann , Brian E. Carpenter , Bing Liu
I-D last updated 2017-02-25
Completed reviews Intdir Early review of -09 by Charles E. Perkins (diff)
Opsdir Last Call review of -12 by Joel Jaeggli (diff)
Secdir Last Call review of -09 by Barry Leiba (diff)
Genart Last Call review of -09 by Joel M. Halpern (diff)
Tsvart Telechat review of -11 by Martin Stiemerling (diff)
Secdir Telechat review of -11 by Barry Leiba (diff)
Genart Telechat review of -11 by Joel M. Halpern (diff)
Artart Telechat review of -11 by Martin Thomson (diff)
Genart Telechat review of -12 by Joel M. Halpern (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Review review-ietf-anima-grasp-09-genart-lc-halpern-2017-02-25
Reviewed revision 09 (document currently at 15)
Result Ready w/nits
Completed 2017-02-25
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


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


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 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 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 would seem helpful.

    Should the first line of 3.5.5 on negotiation include "(using M_REQ_NEG)"?