Suresh,
Appreciate your comments/summary and taking the time to review.
> 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.
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.
> * It is really unclear from the draft how to differentiate between the
> 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.
> Since the op codes can also be assigned using the Expert Review process,
> 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
> informative
Ah, thank you. Another item for me to track.
Thanks!
Mallikarjun
Suresh Krishnan wrote:
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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
