Re: [pcp] Comments on draft-boucadair-pcp-nat-reveal

[<[e-mail]>]

Hi Dave,

This is not about a monitoring function but about real-time control signaling to help a decision-making entity to make appropriate decisions on the policy to be enforced for a new session. The correlation between the internal and external information is maintained by the NAT/PCP server. IMHO, it is much more simpler to package this new feature with an existing PCP server which interacts with the active NAT mapping table.

The proposed PCP optional extension is really simple. We have a working implementation of the QUERY opcode that showed us this is really trivial to support.

MIBs are here from a while but this didn't prevented the emergence of alternative promising approaches (think about SPPI, PIB, YANG, etc.). Deciding which approach is better for a given context is deployment-specific. Note that access to management interfaces is restricted to the management purposes. Relaxing that restriction may not be an option for some.

BTW, if your reasoning was applied to SET method, then PCP wouldn't be specified at all!

Cheers,
Med


De : [e-mail] [mailto:[e-mail]] De la part de Dave Thaler
Envoyé : mardi 30 juillet 2013 18:24
À : [e-mail]
Objet : [pcp] Comments on draft-boucadair-pcp-nat-reveal

<personal opinion, no hats>

I read this document, but I don't agree that using PCP is the appropriate way to solve this problem.
The problem described can and should be solved using the existing NAT MIB document in
the Behave WG.

More generally, any scenario requiring querying (but not changing) NAT state by an
authorized entity administered by the same organization is really a management/monitoring
function and should be done by the NAT MIB not by extensions to PCP.

We don't need multiple ways to do the same thing.

-Dave