Telechat Review of draft-ietf-mpls-residence-time-14
review-ietf-mpls-residence-time-14-secdir-telechat-kaduk-2017-03-01-00
| Request | Review of | draft-ietf-mpls-residence-time |
|---|---|---|
| Requested revision | No specific revision (document currently at 15) | |
| Type | Telechat Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2017-02-28 | |
| Requested | 2017-01-31 | |
| Authors | Greg Mirsky , Stefano Ruffini , Eric Gray , John Drake , Stewart Bryant , Sasha Vainshtein | |
| Draft last updated | 2017-03-01 | |
| Completed reviews |
Rtgdir Early review of -11
by
He Jia
(diff)
Genart Last Call review of -12 by Robert Sparks (diff) Secdir Last Call review of -12 by Benjamin Kaduk (diff) Opsdir Last Call review of -12 by Jürgen Schönwälder (diff) Secdir Telechat review of -14 by Benjamin Kaduk (diff) Genart Telechat review of -13 by Robert Sparks (diff) Genart Telechat review of -14 by Robert Sparks (diff) |
|
| Assignment | Reviewer | Benjamin Kaduk |
| State | Completed | |
| Review |
review-ietf-mpls-residence-time-14-secdir-telechat-kaduk-2017-03-01
|
|
| Reviewed revision | 14 (document currently at 15) | |
| Result | Has Nits | |
| Completed | 2017-03-01 |
review-ietf-mpls-residence-time-14-secdir-telechat-kaduk-2017-03-01-00
I previously reviewed the -12 (https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html); the -14 seems much improved. On this re-read, I have a better sense of how the various TLVs and sub-TLVs fit together to achieve the goal of having the RTM-capable nodes identify each other and collaborate to account for residence time when processing timing packets. I have no security concerns with the document, as the updated security considerations address the concerns previously raised. However, there are a couple of issues that should probably block publication (but ought to be easy to resolve): Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7 bits, 'Length' 8, 'I' 1, and 'Reserved' 15. Presumably Type is intended to be the full 8 bits, given the assigned values in the registry. On page 16, second paragraph: The ingress node MAY inspect the I bit flag received in each RTM_SET TLV contained in the LSP_ATTRIBUTES object of a received Resv message. Presence of the RTM_SET TLV with I bit field set to 1 indicates that some RTM nodes along the LSP could be included in the calculation of the residence time. An ingress node MAY choose to resignal the LSP to include all RTM nodes or simply notify the user via a management interface. Is that supposed to be "included" or "excluded"? My reading of the previous paragraph was that the I bit would be set when a node failed to compute the next RTM-capable node along the path, and of course, we expect normal operation to include the residence time for all RTM-capable nodes, so signalling potential inclusion is odd. I'll close off this review by noting that sections 4.3 through 4.6 seem to all talk about how to use other protocols to indicate that RTM may be used and could perhaps be grouped into an intermediate subsection, wondering whether the "Type" and "Length" fields in Figure 2 are the same octets of the packet as in Figure 1, and repeating my as-yet unfulfilled intention to send further minor editorial patches to the authors. -Ben