Re: [pcp] pcp-base-19

Sent from my iPad

On Dec 21, 2011, at 2:56 PM, "Dan Wing" <dwing@cisco.com<mailto:dwing@cisco.com>> wrote:

-----Original Message-----
From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]
Sent: Wednesday, December 21, 2011 10:19 AM
To: Dan Wing
Cc: <mailto:pcp@ietf.org> pcp@ietf.org<mailto:pcp@ietf.org>
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>
Will get back to u after my current meeting.

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?
The existing text disallows client to request same external IP proactively. You agreed my comments earlier before.

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.
If there are tools to find this kind of nits, our work would be easier.

-d

Happy holidays,
Tina

-----Original Message-----
From: pcp-bounces@ietf.org<mailto:pcp-bounces@ietf.org> [mailto:pcp-bounces@ietf.org] 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
pcp@ietf.org<mailto:pcp@ietf.org>
https://www.ietf.org/mailman/listinfo/pcp