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

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

Anybody can explain shortly the reason of the change RECOMMENDED ->
recommended? 

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