Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB
draft-ietf-trill-oam-mib-11

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")

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…"

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

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

- 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.