Subject: [Gen-art] Gen-ART review of draft-ietf-ips-iscsi-impl-guide-08.txt

From: Suresh Krishnan <[email-masked]>
Date: Mon, 04 Jun 2007 16:12:58 -0400

I am the assigned Gen-ART reviewer for
draft-ietf-ips-iscsi-impl-guide-08.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is ready for publication, but I have some suggestions.

Comments: Overall the draft is well written and has a really well 
written IANA Considerations section.

Minor
=====

* Section 4.1.2 c

"     c. Should receive the TMF Response concluding all the tasks in
           the set of affected tasks. "

I am not sure of the intent of the sentence, but I believe it to be 
normative. So I think the "Should" needs to be replaced with a SHOULD.

* It is really unclear from the draft how to differentiate between the 
following types of information
   - Updates to RFC3720
   - New behavior on top of RFC3720
   - Clarifications and implementation advice

since they are intermingled throughout the document.

I tried to skim through RFC3720 but the document is HUGE. It would be 
really helpful to have a section in this draft listing just the updates 
made to RFC3720 so that people trying to implement just the updates can 
easily find such info in the document.

e.g.

Topic		Section in draft	Updated Section in RFC3720
R2T Ordering	3.2			10.8
...

* For section 11.2 iSCSI Opcodes, the document mentions the following

"Fields to record in the registry: Assigned value, Who can
originate (Initiator or Target), Operation Name and its
associated RFC reference"

Since the op codes can also be assigned using the Expert Review process, 
it should probably mention that the RFC reference is optional.

Editorial
=========

* RFC2119 occurs twice in the references. Once as normative and once as 
informative

Cheers
Suresh

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Jun 2007 16:58:07 +0300

Suresh,

thanks for the review.

Authors, if you'd like to incorporate any of these suggestions,  
please email me a corresponding RFC Editor Note.

Lars

On 2007-6-4, at 23:12, ext Suresh Krishnan wrote:
> * It is really unclear from the draft how to differentiate between  
> the following types of information
>   - Updates to RFC3720
> I tried to skim through RFC3720 but the document is HUGE. It would  
> be really helpful to have a section in this draft listing just the  
> updates made to RFC3720 so that people trying to implement just the  
> updates can easily find such info in the document.
>
> e.g.
>
> Since the op codes can also be assigned using the Expert Review  
> process, it should probably mention that the RFC reference is  
> optional.
>
> Editorial
> =========
>
> * RFC2119 occurs twice in the references. Once as normative and  
> once as informative
>
>
> Cheers
> Suresh
>

Lars

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 06 Jun 2007 11:35:16 -0700

Suresh,

Appreciate your comments/summary and taking the time to review.

 > normative. So I think the "Should" needs to be replaced with a SHOULD.

I had intentionally left it non-normative because initiator may have 
other reasons to take down connection and session concurrent with (or 
even because of) this TMF activity.  In the SCSI architecture, the 
initiator has the last word on what size of hammer it can use to drive 
error recovery, and multi-task abort, LU reset, target reset, connection 
drops, and session drops are all varying sizes of hammers at its 
disposal.  I didn't want to require the initiator to wait in order to 
receive a TMF Response.

 > following types of information

While I agree that the three kinds of information are inter-mingled 
throughout the document, the differentiation though is clearly called 
out in respective sections.  In the case when an existing 3720 semantics 
are being modified, the draft specifically quotes the 3720 section (and 
text in most places) being modified.

I will see what if any we can do further improve the draft.  I know the 
volumninous nature of 3720, but in most cases, I am afraid an 
implementer will have no choice but to read 3720 and this draft.

 > it should probably mention that the RFC reference is optional.

Thanks for catching a potential ambiguity in the draft.  The intent of 
the draft was to require using _both_ processes for each opcode 
allocation request, here's how it's intended to work:

OLD:
    Allocation Policy:

    Standards Action ([IANA]), Expert Review ([IANA])

NEW:

    Allocation Policy:

    Standards Action ([IANA]): This is required for defining
    the semantics of the opcode

    Expert Review ([IANA]): This is required for selecting
    the specific opcode(s) to allocate in order to ensure
    compliance with the above Allocation request guidance

I will propose it as an RFC Editor item.

 > * RFC2119 occurs twice in the references. Once as normative and once as

Ah, thank you.  Another item for me to track.

Thanks!

Mallikarjun