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

From: "Orly Nicklass" <[email-masked]>
Date: Mon, 10 Oct 2005 10:02:44 +0200

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