Re: [pcp] WG Call for Adoption: draft-maglione-pcp-radius-ext-07

Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> Tue, 30 April 2013 10:30 UTC

Return-Path: <achatz@forthnetgroup.gr>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F02521F9BCA for <pcp@ietfa.amsl.com>; Tue, 30 Apr 2013 03:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej8JNqArrh9v for <pcp@ietfa.amsl.com>; Tue, 30 Apr 2013 03:30:21 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7662C21F9B10 for <pcp@ietf.org>; Tue, 30 Apr 2013 03:30:21 -0700 (PDT)
Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r3UAUHl9013481; Tue, 30 Apr 2013 13:30:17 +0300
Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id r3UAUG0D016763; Tue, 30 Apr 2013 13:30:16 +0300
Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r3UAUFTL016193; Tue, 30 Apr 2013 13:30:16 +0300
Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN)
Message-ID: <517F9D2A.5050601@forthnetgroup.gr>
Date: Tue, 30 Apr 2013 13:30:02 +0300
From: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Organization: Forthnet
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [pcp] WG Call for Adoption: draft-maglione-pcp-radius-ext-07
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 10:30:27 -0000

just had a quick look and i have a question:

If i understand correctly the packet format, you can't have a PCP server for IPv4 and a different PCP server for IPv6, unless the same DNS name is used; am i right?
Generally, how do you differentiate between v4 and v6 ones when the Dual-Stack context is used?
Is this left to the NAS to decide (based on what?) which one to pass to the co-located DHCPv4/v6 servers, or does the NAS pass everything to both DHCP servers?

...and some minor ones...
>    In such environment, PCP server's name can be configured on a RADIUS
>    server, which then passes the information to a NAS that co-locates
>    with the DHCPv4/DHCPv6 server, which in turn populates the location
>    of the PCP server.

Shouldn't this be the opposite? DHCP server that co-locates with the NAS.


> When the co-located DHCPv6 server receives a DHCPv6 message
>    containing the PCP Server Option, it SHALL use the name returned in
>    the RADIUS attribute as defined in this memo to populate the DHCPv6
>    PCP Server option defined in [I-D.ietf-pcp-dhcp <http://tools.ietf.org/html/draft-maglione-pcp-radius-ext-07#ref-I-D.ietf-pcp-dhcp>].

When the co-located DHCPv6 server receives a DHCPv6 message from a client containing the PCP Server Option...

> The scenario with PPP Session and IPv4 only connectivity does not
>    require DHCPv4: the whole configuration of the client is performed by
>    PPP.  This case is out of scope of this document because in order to
>    complete the configuration of the PCP client a new PPP IPC option
>    would be required.

...a new PPP IPCP option..

--
Tassos


Reinaldo Penno (repenno) wrote on 26/04/2013 17:12:
> Hello,
>
> This email starts a 2-week consensus call on adopting "RADIUS Extensions
> for Port Control Protocol (PCP)" as a WG item.
>
>      Title     : RADIUS Extensions for Port Control Protocol (PCP)
>      Author(s) : R. Maglione et al
>      Filename  : draft-maglione-pcp-radius-ext-07
>      URL       : 
> http://tools.ietf.org/html/draft-maglione-pcp-radius-ext-07
>
> Please read the current revision and state you opinion either for or
> against adoption (and with reasoning why) in the mailing list.
>
> The call for adoption ends 10th May 2013.
>
> Thanks,
>
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>