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

["Wijnen, Bert (Bert)" <[e-mail]>]

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