[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.