Re: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt--and 02

[Keith McCloghrie <[e-mail]>]

I've put a new version at:

   ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fam-mib-02.txt

> 1-Checking nits according to
> http://www.ietf.org/ietf/1id-guidelines.txt:
>   - There might be pages with length exceeding 58 lines per page, (page
> 3) being 59 lines.
> PLS check.

I have checked, and my text conforms to the requirement in
draft-rfc-editor-rfc2223bis-08.txt which says:

           Each page must be limited to 58 lines followed by a Form Feed
           (FF) character, followed by an EOL sequence.  The 58 line
           limit includes the headers and footers specified below.

i.e., there appears to be a bug in 'idnits'.

> 2-Was the abstract got shorter on purpose omitting the reference to T11
> group? It is in the Ack section but I wonder.

I believe my text conforms to http://www.ietf.org/ietf/1id-guidelines.html
which says:

   Every Internet-Draft must have an Abstract section. The Abstract
   should provide a concise and comprehensive overview of the purpose
   and contents of the entire document. Its purpose is to give a
   technically knowledgeable reader a general overview of the function
   of the document, to decide whether reading it will be useful. In
   addition to its function in the document, the Abstract section is
   used as a summary in publication announcements and in the online
   index of Internet-Drafts.

   Composing a useful Abstract is a non-trivial writing task. Often, a
   satisfactory abstract can be constructed in part from material from
   the Introduction section, but a good abstract will be shorter, less
   detailed, and broader in scope than the Introduction. Simply copying
   and pasting the first few paragraphs of the Introduction is
   tempting, but it generally results in an Abstract that is both
   incomplete and redundant.

   An Abstract will typically be 5-10 lines, but an Abstract of more
   than 20 lines or less than 3 lines is generally not acceptable.

   An Abstract should be complete in itself, so it should contain no
   citations unless they are completely defined within the Abstract.
   Abbreviations appearing in the Abstract should generally be expanded
   in parentheses. There is a small set of reasonable exceptions to
   this rule; for example, readers don't need to be reminded of what
   "IP" or "TCP" or "MIB" means. In the end, therefore, this is a
   judgment call, but please err on the side of explicitness.

> 3-in issue 6 of version 01 I mentioned two points, the second one is
> fine. The first one I think you have missed. It should be addressed:
> [FC-MGMT]
>      K. McCloghrie, "Fibre Channel Management MIB", Internet-Draft
>      (draft-ietf-ips-fcmgmt-mib-nn.txt), work-in-progress.
> Should be changed to:
> [RFC4044]
>       K. McCloghrie, "Fibre Channel Management MIB",RFC 4044, May 2005

OK, but please note that you incorrectly omitted the period at the
end of your text, and you also incorrectly omitted a space character
in 'MIB",RFC'.

> 4-Following #3 above, any reference to [FC-MGMT] in the text (like sec.
> 4, 5 etc.) better be replaced with [RFC4044]

The use of "[FC-MGMT]" complies with draft-rfc-editor-rfc2223bis-08.txt
which states:

      We recommend enclosing citations in square brackets ("[ ]").
      Simple numeric citations ("[53]") can cause confusing gaps when
      the list of references is split between normative and informative.
      A good alternative is to have two separate series, "[n1]", "[n2]",
      ... "[i1]", "[i2]" for citations to normative and informative
      references.  Other choices include author abbreviations, possibly
      a year ("[Smith93]"), and some brief encoding of the title and
      year ("[MPLS99a]").

> 5-It is easier to follow when OBJECT-GROUP has the same order of objects
> as they appear in their corresponding Entries.
> t11FamGroup  is not fully aligned with its various object including the
> change you made for object 18.

These days, when all the "nits" are being written down so that they can be
enforced, it seems that "nits" are more important than "easier to follow".
So, because there is no SMI requirement, and no Guidelines requirement,
and no "nit" requirement regarding the order of objects listed in an
OBJECT-GROUP definition, I see no need to change this. 

> 6-Any reason to remove the statement --to be assigned by IANA from the
> t11FabricAddrMgrMIB ? Actually the guide recommend the following:
> 
>    -- RFC Ed.: replace nn with IANA-assigned number & remove this note
 
Actually, the guide recommends:

   -- RFC Ed.: replace XXX with IANA-assigned number & remove this note

My personal belief is that this is redundant now that the IETF requires
an "IANA Considerations" section, but sigh, I'll add it.

> Now--Since there are two such cases in this ID, I would recommend to
> name them differently. Like nn and mm,
> Or simply the common XXX, YYY.
 
I can't use "YYY" because RFC 4181 recommends "XXX".

> 7-in section 11 I would extend the request to reference both locations
> rather than just say
> "IANA is requested to make a MIB OID assignment under the appropriate  
>     under the appropriate subtree. "
> The guide recommend the following:
> Editor's Note (to be removed prior to publication):  the IANA is
>       requested to assign a value for "XXX" under the 'mib-2' subtree
>       and to record the assignment in the SMI Numbers registry.  When
>       the assignment has been made, the RFC Editor is asked to replace
>       "XXX" (here and in the MIB module) with the assigned value and to
>       remove this note.
> I suppose you can make it shorter but include  both MIB modules in this
> ID.

I'll change it to:

   IANA is requested to make two MIB OID assignments, one for the
   T11-TC-MIB module and one for the T11-FC-FABRIC-ADDR-MGR-MIB module,
   under the appropriate subtree(s).

Keith.

_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss