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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 6 Mar 2006 19:33:52 +0100

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.

  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.

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

- Section 7 seems redundant with the back matter, and might as
  well be removed.

- In the references section, are the details for [FC-SW-4] now
  known? If so, might want to fill them out.

Bert

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 8 Mar 2006 21:16:31 +0100

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Wednesday, March 08, 2006 16:21
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
> 
> 
> Bert,
> 
> Thanks for the review.
> 
Welcome

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

> From [email-masked] Wed Mar 08 15:16:43 2006
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Keith McCloghrie <[email-masked]>
Date: Wed, 8 Mar 2006 21:16:31 +0100 
Cc: [email-masked], [email-masked], [email-masked], [email-masked],
	[email-masked], [email-masked]
Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Wednesday, March 08, 2006 16:21
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
> 
> 
> Bert,
> 
> Thanks for the review.
> 
Welcome

> 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.
> > 
> I'd prefer to fix them now, but I'll wait for your response to this
> message before doing so.
> 
> 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.

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

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

> Yes, we filled them in recently on one of the other FC MIBs.
> Thanks for reminding me of that.
> 

Thanks,
Bert
> Keith.