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

From: Keith McCloghrie <[email-masked]>
Date: Sat, 8 Apr 2006 13:31:29 -0700 (PDT)

> 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:[email-masked]] 
> > Sent: Thursday, April 06, 2006 12:42 AM
> > To: Keith McCloghrie; Romascanu, Dan (Dan)
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > 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:[email-masked]]
> > > Sent: Wednesday, March 08, 2006 21:17
> > > To: Keith McCloghrie
> > > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; 
> > > [email-masked]; [email-masked]
> > > Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
> > > 
> > > 
> > > Inline
> > > 
> > > > -----Original Message-----
> > > > From: Keith McCloghrie [mailto:[email-masked]]
> > > > Sent: Wednesday, March 08, 2006 16:21
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > > > [email-masked]; [email-masked]; [email-masked]; [email-masked]
> > > > 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
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/imss
> > > 
> > 
> 

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss

---

From: Keith McCloghrie <[email-masked]>
Date: Sat, 8 Apr 2006 20:54:35 -0700 (PDT)

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
> 
> > Sent: Saturday, April 08, 2006 22:31
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [imss] RE: AD review of: