On 2/21/14, 4:32 AM, Jari Arkko wrote: > Hi, > > First: I cleared my discuss, so this document's progress is now up to you > guys and Joel. Some further discussion inline:
related to this, I'd like one more pass through the source document before we send it to the rfc editor. if you can drop me a copy after you cleared the genart comments but before we post it that would be appreciated. >> 4-02-21 0:56 GMT+08:00, Jari Arkko <[email protected]>: >>> FWIW, I have now done my own review. I think there are language issues, but >>> they do not prevent going forward. Language itself will be fixed by the RFC >>> Editor. I'm more interested in cases where there might be an semantics >>> unclarity issue. >>> >>> I think it would be beneficial to go through each of the comments before >>> final approval of the document. >>> >>> With that in mind, going through some of my own and Elwyn's comments: >>> >>>> o Operators who adopt NAT64-FE may leverage the application layer >>>> proxies, e.g. X-Forwarded-For (XFF) >>>> [ >>>> I-D.ietf-appsawg-http-forwarded >>>> ], to convey the IPv6 source >>>> address in HTTP headers. >>> >>> I'd say ... may leverage application layer proxies, and those may use >>> additional attributes such as X-Forwarded-For ... >> >>> >>>> Those messages would be passed on to >>>> web-servers. The log parsing tools are required to be able to >>>> support IPv6 and may lookup Radius servers for the target >>>> subscribers based on IPv6 addresses included in XFF HTTP headers. >>>> XFF is the de facto standard which has been integrated in most >>>> Load Balancers. Therefore, it may be superior to use in a NAT-FE >>>> environment. In the downsides, XFF is specific to HTTP. It >>>> restricts the usages so that the solution can't be applied to >>>> requests made over HTTPs. This makes geo-location problematic for >>>> HTTPs based services. >>>> >>> >>> Not sure we should call something a de facto standard while pointing to a >>> draft. I'd just say "... has been implemented in many ..." >> >> thank you for the suggestion. We will make following changes: >> >> ==NEW >> >> o Operators who adopt NAT64-FE may leverage the application layer >> proxies. Those may use additional attributes such as X-Forwarded-For >> (XFF) >> [I-D.ietf-appsawg-http-forwarded] to convey the IPv6 source >> address in HTTP headers. Those messages would be passed on to >> web-servers. The log parsing tools are required to be able to >> support IPv6 and may lookup Radius servers for the target >> subscribers based on IPv6 addresses included in XFF HTTP headers. >> XFF has been implemented in most Load Balancers. Therefore, >> it may be superior to use in a NAT-FE >> environment. In the downsides, XFF is specific to HTTP. It >> restricts the usages so that the solution can't be applied to >> requests made over HTTPs. This makes geo-location problematic for >> HTTPs based services. > > OK > >> >> >> >>>> The experiences of some >>>> applications are still align with [ >>>> RFC6586]. >>> >>> >>> Not sure what this means. >> >> Several applications don't work properly as described in the RFC6585. > > If you use that text, then it would be fine. > >> >>> >>> >>>> | SIP-VoIP |Fail, due to the lack of NAT64 traversal | >>>> >>> >>> Did you mean ALG? Not sure what this would mean otherwise. >> >> I mean ICE is recommended to be supported in order to avoid SIP-ALG. >> After the discussion with Dan Wing, resorting to SIP-ALG for >> supporting IPv4-IPv6 inter-working is not preferred. > > Ok. Please elaborate, because the text was unclear to the reader. > > Also, I think you should go through Elwyn's comments and see if you make > improvements. > > Jari > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
