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

Hi Mohamed,

Am 09.07.15 um 14:20 schrieb mohamed.boucadair@orange.com:
> 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."

This text is fixing my issue here.

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

jep, that works.

Thanks,

   Martin

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