Skip to main content

Early Review of draft-ietf-masque-ip-proxy-reqs-02

Request Review of draft-ietf-masque-ip-proxy-reqs
Requested revision No specific revision (document currently at 03)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2021-06-11
Requested 2021-05-17
Requested by Christopher A. Wood
Authors Alex Chernyakhovsky , Dallas McCall , David Schinazi
I-D last updated 2021-06-14
Completed reviews Secdir Early review of -02 by Loganaden Velvindron (diff)
Genart Early review of -02 by Robert Sparks (diff)
Intdir Early review of -02 by Bob Hinden (diff)
Rtgdir Early review of -02 by John Drake (diff)
Tsvart Early review of -02 by Kyle Rose (diff)
We're requesting early review of a Working Group Supporting Document to improve quality. This document is not meant to be published as an RFC, but we'd like to ensure as wide of a review as possible.
Assignment Reviewer Bob Hinden
State Completed
Request Early review on draft-ietf-masque-ip-proxy-reqs by Internet Area Directorate Assigned
Posted at
Reviewed revision 02 (document currently at 03)
Result Not ready
Completed 2021-06-14
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

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

6. Security Considerations

Surely there are Security requirements for a Proxy IP solution.  They need to be
described here.