Skip to main content

Early Review of draft-ietf-idr-error-handling-15
review-ietf-idr-error-handling-15-rtgdir-early-chen-2014-12-19-00

Request Review of draft-ietf-idr-error-handling
Requested revision No specific revision (document currently at 19)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2014-12-19
Requested 2014-12-08
Authors Enke Chen , John Scudder , Prodosh Mohapatra , Keyur Patel
I-D last updated 2014-12-19
Completed reviews Genart Last Call review of -18 by Tom Taylor (diff)
Secdir Last Call review of -18 by Paul E. Hoffman (diff)
Opsdir Early review of -15 by Warren "Ace" Kumari (diff)
Rtgdir Early review of -13 by Joel M. Halpern (diff)
Rtgdir Early review of -15 by Mach Chen (diff)
Assignment Reviewer Mach Chen
State Completed
Request Early review on draft-ietf-idr-error-handling by Routing Area Directorate Assigned
Reviewed revision 15 (document currently at 19)
Result Has issues
Completed 2014-12-19
review-ietf-idr-error-handling-15-rtgdir-early-chen-2014-12-19-00
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review. The purpose of the review is
to provide assistance to the Routing ADs. For more information about the
Routing Directorate, please see ​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-idr-error-handling-16.txt
Reviewer: Mach Chen
Review Date: Nov. 12, 2014
Intended Status: Standards Track

Summary:
 This document is well written and easy to understand. I found some nits and
 one minor issue that I think should be resolved before publication.

Comments:
 None.

Major Issues:
 No major issues found.

Minor Issues:
 Section 7.3
 "The attribute is considered malformed if its length is not 4 [RFC4271]."

 If only according to RFC4271, this is the case, but seems that RFC5549 allows
 that the length of Nexthop attribute can be either 4 or 16.

Nits:
 Section 2.
 s/to handling/to handle

 in the last bullet of the 4 approaches.
 s/must not/MUST NOT

Best regards,
Mach