Re: [pcp] Capability discovery

[Yoshihiro Ohba <[e-mail]>]

OK.  Then how about the following approches?

- For PANA encapsulation approach, we use what Dan mentioned, i.e., the client
simply try to use the extension and get an error from the server not supporing
the extension.

- For PANA side-by-side approach:

    The PCP client supporting PCP authentication MAY send an unauthenticated
    ANNOUNCE request prior to initiating PANA in order to know whether a PCP
    server supports PCP authentication.  A PCP server supporting PCP
    authentication SHALL return an unauthenticated ANNOUNCE response with
    (new) "AUTHENTICATION_REQUIRED" result code.  A PCP server not supporting
    PCP authentication SHALL return an unauthenticated ANNOUNCE response
    with "SUCCESS" result code.

Regards,
Yoshihiro Ohba


(2012/10/06 2:42), Dave Thaler wrote:
> Yoshihiro Ohba writes:
>> (2012/10/05 22:56), Dan Wing wrote:
>>>> -----Original Message-----
>>>> From:[e-mail]  [mailto:[e-mail]] On Behalf Of
>>>> Yoshihiro Ohba
>>>> Sent: Thursday, October 04, 2012 8:04 PM To:[e-mail]
>>>> Subject: [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.
>>> Yes, that problem needs to be solved.
>>>
>>>> The same issue will exist for future PCP extensions.
>>> I disagree that problem exists for PCP extensions.  The client can
>>> simply try to use the extension, and will either get back an error
>>> (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will
>>> not be included in the response (for options outside the mandatory-
>>> to-process range).
>> In that case, the problem is specific to side-by-side PANA approach
>> which does not use PCP opcode/options.  Is this correct?
> Yes, I believe that's correct.
>
> -Dave
>
>
>