Subject: [pcp] base #31 (new): Query-capability support?

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 14 Dec 2010 20:29:10 -0000

#31: Query-capability support?

 From http://www.ietf.org/mail-archive/web/pcp/current/msg00167.html

 Moreover, I'm in favour of having explicit OpCodes such as the
    following:
 [...]
    6.  PING/PING:
        A.  assess the availability of the PCP Server
        B.  Retrieve the capabilities of the PCP Server
        C.  Retrieve a set of useful data such as mappings count, etc.

-- 
--------------------------------------------------+-------------------------
 Reporter:  mohamed.boucadair@…                   |       Owner:     
     Type:  enhancement                           |      Status:  new
 Priority:  minor                                 |   Milestone:     
Component:  base                                  |     Version:     
 Severity:  Active WG Document                    |    Keywords:     
--------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/31>
pcp <http://tools.ietf.org/pcp/>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 13:05:05 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> pcp issue tracker
> Sent: Tuesday, December 14, 2010 12:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [pcp] base #31 (new): Query-capability support?
> 

Why does a PCP client need to know, unless it is attempting to do
real work (sending real opcodes) to the PCP server? 

>         B.  Retrieve the capabilities of the PCP Server

I believe we discussed this in an earlier thread, but to recap:

An IPv4-only PCP client will only want to use PIN44; it has no use
for learning capabilities.

A dual-stack PCP client will have a need to use PIN44 and PIN66.  It
takes two messages to try PIN44 and to try PIN66.  If we had a discovery
OpCode, it would take two messages (minimum, if PCP servers supports
only PIN44 or only PIN66) or would take three messages (if the PCP
server supports both PIN44 and a PIN66)

An IPv6-only PCP client will want to use PIN64 and PIN66.  Analysis
of number of messages is same as dual-stack PCP client.

>         C.  Retrieve a set of useful data such as mappings count, etc.

Mapping count would become inaccurate as soon as it's sent, except 
on a quiescent network.

Returning "port quota limit" could be useful, though.  But only for
diagnostic purposes for the user -- the protocol itself doesn't 
need it.  

Can (C) be described in a separate document?

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Dec 2010 23:10:01 +0100

In your previous mail you wrote:

=> I agree about dynamic mappings but not for objects created by PCP.
As I explained we need a GET operation to synchronize the state in
the 'state is on the PCP server' case and to get the number of entries
is the first step (the next one is to choose between GET_N and
GET+GET_NEXT, i.e., UPnP IGD vs. SNMP, IMHO the second is better
because it works even in dynamic contexts).

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 16:52:27 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 20, 2010 2:10 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] base #31 (new): Query-capability support?
> 
> 

There can be multiple PCP clients running on the same host, or on
several hosts in the same subscriber's network -- all of their
mappings counting against the subscriber's quota.

> is the first step 

But that breaks if there are more than one PCP clients.

> (the next one is to choose between GET_N and

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 11:06:26 +0100

=> I can't see an issue: count operations should get same scopes
than 'delete all' operations.

=> we already discussed about this: a per-application ID is needed
(at least for 'delete all' operations which can get a greater
scope then expected without this).

Chairs, can you get a new item about a per-application ID option?

Regards