Hi Med, I realize that you published a revision with the A+P reference. However, I believe A+P is a problem for address sharing with its own solution, i.e. the port range is the host id.
I would favor removing Sec. 4.6. Anyway you have not been exhaustive on the solution space. Regards, Behcet On Thu, Feb 14, 2013 at 12:51 AM, <[email protected]> wrote: > ** > Hi Behcet, > > I'm aware of that context but the problem is that I don't have a good > reference to cite for it. > http://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would be a > good reference to cite but unfortunately the port set section was removed > in the last version > http://tools.ietf.org/html/draft-schott-fmc-requirements-04. > > Saying that, I really think having one example to cite is sufficient. No > need to have an exhaustive reference list. > > Thanks. > > Cheers, > Med > > ------------------------------ > *De :* Behcet Sarikaya [mailto:[email protected]] > *Envoyé :* mercredi 13 février 2013 20:09 > > *À :* BOUCADAIR Mohamed OLNC/OLN > *Cc :* Suresh Krishnan; Brian Haberman; > [email protected]; [email protected] > *Objet :* Re: [Int-area] AD evaluation: > draft-ietf-intarea-nat-reveal-analysis > > Hi Med, > > I think that email discussions we had on this issue in fmc list last year > will provide good context in these discussions, please remember them. > > See inline: > > On Wed, Feb 13, 2013 at 11:16 AM, <[email protected]> wrote: > >> ** >> Re-, >> >> Please see inline. >> >> Cheers, >> Med >> >> ------------------------------ >> *De :* Behcet Sarikaya [mailto:[email protected]] >> *Envoyé :* mercredi 13 février 2013 18:01 >> *À :* BOUCADAIR Mohamed OLNC/OLN >> *Cc :* Suresh Krishnan; Brian Haberman; >> [email protected]; [email protected] >> >> *Objet :* Re: [Int-area] AD evaluation: >> draft-ietf-intarea-nat-reveal-analysis >> >> Hi Med, >> >> On Wed, Feb 13, 2013 at 10:43 AM, <[email protected]> wrote: >> >>> ** >>> Hi Behcet, >>> >>> I have two comments: >>> >>> * Host identification issue is valid for any address sharing mechanism. >>> >> >> I am not sure on A+P? >> [Med] both A+P and NAT-based address sharing solutions are covered by >> rfc6269. host identifier is just a means to distinguish hosts under the >> same IP address. It does not matter how address sharing is implemented. >> >> A+P requires point-to-point link, right? >> >>> This is why the introduction mentions already the following: >>> >>> As reported in [RFC6269 <https://tools.ietf.org/html/rfc6269>], several >>> issues are encountered when an IP >>> address is shared among several subscribers. These issues are >>> encountered in various deployment contexts: e.g., Carrier Grade NAT >>> (CGN), application proxies or A+P [RFC6346 >>> <https://tools.ietf.org/html/rfc6346>]. >>> >>> * RFC6346 is provided as an example of a solution making use of port sets. >>> You are right, other solutions (than a+p) can be considered but having one >>> pointer to a solution example is just fair. No need to be exhaustive here. >>> >>> >> Again, I am not sure if Section 4.6 describes what A+P says? >> [Med] That section says non overlapping port sets are assigned to hosts >> sharing the same IP address. The text does not describe if the shared >> address is also configured to those hosts or if there is a NAT in the host, >> etc. These are implementation variants. There is no value to provide such >> details in that section. Adding a ref to A+P is just fair. This does not >> preclude other contexts. >> >> > If Section 4.6 applies to A+P, there is no need for such a text, just say > Use A+P and give the reference, right? > > Regards, > > Behcet > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
