Re: [pcp] Capability discovery

[<[e-mail]>]

Dear Yoshihiro,

FYI, this document proposes an option to retrieve the capabilities of the PCP-controlled device:
http://tools.ietf.org/html/draft-boucadair-pcp-capability-00

The current version does only describe whether the controlled device is NAT44, NAT46, NAT64, IPv4 FW, IPv6 FW, Port Range Router. 

This feature is defined as an option but can be elected to be defined as standalone OpCode. The capabilities set format can be modified to support new capabilities: e.g., authentication support, list of supported opcodes, etc. 

Saying that, IMHO we need further analyze what are the gains and the impacts on the PCP server to support such feature:

* Is it reducing exchanged messages? 
* Does it harm if we try an opcode no matter if the PCP server supports it or not?
* Reduce delay before establishing a session?
* Be a trigger to decide whether all available PCP Servers need to be contacted in // or select only one?


Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Yoshihiro Ohba
>Envoyé : vendredi 5 octobre 2012 05:04
>À : [e-mail]
>Objet : [pcp] Capability discovery
>
>There has been a question on what to do when PCP client supports PCP
>authentication
>while PCP server does not, and vise versa. The same issue will 
>exist for
>future PCP extensions.
>
>I would like to hear opinions whether defining a capability discovery
>exchange
>in PCP base specification ever makes sense, where the capability
>discovery exchange is
>expected to happen prior to any other PCP opcodes.
>
>Best Regards,
>Yoshihiro Ohba
>
>
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp
>