Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking

<mohamed.boucadair@orange.com> Fri, 24 August 2012 15:47 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 BC27E21F86C5 for <pcp@ietfa.amsl.com>; Fri, 24 Aug 2012 08:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.376
X-Spam-Level:
X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA1oe4HWyTqJ for <pcp@ietfa.amsl.com>; Fri, 24 Aug 2012 08:47:29 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 73EAA21F8710 for <pcp@ietf.org>; Fri, 24 Aug 2012 08:47:28 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9539F26475A; Fri, 24 Aug 2012 17:47:27 +0200 (CEST)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5BF0927C054; Fri, 24 Aug 2012 17:47:27 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 24 Aug 2012 17:47:05 +0200
From: <mohamed.boucadair@orange.com>
To: Xiaohong Deng <dxhbupt@gmail.com>
Date: Fri, 24 Aug 2012 17:47:03 +0200
Thread-Topic: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking
Thread-Index: Ac2B9o9t5rxM1IRtQqaV2bqKwDuD9QAGRI+w
Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AAF7@PUEXCB1B.nanterre.francetelecom.fr>
References: <CANb4OckhpkQH_Wkqyb1T6uuAO8ugLWZHHb_8L69DVe3bP8kUmQ@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36E4FC2DA35@PUEXCB1B.nanterre.francetelecom.fr> <CANb4OckhX8xWNKiFa8Dbi60Cdy-zjLaicDH8Z-yvgy3KbE_aSQ@mail.gmail.com> <CANb4OcnrE7Ntr6a1SiZskO=GfxkuY4DfD7etT2pAnMY6kXOPfQ@mail.gmail.com> <94C682931C08B048B7A8645303FDC9F36E512B4463@PUEXCB1B.nanterre.francetelecom.fr> <CANb4Ock8XLCxm8vFt-6g-v6Bk_X5TNiaPhw32SUV9VH9FcfL3A@mail.gmail.com>
In-Reply-To: <CANb4Ock8XLCxm8vFt-6g-v6Bk_X5TNiaPhw32SUV9VH9FcfL3A@mail.gmail.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5332AAF7PUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.150316
Cc: "pcp@ietf.org" <pcp@ietf.org>, "draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org" <draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org>
Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking
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: Fri, 24 Aug 2012 15:47:29 -0000

Hi Xiaohong,

Ok, done.

Thank you for the review.

Cheers,
Med

________________________________
De : Xiaohong Deng [mailto:dxhbupt@gmail.com]
Envoyé : vendredi 24 août 2012 14:47
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org
Objet : Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking

Hi Med,

I prefer the wording in your explanation:

only "1" is allowed: i.e., the iwf is supposed to send back an error if not set to 0.

Cheers,
Xiaohong

On Fri, Aug 17, 2012 at 4:15 PM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Xiaohong,

The current text says only "1" is allowed: i.e., the iwf is supposed to send back an error if not set to 0.

If you have a better wording, this is welcome.

Cheers,
Med

________________________________
De : Xiaohong Deng [mailto:dxhbupt@gmail.com<mailto:dxhbupt@gmail.com>]
Envoyé : vendredi 17 août 2012 15:50
À : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org<mailto:draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org>; pcp@ietf.org<mailto:pcp@ietf.org>; BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking

Hi Med,

Thanks for your efficient feedback.

Please see inline. Now focus only on unsolved ones.

On Thu, Aug 16, 2012 at 10:24 AM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
   PortMappingEnabled:
      PCP does not support deactivating the dynamic NAT mapping since
      the initial goal of PCP is to ease the traversal of Carrier Grade
      NAT.  Supporting such per-subscriber function may overload the
      Carrier Grade NAT.
+ What if the customer wants to deactivate a static NAT mappings on CGN? it is not stated clearly that IWF should support it or not. My reading here is that for the same reason: not to overload the carrier Grade NAT, it should not support deactivate static mappings either. IMO,it's worth to state clearer that it applys to both static and dynamic mappings, if that is what text here means.
[Med] IGD spec says "PortMappingEnabled: This variable allows security conscious users to disable and enable dynamic NAT port mappings on the IGD.". PCP does not provide such feature.

Je sais. That's why I asked, and please see below .



      On reading the value is 1, writing a value different from 1 is not
      supported.
+ what if on reading the value is 0, which means deactivating the mapping?
[Med] see above. Only "1" is supported.
Here, I elaborate the question again.

Quotation from UPnP-gw-WANIPConnection-v2-Service spcification:

"Arguments for AddPortMapping() and AddAnyPortMapping() :

*Argument                       Direction           relatedStateVariable*
...
NewEnabled                   IN                      PortMappingEnabled
..."

My concern was and is: with the current text, it doesn't look clear to me, how IGD should react when recieve a PortMappingEnabled valule of '0' from these two actions, which means that users want to disable the mapping.


"Arguments for GetGenericPortMappingEntry() GetGenericPortMappingEntry()
*Argument                       Direction           relatedStateVariable*
...
 NewEnabled                   OUT                  PortMappingEnabled
..."

Don't see any problems for IGD with actions  (Get*) having this parameter for OUT direction.



[Med] Are you sure 718 error code is allowed for GetSpecificPortMappingEntry?
Good point. According to specification, no.
p.s. But I think anyway it would be interesting to do a test to see what will happen in that case. Come back to you soon later with the test results.

Cheers,
Xiaohong