RE: FCIP: RE: FCencap: List ALL SOF/EOF codes

[Black_David@emc.com]

IMHO, you're both right.  I have no problem with referencing a
major stable version of an evolving T10 or T11 document (e.g.,
iSCSI will almost certainly have to do this for SAM-2).  I also
consider FC-MI to be authoritative due to both its interoperability
focus and the expectation that it will be a de facto standard
in the industry independent of its procedural situation in T11.

I definitely want to see a reference to FC-MI, as I think
it's significant that a T11 interoperability document
prohibits Class 1 service.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Murali Rajagopal [mailto:muralir@lightsand.com]
> Sent: Tuesday, November 13, 2001 5:20 PM
> To: ENDL_TX@computer.org; IPS Reflector
> Subject: FCIP: RE: FCencap: List ALL SOF/EOF codes
> 
> 
> Ralph:
> 
> Reference [4]  in the current draft already exists for BB-2. 
> In the past
> (see RFC 2625 Ref. showing pre-standard references) I had no 
> difficulty in
> getting a RFC published with such references. Maybe Elizabeth 
> can check to
> see if this is still the practice.
> 
> -Murali
> 
> 
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On 
> Behalf Of Ralph
> Weber
> Sent: Tuesday, November 13, 2001 1:21 PM
> To: IPS Reflector
> Subject: Re: FCencap: List ALL SOF/EOF codes
> 
> I support option 3.
> 
> Option 1 fails to reflect the reality of current T11 work on
> Class 4.
> 
> Option 2 fails to consider the recent debate over iSCSI profiles.
> The IETF position on profiles (as stated by the ADs during last
> summer's debate) is that profiles must be stated as requirements
> in RFCs. Therefore, the T11 FC-MI carries the weight of a standard
> in the IETF and the FC-MI interoperability prohibition for Class 1
> must be stated in the FC Encapsulation. (Either that or those
> folks wanting to write iSCSI profiles can resharpen their pens
> for round two.)
> 
> Option 4 attempts to link the good works of option 3 with
> the bogus concept of profiles in option 2, which makes it
> every bit as bogus.
> 
> Murali's option 5 guarantees that there will be no RFC on
> FC Encapsulation until 2003 since there will be no FC-BB-2
> standard to reference until then.
> 
> Thanks.
> 
> Ralph...
> 
> Elizabeth Rodriguez wrote:
> 
> >
> > (Chair hat on)
> >
> > Let me jump back in here, and summarize as I see it:
> >
> > Codes from FC-BB cannot be taken intact, since there are 
> invalid codes
> > in that specification.
> > Codes initially trimmed in January of this year, but Ralph correctly
> > points out, that was prior to the formation of the FC encapsulation
> > draft (e.g. discussion pertained directly to FCIP; did not take into
> > consideration iFCP)
> >
> > That said, we can modify the current FC encapsulation draft 
> to include
> > other classes of service, if we so choose.
> >
> > We can choose to
> > 1) Keep the table as is.
> > Note: The current SOF/EOF codes defined in the FC 
> encapsulation draft
> > match the currently defined FC-BB-2 subset.
> >
> > 2) Add Class 1 codes
> > Note:  FC-MI (technical report, not a standard) does not 
> support Class
> > 1.
> > Note2: Practicality of Class 1 over IP questioned.
> >
> > 3) Add Class 4 codes
> > Note:  Class 4 work is ongoing, but SOF/EOF codes currently 
> defined for
> > class 4 unchanged.
> >
> > 4) Add both class 1 and class 4 codes
> >
> > I would like to solicit input from everyone on what codes 
> people feel
> > should be included in the FC encapsulation draft.
> > Note:  Drafts following FC encapsulation may restrict 
> classes of service
> > that draft supports.
> >
> > Thanks,
> >
> > Elizabeth
> >
> > -----Original Message-----
> > From: Murali Rajagopal [mailto:muralir@lightsand.com]
> > Sent: Monday, November 12, 2001 6:01 PM
> > To: Charles Monia; IPS Reflector
> > Subject: RE: FCencap: List ALL SOF/EOF codes
> >
> > On the specific topic of supported SOF and EOF codes the 
> ietf documents
> > should be driven by the specification provided in the *most 
> relevant *
> > document which in this case happens to be FC-BB-2 ant FC-MI.  FC-MI
> > should
> > be kept out of this.
> >
> > If we simply accept to adopt the SOF and EOF codes listed 
> for BB-2 the
> > problem is solved. FYI, BB-2 only supports Class 2, 3, and F codes.
> > I don't see why we are making a big deal about this.
> >
> > -Murali
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu 
> [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Charles Monia
> > Sent: Monday, November 12, 2001 3:33 PM
> > To: IPS Reflector
> > Subject: RE: FCencap: List ALL SOF/EOF codes
> >
> > Hi Folks:
> >
> > > David's observation is correct. FC-MI rev 1.8 (28 Sept 2001)
> > > prohibits Class 1 and I can find no letter ballot comments
> > > asking that it be reinstated.
> >
> > The last time I checked, the FC-MI spec was not a "standards track"
> > document
> > (to use IETF terminology). If that's still the case, is FC-MI's
> > prohibition
> > of class 1 a sufficient basis for precluding class 1 support in the
> > encapsulation spec?
> >
> > Charles
> > > -----Original Message-----
> > > From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> > > Sent: Saturday, November 10, 2001 8:52 AM
> > > To: IPS Reflector
> > > Cc: Black_David@emc.com
> > > Subject: Re: FCencap: List ALL SOF/EOF codes
> > >
> > >
> > > David's observation is correct. FC-MI rev 1.8 (28 Sept 2001)
> > > prohibits Class 1 and I can find no letter ballot comments
> > > asking that it be reinstated.
> > >
> > > Therefore, I am forced to agree with David. Class 1 MUST NOT
> > > be mentioned in the FC Encapsulation draft. If necessary, a
> > > note discussing interoperability and FC-MI can be added.
> > >
> > > Thanks.
> > >
> > > Ralph...
> > >
> > > Black_David@emc.com wrote:
> > >
> > > > FC-MI was going to prohibit Class 1 last time I 
> checked.  Since the
> > > > I in FC-MI stands for "Interoperability", this seems like a
> > > reasonable
> > > > rationale for excluding Class 1 service.
> > > >
> > > > --David
> > > > ---------------------------------------------------
> > > > David L. Black, Senior Technologist
> > > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > > ---------------------------------------------------
> > >
>