Reviewer: Linda Dunbar Review result: Serious Issues Reviewer: Linda Dunbar Review result: Has Issues I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last-call comments. Summary: This document describes the method to encode IP packets with the HTTP frame. Issue-1: HTTP frame itself is carried by an IP packet. If a client needs to send data packets to its desired destinations (e.g., IP D, E, ) via the node that acts as the IP Proxy shown in Figure 14, it can be much easier accomplished by establishing an IP tunnel between the Client and the "IP Proxy Node (i.e., the tunnel between IP-A and IP-B). The IP layer can already achieve this goal natively. You don't need to put an IP packet inside an HTTP frame which is a payload to an IP packet. Issue-2: Address request capsule: In order for the Client HTTP frame to reach the Proxy node, they both already have the IP connection. What is the purpose of the Address request? Issue-3: Section 4.7.3 Route_advertisement Capsule: The widely deployed BGP can advertise the routes. You don't need another layer to repeat the work. Best Regards, Linda Dunbar -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
