Re: [pcp] pcp-base-19

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Tina TSOU [mailto:[e-mail]]
> Sent: Wednesday, December 21, 2011 10:19 AM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: [pcp] pcp-base-19
> 
> Hi all,
> Some comments on pcp-base-19:
> 
> 1. P17, section 6.3 / P18, section 6.4
> "If the PCP server does not implement this Option, ..."
> "UNSUPP_OPTION: Unsupported Option.  This error only occurs if the
> Option is in the mandatory-to-process range."
> 
> Why do we set this restriction "only occurs if the Option is in the
> mandatory-to-process range."?
> I think UNSUPP_OPTION error code is better than MALFORMED_OPTION if
> there is an unsupported optional Option.

Unsupported optional Options don't cause errors to be generated;
they are simply ignored (as if not present in the request) and the 
PCP response won't contain those Options (as if not present in the 
request)

The full text is:

   The most significant bit in the Option Code indicates if its
   processing is optional or mandatory.  If the most significant bit is
   set, handling this Option is optional, and a PCP server MAY process
   or ignore this Option, entirely at its discretion.  If the most
   significant bit is clear, handling this Option is mandatory, and a
   PCP server MUST process this Option or return an error code if it
   cannot.  If the PCP server does not implement this Option, or cannot
   perform the function indicated by this Option (e.g., due to a parsing
   error with the Option), it MUST generate an error response with code
   UNSUPP_OPTION or MALFORMED_OPTION (as appropriate).

That last sentence is intended to only apply if the significant bit
is clear.  I agree that is not clear.  I will replace the paragraph above
with this new paragraph, which indicates any sort of parsing error
generates MALFORMED_OPTION, and indicates when options are included
in responses:


        <t>If an Option cannot successfully be parsed, the PCP server
        MUST generate an error response with code MALFORMED_OPTION.
        The most significant bit in the Option Code indicates if its
        processing is optional or mandatory.  If the most significant
        bit is set, handling this Option is optional, and a PCP server
        MAY process or ignore this Option, entirely at its discretion.
        If the most significant bit is clear, handling this Option is
        mandatory, and a PCP server MUST process this Option or return
        the error UNSUPP_OPTION if it cannot.  All processed options
        are returned in successful responses, and unprocessed options 
        are not included in successful responses.</t>


> 2. P28, section 9
> "It is REQUIRED that the PCP-controlled device assign the same
> external IP address to PCP-created explicit dynamic mappings and to
> implicit dynamic mappings for a given Internal Address. In the absence
> of a PCP option indicating otherwise, it is REQUIRED that all
> PCP-created explicit dynamic mappings be assigned the same external
> IP address."
> 
> How about replace "In the absence of a PCP option indicating otherwise,
> it is REQUIRED that all PCP-created explicit dynamic mappings be
> assigned the same external IP address."
> with
> "It is indicated by the PCP client that PCP-created explicit dynamic
> mappings be assigned the same external IP address, unless there are
> explicit reasons of not doing so, e.g.
> http://tools.ietf.org/html/draft-penno-pcp-zones-00"?
>
> Because "It is REQUIRED that the PCP" give the requirement from the
> server's point of view, I think we should also give the requirement
> from the client's point of view.
> This is more or less what Dan suggested before, perhaps an oversight.

I don't understand the nuance between the wording.  Can you give an
example of what the existing text prohibits / breaks / disallows?


> 3. P38, section 10.2
> "the PCP server may not be able grant the suggested External IP Address
> and Port"
> 
> typo? be able to?

Thanks, fixed.


> 4. P57, section 12.3
> "the value of the Prefix Length pertains only to to the IPv4 portion of
> the address."
> 
> typo, duplicate "to"

Thanks, fixed.


> 5. P59, section 13.1.1
> "In many networking APIs is is difficult or	impossible to have two
> independent clients listening for both unicasts and multicasts on the
> same port at the same time.  For this reason, two ports are used."
> 
> typo, duplicate "is"

Thanks, fixed to read "it is".


> 6. P61, section 13.1.4 Processing a PEER Response
> 
> the title "PEER Response",
> 
> guess it should be "ANNOUNCE"

Oops, thanks.  Fixed.


> "then for all PCP mappings it made at that server address the client
> should issue new PCP requests to to recreate any lost mapping state. "
> 
> typo, duplicate "to"

Thanks, fixed.

-d

> 
> 
> Happy holidays,
> Tina
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Dan Wing
> Sent: Monday, December 19, 2011 5:21 PM
> To: 'PCP'
> Subject: [pcp] pcp-base-19
> 
> Major changes in -19 are summarized in the Changes section, and
> are:
> 
>    o  Described race condition with MAP containing PREFER_FAILURE and
>       Mapping Update.
> 
>    o  Added state machine (Section 14.5).
> 
>    o  Fully integrated Rapid Recovery, with a separate Opcode having
> its
>       own processing description.
> 
>    o  Clarified that due to Mapping Update, a single MAP or PEER
> request
>       can receive multiple responses, each updating the previous
>       request, and that the PCP client needs to handle MAP updates or
>       PEER updates accordingly.
> 
> Side-by-side diffs,
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-19.txt
> 
> -d
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp