[Ips] RE: Gen-ART review of draft-ietf-ips-scsi-mib-08

[[e-mail]]

Harald,

Thanks for the review.  We clearly need to respin the document.  Let
me try to deal with your comments, as I'm the responsible WG chair:

> [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 answer to both questions is "yes", and there are two issues here:

(1) The REFERENCE clauses are wrong, even though the content of the
	referenced document is the same as what should have been referenced,
	and that content is stable.  The correct references are those given
	in the normative references section, namely ANSI INCITS 366-2003
	and ANSI INCITS 351-2001, and those need to be used in the REFERENCE
	clauses.

(2) For the normative references, the actual references are to the real
	standards (ANSI INCITS), which one is expected to pay for.  T10
	makes the final working drafts available at the URLs given in the
	references, with the following disclaimer:

  This page includes the T10 working draft documents. There are no approved
  (official) standards here. Once a standard is approved, you should buy it
  from ANSI ([phone]). Your payment insures that you receive the
  actual standard with all the final changes and it supports the standards
  process. In most cases, the final T10 committee working draft revision
  for a project is retained here. The drafts are used by T10 Committee
  members for reference. In case of any conflict, the published ANSI
  standard prevails.

Issue (1) is sufficient to require a respin of the document - IMHO, any
change to MIB content requires a respin, lest the RFC Editor do something
that prevents the MIB from compiling, and there's an actual change to
MIB content needed to deal with something else you found.

Issue (2) is more subtle.  The URLs are in the draft in order to
facilitate development and technical review of the MIB.  They should
stay there until at least completion of IESG review (and T10 has no
problem with this), but probably should be introduced as "final draft
available at <URL>".

I suggest use of a note to the RFC Editor (in the revised draft) to
remove the URLs, so that they remain available for IESG review purposes.
A quick check of other IETF documents (published RFCs and drafts in
the RFC Editor queue) suggests that we have not included URLs for
these sorts of references in the past.

This URL issue also affects some of the informative reference.
Thanks for catching this.

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

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

It wouldn't hurt to add statements that they are potentially writable
- note that the compliance section contains numerous statements saying
that write access is not required.

> SAS (Serial Attached SCSI) is not mentioned at all. Is it irrelevant, or 
> "just another transport"? Or is this what's called "scsiTransportSBP"?

None of the above - SBP is SCSI over IEEE 1394 (Firewire).  SAS is
different, important and definitely should be added - one more reason
for a respin.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[e-mail]] 
> Sent: Tuesday, January 17, 2006 10:03 AM
> To: [e-mail]
> Cc: [e-mail]; Black, David; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Gen-ART review of draft-ietf-ips-scsi-mib-08
> 
> 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.
> 

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