Hi Elwyn, Yes, I do think that's reasonably obvious, e.g., as I'd expect a Gen-ART reviewer to flag that issue if it wasn't clear in a future specification ;-). In addition, the proposed text does not allow for possible future uses of the Res bits that do not involve adding data to the Private Data area.
Thanks, --David +++ Sent from BlackBerry +++ ----- Original Message ----- From: Elwyn Davies [mailto:[email protected]] Sent: Wednesday, December 28, 2011 08:16 PM To: Black, David Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: [Gen-art] Fwd: Russ Housley's Discuss on draft-ietf-storm-mpa-peer-connect-07:(with DISCUSS) Hi, David. I was thinking of adding to the note in s10 something like: If in future several of the "Res" field bits are in use, care must be taken to specify the layout of the private data area so that the correct data is associated with each option whichever combination of bits are set. However, I supose this is really motherhood and apple pie. I'll live with what is there at the moment if you feel this is just too obvious. Regards, Elwyn On Wed, 2011-12-28 at 10:44 -0500, [email protected] wrote: > Hi Elwyn, > > Thanks for following up on this. Regarding ordering of private data: > > > However, I think that the > > note added to the end of Section 10 regarding the addition of further > > 'not-so-private' data perhaps needs another sentence about ordering, as > > per my and David's comments. > > The text at the end of Section 10 is about possible future protocol > enhancements - > e.g., if one or more of the Res (currently reserved) bits in the MPA header > are > used to define future standard elements that are carried in the MPA "Private > Data" > field (as was done in this draft for enhanced connection establishment data. > I > would prefer to defer any specification of ordering of future data additions > to > the document that defines those additions. > > For the current mpa-peer-connect draft, I believe the private data ordering > requirements are covered and clear - the enhanced RDMA connection > establishment > data MUST come first. Section 6 covers the MPA/TCP case; > > Private Data: Unchanged from [RFC5044]. However, if the 'S' flag is > set, Private Data MUST begin with enhanced RDMA connection > establishment data (see Section 9). > > The 'S' flag is the presence/absence flag for enhanced RDMA connection > establishment data, If the 'S' flag is clear, there's no enhanced RDMA > connection establishment data, and hence no ordering concern. > > Section 7 covers the SCTP case (end of this paragraph): > > The Enhanced DDP stream session establishment follows the same rules > as the standard DDP stream session establishment as defined in > [RFC5043]. ULP-supplied Private Data MUST be included for Enhanced > DDP Stream Session Initiate, Enhanced DDP Stream Session Accept, and > Enhanced DDP Stream Session Reject messages, and MUST follow the > enhanced RDMA connection establishment data in the DDP Stream Session > Initiate and the Enhanced DDP Stream Session Accept messages. > > Aside from enhanced RDMA connection establishment data, the only other data > that can be carried as Private Data is "ULP-supplied Private Data". > > Thanks, > --David > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Elwyn Davies > > Sent: Wednesday, December 28, 2011 9:11 AM > > To: Russ Housley > > Cc: [email protected]; General Area > > Review Team > > Subject: Re: [Gen-art] Fwd: Russ Housley's Discuss on > > draft-ietf-storm-mpa-peer-connect-07:(with > > DISCUSS) > > > > Hi, Russ. > > > > I hope you have had a good Christmas break. > > > > I responded to David Black's previous query about this on December 14 > > (see attached, copied to you at the time). However... > > > > I have just had a look at the -09 version provoked by David Harrington's > > comments. I think I may have been a little premature in signing off on > > that version as the RTR frame discussion did still need improvement. > > Verion -09 definitely fixes that issue IMO. However, I think that the > > note added to the end of Section 10 regarding the addition of further > > 'not-so-private' data perhaps needs another sentence about ordering, as > > per my and David's comments. > > > > Apart from that, I believe we are all done here - I have also reviewed > > the IANA registries draft in the last couple of days. > > > > Best wishes for the New Year. > > > > Regards, > > Elwyn > > > > On Fri, 2011-12-23 at 13:17 -0500, Russ Housley wrote: > > > Elwyn: > > > > > > > > > Have your concerns been addressed. > > > > > > > > > Russ > > > > > > = = = = = = = = > > > > > > Discuss (2011-09-30) > > > > > > The Gen-ART Review by Elwyn Davies on 26-Sept-2011 raises some > > > concerns that deserve a response. Please find the review at > > > http://www.ietf.org/mail-archive/web/gen-art/current/msg06754.html. > > > > > > > > > > > > Begin forwarded message: > > > > > > > From: "David Harrington" <[email protected]> > > > > > > > > Date: December 22, 2011 7:12:31 PM EST > > > > > > > > To: "'Russ Housley'" <[email protected]> > > > > > > > > Subject: RE: Russ Housley's Discuss on > > > > draft-ietf-storm-mpa-peer-connect-07:(with DISCUSS) > > > > > > > > > > > > Hi Russ, > > > > > > > > Can you check your DISCUSS on draft-ietf-storm-mpa-peer-connect? > > > > I believe we have addressed all of Elwyn's concerns. > > > > http://www.ietf.org/mail-archive/web/gen-art/current/msg06754.html. > > > > > > > > Thanks, and have a Merry Christmas! > > > > David Harrington > > > > Director, IETF Transport Area > > > > [email protected] (preferred for ietf) > > > > [email protected] > > > > +1 603 828 1401 (cell) > > > > > > > > > > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
