Subject: [pcp] UNPROCESSED with SUCCESS

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2011 17:07:07 +0200

In base 16 7.7.1 page 26, UNPROCESSED is defined with:

      May appear in: responses, and only if the result code is non-zero.

I'd like to relax this to handle a corner case: a MAP request with at least
a FILTER option which matches a static mapping. The meaning is the FILTERs
don't make sense (in particular the MAP request doesn't change them) so
they are unprocessed, but the request still returns a SUCCESS.

BTW there are other solutions but worse, for instance an UNSUPP_OPTION
which suggests the PCP server doesn't support FILTER, and is not a SUCCESS.

Regards

[email-masked]

PS: I've found inconsistencies in the "May appear in:"'s, my next
message is abound them.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 27 Oct 2011 17:08:25 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Wednesday, October 26, 2011 8:07 AM
> To: [email-masked]
> Subject: [pcp] UNPROCESSED with SUCCESS
> 

Let's back away from the protocol a little bit, and think about what problem
we're trying to solve.

If the PCP client sends a MAP request with a FILTER option, the PCP client
either:

  * thinks there is an existing mapping, and is trying to adjust its
    filtering
  * wants to create a new mapping with specific filtering

It seems that the desired behavior of the protocol depends on what
we assume the PCP client is most likely to do -- no?

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2011 17:09:38 +0200

=> as I explained it is a corner case...

   
=> in this case it should be the second because if the existence
of the static mapping is known the fact Web & co interface must
be used and not PCP is known too.

=> perhaps we should look at what the caller of the PCP client
is most likely to do next. We can say:
 - the existence of a matching static mapping is an error but
  we have no clear ways to encode this by an error response,
  so we fall in one of the other cases

 - the FILTER options are obviously not processed so could
  be marked as them in a success response

 - the static mapping response implies the FILTER options
  are not relevant, so just ignore them and returns the
  INT32_MAX success response
   
To implement the second we need to relax the UNPROCESSED spec,
to implement the last one we just need to agree it is the
best acceptable thing.

Regards