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

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

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