Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB
draft-ietf-trill-oam-mib-11
Yes
(Alia Atlas)
No Objection
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 06 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -06)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2015-08-19 for -07)
Unknown
Weird that this document uses the old template, with Status of this Memo as the first section. I would suggest doing a pass of this whole document to clean up the English before it goes to the RFC Editor, as there are enough places where the grammar is ambiguous that it would be better not to have the RFC Editor try to interpret them all. Some examples of issues that seem to occur throughout the document: Missing articles (e.g. Sec 5.3, "trilloamNotifications are sent to management entity") Inconsistent capitalization (e.g. in the definition of trillOamMepTxLbmReplyModeOob, "True Indicates that Reply of Lbm") Subject-verb agreement problems (e.g., in the definition of trillOamMepTxMtvmMessages, "Rbridge retransmit the Multi Destination message") Ambiguous text (e.g., in the definition of trillOamMepTxPtmMessages, "Once Destination or Hop count reaches it's treated as single Counter increment of this object")
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -06)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-08-17 for -06)
Unknown
A few nits: -- section 3: s/is intended to provide/provides ; (Unless you are concerned that it did not succeed? Please expand OAM on first mention. -- 5.3.1: s/fault alarm/fault alarms -- 6 (title) s/module/modules -- 6, first paragraph, "relevant to TRILL OAM MIB" missing article -- 6.1, first paragraph: Is there a reason to capitalize "Augments" and "Augmenting"? --6.1, 2nd paragraph: I have trouble parsing this paragraph. Do you mean some implementations do not support Link Trace Messages? All implementations? The TRILL standard? I suggest the latter part of the sentence be “statistics for these messages should have default values as per…"
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-08-19 for -07)
Unknown
Melinda Shore did the opsdir review. would like to see the question of the security considerations setion addressed. ---- I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: The document is in good basic shape, with some weaknesses in the security considerations. I'd like to see those remedied but I'm not sure they're serious enough to recommend blocking publication. This document specifies a MIB for TRILL. This document has been received MIB doctor review and issues raised during that review have been been resolved. The security considerations section is weak, but not fatally so. The draft identifies exposing MAC addresses as a potential privacy issue but does not identify other security considerations specific to this particular MIB module, which is unfortunate given the inclusion of writable objects. More specificity about which security mechanisms to use might help avoid interoperability problems. Also, in this climate it may be useful to separate out the privacy issues into a "Privacy Considerations" subsection. The nits checker found: . two instances of non-RFC5735-compliant IPv4 addresses . a missing reference to CFM. This one is wrong - CFM is identified and a reference provided in the Introduction (section 1) Melinda
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-08-18 for -06)
Unknown
Thanks for the updated Security Considerations in the SecDir review, that update will address my concerns. https://www.ietf.org/mail-archive/web/secdir/current/msg05934.html
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -06)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -06)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-08-19 for -07)
Unknown
- Grepping for "MAX-ACCESS *read-create" gives me 28 hits. The security considerations section describes 5 of those that I can see. Are you saying that you did check but all of the others are read-create are not in fact sensitive? - The security considerations here might note two additional things. First, access to the read-only date exposes the network topology so might be considered more sensitive than other MIBs. And second, if one can set an IP address to which reports are sent say in the event of some kind of packet storm, then that could maybe be used to DoS that IP address. I'm not sure either is worth a mention, but just wanted to check in case they might be.
Terry Manderson Former IESG member
No Objection
No Objection
(for -07)
Unknown