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

[Keith McCloghrie <[e-mail]>]

Bert,

Thanks for the review.

> 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 ?

>   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 :-).
 
> - 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).

> - Section 7 seems redundant with the back matter, and might as
>   well be removed.
 
I'll let the RFC Editor do that.

> - 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.

Keith.

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