Resend, this time with correct email address
> -----Original Message----- > From: Ronald Bonica > Sent: Wednesday, September 09, 2015 4:50 PM > To: 'Suresh Krishnan' <[email protected]>; [email protected] > Cc: [email protected] > Subject: RE: [Gen-art] Gen-ART review of draft-ietf-conex-tcp-modifications > > Suresh, > > You are absolutely right. We have two possible solutions, an HBH Option and > a Destination Option. Both solutions severely limit CONEX deployability. > > Since my comment is more about draft-ietf-conex-destopt than it is about > draft-ietf-conex-tcp-modifications, I think that we can let draft-ietf-conex- > tcp-modifications go forward, as is. > > Before draft-ietf-conex-tcp-modifications comes up for last call, we might > want to augment Section 5, explaining why both solutions limit severely limit > CONEX deployability. Since all of the CONEX documents are EXPERIMENTAL, > that caveat shouldn't be an impediment to publication. > > We will need to address the problem before the CONEX documents become > PROPOSED STANDARD. But we can cross that bridge when we get to it. > > > Ron > > > > > > -----Original Message----- > > From: Suresh Krishnan [mailto:[email protected]] > > Sent: Tuesday, September 08, 2015 2:47 PM > > To: Ronald Bonica <[email protected]>; [email protected] > > Cc: [email protected] > > Subject: Re: [Gen-art] Gen-ART review of > > draft-ietf-conex-tcp-modifications > > > > Hi Ron, > > Thanks for your review. Please find comments inline. > > > > On 09/08/2015 12:20 PM, Ronald Bonica wrote: > > > I am the assigned Gen-ART reviewer for this draft. For background on > > > Gen-ART, please see the FAQ at > > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> > > > > > > Document: > > > draft-ietf-conex-tcp-modifications-09 > > > Reviewer: Ron Bonica > > > Review Date: 2015-09-07 > > > IETF LC End Date: 2015-08-31 > > > IETF Telechat Date: 2015-10-01 > > > > > > Summary: This document will be ready for publication as soon as > > > the > > major issue (below) below is addressed. > > > > > > Major Issues: > > > > > > This document contains a normative reference to > > > draft-ietf-conex-destopt- > > 09. The normative reference is appropriate, because this document > > doesn't work at all unless the concepts described in > > draft-ietf-conex-destopt-09 work. > > > > > > I am concerned about draft-ietf-conex-destopt-09. It uses an IPv6 > > Destination Option to signal CONEX state to intermediate routers. > > However, according to RFC 2460: > > > > > > "With one exception, extension headers are not examined or > processed > > > by any node along a packet's delivery path, until the packet reaches > > > the node (or each of the set of nodes, in the case of multicast) > > > identified in the Destination Address field of the IPv6 header." > > > > > > The exception to which RFC 2460 refers is the Hop-by-hop Extension > > Header. Intermediate routers don't examine Destination Options. > > > > > > Section 5 of draft-ietf-conex-destopt-09 attempts to address this > > > issue, but > > I am not sure that the argument is acceptable. > > > > I think we can discuss this further but in my view there are no good > > solutions to this problem. There are two probable alternatives here > > > > Hop-by-hop options: This is arguably the right way to define > > information that is inspected on intermediate nodes. But using this > > implies that there is a huge performance penalty for conex packets > > that hit conex unaware routers (basically being punted into the slow > > path in the best case, being dropped at worst). RFC7045 section 2.2 > > talks about this explicitly but this problem has been known for much > longer. This will break requirement R-3. > > > > Destination options: Intended for the destination of the packet, but > > capable of being read at *consenting* conex-aware network nodes. Does > > not affect nodes that are conex unaware. This is no different than a > > router that looks at a TCP port for an enforcing an ACL, right? > > > > Let me know what you think. (Especially, we would be grateful if you > > think there is a better solution we ought to be considering that would > > meet the > > requirements) > > > > Regards > > Suresh > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
