Subject: [Gen-art] Gen-ART review of draft-ietf-ips-scsi-mib-08

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2006 16:02:41 +0100

This is a Gen-ART review.
For Gen-ART info, see this 
URL:<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>

Document: draft-ietf-ips-scsi-mib-08.txt
Reviewer: Harald Alvestrand
Date: Jan 17, 2006
Summary: Excellent document, two important comments.

I enjoyed reading this document! - the intro to SCSI and its history was 
fun to read!
----------------------------------------------------------
Two important questions, that may warrant a respin of the document if I'm 
right that there's a problem here:

[SAM-2] and [SPC2] are normative references (defines format for ScsiLUN and 
other things), but are listed as Working Drafts in the REFERENCE clauses of 
multiple MIB objects. (In the references section, the draftness seems 
implied by the URL only)
Is this stable enough for an IETF standard reference?
Or are the references in the MIB wrong?

The term "running at high speed" is a gating criterion for whether or not 
the HS counters are mandatory, but I can't see that it's defined in a 
testable way. Might have missed it - it would logically seem to belong in 
section 7.5.
-------------------------------------------------------------
Questions, that I'd like to have answered in email, but don't warrant a 
respin in my opinion:

The scsiDscTgtTable and scsiAuthorizedIntr table seem to form "access 
lists". They seem to be read-write via SNMP. Should this be explicitly 
mentioned in the intro in section 5?
The security considerations for these objects are very good, and make it 
very clear that they're writable!

SAS (Serial Attached SCSI) is not mentioned at all. Is it irrelevant, or 
"just another transport"? Or is this what's called "scsiTransportSBP"?
-------------------------------------------------------------
Nits, which IMHO you can fix or not as you feel like:

Some byzantine sentences...

7.3 "another logical unit changes its status to from available" is missing 
something

7.4 "at 10GBit/second with 512 read/write operations" seems to be missing a 
byte :-)

RFC 2119 is listed as an informative reference. I think it needs to be 
normative.
_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: [email-masked]
Date: Tue, 17 Jan 2006 12:40:28 -0500

Harald,

Ok, there's some text in Section 7.5 that's already headed in
that direction, so we'll see about writing a "MUST implement"
requirement for the Counter64 items based on interface speed.

Thanks,
--David 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Harald Tveit Alvestrand
> Sent: Tuesday, January 17, 2006 11:17 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [Gen-art] RE: Gen-ART review of draft-ietf-ips-scsi-mib-08
> 
> Thanks for the quick feedback, David!
> 
> I'm happy to leave this in your hands - one comment only:
> 
> --On tirsdag, januar 17, 2006 11:02:36 -0500 
> [email-masked] wrote:
> 
> >> The term "running at high speed" is a gating criterion for whether or
> >> not  the HS counters are mandatory, but I can't see that it's defined
in
> >> a  testable way. Might have missed it - it would logically seem to
> >> belong in  section 7.5.
> >
> > Unfortunately, it's fuzzy and not testable in all cases.  Here's what
> > RFC 4181 (Section 4.6.1.2) has to say about this issue:
> >
> >    Henceforth "standard" MIB modules MAY
> >    use the Counter64 type when it makes sense to do so, and MUST use
> >    Counter64 if the information being modelled would wrap in less than
> >    one hour if the Counter32 type was used instead.
> >
> > It clearly "makes sense" to use the Counter64 type, as there are SCSI
> > implementations that clearly need it based on the "would wrap in less
> > than one hour" criterion.  Would adapting the quoted RFC 4181 text
> > (with a reference to RFC 4181) be sufficient to satisfy your concern?
> 
> What I'd like to see is something that makes it a complete no-brainer 
> whether or not the HC counters are needed, for instance:
> 
>   If the interconnect speed is higher than 4 Gbits/second, the HC counters
>   MUST be implemented, since that makes it possible to spin the counters
>   in one hour (see [RFC4181]).
> 
> I wouldn't like someone to say "but... my implementation has a 10G 
> interface, but it's so badly implemented that I can't possibly get more 
> than 1 million operations per second through it, so I don't need to 
> implement the HC counters, do I?"
> 
> (4G is picked out of thin air, but illustrates the problem... if The
Number 
> is 3G, then 4G FC needs to implement it; if The Number is 9G, then only 
> people with 10GE and Infiniband interfaces need bother...)
> 
> But you know this stuff, I don't....
> 
>                      Harald
> 
> 
> 
>