[Int-dir] Intdir early review of draft-ietf-masque-ip-proxy-reqs-02
Bob Hinden via Datatracker <noreply@ietf.org> Sun, 13 June 2021 23:07 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A95543A13B5; Sun, 13 Jun 2021 16:07:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bob Hinden via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-masque-ip-proxy-reqs.all@ietf.org, masque@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.32.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162362562652.8324.1391395975676318672@ietfa.amsl.com>
Reply-To: Bob Hinden <bob.hinden@gmail.com>
Date: Sun, 13 Jun 2021 16:07:06 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/CWGFPidsUMW25J4hRDwbK1BE1T0>
Subject: [Int-dir] Intdir early review of draft-ietf-masque-ip-proxy-reqs-02
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2021 23:07:07 -0000
Reviewer: Bob Hinden Review result: Not Ready I'm reviewing the document as part of the Internet Directorate INTDIR). Note: I have not been following MASQUE, so I may be missing some context. 1.1 Conventions Is this necessary for an Informational Document that says it isn't going to be published as an RFC? 1.2 Definitions Suggest adding here (or to the Introduction that this will work with IPv6 and IPv4. 2.1 Consumer VPN Why "consumer VPN". Sounds like all VPN to me, and you don't describe any other type of VPNs. 2.2 Point to Point Connectivity This might be clearer if it's described in terms of two end-points, instead of two IP addresses. 2.3 Point to Network Connectivity How is this different from 2.1? 2.4 Network to Network Connectivity. If it is also called "a site to site VPN", suggest just calling it that. At a higher level, isn't this all just a VPN that runs over HTTP? 3.2 Proxying of IP Packets I didn't understand the part about extensions that may modify the packets. Wouldn't the break the basic idea? 3.4 IP assignment An IP range is usually described as a Prefix/length. Why not use this terminology like that is done in the next section. I am also not sure what the difference between this section and the next one. 3.6 Identity This needs work. I think you need to describe the requirements for an identifier, not just citing examples. I also don't like using email addresses, domains, or user name. 3.7 Transport Security s/run over a protocol/run over a transport/ 3.8 Flow control I didn't understand this. 3.9 Indistinguishability Perhaps call this "Privacy". 3.12 Statefulness This section doesn't say anything. If there are requirements, say what they are. 4.2 Reliable Tranmission of IP Packets IP Packets are not reliable. You can't change that. It's the transport protocols that create session reliability. I don't understand what this section is describing. 4.3 Configuration of Congestion and Flow Control Congestion and Flow Control mechanisms are very hard, and are part of transport protocols. I don't see how what is described here could work. 4.4 Data Transport Compression Suggest using an existing IP compression technique, do not invent another one. 6. Security Considerations Surely there are Security requirements for this. They need to be described here.
- [Int-dir] Intdir early review of draft-ietf-masqu… Bob Hinden via Datatracker