Re: [pcp] Martin Stiemerling's No Objection on draft-ietf-pcp-proxy-08: (with COMMENT)

Hi Martin,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : pcp [mailto:pcp-bounces@ietf.org] De la part de Martin Stiemerling
> Envoyé : jeudi 9 juillet 2015 10:56
> À : The IESG
> Cc : pcp@ietf.org
> Objet : [pcp] Martin Stiemerling's No Objection on draft-ietf-pcp-proxy-
> 08: (with COMMENT)
> 
> Martin Stiemerling has entered the following ballot position for
> draft-ietf-pcp-proxy-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have these comments and questions:
> 
> 1) There is no clear definition of what a PCP proxy really is.

[Med] There is a concise definition in Section 1: 

" the PCP proxy is logically equivalent
   to a PCP client back-to-back with a PCP server.  The "glue" between
   the two is what is specified in this document."

If you think this is not sufficient, what about adding this NEW text:

   "The PCP Proxy is responsible for relaying PCP messages received from
   PCP clients to upstream PCP servers and vice versa.

   Whether the PCP Proxy is co-located with a flow-aware function (e.g.,
   NAT, firewall) is deployment-specific."

 Section 1.
> shows it as a pure signalling entity only w/o any NAT functionality (no
> mapping functionality)

[Med] Only PCP functional elements are shown in Figure 1 because there is no assumption about the colocation of the PCP Proxy with a function it may control. Section 1.1 is an example of a PCP Proxy that is collocated with a NAT, while Section 1.2 is about a PCP proxy which does not interact with a PCP-controlled function. 

 but the document body itself talks about PCP
> proxies having a mapping table (and also the possibility of not --
> Section 3.4.1). Adding such a statement about the PCP proxy is or can be
> to the intro or the terminology section is a good thing.

[Med] There is always a mapping table maintained by the PCP proxy because this is a logical consequence of the PCP Proxy being defined as "a PCP client back-to-back with a PCP server". Section 3.4.1 is about the colocation with NAT, not about PCP mapping tables. 

> 
> 2) Section 3.1 talks about hairpinning:
> There is a potential noteable issue in terms of network management: If
> the PCP proxy is performing the hair pinning for the Assigned External
> Address, the byte counters on the PCP server and the proxy will differ
> for the Assigned External Address. This might be worth to note in a
> network managment section (or elsewhere in the document).
> 

[Med] What about this adding this NEW text: 

  "Note that traffic counters maintained by an upstream PCP server will
   differ from the ones of a PCP Proxy implementing the optimized
   hairpin routing."

> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp