Subject: [pcp] clarification request about option processing

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Oct 2011 22:16:48 +0200

In the draft 14 it seems options are copied from the request to
the response without the possible omission from draft 13?
Is my interpretation correct?

If it is the case I have two comments:
 - it makes the processing of options far simpler as there is
  no longer a need for optional copy or squeeze of options in response
 - unfortunately it makes also easier to build a request which
  leads to an oversized response (i.e., more than 1024 byte long)

Regards

[email-masked]

PS: i do *not* request a change for version 15 here, I am only trying
to understand the 13 vs 14 changes...

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 12:50:15 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Tuesday, October 11, 2011 1:17 PM
> To: [email-masked]
> Subject: [pcp] clarification request about option processing
> 

I don't see significant changes between the section titled
"General PCP Option" in -13 (which was Section 6.7) and
in -14 (which is Section 7.7), 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-14.txt

Sorry, I do not understand that sentence in general, and especially 
do not understand the phrase "without the possible omission from 
draft 13".

So, please provide a specific pointer.

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

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

In your previous mail you wrote:

=> in 13 but not in 14:

   The response MUST encode the Options in the same order,
   but MAY omit some PCP Options in the response, to indicate the PCP
       ^^^^^^^^
   server does not understand that Option or that Option is not
   permitted to be included in responses by the definition of the Option
   itself.

so I interpret the 14 into the options are copied from the request
to the response, in fact the only difference after the opcode is
the response can get an UNPROCESSED option at the end of options.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 14:50:16 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2011 1:42 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] clarification request about option processing
> 
> 

Right.  

If this causes heartburn related to the PCP maximum message size
for a response, suggestions for how to better deal with this 
are appreciated.

The "MAY omit" was giving too much wiggle room.

-d

---

From: Tina TSOU <[email-masked]>
Date: Wed, 12 Oct 2011 22:18:48 +0000

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
http://www.huawei.com/en/solutions/expand-broadband/hw-092950-ipv6.htm

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Wednesday, October 12, 2011 1:42 PM
To: Dan Wing
Cc: [email-masked]
Subject: Re: [pcp] clarification request about option processing

   
=> in 13 but not in 14:

Regards

---

From: Tina TSOU <[email-masked]>
Date: Wed, 12 Oct 2011 22:24:12 +0000

Sorry by mistyping in Chinese.
Francis and I interoped in Quebec meeting based on -12.
-13 changed a lot from -12, so I'm not able to interop with Gabor easily, even with one version difference.

Francis' here interpretation makes sense.

Best Regards,
Tina TSOU

-----Original Message-----
From: Tina TSOU 
Sent: Wednesday, October 12, 2011 3:19 PM
To: 'Francis Dupont'; Dan Wing
Cc: [email-masked]
Subject: 看看咱们的实现是不是Francis说的那样//RE: [pcp] clarification request about option processing

Best Regards,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Wednesday, October 12, 2011 1:42 PM
To: Dan Wing
Cc: [email-masked]
Subject: Re: [pcp] clarification request about option processing

   
=> in 13 but not in 14:

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Oct 2011 01:09:18 +0200

Right.  
   
=> fine, it should make the option post-parsing far simpler.

=> IMHO the simplest is to require requests to have enough room for a
possible UNPROCESSED option in response for all the option codes which
occur, and if the PCP server finds there is not enough room it MAY
reject a request with MALFORMED_REQUEST (the idea behind the MAY is to
allow proactive or reactive check, i.e., to check all requests for
the room or to check only requests with unprocessed options).
BTW this should be extended to any options which can be appended
to response, i.e., it is the responsability of the client to provide
enough rooms at the end of requests to keep response length <= 1024.
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Oct 2011 17:30:13 -0700

> Sent: Wednesday, October 12, 2011 4:09 PM
> To: Dan Wing
> Cc: [email-masked]

Ok, so I am adding:

   If a PCP response would have
   exceeded the maximum PCP message size, the PCP server MAY
   respond with MALFORMED_REQUEST.</t>

> enough rooms at the end of requests to keep response length <= 1024.

Ok, so I am adding:

  It is the responsibility of the
  PCP client to ensure the server has sufficient room to reply
  with an error including UNPROCESSED Options; this can be achieved
  by sending messages that don't exceed 1024-4*number_of_options
  octets.

-d