Re: [pcp] Ben Campbell's No Objection on draft-ietf-pcp-third-party-id-option-04: (with COMMENT)

[Juergen Quittek <[e-mail]>]

Dear Ben,

Thank you for the additional comments that you have made.
Please find replies inline.

> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Dienstag, 17. November 2015 23:53
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Ben Campbell's No Objection on draft-ietf-pcp-third-party-id-option-04:
> (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-pcp-third-party-id-option-04: 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-third-party-id-option/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Major Issues:
> ===========
> - I concur with Alissa and Joel's DISCUSS positions. I am balloting NO
> OBJECTION to avoid duplication; I will follow the conversations that
> result from those positions.
> 
> Minor Issues:
> ===========
> - The use cases seem to require the reader to make a leap of logic to
> figure out how the THIRD_PARTY_ID actually gets used in the
> routing/mapping of user packets. (This is related to Alissa's DISCUSS
> comment about the mapping being under specified.)

Yes, this would get solved by reducing the scope to tunnel IDs. 

> - Figure 2: is there an assumption that the L2 tunnel to the CGN NAT is
> the same as or correlated with that to the UPnP IGD?

No. they are uncorrelated.

> - 3.2: Is there an assumption the web application authenticates users? I
> assume so, since the web app needs to get the ID from somewhere.

Yes, there is this assumption. It is required for security reasons.

> - 4:
> Putting THIRD_PARTY_ID in the "mandatory-to-process" range seems to
> prevent use cases where the client sends the parameter "just in case". It
> might be worth having some text to say it should not be included unless
> the client knows for a fact the NAT cannot create a mapping without it.

This is a very good suggestion. We will come up with according text 
in the next revision of the draft.

> - 5.1:
> I don't think it makes sense to allow THIRD_PARTY_ID to be used
> independently of THIRD_PARTY, unless you define what it means to do so.

This is in line with Alissa's DISCUSS to restrict the scope. It assume this issue 
will be solved together with her DISCUSS.

> Editorial:
> ========
> - Please expand "BRAS" on first mention.

Will do.

Thanks and best regards,
    Juergen