Subject: [pcp] draft-ietf-pcp-base-15 posted

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Oct 2011 22:53:56 -0700

-15 has been posted, which should resolve all open issues.

Side-by-side diffs from -14 to -15,
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-15.txt

document:
http://tools.ietf.org/html/draft-ietf-pcp-base-15

B.1.  Changes from draft-ietf-pcp-base-14 to -15

   o  Softened and removed text that was normatively explaining how PEER
      is implemented within a NAT.

   o  Allow a MAP request for protocol=0, which means "all protocols".
      This can work for an IPv6 or IPv4 firewall.  Its use with a NAPT
      is undefined.

   o  combined SERVER_OVERLOADED and NO_RESOURCES into one error code,
      NO_RESOURCES.

   o  SCTP mappings have to use same internal and requested external
      ports, and have implied PREFER_FAILURE semantics.

   o  Re-instated ADDRESS_MISMATCH error, which only checks the client
      address (not its port).

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Oct 2011 10:53:53 +0200

In your previous mail you wrote:

=> we don't have the same definition of "all"...

Regards

[email-masked]

PS: the PROCESSING_ERROR is still at the head of my (far to
be empty :-) list of open issues.
PPS: BTW looking at the diff in section 8 in the figure 6 comments:
either plain -> Plain or Encapsulation -> encapsulation

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Oct 2011 08:08:07 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 20, 2011 1:54 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] draft-ietf-pcp-base-15 posted
> 
> 

I don't follow.  Please provide clearer feedback on the mistake
in that text.  RFC Editor's OLD / NEW syntax works well.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Oct 2011 23:33:27 +0200

> be empty :-) list of open issues.

=> get back (from base 12):

   6  PROCESSING_ERROR, server encountered an error after parsing while
      attempting to process a request.

(of course the important detail is the "after parsing")

   
=> replace:

   Dual-Stack Lite plain mode and (2) showing Dual-Stack Lite
   Encapsulation mode [I-D.dupont-pcp-dslite].  In a Dual-Stack Lite

by

   Dual-Stack Lite Plain mode and (2) showing Dual-Stack Lite
   Encapsulation mode [I-D.dupont-pcp-dslite].  In a Dual-Stack Lite
   
or

   Dual-Stack Lite plain mode and (2) showing Dual-Stack Lite
   encapsulation mode [I-D.dupont-pcp-dslite].  In a Dual-Stack Lite

(I prefer the second: I am French, not German :-).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Oct 2011 14:46:28 -0700

> Sent: Thursday, October 20, 2011 2:33 PM
> To: Dan Wing
> Cc: [email-masked]

The change log at
http://tools.ietf.org/html/draft-ietf-pcp-base-15#appendix-B.3
says it was removed because:

   o  removed PROCESSING_ERROR error, which was too similar to
      MALFORMED_REQUEST.

I don't know how to write the important detail to differentiate
between the two errors for the server or for what the client would
do.

> (I prefer the second: I am French, not German :-).

Oh, it's a nit about uppercase/lowercase.  Fixed.

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Oct 2011 12:32:42 +0200

The change log at

=> this argument is pretty wrong: MALFORMED_REQUEST is for error
in the parsing because the client sent something bad, PROCESSING_ERROR
is for error after the parsing because even the request is valid
for some reasons the server failed to process it.

=> for the server it is easy: just apply the "after parsing" vs
"during parsing" criterion. For the client it is less easy because
it just knows in the PROCESSING_ERROR error case something goes wrong
and it has no clear recovery way. But it is the case for any user
defined error too so the choice is to standardize this error or
to get all server implementations add it as an extended error
(i.e., code 128 & co). But we have already discuss this so
this has just to be addressed so this will be removed from the
open issue list.

Regards