From imss-bounces@ietf.org Thu Oct 06 12:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYCh-0004em-H0; Thu, 06 Oct 2005 12:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYCf-0004eC-Ms for imss@megatron.ietf.org; Thu, 06 Oct 2005 12:02:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12035 for ; Thu, 6 Oct 2005 12:02:38 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENYLm-00065I-1Y for imss@ietf.org; Thu, 06 Oct 2005 12:12:07 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j96G2R7R009969; Thu, 6 Oct 2005 11:02:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Oct 2005 18:02:26 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155083CEC84@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Imss (E-mail)" Date: Thu, 6 Oct 2005 18:02:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: "Orly Nicklass \(E-mail\)" Subject: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org 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! Bert -----Original Message----- From: Orly Nicklass [mailto:orly_n@rad.com] Sent: Thursday, October 06, 2005 13:52 To: Wijnen, Bert (Bert); Black_David@emc.com Cc: kzm@cisco.com; cds@cisco.com Subject: RE: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt Hi, 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 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). 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 ietf-ipr@ietf.org. 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. 4.) Abstract -- ok 5.) MIB Boilerplate -- ok 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? 7.) Security Considerations--ok 8.) Introduction--some redundancy exit with the abstract, maybe combination with section 3. "Short Overview of Fibre Channel" could have helped. 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 ? 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. --T11FamState description could be easier to follow if the order of the values-explanation was as the order in the enumeration --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 --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 } END of Review Orly -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 25, 2005 23:13 To: David Black (E-mail) Cc: Orly Nicklass Subject: RE: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt David, Orly has agreed to do MIB doctor review for this MIB module within the next week or two. Orly, pls send comments to WG mailing list, copy authors and myself. Thanks, Bert _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Oct 07 14:00:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwVo-0005NN-FS; Fri, 07 Oct 2005 14:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENwVn-0005Mz-Dc for imss@megatron.ietf.org; Fri, 07 Oct 2005 14:00:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02993 for ; Fri, 7 Oct 2005 14:00:01 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENwf7-0001Ii-Oi for imss@ietf.org; Fri, 07 Oct 2005 14:09:42 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Oct 2005 10:59:53 -0700 X-IronPort-AV: i="3.97,188,1125903600"; d="scan'208"; a="664303822:sNHT26370724" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j97Hxo4V029170; Fri, 7 Oct 2005 10:59:51 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA07425; Fri, 7 Oct 2005 10:59:50 -0700 (PDT) From: Keith McCloghrie Message-Id: <200510071759.KAA07425@cisco.com> Subject: Re: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt To: bwijnen@lucent.com Date: Fri, 7 Oct 2005 10:59:50 -0700 (PDT) In-Reply-To: from "Wijnen, Bert (Bert)" at Oct 06, 2005 06:02:18 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: 7bit Cc: imss@ietf.org, orly_n@rad.co.il X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org 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 > ietf-ipr@ietf.org. > > > 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 imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 10 06:55:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvK1-0000nT-H3; Mon, 10 Oct 2005 06:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOvJz-0000mf-7E for imss@megatron.ietf.org; Mon, 10 Oct 2005 06:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01027 for ; Mon, 10 Oct 2005 06:55:52 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOvTs-0000o0-2L for imss@ietf.org; Mon, 10 Oct 2005 07:06:08 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9AAsG1o015035; Mon, 10 Oct 2005 05:54:17 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Oct 2005 12:54:15 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155083CF3F2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie Subject: RE: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.tx t--and 02 Date: Mon, 10 Oct 2005 12:54:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: imss@ietf.org, Orly Nicklass X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org 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:orly_n@rad.com] > Sent: Monday, October 10, 2005 10:03 > To: Keith McCloghrie; bwijnen@lucent.com > Cc: imss@ietf.org > 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:kzm@cisco.com] > Sent: Friday, October 07, 2005 20:00 > To: bwijnen@lucent.com > Cc: imss@ietf.org; 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 > > ietf-ipr@ietf.org. > > > > > > 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 imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 10 12:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0lh-0004MZ-AQ; Mon, 10 Oct 2005 12:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0le-0004Lq-Bq for imss@megatron.ietf.org; Mon, 10 Oct 2005 12:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05255 for ; Mon, 10 Oct 2005 12:44:47 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP0vX-0001KC-SV for imss@ietf.org; Mon, 10 Oct 2005 12:55:06 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2005 09:44:38 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9AGiZKC029453; Mon, 10 Oct 2005 09:44:36 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA05208; Mon, 10 Oct 2005 09:44:35 -0700 (PDT) From: Keith McCloghrie Message-Id: <200510101644.JAA05208@cisco.com> Subject: Re: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt--and 02 To: orly_n@rad.com (Orly Nicklass) Date: Mon, 10 Oct 2005 09:44:35 -0700 (PDT) In-Reply-To: from "Orly Nicklass" at Oct 10, 2005 10:02:44 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: bwijnen@lucent.com, Keith McCloghrie , imss@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org 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 imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 10 12:46:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0nI-0004uw-PD; Mon, 10 Oct 2005 12:46:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP0nE-0004tU-Jm for imss@megatron.ietf.org; Mon, 10 Oct 2005 12:46:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05308 for ; Mon, 10 Oct 2005 12:46:25 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP0xA-0001MI-Le for imss@ietf.org; Mon, 10 Oct 2005 12:56:45 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2005 09:46:19 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9AGkHKC000925; Mon, 10 Oct 2005 09:46:17 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA05436; Mon, 10 Oct 2005 09:46:16 -0700 (PDT) From: Keith McCloghrie Message-Id: <200510101646.JAA05436@cisco.com> Subject: Re: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.tx To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Mon, 10 Oct 2005 09:46:16 -0700 (PDT) In-Reply-To: from "Wijnen, Bert (Bert)" at Oct 10, 2005 12:54:11 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: imss@ietf.org, Keith McCloghrie , Orly Nicklass X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org I've put a new version at: ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fam-mib-02.txt > 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 I have removed "[RFC2741]". > !! 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 have changed "[RFC2863]" to "[IF-MIB]" > - 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 How is the RFC Editor going to know what "xxxx" is ?? I have changed it to : -- RFC Editor: replace yyyy with actual RFC number & remove this note > - For consistency, I think I would change > t11FabricAddrMgrMIB MODULE-IDENTITY > into > t11FamMIB MODULE-IDENTITY > but as I said, it is a nit. Thanks for catching this, but I believe that consistency requires it to be: t11FcFabricAddrMgrMIB MODULE-IDENTITY > - indentation for various MIB objects and descriptions is inconsistent I've fixed those that I could find. > 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. Dave Perkins suggested (about seven or eight years ago) that this be included in RFC 2578, but the WG rejected it. It is still in SMICng, but there a switch to ignore this "warning". I forget which switch it is. > 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. I have inserted into the MODULE-IDENTITY's DESCRIPTION After an agent reboot, the values of read-write objects defined in this MIB module are implementation-dependent. and near the end of each read-write object's DESCRIPTION: For the persistence of values across reboots, see the MODULE-IDENTITY's DESCRIPTION clause." > 2. In that same table, I see Counter32 objects, but nothing about possible > discontinuities and if any, which is the discontinuity timer. RFC 2578 says: ... Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Note: "... at other times as specified in the description ...". RFC 4181 does not alter this because it says: It is OK to use Counter32/64 for counters that may/will be reset when the management subsystem is re-initialized or when other unusual/irregular events occur ... However, if it is possible for such other unusual/irregular events to occur, the DESCRIPTION clause MUST state that this is so and MUST describe those other unusual/irregular events in sufficient detail that it is possible for a management application to determine whether a reset has occurred since the last time the counter was polled. The RECOMMENDED way to do this is to provide a discontinuity indicator as described in RFC 2578 Sections 7.1.6 and 7.1.10. Thus, the DESCRIPTION clause is required to mention discontinuities and have a discontinuity indicator *if* they can occur, not just at reboot, but at other times as well. So, it is appropriate for you to ask the question, but my answer is: no, there are no discontinuities other than at reboot, and thus, the text I have is fine. > 3. For t11FamIfRowStatus, I think you need to state if other writable column(s) > can be changed or not when in active state. The rule in RFC 4181 is broken -- it says: The DESCRIPTION clause of the status column MUST specify whether or not it is possible to modify other columns in the same conceptual row when the status value is active(1). Note that in many cases it will be possible to modify some writable columns when the row is active but not others. In such cases, the DESCRIPTION clause for each writable column SHOULD state whether or not that column can be modified when the row is active, and the DESCRIPTION clause for the status column SHOULD state that modifiability of other columns when the status value is active(1) is specified in the DESCRIPTION clauses for those columns (rather than listing the modifiable columns individually). Note that the first sentence says what MUST be in the DESCRIPTION clause. The second and third sentences give an example of when the first sentence is *wrong*, and a SHOULD applies instead. Further, it is possible for any table, T, defined in any MIB module, that a future MIB module could define new read-write objects in a new table which AUGMENTS T. Thus, the "In such cases" in third sentence above is a future possibility for all tables in all MIB modules. So, *all* RowStatus objects: ... SHOULD state that modifiability of other columns when the status value is active(1) is specified in the DESCRIPTION clauses for those columns (rather than listing the modifiable columns individually). i.e., this is boilerplate, and effectively redundant. Why do we require redundant text in DESCRIPTIONs ?? Furthermore, in this MIB, the MODULE-COMPLIANCE clause says that the MIN-ACCESS for both t11FamIfRcfReject and t11FamIfRowStatus is read-only, i.e., the implementation gets to choose whether write access is to be supported: a) at all times, b) at some times but not other times, or c) never. Thus, the OBJECT-TYPE cannot require that writable columns be change-able/not change-able at any specific times. In light of the above arguments, I propose to add: Implementations which support write-access to this object can do so under whatever conditions they choose." to the t11FamIfRcfReject's DESCRIPTION. Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 10 18:39:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6JH-0003BW-C5; Mon, 10 Oct 2005 18:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6JG-0003BI-Cu for imss@megatron.ietf.org; Mon, 10 Oct 2005 18:39:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00139 for ; Mon, 10 Oct 2005 18:39:51 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP6TE-0003uO-Ek for imss@ietf.org; Mon, 10 Oct 2005 18:50:14 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9AMdd2a006113; Mon, 10 Oct 2005 17:39:40 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Oct 2005 00:39:38 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550848F90E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie Subject: RE: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.tx Date: Tue, 11 Oct 2005 00:39:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: imss@ietf.org, orly_n@rad.com X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Inline > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Monday, October 10, 2005 18:46 > To: bwijnen@lucent.com > Cc: kzm@cisco.com; imss@ietf.org; orly_n@rad.com > Subject: Re: [imss] FW: MIB Doctor review > draft-ietf-imss-fc-fam-mib-01.tx > > > I've put a new version at: > > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fam-mib-02.txt > I'll try to take a look at it after I wake up (it is time to go to bed now) > > 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 > > I have removed "[RFC2741]". > Thanks > > !! 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 have changed "[RFC2863]" to "[IF-MIB]" > Not my preference, but valid and OK > > - 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 > > How is the RFC Editor going to know what "xxxx" is ?? I > have changed it to : > > -- RFC Editor: replace yyyy with actual RFC number & remove > this note > ;-) > > - For consistency, I think I would change > > t11FabricAddrMgrMIB MODULE-IDENTITY > > into > > t11FamMIB MODULE-IDENTITY > > but as I said, it is a nit. > > Thanks for catching this, but I believe that consistency > requires it to be: > > t11FcFabricAddrMgrMIB MODULE-IDENTITY > Keith, I can live with it. We named IF-MIB the ifMIB We named SNMP-VIEW-BASED-ACM-MIB the snmpVacmMIB We named SNMP-USER-BASED-SM-MIB the snmpUsmMIB So... I won't block on this. > > - indentation for various MIB objects and descriptions is > inconsistent > > I've fixed those that I could find. > > > 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. > > Dave Perkins suggested (about seven or eight years ago) that this be > included in RFC 2578, but the WG rejected it. It is still in SMICng, > but there a switch to ignore this "warning". I forget which > switch it is. > As I said, I think it is OK. Just wanted to hear/understand you are aware of it and are doing it consciously. I know the -Z switch in SMICng, so I can certainly suppress it and often do so. In fact I personally asked Perkins to add that switch if I recall correctly (like I have asked several other switches) > > 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. > > I have inserted into the MODULE-IDENTITY's DESCRIPTION > > After an agent reboot, the values of read-write objects > defined in this MIB module are implementation-dependent. > > and near the end of each read-write object's DESCRIPTION: > > For the persistence of values across reboots, see the > MODULE-IDENTITY's DESCRIPTION clause." > No my ideal. But as long as implementors can find what the expected behaviour is (i.e. undefined or non-deterministic as you seem to say), then I am fine with it. Implementors of applications will let the WG know if they are happy with that or not. > > 2. In that same table, I see Counter32 objects, but nothing about possible > > discontinuities and if any, which is the discontinuity timer. > > RFC 2578 says: > ... Discontinuities > in the monotonically increasing value normally occur at re- > initialization of the management system, and at other times as > specified in the description of an object-type using this ASN.1 type. > If such other times can occur, for example, the creation of an object > instance at times other than re-initialization, then a corresponding > object should be defined, with an appropriate SYNTAX clause, to > indicate the last discontinuity. > > Note: "... at other times as specified in the description > ...". RFC 4181 does not alter this because it says: > > It is OK to use Counter32/64 for counters that may/will be reset > when the management subsystem is re-initialized or when other > unusual/irregular events occur ... However, if it is > possible for such other unusual/irregular events to occur, the > DESCRIPTION clause MUST state that this is so and MUST describe > those other unusual/irregular events in sufficient detail that it > is possible for a management application to determine whether a > reset has occurred since the last time the counter was polled. The > RECOMMENDED way to do this is to provide a discontinuity indicator > as described in RFC 2578 Sections 7.1.6 and 7.1.10. > > Thus, the DESCRIPTION clause is required to mention discontinuities and have > a discontinuity indicator *if* they can occur, not just at reboot, but at > other times as well. > > So, it is appropriate for you to ask the question, but my answer is: > no, there are no discontinuities other than at reboot, and thus, the text > I have is fine. > And so all implementors have to wonder. Is the (in my view) missing text not there on purpose or was it left out by accident. Adding the explanation you provide here woudl make it clear for everyone, without trying to go search all the details in several other documents. > > 3. For t11FamIfRowStatus, I think you need to state if other writable column(s) > > can be changed or not when in active state. > > The rule in RFC 4181 is broken -- it says: > > The DESCRIPTION clause of the status column MUST specify whether > or not it is possible to modify other columns in the same > conceptual row when the status value is active(1). Note that in > many cases it will be possible to modify some writable columns > when the row is active but not others. In such cases, the > DESCRIPTION clause for each writable column SHOULD state whether > or not that column can be modified when the row is active, and > the DESCRIPTION clause for the status column SHOULD state that > modifiability of other columns when the status value is active(1) > is specified in the DESCRIPTION clauses for those columns (rather > than listing the modifiable columns individually). > > Note that the first sentence says what MUST be in the DESCRIPTION clause. > The second and third sentences give an example of when the first sentence > is *wrong*, and a SHOULD applies instead. > That is a separate discussion and you could have commented on that when we did IETF Last Call for that BCP document. > Further, it is possible for any table, T, defined in any MIB module, that > a future MIB module could define new read-write objects in a new table which > AUGMENTS T. Thus, the "In such cases" in third sentence above is a future > possibility for all tables in all MIB modules. So, *all* RowStatus objects: > > ... SHOULD state that modifiability of other columns when the status > value is active(1) is specified in the DESCRIPTION clauses for > those columns (rather than listing the modifiable columns > individually). > > i.e., this is boilerplate, and effectively redundant. Why do we require > redundant text in DESCRIPTIONs ?? > > Furthermore, in this MIB, the MODULE-COMPLIANCE clause says that the > MIN-ACCESS for both t11FamIfRcfReject and t11FamIfRowStatus is > read-only, i.e., the implementation gets to choose whether write > access is to be supported: a) at all times, b) at some times but not > other times, or c) never. Thus, the OBJECT-TYPE cannot require that > writable columns be change-able/not change-able at any specific times. > Well, that can be taken into account when you write the text, as it seems you are doing below. > In light of the above arguments, I propose to add: > > Implementations which support write-access to this object > can do so under whatever conditions they choose." > In other words, and application developer has no idea if such an object is writable or not and just has to use the trial and error method. If the IPS community is happy with that, then so be it. I personally do not suffer from such ambiguities. The IPS community who needs to develop management applications will suffer and experience less interoperability as a result. WG, is that what you want? > to the t11FamIfRcfReject's DESCRIPTION. > > Keith. > Bert _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Oct 11 15:51:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQA4-0001xj-3r; Tue, 11 Oct 2005 15:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQA2-0001xY-Oa for imss@megatron.ietf.org; Tue, 11 Oct 2005 15:51:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25390 for ; Tue, 11 Oct 2005 15:51:40 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPQKC-0006PZ-AE for imss@ietf.org; Tue, 11 Oct 2005 16:02:13 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9BJpcpR013657 for ; Tue, 11 Oct 2005 15:51:39 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Oct 2005 15:51:33 -0400 Message-ID: To: imss@ietf.org Date: Tue, 11 Oct 2005 15:51:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.11.23 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [imss] Tentative imss meeting time in Vancouver X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org The secretariat is working on stabilizing the meeting time schedule earlier than in the past - the final schedule will be out by the 17th. This is imss's tentative time slot: TUESDAY, November 8, 2005 1740-1840 Afternoon Session III APP crisp Cross Registry Information Service Protocol WG INT dhc Dynamic Host Configuration WG INT pana Protocol for Carrying Authenticaion for Network Access WG IRTF mobopts IP Mobility Optimizations RG OPS imss Internet and Management Support for Storage WG RTG rtgwg Routing Area WG SEC pki4ipsec Profiling Use of PKI in IPSEC WG TSV enum Telephone Number Mapping WG None of these look like conflict problems to me. FYI, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Tue Oct 11 16:37:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQs1-00074h-Hl; Tue, 11 Oct 2005 16:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQrz-00074Y-Hi for imss@megatron.ietf.org; Tue, 11 Oct 2005 16:37:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01967 for ; Tue, 11 Oct 2005 16:37:05 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPR29-0000ga-Jd for imss@ietf.org; Tue, 11 Oct 2005 16:47:38 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2005 13:36:57 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9BKatJh001140; Tue, 11 Oct 2005 13:36:55 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA10942; Tue, 11 Oct 2005 13:36:55 -0700 (PDT) From: Keith McCloghrie Message-Id: <200510112036.NAA10942@cisco.com> To: bwijnen@lucent.com Date: Tue, 11 Oct 2005 13:36:55 -0700 (PDT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: imss@ietf.org Subject: [imss] Submission of draft-ietf-imss-fc-nsm-mib-03.txt (fwd) X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Bert, FYI. I have submitted an updated version of draft-ietf-imss-fc-nsm-mib with a few nit-fixes. Keith. -------------- Forwarded message: > From: Keith McCloghrie > Message-Id: <200510112035.NAA09937@cisco.com> > Subject: Submission of draft-ietf-imss-fc-nsm-mib-03.txt > To: internet-drafts@ietf.org (Internet Drafts Submissions) > Date: Tue, 11 Oct 2005 13:35:14 -0700 (PDT) > Cc: black_david@emc.com, kzm@cisco.com (Keith McCloghrie) > > Please accept: > > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-nsm-mib-03.txt > > as a submission of a new version of the Internet-Draft. > > Thanks, > Keith. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Oct 12 10:37:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhjn-00014v-Or; Wed, 12 Oct 2005 10:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOscj-0007yq-L3 for imss@megatron.ietf.org; Mon, 10 Oct 2005 04:03:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23403 for ; Mon, 10 Oct 2005 04:03:02 -0400 (EDT) Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOsmW-0004ye-5A for imss@ietf.org; Mon, 10 Oct 2005 04:13:13 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j9A7xqYN003097 for ; Mon, 10 Oct 2005 09:59:53 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j9A7xqLx003094; Mon, 10 Oct 2005 09:59:52 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt--and 02 Date: Mon, 10 Oct 2005 10:02:44 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A5205641503@exrad2.ad.rad.co.il> Thread-Topic: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.txt--and 02 Thread-Index: AcXLcee3yGk9VD2vTPqNDWqAi4AXuQAehWsw From: "Orly Nicklass" To: "Keith McCloghrie" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 12 Oct 2005 10:37:47 -0400 Cc: imss@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org =20 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 =20 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:kzm@cisco.com]=20 Sent: Friday, October 07, 2005 20:00 To: bwijnen@lucent.com Cc: imss@ietf.org; 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. >=20 > Thanks to Orly for her review! >=20 > Pls copy her if you want her to see comments/questions/answers because > she is not subscribed to your mailing list. >=20 > W.r.t. to the comment on th eexpired draft: it has been (or will be=20 > 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=20 Let me know if/when I should submit it as the new I-D. Thanks, Keith. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My responses: > The draft has expired, and has been deleted from the Internet-Drafts=20 > directory. > ---------------------------------------------------------------------- > Here are 9 issues I found as potential items for fix: >=20 > 1.)Format---line(738) is too long =20 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". >=20 > Should be as follows: >=20 > Status of this Memo >=20 > 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. >=20 > 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. >=20 > 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." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on January 13, 2006. >=20 > Copyright Notice >=20 > Copyright (C) The Internet Society (2005). =20 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=20 > IPR > (7) are marked with numbers and=20 > listed in mixed order.=20 > - section 7 is redundant to 15 and seems as older version=20 > Should be as follows: >=20 > Intellectual Property Statement >=20 > 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. >=20 > 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. >=20 > 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 > ietf-ipr@ietf.org. >=20 >=20 > Disclaimer of Validity >=20 > 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. >=20 >=20 > Copyright Statement >=20 > 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. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. =20 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 >=20 > 5.) MIB Boilerplate -- ok =20 Above you said "9 issues" -- if #4 and #5 are "-- ok", why are they issues ??=20 > 6.) References -- > [FC-MGMT] draft-ietf-ips-fcmgmt-mib is RFC4044 by now "Fibre Channel=20 > Management MIB" [ON] You should use the RFC not the ID.? > RFC2837, was obsoleted by RFC4044, do we really need it?=20 =20 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 =20 Again, why is this an issue ?? > 8.) Introduction--some redundancy exit with the abstract, maybe=20 > combination with section 3. "Short Overview of Fibre Channel" > could have helped. =20 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=20 > 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=20 > [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=20 > the values-explanation was as the order in the enumeration OK. > --line:260: element #18 `t11FamPrincipalSwitchSelections' does not=20 > match order of > columnar objects under `t11FamEntry',=20 > 't11FamLocalPrincipalSwitchSlctns' is listed as #18 and affect the=20 > rest that follow it. > Better have the right order as the `t11FamEntry' listed and the=20 > corresponding OBJECT -GROUP =20 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) >=20 > It is recommended to change=20 > t11FamNotifications OBJECT IDENTIFIER ::=3D { t11FamMIBObjects 0 } >=20 > TO: > t11FamNotifications OBJECT IDENTIFIER ::=3D { t11FabricAddrMgrMIB 0 = } =20 Sigh, ... OK. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Oct 12 15:18:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPm7a-00033h-SK; Wed, 12 Oct 2005 15:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPm7Y-000325-Gq for imss@megatron.ietf.org; Wed, 12 Oct 2005 15:18:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12974 for ; Wed, 12 Oct 2005 15:18:33 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmHv-0004aQ-AD for imss@ietf.org; Wed, 12 Oct 2005 15:29:19 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9CJIQMH008121 for ; Wed, 12 Oct 2005 15:18:27 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Oct 2005 15:17:47 -0400 Message-ID: To: imss@ietf.org Date: Wed, 12 Oct 2005 15:17:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.12.22 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CHILD_PORN_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [imss] FW: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Internet Area Expert Review comments on the new IP over FC draft are below. Based on further conversation w/Brian, it's ok not to update the references (Section 17 comment below) in order to avoid getting caught in a REF (reference) hold at the RFC Editor. Many thanks to Brian for doing this review. The authors should prepare a -02 version of this draft to address these comments (and update the boilerplate while they're at it). They should make sure it passes the ID nits checker at: http://tools.ietf.org/tools/idnits/idnits.pyht before submitting. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net] Sent: Wednesday, October 12, 2005 9:18 AM To: Margaret Wasserman Cc: Black, David; Bert Wijnen Subject: Re: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt Margaret & Bert, Here are my comments on this draft. Overall, I think it looks pretty good. General Comments -------------------------- - The document needs to be consistent in its terminology on whether it is updating or obsoleting RFCs 2625 and 3831. The language in the Introduction seems to contradict the information in the document header. Section 3 ------------ - I would like to see some rationale/explanation for the values 1304 (in the fourth bullet) and 1024 (In the fifth bullet). How are those values derived and how are they related? Section 4.1 --------------- - The last paragraph allows more than one frame to be included in an IP FC Sequence. It states that only the first frame has an FC Network Header and LLC/SNAP Header. I assume that means that all frames in the sequence must be the same protocol. It would be nice if that was stated explicitly and some reasoning given. Section 4.3 -------------- - Does routing traffic need to be mentioned in this list? Specifically, how does routing traffic get handled? - Can the exceptions to the SHOULD be spelled out? Section 4.8 -------------- - With an MTU of 65280 octets is Jumbogram support needed? Section 5.2 -------------- - There is an implication that the FC U/L bit has the same semantics as the Ethernet U/L. I believe that is true, but it would help if it were mentioned. - I don't see the benefit of having both figures 9 & 10. Section 5.3 --------------- - I don't see the benefit of having both figures 12 & 13. - The last sentence contains an example interface ID of 3463:462A:BCDE:F789. I don't see where the x789 portion comes from? Is it just an example? It may be clearer to replace those with 'xxx'. Section 7 ------------ - The discussion of ARP opcodes should probably reference the [ARP] spec. Section 9.3 -------------- - (bullet 4) Should the responder cache info from the Request packet? Section 17 ------------- - The references to [AARCH], [ACONF], [DISC], and [ICMPv6] should probably be updated to the latest versions that are done or nearly done within the IPv6 WG. Regards, Brian _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Oct 12 15:50:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmcX-0002vz-Hf; Wed, 12 Oct 2005 15:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmbz-0002ck-8j; Wed, 12 Oct 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14456; Wed, 12 Oct 2005 15:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPmmL-0005Op-GX; Wed, 12 Oct 2005 16:00:46 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPmbx-0000W5-IT; Wed, 12 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-nsm-mib-03.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Fibre-Channel Name Server MIB Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-nsm-mib-03.txt Pages : 37 Date : 2005-10-12 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-nsm-mib-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-nsm-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-nsm-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-12110339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-nsm-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-nsm-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-12110339.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Wed Oct 12 17:47:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoRc-0006oy-2e; Wed, 12 Oct 2005 17:47:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoRa-0006ot-1u for imss@megatron.ietf.org; Wed, 12 Oct 2005 17:47:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07514 for ; Wed, 12 Oct 2005 17:47:22 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPobw-0006G9-7s for imss@ietf.org; Wed, 12 Oct 2005 17:58:10 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 Oct 2005 14:47:15 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9CLlCJh029223 for ; Wed, 12 Oct 2005 14:47:13 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA19738 for imss@ietf.org; Wed, 12 Oct 2005 14:47:12 -0700 (PDT) From: Keith McCloghrie Message-Id: <200510122147.OAA19738@cisco.com> To: imss@ietf.org Date: Wed, 12 Oct 2005 14:47:12 -0700 (PDT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [imss] More nit-fixes, and a new section X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Hi, Continuing my nit-fixing chores, I've created new versions of two more WG documents: ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fspf-mib-01.txt ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-rtm-mib-01.txt While updating draft-ietf-imss-fc-rtm-mib-01.txt, I remembered a question and answer about this MIB which had occurred in a T11.5 meeting, but had not been recorded/included in the text. I've rectified that by adding the following section: 5.5. The t11FcRouteTable's INDEX It is normally valuable for a MIB table which contains routes to be ordered such that a management application is able to query the table based on some attribute, without having to read every row in the MIB table. This requires the rows in the table be ordered according to such attributes, and thus, that those attributes be represented by objects included in the table's INDEX clause. Examples of this can be seen in the ipCidrRouteTable [RFC2096], and more recently, the inetCidrRouteTable in [RFC2096bis]. Providing the same useful feature in the MIB in this document, results in having an unusually large number (ten) of objects in the t11FcRouteTable's INDEX clause. However, all ten are either integers or strings of length 0 or 3 octets. Thus, the aggregate number of sub-identifiers to be appended to an OBJECT-TYPE's OID when naming an instance of an object in this table, is at most 22 sub-identifiers, i.e., less than the *minimum* number to be appended for the inetCidrRouteTable table. In other words, while ten is an unusually large number of objects in an INDEX clause, the resultant OIDs are not unusually large. If anyone has any comments on this text, or any other comments on either of the two new versions listed above, please let me know. If not, then I propose to submit the new versions as I-Ds. Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Oct 12 20:40:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPr9V-0001IY-At; Wed, 12 Oct 2005 20:40:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPr9U-0001IN-0O for imss@megatron.ietf.org; Wed, 12 Oct 2005 20:40:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14265 for ; Wed, 12 Oct 2005 20:40:51 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPrJr-0001Ub-Is for imss@ietf.org; Wed, 12 Oct 2005 20:51:42 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2005 17:40:44 -0700 X-IronPort-AV: i="3.97,208,1125903600"; d="scan'208"; a="351460730:sNHT33304144" Received: from [171.71.49.17] (dhcp-171-71-49-17.cisco.com [171.71.49.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9D0ed94027857; Wed, 12 Oct 2005 17:40:42 -0700 (PDT) Message-ID: <434DAD06.7020404@cisco.com> Date: Wed, 12 Oct 2005 17:40:38 -0700 From: Claudio DeSanti User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [imss] FW: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: 7bit Cc: imss@ietf.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org David, thanks for the comments, in-line are my answers. Please provide me feedback. Claudio. Black_David@emc.com wrote: > Internet Area Expert Review comments on the new IP over FC > draft are below. Based on further conversation w/Brian, it's > ok not to update the references (Section 17 comment below) in > order to avoid getting caught in a REF (reference) hold at > the RFC Editor. Many thanks to Brian for doing this review. > > The authors should prepare a -02 version of this draft > to address these comments (and update the boilerplate while > they're at it). They should make sure it passes the ID nits > checker at: > > http://tools.ietf.org/tools/idnits/idnits.pyht > > before submitting. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Wednesday, October 12, 2005 9:18 AM > To: Margaret Wasserman > Cc: Black, David; Bert Wijnen > Subject: Re: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt > > Margaret & Bert, > Here are my comments on this draft. Overall, I think it looks pretty > good. > > General Comments > -------------------------- > > - The document needs to be consistent in its terminology on > whether it is updating or obsoleting RFCs 2625 and 3831. > The language in the Introduction seems to contradict the > information in the document header. The current text says: "This document updates [RFC-2625] and, hence, replaces it." "This document incorporates and updates [RFC-3831] and, hence, replaces it." Would a more straightforward: "This document replaces [RFC-2625]." "This document replaces [RFC-3831]." be better? > > Section 3 > ------------ > > - I would like to see some rationale/explanation for the values > 1304 (in the fourth bullet) and 1024 (In the fifth bullet). How > are those values derived and how are they related? The 1304 bytes requirement just translates at layer 2 (with the Information Unit structure represented in figure 2) the minimum MTU required by IPv6 (as stated in the text). 1304 is 1280 (the minimum IPv6 MTU) + 8 (LLC/SNAP Header) + 16 (Network_Header). I don't think further clarification is needed. Th 1024 bytes requirement is needed for proper handling of multicast, and is discussed in detail in section 10. Would it be enough to add a reference to that section to the fifth bullet? > > Section 4.1 > --------------- > > - The last paragraph allows more than one frame to be included > in an IP FC Sequence. It states that only the first frame has an > FC Network Header and LLC/SNAP Header. I assume that > means that all frames in the sequence must be the same protocol. > It would be nice if that was stated explicitly and some reasoning > given. This is how the mapping of an IU to a Sequence is done, and is defined in FC-FS. FC-FS is referenced by this section, and I don't think we need to repeat here what is defined there. BTW, this section has the same text of RFC 3831. > > Section 4.3 > -------------- > > - Does routing traffic need to be mentioned in this list? > Specifically, > how does routing traffic get handled? The list is an e.g. list, and then it is not exhaustive. I can certainly add "IPv6/IPv4 Routing Protocols packets" to this list. > > - Can the exceptions to the SHOULD be spelled out? The reason for a SHOULD is to not completely close the door to Class 2 for unicast data traffic, in the case somebody want to do it. > > Section 4.8 > -------------- > > - With an MTU of 65280 octets is Jumbogram support needed? No, because Jumbogram support is required only for packets bigger than 65536 bytes. > > Section 5.2 > -------------- > > - There is an implication that the FC U/L bit has the same semantics > as the Ethernet U/L. I believe that is true, but it would help if > it were > mentioned. > > - I don't see the benefit of having both figures 9 & 10. There is no concept of U/L bit in Fibre Channel, because the N_Port_Name is used only as an identifier, not as a locator (i.e., it is not used to forward frames). However FC-FS defines a way to map FC N_Port_Names in IEEE EUI-64 addresses, and in the EUI-64 addresses the U/L bit is present. This is the reason for having both figure 9 and 10, to show how the EUI-64 address is derived, and then to use it for IPv6. BTW, the text in this section is the same as in RFC 3831. > > Section 5.3 > --------------- > > - I don't see the benefit of having both figures 12 & 13. Please see my comment above. > > - The last sentence contains an example interface ID of > 3463:462A:BCDE:F789. I don't see where the x789 > portion comes from? Is it just an example? It may be > clearer to replace those with 'xxx'. The x789 are the second to fourth nibbles in the originating N_Port_Name. All the examples in section 5 are carefully crafted to show how the addresses are manipulated. > > Section 7 > ------------ > > - The discussion of ARP opcodes should probably reference the > [ARP] spec. Would it be enough to change the line: "- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply;" to "- Opcode: 0x0001 for ARP Request, 0x0002 for ARP Reply (see [ARP]);"? > > Section 9.3 > -------------- > > - (bullet 4) Should the responder cache info from the Request packet? Yes, as required by [ARP]. What about changing the first sentence of bullet 4 from: "When a broadcast FC ARP Request is received by the Nx_Port with the matching IPv4 address, it generates a unicast FC ARP Reply." to: "When a broadcast FC ARP Request is received by the Nx_Port with the matching IPv4 address, that Nx_Port caches the information carried in the FC ARP Request in its local mapping tables and generates a unicast FC ARP Reply."? > > Section 17 > ------------- > > - The references to [AARCH], [ACONF], [DISC], and [ICMPv6] should > probably be updated to the latest versions that are done or nearly > done within the IPv6 WG. > > Regards, > Brian > > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Oct 13 17:55:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB2t-0005tt-UF; Thu, 13 Oct 2005 17:55:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQB2s-0005tW-Mz; Thu, 13 Oct 2005 17:55:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20120; Thu, 13 Oct 2005 17:55:22 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQBDS-0002NT-H0; Thu, 13 Oct 2005 18:06:23 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2005 14:55:17 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9DLtE94011193; Thu, 13 Oct 2005 14:55:14 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA26792; Thu, 13 Oct 2005 14:55:13 -0700 (PDT) From: Keith McCloghrie Message-Id: <200510132155.OAA26792@cisco.com> To: internet-drafts@ietf.org (Internet Drafts Submissions) Date: Thu, 13 Oct 2005 14:55:13 -0700 (PDT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: imss@ietf.org, Silvano Gai , H Vivek , Claudio Desanti , Keith McCloghrie Subject: [imss] submission of draft-kzm-imss-fc-zs-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Please accept: ftp://ftpeng.cisco.com/ftp/kzm/draft-kzm-imss-fc-zs-mib-01.txt as a submission of an updated version of the existing Internet-Draft. Thanks, Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Sun Oct 16 22:02:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERKKB-00039g-9I; Sun, 16 Oct 2005 22:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERKK9-000380-9b for imss@megatron.ietf.org; Sun, 16 Oct 2005 22:02:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07870 for ; Sun, 16 Oct 2005 22:01:54 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERKVN-0004L7-3j for imss@ietf.org; Sun, 16 Oct 2005 22:13:38 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9H21cIo017643; Sun, 16 Oct 2005 21:01:39 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Oct 2005 04:01:38 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568165@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Imss (E-mail)" , "David Black (E-mail)" , "Elizabeth G. Rodriguez (E-mail)" Date: Mon, 17 Oct 2005 04:01:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "David Kessens \(E-mail\)" Subject: [imss] Your new WG chair is: David Black X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org IMSS WG, Since David has been doing a great job ad interim or acting WG chair, I have asked him to become the permanent chair. He agrees to accept that position. So I will inform the Secretariat who will then update the WG charter pages. Let me also take this opportunity to thank Elizabeth for chairing the WG up till the time that her new job made it impossible (time-wise) to continue chairing. Bert co-AD for the IETF OPS area _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Oct 17 18:53:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdrZ-0003cm-F9; Mon, 17 Oct 2005 18:53:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERdrX-0003cT-NO for imss@megatron.ietf.org; Mon, 17 Oct 2005 18:53:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12953 for ; Mon, 17 Oct 2005 18:53:39 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERe2v-00074R-Kr for imss@ietf.org; Mon, 17 Oct 2005 19:05:36 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2005 15:53:36 -0700 X-IronPort-AV: i="3.97,225,1125903600"; d="scan'208"; a="221027695:sNHT25864560" Received: from [10.21.145.207] (sjc-vpn7-463.cisco.com [10.21.145.207]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9HMrXUw001544; Mon, 17 Oct 2005 15:53:34 -0700 (PDT) Message-ID: <43542B6D.3010300@cisco.com> Date: Mon, 17 Oct 2005 15:53:33 -0700 From: Claudio DeSanti User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [imss] FW: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: imss@ietf.org, t11_3@mail.t11.org X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org An updated I-D has been submitted. While the secretariat processes it, it may be accessed on the T11 web site by following this link: http://www.t11.org/t11/docreg.nsf/ufile/05-092v2 The resolution of the Internet Area Expert Review comments is also available on the T11 web site: http://www.t11.org/t11/docreg.nsf/ufile/05-741v0 Thanks, Claudio. Black_David@emc.com wrote: > Internet Area Expert Review comments on the new IP over FC > draft are below. Based on further conversation w/Brian, it's > ok not to update the references (Section 17 comment below) in > order to avoid getting caught in a REF (reference) hold at > the RFC Editor. Many thanks to Brian for doing this review. > > The authors should prepare a -02 version of this draft > to address these comments (and update the boilerplate while > they're at it). They should make sure it passes the ID nits > checker at: > > http://tools.ietf.org/tools/idnits/idnits.pyht > > before submitting. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Wednesday, October 12, 2005 9:18 AM > To: Margaret Wasserman > Cc: Black, David; Bert Wijnen > Subject: Re: INT Area Review: draft-ietf-imss-ip-over-fibre-channel-01.txt > > Margaret & Bert, > Here are my comments on this draft. Overall, I think it looks pretty > good. > > General Comments > -------------------------- > > - The document needs to be consistent in its terminology on > whether it is updating or obsoleting RFCs 2625 and 3831. > The language in the Introduction seems to contradict the > information in the document header. > > Section 3 > ------------ > > - I would like to see some rationale/explanation for the values > 1304 (in the fourth bullet) and 1024 (In the fifth bullet). How > are those values derived and how are they related? > > Section 4.1 > --------------- > > - The last paragraph allows more than one frame to be included > in an IP FC Sequence. It states that only the first frame has an > FC Network Header and LLC/SNAP Header. I assume that > means that all frames in the sequence must be the same protocol. > It would be nice if that was stated explicitly and some reasoning > given. > > Section 4.3 > -------------- > > - Does routing traffic need to be mentioned in this list? > Specifically, > how does routing traffic get handled? > > - Can the exceptions to the SHOULD be spelled out? > > Section 4.8 > -------------- > > - With an MTU of 65280 octets is Jumbogram support needed? > > Section 5.2 > -------------- > > - There is an implication that the FC U/L bit has the same semantics > as the Ethernet U/L. I believe that is true, but it would help if > it were > mentioned. > > - I don't see the benefit of having both figures 9 & 10. > > Section 5.3 > --------------- > > - I don't see the benefit of having both figures 12 & 13. > > - The last sentence contains an example interface ID of > 3463:462A:BCDE:F789. I don't see where the x789 > portion comes from? Is it just an example? It may be > clearer to replace those with 'xxx'. > > Section 7 > ------------ > > - The discussion of ARP opcodes should probably reference the > [ARP] spec. > > Section 9.3 > -------------- > > - (bullet 4) Should the responder cache info from the Request packet? > > Section 17 > ------------- > > - The references to [AARCH], [ACONF], [DISC], and [ICMPv6] should > probably be updated to the latest versions that are done or nearly > done within the IPv6 WG. > > Regards, > Brian > > _______________________________________________ > imss mailing list > imss@ietf.org > https://www1.ietf.org/mailman/listinfo/imss > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Wed Oct 19 15:51:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJya-0003F0-WB; Wed, 19 Oct 2005 15:51:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJww-0002hb-PZ; Wed, 19 Oct 2005 15:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09574; Wed, 19 Oct 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESK8d-0006lI-72; Wed, 19 Oct 2005 16:02:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESJwo-00063y-R2; Wed, 19 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Oct 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-ip-over-fibre-channel-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-ip-over-fibre-channel-02.txt Pages : 32 Date : 2005-10-19 This document specifies the way of encapsulating IPv6, IPv4 and ARP packets over Fibre Channel. This document specifies also the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-ip-over-fibre-channel-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-ip-over-fibre-channel-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-ip-over-fibre-channel-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-19131248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-ip-over-fibre-channel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-ip-over-fibre-channel-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-19131248.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Thu Oct 20 09:07:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESa8e-0003XD-Lb; Thu, 20 Oct 2005 09:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESa8a-0003PT-RN for imss@megatron.ietf.org; Thu, 20 Oct 2005 09:07:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09568 for ; Thu, 20 Oct 2005 09:07:06 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESaKV-0007j3-Jh for imss@ietf.org; Thu, 20 Oct 2005 09:19:37 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9KD6tQb023769; Thu, 20 Oct 2005 08:06:56 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 Oct 2005 15:06:55 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508568B52@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: cds@cisco.com, "David Black (E-mail)" Date: Thu, 20 Oct 2005 15:06:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: "Imss \(E-mail\)" , "Brian Haberman \(E-mail\)" Subject: [imss] AD review: draft-ietf-imss-ip-over-fibre-channel-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org OK, making a last check before I issue/request IETF Last Call. - I see (on front page): Category: Standards Track Replaces: RFC 2625, RFC 3831 I guess you mean that it Obsoletes 2625 and 3831 ?? I believe that "Obsoletes" is teh term that we use normally instead of "replaces" - Acknowledgements You may want to acknowledge the authors/editors of RFC2625 You can (as far as I am concerned) consider the above as initial IETF Last Call comments. If so, pls send me suggested updates for "Notes to RFC-Editor" for the acknowledgement section. For the first point I have: Note to RFC Editor - Front-page OLD: Replaces: RFC 2625, RFC 3831 NEW: Obsoletes: RFC 2625, RFC 3831 - Page 3: OLD: This document replaces [RFC-2625]. NEW: This document obsoletes [RFC-2625]. OLD: transmitted on a Fibre Channel network. This document replaces [RFC-3831]. NEW: transmitted on a Fibre Channel network. This document obsoletes [RFC-3831]. I can start an IETF Last Call now (unless you want to quickly spin another rev). In any event, I would do a 3-week IETF Last Call to cater for the busy time just before the IETF meeting. David, Let me know how you want me to proceed. Bert > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Wednesday, October 19, 2005 15:23 > To: bwijnen@lucent.com; brian@innovationslab.net > Cc: cds@cisco.com; Black_David@emc.com > Subject: RE: [imss] FW: INT Area Review: > draft-ietf-imss-ip-over-fibre-cha nnel-01.txt > > > Bert, > > These should be fine, we checked an earlier version of the > changes with Brian, and they were ok by him - what's in the > actual draft is not exactly what he reviewed, but the changes > are consistent with what he reviewed, and should still be fine > - double-checking doesn't hurt, though. > > Thanks, > --David > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Wednesday, October 19, 2005 8:12 AM > > To: Brian Haberman (E-mail) > > Cc: Claudio DeSanti; Black, David > > Subject: RE: [imss] FW: INT Area Review: > > draft-ietf-imss-ip-over-fibre-cha nnel-01.txt > > > > Brian, here is some action based on your review. > > Can youy check if that makes you happy? > > > > Claudio, pls do copy Brian explicitly when addrressing his > > review/comments, because he is not on the imss mailing list. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: imss-bounces@ietf.org > > [mailto:imss-bounces@ietf.org]On Behalf Of > > > Claudio DeSanti > > > Sent: Monday, October 17, 2005 18:54 > > > To: Black_David@emc.com > > > Cc: imss@ietf.org; t11_3@mail.t11.org > > > Subject: Re: [imss] FW: INT Area Review: > > > draft-ietf-imss-ip-over-fibre-channel-01.txt > > > > > > > > > An updated I-D has been submitted. While the secretariat > > > processes it, > > > it may be accessed on the T11 web site by following this link: > > > > > > http://www.t11.org/t11/docreg.nsf/ufile/05-092v2 > > > > > > The resolution of the Internet Area Expert Review > comments is also > > > available on the T11 web site: > > > > > > http://www.t11.org/t11/docreg.nsf/ufile/05-741v0 > > > > > > Thanks, > > > > > > Claudio. > > > > > > > > > Black_David@emc.com wrote: > > > > Internet Area Expert Review comments on the new IP over FC > > > > draft are below. Based on further conversation w/Brian, it's > > > > ok not to update the references (Section 17 comment below) in > > > > order to avoid getting caught in a REF (reference) hold at > > > > the RFC Editor. Many thanks to Brian for doing this review. > > > > > > > > The authors should prepare a -02 version of this draft > > > > to address these comments (and update the boilerplate while > > > > they're at it). They should make sure it passes the ID nits > > > > checker at: > > > > > > > > http://tools.ietf.org/tools/idnits/idnits.pyht > > > > > > > > before submitting. > > > > > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Senior Technologist > > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > > > > > -----Original Message----- > > > > From: Brian Haberman [mailto:brian@innovationslab.net] > > > > Sent: Wednesday, October 12, 2005 9:18 AM > > > > To: Margaret Wasserman > > > > Cc: Black, David; Bert Wijnen > > > > Subject: Re: INT Area Review: > > > draft-ietf-imss-ip-over-fibre-channel-01.txt > > > > > > > > Margaret & Bert, > > > > Here are my comments on this draft. Overall, I think > > > it looks pretty > > > > good. > > > > > > > > General Comments > > > > -------------------------- > > > > > > > > - The document needs to be consistent in its > terminology on > > > > whether it is updating or obsoleting RFCs 2625 > and 3831. > > > > The language in the Introduction seems to > contradict the > > > > information in the document header. > > > > > > > > Section 3 > > > > ------------ > > > > > > > > - I would like to see some rationale/explanation for > > > the values > > > > 1304 (in the fourth bullet) and 1024 (In the fifth > > > bullet). How > > > > are those values derived and how are they related? > > > > > > > > Section 4.1 > > > > --------------- > > > > > > > > - The last paragraph allows more than one frame to > > be included > > > > in an IP FC Sequence. It states that only the > > > first frame has an > > > > FC Network Header and LLC/SNAP Header. I assume that > > > > means that all frames in the sequence must be the > > > same protocol. > > > > It would be nice if that was stated explicitly and > > > some reasoning > > > > given. > > > > > > > > Section 4.3 > > > > -------------- > > > > > > > > - Does routing traffic need to be mentioned in this list? > > > > Specifically, > > > > how does routing traffic get handled? > > > > > > > > - Can the exceptions to the SHOULD be spelled out? > > > > > > > > Section 4.8 > > > > -------------- > > > > > > > > - With an MTU of 65280 octets is Jumbogram support needed? > > > > > > > > Section 5.2 > > > > -------------- > > > > > > > > - There is an implication that the FC U/L bit has the > > > same semantics > > > > as the Ethernet U/L. I believe that is true, but > > > it would help if > > > > it were > > > > mentioned. > > > > > > > > - I don't see the benefit of having both figures 9 & 10. > > > > > > > > Section 5.3 > > > > --------------- > > > > > > > > - I don't see the benefit of having both figures 12 & 13. > > > > > > > > - The last sentence contains an example interface ID of > > > > 3463:462A:BCDE:F789. I don't see where the x789 > > > > portion comes from? Is it just an example? It may be > > > > clearer to replace those with 'xxx'. > > > > > > > > Section 7 > > > > ------------ > > > > > > > > - The discussion of ARP opcodes should probably > > reference the > > > > [ARP] spec. > > > > > > > > Section 9.3 > > > > -------------- > > > > > > > > - (bullet 4) Should the responder cache info from the > > > Request packet? > > > > > > > > Section 17 > > > > ------------- > > > > > > > > - The references to [AARCH], [ACONF], [DISC], and > > > [ICMPv6] should > > > > probably be updated to the latest versions that > > > are done or nearly > > > > done within the IPv6 WG. > > > > > > > > Regards, > > > > Brian > > > > > > > > _______________________________________________ > > > > imss mailing list > > > > imss@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > > > > > > _______________________________________________ > > > imss mailing list > > > imss@ietf.org > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Oct 20 13:57:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESefh-0005uG-OH; Thu, 20 Oct 2005 13:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESefe-0005u2-UC for imss@megatron.ietf.org; Thu, 20 Oct 2005 13:57:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03600 for ; Thu, 20 Oct 2005 13:57:33 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESerd-0002lY-QH for imss@ietf.org; Thu, 20 Oct 2005 14:10:06 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2005 10:57:33 -0700 X-IronPort-AV: i="3.97,236,1125903600"; d="scan'208"; a="222128449:sNHT28120552" Received: from [171.71.49.234] (dhcp-171-71-49-234.cisco.com [171.71.49.234]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9KHvR8k025110; Thu, 20 Oct 2005 10:57:28 -0700 (PDT) Message-ID: <4357DA8B.5080808@cisco.com> Date: Thu, 20 Oct 2005 10:57:31 -0700 From: Claudio DeSanti User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" References: <7D5D48D2CAA3D84C813F5B154F43B15508568B52@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508568B52@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: 7bit Cc: "Imss \(E-mail\)" , "David Black \(E-mail\)" , "Brian Haberman \(E-mail\)" Subject: [imss] Re: AD review: draft-ietf-imss-ip-over-fibre-channel-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Hi Bert, I am perfectly fine in starting an IETF last call now and handling your comments as last call comments. I would prefer to spin another revision, if needed, after the last call rather than before. Thanks, Claudio. Wijnen, Bert (Bert) wrote: > OK, making a last check before I issue/request IETF Last Call. > > - I see (on front page): > > Category: Standards Track > Replaces: RFC 2625, RFC 3831 > > I guess you mean that it Obsoletes 2625 and 3831 ?? > I believe that "Obsoletes" is teh term that we use normally > instead of "replaces" > > - Acknowledgements > You may want to acknowledge the authors/editors of RFC2625 > > You can (as far as I am concerned) consider the above as initial IETF Last > Call comments. If so, pls send me suggested updates for "Notes to RFC-Editor" > for the acknowledgement section. For the first point I have: > > Note to RFC Editor > > - Front-page > OLD: > Replaces: RFC 2625, RFC 3831 > NEW: > Obsoletes: RFC 2625, RFC 3831 > > - Page 3: > OLD: > This document replaces [RFC-2625]. > NEW: > This document obsoletes [RFC-2625]. > > OLD: > transmitted on a Fibre Channel network. This document replaces > [RFC-3831]. > NEW: > transmitted on a Fibre Channel network. This document obsoletes > [RFC-3831]. > > I can start an IETF Last Call now (unless you want to quickly spin another > rev). In any event, I would do a 3-week IETF Last Call to cater for the > busy time just before the IETF meeting. > > David, Let me know how you want me to proceed. > > Bert > >>-----Original Message----- >>From: Black_David@emc.com [mailto:Black_David@emc.com] >>Sent: Wednesday, October 19, 2005 15:23 >>To: bwijnen@lucent.com; brian@innovationslab.net >>Cc: cds@cisco.com; Black_David@emc.com >>Subject: RE: [imss] FW: INT Area Review: >>draft-ietf-imss-ip-over-fibre-cha nnel-01.txt >> >> >>Bert, >> >>These should be fine, we checked an earlier version of the >>changes with Brian, and they were ok by him - what's in the >>actual draft is not exactly what he reviewed, but the changes >>are consistent with what he reviewed, and should still be fine >>- double-checking doesn't hurt, though. >> >>Thanks, >>--David >> >> >>>-----Original Message----- >>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >>>Sent: Wednesday, October 19, 2005 8:12 AM >>>To: Brian Haberman (E-mail) >>>Cc: Claudio DeSanti; Black, David >>>Subject: RE: [imss] FW: INT Area Review: >>>draft-ietf-imss-ip-over-fibre-cha nnel-01.txt >>> >>>Brian, here is some action based on your review. >>>Can youy check if that makes you happy? >>> >>>Claudio, pls do copy Brian explicitly when addrressing his >>>review/comments, because he is not on the imss mailing list. >>> >>>Thanks, >>>Bert >>> >>> >>>>-----Original Message----- >>>>From: imss-bounces@ietf.org >>> >>>[mailto:imss-bounces@ietf.org]On Behalf Of >>> >>>>Claudio DeSanti >>>>Sent: Monday, October 17, 2005 18:54 >>>>To: Black_David@emc.com >>>>Cc: imss@ietf.org; t11_3@mail.t11.org >>>>Subject: Re: [imss] FW: INT Area Review: >>>>draft-ietf-imss-ip-over-fibre-channel-01.txt >>>> >>>> >>>>An updated I-D has been submitted. While the secretariat >>>>processes it, >>>>it may be accessed on the T11 web site by following this link: >>>> >>>>http://www.t11.org/t11/docreg.nsf/ufile/05-092v2 >>>> >>>>The resolution of the Internet Area Expert Review >> >>comments is also >> >>>>available on the T11 web site: >>>> >>>>http://www.t11.org/t11/docreg.nsf/ufile/05-741v0 >>>> >>>>Thanks, >>>> >>>> Claudio. >>>> >>>> >>>>Black_David@emc.com wrote: >>>> >>>>>Internet Area Expert Review comments on the new IP over FC >>>>>draft are below. Based on further conversation w/Brian, it's >>>>>ok not to update the references (Section 17 comment below) in >>>>>order to avoid getting caught in a REF (reference) hold at >>>>>the RFC Editor. Many thanks to Brian for doing this review. >>>>> >>>>>The authors should prepare a -02 version of this draft >>>>>to address these comments (and update the boilerplate while >>>>>they're at it). They should make sure it passes the ID nits >>>>>checker at: >>>>> >>>>>http://tools.ietf.org/tools/idnits/idnits.pyht >>>>> >>>>>before submitting. >>>>> >>>>>Thanks, >>>>>--David >>>>>---------------------------------------------------- >>>>>David L. Black, Senior Technologist >>>>>EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>>>+1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>black_david@emc.com Mobile: +1 (978) 394-7754 >>>>>---------------------------------------------------- >>>>> >>>>>-----Original Message----- >>>>>From: Brian Haberman [mailto:brian@innovationslab.net] >>>>>Sent: Wednesday, October 12, 2005 9:18 AM >>>>>To: Margaret Wasserman >>>>>Cc: Black, David; Bert Wijnen >>>>>Subject: Re: INT Area Review: >>>> >>>>draft-ietf-imss-ip-over-fibre-channel-01.txt >>>> >>>>>Margaret & Bert, >>>>> Here are my comments on this draft. Overall, I think >>>> >>>>it looks pretty >>>> >>>>>good. >>>>> >>>>>General Comments >>>>>-------------------------- >>>>> >>>>> - The document needs to be consistent in its >> >>terminology on >> >>>>> whether it is updating or obsoleting RFCs 2625 >> >>and 3831. >> >>>>> The language in the Introduction seems to >> >>contradict the >> >>>>> information in the document header. >>>>> >>>>>Section 3 >>>>>------------ >>>>> >>>>> - I would like to see some rationale/explanation for >>>> >>>>the values >>>> >>>>> 1304 (in the fourth bullet) and 1024 (In the fifth >>>> >>>>bullet). How >>>> >>>>> are those values derived and how are they related? >>>>> >>>>>Section 4.1 >>>>>--------------- >>>>> >>>>> - The last paragraph allows more than one frame to >>> >>>be included >>> >>>>> in an IP FC Sequence. It states that only the >>>> >>>>first frame has an >>>> >>>>> FC Network Header and LLC/SNAP Header. I assume that >>>>> means that all frames in the sequence must be the >>>> >>>>same protocol. >>>> >>>>> It would be nice if that was stated explicitly and >>>> >>>>some reasoning >>>> >>>>> given. >>>>> >>>>>Section 4.3 >>>>>-------------- >>>>> >>>>> - Does routing traffic need to be mentioned in this list? >>>>>Specifically, >>>>> how does routing traffic get handled? >>>>> >>>>> - Can the exceptions to the SHOULD be spelled out? >>>>> >>>>>Section 4.8 >>>>>-------------- >>>>> >>>>> - With an MTU of 65280 octets is Jumbogram support needed? >>>>> >>>>>Section 5.2 >>>>>-------------- >>>>> >>>>> - There is an implication that the FC U/L bit has the >>>> >>>>same semantics >>>> >>>>> as the Ethernet U/L. I believe that is true, but >>>> >>>>it would help if >>>> >>>>>it were >>>>> mentioned. >>>>> >>>>> - I don't see the benefit of having both figures 9 & 10. >>>>> >>>>>Section 5.3 >>>>>--------------- >>>>> >>>>> - I don't see the benefit of having both figures 12 & 13. >>>>> >>>>> - The last sentence contains an example interface ID of >>>>> 3463:462A:BCDE:F789. I don't see where the x789 >>>>> portion comes from? Is it just an example? It may be >>>>> clearer to replace those with 'xxx'. >>>>> >>>>>Section 7 >>>>>------------ >>>>> >>>>> - The discussion of ARP opcodes should probably >>> >>>reference the >>> >>>>> [ARP] spec. >>>>> >>>>>Section 9.3 >>>>>-------------- >>>>> >>>>> - (bullet 4) Should the responder cache info from the >>>> >>>>Request packet? >>>> >>>>>Section 17 >>>>>------------- >>>>> >>>>> - The references to [AARCH], [ACONF], [DISC], and >>>> >>>>[ICMPv6] should >>>> >>>>> probably be updated to the latest versions that >>>> >>>>are done or nearly >>>> >>>>> done within the IPv6 WG. >>>>> >>>>>Regards, >>>>>Brian >>>>> >>>>>_______________________________________________ >>>>>imss mailing list >>>>>imss@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/imss >>>>> >>>> >>>>_______________________________________________ >>>>imss mailing list >>>>imss@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/imss >>>> >>> > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Oct 20 15:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgTg-0002dA-JI; Thu, 20 Oct 2005 15:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESgQZ-0001FD-H5; Thu, 20 Oct 2005 15:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10049; Thu, 20 Oct 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESgcO-0006U4-7e; Thu, 20 Oct 2005 16:02:33 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESgQN-0000xK-5D; Thu, 20 Oct 2005 15:50:03 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Oct 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-fam-mib-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Fibre Channel Fabric Address Manager MIB Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-fam-mib-02.txt Pages : 43 Date : 2005-10-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fam-mib-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-fam-mib-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-fam-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-20142759.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-fam-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-fam-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-20142759.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Thu Oct 20 17:03:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShZZ-000519-8L; Thu, 20 Oct 2005 17:03:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EShV1-0000jT-MG for imss@megatron.ietf.org; Thu, 20 Oct 2005 16:58:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01644 for ; Thu, 20 Oct 2005 16:53:21 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EShU6-0000Li-83 for imss@ietf.org; Thu, 20 Oct 2005 16:57:58 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9KKiiJP009043; Thu, 20 Oct 2005 16:45:06 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Oct 2005 16:43:30 -0400 Message-ID: To: bwijnen@lucent.com Date: Thu, 20 Oct 2005 16:43:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.20.23 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CHILD_PORN_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: imss@ietf.org, brian@innovationslab.net, cds@cisco.com Subject: [imss] RE: AD review: draft-ietf-imss-ip-over-fibre-channel-02.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Bert, I agree. Please start the IETF Last Call now - running it for 3 weeks so that it ends around the end of the Vancouver meeting week makes sense to me. Let's plan a quick respin after IETF Last Call to fix the "obsoletes" text and get the Acknowledgements updated. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Claudio DeSanti [mailto:cds@cisco.com] > Sent: Thursday, October 20, 2005 1:58 PM > To: Wijnen, Bert (Bert) > Cc: Black, David; Imss (E-mail); Brian Haberman (E-mail) > Subject: Re: AD review: draft-ietf-imss-ip-over-fibre-channel-02.txt > > Hi Bert, > > I am perfectly fine in starting an IETF last call now and handling your > comments as last call comments. I would prefer to spin another revision, > if needed, after the last call rather than before. > > Thanks, > > Claudio. > > > Wijnen, Bert (Bert) wrote: > > OK, making a last check before I issue/request IETF Last Call. > > > > - I see (on front page): > > > > Category: Standards Track > > Replaces: RFC 2625, RFC 3831 > > > > I guess you mean that it Obsoletes 2625 and 3831 ?? > > I believe that "Obsoletes" is teh term that we use normally > > instead of "replaces" > > > > - Acknowledgements > > You may want to acknowledge the authors/editors of RFC2625 > > > > You can (as far as I am concerned) consider the above as > initial IETF Last > > Call comments. If so, pls send me suggested updates for > "Notes to RFC-Editor" > > for the acknowledgement section. For the first point I have: > > > > Note to RFC Editor > > > > - Front-page > > OLD: > > Replaces: RFC 2625, RFC 3831 > > NEW: > > Obsoletes: RFC 2625, RFC 3831 > > > > - Page 3: > > OLD: > > This document replaces [RFC-2625]. > > NEW: > > This document obsoletes [RFC-2625]. > > > > OLD: > > transmitted on a Fibre Channel network. This document replaces > > [RFC-3831]. > > NEW: > > transmitted on a Fibre Channel network. This document obsoletes > > [RFC-3831]. > > > > I can start an IETF Last Call now (unless you want to quickly spin another > > rev). In any event, I would do a 3-week IETF Last Call to cater for the > > busy time just before the IETF meeting. > > > > David, Let me know how you want me to proceed. > > > > Bert > > > >>-----Original Message----- > >>From: Black_David@emc.com [mailto:Black_David@emc.com] > >>Sent: Wednesday, October 19, 2005 15:23 > >>To: bwijnen@lucent.com; brian@innovationslab.net > >>Cc: cds@cisco.com; Black_David@emc.com > >>Subject: RE: [imss] FW: INT Area Review: > >>draft-ietf-imss-ip-over-fibre-cha nnel-01.txt > >> > >> > >>Bert, > >> > >>These should be fine, we checked an earlier version of the > >>changes with Brian, and they were ok by him - what's in the > >>actual draft is not exactly what he reviewed, but the changes > >>are consistent with what he reviewed, and should still be fine > >>- double-checking doesn't hurt, though. > >> > >>Thanks, > >>--David > >> > >> > >>>-----Original Message----- > >>>From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > >>>Sent: Wednesday, October 19, 2005 8:12 AM > >>>To: Brian Haberman (E-mail) > >>>Cc: Claudio DeSanti; Black, David > >>>Subject: RE: [imss] FW: INT Area Review: > >>>draft-ietf-imss-ip-over-fibre-cha nnel-01.txt > >>> > >>>Brian, here is some action based on your review. > >>>Can youy check if that makes you happy? > >>> > >>>Claudio, pls do copy Brian explicitly when addrressing his > >>>review/comments, because he is not on the imss mailing list. > >>> > >>>Thanks, > >>>Bert > >>> > >>> > >>>>-----Original Message----- > >>>>From: imss-bounces@ietf.org > >>> > >>>[mailto:imss-bounces@ietf.org]On Behalf Of > >>> > >>>>Claudio DeSanti > >>>>Sent: Monday, October 17, 2005 18:54 > >>>>To: Black_David@emc.com > >>>>Cc: imss@ietf.org; t11_3@mail.t11.org > >>>>Subject: Re: [imss] FW: INT Area Review: > >>>>draft-ietf-imss-ip-over-fibre-channel-01.txt > >>>> > >>>> > >>>>An updated I-D has been submitted. While the secretariat > >>>>processes it, > >>>>it may be accessed on the T11 web site by following this link: > >>>> > >>>>http://www.t11.org/t11/docreg.nsf/ufile/05-092v2 > >>>> > >>>>The resolution of the Internet Area Expert Review > >> > >>comments is also > >> > >>>>available on the T11 web site: > >>>> > >>>>http://www.t11.org/t11/docreg.nsf/ufile/05-741v0 > >>>> > >>>>Thanks, > >>>> > >>>> Claudio. > >>>> > >>>> > >>>>Black_David@emc.com wrote: > >>>> > >>>>>Internet Area Expert Review comments on the new IP over FC > >>>>>draft are below. Based on further conversation w/Brian, it's > >>>>>ok not to update the references (Section 17 comment below) in > >>>>>order to avoid getting caught in a REF (reference) hold at > >>>>>the RFC Editor. Many thanks to Brian for doing this review. > >>>>> > >>>>>The authors should prepare a -02 version of this draft > >>>>>to address these comments (and update the boilerplate while > >>>>>they're at it). They should make sure it passes the ID nits > >>>>>checker at: > >>>>> > >>>>>http://tools.ietf.org/tools/idnits/idnits.pyht > >>>>> > >>>>>before submitting. > >>>>> > >>>>>Thanks, > >>>>>--David > >>>>>---------------------------------------------------- > >>>>>David L. Black, Senior Technologist > >>>>>EMC Corporation, 176 South St., Hopkinton, MA 01748 > >>>>>+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >>>>>black_david@emc.com Mobile: +1 (978) 394-7754 > >>>>>---------------------------------------------------- > >>>>> > >>>>>-----Original Message----- > >>>>>From: Brian Haberman [mailto:brian@innovationslab.net] > >>>>>Sent: Wednesday, October 12, 2005 9:18 AM > >>>>>To: Margaret Wasserman > >>>>>Cc: Black, David; Bert Wijnen > >>>>>Subject: Re: INT Area Review: > >>>> > >>>>draft-ietf-imss-ip-over-fibre-channel-01.txt > >>>> > >>>>>Margaret & Bert, > >>>>> Here are my comments on this draft. Overall, I think > >>>> > >>>>it looks pretty > >>>> > >>>>>good. > >>>>> > >>>>>General Comments > >>>>>-------------------------- > >>>>> > >>>>> - The document needs to be consistent in its > >> > >>terminology on > >> > >>>>> whether it is updating or obsoleting RFCs 2625 > >> > >>and 3831. > >> > >>>>> The language in the Introduction seems to > >> > >>contradict the > >> > >>>>> information in the document header. > >>>>> > >>>>>Section 3 > >>>>>------------ > >>>>> > >>>>> - I would like to see some rationale/explanation for > >>>> > >>>>the values > >>>> > >>>>> 1304 (in the fourth bullet) and 1024 (In the fifth > >>>> > >>>>bullet). How > >>>> > >>>>> are those values derived and how are they related? > >>>>> > >>>>>Section 4.1 > >>>>>--------------- > >>>>> > >>>>> - The last paragraph allows more than one frame to > >>> > >>>be included > >>> > >>>>> in an IP FC Sequence. It states that only the > >>>> > >>>>first frame has an > >>>> > >>>>> FC Network Header and LLC/SNAP Header. I assume that > >>>>> means that all frames in the sequence must be the > >>>> > >>>>same protocol. > >>>> > >>>>> It would be nice if that was stated explicitly and > >>>> > >>>>some reasoning > >>>> > >>>>> given. > >>>>> > >>>>>Section 4.3 > >>>>>-------------- > >>>>> > >>>>> - Does routing traffic need to be mentioned in this list? > >>>>>Specifically, > >>>>> how does routing traffic get handled? > >>>>> > >>>>> - Can the exceptions to the SHOULD be spelled out? > >>>>> > >>>>>Section 4.8 > >>>>>-------------- > >>>>> > >>>>> - With an MTU of 65280 octets is Jumbogram support needed? > >>>>> > >>>>>Section 5.2 > >>>>>-------------- > >>>>> > >>>>> - There is an implication that the FC U/L bit has the > >>>> > >>>>same semantics > >>>> > >>>>> as the Ethernet U/L. I believe that is true, but > >>>> > >>>>it would help if > >>>> > >>>>>it were > >>>>> mentioned. > >>>>> > >>>>> - I don't see the benefit of having both figures 9 & 10. > >>>>> > >>>>>Section 5.3 > >>>>>--------------- > >>>>> > >>>>> - I don't see the benefit of having both figures 12 & 13. > >>>>> > >>>>> - The last sentence contains an example interface ID of > >>>>> 3463:462A:BCDE:F789. I don't see where the x789 > >>>>> portion comes from? Is it just an example? It may be > >>>>> clearer to replace those with 'xxx'. > >>>>> > >>>>>Section 7 > >>>>>------------ > >>>>> > >>>>> - The discussion of ARP opcodes should probably > >>> > >>>reference the > >>> > >>>>> [ARP] spec. > >>>>> > >>>>>Section 9.3 > >>>>>-------------- > >>>>> > >>>>> - (bullet 4) Should the responder cache info from the > >>>> > >>>>Request packet? > >>>> > >>>>>Section 17 > >>>>>------------- > >>>>> > >>>>> - The references to [AARCH], [ACONF], [DISC], and > >>>> > >>>>[ICMPv6] should > >>>> > >>>>> probably be updated to the latest versions that > >>>> > >>>>are done or nearly > >>>> > >>>>> done within the IPv6 WG. > >>>>> > >>>>>Regards, > >>>>>Brian > >>>>> > >>>>>_______________________________________________ > >>>>>imss mailing list > >>>>>imss@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/imss > >>>>> > >>>> > >>>>_______________________________________________ > >>>>imss mailing list > >>>>imss@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/imss > >>>> > >>> > > > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Oct 20 18:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjIM-0007Ay-90; Thu, 20 Oct 2005 18:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjIH-00079L-22; Thu, 20 Oct 2005 18:53:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20691; Thu, 20 Oct 2005 18:53:43 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESjUI-0004tY-MC; Thu, 20 Oct 2005 19:06:18 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ESjIG-0006EL-5S; Thu, 20 Oct 2005 18:53:52 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 20 Oct 2005 18:53:52 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: imss@ietf.org Subject: [imss] Last Call: 'Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel' to Proposed Standard X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org The IESG has received a request from the Internet and Management Support for Storage WG to consider the following document: - 'Transmission of IPv6, IPv4 and ARP Packets over Fibre Channel ' as a Proposed Standard This document (once approved) will obsolete RFC2625 and RFC3831. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imss-ip-over-fibre-channel-02.txt _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Oct 21 15:50:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2uI-0003zf-8F; Fri, 21 Oct 2005 15:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2tw-0003oR-6q; Fri, 21 Oct 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29942; Fri, 21 Oct 2005 15:49:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET366-0004XO-UI; Fri, 21 Oct 2005 16:02:39 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tt-0001CR-DK; Fri, 21 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-rtm-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : Fibre-Channel Routing Information MIB Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-rtm-mib-01.txt Pages : 22 Date : 2005-10-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric which is independent of the usage of a particular routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-rtm-mib-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-rtm-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-rtm-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21105010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-rtm-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-rtm-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21105010.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Fri Oct 21 15:51:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2uy-0004Gi-MH; Fri, 21 Oct 2005 15:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET2ty-0003pd-6g; Fri, 21 Oct 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29966; Fri, 21 Oct 2005 15:49:54 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET366-0004XQ-VD; Fri, 21 Oct 2005 16:02:40 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tt-0001CW-EE; Fri, 21 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-fspf-mib-01.txt X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF. Title : MIB for Fibre-Channel's Fabric Shortest Path First Protocol Author(s) : C. DeSanti, et al. Filename : draft-ietf-imss-fc-fspf-mib-01.txt Pages : 40 Date : 2005-10-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fspf-mib-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imss-fc-fspf-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imss-fc-fspf-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21130527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-fspf-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-fspf-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21130527.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss --NextPart-- From imss-bounces@ietf.org Fri Oct 21 21:51:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET8Xm-0005jn-Ux; Fri, 21 Oct 2005 21:51:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET8Xl-0005iM-OG for imss@megatron.ietf.org; Fri, 21 Oct 2005 21:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11365 for ; Fri, 21 Oct 2005 21:51:22 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET8k0-00025D-Pq for imss@ietf.org; Fri, 21 Oct 2005 22:04:14 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9M1pUle012695 for ; Fri, 21 Oct 2005 21:51:30 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Oct 2005 21:51:29 -0400 Message-ID: To: imss@ietf.org Date: Fri, 21 Oct 2005 21:51:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.21.34 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __KNOWN_SPAMMER_ADDRESS_5 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [imss] Vancouver Agenda X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: imss-bounces@ietf.org Errors-To: imss-bounces@ietf.org Here's the draft agenda for imss in Vancouver. It can be bashed further in the meeting. Internet and Management Support for Storage (imss) WG Meeting - Vancouver, Canada Tuesday, November 8, 2005: 1740-1840 ------------------------------------------------------ Administrivia, agenda bashing, draft status review, etc.: 15 min David L. Black, EMC (new imss WG chair) Blue sheets Note Well Milestones Draft status T11.5 Status, Fibre Channel MIBs under development: 20 min Roger Cummings (Symantec, T11.5 chair) FLIP (FAIS Line Interface Protocol) Conceptual Discussion: 25 min Roger Cummings (Symantec, T11.5 chair) draft-cummings-imss-flip-00.txt ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss