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

[Keith McCloghrie <[e-mail]>]

Bert/Orly,

> WG, 
> here is the MIB doctor review.
> 
> Thanks to Orly for her review!
> 
> Pls copy her if you want her to see comments/questions/answers
> because she is not subscribed to your mailing list.
> 
> W.r.t. to the comment on th eexpired draft: it has been (or
> will be soon) resurrected by the secretariat!

My responses to Orly's comments are below.  I have put an updated
document at:

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

Let me know if/when I should submit it as the new I-D.

Thanks,
Keith.
=====================

My responses:

> The draft has expired, and has been deleted from the Internet-Drafts
> directory. 
> ----------------------------------------------------------------------
> Here are 9  issues I found as potential items for fix:
> 
> 1.)Format---line(738) is too long
 
Oops, one character too many.

> 2)  Conformance with RFC 3978/3979 boilerplate---
>       -Seems as if an old copy of those is  being used in the  "Status
> of this Memo".
> 
> Should be as follows:
> 
> Status of this Memo
> 
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on January 13, 2006.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2005).
 
I myself get very frustrated at the number of times that the boilerplate
changes, but because of such changes, I think your replacement text is
incorrect, in two ways:

  a) I think the IETF's requirements (aside: how can they be called
  "Guidelines" when non-compliant submissions are refused!!) prohibit
  the inclusion of: "This Internet-Draft will expire on January 13,
  2006" in this section.

  b) idnits now complains about having a Copyright Notice near the 
  beginning of the document !!

If I had been clairvoyant enough to have submitted the I-D last
February containing the version of the boilerplate which is required
today, it would have been unacceptable back then.  However, since I do
now have to submit a revised version, I will have to change the I-D to
have today's version of the boilerplate rather than last February's :-(.

> 3)      IPR related ---
>         -Disclaimer of validity (15),  copyright statements (14) and IPR
> (7) are marked with numbers and 
>           listed in mixed order. 
>         - section 7 is redundant to 15 and seems as older version
> Should be as follows:
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    [e-mail].
> 
> 
> Disclaimer of Validity
> 
>    This document and the information contained herein are provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
>    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
>    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
>    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Copyright Statement
> 
>    Copyright (C) The Internet Society (2005).  This document is subject
>    to the rights, licenses and restrictions contained in BCP 78, and
>    except as set forth therein, the authors retain all their rights.
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
 
I don't know whether the above is correct without comparing it against
what the "guidelines" say.  To maximize the odds that my new text will
be acceptable, I will replace the above with a cut-and-paste from
the I-D that I submitted a couple of weeks ago which was acceptable
then (and hope that the "guidelines" haven't changed since).

> 4.) Abstract -- ok
> 
> 5.) MIB Boilerplate -- ok
 
Above you said "9 issues" -- if #4 and #5 are "-- ok", why are they
issues ?? 

> 6.) References -- 
> [FC-MGMT] draft-ietf-ips-fcmgmt-mib is RFC4044 by now "Fibre Channel
> Management MIB"  
> RFC2837,  was obsoleted by RFC4044, do we really need it? 
 
Yes, RFC2837 is referenced in the text because it's part of the history,
where it explains why RFC 2837 is obsolete.

> 7.) Security Considerations--ok
 
Again, why is this an issue ??

> 8.) Introduction--some redundancy exit with the abstract, maybe
> combination with section 3.  "Short Overview of Fibre Channel"
>      could have helped.
 
I agree it is redundant to have both an Abstract and an Intoduction,
but the IETF requires both, and even suggests they contain redundant
information (specifically, "a satisfactory abstract can be constructed
in part from material from the Introduction section").

> 9.) MIB objects--
> --there are few TCs in T11-FC-FABRIC-ADDR-MGR-MIB, why T11FabricIndex
> was placed in a separate MODULE and all others not with it ?

Because it was known in advance that there would be several follow-on
T11-XXX-MIB modules, which would need to IMPORT T11FabricIndex.
However, they would not need to IMPORT all of the TC's defined in
T11-FC-FABRIC-ADDR-MGR-MIB, and they would need to define their own
TC's.  So, the only 100%-consistent way to have spread the TC's over
the set of MIB modules would have been to delay the approval of
draft-ietf-imss-fc-fam-mib until all the other T11-XXX-MIB modules were
also ready to be approved, so that the T11-TC-MIB could contain all the
common TC's.  I did not (and still don't) believe such a delay was/is
warranted by such a small increase in consistency.

>   Also, based on its description it seems as the range should be
> (1..4095) , maybe there should be a word stating the consistency with
> [FC-SW-4]
>  regarding the value 0.
>   Maybe there are good reasons for the above that I simply not aware of.

Yes, I should and will add text to the DESCRIPTION, so that the
explanation which is presently in the Change Log doesn't get lost
when the Change Log is deleted.

I'll also take this opportunity to make the DESCRIPTION more 
definitive (i.e., change it to "the forthcoming standard, FC-SW-4,
defines how ...") which is now true, rather than using the speculative
text which needed to be written previously.

I'll also take this opportunity to delete the Change Log.

> --T11FamState description could be easier to follow if the order of the
> values-explanation  was as the order in the enumeration

OK.

> --line:260:  element #18 `t11FamPrincipalSwitchSelections' does not
> match order of 
>   columnar objects under `t11FamEntry',
> 't11FamLocalPrincipalSwitchSlctns' is listed as #18 and affect the rest
> that follow it. 
>   Better have the right order as the `t11FamEntry' listed and the
> corresponding OBJECT -GROUP
 
I had already discovered this and fixed it in my source, but had not
re-submitted a new version (so as to try to avoid being disruptive to
the process).

> --MIB layout is not as usually recommended:
>          +-- xxxNotifications(0)
>          +-- xxxObjects(1)
>          +-- xxxConformance(2)
> 
> It is recommended to change 
> t11FamNotifications   OBJECT IDENTIFIER ::= { t11FamMIBObjects 0 }
> 
> TO:
> t11FamNotifications   OBJECT IDENTIFIER ::= { t11FabricAddrMgrMIB 0 }
 
Sigh, ... OK.

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