Subject: RE: [Ips] ABORT TASK vs ABORT TASK SET

From: [email-masked]
Date: Tue, 7 Jun 2005 17:50:00 -0400

Mallikarjun,

> Is there a standard way to make a 
> formal linkage between RFC 3720 and this new draft, e.g. as in "when you 
> implement RFC 3720, you must/should implement the contents of draft foo 
> because foo fills in some intended but unspecified semantics of RFC 3720"

Yes, the draft will be an active IPS WG draft that says on its first page
that it "Updates" RFC 3720, and that "Updates" statement will be on it
when it (eventually) gets published as an RFC.

> Yes, I can be talked into doing that.... 

Many thanks ... I'll make sure you get useful text on the REPORT LUNS issue.

> I assume it has to be submitted as an individual submission to begin
> with?

Yes, temporarily - I need to go get AD approval for this to be an
official WG draft (and will start that process now ...).

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email-masked]] 
> Sent: Tuesday, June 07, 2005 2:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET
> 
> David,
> 
>  >What I would suggest is that we start an Internet-Draft
>  > that is intended to become an Implementers Guide RFC 
> (standards track)
> 
> I am fine with your suggestion.  Is there a standard way to make a 
> formal linkage between RFC 3720 and this new draft, e.g. as in "when you 
> implement RFC 3720, you must/should implement the contents of draft foo 
> because foo fills in some intended but unspecified semantics of RFC 3720"
> 
>  >would you be interested in editing
>  > an implementers guide Internet Draft?
> 
> Yes, I can be talked into doing that....  I assume it has to be 
> submitted as an individual submission to begin with?
> 
> Thanks.
> 
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> [email-masked] wrote:
> > Mallikarjun,
> > 
> > 
> >>I am concerned that the current lack of detailed specification would
> >>allow targets that might even cause silent data corruptions 
> >>to qualify as RFC 3720-compliant.
> >>
> >>Here are what I believe to be semantics applicable to all 
> TMF requests
> >>that can potentially terminate multiple tasks.  I do not 
> know the IETF 
> >>process well enough here, but I suggest that we consider this text 
> >>replacing the existing section 10.6.2 in RFC 3720 - so the 
> new text can 
> >>cover all the TMFs that can impact multiple tasks.  This is 
> basically a 
> >>superset of the current 10.6.2 semantics.
> > 
> > 
> > IETF does have an errata process, but (IMHO) it's not a great venue
> > for something like this that it's important for implementers to pay
> > attention to.  What I would suggest is that we start an 
> Internet-Draft
> > that is intended to become an Implementers Guide RFC 
> (standards track)
> > to include both technical corrections like this one, and 
> explanations
> > of subtle points such as how to deal with (what appear to be) REPORT
> > LUNS overruns as discussed here earlier.  An available 
> example is that
> > an implementers guide draft is being maintained for SCTP (see
> > draft-ietf-tsvwg-sctpimpguide-13.txt) although I'd like to 
> believe that
> > an iSCSI implementers guide won't grow to that size.
> > 
> > For this task management issue, explaining what the problem 
> is and why
> > the change fixes it in an implementers guide is at least as 
> important as
> > specifying the change.  For the REPORT LUNS overruns, the 
> implementers
> > guide text would be an explanation of why no change is 
> needed, including
> > some elaboration on the (less than completely obvious) 
> SPC-2 text that
> > specifies the behavior of REPORT LUNS in this circumstance. 
>  Before I
> > go looking for another volunteer, would you be interested in editing
> > an implementers guide Internet Draft?  Between Julian and 
> I, we should
> > be able write the REPORT LUNS explanation paragraph or two.
> > 
> > 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
> > ----------------------------------------------------
> 

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