Subject: RE: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.tx t--and 02

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 10 Oct 2005 12:54:11 +0200

Keith, I also did a quick check on rev 02 that you pointed to.
Here are some additional nits that I found, and that you might
as well tidy up while working on it:

- issues with citations/references:
  !! Missing Reference for citation: [RFC2741]
  P005 L031:    single SNMP agent having multiple AgentX [RFC2741] sub-agents, with

  !! Missing Reference for citation: [RFC2863]
  P004 L044:    extensions to the standard IF-MIB [RFC2863] for Fibre Channel
  (you seem to be using [IF-MIB] and also [RFC2863]. I prefer the latter)

- I would change (2 times):
    REVISION    "200510070000Z"
    DESCRIPTION
           "Initial version of this MIB module."
  into:
    REVISION    "200510070000Z"
    DESCRIPTION
           "Initial version of this MIB module, published as RFCyyyy."
           -- RFC-Editor, pls fill in xxxx for RFCyyyy
  
- For consistency, I think I would change 
     t11FabricAddrMgrMIB MODULE-IDENTITY
  into
     t11FamMIB MODULE-IDENTITY
  but as I said, it is a nit.

- indentation for various MIB objects and descriptions is inconsistent

Could you also comment on:

   W: f(t11fc.mi2), (699,13) Row "t11FamIfEntry" does not have a consistent indexing
      scheme - cannot specify an index item from additional "base row" fcmInstanceEntry,
      since can have only one "base row" which is ifEntry

I think it is OK, but would like to hear/read your comments.

Further, I have these somehwat more serious comments:

1. I see in the t11FamTable a number of writable objects, but I seem to be
   missing any writeup as to what the expected persistency behaviour is
   for these objects. Am I not looking at the correct place?
   Same for t11FamIfTable. Maybe other places as well, pls check.
2. In that same table, I see COunter32 objects, but nothing about possible
   discontinuities and if any, which is the discontinuity timer.
3. For t11FamIfRowStatus, I think you need to state if other writable column(s)
   can be changed or not when in active state.

Bert

> -----Original Message-----
> From: Orly Nicklass [mailto:[email-masked]]
> Sent: Monday, October 10, 2005 10:03
> To: Keith McCloghrie; [email-masked]
> Cc: [email-masked]
> Subject: RE: [imss] FW: MIB Doctor review
> draft-ietf-imss-fc-fam-mib-01.txt--and 02
> 
> 
>  
>  Keit,
> 
> Regarding version 01 related issues, I said 9 so you can 
> easily look for
> all. I should have said:
> Here are 9  issues, 6 I found as potential items for fix.
> Reply to related items can be found in lines with prefix [ON].
> 
> 
> Regarding version 02:
> Below is a list of my comments:
> 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.
> 2-Was the abstract got shorter on purpose omitting the 
> reference to T11
> group? It is in the Ack section but I wonder.
> 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
> 4-Following #3 above, any reference to [FC-MGMT] in the text 
> (like sec.
> 4, 5 etc.) better be replaced with [RFC4044]
> 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.
> 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
> 
> 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.
> 
> 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.
> End
> Orly
> 
> 
> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: Friday, October 07, 2005 20:00
> To: [email-masked]
> Cc: [email-masked]; Orly Nicklass
> Subject: Re: [imss] FW: MIB Doctor review
> draft-ietf-imss-fc-fam-mib-01.txt
> 
> 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.
> 
> [ON] The above is an Auto-generated text by running XML2RFC 
> tool version
> 1.29 and it passes with no nits.
> The incorrect date is due to my input example. Sorry.
> Section 6 of  http://www.ietf.org/ietf/1id-guidelines.txt states:
> "A document expiration date should appear on the first and 
> last page of
> the Internet-Draft. "
> 
>   b) idnits now complains about having a Copyright Notice near the
>   beginning of the document !!
> [ON] The recommandation is to place it at  the end, the XML2RFC places
> it as shown. I have not seen any nits on the 
> above.Intresting! Ok if you
> leave it just for the end.
> 
> 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
> >    [email-masked].
> > 
> > 
> > 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"
> [ON] You should use the  RFC not the ID.?
> > 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.
> [ON]ok.
> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss