Skip to main content

Telechat Review of draft-ietf-bier-ospf-bier-extensions-12
review-ietf-bier-ospf-bier-extensions-12-genart-telechat-sparks-2018-02-19-00

Request Review of draft-ietf-bier-ospf-bier-extensions
Requested revision No specific revision (document currently at 18)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-02-20
Requested 2018-02-08
Authors Peter Psenak , Nagendra Kumar Nainar , IJsbrand Wijnands , Andrew Dolganow , Tony Przygienda , Zhaohui (Jeffrey) Zhang , Sam Aldrin
I-D last updated 2018-02-19
Completed reviews Genart Telechat review of -12 by Robert Sparks (diff)
Secdir Telechat review of -11 by Adam W. Montville (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Telechat review on draft-ietf-bier-ospf-bier-extensions by General Area Review Team (Gen-ART) Assigned
Reviewed revision 12 (document currently at 18)
Result Almost ready
Completed 2018-02-19
review-ietf-bier-ospf-bier-extensions-12-genart-telechat-sparks-2018-02-19-00
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bier-ospf-bier-extensions-12
Reviewer: Robert Sparks
Review Date: 2018-02-19
IETF LC End Date: 2018-02-22
IESG Telechat date: 2018-02-22

Summary: Almost ready for publication as a standards track RFC

Major issue:
The security considerations section is essentially empty (what it currently
says reduces to "don't let malformed packets crash your implementation". Surely
there's more to say here. Is there an assumption that, in any given deployment,
the administrators of the bier layer and the ospf layer are the same people,
and have the same authority? If so, it's probably worth saying so. If not, are
there edges to discuss? If this document really doesn't introduce any new
security considerations, it should argue why that's the case.

Minor issues:
Is there a reason not to use the example/documentation IPV4 address ranges?
(See the shepherd writeup). The author count is above the current
RFC-Editor/IESG recommendations. Work that out with your ADs.