Subject: [imss] RE: AD review: draft-ietf-imss-ip-over-fibre-channel-02.txt

From: [email-masked]
Date: Thu, 20 Oct 2005 16:43:21 -0400

Bert,

I agree.  Please start the IETF Last Call now - running it for
3 weeks so that it ends around the end of the Vancouver meeting
week makes sense to me.  Let's plan a quick respin after IETF
Last Call to fix the "obsoletes" text and get the Acknowledgements
updated.

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
----------------------------------------------------

> -----Original Message-----
> From: Claudio DeSanti [mailto:[email-masked]] 
> Sent: Thursday, October 20, 2005 1:58 PM
> To: Wijnen, Bert (Bert)
> Cc: Black, David; Imss (E-mail); Brian Haberman (E-mail)
> Subject: Re: AD review: draft-ietf-imss-ip-over-fibre-channel-02.txt
> 
> Hi Bert,
> 
> I am perfectly fine in starting an IETF last call now and handling your 
> comments as last call comments. I would prefer to spin another revision, 
> if needed, after the last call rather than before.
>
> Thanks,
> 
>                                Claudio.
> 
> 
> Wijnen, Bert (Bert) wrote:
> > OK, making a last check before I issue/request IETF Last Call.
> > 
> > - I see (on front page):
> > 
> >     Category: Standards Track
> >     Replaces: RFC 2625, RFC 3831
> > 
> >   I guess you mean that it Obsoletes 2625 and 3831 ??
> >   I believe that "Obsoletes" is teh term that we use normally
> >   instead of "replaces"
> > 
> > - Acknowledgements
> >   You may want to acknowledge the authors/editors of RFC2625
> > 
> > You can (as far as I am concerned) consider the above as 
> initial IETF Last 
> > Call comments. If so, pls send me suggested updates for 
> "Notes to RFC-Editor"
> > for the acknowledgement section. For the first point I have:
> > 
> > Note to RFC Editor
> >  
> > - Front-page
> >   OLD:
> >      Replaces: RFC 2625, RFC 3831
> >   NEW:
> >      Obsoletes: RFC 2625, RFC 3831
> > 
> > - Page 3:
> >   OLD:
> >    This document replaces [RFC-2625].
> >   NEW:
> >    This document obsoletes [RFC-2625].
> >  
> >   OLD:
> >    transmitted on a Fibre Channel network.  This document replaces
> >    [RFC-3831].
> >   NEW:
> >    transmitted on a Fibre Channel network.  This document obsoletes
> >    [RFC-3831].
> > 
> > I can start an IETF Last Call now (unless you want to quickly spin
another 
> > rev). In any event, I would do a 3-week IETF Last Call to cater for the
> > busy time just before the IETF meeting.
> > 
> > David, Let me know how you want me to proceed.
> > 
> > Bert
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]]
> >>Sent: Wednesday, October 19, 2005 15:23
> >>To: [email-masked]; [email-masked]
> >>Cc: [email-masked]; [email-masked]
> >>Subject: RE: [imss] FW: INT Area Review:
> >>draft-ietf-imss-ip-over-fibre-cha nnel-01.txt
> >>
> >>
> >>Bert,
> >>
> >>These should be fine, we checked an earlier version of the
> >>changes with Brian, and they were ok by him - what's in the
> >>actual draft is not exactly what he reviewed, but the changes
> >>are consistent with what he reviewed, and should still be fine
> >>- double-checking doesn't hurt, though.
> >>
> >>Thanks,
> >>--David 
> >>
> >>
> >>>-----Original Message-----
> >>>From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> >>>Sent: Wednesday, October 19, 2005 8:12 AM
> >>>To: Brian Haberman (E-mail)
> >>>Cc: Claudio DeSanti; Black, David
> >>>Subject: RE: [imss] FW: INT Area Review: 
> >>>draft-ietf-imss-ip-over-fibre-cha nnel-01.txt
> >>>
> >>>Brian, here is some action based on your review.
> >>>Can youy check if that makes you happy?
> >>>
> >>>Claudio, pls do copy Brian explicitly when addrressing his
> >>>review/comments, because he is not on the imss mailing list.
> >>>
> >>>Thanks,
> >>>Bert
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [email-masked] 
> >>>
> >>>[mailto:[email-masked]]On Behalf Of
> >>>
> >>>>Claudio DeSanti
> >>>>Sent: Monday, October 17, 2005 18:54
> >>>>To: [email-masked]
> >>>>Cc: [email-masked]; [email-masked]
> >>>>Subject: Re: [imss] FW: INT Area Review:
> >>>>draft-ietf-imss-ip-over-fibre-channel-01.txt
> >>>>
> >>>>
> >>>>An updated I-D has been submitted. While the secretariat 
> >>>>processes it, 
> >>>>it may be accessed on the T11 web site by following this link:
> >>>>
> >>>>http://www.t11.org/t11/docreg.nsf/ufile/05-092v2
> >>>>
> >>>>The resolution of the Internet Area Expert Review 
> >>
> >>comments is also 
> >>
> >>>>available on the T11 web site:
> >>>>
> >>>>http://www.t11.org/t11/docreg.nsf/ufile/05-741v0
> >>>>
> >>>>Thanks,
> >>>>
> >>>>                          Claudio.
> >>>>
> >>>>
> >>>>[email-masked] wrote:
> >>>>
> >>>>>Internet Area Expert Review comments on the new IP over FC
> >>>>>draft are below.  Based on further conversation w/Brian, it's
> >>>>>ok not to update the references (Section 17 comment below) in
> >>>>>order to avoid getting caught in a REF (reference) hold at
> >>>>>the RFC Editor.  Many thanks to Brian for doing this review.
> >>>>>
> >>>>>The authors should prepare a -02 version of this draft
> >>>>>to address these comments (and update the boilerplate while
> >>>>>they're at it).  They should make sure it passes the ID nits
> >>>>>checker at: 
> >>>>>
> >>>>>http://tools.ietf.org/tools/idnits/idnits.pyht
> >>>>>
> >>>>>before submitting.
> >>>>>
> >>>>>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
> >>>>>----------------------------------------------------
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: Brian Haberman [mailto:[email-masked]] 
> >>>>>Sent: Wednesday, October 12, 2005 9:18 AM
> >>>>>To: Margaret Wasserman
> >>>>>Cc: Black, David; Bert Wijnen
> >>>>>Subject: Re: INT Area Review: 
> >>>>
> >>>>draft-ietf-imss-ip-over-fibre-channel-01.txt
> >>>>
> >>>>>Margaret & Bert,
> >>>>>      Here are my comments on this draft.  Overall, I think 
> >>>>
> >>>>it looks pretty
> >>>>
> >>>>>good.
> >>>>>
> >>>>>General Comments
> >>>>>--------------------------
> >>>>>
> >>>>>      - The document needs to be consistent in its 
> >>
> >>terminology on
> >>
> >>>>>         whether it is updating or obsoleting RFCs 2625 
> >>
> >>and 3831.
> >>
> >>>>>         The language in the Introduction seems to 
> >>
> >>contradict the
> >>
> >>>>>          information in the document header.
> >>>>>
> >>>>>Section 3
> >>>>>------------
> >>>>>
> >>>>>      - I would like to see some rationale/explanation for 
> >>>>
> >>>>the values
> >>>>
> >>>>>        1304 (in the fourth bullet) and 1024 (In the fifth 
> >>>>
> >>>>bullet).  How
> >>>>
> >>>>>        are those values derived and how are they related?
> >>>>>
> >>>>>Section 4.1
> >>>>>---------------
> >>>>>
> >>>>>      - The last paragraph allows more than one frame to 
> >>>
> >>>be included
> >>>
> >>>>>         in an IP FC Sequence.  It states that only the 
> >>>>
> >>>>first frame has an
> >>>>
> >>>>>         FC Network Header and LLC/SNAP Header.  I assume that
> >>>>>         means that all frames in the sequence must be the 
> >>>>
> >>>>same protocol.
> >>>>
> >>>>>         It would be nice if that was stated explicitly and 
> >>>>
> >>>>some reasoning
> >>>>
> >>>>>         given.
> >>>>>
> >>>>>Section 4.3
> >>>>>--------------
> >>>>>
> >>>>>      - Does routing traffic need to be mentioned in this list?
> >>>>>Specifically,
> >>>>>         how does routing traffic get handled?
> >>>>>
> >>>>>      - Can the exceptions to the SHOULD be spelled out?
> >>>>>
> >>>>>Section 4.8
> >>>>>--------------
> >>>>>
> >>>>>      - With an MTU of 65280 octets is Jumbogram support needed?
> >>>>>
> >>>>>Section 5.2
> >>>>>--------------
> >>>>>
> >>>>>      - There is an implication that the FC U/L bit has the 
> >>>>
> >>>>same semantics
> >>>>
> >>>>>         as the Ethernet U/L.  I believe that is true, but 
> >>>>
> >>>>it would help if
> >>>>
> >>>>>it were
> >>>>>         mentioned.
> >>>>>
> >>>>>      - I don't see the benefit of having both figures 9 & 10.
> >>>>>
> >>>>>Section 5.3
> >>>>>---------------
> >>>>>
> >>>>>      - I don't see the benefit of having both figures 12 & 13.
> >>>>>
> >>>>>      - The last sentence contains an example interface ID of
> >>>>>         3463:462A:BCDE:F789.  I don't see where the x789
> >>>>>         portion comes from?  Is it just an example?  It may be
> >>>>>         clearer to replace those with 'xxx'.
> >>>>>
> >>>>>Section 7
> >>>>>------------
> >>>>>
> >>>>>      - The discussion of ARP opcodes should probably 
> >>>
> >>>reference the
> >>>
> >>>>>         [ARP] spec.
> >>>>>
> >>>>>Section 9.3
> >>>>>--------------
> >>>>>
> >>>>>      - (bullet 4) Should the responder cache info from the 
> >>>>
> >>>>Request packet?
> >>>>
> >>>>>Section 17
> >>>>>-------------
> >>>>>
> >>>>>      - The references to [AARCH], [ACONF], [DISC], and 
> >>>>
> >>>>[ICMPv6] should
> >>>>
> >>>>>         probably be updated to the latest versions that 
> >>>>
> >>>>are done or nearly
> >>>>
> >>>>>         done within the IPv6 WG.
> >>>>>
> >>>>>Regards,
> >>>>>Brian
> >>>>>
> >>>>>_______________________________________________
> >>>>>imss mailing list
> >>>>>[email-masked]
> >>>>>https://www1.ietf.org/mailman/listinfo/imss
> >>>>>
> >>>>
> >>>>_______________________________________________
> >>>>imss mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/imss
> >>>>
> >>>
> > 
> 

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