RE: Protocol Action: iSCSI to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Loa, I would make this stronger still - the problem as I understood it
was that "transport" is ambiguous (in the world of iSCSI), so even in
the presence of "strong and explicitly stated reasons" to call SCSI 
transport "transport", more IETF reviewers will be confused than
enlightened.

I'd go for a requirement for Internet terminology - SCSI transport
would always be qualified, in this case.

Spencer

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se]
> Sent: Friday, February 14, 2003 1:43 AM
> To: RJ Atkinson
> Cc: Mallikarjun C.; Bob Braden; sob@harvard.edu; mankin@psg.com;
> ips@ece.cmu.edu; ietf@ietf.org
> Subject: Re: Protocol Action: iSCSI to Proposed Standard
> 
> 
> 
> Ran,
> 
> would agree to this, and put even stronger
> 
> "... Internet RFCs the normal Inernet terminology SHOULD be 
> used, unless 
> there
> are very stong and explicitly stated reasons not to ..."
> 
> it should als  be that the I* have a guiding role in this
> 
> /Loa
> 
> 
> RJ Atkinson wrote:
> 
> >
> > On Wednesday, Feb 12, 2003, at 13:24 America/Montreal, 
> Mallikarjun C. 
> > wrote:
> >
> >>> All the Internet documentation with which I am familiar, 
> as well as the
> >>
> >>
> >> I think we have a case of overlapping vocabulary from two 
> different 
> >> domains.
> >>
> >> Per SCSI Architecture Model (SAM-2, SAM-3), iSCSI is very clearly
> >> a "SCSI transport protocol" (as opposed to a SCSI 
> application layer 
> >> protocol).
> >> Parallel SCSI, Fibre Channel etc. are all "SCSI 
> transports" per SCSI 
> >> conventions.
> >> That is all the critiqued abstract is trying to describe.
> >
> >
> > In the context of an *Internet* RFC, it seems sensible to 
> use the normal
> > Internet terminology -- unless one very very clearly 
> indicates that a
> > term is being used in some different semantic.  One might 
> postulate that
> > the document's editors and RFC-Editor could work out a 
> mutually agreeable
> > editorial change here to add clarity.
> >
> > Ran
> >
> >
> >
> >
> 
> 
> 
> _______________________________________________
> This message was passed through 
> ietf_censored@carmen.ipv6.cselt.it, which is a sublist of 
> ietf@ietf.org. Not all messages are passed. Decisions on what 
> to pass are made solely by Raffaele D'Albenzio.
> 





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]