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

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

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.


> From [e-mail] Wed Mar 08 15:16:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FH55N-0000PK-4Z; Wed, 08 Mar 2006 15:16:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55L-0000PA-Rm
	for [e-mail]; Wed, 08 Mar 2006 15:16:39 -0500
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH55L-00074v-HS
	for [e-mail]; Wed, 08 Mar 2006 15:16:39 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k28KGWjC023323; 
	Wed, 8 Mar 2006 14:16:32 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <G3YWVF13>; Wed, 8 Mar 2006 21:16:31 +0100
Message-ID: <[e-mail]>
From: "Wijnen, Bert (Bert)" <[e-mail]>
To: Keith McCloghrie <[e-mail]>
Date: Wed, 8 Mar 2006 21:16:31 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
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
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:[e-mail]?subject=subscribe>
Errors-To: [e-mail]

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