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

["Romascanu, Dan \(Dan\)" <[e-mail]>]

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. 

This looks to me enough liberty for implementers to do something else
and for operators to deploy something else if they have good reasons. 

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


 
 

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: Sunday, April 09, 2006 6:55 AM
> To: "Wijnen, Bert (Bert)"
> Cc: Keith McCloghrie; Romascanu, Dan (Dan); [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: [imss] RE: AD review of: 
> draft-ietf-imss-fc-rtm-mib-03.txt
> 
> 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:[e-mail]]
> > > Sent: Saturday, April 08, 2006 22:31
> > > To: [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > > [e-mail]; [e-mail]; [e-mail]; [e-mail]
> > > 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:[e-mail]]
> > > > > Sent: Thursday, April 06, 2006 12:42 AM
> > > > > To: Keith McCloghrie; Romascanu, Dan (Dan)
> > > > > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > > > > [e-mail]; [e-mail]
> > > > > 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:[e-mail]]
> > > > > > Sent: Wednesday, March 08, 2006 21:17
> > > > > > To: Keith McCloghrie
> > > > > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > > > [e-mail];
> > > > > > [e-mail]; [e-mail]
> > > > > > Subject: [imss] RE: AD review of: 
> > > draft-ietf-imss-fc-rtm-mib-02.txt
> > > > > > 
> > > > > > 
> > > > > > Inline
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Keith McCloghrie [mailto:[e-mail]]
> > > > > > > Sent: Wednesday, March 08, 2006 16:21
> > > > > > > To: [e-mail]
> > > > > > > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > > > > > > [e-mail]; [e-mail]; [e-mail];
> > > [e-mail]
> > > > > > > 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
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/imss
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> > _______________________________________________
> > imss mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/imss
> > 
> 

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