Re: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-03.txt

Keith McCloghrie <kzm@cisco.com> Sun, 09 April 2006 03:54 UTC

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 <kzm@cisco.com>
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
Date: Sat, 08 Apr 2006 20:54:35 -0700
In-Reply-To: <no.id> 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 <kzm@cisco.com>, 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 <imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=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