Proposed Responses to the CAM public review comments.

Lansing J Sloan ljsloan at anduin.ocf.llnl.gov
Fri May 5 14:43:23 PDT 1995


Membership of X3T10 (SCSI Reflector):
     
     Here are my comments on the proposed responses to LLNL's
public review comments on CAM, as supplemented by a discussion
with Bill and by looking at a red-lined document showing changes.
     
     I am satisfied with all proposed responses except as noted
below.  I am in full agreement with getting CAM finished
and moving on to CAM-3.  Therefore, I can easily accept
continuing rejection of comments.
     
     The urgent items (if there are any ) are old comment #058
and new comment #190.
     
     I have not read the entire red-lined document, not even all
of the text changed in response to the comments, and do not
expect time for careful reading.
                                
                      NEW SPECIFIC COMMENTS
     
     These are based on the red-lined document.  They start with
#187, to continue the original numbering.

#187 (E) Comment on 5.1, first paragraph, third sentence
     
     The new comma after "peripheral drivers" is not needed.

#188 (E) Comment on 9.1.4, 10.2, and possibly elsewhere
     
     Consider changing references to "CAM-2" to say "CAM-3" or
consider saying "future versions of CAM".  The cases I've noticed
are in notes that apply to CAM status 1Ah, but a global search
may be warranted, and different changes may be appropriate
depending on the context.

#189 (E) Comment on 7.8, following typedef of CAM_SIM_ENTRY
     
     In the first sentence, "calls" should be "call" -- "... the
XPT shall update ... and call ...".

#190 (E) Comment on 8.1.6.1, under a) xpt_init()
     
     The red-lined document appears to have three paragraphs
under a) long xpt_init().  The last two appear to be nearly
redundant.  The third, which discusses CAM status, seems
incorrect and should be removed.

#191 (E) Comment on 9.2.3, first paragraph
     
     In the second sentence, consider replacing "other HBAs" with
"HBA/SCSI bus(es)".  Regarding "other", it is not clear what this
word means.  (Does the caller want "further" information on
unaddressed HBAs?)
     
     In the third sentence, "... only fields ... is ..." should
be "... only fields ... are ...", since two fields are valid.

#192 (E) Comment on 11.3.8.2, step A)
     
     I originally completely misunderstood the intent of step A.
I did not realize that step A discusses a situation where the SIM
shall not proceed with the remaining steps.  I've said orally
that it is desirable to be very clear whenever performing a step
means that processing is done and/or later steps are to be
skipped.
     
     This may apply to other places in the document also.

#193 (E) Comment on 12
     
     I like the new text.  Here are a few nits.  (Note: 12.1 and
12.2 seem fine.)  Should the title of clause 12 be "HBA engines"
or "SIM/HBA engines"?  In paragraph 1, sentence 1, should "an
HBA" be "a SIM/HBA"?  In paragraph 1, last sentence, in "an
peripheral HBA" should "an" be "a" and should HBA" be "SIM/HBA"?
In the last sentence of paragraph 2, in "an SIM/HBA" should "an"
be "a"?  In paragraph 3, should the first sentence end with "HBA"
or "SIM/HBA"?  In the last sentence of paragraph 3, in "an
SIM/HBA" should "an" be "a"?

#194 (E) Comment on 11.3.3.1.5, step E)
     
     Consider deleting "The SIM/HBA shall" from the beginning of
the sentence and capitalizing the following word.
                                
           COMMENTS ACCEPTED BUT PROBLEMS WITH CHANGES

#055 (E) Comment on 9.2.2, 9.2.3, 9.2.4, 9.2.7 and 9.2.8
     
     In many of the bullets listing CAM Status values,
"indicates" is followed by an unneeded comma.  This occurs 3
times in 9.2.2, 3 times in 9.2.3, 1 time in 9.2.4, 2 times in
9.2.7, and 2 times in 9.2.8.
     
     *** The changes did not get made in 9.2.8.

#063 (E) Comment on 9.2.4, second paragraph
     
     In each bullet, insert "if the" before "CAM Flag".
     
     ...
     
     *** For the second bullet in the red-lined document, "If CAM
Flag" should be "If the CAM Flag".  The intended change was not
fully carried out.

#116 (E) Comment on various including 11.3.3.1.2.1, step G)
     
     Consider deleting "The SIM/HBA shall" from the beginning of
each of the first two sentences and capitalizing the following
word.
     
     Make similar changes in 11.3.3.1.3.2 H), 11.3.3.1.3.3 G),
11.3.3.1.4 D), and the one sentence in 11.3.3.1.5 F).
     
     *** In the red-lined document 11.3.3.1.5 F is not corrected.

#166 (E) Comment on Annex B.1.1
     
     The first assignment should be to "target1CCB" rather than
"targetCCB1", for consistency with the rest of B.1.1 and B.1.2.
     
     *** The wrong line was changed.  A copy of the first two
lines under "Initialization sequence with multiple target CCBs
provided" would be good for the first two lines under
"Initialization sequence with single target CCB provided".
                                
                      OLD SPECIFIC COMMENTS

#020 (E) Comment on 6.4, item g) in list of requirements
     
     Does "determine" mean "learn" or does "determine" mean
