Re: Review of draft-ietf-anima-grasp-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks, Joel!

On Sat, Feb 25, 2017 at 11:41:15AM -0800, 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)"?
> 

-- 
---
tte@xxxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]