Hi Suresh, On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishnan < [email protected]> wrote:
> Hi Behcet, > > On 02/12/2013 05:57 PM, Behcet Sarikaya wrote: > > Hi Suresh, > > > > On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan > > <[email protected] <mailto:[email protected]>> > wrote: > > > > Hi Brian, > > Thanks for the review. I wanted to clarify three points that you > > raised and I will ask the authors take care of the rest. > > > > On 02/11/2013 04:11 PM, Brian Haberman wrote: > > > 7. In Section 4.1.2, it would be good to describe any issues that > the > > > approach has with the original use of the Identification field for > > > fragmentation reassembly. If a middlebox changes the ID field, > weird > > > things can/will happen if those packets are fragmented somewhere. > > > > Agree. I think this is precisely the reason that the mechanism for > > putting the HOST_ID in the IP-ID is a non-starter. > > > > > 11. Is Section 4.6 theoretical or is there a specific reference > > that can > > > be added for this technique? > > > > There are several mechanisms that use port sets for IPv4 address > > sharing. A+P (RFC6346) is one such mechanism. > > > > Section 4.6 is not about about A+P. In A+P there is also the use of a > > shared public IPv4 address. > > Right. But section 4.6 is about assigning port sets and Brian asked if > that was any specific mechanisms that assigned port sets. A+P does so. > Not sure about what you mean by "In A+P there is also the use of a > shared public IPv4 address". This is the reason why we need a HOST_ID at > all. > > I think that this draft is not about A+P (don't ask me why, ask Med :-) ). The correct reference for Section 4.6 would be BBF document WT-146 on Subscriber Sessions Regards, Behcet > Thanks > Suresh > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
