From imss-bounces@ietf.org Wed Apr 05 17:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFll-0008Qn-ML; Wed, 05 Apr 2006 17:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFlk-0008Oz-64 for imss@ietf.org; Wed, 05 Apr 2006 17:42:28 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFlj-0006wH-Q7 for imss@ietf.org; Wed, 05 Apr 2006 17:42:28 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k35Lfvpv000819; Wed, 5 Apr 2006 16:41:58 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <2JG5RZ5P>; Wed, 5 Apr 2006 23:41:55 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509BDA527@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie , dromasca@avaya.com Subject: RE: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt Date: Wed, 5 Apr 2006 23:41:55 +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: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: imss@ietf.org, sgai@cisco.com, skode@cisco.com, cds@cisco.com, Black_David@emc.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: , Errors-To: imss-bounces@ietf.org Keith/Dan, I am basically happy with revision 3. I am surprised to see that RECOMMENDED was changed to lowercase in the security considerations section. If I were still AD I would require that to be changed back to upper case as per the template at: http://www.ops.ietf.org/mib-security.html That template text was agreed to by MIB doctors and Security Area geeks a few years back, and it was not easy to agree on the text. Doc is ready for IETF LC, above comment can be addressed as rfc-editor note or be considered IETF LC comments. Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, March 08, 2006 21:17 > To: Keith McCloghrie > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; dromasca@avaya.com; > skode@cisco.com; Black_David@emc.com > Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > > Inline > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Wednesday, March 08, 2006 16:21 > > To: bwijnen@lucent.com > > Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com; > > kzm@cisco.com; > > sgai@cisco.com; imss@ietf.org; dromasca@avaya.com > > Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > Bert, > > > > Thanks for the review. > > > Welcome > > > > This document is ready for IETF Last Call. > > > > > > One topic that I would prefer to see addressed: > > > > > > - When I see: > > > t11FcRouteDestAddrId OBJECT-TYPE > > > SYNTAX FcAddressIdOrZero > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "The destination Fibre Channel Address Identifier of > > > this route. A zero-length string for this field is > > > not allowed." > > > ::= { t11FcRouteEntry 1 } > > > > > > I then wonder why the syntax is not: > > > > > > SYNTAX FcAddressIdOrZero (SIZE(3)) > > > > > > So that the restriction that zero-length is not allowed is > > > also machine readable. > > > > While I agree in principle, I think it also has one other effect: > > it changes t11FcRouteDestAddrId from being a variable-length string > > into a fixed-length string, which only matters because > > t11FcRouteDestAddrId is present in the INDEX clause, and thus, > > I fear that some implementations might get the INDEX-ing wrong (re: > > difference between bullets 2 and 3 at top of RFC 2578's page 28). > > Thus, if you really want to see the restriction reflected in the > > SYNTAX clause, I would prefer to do so as: > > > > SYNTAX OCTET STRING (SIZE (3)) > > > > so that it uses a regular construct, and implementors will > immediately > > know what to do. Do you agree ? > > > > Thanks Keith, I had overlooked that aspect of variable length > for indexing. > Using OCTET STRING as you suggest does fix my initial > comment, but then > takes away that this is a FCAddressId. > So I am not sure which choice I prefer. Does WG have any comments? > Are there any implementers on the list who want to comment? > > So I have no firm opinion on which choice I like best anymore. > > > > > Could be addressesd after IETF Last Call, even with an > > RFC-Editor note. > > > > > > Mainly have some NITs below. > > > You may consider them as initial IETF Last Call comments. > > > Let me know if you rather do a new rev first or if you > > > prefer to do IETF LC now. I will probably let IETF LC extend > > > beyond the IETF week, because people are probably busy reviewing > > > documents for the IETF week itself. > > > > I'd prefer to fix them now, but I'll wait for your response to this > > message before doing so. > > > > > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause > > > For example, from the DESCRIPTION clause of t11FcRouteIfDown > > > it seems that maybe a 'destroy' to the RowStatus object > > > may not take immediate effect? You might want to describe that. > > > It is also unclear if any writeable objects can be written > > > when a row is active? > > > > The last sentence of RowStatus's DESCRIPTION in RFC 2579 says that > > a 'destroy' requires the row to be removed immediately. There was > > discussion in T11.5 of the relationship between this table and the > > routing mechanisms that a FC switch uses, and we agreed that such a > > relationship is proprietary, and that the MIB needs to stay at > > arms-length from being too specific about this > relationship. Thus, I > > would prefer not to add text talking about it. > > > > There is one thing I can add, which is implicit in t11FcRouteTable's > > DESCRIPTION, but it would probably be useful to add a more explicit > > statement in t11FcRouteRowStatus's DESCRIPTION: > > > > The only rows which can be deleted by setting this > object to > > 'destroy' are those for which t11FcRouteProto has the value > > 'netmgmt'. > > > > Then, it won't be so meagre :-). > > > > Good. > > > > - The 4 OBJECT clauses that you did as comments in the > > > MODULE-COMPLIANCE are normally put as comments inside the > > > DESCRIPTION clause of the MODULE-COMPLIANCE clause itself. > > > That way the text is better kept when MIB module gets > > > extracted from RFC. Not a blocking comment though. > > > > OK, I'll move them. (The downside is that the double-quotes have to > > change, e.g., to single-quotes). > > > yep, but thanks for moving them. I think it makes IETF MIB docs more > consistent. And I just happen to like consistency in this space. > > > > > - Section 7 seems redundant with the back matter, and might as > > > well be removed. > > > > I'll let the RFC Editor do that. > > > > Mmm... why is that? > If you do a new rev anyway, why not just make it right BEFORE it > goes to RFC-Editor? > > > > - In the references section, are the details for [FC-SW-4] now > > > known? If so, might want to fill them out. > > > > Yes, we filled them in recently on one of the other FC MIBs. > > Thanks for reminding me of that. > > > > Thanks, > Bert > > Keith. > > > > _______________________________________________ > 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 Apr 05 18:17:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGJp-0000fC-6q; Wed, 05 Apr 2006 18:17:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGJo-0000f6-5O for imss@ietf.org; Wed, 05 Apr 2006 18:17:40 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGJn-0000N2-JL for imss@ietf.org; Wed, 05 Apr 2006 18:17:40 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k35MHWtv020762; Wed, 5 Apr 2006 17:17:33 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <2JG5R5DG>; Thu, 6 Apr 2006 00:17:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509BDA52F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie , dromasca@avaya.com Subject: RE: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-02.txt Date: Thu, 6 Apr 2006 00:17:30 +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: bfef20db74c24e87b6dbcd42ea7ba67c Cc: imss@ietf.org, silvano@ip6.com, cds@cisco.com, vgaonkar@cisco.com, Black_David@emc.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: , Errors-To: imss-bounces@ietf.org Keit/Dan, I am OK with the new revision 2. Sect 7 is still redundant with back matter! But.. doc is ready for IETF LC I think. Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Wednesday, March 08, 2006 21:17 > To: Keith McCloghrie > Cc: silvano@ip6.com; cds@cisco.com; imss@ietf.org; dromasca@avaya.com; > Black_David@emc.com; vgaonkar@cisco.com > Subject: RE: [imss] Re: AD review of: > draft-ietf-imss-fc-fspf-mib-01.txt > > > Inline > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Tuesday, March 07, 2006 16:24 > > To: bwijnen@lucent.com > > Cc: silvano@ip6.com; cds@cisco.com; imss@ietf.org; kzm@cisco.com; > > dromasca@avaya.com; Black_David@emc.com; vgaonkar@cisco.com > > Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt > > > > > > Hi Bert, > > > > > Summary: > > > > > > looks good. I would be OK with doing IETF Last Call and > consider these > > > comments as initial IETF Last Call comments. At the other > hand, IETF > > > LC right before/during an IETF will not get many people to pay > > > attention to this. Maybe you rather do a new rev first? > > > > I'll do a new rev first, but it won't now get posted until > > after the IETF. > > > > I think the repository opens on Monday of IETF week already. > > > > more serious questions/issues: > > > > > > SMICng tells me: > > > E: f(t11fcfspf.mi2), (915,54) Index item > "t11FspfLinkIndex" must be > > > defined with syntax that includes a range > > > W: f(t11fcfspf.mi2), (1007,19) Variable "ifIndex" in > notification > > > "t11FspfNbrStateChangNotify" is an index for a table > > > > > > The warning is OK/acceptable as far as I am concerned. > > > The Error would probably be best fixed. > > > > SMICng is confused: > > > > - t11FspfLinkIndex is defined as Unsigned32, which is defined with a > > range of (0..4294967295). So, it does have a range (but > see below). > > > seem my comment below > > > - ifIndex is read-only. RFC 2578 says (in section 7.3): > > > > The value "not-accessible" indicates an auxiliary > object (see Section > > 7.7). The value "accessible-for-notify" indicates an > object which is > > accessible only via a notification (e.g., snmpTrapOID [5]). > > > > These values are ordered, from least to greatest: > "not-accessible", > > "accessible-for-notify", "read-only", "read-write", > "read-create". > > > > Since "read-only" is greater than "accessible-for-notify", it is > > both readable and accessible via a notification. Indeed, consider > > the situation described in bullet (2) of section 7.7 of > RFC 2578 -- > > the only way to have a notification include any > information from a row > > of a table for which all of the row's objects are also > specified in > > its INDEX clause, is for it to include an object from the > INDEX clause. > > > > Understood, but we do have the desire to not include INDEX items. > For ifIndex, one could have used ifDescr. > I would further think that t11FspfIfNbrDomainId also already includes > the ifIndex in its INDEX part of the OID. > But I agree with you that this is not a big issue, as I said above: > > The warning is OK/acceptable as far as I am concerned. > > > > > SMILINT tells me: > > > > > > C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FSPF-MIB > > > ./T11-FC-FSPF-MIB:212: [5] {identifier-case-match} warning: > > identifier `t11FspfA > > > RegionNum' differs from `T11FspfARegionNum' only in case > > > ./T11-FC-FSPF-MIB:61: [6] {previous-definition} info: > > previous definition of `T1 > > > 1FspfARegionNum' > > > ./T11-FC-FSPF-MIB:824: [5] {identifier-case-match} warning: > > identifier `t11FspfL > > > srType' differs from `T11FspfLsrType' only in case > > > ./T11-FC-FSPF-MIB:71: [6] {previous-definition} info: > > previous definition of `T1 > > > 1FspfLsrType' > > > ./T11-FC-FSPF-MIB:964: [5] {identifier-case-match} warning: > > identifier `t11FspfL > > > inkType' differs from `T11FspfLinkType' only in case > > > ./T11-FC-FSPF-MIB:89: [6] {previous-definition} info: > > previous definition of `T1 > > > 1FspfLinkType' > > > ./T11-FC-FSPF-MIB:61: [5] {type-without-format} warning: > > type `T11FspfARegionNum > > > ' has no format specification > > > ./T11-FC-FSPF-MIB:71: [5] {type-without-format} warning: > > type `T11FspfLsrType' h > > > as no format specification > > > ./T11-FC-FSPF-MIB:89: [5] {type-without-format} warning: > > type `T11FspfLinkType' > > > has no format specification > > > ./T11-FC-FSPF-MIB:129: [5] {type-without-format} warning: > > type `T11FspfLastCreat > > > ionTime' has no format specification > > > > > > The identifier-case-match are acceptable. They may confuse > > people though. > > > > > > The type-without-format warnings are for your TCs. > > > You may want to add a SIPLAY-HINT > > > > Both section 3.1 of RFC 2579 and section 4.6.3 of RFC 4181 say that > > the DISPLAY-HINT clause is optional/need not be present. > > > > As I said: you MAY want to add a DISPLAY-HINT (well I see I > misspelled it) > so I will appreciate if you do, but I won't get sleepless > nights if you don't. > > > > - sect 5 states: > > > protocol. (Note that there are no definitions in this > MIB module of > > > "managed actions" which can be invoked via SNMP.) > > > So what does that mean for t11FspfSetToDefault, which > to me seems to > > > be an action that can be invoked via SNMP?? > > > Same for t11FspfIfSetToDefault > > > > It depends on how one defines "action", and you're right > that the term > > "managed action" is not well-defined. That sentence was > added based on > > a question that arose in T11. The term "managed action" > was intended > > to mean a setRequest which caused a switch to send out a > command in one > > of the T11-defined protocols; for comparison, see some of > the objects > > defined in draft-ietf-imss-fc-fam-mib-03.txt (e.g., t11FamRestart). > > Since that sentence is adding confusion, I will delete it. > > > Thanks > > > > - redundant objects?? > > > I do not see what the difference is between the follow two > > > (well, except SYNTAX). Is there any? If so, can that be made > > > clear in the DESCRIPTION clauses? If not, can one be removed? > > > > > > t11FspfLsrs OBJECT-TYPE > > > SYNTAX Gauge32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The current number of entries for this Fabric in the > > > t11FspfLsrTable." > > > ::= { t11FspfEntry 19 } > > > > > > t11FspfLsrNumber OBJECT-TYPE > > > SYNTAX Unsigned32 (0..2147483647) > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The current number of rows for this fabric in the > > > t11FspfLsrTable." > > > ::= { t11FspfEntry 23 } > > > > Thanks for spotting that. I will remove one of them. > > > Good > > > > - t11FspfStorageType > > > Which writeable objects must be writable for a 'permanent' row? > > > > Since I already succumbed in adding the sentence that you're looking > > for to t11FspfIfStorageType, I will (so as to be > consistent) add it to > > t11FspfStorageType also. > > > Mmm.. my comment was/is mainly based on text from RFC2579 (on > of yours): > StorageType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Describes the memory realization of a conceptual row. A > row which is volatile(2) is lost upon reboot. A row which > is either nonVolatile(3), permanent(4) or readOnly(5), is > backed up by stable storage. A row which is permanent(4) > can be changed but not deleted. A row which is > readOnly(5) > cannot be changed nor deleted. > > If the value of an object with this syntax is either > permanent(4) or readOnly(5), it cannot be written. > Conversely, if the value is either other(1), > volatile(2) or > nonVolatile(3), it cannot be modified to be > permanent(4) or > readOnly(5). (All illegal modifications result in a > 'wrongValue' error.) > > Every usage of this textual convention is required to > specify the columnar objects which a permanent(4) row must > at a minimum allow to be writable." > > So that last sentence to me seems to require it. > > > > However, the requirement at the top of page 23 in RFC 4181 is bogus > > because: a) a requirement which says that an "object must be > > writeable" > > under some particular circumstance is for the minimum > requried access, > > i.e., MIN-ACCESS, and belongs in MODULE-COMPLIANCE, not in > > OBJECT-TYPE, > > b) in this case, all of the accessible objects in this table have a > > MIN-ACCESS of read-only. So, the answer to your question is already > > present in the document. > > > > Mmm... I thought the MIN-ACCESS in the module compliance is > to indicate > that this MIB module can be implemented read-only. > It seems to me that if the object is supported in READ-WRITE > or READ-CREATE > mode, that in that case the normal StorageType requirments > (as in RFC2579) > apply. So I am not sure I agree with your argumentation here. > Anyway, if you add the sentence, then the point is moot (at > least for this > document). > > > > - Mmm. I find the way you delete a row in t11FspfIfRowStatus > > > a bit strange/weird. But I guess I can live with it. > > > Can you explain why you do it this way? > > > > Because: > > > > 1. having unnecessary rows in this table clutters it up, and makes > > those rows that are useful harder for a NMS to find. > > 2. having the current value always be in same object, > irrespective of > > whether it is a default or a non-default value is desirable. > > 3. when non-default values are specified for a port's parameters, > > they need to be retained in the MIB even when the port > is 'isolated'. > > 4. when an E_Port becomes isolated, we want its row to get deleted > > if and only if all of its parameter values are the > default values. > > > > Thanks. Might be good if you add some of that explnanation. > But I won't > loose sleep if you (and the WG) decide that your current text > is good enough. > > > > - t11FspfLinkIndex probably better specifies a range that > excludes zero ?? > > > see also smicng error above. > > > > The smicng error is confused, but I agree it would be better > > to exclude zero, and I'll change it to do so. > > > > So I use the SMICng warning/error messages to check what the > situation is. > And doing so made me wonder about the zero value for the INDEX. > > > > admin/nits and just questions for clarity/explanation > > > > > > - I see: > > > t11FspfIfNbrPortIndex OBJECT-TYPE > > > SYNTAX Unsigned32 (1..4294967295) > > > > > > t11FspfLinkPortIndex OBJECT-TYPE > > > SYNTAX Unsigned32 (0..16777215) > > > > > > t11FspfLinkNbrPortIndex OBJECT-TYPE > > > SYNTAX Unsigned32 (0..16777215) > > > > > > Is it just me who wonders about the different ranges?? > > > Maybe I am missing something or misunderstanding. > > > > The format of the FSPF protocol packets as shown in FC-SW-4 > indicates > > that the port number field is 3 bytes long. Hence, (0..16777215) is > > correct, and (1..4294967295) is incorrect -- I will change > > t11FspfIfNbrPortIndex. > > > > Thanks > > > > - I wonder what a value of zero means for T11FspfLinkType > > > If it can never exist, would it be better to make the range > > > (1..255) ?? > > > > The only difference between the definition in the MIB and > the definition > > pointed to by the REFERENCE clause is that FC-SW-4 says "all others" > > rather than just "others", i.e., zero is a reserved value. > I can add > > "all" into the DESCRIPTION. > > > > Would be good I think > > > > - I wonder if T11FspfLsrType and T11FspfLinkType would be better > > > defined with a base type of INTEGER? In other words > Enumerations? > > > > This is a trade-off between having the MIB definition being more > > explicit or more open-ended. As these objects are > currently defined, > > they implicitly get any new values as and when T11 defines > new values > > for that field. Having them as enumerations would be more explicit, > > but would require a MIB change to incorporate newly defined > values. I > > think this trade-off should be made individually for each > > object on its own merits. > > > > So it seems thought has gone into this. > If this is what the WG wants, then fine. > > > > - I wonder how new non-Vendor-Specific values for T11FspfLsrType > > > and T11FspfLinkType will be assigned/allocated? > > > Probably by T11? Would not hurt to say something about that. > > > > Both of those TC's have a REFERENCE clause pointing to a T11 spec. > > That particular spec doesn't define the term "Vendor Specific" (and > > I'm not sure which, if any, T11 spec does define it), but if I > > understand correctly, in T11 the term means that it is the > vendors who > > define such values and that different vendors can (and do) have > > different meanings for the same value, i.e., they are reserved but > > *not* allocated by an IANA-equivalent organization. A > network manager > > managing a Fibre Channel has to know this, not because of > SNMP or the > > MIB, but because of Fibre Channel. > > > > Might want to add some explanatory text then. > > > > - I suspect that the RFCyyyy in t11FspfAdminStatus > REFERENCE clause > > > is (or should be) a different yyyy than the one in the > > > MODULE-IDENTITY macro? > > > > Right. I'll change t11FspfAdminStatus to use zzzz. > > > AS you see, I can still be very nitpicky ;-) > > > > - In a number of places I would prefer to see "MIB module" instead > > > of just "MIB". But I cam live with if if this is the > doc does not > > > need changing for anything else. > > > > I'll look for them. > > > Thanks > > > > - Section 7 is redundant and contains same material as the > > back matter. > > > > Right. > > > > Bert > > Thanks, > > Keith. > > > > _______________________________________________ > > 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 Apr 06 11:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWR0-0007dh-OQ; Thu, 06 Apr 2006 11:30:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFqF-00023k-7o for imss@ietf.org; Wed, 05 Apr 2006 17:47:07 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFqE-00076X-OU for imss@ietf.org; Wed, 05 Apr 2006 17:47:07 -0400 Received: from tierw.net.avaya.com (h198-152-13-100.avaya.com [198.152.13.100]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k35LjZYM028381 for ; Wed, 5 Apr 2006 17:45:35 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k35LUk37004199 for ; Wed, 5 Apr 2006 17:30:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt Date: Thu, 6 Apr 2006 00:47:03 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt Thread-Index: AcZY+cbkyjMzSB2sS2GMrI3cTVyRyAAAI7gA From: "Romascanu, Dan \(Dan\)" To: "Wijnen, Bert \(Bert\)" , "Keith McCloghrie" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-Mailman-Approved-At: Thu, 06 Apr 2006 11:30:09 -0400 Cc: imss@ietf.org, sgai@cisco.com, skode@cisco.com, cds@cisco.com, Black_David@emc.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: , Errors-To: imss-bounces@ietf.org Anybody can explain shortly the reason of the change RECOMMENDED -> recommended?=20 Thanks, Dan =20 =20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, April 06, 2006 12:42 AM > To: Keith McCloghrie; Romascanu, Dan (Dan) > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org;=20 > skode@cisco.com; Black_David@emc.com > Subject: RE: [imss] RE: AD review of:=20 > draft-ietf-imss-fc-rtm-mib-03.txt >=20 > Keith/Dan, > I am basically happy with revision 3. >=20 > I am surprised to see that RECOMMENDED was changed to=20 > lowercase in the security considerations section. > If I were still AD I would require that to be changed back to=20 > upper case as per the template at: > http://www.ops.ietf.org/mib-security.html >=20 > That template text was agreed to by MIB doctors and Security=20 > Area geeks a few years back, and it was not easy to agree on the text. >=20 > Doc is ready for IETF LC, above comment can be addressed as=20 > rfc-editor note or be considered IETF LC comments. >=20 > Bert >=20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Wednesday, March 08, 2006 21:17 > > To: Keith McCloghrie > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org;=20 > dromasca@avaya.com;=20 > > skode@cisco.com; Black_David@emc.com > > Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > >=20 > >=20 > > Inline > >=20 > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Wednesday, March 08, 2006 16:21 > > > To: bwijnen@lucent.com > > > Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com;=20 > > > kzm@cisco.com; sgai@cisco.com; imss@ietf.org; dromasca@avaya.com > > > Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > >=20 > > >=20 > > > Bert, > > >=20 > > > Thanks for the review. > > >=20 > > Welcome > >=20 > > > > This document is ready for IETF Last Call. > > > >=20 > > > > One topic that I would prefer to see addressed: > > > >=20 > > > > - When I see: > > > > t11FcRouteDestAddrId OBJECT-TYPE > > > > SYNTAX FcAddressIdOrZero > > > > MAX-ACCESS not-accessible > > > > STATUS current > > > > DESCRIPTION > > > > "The destination Fibre Channel Address Identifier of > > > > this route. A zero-length string for this field is > > > > not allowed." > > > > ::=3D { t11FcRouteEntry 1 } > > > >=20 > > > > I then wonder why the syntax is not: > > > >=20 > > > > SYNTAX FcAddressIdOrZero (SIZE(3)) > > > >=20 > > > > So that the restriction that zero-length is not allowed is > > > > also machine readable. > > > =20 > > > While I agree in principle, I think it also has one other effect:=20 > > > it changes t11FcRouteDestAddrId from being a=20 > variable-length string=20 > > > into a fixed-length string, which only matters because=20 > > > t11FcRouteDestAddrId is present in the INDEX clause, and thus, I=20 > > > fear that some implementations might get the INDEX-ing wrong (re: > > > difference between bullets 2 and 3 at top of RFC 2578's page 28). > > > Thus, if you really want to see the restriction reflected in the=20 > > > SYNTAX clause, I would prefer to do so as: > > >=20 > > > SYNTAX OCTET STRING (SIZE (3)) > > >=20 > > > so that it uses a regular construct, and implementors will > > immediately > > > know what to do. Do you agree ? > > >=20 > >=20 > > Thanks Keith, I had overlooked that aspect of variable length for=20 > > indexing. > > Using OCTET STRING as you suggest does fix my initial comment, but=20 > > then takes away that this is a FCAddressId. > > So I am not sure which choice I prefer. Does WG have any comments? > > Are there any implementers on the list who want to comment? > >=20 > > So I have no firm opinion on which choice I like best anymore. > >=20 > >=20 > > > > Could be addressesd after IETF Last Call, even with an > > > RFC-Editor note. > > > >=20 > > > > Mainly have some NITs below. > > > > You may consider them as initial IETF Last Call comments. > > > > Let me know if you rather do a new rev first or if you=20 > prefer to=20 > > > > do IETF LC now. I will probably let IETF LC extend=20 > beyond the IETF=20 > > > > week, because people are probably busy reviewing=20 > documents for the=20 > > > > IETF week itself. > > > =20 > > > I'd prefer to fix them now, but I'll wait for your=20 > response to this=20 > > > message before doing so. > > >=20 > > > > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause > > > > For example, from the DESCRIPTION clause of t11FcRouteIfDown > > > > it seems that maybe a 'destroy' to the RowStatus object > > > > may not take immediate effect? You might want to=20 > describe that. > > > > It is also unclear if any writeable objects can be written > > > > when a row is active? > > > =20 > > > The last sentence of RowStatus's DESCRIPTION in RFC 2579=20 > says that a=20 > > > 'destroy' requires the row to be removed immediately. There was=20 > > > discussion in T11.5 of the relationship between this=20 > table and the=20 > > > routing mechanisms that a FC switch uses, and we agreed=20 > that such a=20 > > > relationship is proprietary, and that the MIB needs to stay at=20 > > > arms-length from being too specific about this > > relationship. Thus, I > > > would prefer not to add text talking about it. > > >=20 > > > There is one thing I can add, which is implicit in=20 > t11FcRouteTable's=20 > > > DESCRIPTION, but it would probably be useful to add a=20 > more explicit=20 > > > statement in t11FcRouteRowStatus's DESCRIPTION: > > >=20 > > > The only rows which can be deleted by setting this > > object to > > > 'destroy' are those for which t11FcRouteProto=20 > has the value > > > 'netmgmt'. > > >=20 > > > Then, it won't be so meagre :-). > > > =20 > >=20 > > Good. > >=20 > > > > - The 4 OBJECT clauses that you did as comments in the > > > > MODULE-COMPLIANCE are normally put as comments inside the > > > > DESCRIPTION clause of the MODULE-COMPLIANCE clause itself. > > > > That way the text is better kept when MIB module gets > > > > extracted from RFC. Not a blocking comment though. > > > =20 > > > OK, I'll move them. (The downside is that the=20 > double-quotes have to=20 > > > change, e.g., to single-quotes). > > >=20 > > yep, but thanks for moving them. I think it makes IETF MIB=20 > docs more=20 > > consistent. And I just happen to like consistency in this space. > >=20 > >=20 > > > > - Section 7 seems redundant with the back matter, and might as > > > > well be removed. > > > =20 > > > I'll let the RFC Editor do that. > > >=20 > >=20 > > Mmm... why is that? > > If you do a new rev anyway, why not just make it right=20 > BEFORE it goes=20 > > to RFC-Editor? > >=20 > > > > - In the references section, are the details for [FC-SW-4] now > > > > known? If so, might want to fill them out. > > >=20 > > > Yes, we filled them in recently on one of the other FC MIBs. > > > Thanks for reminding me of that. > > >=20 > >=20 > > Thanks, > > Bert > > > Keith. > > >=20 > >=20 > > _______________________________________________ > > imss mailing list > > imss@ietf.org > > https://www1.ietf.org/mailman/listinfo/imss > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Apr 07 13:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRv1Y-0002ML-0d; Fri, 07 Apr 2006 13:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRv10-0000pD-Oa; Fri, 07 Apr 2006 13:44:58 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRum5-0005Ko-JL; Fri, 07 Apr 2006 13:29:34 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k37HTXxG030430; Fri, 7 Apr 2006 10:29:33 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k37HTXsc030429; Fri, 7 Apr 2006 10:29:33 -0700 Date: Fri, 7 Apr 2006 10:29:33 -0700 Message-Id: <200604071729.k37HTXsc030429@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: imss@ietf.org, rfc-editor@rfc-editor.org Subject: [imss] RFC 4438 on Fibre-Channel Name Server MIB 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: , Errors-To: imss-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4438 Title: Fibre-Channel Name Server MIB Author: C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai Status: Standards Track Date: April 2006 Mailbox: cds@cisco.com, vgaonkar@cisco.com, hvivek@cisco.com, kzm@cisco.com, retired Pages: 36 Characters: 70156 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-imss-fc-nsm-mib-05.txt URL: http://www.rfc-editor.org/rfc/rfc4438.txt 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. [STANDARDS TRACK] This document is a product of the Internet and Management Support for Storage Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Sat Apr 08 16:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSK5x-0003vb-Hp; Sat, 08 Apr 2006 16:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSK5w-0003vP-CO for imss@ietf.org; Sat, 08 Apr 2006 16:31:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSK5v-0001G0-NG for imss@ietf.org; Sat, 08 Apr 2006 16:31:44 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Apr 2006 13:31:43 -0700 X-IronPort-AV: i="4.04,102,1144047600"; d="scan'208"; a="1793129901:sNHT33984356" Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k38KVgYg013388; Sat, 8 Apr 2006 13:31:42 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA11187; Sat, 8 Apr 2006 13:31:29 -0700 (PDT) From: Keith McCloghrie Message-Id: <200604082031.NAA11187@cisco.com> Subject: Re: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt To: dromasca@avaya.com ("Romascanu, Dan \(Dan\)") Date: Sat, 8 Apr 2006 13:31:29 -0700 (PDT) In-Reply-To: from "Romascanu, Dan \(Dan\)" at Apr 06, 2006 12:47:03 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: b84f8c8fba0e1389e5eb998b64078964 Cc: sgai@cisco.com, cds@cisco.com, imss@ietf.org, Keith McCloghrie , skode@cisco.com, "\"Wijnen, Bert \(Bert\)\"" , Black_David@emc.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: , Errors-To: imss-bounces@ietf.org > Anybody can explain shortly the reason of the change RECOMMENDED -> > recommended? Yes, I changed it because the 'idnits' tool complained about it. In fact, RFC 2119 says: .... Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. So, since http://ops.ietf.org/mib-security.html contains no mention of RFC 2119, and no mention of including the above paragraph in the MIB document, I presumed that its use of "RECOMMENDED" is not in the sense of RFC 2119. Therefore, I changed the document to be idnits-compliant by making the simplest, least disruptive change, which is most consistent with all previous RFCs that I have generated containing recommendations for use and deployment of SNMPv3, including the two RFCs which this WG had published last week. Keith. > > Thanks, > > Dan > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Thursday, April 06, 2006 12:42 AM > > To: Keith McCloghrie; Romascanu, Dan (Dan) > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > skode@cisco.com; Black_David@emc.com > > Subject: RE: [imss] RE: AD review of: > > draft-ietf-imss-fc-rtm-mib-03.txt > > > > Keith/Dan, > > I am basically happy with revision 3. > > > > I am surprised to see that RECOMMENDED was changed to > > lowercase in the security considerations section. > > If I were still AD I would require that to be changed back to > > upper case as per the template at: > > http://www.ops.ietf.org/mib-security.html > > > > That template text was agreed to by MIB doctors and Security > > Area geeks a few years back, and it was not easy to agree on the text. > > > > Doc is ready for IETF LC, above comment can be addressed as > > rfc-editor note or be considered IETF LC comments. > > > > Bert > > > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Wednesday, March 08, 2006 21:17 > > > To: Keith McCloghrie > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > dromasca@avaya.com; > > > skode@cisco.com; Black_David@emc.com > > > Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > > > > Inline > > > > > > > -----Original Message----- > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > Sent: Wednesday, March 08, 2006 16:21 > > > > To: bwijnen@lucent.com > > > > Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com; > > > > kzm@cisco.com; sgai@cisco.com; imss@ietf.org; dromasca@avaya.com > > > > Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > > > > > > > Bert, > > > > > > > > Thanks for the review. > > > > > > > Welcome > > > > > > > > This document is ready for IETF Last Call. > > > > > > > > > > One topic that I would prefer to see addressed: > > > > > > > > > > - When I see: > > > > > t11FcRouteDestAddrId OBJECT-TYPE > > > > > SYNTAX FcAddressIdOrZero > > > > > MAX-ACCESS not-accessible > > > > > STATUS current > > > > > DESCRIPTION > > > > > "The destination Fibre Channel Address Identifier of > > > > > this route. A zero-length string for this field is > > > > > not allowed." > > > > > ::= { t11FcRouteEntry 1 } > > > > > > > > > > I then wonder why the syntax is not: > > > > > > > > > > SYNTAX FcAddressIdOrZero (SIZE(3)) > > > > > > > > > > So that the restriction that zero-length is not allowed is > > > > > also machine readable. > > > > > > > > While I agree in principle, I think it also has one other effect: > > > > it changes t11FcRouteDestAddrId from being a > > variable-length string > > > > into a fixed-length string, which only matters because > > > > t11FcRouteDestAddrId is present in the INDEX clause, and thus, I > > > > fear that some implementations might get the INDEX-ing wrong (re: > > > > difference between bullets 2 and 3 at top of RFC 2578's page 28). > > > > Thus, if you really want to see the restriction reflected in the > > > > SYNTAX clause, I would prefer to do so as: > > > > > > > > SYNTAX OCTET STRING (SIZE (3)) > > > > > > > > so that it uses a regular construct, and implementors will > > > immediately > > > > know what to do. Do you agree ? > > > > > > > > > > Thanks Keith, I had overlooked that aspect of variable length for > > > indexing. > > > Using OCTET STRING as you suggest does fix my initial comment, but > > > then takes away that this is a FCAddressId. > > > So I am not sure which choice I prefer. Does WG have any comments? > > > Are there any implementers on the list who want to comment? > > > > > > So I have no firm opinion on which choice I like best anymore. > > > > > > > > > > > Could be addressesd after IETF Last Call, even with an > > > > RFC-Editor note. > > > > > > > > > > Mainly have some NITs below. > > > > > You may consider them as initial IETF Last Call comments. > > > > > Let me know if you rather do a new rev first or if you > > prefer to > > > > > do IETF LC now. I will probably let IETF LC extend > > beyond the IETF > > > > > week, because people are probably busy reviewing > > documents for the > > > > > IETF week itself. > > > > > > > > I'd prefer to fix them now, but I'll wait for your > > response to this > > > > message before doing so. > > > > > > > > > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause > > > > > For example, from the DESCRIPTION clause of t11FcRouteIfDown > > > > > it seems that maybe a 'destroy' to the RowStatus object > > > > > may not take immediate effect? You might want to > > describe that. > > > > > It is also unclear if any writeable objects can be written > > > > > when a row is active? > > > > > > > > The last sentence of RowStatus's DESCRIPTION in RFC 2579 > > says that a > > > > 'destroy' requires the row to be removed immediately. There was > > > > discussion in T11.5 of the relationship between this > > table and the > > > > routing mechanisms that a FC switch uses, and we agreed > > that such a > > > > relationship is proprietary, and that the MIB needs to stay at > > > > arms-length from being too specific about this > > > relationship. Thus, I > > > > would prefer not to add text talking about it. > > > > > > > > There is one thing I can add, which is implicit in > > t11FcRouteTable's > > > > DESCRIPTION, but it would probably be useful to add a > > more explicit > > > > statement in t11FcRouteRowStatus's DESCRIPTION: > > > > > > > > The only rows which can be deleted by setting this > > > object to > > > > 'destroy' are those for which t11FcRouteProto > > has the value > > > > 'netmgmt'. > > > > > > > > Then, it won't be so meagre :-). > > > > > > > > > > Good. > > > > > > > > - The 4 OBJECT clauses that you did as comments in the > > > > > MODULE-COMPLIANCE are normally put as comments inside the > > > > > DESCRIPTION clause of the MODULE-COMPLIANCE clause itself. > > > > > That way the text is better kept when MIB module gets > > > > > extracted from RFC. Not a blocking comment though. > > > > > > > > OK, I'll move them. (The downside is that the > > double-quotes have to > > > > change, e.g., to single-quotes). > > > > > > > yep, but thanks for moving them. I think it makes IETF MIB > > docs more > > > consistent. And I just happen to like consistency in this space. > > > > > > > > > > > - Section 7 seems redundant with the back matter, and might as > > > > > well be removed. > > > > > > > > I'll let the RFC Editor do that. > > > > > > > > > > Mmm... why is that? > > > If you do a new rev anyway, why not just make it right > > BEFORE it goes > > > to RFC-Editor? > > > > > > > > - In the references section, are the details for [FC-SW-4] now > > > > > known? If so, might want to fill them out. > > > > > > > > Yes, we filled them in recently on one of the other FC MIBs. > > > > Thanks for reminding me of that. > > > > > > > > > > Thanks, > > > Bert > > > > Keith. > > > > > > > > > > _______________________________________________ > > > 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 Sat Apr 08 17:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSKaP-0004JS-Rl; Sat, 08 Apr 2006 17:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSKaO-0004JM-Oj for imss@ietf.org; Sat, 08 Apr 2006 17:03:12 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSKaO-00020g-AY for imss@ietf.org; Sat, 08 Apr 2006 17:03:12 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k38L33h4016018; Sat, 8 Apr 2006 16:03:04 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <2JG5THJ4>; Sat, 8 Apr 2006 23:03:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509BDADCE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie , dromasca@avaya.com Subject: RE: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt Date: Sat, 8 Apr 2006 23:02:53 +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: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: sgai@cisco.com, cds@cisco.com, imss@ietf.org, skode@cisco.com, bwijnen@lucent.com, Black_David@emc.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: , Errors-To: imss-bounces@ietf.org I think it is better to keep the CAPITALIZED language and add (use) the reference to rfc2119. Bert > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Saturday, April 08, 2006 22:31 > To: dromasca@avaya.com > Cc: bwijnen@lucent.com; kzm@cisco.com; sgai@cisco.com; cds@cisco.com; > imss@ietf.org; skode@cisco.com; Black_David@emc.com > Subject: Re: [imss] RE: AD review of: > draft-ietf-imss-fc-rtm-mib-03.txt > > > > Anybody can explain shortly the reason of the change RECOMMENDED -> > > recommended? > > Yes, I changed it because the 'idnits' tool complained about it. > > In fact, RFC 2119 says: > .... Authors who follow these guidelines > should incorporate this phrase near the beginning of their > document: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as > described in > RFC 2119. > > So, since http://ops.ietf.org/mib-security.html contains no mention > of RFC 2119, and no mention of including the above paragraph > in the MIB > document, I presumed that its use of "RECOMMENDED" is not in > the sense of > RFC 2119. Therefore, I changed the document to be idnits-compliant by > making the simplest, least disruptive change, which is most consistent > with all previous RFCs that I have generated containing > recommendations > for use and deployment of SNMPv3, including the two RFCs which this WG > had published last week. > > Keith. > > > > > Thanks, > > > > Dan > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Thursday, April 06, 2006 12:42 AM > > > To: Keith McCloghrie; Romascanu, Dan (Dan) > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > > skode@cisco.com; Black_David@emc.com > > > Subject: RE: [imss] RE: AD review of: > > > draft-ietf-imss-fc-rtm-mib-03.txt > > > > > > Keith/Dan, > > > I am basically happy with revision 3. > > > > > > I am surprised to see that RECOMMENDED was changed to > > > lowercase in the security considerations section. > > > If I were still AD I would require that to be changed back to > > > upper case as per the template at: > > > http://www.ops.ietf.org/mib-security.html > > > > > > That template text was agreed to by MIB doctors and Security > > > Area geeks a few years back, and it was not easy to agree > on the text. > > > > > > Doc is ready for IETF LC, above comment can be addressed as > > > rfc-editor note or be considered IETF LC comments. > > > > > > Bert > > > > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Wednesday, March 08, 2006 21:17 > > > > To: Keith McCloghrie > > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > > dromasca@avaya.com; > > > > skode@cisco.com; Black_David@emc.com > > > > Subject: [imss] RE: AD review of: > draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > > > > > > > Inline > > > > > > > > > -----Original Message----- > > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > > Sent: Wednesday, March 08, 2006 16:21 > > > > > To: bwijnen@lucent.com > > > > > Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com; > > > > > kzm@cisco.com; sgai@cisco.com; imss@ietf.org; > dromasca@avaya.com > > > > > Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > > > > > > > > > > Bert, > > > > > > > > > > Thanks for the review. > > > > > > > > > Welcome > > > > > > > > > > This document is ready for IETF Last Call. > > > > > > > > > > > > One topic that I would prefer to see addressed: > > > > > > > > > > > > - When I see: > > > > > > t11FcRouteDestAddrId OBJECT-TYPE > > > > > > SYNTAX FcAddressIdOrZero > > > > > > MAX-ACCESS not-accessible > > > > > > STATUS current > > > > > > DESCRIPTION > > > > > > "The destination Fibre Channel Address > Identifier of > > > > > > this route. A zero-length string for > this field is > > > > > > not allowed." > > > > > > ::= { t11FcRouteEntry 1 } > > > > > > > > > > > > I then wonder why the syntax is not: > > > > > > > > > > > > SYNTAX FcAddressIdOrZero (SIZE(3)) > > > > > > > > > > > > So that the restriction that zero-length is not allowed is > > > > > > also machine readable. > > > > > > > > > > While I agree in principle, I think it also has one > other effect: > > > > > it changes t11FcRouteDestAddrId from being a > > > variable-length string > > > > > into a fixed-length string, which only matters because > > > > > t11FcRouteDestAddrId is present in the INDEX clause, > and thus, I > > > > > fear that some implementations might get the > INDEX-ing wrong (re: > > > > > difference between bullets 2 and 3 at top of RFC > 2578's page 28). > > > > > Thus, if you really want to see the restriction > reflected in the > > > > > SYNTAX clause, I would prefer to do so as: > > > > > > > > > > SYNTAX OCTET STRING (SIZE (3)) > > > > > > > > > > so that it uses a regular construct, and implementors will > > > > immediately > > > > > know what to do. Do you agree ? > > > > > > > > > > > > > Thanks Keith, I had overlooked that aspect of variable > length for > > > > indexing. > > > > Using OCTET STRING as you suggest does fix my initial > comment, but > > > > then takes away that this is a FCAddressId. > > > > So I am not sure which choice I prefer. Does WG have > any comments? > > > > Are there any implementers on the list who want to comment? > > > > > > > > So I have no firm opinion on which choice I like best anymore. > > > > > > > > > > > > > > Could be addressesd after IETF Last Call, even with an > > > > > RFC-Editor note. > > > > > > > > > > > > Mainly have some NITs below. > > > > > > You may consider them as initial IETF Last Call comments. > > > > > > Let me know if you rather do a new rev first or if you > > > prefer to > > > > > > do IETF LC now. I will probably let IETF LC extend > > > beyond the IETF > > > > > > week, because people are probably busy reviewing > > > documents for the > > > > > > IETF week itself. > > > > > > > > > > I'd prefer to fix them now, but I'll wait for your > > > response to this > > > > > message before doing so. > > > > > > > > > > > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause > > > > > > For example, from the DESCRIPTION clause of > t11FcRouteIfDown > > > > > > it seems that maybe a 'destroy' to the RowStatus object > > > > > > may not take immediate effect? You might want to > > > describe that. > > > > > > It is also unclear if any writeable objects can be written > > > > > > when a row is active? > > > > > > > > > > The last sentence of RowStatus's DESCRIPTION in RFC 2579 > > > says that a > > > > > 'destroy' requires the row to be removed immediately. > There was > > > > > discussion in T11.5 of the relationship between this > > > table and the > > > > > routing mechanisms that a FC switch uses, and we agreed > > > that such a > > > > > relationship is proprietary, and that the MIB needs > to stay at > > > > > arms-length from being too specific about this > > > > relationship. Thus, I > > > > > would prefer not to add text talking about it. > > > > > > > > > > There is one thing I can add, which is implicit in > > > t11FcRouteTable's > > > > > DESCRIPTION, but it would probably be useful to add a > > > more explicit > > > > > statement in t11FcRouteRowStatus's DESCRIPTION: > > > > > > > > > > The only rows which can be deleted by setting this > > > > object to > > > > > 'destroy' are those for which t11FcRouteProto > > > has the value > > > > > 'netmgmt'. > > > > > > > > > > Then, it won't be so meagre :-). > > > > > > > > > > > > > Good. > > > > > > > > > > - The 4 OBJECT clauses that you did as comments in the > > > > > > MODULE-COMPLIANCE are normally put as comments inside the > > > > > > DESCRIPTION clause of the MODULE-COMPLIANCE clause itself. > > > > > > That way the text is better kept when MIB module gets > > > > > > extracted from RFC. Not a blocking comment though. > > > > > > > > > > OK, I'll move them. (The downside is that the > > > double-quotes have to > > > > > change, e.g., to single-quotes). > > > > > > > > > yep, but thanks for moving them. I think it makes IETF MIB > > > docs more > > > > consistent. And I just happen to like consistency in this space. > > > > > > > > > > > > > > - Section 7 seems redundant with the back matter, > and might as > > > > > > well be removed. > > > > > > > > > > I'll let the RFC Editor do that. > > > > > > > > > > > > > Mmm... why is that? > > > > If you do a new rev anyway, why not just make it right > > > BEFORE it goes > > > > to RFC-Editor? > > > > > > > > > > - In the references section, are the details for > [FC-SW-4] now > > > > > > known? If so, might want to fill them out. > > > > > > > > > > Yes, we filled them in recently on one of the other FC MIBs. > > > > > Thanks for reminding me of that. > > > > > > > > > > > > > Thanks, > > > > Bert > > > > > Keith. > > > > > > > > > > > > > _______________________________________________ > > > > 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 Sat Apr 08 23:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSR0p-0003kh-Gk; Sat, 08 Apr 2006 23:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSR0o-0003gN-3N for imss@ietf.org; Sat, 08 Apr 2006 23:54:54 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSR0j-0005gH-39 for imss@ietf.org; Sat, 08 Apr 2006 23:54:51 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 08 Apr 2006 20:54:48 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k393sm7T026772; Sat, 8 Apr 2006 20:54:48 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA04997; Sat, 8 Apr 2006 20:54:35 -0700 (PDT) From: Keith McCloghrie Message-Id: <200604090354.UAA04997@cisco.com> Subject: Re: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Sat, 8 Apr 2006 20:54:35 -0700 (PDT) In-Reply-To: from "Wijnen, Bert (Bert)" at Apr 08, 2006 11:02:53 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: 3be09dac38eaa50f02d21c7fcee1128c Cc: sgai@cisco.com, cds@cisco.com, imss@ietf.org, Keith McCloghrie , dromasca@avaya.com, skode@cisco.com, bwijnen@lucent.com, Black_David@emc.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: , Errors-To: imss-bounces@ietf.org Bert, While you and I both agree with the boilerplate's recommendations for the implementation and use of SNMPv3, it is my belief that at least one of them is trying to impose the use of SNMPv3 on implementors and/or operators, and therefore, given that RFC 2119 says: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I suggest that we must not use these imperatives in this situation. (Note that the above paragraph from 2119 actually contains "must not" in lower case, i.e., it is wrong to capitalise every occurrence of these imperatives.) Keith. > I think it is better to keep the CAPITALIZED language and add > (use) the reference to rfc2119. > > Bert > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Saturday, April 08, 2006 22:31 > > To: dromasca@avaya.com > > Cc: bwijnen@lucent.com; kzm@cisco.com; sgai@cisco.com; cds@cisco.com; > > imss@ietf.org; skode@cisco.com; Black_David@emc.com > > Subject: Re: [imss] RE: AD review of: > > draft-ietf-imss-fc-rtm-mib-03.txt > > > > > > > Anybody can explain shortly the reason of the change RECOMMENDED -> > > > recommended? > > > > Yes, I changed it because the 'idnits' tool complained about it. > > > > In fact, RFC 2119 says: > > .... Authors who follow these guidelines > > should incorporate this phrase near the beginning of their > > document: > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as > > described in > > RFC 2119. > > > > So, since http://ops.ietf.org/mib-security.html contains no mention > > of RFC 2119, and no mention of including the above paragraph > > in the MIB > > document, I presumed that its use of "RECOMMENDED" is not in > > the sense of > > RFC 2119. Therefore, I changed the document to be idnits-compliant by > > making the simplest, least disruptive change, which is most consistent > > with all previous RFCs that I have generated containing > > recommendations > > for use and deployment of SNMPv3, including the two RFCs which this WG > > had published last week. > > > > Keith. > > > > > > > > Thanks, > > > > > > Dan > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Thursday, April 06, 2006 12:42 AM > > > > To: Keith McCloghrie; Romascanu, Dan (Dan) > > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > > > skode@cisco.com; Black_David@emc.com > > > > Subject: RE: [imss] RE: AD review of: > > > > draft-ietf-imss-fc-rtm-mib-03.txt > > > > > > > > Keith/Dan, > > > > I am basically happy with revision 3. > > > > > > > > I am surprised to see that RECOMMENDED was changed to > > > > lowercase in the security considerations section. > > > > If I were still AD I would require that to be changed back to > > > > upper case as per the template at: > > > > http://www.ops.ietf.org/mib-security.html > > > > > > > > That template text was agreed to by MIB doctors and Security > > > > Area geeks a few years back, and it was not easy to agree > > on the text. > > > > > > > > Doc is ready for IETF LC, above comment can be addressed as > > > > rfc-editor note or be considered IETF LC comments. > > > > > > > > Bert > > > > > > > > > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Wednesday, March 08, 2006 21:17 > > > > > To: Keith McCloghrie > > > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > > > dromasca@avaya.com; > > > > > skode@cisco.com; Black_David@emc.com > > > > > Subject: [imss] RE: AD review of: > > draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > > > > > > > > > > Inline > > > > > > > > > > > -----Original Message----- > > > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > > > Sent: Wednesday, March 08, 2006 16:21 > > > > > > To: bwijnen@lucent.com > > > > > > Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com; > > > > > > kzm@cisco.com; sgai@cisco.com; imss@ietf.org; > > dromasca@avaya.com > > > > > > Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > > > > > > > > > > > > > Bert, > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > Welcome > > > > > > > > > > > > This document is ready for IETF Last Call. > > > > > > > > > > > > > > One topic that I would prefer to see addressed: > > > > > > > > > > > > > > - When I see: > > > > > > > t11FcRouteDestAddrId OBJECT-TYPE > > > > > > > SYNTAX FcAddressIdOrZero > > > > > > > MAX-ACCESS not-accessible > > > > > > > STATUS current > > > > > > > DESCRIPTION > > > > > > > "The destination Fibre Channel Address > > Identifier of > > > > > > > this route. A zero-length string for > > this field is > > > > > > > not allowed." > > > > > > > ::= { t11FcRouteEntry 1 } > > > > > > > > > > > > > > I then wonder why the syntax is not: > > > > > > > > > > > > > > SYNTAX FcAddressIdOrZero (SIZE(3)) > > > > > > > > > > > > > > So that the restriction that zero-length is not allowed is > > > > > > > also machine readable. > > > > > > > > > > > > While I agree in principle, I think it also has one > > other effect: > > > > > > it changes t11FcRouteDestAddrId from being a > > > > variable-length string > > > > > > into a fixed-length string, which only matters because > > > > > > t11FcRouteDestAddrId is present in the INDEX clause, > > and thus, I > > > > > > fear that some implementations might get the > > INDEX-ing wrong (re: > > > > > > difference between bullets 2 and 3 at top of RFC > > 2578's page 28). > > > > > > Thus, if you really want to see the restriction > > reflected in the > > > > > > SYNTAX clause, I would prefer to do so as: > > > > > > > > > > > > SYNTAX OCTET STRING (SIZE (3)) > > > > > > > > > > > > so that it uses a regular construct, and implementors will > > > > > immediately > > > > > > know what to do. Do you agree ? > > > > > > > > > > > > > > > > Thanks Keith, I had overlooked that aspect of variable > > length for > > > > > indexing. > > > > > Using OCTET STRING as you suggest does fix my initial > > comment, but > > > > > then takes away that this is a FCAddressId. > > > > > So I am not sure which choice I prefer. Does WG have > > any comments? > > > > > Are there any implementers on the list who want to comment? > > > > > > > > > > So I have no firm opinion on which choice I like best anymore. > > > > > > > > > > > > > > > > > Could be addressesd after IETF Last Call, even with an > > > > > > RFC-Editor note. > > > > > > > > > > > > > > Mainly have some NITs below. > > > > > > > You may consider them as initial IETF Last Call comments. > > > > > > > Let me know if you rather do a new rev first or if you > > > > prefer to > > > > > > > do IETF LC now. I will probably let IETF LC extend > > > > beyond the IETF > > > > > > > week, because people are probably busy reviewing > > > > documents for the > > > > > > > IETF week itself. > > > > > > > > > > > > I'd prefer to fix them now, but I'll wait for your > > > > response to this > > > > > > message before doing so. > > > > > > > > > > > > > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause > > > > > > > For example, from the DESCRIPTION clause of > > t11FcRouteIfDown > > > > > > > it seems that maybe a 'destroy' to the RowStatus object > > > > > > > may not take immediate effect? You might want to > > > > describe that. > > > > > > > It is also unclear if any writeable objects can be written > > > > > > > when a row is active? > > > > > > > > > > > > The last sentence of RowStatus's DESCRIPTION in RFC 2579 > > > > says that a > > > > > > 'destroy' requires the row to be removed immediately. > > There was > > > > > > discussion in T11.5 of the relationship between this > > > > table and the > > > > > > routing mechanisms that a FC switch uses, and we agreed > > > > that such a > > > > > > relationship is proprietary, and that the MIB needs > > to stay at > > > > > > arms-length from being too specific about this > > > > > relationship. Thus, I > > > > > > would prefer not to add text talking about it. > > > > > > > > > > > > There is one thing I can add, which is implicit in > > > > t11FcRouteTable's > > > > > > DESCRIPTION, but it would probably be useful to add a > > > > more explicit > > > > > > statement in t11FcRouteRowStatus's DESCRIPTION: > > > > > > > > > > > > The only rows which can be deleted by setting this > > > > > object to > > > > > > 'destroy' are those for which t11FcRouteProto > > > > has the value > > > > > > 'netmgmt'. > > > > > > > > > > > > Then, it won't be so meagre :-). > > > > > > > > > > > > > > > > Good. > > > > > > > > > > > > - The 4 OBJECT clauses that you did as comments in the > > > > > > > MODULE-COMPLIANCE are normally put as comments inside the > > > > > > > DESCRIPTION clause of the MODULE-COMPLIANCE clause itself. > > > > > > > That way the text is better kept when MIB module gets > > > > > > > extracted from RFC. Not a blocking comment though. > > > > > > > > > > > > OK, I'll move them. (The downside is that the > > > > double-quotes have to > > > > > > change, e.g., to single-quotes). > > > > > > > > > > > yep, but thanks for moving them. I think it makes IETF MIB > > > > docs more > > > > > consistent. And I just happen to like consistency in this space. > > > > > > > > > > > > > > > > > - Section 7 seems redundant with the back matter, > > and might as > > > > > > > well be removed. > > > > > > > > > > > > I'll let the RFC Editor do that. > > > > > > > > > > > > > > > > Mmm... why is that? > > > > > If you do a new rev anyway, why not just make it right > > > > BEFORE it goes > > > > > to RFC-Editor? > > > > > > > > > > > > - In the references section, are the details for > > [FC-SW-4] now > > > > > > > known? If so, might want to fill them out. > > > > > > > > > > > > Yes, we filled them in recently on one of the other FC MIBs. > > > > > > Thanks for reminding me of that. > > > > > > > > > > > > > > > > Thanks, > > > > > Bert > > > > > > Keith. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Mon Apr 10 05:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSt5J-0001LD-LX; Mon, 10 Apr 2006 05:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSt5I-0001L8-Fz for imss@ietf.org; Mon, 10 Apr 2006 05:53:24 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSt5H-00011f-Va for imss@ietf.org; Mon, 10 Apr 2006 05:53:24 -0400 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3A9p55E017277 for ; Mon, 10 Apr 2006 05:51:05 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k3A9oA2G018601 for ; Mon, 10 Apr 2006 05:50:11 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt Date: Mon, 10 Apr 2006 12:53:20 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt Thread-Index: AcZbiV+kVRp5E0TmQyWT62vukW79hgA+ty0g From: "Romascanu, Dan \(Dan\)" To: "Keith McCloghrie" , "Wijnen, Bert \(Bert\)" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Cc: sgai@cisco.com, cds@cisco.com, imss@ietf.org, skode@cisco.com, bwijnen@lucent.com, Black_David@emc.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: , Errors-To: imss-bounces@ietf.org Keith and Bert, I do not believe that following the text recommended in the guidelines (with capitalization) is imposing the usage of SNMPv3 on implementers or operators. After all the text in http://www.ops.ietf.org/mib-security.html says: 'It is RECOMMENDED that implementers consider ...' So it's using RECOMMENDED and not MANDATORY, and then the recommendation is to consider doing something, and not to do something.=20 This looks to me enough liberty for implementers to do something else and for operators to deploy something else if they have good reasons.=20 I would however like to clarify the issue by adding in http://www.ops.ietf.org/mib-security.html the RFC 2119 reference. It's obvious, but probably not obvious enough. Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: Sunday, April 09, 2006 6:55 AM > To: "Wijnen, Bert (Bert)" > Cc: Keith McCloghrie; Romascanu, Dan (Dan); sgai@cisco.com;=20 > cds@cisco.com; imss@ietf.org; skode@cisco.com;=20 > bwijnen@lucent.com; Black_David@emc.com > Subject: Re: [imss] RE: AD review of:=20 > draft-ietf-imss-fc-rtm-mib-03.txt >=20 > Bert, >=20 > While you and I both agree with the boilerplate's=20 > recommendations for the implementation and use of SNMPv3, it=20 > is my belief that at least one of them is trying to impose=20 > the use of SNMPv3 on implementors and/or operators, and=20 > therefore, given that RFC 2119 says: >=20 > 6. Guidance in the use of these Imperatives >=20 > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. >=20 > I suggest that we must not use these imperatives in this situation. > (Note that the above paragraph from 2119 actually contains "must not" > in lower case, i.e., it is wrong to capitalise every=20 > occurrence of these imperatives.) >=20 > Keith. >=20 > > I think it is better to keep the CAPITALIZED language and add > > (use) the reference to rfc2119. > >=20 > > Bert > >=20 > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Saturday, April 08, 2006 22:31 > > > To: dromasca@avaya.com > > > Cc: bwijnen@lucent.com; kzm@cisco.com; sgai@cisco.com;=20 > > > cds@cisco.com; imss@ietf.org; skode@cisco.com; Black_David@emc.com > > > Subject: Re: [imss] RE: AD review of:=20 > > > draft-ietf-imss-fc-rtm-mib-03.txt > > >=20 > > >=20 > > > > Anybody can explain shortly the reason of the change=20 > RECOMMENDED=20 > > > > -> recommended? > > >=20 > > > Yes, I changed it because the 'idnits' tool complained about it. > > >=20 > > > In fact, RFC 2119 says: > > > .... Authors who follow=20 > these guidelines > > > should incorporate this phrase near the beginning of their > > > document: > > >=20 > > > The key words "MUST", "MUST NOT", "REQUIRED",=20 > "SHALL", "SHALL > > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > > "OPTIONAL" in this document are to be interpreted=20 > as described=20 > > > in > > > RFC 2119. > > >=20 > > > So, since http://ops.ietf.org/mib-security.html contains no=20 > > > mention of RFC 2119, and no mention of including the=20 > above paragraph=20 > > > in the MIB document, I presumed that its use of=20 > "RECOMMENDED" is not=20 > > > in the sense of RFC 2119. Therefore, I changed the=20 > document to be=20 > > > idnits-compliant by making the simplest, least disruptive change,=20 > > > which is most consistent with all previous RFCs that I have=20 > > > generated containing recommendations for use and deployment of=20 > > > SNMPv3, including the two RFCs which this WG had published last=20 > > > week. > > >=20 > > > Keith. > > > =20 > > > >=20 > > > > Thanks, > > > >=20 > > > > Dan > > > >=20 > > > > > -----Original Message----- > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > Sent: Thursday, April 06, 2006 12:42 AM > > > > > To: Keith McCloghrie; Romascanu, Dan (Dan) > > > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org;=20 > > > > > skode@cisco.com; Black_David@emc.com > > > > > Subject: RE: [imss] RE: AD review of:=20 > > > > > draft-ietf-imss-fc-rtm-mib-03.txt > > > > >=20 > > > > > Keith/Dan, > > > > > I am basically happy with revision 3. > > > > >=20 > > > > > I am surprised to see that RECOMMENDED was changed to=20 > lowercase=20 > > > > > in the security considerations section. > > > > > If I were still AD I would require that to be changed back to=20 > > > > > upper case as per the template at: > > > > > http://www.ops.ietf.org/mib-security.html > > > > >=20 > > > > > That template text was agreed to by MIB doctors and Security=20 > > > > > Area geeks a few years back, and it was not easy to agree > > > on the text. > > > > >=20 > > > > > Doc is ready for IETF LC, above comment can be addressed as=20 > > > > > rfc-editor note or be considered IETF LC comments. > > > > >=20 > > > > > Bert > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > > Sent: Wednesday, March 08, 2006 21:17 > > > > > > To: Keith McCloghrie > > > > > > Cc: sgai@cisco.com; cds@cisco.com; imss@ietf.org; > > > > > dromasca@avaya.com; > > > > > > skode@cisco.com; Black_David@emc.com > > > > > > Subject: [imss] RE: AD review of:=20 > > > draft-ietf-imss-fc-rtm-mib-02.txt > > > > > >=20 > > > > > >=20 > > > > > > Inline > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > > > > Sent: Wednesday, March 08, 2006 16:21 > > > > > > > To: bwijnen@lucent.com > > > > > > > Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com;=20 > > > > > > > kzm@cisco.com; sgai@cisco.com; imss@ietf.org; > > > dromasca@avaya.com > > > > > > > Subject: Re: AD review of:=20 > draft-ietf-imss-fc-rtm-mib-02.txt > > > > > > >=20 > > > > > > >=20 > > > > > > > Bert, > > > > > > >=20 > > > > > > > Thanks for the review. > > > > > > >=20 > > > > > > Welcome > > > > > >=20 > > > > > > > > This document is ready for IETF Last Call. > > > > > > > >=20 > > > > > > > > One topic that I would prefer to see addressed: > > > > > > > >=20 > > > > > > > > - When I see: > > > > > > > > t11FcRouteDestAddrId OBJECT-TYPE > > > > > > > > SYNTAX FcAddressIdOrZero > > > > > > > > MAX-ACCESS not-accessible > > > > > > > > STATUS current > > > > > > > > DESCRIPTION > > > > > > > > "The destination Fibre Channel Address > > > Identifier of > > > > > > > > this route. A zero-length string for > > > this field is > > > > > > > > not allowed." > > > > > > > > ::=3D { t11FcRouteEntry 1 } > > > > > > > >=20 > > > > > > > > I then wonder why the syntax is not: > > > > > > > >=20 > > > > > > > > SYNTAX FcAddressIdOrZero (SIZE(3)) > > > > > > > >=20 > > > > > > > > So that the restriction that zero-length is=20 > not allowed is > > > > > > > > also machine readable. > > > > > > > =20 > > > > > > > While I agree in principle, I think it also has one > > > other effect:=20 > > > > > > > it changes t11FcRouteDestAddrId from being a > > > > > variable-length string > > > > > > > into a fixed-length string, which only matters because=20 > > > > > > > t11FcRouteDestAddrId is present in the INDEX clause, > > > and thus, I > > > > > > > fear that some implementations might get the > > > INDEX-ing wrong (re: > > > > > > > difference between bullets 2 and 3 at top of RFC > > > 2578's page 28). > > > > > > > Thus, if you really want to see the restriction > > > reflected in the > > > > > > > SYNTAX clause, I would prefer to do so as: > > > > > > >=20 > > > > > > > SYNTAX OCTET STRING (SIZE (3)) > > > > > > >=20 > > > > > > > so that it uses a regular construct, and implementors will > > > > > > immediately > > > > > > > know what to do. Do you agree ? > > > > > > >=20 > > > > > >=20 > > > > > > Thanks Keith, I had overlooked that aspect of variable > > > length for > > > > > > indexing. > > > > > > Using OCTET STRING as you suggest does fix my initial > > > comment, but > > > > > > then takes away that this is a FCAddressId. > > > > > > So I am not sure which choice I prefer. Does WG have > > > any comments? > > > > > > Are there any implementers on the list who want to comment? > > > > > >=20 > > > > > > So I have no firm opinion on which choice I like=20 > best anymore. > > > > > >=20 > > > > > >=20 > > > > > > > > Could be addressesd after IETF Last Call, even with an > > > > > > > RFC-Editor note. > > > > > > > >=20 > > > > > > > > Mainly have some NITs below. > > > > > > > > You may consider them as initial IETF Last Call=20 > comments. > > > > > > > > Let me know if you rather do a new rev first or if you > > > > > prefer to > > > > > > > > do IETF LC now. I will probably let IETF LC extend > > > > > beyond the IETF > > > > > > > > week, because people are probably busy reviewing > > > > > documents for the > > > > > > > > IETF week itself. > > > > > > > =20 > > > > > > > I'd prefer to fix them now, but I'll wait for your > > > > > response to this > > > > > > > message before doing so. > > > > > > >=20 > > > > > > > > - t11FcRouteRowStatus has a pretty meager=20 > DESCRIPTION clause > > > > > > > > For example, from the DESCRIPTION clause of > > > t11FcRouteIfDown > > > > > > > > it seems that maybe a 'destroy' to the=20 > RowStatus object > > > > > > > > may not take immediate effect? You might want to > > > > > describe that. > > > > > > > > It is also unclear if any writeable objects=20 > can be written > > > > > > > > when a row is active? > > > > > > > =20 > > > > > > > The last sentence of RowStatus's DESCRIPTION in RFC 2579 > > > > > says that a > > > > > > > 'destroy' requires the row to be removed immediately.=20 > > > There was > > > > > > > discussion in T11.5 of the relationship between this > > > > > table and the > > > > > > > routing mechanisms that a FC switch uses, and we agreed > > > > > that such a > > > > > > > relationship is proprietary, and that the MIB needs > > > to stay at > > > > > > > arms-length from being too specific about this > > > > > > relationship. Thus, I > > > > > > > would prefer not to add text talking about it. > > > > > > >=20 > > > > > > > There is one thing I can add, which is implicit in > > > > > t11FcRouteTable's > > > > > > > DESCRIPTION, but it would probably be useful to add a > > > > > more explicit > > > > > > > statement in t11FcRouteRowStatus's DESCRIPTION: > > > > > > >=20 > > > > > > > The only rows which can be deleted by=20 > setting this > > > > > > object to > > > > > > > 'destroy' are those for which t11FcRouteProto > > > > > has the value > > > > > > > 'netmgmt'. > > > > > > >=20 > > > > > > > Then, it won't be so meagre :-). > > > > > > > =20 > > > > > >=20 > > > > > > Good. > > > > > >=20 > > > > > > > > - The 4 OBJECT clauses that you did as comments in the > > > > > > > > MODULE-COMPLIANCE are normally put as=20 > comments inside the > > > > > > > > DESCRIPTION clause of the MODULE-COMPLIANCE=20 > clause itself. > > > > > > > > That way the text is better kept when MIB module gets > > > > > > > > extracted from RFC. Not a blocking comment though. > > > > > > > =20 > > > > > > > OK, I'll move them. (The downside is that the > > > > > double-quotes have to > > > > > > > change, e.g., to single-quotes). > > > > > > >=20 > > > > > > yep, but thanks for moving them. I think it makes IETF MIB > > > > > docs more > > > > > > consistent. And I just happen to like consistency=20 > in this space. > > > > > >=20 > > > > > >=20 > > > > > > > > - Section 7 seems redundant with the back matter, > > > and might as > > > > > > > > well be removed. > > > > > > > =20 > > > > > > > I'll let the RFC Editor do that. > > > > > > >=20 > > > > > >=20 > > > > > > Mmm... why is that? > > > > > > If you do a new rev anyway, why not just make it right > > > > > BEFORE it goes > > > > > > to RFC-Editor? > > > > > >=20 > > > > > > > > - In the references section, are the details for > > > [FC-SW-4] now > > > > > > > > known? If so, might want to fill them out. > > > > > > >=20 > > > > > > > Yes, we filled them in recently on one of the=20 > other FC MIBs. > > > > > > > Thanks for reminding me of that. > > > > > > >=20 > > > > > >=20 > > > > > > Thanks, > > > > > > Bert > > > > > > > Keith. > > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > imss mailing list > > > > > > imss@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > imss mailing list > > imss@ietf.org > > https://www1.ietf.org/mailman/listinfo/imss > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Apr 10 09:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwre-0004Qo-VN; Mon, 10 Apr 2006 09:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwrd-0004Qg-Rd; Mon, 10 Apr 2006 09:55:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwrd-00023Q-JT; Mon, 10 Apr 2006 09:55:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3ADtXvP028029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2006 13:55:33 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FSwrd-0003Wo-7g; Mon, 10 Apr 2006 09:55:33 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 10 Apr 2006 09:55:33 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: imss@ietf.org Subject: [imss] Last Call: 'MIB for Fibre-Channel's Fabric Shortest Path First Protocol' to Proposed Standard (draft-ietf-imss-fc-fspf-mib) 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: , 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: - 'MIB for Fibre-Channel's Fabric Shortest Path First Protocol ' as a Proposed Standard 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 2006-04-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fspf-mib-02.txt _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Apr 10 09:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwsH-0004iO-RC; Mon, 10 Apr 2006 09:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwsG-0004iF-Hb; Mon, 10 Apr 2006 09:56:12 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwsE-000242-AB; Mon, 10 Apr 2006 09:56:12 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3ADuABX026379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 13:56:10 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FSwsE-0003Zo-3j; Mon, 10 Apr 2006 09:56:10 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 10 Apr 2006 09:56:10 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: imss@ietf.org Subject: [imss] Last Call: 'Fibre-Channel Routing Information MIB' to Proposed Standard (draft-ietf-imss-fc-rtm-mib) 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: , 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: - 'Fibre-Channel Routing Information MIB ' as a Proposed Standard 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 2006-04-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-rtm-mib-03.txt _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Thu Apr 27 18:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFJC-0001qW-JF; Thu, 27 Apr 2006 18:50:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZFJB-0001qO-T8; Thu, 27 Apr 2006 18:50:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZFJB-0000pT-Kx; Thu, 27 Apr 2006 18:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3RMo10e009801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FZFJB-0002sF-7y; Thu, 27 Apr 2006 18: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: Thu, 27 Apr 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-vf-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: , 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 : The Virtual Fabrics MIB Author(s) : S. Kipp, et al. Filename : draft-ietf-imss-fc-vf-mib-02.txt Pages : 23 Date : 2006-4-27 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 Virtual Fabrics function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-vf-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-vf-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-vf-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: <2006-4-27155337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-vf-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-vf-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-27155337.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 Apr 28 17:22:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaPe-0007fr-UW; Fri, 28 Apr 2006 17:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZaPc-0007dN-IR; Fri, 28 Apr 2006 17:22:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZ8n-0008Q2-Ge; Fri, 28 Apr 2006 16:00:37 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FZZ1q-0005SQ-AR; Fri, 28 Apr 2006 15:53:27 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3SJo1BX000402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FZYyX-0007X8-PM; Fri, 28 Apr 2006 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, 28 Apr 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: imss@ietf.org Subject: [imss] I-D ACTION:draft-ietf-imss-fc-rtm-mib-04.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: , 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-04.txt Pages : 22 Date : 2006-4-28 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-04.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-04.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-04.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: <2006-4-28145751.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imss-fc-rtm-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imss-fc-rtm-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-28145751.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 Apr 28 17:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZakD-0008T5-Hu; Fri, 28 Apr 2006 17:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZakC-0008T0-96 for imss@ietf.org; Fri, 28 Apr 2006 17:43:20 -0400 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 1FZakB-0008Q8-UB for imss@ietf.org; Fri, 28 Apr 2006 17:43:20 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2006 14:43:20 -0700 X-IronPort-AV: i="4.04,165,1144047600"; d="scan'208"; a="321236235:sNHT30144306" Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3SLhJw1014135 for ; Fri, 28 Apr 2006 14:43:19 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA28940 for imss@ietf.org; Fri, 28 Apr 2006 14:42:59 -0700 (PDT) From: Keith McCloghrie Message-Id: <200604282142.OAA28940@cisco.com> Subject: [imss] I-D ACTION:draft-ietf-imss-fc-rtm-mib-04.txt (fwd) To: imss@ietf.org Date: Fri, 28 Apr 2006 14:42:59 -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: a7d2e37451f7f22841e3b6f40c67db0f 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: , Errors-To: imss-bounces@ietf.org FYI. The new version (see below) was to fix some editorial issues that a GenART review (see draft-doria-genart-experience-01.txt) raised. Keith. ------------- Forwarded message: > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Date: Fri, 28 Apr 2006 15:50:01 -0400 > Cc: imss@ietf.org > Subject: [imss] I-D ACTION:draft-ietf-imss-fc-rtm-mib-04.txt > > --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-04.txt > Pages : 22 > Date : 2006-4-28 > > 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-04.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-04.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-04.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: <2006-4-28145751.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-imss-fc-rtm-mib-04.txt > > --OtherAccess > Content-Type: Message/External-body; name="draft-ietf-imss-fc-rtm-mib-04.txt"; > site="ftp.ietf.org"; access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <2006-4-28145751.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-- > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss