[pcp] #76 (proxy): Dave Thaler's comments on draft-ietf-pcp-proxy-06

"pcp issue tracker" <trac@tools.ietf.org> Tue, 28 April 2015 21:36 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: pcp issue tracker <trac@tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: draft-ietf-pcp-proxy@tools.ietf.org, dthaler@microsoft.com
Date: Tue, 28 Apr 2015 21:36:13 -0000
Message-ID: <059.537358a39f79e82289de47eacc67bfba@tools.ietf.org>
Resent-To: draft-ietf-pcp-proxy@ietf.org
Resent-Message-Id: <20150428213613.846421A89F5@ietfa.amsl.com>
Resent-Date: Tue, 28 Apr 2015 14:36:13 -0700
Resent-From: trac@tools.ietf.org
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/xcLPrv3TCrZuo21RvVBkaaGtRgk>
Cc: pcp@ietf.org
Subject: [pcp] #76 (proxy): Dave Thaler's comments on draft-ietf-pcp-proxy-06

#76: Dave Thaler's comments on draft-ietf-pcp-proxy-06

 Section 1.1:
 > likely to be more than on NAT on the path between client machines and

 s/more than on/more than one/

 Section 1.2:
 Is it worth noting that the pcp-anycast draft is an alternate solution to
 this same use case?

 Section 3.2:
 This section's wording is a bit confusing.   Section 1 explained the
 reference
 model of back-to-back client and server.  So termination would occur when
 either
 a) the request gets to a server that does not have the PCP proxy
 functional element, or
 b) it gets to a PCP proxy whose PCP client has no PCP servers reachable
 (e.g. none configured and no default routers that respond to PCP) and thus
 has nothing to forward to.
 No?

 The two examples currently in 3.2 are merely ways a NAT gateway (but a PCP
 proxy could be a firewall or something other than a NAT...) could choose
 to enable or disable a PCP proxy functional element and hence
 toggle between a and b above.   But the PCP speaker might not be a NAT
 gateway, or it might not implement a PCP proxy at all, or it might
 implement one but not be "configured to know it's the outermost" but
 rather use rule b above.
 So I think section 3.2 needs further elaboration as noted above.

 Section 3.6:
 I think the reference to Zone ID [I-D.penno-pcp-zones] should probably
 reference the Third Party ID Option [I-D.ietf-pcp-third-party-id-option].

 Section 5:
 > Section 3.3 specifies the cases where a THIRD_PARTY option is inserted
 > the PCP Proxy.  In those cases, means to prevent a malicious

 s/inserted/inserted by/

 > THIRD_PARTY option MUST NOT be enabled unless the network on which

 Grammar: s/option/options/

 >   dropped (or in the case of an unknown Option which is not mandatory-
 >   to-process the Option be removed) if it is not compatible with

 s/Option be/Option SHOULD be/

-- 
-------------------------------------+-------------------------------------
 Reporter:  dthaler@microsoft.com    |      Owner:  draft-ietf-pcp-
     Type:  defect                   |  proxy@tools.ietf.org
 Priority:  minor                    |     Status:  new
Component:  proxy                    |  Milestone:  milestone1
 Severity:  Waiting for Shepherd     |    Version:  1.0
  Writeup                            |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/pcp/trac/ticket/76>
pcp <http://tools.ietf.org/pcp/>

[pcp] #76 (proxy): Dave Thaler's comments on draf… pcp issue tracker
Re: [pcp] #76 (proxy): Dave Thaler's comments on … mohamed.boucadair
Re: [pcp] #76 (proxy): Dave Thaler's comments on … Dave Thaler
Re: [pcp] #76 (proxy): Dave Thaler's comments on … pcp issue tracker