Skip to main content

Telechat Review of draft-ietf-pwe3-oam-msg-map-
review-ietf-pwe3-oam-msg-map-secdir-telechat-kaufman-2011-01-10-00

Request Review of draft-ietf-pwe3-oam-msg-map
Requested revision No specific revision (document currently at 16)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2011-01-18
Requested 2010-11-30
Authors Yaakov (J) Stein , Monique Morrow, Thomas Nadeau , Luca Martini , Mustapha Aissaoui , Peter Busschbach
I-D last updated 2011-01-10
Completed reviews Secdir Telechat review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Request Telechat review on draft-ietf-pwe3-oam-msg-map by Security Area Directorate Assigned
Completed 2011-01-10
review-ietf-pwe3-oam-msg-map-secdir-telechat-kaufman-2011-01-10-00

**Please ignore previous version; I had a typo in an email address and draft
name. **



I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document
 editors and WG chairs should treat these comments just like any other last
 call comments.



This document specifies a standardized way of translating error notification
codes between several different protocols. The need comes up in the context of
using Pseudowire (PW) protocol to replace a physical link in a network.
Pseudowires
 replace physical wires imperfectly in that they can have more complex failure
 modes. These can interact in complex ways with the failure modes of the
 protocols running over the pseudowires.



There are no real security considerations in the code mappings. This document
references the security considerations sections of other RFCs where the
translated error codes are handled. This seems appropriate.



The only thing that came to my mind that relates to security that was not
discussed was emergent errors, where the pseudowire could introduce an error
not detectable at its endpoints that could nevertheless cause problems at a
higher layer.
 Examples would be a pseudowire that duplicated, selectively lost, or reordered
 packets. There are also interesting problems to be had where the pseudowire
 capacity is variable and its carrying capacity falls below the higher layer
 protocol’s ability to use it. An example would be a link between two routers
 that should be declared down when it gets slow enough so that higher layers
 will find better routes. Even so, any such discussion would belong in a
 different document.



I’d like to express my great appreciation for Section 4.1, which expands almost
all of the acronyms used in the document. It made it possible for me – with
almost no previous knowledge of the subject matter – to read and mostly
understand
 most of the document. I wish such a thing could be made mandatory for all RFCs.



                --Charlie