Last Call Review of draft-ietf-mpls-rsvp-te-no-php-oob-mapping-
review-ietf-mpls-rsvp-te-no-php-oob-mapping-secdir-lc-leiba-2011-08-26-00
| Request | Review of | draft-ietf-mpls-rsvp-te-no-php-oob-mapping |
|---|---|---|
| Requested revision | No specific revision (document currently at 09) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2011-08-23 | |
| Requested | 2011-07-26 | |
| Authors | Zafar Ali , Rahul Aggarwal , George Swallow | |
| Draft last updated | 2011-08-26 | |
| Completed reviews |
Secdir Last Call review of -??
by
Barry Leiba
|
|
| Assignment | Reviewer | Barry Leiba |
| State | Completed | |
| Review |
review-ietf-mpls-rsvp-te-no-php-oob-mapping-secdir-lc-leiba-2011-08-26
|
|
| Completed | 2011-08-26 |
review-ietf-mpls-rsvp-te-no-php-oob-mapping-secdir-lc-leiba-2011-08-26-00
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.
It's a simple draft, defining a few new flags, and I don't see any
problems with it.
I have one minor question; in section 2.2 is this:
An Ingress LSR sets the OOB mapping indication flag to signal the
Egress LSR that binding of RSVP-TE LSP to an application and
payload identification is being signaled out-of-band. This flag
MUST NOT be modified by any other LSRs in the network. LSRs other
than the Egress LSRs SHOULD ignore this flag.
On that last "SHOULD": what does it mean for any other LSR *not* to
ignore the flag? That is, what can they do? How can they not ignore
it, since there's no defined behaviour for them to do with it?
Barry