Telechat Review of draft-ietf-idr-as0-05
review-ietf-idr-as0-05-genart-telechat-davies-2012-12-20-00

Request Review of draft-ietf-idr-as0
Requested rev. no specific revision (document currently at 06)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-09-11
Requested 2012-09-06
Draft last updated 2012-12-20
Completed reviews Genart Last Call review of -05 by Elwyn Davies (diff)
Genart Telechat review of -05 by Elwyn Davies (diff)
Secdir Last Call review of -?? by Tobias Gondrom
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-idr-as0-05-genart-telechat-davies-2012-12-20
Reviewed rev. 05 (document currently at 06)
Review result Ready
Review completed: 2012-12-20

Review
review-ietf-idr-as0-05-genart-telechat-davies-2012-12-20

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-idr-as0-05.txt
Reviewer: Elwyn Davies
Review Date: 22 August 2012
IETF LC End Date: 22 August 2012
IESG Telechat date: (if known) - 

Summary:
Almost ready. 

Major issues:
None.

Minor issues:
s1, para 2:
>    [RFC6491] specifies that AS number zero in a ROA is used to mark an
>    NLRI which is to be marked as Invalid.
This is not what s4 of RFC 6491 says although ultimately this is
(probably) the way in which it is intended to be used.  RFC 6491 just
says that an 'AS 0 ROA' is used to mark a prefix and all its more
specific prefixes as not to be used in a routing context.

s1, para 4:
>    As at least two implementations discard routes containing AS 0, and
>    to allow approaches such as the above, this document codifies this
>    behavior.
This sentence is not entirely clear as to what behavior is being
codified. It could be just discarding routes with AS 0 or the the use of
AS 0 to mark prefixes that shouldn't be routed.  Please make this easier
to parse.  This is partly because of the over interpretation of RFC 6491
mentioned in the previous comment.

Nits/editorial comments:
Abstract: Acronym BGP needs expanding.
s1: Acronyms ROA, AS and NLRI need expanding.
s2: It would be worth reinforcing that the behaviors being modified here
are currently specified in RFC 4271.  Arguably relevant section numbers
would help.
s4: Acronym RPKI needs expanding.
s4, para 2:
> security gotchas often lurk in the undefined spaces
This is slang and cliche that may be difficult for non-US speakers to understand.