"control".  The word "determine" is quite ambiguous here, and
should be replaced with an unambiguous term.
     
     A global electronic search for other ambiguous uses of
"determine" may be worth while.

>Rejected -  The usage is not ambiguous.  The definition of
>"determine" is the following:
>     "to obtain definite and firsthand knowledge"
>The dictionary definition does not include "to control".
     
     After looking at Webster's Ninth New Collegiate Dictionary,
I believe there is ambiguity.  That dictionary includes a number
of definitions of "determine," including the following.  (1c) to
settle or decide by choice of alternatives or possibilities.
(4a) to find out or come to a decision about by investigation,
reasoning, or calculation.  Synonyms: "see DECIDE, DISCOVER". I
suggest replacing "determine" with "find out" or "discover".
     
     

#032 (E) Comment on 7.5, third paragraph, first bullet
     
     Change "shall ensure that" to "shall check whether".

>Rejected - The use of "shall ensure that" is stronger.
     
     "Shall check whether" seems preferable.  The second and last
bullets state what to do depending on the results of the check.
They appear to cover all possible outcomes.
     
     

#058 (T) Comment on 9.2.3, second paragraph below table 8
     
     In the second paragraph below table 8, it's not clear how
the revision number for a standard would be determined.  (Annex C
has the value corresponding to revision 11, but is not normative.
And the revision number for the standard clearly could change.)

>Rejected -  It is felt the text clear denotes how to determine
>the revision number.
     
     If the revision number is known, the text is clear regarding
what to put in the Version Number field.  The problem is how to
determine the revision number.  If Revision 12a is what ANSI
approves as a standard, by the time ANSI editors have done
whatever they do will there be any evidence in the standard that
the revision number is 12a?



#091 (T) Comment on 11.2.1
     
     Text should be added to specify whether the SIM/HBA is
expected to free Target CCBs when a specific LUN is disabled or
whether the driver is responsible for the CCBs after the LUN is
disabled.  The eighth paragraph following Table 22 (the paragraph
that begins "To disable the selection of a specific LUN ...) may
be one good place for such text.

>Accepted - Document updated.

>New wording:
>Upon disabling the specified LUN, the target peripheral driver
>may free all
>allocated Target CCBs that were associated to the enabled LUN.
     
     An editorial nit in the new text: in "associated to" should
"to" be "with"?
     
     The change clarified the intent of CAM.  My concern is now
whether the driver has a way of knowing if CCBs have been freed.
If yes, there is nothing for the driver to do.  If not, then the
driver should free (or possibly re-use) them.  Is there
sufficient information for the driver to know whether the CCBs
were freed or not?  That seems important.  If the drivers knows
the CCBs were not freed, is there enough information for the
driver to be able to find and free or re-use the CCBs?  (Clearly
a driver could create its own data structure to keep track, but
is the information already available?)



#134 (E) Comment on 11.3.6, step D) 6) for drivers
     
     In the last sentence, change "is greater" to "larger".

>Rejected - The use of "is greater" is appropriate.
     
     At least delete the "is" since the sentence currently says
"... is greater" ... is desired ...", or make some other
correction.  Since the size (not the value) of a field is being
discussed, "larger" seems better than "greater."



#141 (T) Comment on 11.3.8.2, step G)
     
     "CDB completion" should be "CDB received".

>Rejected  - The term "CDB completion" is correct since  a  total
CDB >may not be received.

#142 (T) Comment on 11.3.8.3
     
     In the title of this clause and in the first sentence, "CDB
completion" should be "CDB received" in both places.  In the
title, capitalize "Received".

>Rejected  - The term "CDB completion" is correct since  a  total
CDB >may not be received.
     
     Regarding comments 141 and 142, I remain unhappy with "CDB
completion" but suspect a good correction would require changes
in several places.  In 11.1, the fifth paragraph introduces
target mode and uses the clear (though lengthy) wording
"Peripheral Driver CDB Received Completion Function".  In
11.3.8.1 step (B), perhaps "CDB completion function" should be
either the lengthy wording or else change "CDB" to "CCB".  In
11.3.9, provide a description of what goes into the various
fields or point to other clauses that specify what goes in them
(appropriate only for the fields where the ACCEPT TARGET I/O CCB
is distinctive).  And check for other places in the document
where "CDB completion" is used to mean that a CDB was received
rather than that it was completely processed.  Conclusion: do
nothing until CAM-3.
                                
                 COMMENT ON SUMMARY OF RESPONSES
     
     Comments 046, 075, 083, 085, and 107 have always been
editorial; 046 did not need to be downgraded and the others are
rejected editorial comments, not rejected technical comments.
                                
                      COMMENTS ON RESPONSES
     
     In the response to 090, the new and old words were
mislabeled and probably interchanged.
     
     For comment 169 no response was stated in the list of
responses.  (CAM was fixed, I assume the response should be
"Accepted - document updated.")
                                
                          OTHER REMARKS
     
     After looking at the proposed response to #101, I understand
and agree.  Sorry for the confusion over the phone, Bill.
                                
                         END OF COMMENTS
     
     
                         Sincerely,



                         Lansing J. Sloan






More information about the T10 mailing list