From yoshihiro.ohba@toshiba.co.jp Sun Jul 8 15:38:51 2012 Return-Path: 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 CCA3521F86B2 for ; Sun, 8 Jul 2012 15:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 nXver+r+XRv9 for ; Sun, 8 Jul 2012 15:38:51 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1521F86B1 for ; Sun, 8 Jul 2012 15:38:47 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q68Md8vG024423 for ; Mon, 9 Jul 2012 07:39:08 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q68Md8nJ013019 for pcp@ietf.org; Mon, 9 Jul 2012 07:39:08 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id HAA13018; Mon, 9 Jul 2012 07:39:08 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q68Md8ds005052 for ; Mon, 9 Jul 2012 07:39:08 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q68Md8h8019967; Mon, 9 Jul 2012 07:39:08 +0900 (JST) Received: from [133.196.20.84] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M6V00FAO5L7XH40@mail.po.toshiba.co.jp> for pcp@ietf.org; Mon, 09 Jul 2012 07:39:08 +0900 (JST) Date: Mon, 09 Jul 2012 07:39:16 +0900 From: Yoshihiro Ohba In-reply-to: <20120707050545.8688.284.idtracker@ietfa.amsl.com> To: pcp@ietf.org Message-id: <4FFA0C14.5040006@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit X-Forwarded-Message-Id: <20120707050545.8688.284.idtracker@ietfa.amsl.com> References: <20120707050545.8688.284.idtracker@ietfa.amsl.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 Subject: [pcp] draft-ohba-pcp-pana-00 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 22:38:51 -0000 The following draft that addresses separate key management for PCP message authentication: http://www.ietf.org/internet-drafts/draft-ohba-pcp-pana-00.txt Comments are appreciated. Best Regards, Yoshihiro Ohba From simon.perreault@viagenie.ca Tue Jul 10 12:36:23 2012 Return-Path: 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 723EE21F86C5; Tue, 10 Jul 2012 12:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 gPB+winjd+gD; Tue, 10 Jul 2012 12:36:22 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6341121F86C4; Tue, 10 Jul 2012 12:36:22 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1D294414B1; Tue, 10 Jul 2012 15:36:48 -0400 (EDT) Message-ID: <4FFC844F.3010207@viagenie.ca> Date: Tue, 10 Jul 2012 15:36:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [pcp] secdir review of draft-ietf-behave-lsn-requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:36:23 -0000 (adding pcp@ietf.org to the recipients list...) Sam, Thanks for the review, comments inline... On 07/10/2012 02:16 PM, Sam Hartman wrote: > Requirement 9 requires a Port Control Protocol (PCP) server. I think we > need to say somewhat more about that in order for PCP to be secure on a > CGN. In this > discussion I urge people to read section 17.1 (the simple thread model) > of draft-ietf-pcp-base. We want to be using the simple threat model > because there's no clear credential that CGN operators are guaranteed to > share with their customers. If we ask people to set up a credential and > configure an authentication mechanism to take advantage of the CGN's > PCP server, people will either ignore our recommendations or CGN PCP will > be useless. > > The cardinal rule of the simple threat model is do no harm: make sure > that PCP cannot be used in a manner that makes security worse than > implicit NAT mappings. The CGN situation is a bit more complex than the > typical simple threat model. I spent this morning going over the CGN > case with Margaret Wasserman and based on that discussion, I believe the > following additional requirements are sufficient to use the simple > threat model for CGNs. > > The PCP server MUST NOT permit the lifetime of a mapping to be reduced > beyond its current life, MUST NOT permit a NAT mapping to be created > with a lifetime less than the lifetime used for implicit mappings, MUST > not permit the delete opcode to be used, Unless I'm mistaken, there is no delete opcode in PCP. You just send a MAP request with lifetime=0. So I would propose saying: MUST NOT permit the lifetime of a mapping to be reduced beyond its current life or be set to zero (deleted) > and MUST NOT support the third-party option. I think pcp-base-26 added restrictions to THIRD_PARTY so that it could be used in CGN scenarios. If that is right, wouldn't it then make sense to allow THIRD_PARTY on CGNs? > The map opcode MAY be permitted if the > recommendation of endpoint independent filtering behavior described in > REQ-7 is adopted; the map opcode MUST NOT be permitted in other > circumstances. These constraints MAY be relaxed if a security mechanism > consistent with PCP's Advanced Threat Model (see Section 17.2 of > [I-D.ietf-pcp-base]) is used; this is expected to be rare for CGN > deployments. Mappings created by PCP MUST follow the same deallocation > behavion (REQ-8) as implicitly mapped traffic. > > justification: Most of the concern has to do with one customer device > interacting negatively with the security of another; this is of > particular concern when the devices belong to different customers, but > devices belonging to the same customer are in scope for the PCP security > analysis as well. Reducing a mapping lifetime or deleting a mapping > create DOS opportunities and can create an opportunity for one device to > intercept another device's traffic. If a device spoofs creation of a > mapping with less than the default lifetime, then that can create DOS or > packet capture opportunities. The third-party option creates significant > spoofing opportunities. The behavior of REQ-8 is critical to avoiding > packet capture attacks. Thanks for the full requirements text and justification. That going to make my editing just so much easier! > My second concern is with section 8. > This section says that spoofing is a concern of DOS, notes that ingress > filtering is a defense and makes no recommendation. > > I believe spoofing is a significantly greater concern than DOS. As an > example, I can spoof traffic from you to create an inbound hole towards > one of your ports. Is this a new attack vector introduced by CGN? Without NAT, there's no need for a "hole", anyone can send traffic to any of a subscriber's ports... Thanks, Simon > This is particularly valuable if the filtering > behavior is endpoint independent as recommended in REQ-7. Spoofing is > particularly dangerous with PCP if the constraints I listed above are > not followed. The analysis of the impact of spoofing is a bit tricky, > because it depends on how spoofing is accomplished and on whether an > attacker can observe traffic destined for other customers as well. So, I > think the warning about spoofing needs to be increased. > > I also think we need to make a specific recommendation that people > deploying CGNs deploy sufficient ingress filtering to avoid spoofing. I > understand this specification is mostly about building CGNs not about > deploying them. However this issue seems quite important to the security > of the network. -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hartmans@painless-security.com Tue Jul 10 13:03:31 2012 Return-Path: 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 B9FC411E80BB; Tue, 10 Jul 2012 13:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.301 X-Spam-Level: X-Spam-Status: No, score=-103.301 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 uC6L2XxaUAqr; Tue, 10 Jul 2012 13:03:31 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3A21F86B4; Tue, 10 Jul 2012 13:03:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F06E12043E; Tue, 10 Jul 2012 16:04:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A323441F0; Tue, 10 Jul 2012 16:03:50 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <4FFC844F.3010207@viagenie.ca> Date: Tue, 10 Jul 2012 16:03:50 -0400 In-Reply-To: <4FFC844F.3010207@viagenie.ca> (Simon Perreault's message of "Tue, 10 Jul 2012 15:36:47 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: secdir@ietf.org, pcp@ietf.org, Sam Hartman , draft-ietf-behave-lsn-requirements@tools.ietf.org, ietf@ietf.org Subject: Re: [pcp] secdir review of draft-ietf-behave-lsn-requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:03:32 -0000 >>>>> "Simon" == Simon Perreault writes: Simon> MUST NOT permit the lifetime of a mapping to be reduced beyond its Simon> current life or be set to zero (deleted) OK. >> and MUST NOT support the third-party option. Simon> I think pcp-base-26 added restrictions to THIRD_PARTY so that it could Simon> be used in CGN scenarios. If that is right, wouldn't it then make Simon> sense to allow THIRD_PARTY on CGNs? I don't think you can describe an subscriber-facing network of an ISP as "fully trusted." The text added to 13.1 might permit third_party to be used by an administrative web service within an ISP but certainly not by customers of that ISP. I'd be OK with "MUST NOT allow the third_party option for traffic recieved from customer-facing interfaces." or "MUST NOT allow the third_party option in requests received on the internal network." Then that still permits the case of third_party for administration motivating the text in 13.1. >> My second concern is with section 8. >> This section says that spoofing is a concern of DOS, notes that ingress >> filtering is a defense and makes no recommendation. >> >> I believe spoofing is a significantly greater concern than DOS. As an >> example, I can spoof traffic from you to create an inbound hole towards >> one of your ports. Simon> Is this a new attack vector introduced by CGN? Without NAT, there's no Simon> need for a "hole", anyone can send traffic to any of a subscriber's Simon> ports... I find it difficult to answer that question. I'd say that it is likely an unexpected assumption for someone behind a NAT. It is a vulnerability of CGNs over other NATs, but perhaps not a vulnerability of CGNs over no NAT or firewall at all. Why do we care whether it's new? Is it actually bad if we end up describing a related attack and recommending people deploy in a manner that avoids it? From simon.perreault@viagenie.ca Tue Jul 10 13:31:37 2012 Return-Path: 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 E25B211E80A6; Tue, 10 Jul 2012 13:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 L9vJf1KENulu; Tue, 10 Jul 2012 13:31:36 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 110F121F84D3; Tue, 10 Jul 2012 13:31:36 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1B35A44B4E; Tue, 10 Jul 2012 16:32:04 -0400 (EDT) Message-ID: <4FFC9143.40407@viagenie.ca> Date: Tue, 10 Jul 2012 16:32:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4FFC844F.3010207@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, pcp@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, ietf@ietf.org Subject: Re: [pcp] secdir review of draft-ietf-behave-lsn-requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:31:37 -0000 On 07/10/2012 04:03 PM, Sam Hartman wrote: > >> and MUST NOT support the third-party option. > > Simon> I think pcp-base-26 added restrictions to THIRD_PARTY so that it could > Simon> be used in CGN scenarios. If that is right, wouldn't it then make > Simon> sense to allow THIRD_PARTY on CGNs? > > I don't think you can describe an subscriber-facing network of an ISP as > "fully trusted." > The text added to 13.1 might permit third_party to be used by an > administrative web service within an ISP but certainly not by customers > of that ISP. > I'd be OK with "MUST NOT allow the third_party option for traffic > recieved from customer-facing interfaces." > or "MUST NOT allow the third_party option in requests received on the > internal network." > Then that still permits the case of third_party for administration > motivating the text in 13.1. Makes sense to me. > >> My second concern is with section 8. > >> This section says that spoofing is a concern of DOS, notes that ingress > >> filtering is a defense and makes no recommendation. > >> > >> I believe spoofing is a significantly greater concern than DOS. As an > >> example, I can spoof traffic from you to create an inbound hole towards > >> one of your ports. > > Simon> Is this a new attack vector introduced by CGN? Without NAT, there's no > Simon> need for a "hole", anyone can send traffic to any of a subscriber's > Simon> ports... > > I find it difficult to answer that question. I'd say that it is likely > an unexpected assumption for someone behind a NAT. It is a > vulnerability of CGNs over other NATs, but perhaps not a vulnerability > of CGNs over no NAT or firewall at all. > Why do we care whether it's new? Is it actually bad if we end up > describing a related attack and recommending people deploy in a manner > that avoids it? The DoS part is new. If an evil subscriber creates mappings in your stead, you may be DoSed. This attack vector does not exist with neither single-user NAT nor no NAT at all. That's why we mention it in the security considerations. I don't think it is useful to recommend ingress filtering to prevent unwanted traffic because it would rely on an unrealistic assumption of a new security benefit that a CGN would provide. CGN does not prevent a subscriber from receiving traffic from anyone. That's true even with ingress filtering. How about adding a sentence like... "CGN as described in this document does not provide any security benefits over either single-user NAT or no NAT at all." I don't think we have any power to change a subscriber's unreasonable assumptions, but we can at least honestly say to operators that they're not buying any security with CGN. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From miyakawa@nttv6.jp Tue Jul 10 13:36:30 2012 Return-Path: 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 3FC6711E813D; Tue, 10 Jul 2012 13:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 bepVbC6Z44RE; Tue, 10 Jul 2012 13:36:29 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id A0E9B11E80CB; Tue, 10 Jul 2012 13:36:29 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [115.69.228.212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id E1838BDC18; Wed, 11 Jul 2012 05:36:54 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id B66ACE169A; Wed, 11 Jul 2012 05:36:54 +0900 (JST) Date: Wed, 11 Jul 2012 05:36:54 +0900 (JST) Message-Id: <20120711.053654.193724485.miyakawa@nttv6.jp> To: simon.perreault@viagenie.ca From: Shin Miyakawa In-Reply-To: <4FFC9143.40407@viagenie.ca> References: <4FFC844F.3010207@viagenie.ca> <4FFC9143.40407@viagenie.ca> Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, secdir@ietf.org, pcp@ietf.org, hartmans-ietf@mit.edu, draft-ietf-behave-lsn-requirements@tools.ietf.org Subject: Re: [pcp] secdir review of draft-ietf-behave-lsn-requirements X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 20:36:30 -0000 >> Then that still permits the case of third_party for administration >> motivating the text in 13.1. > > Makes sense to me. +1 > How about adding a sentence like... > > "CGN as described in this document does not provide any security > benefits over either single-user NAT or no NAT at all." I agree with Simon (also as one of the authors of this draft). We think that CGN is not the machine to proveide security benefits and the original intension of this draft is just to make CGN as neutral as possible... Best wishes, Shin Miyakawa From dthaler@microsoft.com Fri Jul 13 12:57:31 2012 Return-Path: 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 2E6DF11E80FD for ; Fri, 13 Jul 2012 12:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.762 X-Spam-Level: X-Spam-Status: No, score=-103.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 VB+c+0IhITn8 for ; Fri, 13 Jul 2012 12:57:29 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id B2E8A11E80F3 for ; Fri, 13 Jul 2012 12:57:27 -0700 (PDT) Received: from mail32-db3-R.bigfish.com (10.3.81.239) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 19:58:03 +0000 Received: from mail32-db3 (localhost [127.0.0.1]) by mail32-db3-R.bigfish.com (Postfix) with ESMTP id BD99B1605D5 for ; Fri, 13 Jul 2012 19:58:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VS-2(z4c5Iz936eIzz1202hzzz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail32-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail32-db3 (localhost.localdomain [127.0.0.1]) by mail32-db3 (MessageSwitch) id 1342209482288869_2087; Fri, 13 Jul 2012 19:58:02 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.231]) by mail32-db3.bigfish.com (Postfix) with ESMTP id 428D9460194 for ; Fri, 13 Jul 2012 19:58:02 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 19:58:01 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 13 Jul 2012 19:57:58 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 13 Jul 2012 12:57:58 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Reminder: submit IETF 84 PCP agenda requests Thread-Index: Ac1hMcyRqaQAF5AuRpqel8fTJxCwZA== Date: Fri, 13 Jul 2012 19:57:58 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Reminder: submit IETF 84 PCP agenda requests X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 19:57:31 -0000 Please submit agenda requests to the chairs. According to the tools page, the following have been updated or submitted s= ince IETF 83: draft-ietf-pcp-authentication-00 2012-06-29=A0 draft-ietf-pcp-dhcp-03 2012-05-03 draft-ietf-pcp-base-26 2012-06-05 draft-boucadair-pcp-bittorrent-00 2012-05-04 draft-boucadair-pcp-failure-03 2012-05-25=A0=A0 draft-boucadair-pcp-rtp-rtcp-04 2012-04-19 draft-deng-pcp-ddns-01 2012-07-10 draft-dupont-pcp-dslite-02 2012-05-02 draft-ietf-pcp-proxy-00 2012-03-29=A0=A0 draft-maglione-pcp-radius-ext-04 2012-06-21 draft-ohba-pcp-pana-00 2012-07-07 draft-penno-pcp-nested-nat-02 2012-07-02 draft-reddy-pcp-server-discovery-00 2012-06-23 I expect to see requests for at least some of the above. =20 Priority will be given to those that are already WG drafts if space is tigh= t, but currently we have plenty of time. -Dave From dthaler@microsoft.com Fri Jul 13 13:07:09 2012 Return-Path: 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 6B24711E80F0 for ; Fri, 13 Jul 2012 13:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] 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 hCALnoZ9BHB2 for ; Fri, 13 Jul 2012 13:07:08 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3F99011E80EA for ; Fri, 13 Jul 2012 13:07:08 -0700 (PDT) Received: from mail17-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 20:07:44 +0000 Received: from mail17-db3 (localhost [127.0.0.1]) by mail17-db3-R.bigfish.com (Postfix) with ESMTP id 99FEE1C0536 for ; Fri, 13 Jul 2012 20:07:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zz1432I4015Izz1202hzz1033IL8275dh5eeeKz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail17-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail17-db3 (localhost.localdomain [127.0.0.1]) by mail17-db3 (MessageSwitch) id 1342210062412371_8597; Fri, 13 Jul 2012 20:07:42 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.235]) by mail17-db3.bigfish.com (Postfix) with ESMTP id 62DFF180049 for ; Fri, 13 Jul 2012 20:07:42 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 20:07:41 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 13 Jul 2012 20:07:39 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 13 Jul 2012 13:07:38 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WG last call on draft-ietf-pcp-upnp-igd-interworking-01 Thread-Index: Ac1hMjoDlGipwl5IQFyJZsQqTYBReg== Date: Fri, 13 Jul 2012 20:07:37 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B6EC46F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:07:09 -0000 >From the IETF 83 minutes: > 1330-1340 UPnP-IGD Interworking Function (Mohamed Boucadair, = 10) > Document: draft-ietf-pcp-upnp-igd-interworking-01 > Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp= -1.pdf >=20 > Any objections to starting a WG Last Call on this? > Francis objected that the issue of an IGD client that asks for a lifetime= =20 > longer than the PCP server is willing to grant can never be solved,=20 > and therefore the entire work item is futile. > Dave: This is an issue, but not an open issue. > Dave: will confer with Alain about whether to start WG Last Call. The chairs have agreed to start a WG last call. We've seen no additional discussion on this draft since last IETF, so this email initiates a last ca= ll on draft-ietf-pcp-upnp-igd-interworking-01. This call will conclude in two weeks (Friday July 27th), just prior to IETF. Hopefully that will allow for discussion of WGLC comments in Vancouver. We need at least 5 reviewers. Please send comments to the list. Thanks, -Dave From phdgang@gmail.com Mon Jul 16 08:54:44 2012 Return-Path: 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 AD9D911E80C1 for ; Mon, 16 Jul 2012 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QJsynIdbcptL for ; Mon, 16 Jul 2012 08:54:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5829821F8709 for ; Mon, 16 Jul 2012 08:54:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3965089vbb.31 for ; Mon, 16 Jul 2012 08:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=33dtpEGblLd6EaWxvJueVnQgcqflNFjspDpM66qna/8=; b=XAc6JmozzM9Dnihxu1XRv9fN7krQhN0iSfC9QmaoXCjhFhF8pz5pj2Ojfm2L4Y4ta9 7yjHX7vTpBCOT68IHMnsAgpDcqVl6pyDNJOCwc5b7Rm+Jx3f7DkfrSNXCN0rpJDZEFhR KWvE2FlQeSZ7UcyR+0or30DBASyNL5fw6ONdpKbtFEW5QqoXSQaF+zuPV/WgT5wGLY4W HH0cKEq0am/NTggYEFz3YS20L5MY8uVZPP/w3xDxi7ecOKtZF2nUvo2Kz1WU1I+BZLxh TEHxuSpvfnfZ0Z3gVJPzL+LkBQsGhT8G+jeyzS1tYBlFqqXBDANsUh2CpPwxXMf7usGp etDg== MIME-Version: 1.0 Received: by 10.221.12.195 with SMTP id pj3mr3984302vcb.68.1342454126906; Mon, 16 Jul 2012 08:55:26 -0700 (PDT) Received: by 10.58.58.36 with HTTP; Mon, 16 Jul 2012 08:55:26 -0700 (PDT) Date: Mon, 16 Jul 2012 23:55:26 +0800 Message-ID: From: GangChen To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:54:44 -0000 Hello all, We had a discussion of PCP in mobile context at last IETF meeting. This work was encouraged to continue the analysis of major issues when PCP is adopted in a mobile environment. Considering very specific features in mobile network, we made a thorough study to current PCP protocol design. Several typical issues have been pointed. PCP applicability to these issues is further presented in the memo. The authors would seek your reviews and comments. Hope the work is of value to the community. Best Regards Authors of PCP-mobile ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 16 Jul 2012 08:17:46 -0700 Subject: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt To: phdgang@gmail.com Cc: caozhen@chinamobile.com, mohamed.boucadair@orange.com, ales.vizdal@t-mobile.cz, laurent.thiebaut@alcatel-lucent.com A new version of I-D, draft-chen-pcp-mobile-deployment-01.txt has been successfully submitted by Gang Chen and posted to the IETF repository. Filename: draft-chen-pcp-mobile-deployment Revision: 01 Title: Analysis of Port Control Protocol in Mobile Network Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-chen-pcp-mobile-deployment-01.txt Status: http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment Htmlized: http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-chen-pcp-mobile-deployment-01 Abstract: This memo provides a motivation description for the Port Control Protocol (PCP) deployment in a 3GPP mobile network environment. The document focuses on a mobile network specific issues (e.g. cell phone battery power consumption, keep-alive traffic reduction), PCP applicability to these issues is further studied and analysed. The IETF Secretariat From dxhbupt@gmail.com Wed Jul 18 10:00:29 2012 Return-Path: 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 DCA4B21F871C for ; Wed, 18 Jul 2012 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 yVFn+jRdx3g7 for ; Wed, 18 Jul 2012 10:00:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 916C721F8717 for ; Wed, 18 Jul 2012 10:00:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2636393lbb.31 for ; Wed, 18 Jul 2012 10:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2ZABZvuadkWMOykWzRlL4k1A6+r29tAVBpdY645V+Xk=; b=VDsuioWUUjI99TE07oPGMI5A2e5z04QabZhyIto2MshrLwaWuZ1EZwlxLJd1dLbq02 rOnDc6/c0xTzPMyvX5d3J0rqHu+zCOm+GpHcI2SQ6JU5OooK4vmpH0GlEUp+xyVvazta cL89zUAK3B4FuNhMvprF0z4LLC1OpTcrHTTogoSd9B2OJSXLjU5+zddnJT6dTi7w54an /CTs2R6lZwItEfzN7PRvAIfibE93laEixtnInXmQEjJE/xC8XL69fE1MjmBvDDqUnyuN GfKkHBUZ4Wpiwfa/x6wRFmCpB3w44b8ehk7L6wuhWCMb1KNN/ojqEqgOzJtTLT+3q/Fg xN4w== MIME-Version: 1.0 Received: by 10.112.102.136 with SMTP id fo8mr2168524lbb.106.1342630878514; Wed, 18 Jul 2012 10:01:18 -0700 (PDT) Received: by 10.112.101.38 with HTTP; Wed, 18 Jul 2012 10:01:18 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 18 Jul 2012 19:01:18 +0200 Message-ID: From: Xiaohong Deng To: Dave Thaler Content-Type: multipart/alternative; boundary=f46d0401fa33940cda04c51d9cc7 Cc: "pcp@ietf.org" Subject: Re: [pcp] Reminder: submit IETF 84 PCP agenda requests X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 17:00:30 -0000 --f46d0401fa33940cda04c51d9cc7 Content-Type: text/plain; charset=ISO-8859-1 Dear Chairs, We would like to request a 10 minutes slot to present draft-deng-pcp-ddns in Vancouver meeting. Thank you! Kind Regards, Xiaohong, on behalf of all authors. Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/ Open source PCP: http://sourceforge.net/projects/pcpclient/ Open source A+P: http://opensourceaplusp.weebly.com/ On Fri, Jul 13, 2012 at 9:57 PM, Dave Thaler wrote: > Please submit agenda requests to the chairs. > > According to the tools page, the following have been updated or submitted > since IETF 83: > > draft-ietf-pcp-authentication-00 2012-06-29 > draft-ietf-pcp-dhcp-03 2012-05-03 > draft-ietf-pcp-base-26 2012-06-05 > draft-boucadair-pcp-bittorrent-00 2012-05-04 > draft-boucadair-pcp-failure-03 2012-05-25 > draft-boucadair-pcp-rtp-rtcp-04 2012-04-19 > draft-deng-pcp-ddns-01 2012-07-10 > draft-dupont-pcp-dslite-02 2012-05-02 > draft-ietf-pcp-proxy-00 2012-03-29 > draft-maglione-pcp-radius-ext-04 2012-06-21 > draft-ohba-pcp-pana-00 2012-07-07 > draft-penno-pcp-nested-nat-02 2012-07-02 > draft-reddy-pcp-server-discovery-00 2012-06-23 > > I expect to see requests for at least some of the above. > Priority will be given to those that are already WG drafts if space is > tight, > but currently we have plenty of time. > > -Dave > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --f46d0401fa33940cda04c51d9cc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Chairs,

We would like to request a 10 minutes slot to present d= raft-deng-pcp-ddns in Vancouver meeting.

Thank you!

Kind Rega= rds,
Xiaohong, on behalf of all authors.

Open source mB4 for Mult= icast DS-Lite: http://sourceforge.net/projects/mb4/
Open source PCP: http://sourceforge.net/projects/pcpclient/
Open sourc= e A+P: ht= tp://opensourceaplusp.weebly.com/

On Fri, Jul 13, 2012 at 9:57 PM, Dave Thaler= <dthaler@microsoft.com> wrote:
Please submit agenda requests to the chairs.

According to the tools page, the following have been updated or submitted s= ince IETF 83:

draft-ietf-pcp-authentication-00 =A0 =A0 =A0 =A02012-06-29=A0
draft-ietf-pcp-dhcp-03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02012-05-03
draft-ietf-pcp-base-26 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02012-06-05
draft-boucadair-pcp-bittorrent-00 =A0 =A0 =A0 2012-05-04
draft-boucadair-pcp-failure-03 =A0 =A0 =A0 =A0 =A02012-05-25=A0=A0
draft-boucadair-pcp-rtp-rtcp-04 2012-04-19
draft-deng-pcp-ddns-01 =A0 =A0 =A0 =A0 =A02012-07-10
draft-dupont-pcp-dslite-02 =A0 =A0 =A0 =A0 =A0 =A0 =A02012-05-02
draft-ietf-pcp-proxy-00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2012-03-29=A0=A0 draft-maglione-pcp-radius-ext-04 =A0 =A0 =A0 =A02012-06-21
draft-ohba-pcp-pana-00 =A0 =A0 =A0 =A0 =A02012-07-07
draft-penno-pcp-nested-nat-02 =A0 2012-07-02
draft-reddy-pcp-server-discovery-00 =A0 =A0 2012-06-23

I expect to see requests for at least some of the above.
Priority will be given to those that are already WG drafts if space is tigh= t,
but currently we have plenty of time.

-Dave

_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp




--f46d0401fa33940cda04c51d9cc7-- From dthaler@microsoft.com Wed Jul 18 14:20:56 2012 Return-Path: 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 5790321F8634 for ; Wed, 18 Jul 2012 14:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.421 X-Spam-Level: X-Spam-Status: No, score=-103.421 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 VSmMw80nqgPC for ; Wed, 18 Jul 2012 14:20:55 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5F21F865D for ; Wed, 18 Jul 2012 14:20:55 -0700 (PDT) Received: from mail88-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 21:21:43 +0000 Received: from mail88-am1 (localhost [127.0.0.1]) by mail88-am1-R.bigfish.com (Postfix) with ESMTP id 54526180212; Wed, 18 Jul 2012 21:21:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz4015Izz1202hzzz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail88-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail88-am1 (localhost.localdomain [127.0.0.1]) by mail88-am1 (MessageSwitch) id 1342646501979637_11143; Wed, 18 Jul 2012 21:21:41 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.249]) by mail88-am1.bigfish.com (Postfix) with ESMTP id EB886300044; Wed, 18 Jul 2012 21:21:41 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 21:21:39 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 18 Jul 2012 21:21:26 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Wed, 18 Jul 2012 14:21:26 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTw== Date: Wed, 18 Jul 2012 21:21:25 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dhc@ietf.org" Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:20:56 -0000 As discussed at last IETF, the authors believe that all issues raised so far have been addressed. No new issues have been raised since then, so this message begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. This call would normally conclude in two weeks but that is during IETF week, so the last call is extended to conclude at the end of IETF (as of the Friday PCP meeting). We also agreed in Vancouver that this last call will be cross-posted to the DHC list, hence cc'ing the DHC WG. We need at least 5 reviewers. Please send comments to the list. Thanks, -Dave Thaler From dthaler@microsoft.com Wed Jul 18 14:49:43 2012 Return-Path: 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 E2B4411E80A2; Wed, 18 Jul 2012 14:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.414 X-Spam-Level: X-Spam-Status: No, score=-103.414 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 68z2BTMPyWNl; Wed, 18 Jul 2012 14:49:42 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id C498111E8087; Wed, 18 Jul 2012 14:49:41 -0700 (PDT) Received: from mail82-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 21:50:32 +0000 Received: from mail82-db3 (localhost [127.0.0.1]) by mail82-db3-R.bigfish.com (Postfix) with ESMTP id 7769B44019E; Wed, 18 Jul 2012 21:50:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail82-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail82-db3 (localhost.localdomain [127.0.0.1]) by mail82-db3 (MessageSwitch) id 1342648231662682_30037; Wed, 18 Jul 2012 21:50:31 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.228]) by mail82-db3.bigfish.com (Postfix) with ESMTP id 9F9233A0206; Wed, 18 Jul 2012 21:50:31 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 21:50:31 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 18 Jul 2012 21:50:22 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 18 Jul 2012 14:50:21 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Wed, 18 Jul 2012 14:50:21 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwABZYWw Date: Wed, 18 Jul 2012 21:50:21 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dhcwg@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:49:43 -0000 Correcting DHC WG email address. > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dav= e > Thaler > Sent: Wednesday, July 18, 2012 2:21 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >=20 > As discussed at last IETF, the authors believe that all issues raised so = far have > been addressed. No new issues have been raised since then, so this messa= ge > begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. >=20 > This call would normally conclude in two weeks but that is during IETF we= ek, so > the last call is extended to conclude at the end of IETF (as of the Frida= y PCP > meeting). >=20 > We also agreed in Vancouver that this last call will be cross-posted to t= he DHC > list, hence cc'ing the DHC WG. >=20 > We need at least 5 reviewers. Please send comments to the list. >=20 > Thanks, > -Dave Thaler >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Wed Jul 18 15:24:17 2012 Return-Path: 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 0DA5021F86E8 for ; Wed, 18 Jul 2012 15:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.208 X-Spam-Level: X-Spam-Status: No, score=-105.208 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 O1zMAaopaoZB for ; Wed, 18 Jul 2012 15:24:16 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1455621F86B5 for ; Wed, 18 Jul 2012 15:24:15 -0700 (PDT) Received: from mail22-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 22:25:06 +0000 Received: from mail22-va3 (localhost [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 847783604DE for ; Wed, 18 Jul 2012 22:25:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail22-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1342650305373989_12135; Wed, 18 Jul 2012 22:25:05 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.253]) by mail22-va3.bigfish.com (Postfix) with ESMTP id 4E952440048 for ; Wed, 18 Jul 2012 22:25:05 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 22:25:04 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 18 Jul 2012 22:25:03 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Wed, 18 Jul 2012 15:25:03 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Draft PCP agenda posted Thread-Index: Ac1lNA7aRwDde0TGQqK0Y9kp8J9KwA== Date: Wed, 18 Jul 2012 22:25:02 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B70B60F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Draft PCP agenda posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:24:17 -0000 http://www.ietf.org/proceedings/84/agenda/agenda-84-pcp now contains a tentative agenda that includes the items I've seen requests for so far. The order and times may change=20 as we get closer to IETF, but if you want to confirm we got your request, you can now see what we have. -Dave From simon.perreault@viagenie.ca Thu Jul 19 05:50:43 2012 Return-Path: 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 751C621F87BC; Thu, 19 Jul 2012 05:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Jb0kNX9Nhz6i; Thu, 19 Jul 2012 05:50:42 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id EF7DD21F87BA; Thu, 19 Jul 2012 05:50:41 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:cd29:16aa:f6fd:52fe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1EB2A42664; Thu, 19 Jul 2012 08:51:24 -0400 (EDT) Message-ID: <500802CB.5010908@viagenie.ca> Date: Thu, 19 Jul 2012 08:51:23 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "behave@ietf.org" References: <5007C972.9020402@neclab.eu> In-Reply-To: <5007C972.9020402@neclab.eu> X-Forwarded-Message-Id: <5007C972.9020402@neclab.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 12:50:43 -0000 Behaviers, PCPers, During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was filed regarding the PCP requirement. Details below. I think this DISCUSS needs to be discussed. So please discuss. Please reply to behave@ietf.org. Thanks, Simon -------- Message original -------- Sujet: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) Date : Thu, 19 Jul 2012 10:46:42 +0200 De : Martin Stiemerling Pour : Simon Perreault Copie à : The IESG , , Hi Simon, all, On 07/17/2012 11:11 PM, Simon Perreault wrote: > Le 2012-07-17 16:42, Martin Stiemerling a écrit : >>> Each and every CGN MUST have PCP and MUST follow the constraints. I'll >>> fix the text in a later revision. >> >> Can we mandate a specific protocol to be used for this or can we only >> mandate that such a type of protocol is being used? I don't see the IETF >> in the position to mandate this type of protocol for CGNs. >> >> There are other protocols out there which might be suitable. Note that I >> am co-author of some, but this isn't the reason for the question. I do >> not get any reward if I promote these protocols. >> >> It is more: >> do we need to constrain CGN deployments to a protocol (PCP) which is >> developed right now, or are we open to existing or future protocols, or >> whatever folks deploying this deem right? >> >> I would propose to change REQ-9 to : >> REQ-9: A CGN MUST include a middlebox control protocol that allows >> manipulation of CGN bindings with the following contstraints > A and B> >> REQ-9a: If PCP is used these contstraints MUST be applied in addition to >> contraints A and B: >> > > That was discussed in IETF 81 (Québec). Here's the extract from the > minutes: > > Stuart Cheshire: ietf has one port forwarding protocol, which > is PCP, so we should require it by name There are multiple middlebox control protocols published by the IETF (standards track and experimental) and I have not seen any call for consensus on what **the** IETF's middlebox control is, neither I have seen any RFC that states this. I do not see that an individual can declare IETF consensus based on his own opinion. > > Dave Thaler: I agree. PCP doc is in final stages. Again, an opinion of an individual. Nothing wrong about it, but it does not state IETF consensus. > > There was consensus from the WG. In consequence, the text was changed > from this (-02): > > A CGN SHOULD support a port forwarding protocol such as the > Port Control Protocol [I-D.ietf-pcp-base]. > > to this (-03): > > A CGN SHOULD include a Port Control Protocol server > [I-D.ietf-pcp-base]. > > (That requirement later became a MUST, but that's orthogonal to what > protocol we require.) I do not see that the IETF can mandate what protocols are being used to control a device. The market will decide! For instance, the is no MUST required that routers implement BGP. It is good to do this, but if one decides to go for IS-IS (or whatever) that is just fine. Another example, there is also no MUST requirement that routers, or hosts in general, have to implement SNMP. However, I can see the immediate need to mandate that a CGN SHOULD/MUST support a middlebox control protocol that is able to install and maintain NAT bindings. Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From hartmans@painless-security.com Thu Jul 19 06:02:10 2012 Return-Path: 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 2F40121F87D3; Thu, 19 Jul 2012 06:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DzSOMyt2duAJ; Thu, 19 Jul 2012 06:02:09 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A831C21F87D2; Thu, 19 Jul 2012 06:02:09 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F27AB203BA; Thu, 19 Jul 2012 09:03:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DE6A941F0; Thu, 19 Jul 2012 09:02:33 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <5007C972.9020402@neclab.eu> <500802CB.5010908@viagenie.ca> Date: Thu, 19 Jul 2012 09:02:33 -0400 In-Reply-To: <500802CB.5010908@viagenie.ca> (Simon Perreault's message of "Thu, 19 Jul 2012 08:51:23 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, "behave@ietf.org" Subject: Re: [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:02:10 -0000 I think that behave-lsn-requirements is far more useful if it names a specific protocol by name. By endorcing one of our middlebox protocols, we encourage interoperability. If we don't pick a protocol by name, we don't really promote interoperability. It's not useful if your CGN does midcom and my client does PCP and I'm your customer. The assumption behind LSN-requirements is that the CGN and the CPE are not controlled/purchased/whatever by the same entity. So, mandating a specific protocol seems desirable. I think that the behave WG is the right place to make that decision. The IETF as a whole should be able to second guess behave, but we should need a fairly high bar for doing so. The claim that PCP is the IETF's only protocol in this space does seem a little bit on the wishful thinking side of things. So, I could understand if the IESG wanted to ask behave to spend a little more time on the question. From hannes.tschofenig@gmx.net Thu Jul 19 09:04:28 2012 Return-Path: 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 D429321F87C7 for ; Thu, 19 Jul 2012 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qskuV+zMCHUy for ; Thu, 19 Jul 2012 09:04:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9BCE621F8668 for ; Thu, 19 Jul 2012 09:04:26 -0700 (PDT) Received: (qmail invoked by alias); 19 Jul 2012 16:05:18 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 19 Jul 2012 18:05:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+B5j0CtcuBzmBM6QNxkAUsHw2Kb93VERE5qplq5F 0LiC6+21RlgFHz Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <500802CB.5010908@viagenie.ca> Date: Thu, 19 Jul 2012 19:05:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5007C972.9020402@neclab.eu> <500802CB.5010908@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "behave@ietf.org" , pcp@ietf.org Subject: Re: [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:04:29 -0000 I agree with Martin's remarks. On Jul 19, 2012, at 3:51 PM, Simon Perreault wrote: > Behaviers, PCPers, >=20 > During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS = was filed regarding the PCP requirement. Details below. >=20 > I think this DISCUSS needs to be discussed. So please discuss. >=20 > Please reply to behave@ietf.org. >=20 > Thanks, > Simon >=20 >=20 > -------- Message original -------- > Sujet: Re: Martin Stiemerling's Discuss on = draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) > Date : Thu, 19 Jul 2012 10:46:42 +0200 > De : Martin Stiemerling > Pour : Simon Perreault > Copie =E0 : The IESG , , = >=20 > Hi Simon, all, >=20 > On 07/17/2012 11:11 PM, Simon Perreault wrote: >> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>> Each and every CGN MUST have PCP and MUST follow the constraints. = I'll >>>> fix the text in a later revision. >>>=20 >>> Can we mandate a specific protocol to be used for this or can we = only >>> mandate that such a type of protocol is being used? I don't see the = IETF >>> in the position to mandate this type of protocol for CGNs. >>>=20 >>> There are other protocols out there which might be suitable. Note = that I >>> am co-author of some, but this isn't the reason for the question. I = do >>> not get any reward if I promote these protocols. >>>=20 >>> It is more: >>> do we need to constrain CGN deployments to a protocol (PCP) which is >>> developed right now, or are we open to existing or future protocols, = or >>> whatever folks deploying this deem right? >>>=20 >>> I would propose to change REQ-9 to : >>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>> manipulation of CGN bindings with the following contstraints >> A and B> >>> REQ-9a: If PCP is used these contstraints MUST be applied in = addition to >>> contraints A and B: >>> >>=20 >> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >> minutes: >>=20 >> Stuart Cheshire: ietf has one port forwarding protocol, = which >> is PCP, so we should require it by name >=20 > There are multiple middlebox control protocols published by the IETF > (standards track and experimental) and I have not seen any call for > consensus on what **the** IETF's middlebox control is, neither I have > seen any RFC that states this. >=20 > I do not see that an individual can declare IETF consensus based on = his > own opinion. >=20 >=20 >>=20 >> Dave Thaler: I agree. PCP doc is in final stages. >=20 > Again, an opinion of an individual. Nothing wrong about it, but it = does > not state IETF consensus. >=20 >>=20 >> There was consensus from the WG. In consequence, the text was changed >> from this (-02): >>=20 >> A CGN SHOULD support a port forwarding protocol such as = the >> Port Control Protocol [I-D.ietf-pcp-base]. >>=20 >> to this (-03): >>=20 >> A CGN SHOULD include a Port Control Protocol server >> [I-D.ietf-pcp-base]. >>=20 >> (That requirement later became a MUST, but that's orthogonal to what >> protocol we require.) >=20 > I do not see that the IETF can mandate what protocols are being used = to > control a device. The market will decide! >=20 > For instance, the is no MUST required that routers implement BGP. It = is > good to do this, but if one decides to go for IS-IS (or whatever) that > is just fine. >=20 > Another example, there is also no MUST requirement that routers, or > hosts in general, have to implement SNMP. >=20 > However, I can see the immediate need to mandate that a CGN = SHOULD/MUST > support a middlebox control protocol that is able to install and > maintain NAT bindings. >=20 > Martin >=20 > --=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Thu Jul 19 09:18:36 2012 Return-Path: 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 EA9D421F86A8; Thu, 19 Jul 2012 09:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bqtzgVANHGZp; Thu, 19 Jul 2012 09:18:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EBE5F21F8672; Thu, 19 Jul 2012 09:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=4947; q=dns/txt; s=iport; t=1342714769; x=1343924369; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RKERFEEvRvV+F3yzQ8zB3/0M1fr5oEZ9M6O4ibKmd+g=; b=kXGdq0vCKKAxk9PGKOhdyvklbtcy0jFW/s444oroN5mQ7abiqm19Ma2M AbFM/ffxV6cK+OEAeIehbtP/6zmjRZAJgFfsLw3DBFLVn6suIR/mJc//a c5u0PCDKWr4HjrUbnPPBddOeCSH81Q1DCrgPHM1KETxMq/jjTzP8UKfyL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEwzCFCtJXHB/2dsb2JhbABFuUCBB4IcBAEBAQQBAQEPAQpRBgUSAQgYIzILFBECBAENBQkZhScHgiQKAwwLnjegCIplZxQEhngDiBiNLI4jgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103492726" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2012 16:19:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6JGJTZa024543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 16:19:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 11:19:25 -0500 From: "Reinaldo Penno (repenno)" To: Hannes Tschofenig , Simon Perreault Thread-Topic: [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) Thread-Index: AQHNZcpD5zVzSRWO2Ue47DGuTsCIiQ== Date: Thu, 19 Jul 2012 16:19:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.65.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--51.962200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1771A1264D08E74EB0B132EF74003450@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "behave@ietf.org" Subject: Re: [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:18:37 -0000 Humm...I'm not sure I agree. "However, if a router does implement EGP it also MUST IMPLEMENT BGP." http://www.ietf.org/rfc/rfc1812.txt Or look at the requirements for IPv6 CEs or any other device that needs to interoperate with others. On 7/19/12 9:05 AM, "Hannes Tschofenig" wrote: >I agree with Martin's remarks. > >On Jul 19, 2012, at 3:51 PM, Simon Perreault wrote: > >> Behaviers, PCPers, >>=20 >> During IESG review of draft-ietf-behave-lsn-requirements, a DISCUSS was >>filed regarding the PCP requirement. Details below. >>=20 >> I think this DISCUSS needs to be discussed. So please discuss. >>=20 >> Please reply to behave@ietf.org. >>=20 >> Thanks, >> Simon >>=20 >>=20 >> -------- Message original -------- >> Sujet: Re: Martin Stiemerling's Discuss on >>draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) >> Date : Thu, 19 Jul 2012 10:46:42 +0200 >> De : Martin Stiemerling >> Pour : Simon Perreault >> Copie =E0 : The IESG , , >> >>=20 >> Hi Simon, all, >>=20 >> On 07/17/2012 11:11 PM, Simon Perreault wrote: >>> Le 2012-07-17 16:42, Martin Stiemerling a =E9crit : >>>>> Each and every CGN MUST have PCP and MUST follow the constraints. >>>>>I'll >>>>> fix the text in a later revision. >>>>=20 >>>> Can we mandate a specific protocol to be used for this or can we only >>>> mandate that such a type of protocol is being used? I don't see the >>>>IETF >>>> in the position to mandate this type of protocol for CGNs. >>>>=20 >>>> There are other protocols out there which might be suitable. Note >>>>that I >>>> am co-author of some, but this isn't the reason for the question. I do >>>> not get any reward if I promote these protocols. >>>>=20 >>>> It is more: >>>> do we need to constrain CGN deployments to a protocol (PCP) which is >>>> developed right now, or are we open to existing or future protocols, >>>>or >>>> whatever folks deploying this deem right? >>>>=20 >>>> I would propose to change REQ-9 to : >>>> REQ-9: A CGN MUST include a middlebox control protocol that allows >>>> manipulation of CGN bindings with the following contstraints >>>items >>>> A and B> >>>> REQ-9a: If PCP is used these contstraints MUST be applied in addition >>>>to >>>> contraints A and B: >>>> >>>=20 >>> That was discussed in IETF 81 (Qu=E9bec). Here's the extract from the >>> minutes: >>>=20 >>> Stuart Cheshire: ietf has one port forwarding protocol, which >>> is PCP, so we should require it by name >>=20 >> There are multiple middlebox control protocols published by the IETF >> (standards track and experimental) and I have not seen any call for >> consensus on what **the** IETF's middlebox control is, neither I have >> seen any RFC that states this. >>=20 >> I do not see that an individual can declare IETF consensus based on his >> own opinion. >>=20 >>=20 >>>=20 >>> Dave Thaler: I agree. PCP doc is in final stages. >>=20 >> Again, an opinion of an individual. Nothing wrong about it, but it does >> not state IETF consensus. >>=20 >>>=20 >>> There was consensus from the WG. In consequence, the text was changed >>> from this (-02): >>>=20 >>> A CGN SHOULD support a port forwarding protocol such as the >>> Port Control Protocol [I-D.ietf-pcp-base]. >>>=20 >>> to this (-03): >>>=20 >>> A CGN SHOULD include a Port Control Protocol server >>> [I-D.ietf-pcp-base]. >>>=20 >>> (That requirement later became a MUST, but that's orthogonal to what >>> protocol we require.) >>=20 >> I do not see that the IETF can mandate what protocols are being used to >> control a device. The market will decide! >>=20 >> For instance, the is no MUST required that routers implement BGP. It is >> good to do this, but if one decides to go for IS-IS (or whatever) that >> is just fine. >>=20 >> Another example, there is also no MUST requirement that routers, or >> hosts in general, have to implement SNMP. >>=20 >> However, I can see the immediate need to mandate that a CGN SHOULD/MUST >> support a middlebox control protocol that is able to install and >> maintain NAT bindings. >>=20 >> Martin >>=20 >> --=20 >> martin.stiemerling@neclab.eu >>=20 >> NEC Laboratories Europe - Network Research Division NEC Europe Limited >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >> Registered in England 283 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Jul 19 11:34:26 2012 Return-Path: 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 ED73321F868A; Thu, 19 Jul 2012 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 QmoWG7e5g+ob; Thu, 19 Jul 2012 11:34:25 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 269DB21F8683; Thu, 19 Jul 2012 11:34:25 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:18fd:ed02:dd69:c681]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 45F45414A1; Thu, 19 Jul 2012 14:35:18 -0400 (EDT) Message-ID: <50085365.6050701@viagenie.ca> Date: Thu, 19 Jul 2012 14:35:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org, "behave@ietf.org" , IETF Subject: Re: [pcp] [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:34:26 -0000 Le 2012-07-19 14:20, David Harrington a écrit : > The IETF could mandate a specific protocol to try to ensure > interoperability, but doing this takes the decision out of the > responsibility of the deployer to choose the best solution for the > deployment environment, and out of the responsibility of the vendor to > best meet their customers' demands. > Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB > might best meet their needs. > Some vendors might support a Netconf environment and desire a > Netconf-based configuration solution. > Some vendors already use AAA widely to control their environment, and > Diameter NAT control might be preferable. Careful here. The above protocols are not used between the CPE and the CGN. The requirement for PCP (or PCP-like) is justified by the need for subscribers to be able to control the CGN to some extent. Note also that any of those protocols could also be supported in addition to PCP, up to the implementer and operator. > Of course, if CGN is only an ipv4 exit strategy, as is asserted, Not as asserted by the draft, I hope. We have tried making clear that CGN as defined in this document really stands for "multi-user NAT" and that there are use cases that have nothing to do with IPv4 sunset (e.g. the NAT function in a wifi hotspot is a CGN). The CGN logical function may or may not be used as part of an IPv4 sunset scenario. As such, it is is absolutely part of behave's core expertise. Sunset4 could have things to say about how CGN gets applied to IPv4 sunset, but how CGN behaves is up to behave. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hartmans@painless-security.com Thu Jul 19 13:16:08 2012 Return-Path: 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 0F80411E809B; Thu, 19 Jul 2012 13:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 GxAaKkdCMFMK; Thu, 19 Jul 2012 13:16:07 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3172711E8099; Thu, 19 Jul 2012 13:16:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 69E72203BA; Thu, 19 Jul 2012 16:17:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B22541F0; Thu, 19 Jul 2012 16:16:31 -0400 (EDT) From: Sam Hartman To: David Harrington References: Date: Thu, 19 Jul 2012 16:16:31 -0400 In-Reply-To: (David Harrington's message of "Thu, 19 Jul 2012 14:20:53 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, "behave@ietf.org" , IETF Subject: Re: [pcp] [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:16:08 -0000 >>>>> "David" == David Harrington writes: David> The IETF could mandate a specific protocol to try to ensure David> interoperability, but doing this takes the decision out of the David> responsibility of the deployer to choose the best solution for the David> deployment environment, and out of the responsibility of the vendor to David> best meet their customers' demands. This doesn't make any sense to me at all. It makes sense if the vendor that the ISP is going to use (the CGN vendor) is somehow related to the vendor that the customer is going to use (the CPE vendor). However, one of the explicitly stated assumptions in the behave-lsn document is that is not the case. The customer gets to choose a CPE vendor and the operator gets to choose a CGN vendor. The deployment environment here is the Internet. In cases like this in the past we have chosen a technology. I'm reasonably sure that host requirements mandate DNS as the name service protocol. We don't want one isp to choose some big LDAP directory and one ISP to choose DNS. We want customers name resolution to continue to work (with the same CPE they already have) as they move from one ISP to another. The same arguments apply here . Under the assumptions of this BCP, there is not a boundary between deployment environments across which one deployment could use PCP and another SNMP. (I am not aware of netconf schema that does anything similar to PCP that has been standardized.) Even obvious deployment environments like cable vs DSL don't make sense. I can buy my own router and stick it behind either a cable modem or a DSL router. People often do this. With some ISPs the configuration gets a little tricky and you may introduce an extra level of NAT. However, people deploy their own customer gateways on cable, DSL, even in some cases mobile wireless. BGP was held up as an example, namely that we don't mandate the implementation of BGP. Well, not all routers should implement BGP. My little Linksys box has no need for it. However, if we wrote requirements for routers participating in the core routing infrastructure--routers between large organizations and ISP--we'd almost certainly mandate BGP. Not all NATs need the same middlebox control protocol. However, this document does not apply to all NATs. It applies to NATs that cross organizational boundaries. That's exactly the environment where saying something like "this is an SNMP deployment," confuses me because I don't think there will be uniform characterizations of the deployment. From bingxuere@gmail.com Thu Jul 19 23:05:52 2012 Return-Path: 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 0CC0F21F8658 for ; Thu, 19 Jul 2012 23:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 f7eoP9sRsk9L for ; Thu, 19 Jul 2012 23:05:50 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7021F8552 for ; Thu, 19 Jul 2012 23:05:50 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3968462ggn.31 for ; Thu, 19 Jul 2012 23:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=oIZjK1hldynaMNIwHggrjUt/v/bqcZH9u8DN4LVwaEM=; b=hko1C+N2/26ivsI+d+Z0FlIgH0YZJOynslJXES8yBF6mk+Bj/ct/eFXqKpTk34d1uj rQHE0XS4Wz6AGsxOg2nKVNffH0EKESzIllGiBzLFcgL2Xtl/bWNx7mKeyREEVZ4MMiLz K1AVH22ncgo7Pe7RRwKcArrZ9TBeH89e/nectQifa7WoriIej3MdcYf9P5lTBWGedEKh B7F62ZQITWBbPK6nXXmTqLRxKxH/MXIVHAvpgu4F87nHyQI+qNSuzY2BfFOgFb6k5/q9 tk07VjXq3T7GRzKtOMtnNxgUrPt1n9N3AyhO1Exc6RtgwMMzRfICIt7Pq4EaHFdJ4sM4 ol5w== Received: by 10.50.217.201 with SMTP id pa9mr7492707igc.54.1342764405472; Thu, 19 Jul 2012 23:06:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Thu, 19 Jul 2012 23:06:05 -0700 (PDT) From: Qiong Date: Fri, 20 Jul 2012 14:06:05 +0800 Message-ID: To: pcp@ietf.org Content-Type: multipart/alternative; boundary=14dae93405cb67bc3704c53cb301 Subject: [pcp] FW:New Version Notification for draft-tsou-pcp-natcoord-07.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:05:52 -0000 --14dae93405cb67bc3704c53cb301 Content-Type: text/plain; charset=UTF-8 Deal All, We have submitted a new version of pcp-natcoord which extends PCP with the ability to reserve port set instead of individual mapping. After receiving valuable comments from the last IETF meeting, we have improved our work on some corner-cases, including: 1) how to deal with the case when one subscriber requires multiple port-sets 2) how to proceed when a mapping is already exist/or not exist for a requested Internal address 3) how to proceed deal with the case when MAP and MAP_PORT_SET co-exist 4) how to deal with the error codes The proposed mechanism can be used to retrieve a restricted IPv4 address and a port range. A deployment scenario is described in: http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-07. This mechisnim is especially important when an operator does not have a dhcpv4 server to do port-set allocation. Your comments are appreciated. Thanks in advance! Best wishes Qiong ===================================================================== A new version of I-D, draft-tsou-pcp-natcoord-07.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Filename: draft-tsou-pcp-natcoord Revision: 07 Title: Lightweight 4over6 Port-set Allocation: Using PCP To Coordinate Between the CGN and Home Gateway Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-tsou-pcp-natcoord-07.txt Status: http://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord Htmlized: http://tools.ietf.org/html/draft-tsou-pcp-natcoord-07 Diff: http://tools.ietf.org/rfcdiff?url2=draft-tsou-pcp-natcoord-07 Abstract: This document defines an extension to the base PCP. New OpCode and Options are defined to enhance PCP with the ability to reserve port sets for internal hosts. -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae93405cb67bc3704c53cb301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Deal All,

We have submitted a new version of pcp-natcoord which extends PCP with the ability to reserve port set= instead of individual mapping. After receiving valuable comments from the = last IETF meeting, we have improved our work on some corner-cases, includin= g:
1) how to deal with the case when one subscriber requires multiple port-set= s
2) how to proceed when a mapping is already exist/or not exist for a = requested Internal address
3) how to proceed deal with the case when MAP= and MAP_PORT_SET co-exist
4) how to deal with the error codes

The proposed mechanism can be us= ed to retrieve a restricted IPv4 address and a port range. A deployment sce= nario is described in: http://tools.ietf.org/html/draft-cui-softwir= e-b4-translated-ds-lite-07. This mechisnim is especially important when= an operator does not have a dhcpv4 server to do port-set allocation.

Your comments are appreciated. Thanks in advance!

Best wishesQiong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DA=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-tsou-pcp-natcoord-07.= txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Qiong=C2= =A0Sun=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-tsou-pcp-natcoord
Revision: =C2=A007
Title:=20 =C2=A0Lightweight=C2=A04over6=C2=A0Port-set=C2=A0Allocation:=C2=A0Using=C2= =A0PCP=C2=A0To=C2=A0Coordinate=C2=A0Between=C2=A0the=C2=A0CGN=C2=A0and=C2= =A0Home=C2=A0Gateway
Creation=C2=A0date: =C2=A02012-07-16
WG=C2=A0ID: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A014
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0This=C2=A0document=C2=A0defines=C2=A0an=C2=A0extensi= on=C2=A0to=C2=A0the=C2=A0base=C2=A0PCP.=C2=A0=C2=A0New=C2=A0OpCode=C2=A0and=
=C2=A0=C2=A0=C2=A0Options=C2=A0are=C2=A0defined=C2=A0to=C2=A0enhance= =C2=A0PCP=C2=A0with=C2=A0the=C2=A0ability=C2=A0to=C2=A0reserve=C2=A0port
=C2=A0=C2=A0=C2=A0sets=C2=A0for=C2=A0internal=C2=A0hosts.


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: http://sourceforge.net/projects= /laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93405cb67bc3704c53cb301-- From dthaler@microsoft.com Thu Jul 26 14:32:12 2012 Return-Path: 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 4953611E80BB for ; Thu, 26 Jul 2012 14:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 fHo445XtpgQQ for ; Thu, 26 Jul 2012 14:32:11 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0262311E80AE for ; Thu, 26 Jul 2012 14:32:10 -0700 (PDT) Received: from mail100-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jul 2012 21:32:10 +0000 Received: from mail100-am1 (localhost [127.0.0.1]) by mail100-am1-R.bigfish.com (Postfix) with ESMTP id D8C0C26024E; Thu, 26 Jul 2012 21:32:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail100-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail100-am1 (localhost.localdomain [127.0.0.1]) by mail100-am1 (MessageSwitch) id 1343338328190507_744; Thu, 26 Jul 2012 21:32:08 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.239]) by mail100-am1.bigfish.com (Postfix) with ESMTP id 22725220048; Thu, 26 Jul 2012 21:32:08 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jul 2012 21:32:07 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 26 Jul 2012 21:32:06 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Thu, 26 Jul 2012 14:32:06 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6Q Date: Thu, 26 Jul 2012 21:32:05 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7234D2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dhc@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:32:12 -0000 Here's my personal comments on draft -03... I have a few editorial nits I'= ll just send to the authors. 1) I agree with the conclusion of the rationale but the sentence "DHC WG's position is this flexibility have some drawbacks such as ind= ucing errors." isn't intelligible. What does "inducing errors" mean? Either explain= or remove. 2) The text on what to do with a name conveyed in an option is duplicated i= n=20 Section 4.2 and 5.2. I'd prefer that this be specified only once, to = avoid opportunities for discrepancies. That is, section 4.2's first two par= agraphs are fine, as are the first 1 1/2 paragraphs of 5.2, since those are about h= ow to get the name out of the option. The rest isn't DHCPv4 or DHCPv6 specific= and should be in its own subsection. 3) Re "It is RECOMMENDED to associate a validity lifetime with any address resulting from resolving the Name". The text should be more specific a= bout what the validity lifetime should be. If the name is resolved in DNS,= I'd say the validity lifetime should be the TTL of the DNS record. 4) Re "When an application issues a PCP request to a PCP Server, the source address of the request MUST be among those assigned on the interface to which the destination PCP Server is bound. This doesn't belong in a DHCP-specific document, it's out of scope. Th= at's the job of the pcp-base spec. =20 5) Same as point 4, but for all of section 6. In my view it belongs either= in pcp-base or perhaps more likely in a separate spec that's not DHCP speci= fic. E.g., if I manually configure one or more names, the same behavior shoul= d apply. 6) Section 5.2 says: "The DHCPv4 client MUST verify that the option length does not exceed 255 octets [RFC1035])." What does this mean? The length field is only 1 byte so cannot contain a value larger than 255 anyway. So what exactly is a client supposed t= o "verify" here? -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dav= e > Thaler > Sent: Wednesday, July 18, 2012 2:21 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >=20 > As discussed at last IETF, the authors believe that all issues raised so = far have > been addressed. No new issues have been raised since then, so this messa= ge > begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. >=20 > This call would normally conclude in two weeks but that is during IETF we= ek, so > the last call is extended to conclude at the end of IETF (as of the Frida= y PCP > meeting). >=20 > We also agreed in Vancouver that this last call will be cross-posted to t= he DHC > list, hence cc'ing the DHC WG. >=20 > We need at least 5 reviewers. Please send comments to the list. >=20 > Thanks, > -Dave Thaler >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Thu Jul 26 14:57:46 2012 Return-Path: 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 5AF6F11E80BE for ; Thu, 26 Jul 2012 14:57:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...W604.wingroup.windeploy.ntdev.microsoft.com>\n X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 j1-5vfC1WlIs for ; Thu, 26 Jul 2012 14:57:45 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC911E80BD for ; Thu, 26 Jul 2012 14:57:45 -0700 (PDT) Received: from mail214-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jul 2012 21:57:44 +0000 Received: from mail214-va3 (localhost [127.0.0.1]) by mail214-va3-R.bigfish.com (Postfix) with ESMTP id ADF5EA0030C; Thu, 26 Jul 2012 21:57:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail214-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail214-va3 (localhost.localdomain [127.0.0.1]) by mail214-va3 (MessageSwitch) id 1343339862560904_26694; Thu, 26 Jul 2012 21:57:42 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.235]) by mail214-va3.bigfish.com (Postfix) with ESMTP id 86B741A004B; Thu, 26 Jul 2012 21:57:42 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jul 2012 21:57:37 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 26 Jul 2012 21:57:35 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Thu, 26 Jul 2012 14:57:35 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUA= Date: Thu, 26 Jul 2012 21:57:34 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B72358D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dhc@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:57:46 -0000 Missed responding to section 7 before sending... 7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is likel= y to be resolved to IPv4 address(es)." I don't think I'd agree with that assumption. If I put a DNS name in = the option, it'll be resolved to whatever records are in DNS of a type the client q= ueries for. The document currently doesn't say what type(s) to query for (A vs AAAA)= . Per my comment on 2, I believe the types to query for should be independ= ent of how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever els= e). =20 "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" By the same reasoning as my previous comment above, it may also be resol= ved to IPv4 addresses. If I have a dual-stack PCP server, I should be able= to put the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather than requiring me to have two separate names for the same server. 8) Pursuant to a discussion I've been having with some folks on draft-iab-identifier-comparison section 3.1.1 and some changes I'll be = making to it as a result, it got me thinking. I'm thinking it would be good to h= ave a short subsection on Guidance to Administrators on what to configure in their = DHCP server to return in these options, or more importantly, what not to con= figure. Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" wou= ld all be a bad idea to configure (unless you specified how they're to be = interpreted which is an option, though probably not the most expedient one). I'm = still strongly in favor of retaining the fact that it's a string that can be passed to= name resolution APIs, but that means it's best to avoid strings that are int= erpreted differently by different such APIs. 9) On the same point, Section 4.2 currently states: "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, each included Name is passed to the name resolution library (e.g., Section 6.1.1 of [RFC1123] or [RFC6055])" The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular a= re=20 problematic because as worded a client that chose not to support IP lite= rals would be legal, and it would try to resolve "10.11.12.13" in DNS, which = we don't want. Surprising (as draft-iab-identifier-comparison already poi= nts out), even [RFC1123] allows this to be optional (a "SHOULD") in: "The host SH= OULD check the string syntactically for a dotted-decimal number before looking it u= p in=20 the Domain Name System." Instead it's important here to require that the client be able to=20 use IP literals. Most name resolution APIs (gethostbyname, getaddrinfo= , etc.) all meet that criteria. -Dave > -----Original Message----- > From: Dave Thaler > Sent: Thursday, July 26, 2012 2:32 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Here's my personal comments on draft -03... I have a few editorial nits = I'll just > send to the authors. >=20 > 1) I agree with the conclusion of the rationale but the sentence > "DHC WG's position is this flexibility have some drawbacks such as i= nducing > errors." > isn't intelligible. What does "inducing errors" mean? Either expla= in or > remove. >=20 > 2) The text on what to do with a name conveyed in an option is duplicated= in > Section 4.2 and 5.2. I'd prefer that this be specified only once, t= o avoid > opportunities for discrepancies. That is, section 4.2's first two p= aragraphs > are > fine, as are the first 1 1/2 paragraphs of 5.2, since those are about= how to > get > the name out of the option. The rest isn't DHCPv4 or DHCPv6 specif= ic and > should be in its own subsection. >=20 > 3) Re "It is RECOMMENDED to associate a validity lifetime with any addres= s > resulting from resolving the Name". The text should be more specific= about > what the validity lifetime should be. If the name is resolved in DN= S, I'd > say the validity lifetime should be the TTL of the DNS record. >=20 > 4) Re "When an > application issues a PCP request to a PCP Server, the source addres= s > of the request MUST be among those assigned on the interface to whi= ch > the destination PCP Server is bound. >=20 > This doesn't belong in a DHCP-specific document, it's out of scope. = That's > the job of the pcp-base spec. >=20 > 5) Same as point 4, but for all of section 6. In my view it belongs eith= er in > pcp-base or perhaps more likely in a separate spec that's not DHCP spe= cific. > E.g., if I manually configure one or more names, the same behavior sho= uld > apply. >=20 > 6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." >=20 > What does this mean? The length field is only 1 byte so cannot conta= in > a value larger than 255 anyway. So what exactly is a client supposed= to > "verify" here? >=20 > -Dave >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dave Thaler > > Sent: Wednesday, July 18, 2012 2:21 PM > > To: pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > As discussed at last IETF, the authors believe that all issues raised > > so far have been addressed. No new issues have been raised since > > then, so this message begins a Working Group Last Call on draft-ietf-pc= p- > dhcp-03. > > > > This call would normally conclude in two weeks but that is during IETF > > week, so the last call is extended to conclude at the end of IETF (as > > of the Friday PCP meeting). > > > > We also agreed in Vancouver that this last call will be cross-posted > > to the DHC list, hence cc'ing the DHC WG. > > > > We need at least 5 reviewers. Please send comments to the list. > > > > Thanks, > > -Dave Thaler > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From volz@cisco.com Thu Jul 19 09:08:00 2012 Return-Path: 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 0EC8521F87BF; Thu, 19 Jul 2012 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 TTNE7FSlADDc; Thu, 19 Jul 2012 09:07:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BA66321F87DC; Thu, 19 Jul 2012 09:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=3900; q=dns/txt; s=iport; t=1342714132; x=1343923732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TZn7Iq93d0RNs/YY9qDESm2XaZdyafxJPSmQoUWPsec=; b=HOY8gWDcb9UUWqs6/7984VjHBneE0TCN5DG/ZjXoM+DEx3oMWtR9EViI AVyC+tvq+10TQ4xoMiRmxiubxqvipn58bsau96pY0Mne/xs/fhmlCb+Bw aVHFmsVQAtsYBCU7ISqVP7VvqtHWgcDQR1hTJIvIEctb1twPcGMIwuC1B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOovCFCtJXG9/2dsb2JhbABFuUCBB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwQBAQsUCQcnCxQJCAEBBAENBQgah2sLnkKgBASLTIYwYAOjZ4Fmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103509158" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jul 2012 16:08:42 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6JG8gGl025295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 16:08:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 11:08:42 -0500 From: "Bernie Volz (volz)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwABZYWwACWnwdA= Date: Thu, 19 Jul 2012 16:08:41 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E026F74@xmb-rcd-x04.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.72] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--43.652000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 26 Jul 2012 16:16:50 -0700 Cc: "dhcwg@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:08:00 -0000 The document seems OK (reviewing from the DHC WG perspective). Minor nits: 1) 2. Terminology o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. o DHCP client (or client) denotes a node that initiates requests to obtain configuration parameters from one or more DHCP servers [RFC3315]. o DHCP server (or server) refers to a node that responds to requests from DHCP clients [RFC3315]. Why are DHCP client / DHCP server just RFC 3315 and use of "DHCP" here impl= ies RFC 2131 and 3315 from the earlier terminology. 2) 4.1. Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PCP_SERVER | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : PCP Server Domain Name : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PCP Server Name DHCPv6 Option The fields of the option shown in Figure 1 are as follows: o Option-code: OPTION_PCP_SERVER (TBA, see Section 9.1) o Option-length: Length of the 'PCP Server Domain Name' field in octets. o PCP Server Domain Name: The domain name of the PCP Server to be used by the PCP Client. The domain name is encoded as specified in Section 8 of [RFC3315]. The OPTION_PCP_SERVER option can include multiple PCP Server Domain Names; each Name is treated as a separate PCP Server. Would it not be appropriate to change the "PCP Server Domain Name" to be "P= CP Server Domain Name(s)"? And make the description clear that it can be on= e or more rather than adding this later (where it easily might be missed). The same applies to the DHCPv4 option (section 5.1). 3) Be nice if the DHCPv4 domain name encoding clarified that compression was n= ot allowed (though RFC 1035 section 3.1 does not say anything about that to= pic)? Perhaps use the RFC 3315 Section 8 text: A domain name, or list of domain names, in DHCP MUST NOT be stored in c= ompressed form, as described in section 4.1.4 of RFC 1035. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= ave Thaler Sent: Wednesday, July 18, 2012 5:50 PM To: pcp@ietf.org Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Correcting DHC WG email address. > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of=20 > Dave Thaler > Sent: Wednesday, July 18, 2012 2:21 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >=20 > As discussed at last IETF, the authors believe that all issues raised=20 > so far have been addressed. No new issues have been raised since=20 > then, so this message begins a Working Group Last Call on draft-ietf-pcp-= dhcp-03. >=20 > This call would normally conclude in two weeks but that is during IETF=20 > week, so the last call is extended to conclude at the end of IETF (as=20 > of the Friday PCP meeting). >=20 > We also agreed in Vancouver that this last call will be cross-posted=20 > to the DHC list, hence cc'ing the DHC WG. >=20 > We need at least 5 reviewers. Please send comments to the list. >=20 > Thanks, > -Dave Thaler >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From ietfdbh@comcast.net Thu Jul 19 11:20:52 2012 Return-Path: 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 4991C21F86C1 for ; Thu, 19 Jul 2012 11:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mzjZ7jDpZkOc for ; Thu, 19 Jul 2012 11:20:51 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 399D921F8694 for ; Thu, 19 Jul 2012 11:20:51 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta10.emeryville.ca.mail.comcast.net with comcast id cG671j0051Y3wxoAAJMlG1; Thu, 19 Jul 2012 18:21:45 +0000 Received: from [192.168.1.67] ([184.39.8.144]) by omta15.emeryville.ca.mail.comcast.net with comcast id cJLu1j00K36TH608bJM1R5; Thu, 19 Jul 2012 18:21:39 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 19 Jul 2012 14:20:53 -0400 From: David Harrington To: Sam Hartman , Simon Perreault Message-ID: Thread-Topic: [BEHAVE] [pcp] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 26 Jul 2012 16:16:50 -0700 Cc: pcp@ietf.org, "behave@ietf.org" , IETF Subject: Re: [pcp] [BEHAVE] Fwd: Re: Martin Stiemerling's Discuss on draft-ietf-behave-lsn-requirements-08: (with DISCUSS and COMMENT) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:20:52 -0000 On 7/19/12 9:02 AM, "Sam Hartman" wrote: >I think that behave-lsn-requirements is far more useful if it names a >specific protocol by name. By endorcing one of our middlebox protocols, >we encourage interoperability. If we don't pick a protocol by name, we >don't really promote interoperability. It's not useful if your CGN does >midcom and my client does PCP and I'm your customer. The assumption >behind LSN-requirements is that the CGN and the CPE are not >controlled/purchased/whatever by the same entity. So, mandating a >specific protocol seems desirable. The IETF could mandate a specific protocol to try to ensure interoperability, but doing this takes the decision out of the responsibility of the deployer to choose the best solution for the deployment environment, and out of the responsibility of the vendor to best meet their customers' demands. Some vendors already support an SNMP-based environment, and a CGN-NAT-MIB might best meet their needs. Some vendors might support a Netconf environment and desire a Netconf-based configuration solution. Some vendors already use AAA widely to control their environment, and Diameter NAT control might be preferable. Some vendors might be implementing the (not yet IETF-approved) PCP standard, and would prefer that solution. > >I think that the behave WG is the right place to make that decision. >The IETF as a whole should be able to second guess behave, but we should >need a fairly high bar for doing so. I think that **within IETF**, behave wg might have the right expertise to make this decision (technical comparison of middlebox protocols by protocol designers). Of course, no current WG has much input from proponents of the original MIDCOM WG strategy, and most Diameter proponents are not very active in behave wg. And behave DOES have an overlap between the PCP developers and behave solutions. So behave WG might be rather biased toward a specific solution (not that the bias is necessarily bad, but the bias should be recognized). Of course, if CGN is only an ipv4 exit strategy, as is asserted, then sunset4 would seem the appropriate choice, so we have one consistent ipv4 exit strategy. We already recognize that different wgs are developing ipv4 exit strategies that conflict; that's why a sunset4 wg has been approved. And if CGN **is** only for ipv4-sunsetting, a "this IETF recommendation becomes obsolete on such-and-such a date" might be appropriate for lsn-requirements. The right expertise might be in the sunset4 wg, which might have increased operator input about a complete ipv4/ipv6 transition deployment strategy rather than middlebox protocol design comparisons by middlebox protocol designers. While I would love to see consensus for a good interoperable solution, and would support ***A*** standard that says "to be compliant to THIS specification, use THIS middlebox proposal", I hesitate to say "this is the ONLY middlebox standard that is recommended or usable within IETF standards" - especially if that only recommended part has little or no actual field experience to back up the RECOMMENDED, and little or no documentation has been done of the suitability/useability in various environments of the existing IETF standards that would become NOT RECOMMENDED. I think the right place to make the decision about which midcom solution should be used in a particular environment is in the market. My cable provider lets me purchase/control my cable router (to a degree), but only certain routers are supported. I can choose which cable router offers the additional functionality/control I want for my environment. My provider has input to the decision, and so do I (to a limited extent). Of course, to a limited extent, I can also choose a different provider or get less support from my provider. > >The claim that PCP is the IETF's only protocol in this space does seem a >little bit on the wishful thinking side of things. So, I could >understand if the IESG wanted to ask behave to spend a little more time >on the question. +1 (or ask sunset4 to spend a little more time on the question). David Harrington ietfdbh@comcast.net +1-603-828-1401 From mohamed.boucadair@orange.com Fri Jul 27 01:25:05 2012 Return-Path: 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 63B3821F849C; Fri, 27 Jul 2012 01:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] 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 ndYb0iQRCAMh; Fri, 27 Jul 2012 01:25:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6178421F8497; Fri, 27 Jul 2012 01:25:04 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 986703B41E0; Fri, 27 Jul 2012 10:25:03 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7A974238059; Fri, 27 Jul 2012 10:25:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 27 Jul 2012 10:24:57 +0200 From: To: "Bernie Volz (volz)" , Dave Thaler , "pcp@ietf.org" Date: Fri, 27 Jul 2012 10:24:56 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwABZYWwACWnwdABgXOiAA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E563@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B70B380@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E026F74@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E026F74@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.65415 Cc: "dhcwg@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 08:25:05 -0000 Dear Bernie, Thank you for the review.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Bernie Volz (volz) >Envoy=E9 : jeudi 19 juillet 2012 18:09 >=C0 : Dave Thaler; pcp@ietf.org >Cc : dhcwg@ietf.org >Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > >The document seems OK (reviewing from the DHC WG perspective). > >Minor nits: > >1) > >2. Terminology > o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. > o DHCP client (or client) denotes a node that initiates requests to > obtain configuration parameters from one or more DHCP servers > [RFC3315]. > o DHCP server (or server) refers to a node that responds=20 >to requests > from DHCP clients [RFC3315]. > >Why are DHCP client / DHCP server just RFC 3315 and use of=20 >"DHCP" here implies RFC 2131 and 3315 from the earlier terminology. > Med: Fixed. The new text is:=20 o DHCP client (or client) denotes a node that initiates requests to obtain configuration parameters from one or more DHCP servers. o DHCP server (or server) refers to a node that responds to requests from DHCP clients. >2) > >4.1. Format > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_PCP_SERVER | Option-length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : PCP Server Domain Name : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: PCP Server Name DHCPv6 Option > > The fields of the option shown in Figure 1 are as follows: > > o Option-code: OPTION_PCP_SERVER (TBA, see Section 9.1) > o Option-length: Length of the 'PCP Server Domain Name' field in > octets. > o PCP Server Domain Name: The domain name of the PCP Server to be > used by the PCP Client. The domain name is encoded as specified > in Section 8 of [RFC3315]. > > The OPTION_PCP_SERVER option can include multiple PCP Server Domain > Names; each Name is treated as a separate PCP Server. > >Would it not be appropriate to change the "PCP Server Domain=20 >Name" to be "PCP Server Domain Name(s)"? And make the=20 >description clear that it can be one or more rather than=20 >adding this later (where it easily might be missed). > >The same applies to the DHCPv4 option (section 5.1). Med: Done. The new text is: o PCP Server Domain Name(s): The domain name s) of the PCP Server to be used by the PCP Client. The OPTION_PCP_SERVER option can include multiple PCP Server Domain Names; each Name is treated as a separate PCP Server. The domain name(s) is encoded as specified in Section 8 of [RFC3315]. And=20 o PCP Server Domain Name(s): The domain name(s) of the PCP Server to be used by the PCP Client when issuing PCP messages. The OPTION_PCP_SERVER option can include multiple PCP Server Domain Names; each Name is treated as a separate PCP Server. The encoding of the domain name(s) is described in Section 3.1 of [RFC1035]. =20 > >3) > >Be nice if the DHCPv4 domain name encoding clarified that=20 >compression was not allowed (though RFC 1035 section 3.1 does=20 >not say anything about that topic)? Perhaps use the RFC 3315=20 >Section 8 text: > > A domain name, or list of domain names, in DHCP MUST NOT=20 >be stored in compressed form, as described in > section 4.1.4 of RFC 1035. Med: I added this sentence to Section 5:=20 "The domain name(s) MUST NOT be stored in compressed form, as described in Section 4.1.4 of [RFC1035]." > > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >On Behalf Of Dave Thaler >Sent: Wednesday, July 18, 2012 5:50 PM >To: pcp@ietf.org >Cc: dhcwg@ietf.org >Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 > >Correcting DHC WG email address. > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of=20 >> Dave Thaler >> Sent: Wednesday, July 18, 2012 2:21 PM >> To: pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> As discussed at last IETF, the authors believe that all=20 >issues raised=20 >> so far have been addressed. No new issues have been raised since=20 >> then, so this message begins a Working Group Last Call on=20 >draft-ietf-pcp-dhcp-03. >>=20 >> This call would normally conclude in two weeks but that is=20 >during IETF=20 >> week, so the last call is extended to conclude at the end of=20 >IETF (as=20 >> of the Friday PCP meeting). >>=20 >> We also agreed in Vancouver that this last call will be cross-posted=20 >> to the DHC list, hence cc'ing the DHC WG. >>=20 >> We need at least 5 reviewers. Please send comments to the list. >>=20 >> Thanks, >> -Dave Thaler >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From mohamed.boucadair@orange.com Fri Jul 27 02:01:26 2012 Return-Path: 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 249B121F860B for ; Fri, 27 Jul 2012 02:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] 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 E5qgqOBKikk8 for ; Fri, 27 Jul 2012 02:01:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2E05421F8609 for ; Fri, 27 Jul 2012 02:01:25 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id C8E8E324188; Fri, 27 Jul 2012 11:01:23 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id AB6A1238056; Fri, 27 Jul 2012 11:01:23 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 27 Jul 2012 11:01:17 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Fri, 27 Jul 2012 11:01:15 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QABedF2A= Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E586@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7234D2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7234D2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.83316 Cc: "dhc@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:01:26 -0000 Dear Dave, Thank you for the review.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : jeudi 26 juillet 2012 23:32 >=C0 : pcp@ietf.org >Cc : dhc@ietf.org >Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > >Here's my personal comments on draft -03... I have a few=20 >editorial nits I'll >just send to the authors. > >1) I agree with the conclusion of the rationale but the sentence > "DHC WG's position is this flexibility have some=20 >drawbacks such as inducing > errors." > isn't intelligible. What does "inducing errors" mean? =20 >Either explain or remove. Med: This is point is discussed in detail here: http://tools.ietf.org/html/= draft-ietf-dhc-option-guidelines-08#section-7. Would you be fine if we add = a reference to that draft? > >2) The text on what to do with a name conveyed in an option is=20 >duplicated in=20 > Section 4.2 and 5.2. I'd prefer that this be specified=20 >only once, to avoid > opportunities for discrepancies. That is, section 4.2's=20 >first two paragraphs are > fine, as are the first 1 1/2 paragraphs of 5.2, since=20 >those are about how to get > the name out of the option. The rest isn't DHCPv4 or=20 >DHCPv6 specific and > should be in its own subsection. Med: There is some duplication there but it does not harm IMHO. I prefer to= maintain the text as it is. > >3) Re "It is RECOMMENDED to associate a validity lifetime with=20 >any address > resulting from resolving the Name". The text should be=20 >more specific about > what the validity lifetime should be. If the name is=20 >resolved in DNS, I'd > say the validity lifetime should be the TTL of the DNS record. > Med: I updated the text as follows: It is RECOMMENDED to associate a validity lifetime (e.g., TTL of DNS record if the Name is resolved using DNS) with any address resulting from resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv4 option when stored in a local name resolution cache.=20 Is this better? >4) Re "When an > application issues a PCP request to a PCP Server, the=20 >source address > of the request MUST be among those assigned on the=20 >interface to which > the destination PCP Server is bound. > > This doesn't belong in a DHCP-specific document, it's out=20 >of scope. That's > the job of the pcp-base spec. =20 > Med: I removed that sentence. >5) Same as point 4, but for all of section 6. In my view it=20 >belongs either in > pcp-base or perhaps more likely in a separate spec that's=20 >not DHCP specific. > E.g., if I manually configure one or more names, the same=20 >behavior should apply. Med: Dave, Section 6 is there because you requested it: see http://www.ietf= .org/mail-archive/web/pcp/current/msg01793.html. Since we have the text now= , I vote for keeping it. No need to create another dependency with another = document to come.=20 > >6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." > > What does this mean? The length field is only 1 byte so=20 >cannot contain > a value larger than 255 anyway. So what exactly is a=20 >client supposed to > "verify" here? Med: The text does not talk about the length of the field but the value it = carries.=20 > >-Dave > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of Dave >> Thaler >> Sent: Wednesday, July 18, 2012 2:21 PM >> To: pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> As discussed at last IETF, the authors believe that all=20 >issues raised so far have >> been addressed. No new issues have been raised since then,=20 >so this message >> begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. >>=20 >> This call would normally conclude in two weeks but that is=20 >during IETF week, so >> the last call is extended to conclude at the end of IETF (as=20 >of the Friday PCP >> meeting). >>=20 >> We also agreed in Vancouver that this last call will be=20 >cross-posted to the DHC >> list, hence cc'ing the DHC WG. >>=20 >> We need at least 5 reviewers. Please send comments to the list. >>=20 >> Thanks, >> -Dave Thaler >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From mohamed.boucadair@orange.com Fri Jul 27 02:21:28 2012 Return-Path: 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 375CC21F85F6 for ; Fri, 27 Jul 2012 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] 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 yeOqF+SF5twm for ; Fri, 27 Jul 2012 02:21:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id F382B21F85F4 for ; Fri, 27 Jul 2012 02:21:26 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2BB8F22C186; Fri, 27 Jul 2012 11:21:26 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0F39923804B; Fri, 27 Jul 2012 11:21:26 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 27 Jul 2012 11:21:19 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Fri, 27 Jul 2012 11:21:18 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAF+rlAA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E59E@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B72358D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B72358D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.83316 Cc: "dhc@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 09:21:28 -0000 Re-, See inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : jeudi 26 juillet 2012 23:58 >=C0 : pcp@ietf.org >Cc : dhc@ietf.org >Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > >Missed responding to section 7 before sending... > >7) Re "A PCP Server configured using OPTION_PCP_SERVER over=20 >DHCPv4 is likely > to be resolved to IPv4 address(es)." > I don't think I'd agree with that assumption. If I put a=20 >DNS name in the option, > it'll be resolved to whatever records are in DNS of a type=20 >the client queries for. > The document currently doesn't say what type(s) to query=20 >for (A vs AAAA). > Per my comment on 2, I believe the types to query for=20 >should be independent of > how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or=20 >whatever else). > =20 > "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be > resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" > By the same reasoning as my previous comment above, it may=20 >also be resolved > to IPv4 addresses. If I have a dual-stack PCP server, I=20 >should be able to put > the same DNS name in both a DHCPv4 option and a DHCPv6=20 >option, rather > than requiring me to have two separate names for the same server. > Med: Makes sense to. I removed the first two sentences.=20 >8) Pursuant to a discussion I've been having with some folks on > draft-iab-identifier-comparison section 3.1.1 and some=20 >changes I'll be making to > it as a result, it got me thinking. I'm thinking it would=20 >be good to have a short > subsection on Guidance to Administrators on what to=20 >configure in their DHCP > server to return in these options, or more importantly,=20 >what not to configure. > Specifically, strings like "10.0.258", "0xA000001", and=20 >"012.0x102" would > all be a bad idea to configure (unless you specified how=20 >they're to be interpreted > which is an option, though probably not the most expedient=20 >one). I'm still strongly > in favor of retaining the fact that it's a string that can=20 >be passed to name > resolution APIs, but that means it's best to avoid strings=20 >that are interpreted > differently by different such APIs. Med: I have no problem to add such sub-section if you provide a text propos= al. Saying that, I think it would be useful to have such guidelines elabora= ted in a generic document not a pcp-specific one. > >9) On the same point, Section 4.2 currently states: > "Once each Name conveyed in the OPTION_PCP_SERVER option is=20 >validated, > each included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055])" > The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in=20 >particular are=20 > problematic because as worded a client that chose not to=20 >support IP literals > would be legal, and it would try to resolve "10.11.12.13"=20 >in DNS, which we > don't want. Surprising (as=20 >draft-iab-identifier-comparison already points out), > even [RFC1123] allows this to be optional (a "SHOULD") in: =20 >"The host SHOULD check > the string syntactically for a dotted-decimal number before=20 >looking it up in=20 > the Domain Name System." > > Instead it's important here to require that the client be able to=20 > use IP literals. Most name resolution APIs=20 >(gethostbyname, getaddrinfo, > etc.) all meet that criteria. Med: "e.g." is there to list example of name resolution library. As for you= r point about the support of IP literals, this is explicitly part of the de= finition of "Name" as defined in this document.=20 > >-Dave > >> -----Original Message----- >> From: Dave Thaler >> Sent: Thursday, July 26, 2012 2:32 PM >> To: pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Here's my personal comments on draft -03... I have a few=20 >editorial nits I'll just >> send to the authors. >>=20 >> 1) I agree with the conclusion of the rationale but the sentence >> "DHC WG's position is this flexibility have some=20 >drawbacks such as inducing >> errors." >> isn't intelligible. What does "inducing errors" mean? =20 >Either explain or >> remove. >>=20 >> 2) The text on what to do with a name conveyed in an option=20 >is duplicated in >> Section 4.2 and 5.2. I'd prefer that this be specified=20 >only once, to avoid >> opportunities for discrepancies. That is, section=20 >4.2's first two paragraphs >> are >> fine, as are the first 1 1/2 paragraphs of 5.2, since=20 >those are about how to >> get >> the name out of the option. The rest isn't DHCPv4 or=20 >DHCPv6 specific and >> should be in its own subsection. >>=20 >> 3) Re "It is RECOMMENDED to associate a validity lifetime=20 >with any address >> resulting from resolving the Name". The text should be=20 >more specific about >> what the validity lifetime should be. If the name is=20 >resolved in DNS, I'd >> say the validity lifetime should be the TTL of the DNS record. >>=20 >> 4) Re "When an >> application issues a PCP request to a PCP Server, the=20 >source address >> of the request MUST be among those assigned on the=20 >interface to which >> the destination PCP Server is bound. >>=20 >> This doesn't belong in a DHCP-specific document, it's out=20 >of scope. That's >> the job of the pcp-base spec. >>=20 >> 5) Same as point 4, but for all of section 6. In my view it=20 >belongs either in >> pcp-base or perhaps more likely in a separate spec that's=20 >not DHCP specific. >> E.g., if I manually configure one or more names, the same=20 >behavior should >> apply. >>=20 >> 6) Section 5.2 says: >> "The DHCPv4 client MUST verify that the >> option length does not exceed 255 octets [RFC1035])." >>=20 >> What does this mean? The length field is only 1 byte so=20 >cannot contain >> a value larger than 255 anyway. So what exactly is a=20 >client supposed to >> "verify" here? >>=20 >> -Dave >>=20 >> > -----Original Message----- >> > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=20 >On Behalf Of >> > Dave Thaler >> > Sent: Wednesday, July 18, 2012 2:21 PM >> > To: pcp@ietf.org >> > Cc: dhc@ietf.org >> > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >> > >> > As discussed at last IETF, the authors believe that all=20 >issues raised >> > so far have been addressed. No new issues have been raised since >> > then, so this message begins a Working Group Last Call on=20 >draft-ietf-pcp- >> dhcp-03. >> > >> > This call would normally conclude in two weeks but that is=20 >during IETF >> > week, so the last call is extended to conclude at the end=20 >of IETF (as >> > of the Friday PCP meeting). >> > >> > We also agreed in Vancouver that this last call will be=20 >cross-posted >> > to the DHC list, hence cc'ing the DHC WG. >> > >> > We need at least 5 reviewers. Please send comments to the list. >> > >> > Thanks, >> > -Dave Thaler >> > >> > _______________________________________________ >> > pcp mailing list >> > pcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From dthaler@microsoft.com Fri Jul 27 12:06:38 2012 Return-Path: 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 0BB3C21F86DF; Fri, 27 Jul 2012 12:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 GAltNseZbBtD; Fri, 27 Jul 2012 12:06:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8421F86E8; Fri, 27 Jul 2012 12:06:36 -0700 (PDT) Received: from mail7-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 19:06:35 +0000 Received: from mail7-am1 (localhost [127.0.0.1]) by mail7-am1-R.bigfish.com (Postfix) with ESMTP id 22D0522021B; Fri, 27 Jul 2012 19:06:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail7-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail7-am1 (localhost.localdomain [127.0.0.1]) by mail7-am1 (MessageSwitch) id 1343415991799264_24655; Fri, 27 Jul 2012 19:06:31 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.242]) by mail7-am1.bigfish.com (Postfix) with ESMTP id C1359320188; Fri, 27 Jul 2012 19:06:31 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 19:06:30 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 27 Jul 2012 19:06:27 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 12:06:27 -0700 From: Dave Thaler To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jA= Date: Fri, 27 Jul 2012 19:06:27 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 19:06:38 -0000 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Friday, July 27, 2012 7:47 AM > To: Dave Thaler; dhcwg@ietf.org > Cc: pcp@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Dave: >=20 > As the options as defined contain a domain name (encoded per RFC 1035) ar= e > address literals really appropriate? This also has consequences for confi= guring > the option data in the servers. And, it seems rather bad to take an encod= ed > name, convert it to a string, only to convert it back into an encoded nam= e. But, > alas, that is likely given the common APIs. > > Also, given that RFC 1035 section 3.1 states: >=20 > Since every domain name ends with the null label of > the root, a domain name is terminated by a length byte of zero. >=20 > And the option is to accommodate a list of domain names (knowing that eac= h > terminates in the null label makes it possible to separate them), how do = you > propose that literals (10.1.2.3) be encoded so that it not end up as the = domain > name "10.1.2.3.". >=20 > Perhaps there is a convention used to do this somewhere? (I admit I haven= 't > looked at draft-iab-identifier-comparison carefully.) (draft-iab-identifier-comparison isn't relevant to that particular question= .) The WG goal was to be able to configure a set of strings that can be passed= to an API such as getaddrinfo() where the string can be either an IP literal o= r a domain name. I take your point as saying that using the encoding defined in RFC 1035 section 3.1 isn't sufficient without an additional statement that the trailing dot should be removed. The only other alternative I see would be to not use that encoding but define some other encoding. > When reviewing this and commenting the other day, I originally had though= t > about commenting on the rather strict rules as to how the results of DNS > queries could be used and was thinking that it might be appropriate to re= lax > them some. Just doing normal DNS lookups and using the results (AAAA if v= 6 is > available, A if v4 is available, etc.) would likely make implementing thi= s much > easier and require less specialized code. Right. I think the goal should be to minimize the amount of processing th= e client has to do with the option contents... just pass it to getaddrinfo() = or equivalent was what the WG had discussed. > > 6) Section 5.2 says: > > "The DHCPv4 client MUST verify that the > > option length does not exceed 255 octets [RFC1035])." >=20 > Good catch. This should be removed as we have the ability to support long= v4 > options - see RFC 3396. >=20 > Note that per section 4 of this RFC: >=20 > Let us divide all DHCP options into two categories - those that, by > definition, require implementation of the mechanisms defined in this > document, and those that do not. We will refer to the former as > concatenation-requiring options, and the latter as non- > concatenation-requiring options. In order for an option to be a > concatenation-requiring option, the protocol specification that > defines that option must require implementation of option splitting > and option concatenation as described in this document, by > specifically referencing this document. >=20 > So the draft should reference RFC 3396 and indicate that this is a > concatenation-requiring option. Agree. -Dave >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Thursday, July 26, 2012 5:59 PM > To: dhcwg@ietf.org > Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 >=20 > I keep mangling the WG mailing list address, so forwarding. >=20 > -----Original Message----- > From: Dave Thaler > Sent: Thursday, July 26, 2012 2:58 PM > To: 'pcp@ietf.org' > Cc: 'dhc@ietf.org' > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Missed responding to section 7 before sending... >=20 > 7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is > likely > to be resolved to IPv4 address(es)." > I don't think I'd agree with that assumption. If I put a DNS name i= n the > option, > it'll be resolved to whatever records are in DNS of a type the client= queries > for. > The document currently doesn't say what type(s) to query for (A vs AAA= A). > Per my comment on 2, I believe the types to query for should be indepe= ndent > of > how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever > else). >=20 > "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be > resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" > By the same reasoning as my previous comment above, it may also be > resolved > to IPv4 addresses. If I have a dual-stack PCP server, I should be ab= le to put > the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather > than requiring me to have two separate names for the same server. >=20 > 8) Pursuant to a discussion I've been having with some folks on > draft-iab-identifier-comparison section 3.1.1 and some changes I'll b= e > making to > it as a result, it got me thinking. I'm thinking it would be good to= have a > short > subsection on Guidance to Administrators on what to configure in thei= r DHCP > server to return in these options, or more importantly, what not to c= onfigure. > Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" w= ould > all be a bad idea to configure (unless you specified how they're to b= e > interpreted > which is an option, though probably not the most expedient one). I'= m still > strongly > in favor of retaining the fact that it's a string that can be passed = to name > resolution APIs, but that means it's best to avoid strings that are i= nterpreted > differently by different such APIs. >=20 > 9) On the same point, Section 4.2 currently states: > "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, > each included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055])" > The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular= are > problematic because as worded a client that chose not to support IP li= terals > would be legal, and it would try to resolve "10.11.12.13" in DNS, whic= h we > don't want. Surprising (as draft-iab-identifier-comparison already p= oints > out), > even [RFC1123] allows this to be optional (a "SHOULD") in: "The host > SHOULD check > the string syntactically for a dotted-decimal number before looking it= up in > the Domain Name System." >=20 > Instead it's important here to require that the client be able to > use IP literals. Most name resolution APIs (gethostbyname, getaddrin= fo, > etc.) all meet that criteria. >=20 > -Dave >=20 > > -----Original Message----- > > From: Dave Thaler > > Sent: Thursday, July 26, 2012 2:32 PM > > To: pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 > > > > Here's my personal comments on draft -03... I have a few editorial > > nits I'll just send to the authors. > > > > 1) I agree with the conclusion of the rationale but the sentence > > "DHC WG's position is this flexibility have some drawbacks such as > inducing > > errors." > > isn't intelligible. What does "inducing errors" mean? Either exp= lain or > > remove. > > > > 2) The text on what to do with a name conveyed in an option is duplicat= ed in > > Section 4.2 and 5.2. I'd prefer that this be specified only once,= to avoid > > opportunities for discrepancies. That is, section 4.2's first two= paragraphs > > are > > fine, as are the first 1 1/2 paragraphs of 5.2, since those are > > about how to get > > the name out of the option. The rest isn't DHCPv4 or DHCPv6 spec= ific and > > should be in its own subsection. > > > > 3) Re "It is RECOMMENDED to associate a validity lifetime with any addr= ess > > resulting from resolving the Name". The text should be more specif= ic > about > > what the validity lifetime should be. If the name is resolved in = DNS, I'd > > say the validity lifetime should be the TTL of the DNS record. > > > > 4) Re "When an > > application issues a PCP request to a PCP Server, the source addr= ess > > of the request MUST be among those assigned on the interface to w= hich > > the destination PCP Server is bound. > > > > This doesn't belong in a DHCP-specific document, it's out of scope. = That's > > the job of the pcp-base spec. > > > > 5) Same as point 4, but for all of section 6. In my view it belongs ei= ther in > > pcp-base or perhaps more likely in a separate spec that's not DHCP s= pecific. > > E.g., if I manually configure one or more names, the same behavior > > should apply. > > > > 6) Section 5.2 says: > > "The DHCPv4 client MUST verify that the > > option length does not exceed 255 octets [RFC1035])." > > > > What does this mean? The length field is only 1 byte so cannot con= tain > > a value larger than 255 anyway. So what exactly is a client suppos= ed to > > "verify" here? > > > > -Dave > > > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > > > Of Dave Thaler > > > Sent: Wednesday, July 18, 2012 2:21 PM > > > To: pcp@ietf.org > > > Cc: dhc@ietf.org > > > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > > > As discussed at last IETF, the authors believe that all issues > > > raised so far have been addressed. No new issues have been raised > > > since then, so this message begins a Working Group Last Call on > > > draft-ietf-pcp- > > dhcp-03. > > > > > > This call would normally conclude in two weeks but that is during > > > IETF week, so the last call is extended to conclude at the end of > > > IETF (as of the Friday PCP meeting). > > > > > > We also agreed in Vancouver that this last call will be cross-posted > > > to the DHC list, hence cc'ing the DHC WG. > > > > > > We need at least 5 reviewers. Please send comments to the list. > > > > > > Thanks, > > > -Dave Thaler > > > > > > _______________________________________________ > > > pcp mailing list > > > pcp@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From dthaler@microsoft.com Fri Jul 27 12:19:13 2012 Return-Path: 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 2A62011E80C0 for ; Fri, 27 Jul 2012 12:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Vr0S17FdUmb3 for ; Fri, 27 Jul 2012 12:19:12 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 364E311E80D6 for ; Fri, 27 Jul 2012 12:19:11 -0700 (PDT) Received: from mail64-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 19:19:10 +0000 Received: from mail64-db3 (localhost [127.0.0.1]) by mail64-db3-R.bigfish.com (Postfix) with ESMTP id 611E6A04C9; Fri, 27 Jul 2012 19:19:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -79 X-BigFish: VS-79(zz9371Ic89bh542M1432I15caKJ4015I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail64-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail64-db3 (localhost.localdomain [127.0.0.1]) by mail64-db3 (MessageSwitch) id 1343416749198089_14129; Fri, 27 Jul 2012 19:19:09 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.243]) by mail64-db3.bigfish.com (Postfix) with ESMTP id 2DDAEE00E4; Fri, 27 Jul 2012 19:19:09 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 19:19:09 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 27 Jul 2012 19:19:07 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 12:19:07 -0700 From: Dave Thaler To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QABedF2AAFmkxMA== Date: Fri, 27 Jul 2012 19:19:06 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B725609@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7234D2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E4A17E586@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E586@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "dhc@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 19:19:13 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Friday, July 27, 2012 2:01 AM > To: Dave Thaler; pcp@ietf.org > Cc: dhc@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Dear Dave, >=20 > Thank you for the review. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >Dave Thaler Envoy=E9 : jeudi 26 juillet 2012 23:32 =C0 : pcp@ietf.org Cc= : > >dhc@ietf.org Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > >Here's my personal comments on draft -03... I have a few editorial > >nits I'll just send to the authors. > > > >1) I agree with the conclusion of the rationale but the sentence > > "DHC WG's position is this flexibility have some drawbacks such as > >inducing > > errors." > > isn't intelligible. What does "inducing errors" mean? > >Either explain or remove. >=20 > Med: This is point is discussed in detail here: http://tools.ietf.org/htm= l/draft- > ietf-dhc-option-guidelines-08#section-7. Would you be fine if we add a > reference to that draft? Yes, good idea. > >2) The text on what to do with a name conveyed in an option is > >duplicated in > > Section 4.2 and 5.2. I'd prefer that this be specified > >only once, to avoid > > opportunities for discrepancies. That is, section 4.2's > >first two paragraphs are > > fine, as are the first 1 1/2 paragraphs of 5.2, since those are > >about how to get > > the name out of the option. The rest isn't DHCPv4 or > >DHCPv6 specific and > > should be in its own subsection. >=20 > Med: There is some duplication there but it does not harm IMHO. I prefer = to > maintain the text as it is. I think it does harm. The fact that the text is not identical means that a reader might interpret them differently, and have different implementatio= ns with different behavior. That would not be correct. So I think it's saf= est to have only one copy of the text. Do others have an opinion on this? > >3) Re "It is RECOMMENDED to associate a validity lifetime with any > >address > > resulting from resolving the Name". The text should be more > >specific about > > what the validity lifetime should be. If the name is > >resolved in DNS, I'd > > say the validity lifetime should be the TTL of the DNS record. > > >=20 > Med: I updated the text as follows: >=20 > It is RECOMMENDED to associate a validity lifetime (e.g., TTL of DNS > record if the Name is resolved using DNS) with any address resulting > from resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv4 option > when stored in a local name resolution cache. >=20 > Is this better? Yes. > >4) Re "When an > > application issues a PCP request to a PCP Server, the source > >address > > of the request MUST be among those assigned on the interface to > >which > > the destination PCP Server is bound. > > > > This doesn't belong in a DHCP-specific document, it's out > >of scope. That's > > the job of the pcp-base spec. >=20 > Med: I removed that sentence. >=20 > >5) Same as point 4, but for all of section 6. In my view it belongs > >either in > > pcp-base or perhaps more likely in a separate spec that's not DHCP > >specific. > > E.g., if I manually configure one or more names, the same behavior > >should apply. >=20 > Med: Dave, Section 6 is there because you requested it: see > http://www.ietf.org/mail-archive/web/pcp/current/msg01793.html. Since we > have the text now, I vote for keeping it. No need to create another depen= dency > with another document to come. Thanks for the reminder and the pointer. I agree that this spec needs to say something. My preference would be to separate it into something non-DHCP specific. But you're right about that possibly delaying the doc. So I'd suggest the following: 1) Introduce a section header called something like "Use of PCP Server Name= s" 2) Make the section start with an introductory sentence saying this section is applicable to any mechanism that configures server names, not just DH= CP. The first sentence of section 6 is a partial starting point for that. 3) Move the text I mentioned in point 2 (that I didn't want duplicated) to a subsection of it, since that text isn't necessarily DHCP specific eit= her. 4) Move section 6 under the "Use of PCP Server Names" section. This allows any other future name configuration mechanism (CLI, SNMP, YANG, or whatever else) to reference a single section of this document, which has all the non-DHCP-specific content under it. > >6) Section 5.2 says: > > "The DHCPv4 client MUST verify that the > > option length does not exceed 255 octets [RFC1035])." > > > > What does this mean? The length field is only 1 byte so > >cannot contain > > a value larger than 255 anyway. So what exactly is a > >client supposed to > > "verify" here? >=20 > Med: The text does not talk about the length of the field but the value i= t carries. I was talking about the value. See the exchange between Bernie and I for what this needs to say instead. =20 > > > >-Dave > > > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > >Behalf Of Dave > >> Thaler > >> Sent: Wednesday, July 18, 2012 2:21 PM > >> To: pcp@ietf.org > >> Cc: dhc@ietf.org > >> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > >> > >> As discussed at last IETF, the authors believe that all > >issues raised so far have > >> been addressed. No new issues have been raised since then, > >so this message > >> begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. > >> > >> This call would normally conclude in two weeks but that is > >during IETF week, so > >> the last call is extended to conclude at the end of IETF (as > >of the Friday PCP > >> meeting). > >> > >> We also agreed in Vancouver that this last call will be > >cross-posted to the DHC > >> list, hence cc'ing the DHC WG. > >> > >> We need at least 5 reviewers. Please send comments to the list. > >> > >> Thanks, > >> -Dave Thaler > >> > >> _______________________________________________ > >> pcp mailing list > >> pcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcp > > > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp > > From Ted.Lemon@nominum.com Fri Jul 27 12:34:16 2012 Return-Path: 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 A72C311E80E6; Fri, 27 Jul 2012 12:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 gxuTLaUCezcB; Fri, 27 Jul 2012 12:34:16 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id BFF2411E80D6; Fri, 27 Jul 2012 12:34:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUBLtNMuTGXBlGlsHIJJTdBBjD5qSS6IK@postini.com; Fri, 27 Jul 2012 12:34:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 95F3D1B82CD; Fri, 27 Jul 2012 12:34:11 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8542719005D; Fri, 27 Jul 2012 12:34:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 27 Jul 2012 12:34:11 -0700 From: Ted Lemon To: Dave Thaler Thread-Topic: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jAAD/3vgA== Date: Fri, 27 Jul 2012 19:34:10 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [pcp] [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 19:34:16 -0000 --_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote: Right. I think the goal should be to minimize the amount of processing th= e client has to do with the option contents... just pass it to getaddrinfo() = or equivalent was what the WG had discussed. Remembering that the DHCP server automatically translates names to IP addre= sses in its configuration, why is it necessary to place this burden on the = client? Traditionally DHCP just sends IP addresses, not names, precisely = because it minimizes the burden on the client while maintaining the flexibi= lity of doing name translation on the server. I assume you already consid= ered this, because I'm pretty sure you've seen debates about this go by bef= ore, but I'm curious as to why you decided to send a name rather than an IP= address. --_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote:
Right.   I think the goal should be to minimize the amount of processin= g the
client has to do with the option contents... just pass it to getaddrinfo() = or
equivalent was what the WG had discussed.

Remembering that the DHCP server automatically translates names to IP = addresses in its configuration, why is it necessary to place this burden on= the client?   Traditionally DHCP just sends IP addresses, not names, = precisely because it minimizes the burden on the client while maintaining the flexibility of doing name translation = on the server.   I assume you already considered this, because I'm pre= tty sure you've seen debates about this go by before, but I'm curious as to= why you decided to send a name rather than an IP address.

--_000_D2E362D0DEAB4024BC18A20D98862778nominumcom_-- From Ted.Lemon@nominum.com Fri Jul 27 15:30:51 2012 Return-Path: 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 BE84C11E80F2; Fri, 27 Jul 2012 15:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 t8r9NCXReEBx; Fri, 27 Jul 2012 15:30:51 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id C940911E80BA; Fri, 27 Jul 2012 15:30:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUBMWmpqs1t58L0ZDtZ8MIgs4hpDTsW8f@postini.com; Fri, 27 Jul 2012 15:30:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A89221B8312; Fri, 27 Jul 2012 15:30:49 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9D92719005D; Fri, 27 Jul 2012 15:30:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 27 Jul 2012 15:30:49 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jAAD/3vgAAN07dw///CugA= Date: Fri, 27 Jul 2012 22:30:48 +0000 Message-ID: <37691433-E8ED-4DF8-AFC4-25BF5E8985F2@nominum.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CE85@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E02CE85@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_" MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 22:30:51 -0000 --_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 27, 2012, at 4:16 PM, Bernie Volz (volz) wrote: The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does s= eem to indicate your solution, but it never specifies =93when=94 this resol= ution should be done. I think that=92s likely and issue we need to discuss = about this guidelines draft. That's an implementation issue; the same issue exists on the client. Sinc= e you're setting up a tunnel, obviously the resolution happens when you set= up the tunnel, and if the DNS changes after that, the client doesn't notic= e, tear down the tunnel, and set up a new one, does it? As for how the server handles it, that's left up to the implementation. T= he ISC DHCP server does the resolution when the request comes in, and if th= e DNS is down, it blocks. Nominum's server does the resolution at request= time too, but is a log smarter about not blocking and about responding if = no answer comes from the DNS. But really, if the DNS is down, you're hose= d anyway, no matter who is doing the resolution. You have to have reliabl= e DNS. --_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3BB905072B53064888C3EAA0003F8D7E@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 27, 2012, at 4:16 PM, Bernie Volz (volz) wrote:
The http://datatracker.ietf.org/= doc/draft-ietf-dhc-option-guidelines does seem to indicate your solution, but it never specifies =93when=94 this res= olution should be done. I think that=92s likely and issue we need to discus= s about this guidelines draft.

That's an implementation issue; the same issue exists on the client. &= nbsp; Since you're setting up a tunnel, obviously the resolution happens wh= en you set up the tunnel, and if the DNS changes after that, the client doe= sn't notice, tear down the tunnel, and set up a new one, does it?

As for how the server handles it, that's left up to the implementation= .   The ISC DHCP server does the resolution when the request comes in,= and if the DNS is down, it blocks.   Nominum's server does the resolu= tion at request time too, but is a log smarter about not blocking and about responding if no answer comes from the DNS. &= nbsp; But really, if the DNS is down, you're hosed anyway, no matter who is= doing the resolution.   You have to have reliable DNS.

--_000_37691433E8ED4DF8AFC425BF5E8985F2nominumcom_-- From dthaler@microsoft.com Fri Jul 27 17:09:04 2012 Return-Path: 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 7650A11E8107 for ; Fri, 27 Jul 2012 17:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.199 X-Spam-Level: X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fSGDYZv8xEw3 for ; Fri, 27 Jul 2012 17:09:04 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id C167F11E8106 for ; Fri, 27 Jul 2012 17:09:03 -0700 (PDT) Received: from mail22-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Sat, 28 Jul 2012 00:09:02 +0000 Received: from mail22-va3 (localhost [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 7C5083601EE for ; Sat, 28 Jul 2012 00:09:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail22-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1343434140359808_6893; Sat, 28 Jul 2012 00:09:00 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.254]) by mail22-va3.bigfish.com (Postfix) with ESMTP id 54433440088 for ; Sat, 28 Jul 2012 00:09:00 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 28 Jul 2012 00:09:00 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.309.3; Sat, 28 Jul 2012 00:08:58 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 17:08:58 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAN1+MAA== Date: Sat, 28 Jul 2012 00:08:57 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B726B6D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B72358D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B72358D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 00:09:04 -0000 10) Section 6 item 2 says: > 2. If several PCP Names are received: each Name is treated as a > separate PCP Server. Moreover, each Name may be resolved into > one IP address or a list of IP addresses. The PCP Client > contacts in parallel the first IP address of each Name and > follows the procedure specified in Section 6.1 for the list of IP > addresses returned for each Name. Section 6.2 provides some > examples to illustrate this procedure. I think the above isn't quite right. There's two cases: a) All PCP servers use the same external IP address (e.g., FWs) b) Each PCP server uses a separate external IP address (i.e., most NATs) In case (a), it's the right thing to send to all PCP servers, since the choice of ingress point is made by external routing. In case (b), the client would get a different IP address from each, which=20 is often not useful, if the app can only use one. E.g., the UPnP-IGD IWF can only use one, and many apps can only use one if the way the app advertises itself to potential peers can only pass one address. In this case, consuming a mapping from more than one would just needlessly consume resources. This for case (b), there should be a way to detect this case, and to only use a single PCP server. -Dave From dthaler@microsoft.com Fri Jul 27 17:31:41 2012 Return-Path: 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 7AC4011E810A for ; Fri, 27 Jul 2012 17:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.316 X-Spam-Level: X-Spam-Status: No, score=-103.316 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] 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 MQB3qtsya6sX for ; Fri, 27 Jul 2012 17:31:40 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id B3D4511E8107 for ; Fri, 27 Jul 2012 17:31:40 -0700 (PDT) Received: from mail9-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Sat, 28 Jul 2012 00:31:40 +0000 Received: from mail9-co1 (localhost [127.0.0.1]) by mail9-co1-R.bigfish.com (Postfix) with ESMTP id 217D56403CC for ; Sat, 28 Jul 2012 00:31:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zz9371I542M1432I4015Izz1202hzz1033IL8275bh8275dh186M5eeeKz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail9-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail9-co1 (localhost.localdomain [127.0.0.1]) by mail9-co1 (MessageSwitch) id 1343435498517072_19423; Sat, 28 Jul 2012 00:31:38 +0000 (UTC) Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.237]) by mail9-co1.bigfish.com (Postfix) with ESMTP id 72A3E700059 for ; Sat, 28 Jul 2012 00:31:38 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 28 Jul 2012 00:31:38 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Sat, 28 Jul 2012 00:31:37 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 17:31:37 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WG last call on draft-ietf-pcp-upnp-igd-interworking-01 Thread-Index: Ac1hMjoDlGipwl5IQFyJZsQqTYBRegLI1Vtw Date: Sat, 28 Jul 2012 00:31:36 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B726CBE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B6EC46F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6EC46F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 00:31:41 -0000 A marked up version with my full comments is available at: http://research.microsoft.com/~dthaler/draft-ietf-pcp-upnp-igd-interworking= -01.pdf A summary of the main non-editorial issues follows: 1) The UPnP IGD state variables and methods fall into two categories: those relevant to port mapping, and those not relevant to port mapping. Current= ly some the latter are listed as "not applicable", some are omitted from the d= ocument, and of those not omitted, I think some of the statements aren't correct. = Instead, I think this doc should be scoped to only discussion of the first category = and say the rest are covered in [IGD2], without enumerating them. And I think we = should also say that an IGD with the IWF MUST be compliant to [IGD2]. I believe = that will maximize the chance of interoperability with UPnP-IGD clients. 2) The doc currently assumes that there's only one ExternalIPAddress. I d= on't think that's as scalable, and it's certainly not required by the PCP protoc= ol. Instead, I think we should explicitly state that the ExternalIPAddress shou= ld be stored on a per control-point basis, so that different control points could see di= fferent=20 values. Each value comes from the PCP responses for mappings for that con= trol point. This means that just because there's a collision in external port for some = other control point doesn't mean that adding a mapping will fail. It would only= fail if that other control point used the same ExternalIPAddress as the requesti= ng one. If the requesting control point hadn't yet been assigned an ExternalIPAddre= ss, then the request should be relayed to the PCP server(s). [See also my comment= #10 on the pcp-dhcp draft.] Section 11.3 of the pcp-base spec already has lo= gic where the server will accept a port MAP request even when one IP already has a ma= pping, as long as it has another available external IP that can service the reques= t. 3) It would be good to add a paragraph, say in the discussion of Figure 4=20 (Cascaded NAT scenario), explaining that without the PCP IWF, the control p= oint would see an "ExternalIPAddress" and port of the WAN link between the IGD and NAT2, not the public address/port on the Internet. With the PCP IWF, the control point will instead see the public address/port on the Internet. It will no longer see the intermediate address/port between the IGD and NAT2, even though it would be useful for communication with another host behind the same NAT2 but not behind the IGD. Such learning is not supported, and so it would be good to point that out. This helps the read= er understand the point of the rest of the logic. 4) Renewals are mentioned in passing under the "PortMappingLeaseDuration" state variable. However the behavior is never specified. This should be= added as a new section 5.10. 5) The assumption in UPnP-IGD is that GetSpecificPortMappingEntry() can not return something that wouldn't be returned by GetGenericPortMappingEntry() and GetListOfPortMappings(). Section 5.8 breaks that, without giving any = justification. That is, it says GetListOfPortMappings and GetGenericPortMappingEntry are served locally, never relayed, but that GetSpecificPortMappingEntry can be relayed when no mapping is found. This is inconsistent. I think it shoul= d be handled locally as well, to retain consistency. Yes that means you can't = use it to look up third party information about other IGDs. And that's a good= thing. -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dav= e > Thaler > Sent: Friday, July 13, 2012 1:08 PM > To: pcp@ietf.org > Subject: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01 >=20 > From the IETF 83 minutes: > > 1330-1340 UPnP-IGD Interworking Function (Mohamed Boucadair= , 10) > > Document: draft-ietf-pcp-upnp-igd-interworking-01 > > Slides: http://www.ietf.org/proceedings/83/slides/slides-83-p= cp-1.pdf > > > > Any objections to starting a WG Last Call on this? > > Francis objected that the issue of an IGD client that asks for a lifeti= me > > longer than the PCP server is willing to grant can never be solved, > > and therefore the entire work item is futile. > > Dave: This is an issue, but not an open issue. > > Dave: will confer with Alain about whether to start WG Last Call. >=20 > The chairs have agreed to start a WG last call. We've seen no additiona= l > discussion on this draft since last IETF, so this email initiates a last = call on > draft-ietf-pcp-upnp-igd-interworking-01. This call will conclude in two > weeks (Friday July 27th), just prior to IETF. Hopefully that will allow > for discussion of WGLC comments in Vancouver. >=20 > We need at least 5 reviewers. Please send comments to the list. >=20 > Thanks, > -Dave >=20 >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Jul 30 02:21:25 2012 Return-Path: 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 DB34F21F8518 for ; Mon, 30 Jul 2012 02:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 P4JZpkxNlg13 for ; Mon, 30 Jul 2012 02:21:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1516F21F8504 for ; Mon, 30 Jul 2012 02:21:24 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CFD2422C1A7; Mon, 30 Jul 2012 11:21:23 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B323F238062; Mon, 30 Jul 2012 11:21:23 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 30 Jul 2012 11:21:15 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Mon, 30 Jul 2012 11:21:14 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAN1+MAAB3H0yQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E8B1@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B72358D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B726B6D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B726B6D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.30.75414 Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:21:26 -0000 Dave,=20 Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : samedi 28 juillet 2012 02:09 >=C0 : pcp@ietf.org >Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > >10) Section 6 item 2 says: >> 2. If several PCP Names are received: each Name is treated as a >> separate PCP Server. Moreover, each Name may be resolved into >> one IP address or a list of IP addresses. The PCP Client >> contacts in parallel the first IP address of each Name and >> follows the procedure specified in Section 6.1 for the=20 >list of IP >> addresses returned for each Name. Section 6.2 provides some >> examples to illustrate this procedure. > >I think the above isn't quite right.=20 Med: This is a simple rationale to guide the PCP Client: * configure the DHCP server to return one Name when there is a need to cont= act only one PCP Server=20 * configure the DHCP server to return several Names when there is a need to= contact several PCP Servers in //. The operator configuring the dhcp server is aware of the capabilities of de= ployed PCP servers. It will need to configure the dhcp server appropriately= (one Name or several ones). Note, a list of IP addresses can be associated= with the same Name. There's two cases: >a) All PCP servers use the same external IP address (e.g., FWs) >b) Each PCP server uses a separate external IP address (i.e.,=20 >most NATs) Med: Note the PCP Client has no means to know in advance the capabilities o= f each PCP server; particularly it does not know the external IP address (p= ool) used by each PCP Server.=20 > >In case (a), it's the right thing to send to all PCP servers, since the >choice of ingress point is made by external routing. > >In case (b), the client would get a different IP address from=20 >each, which=20 >is often not useful, if the app can only use one. E.g., the=20 >UPnP-IGD IWF >can only use one, and many apps can only use one if the way the app >advertises itself to potential peers can only pass one=20 >address. In this >case, consuming a mapping from more than one would just needlessly >consume resources. > >This for case (b), there should be a way to detect this case,=20 >and to only >use a single PCP server. Med: This is deployment-specific. Consider the following cases: * multihomed PCP Client has to contact all PCP servers to install the mappi= ng. This can not be considered as resource consuming * a PCP client which is in front of a NAT64 and IPv6 FW. All these PCP Serv= ers needs to be contacted. =20 > >-Dave > > > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From mohamed.boucadair@orange.com Mon Jul 30 02:37:47 2012 Return-Path: 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 DCCC921F847A for ; Mon, 30 Jul 2012 02:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] 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 VgLLyFvLFK21 for ; Mon, 30 Jul 2012 02:37:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D421F871A for ; Mon, 30 Jul 2012 02:37:46 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A2EE518C2D2; Mon, 30 Jul 2012 11:37:45 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 87C3B4C06E; Mon, 30 Jul 2012 11:37:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 30 Jul 2012 11:37:37 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Mon, 30 Jul 2012 11:37:36 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QABedF2AAFmkxMACCogmg Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E8C4@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7234D2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E4A17E586@PUEXCB1B.nanterre.francetelecom.fr> <9B57C850BB53634CACEC56EF4853FF653B725609@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B725609@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.30.83920 Cc: "dhc@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:37:48 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Dave Thaler [mailto:dthaler@microsoft.com]=20 >Envoy=E9 : vendredi 27 juillet 2012 21:19 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org >Cc : dhc@ietf.org >Objet : RE: WGLC on draft-ietf-pcp-dhcp-03 > > > >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: Friday, July 27, 2012 2:01 AM >> To: Dave Thaler; pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Dear Dave, >>=20 >> Thank you for the review. >>=20 >> Please see inline. >>=20 >> Cheers, >> Med >>=20 >> >-----Message d'origine----- >> >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De=20 >la part de >> >Dave Thaler Envoy=E9 : jeudi 26 juillet 2012 23:32 =C0 :=20 >pcp@ietf.org Cc : >> >dhc@ietf.org Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >> > >> >Here's my personal comments on draft -03... I have a few editorial >> >nits I'll just send to the authors. >> > >> >1) I agree with the conclusion of the rationale but the sentence >> > "DHC WG's position is this flexibility have some=20 >drawbacks such as >> >inducing >> > errors." >> > isn't intelligible. What does "inducing errors" mean? >> >Either explain or remove. >>=20 >> Med: This is point is discussed in detail here:=20 >http://tools.ietf.org/html/draft- >> ietf-dhc-option-guidelines-08#section-7. Would you be fine=20 >if we add a >> reference to that draft? > >Yes, good idea. Med: Done. > >> >2) The text on what to do with a name conveyed in an option is >> >duplicated in >> > Section 4.2 and 5.2. I'd prefer that this be specified >> >only once, to avoid >> > opportunities for discrepancies. That is, section 4.2's >> >first two paragraphs are >> > fine, as are the first 1 1/2 paragraphs of 5.2, since those are >> >about how to get >> > the name out of the option. The rest isn't DHCPv4 or >> >DHCPv6 specific and >> > should be in its own subsection. >>=20 >> Med: There is some duplication there but it does not harm=20 >IMHO. I prefer to >> maintain the text as it is. > >I think it does harm. The fact that the text is not=20 >identical means that >a reader might interpret them differently, and have different=20 >implementations >with different behavior. That would not be correct. So I=20 >think it's safest >to have only one copy of the text. Med: Ok.=20 * I removed the duplicated text into a sub-section of the new Section "Use = of PCP Server Names".=20 * I added this sentence to Section 4.2 and similar one to Section 5.2: "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, the = DHCPv6 client MUST follow the procedure specified in Section 6.1" > >Do others have an opinion on this? > >> >3) Re "It is RECOMMENDED to associate a validity lifetime with any >> >address >> > resulting from resolving the Name". The text should be more >> >specific about >> > what the validity lifetime should be. If the name is >> >resolved in DNS, I'd >> > say the validity lifetime should be the TTL of the DNS record. >> > >>=20 >> Med: I updated the text as follows: >>=20 >> It is RECOMMENDED to associate a validity lifetime (e.g.,=20 >TTL of DNS >> record if the Name is resolved using DNS) with any=20 >address resulting >> from resolving the Name conveyed in a OPTION_PCP_SERVER=20 >DHCPv4 option >> when stored in a local name resolution cache. >>=20 >> Is this better? > >Yes. > >> >4) Re "When an >> > application issues a PCP request to a PCP Server, the source >> >address >> > of the request MUST be among those assigned on the=20 >interface to >> >which >> > the destination PCP Server is bound. >> > >> > This doesn't belong in a DHCP-specific document, it's out >> >of scope. That's >> > the job of the pcp-base spec. >>=20 >> Med: I removed that sentence. >>=20 >> >5) Same as point 4, but for all of section 6. In my view it belongs >> >either in >> > pcp-base or perhaps more likely in a separate spec=20 >that's not DHCP >> >specific. >> > E.g., if I manually configure one or more names, the=20 >same behavior >> >should apply. >>=20 >> Med: Dave, Section 6 is there because you requested it: see >>=20 >http://www.ietf.org/mail-archive/web/pcp/current/msg01793.html. > Since we >> have the text now, I vote for keeping it. No need to create=20 >another dependency >> with another document to come. > >Thanks for the reminder and the pointer. I agree that this=20 >spec needs to >say something. My preference would be to separate it into something >non-DHCP specific. But you're right about that possibly=20 >delaying the doc. >So I'd suggest the following: > >1) Introduce a section header called something like "Use of=20 >PCP Server Names" >2) Make the section start with an introductory sentence saying=20 >this section > is applicable to any mechanism that configures server=20 >names, not just DHCP. > The first sentence of section 6 is a partial starting point=20 >for that. >3) Move the text I mentioned in point 2 (that I didn't want=20 >duplicated) to > a subsection of it, since that text isn't necessarily DHCP=20 >specific either. >4) Move section 6 under the "Use of PCP Server Names" section. > >This allows any other future name configuration mechanism (CLI, SNMP, >YANG, or whatever else) to reference a single section of this document, >which has all the non-DHCP-specific content under it. Med: Done. The new ToC for this section is as follows: 6. Use of PCP Server Names . . . . . . . . . . . . . . . . . . . 6 6.1. Name Resolution . . . . . . . . . . . . . . . . . . . . . 6 6.2. IP Address Selection . . . . . . . . . . . . . . . . . . . 7 6.2.1. Serial Queries . . . . . . . . . . . . . . . . . . . . 7 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . 8 6.2.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . 8 6.2.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . 9 > >> >6) Section 5.2 says: >> > "The DHCPv4 client MUST verify that the >> > option length does not exceed 255 octets [RFC1035])." >> > >> > What does this mean? The length field is only 1 byte so >> >cannot contain >> > a value larger than 255 anyway. So what exactly is a >> >client supposed to >> > "verify" here? >>=20 >> Med: The text does not talk about the length of the field=20 >but the value it carries. > >I was talking about the value. >See the exchange between Bernie and I for what this needs to=20 >say instead. >=20 >> > >> >-Dave >> > >> >> -----Original Message----- >> >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On >> >Behalf Of Dave >> >> Thaler >> >> Sent: Wednesday, July 18, 2012 2:21 PM >> >> To: pcp@ietf.org >> >> Cc: dhc@ietf.org >> >> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >> >> >> >> As discussed at last IETF, the authors believe that all >> >issues raised so far have >> >> been addressed. No new issues have been raised since then, >> >so this message >> >> begins a Working Group Last Call on draft-ietf-pcp-dhcp-03. >> >> >> >> This call would normally conclude in two weeks but that is >> >during IETF week, so >> >> the last call is extended to conclude at the end of IETF (as >> >of the Friday PCP >> >> meeting). >> >> >> >> We also agreed in Vancouver that this last call will be >> >cross-posted to the DHC >> >> list, hence cc'ing the DHC WG. >> >> >> >> We need at least 5 reviewers. Please send comments to the list. >> >> >> >> Thanks, >> >> -Dave Thaler >> >> >> >> _______________________________________________ >> >> pcp mailing list >> >> pcp@ietf.org >> >> https://www.ietf.org/mailman/listinfo/pcp >> > >> > >> >_______________________________________________ >> >pcp mailing list >> >pcp@ietf.org >> >https://www.ietf.org/mailman/listinfo/pcp >> > > >= From mohamed.boucadair@orange.com Mon Jul 30 04:49:06 2012 Return-Path: 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 77DBE21F874A; Mon, 30 Jul 2012 04:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, UNPARSEABLE_RELAY=0.001] 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 yTAZ1Aob2i6y; Mon, 30 Jul 2012 04:49:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5E421F873C; Mon, 30 Jul 2012 04:49:03 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7BAE118C224; Mon, 30 Jul 2012 13:49:02 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 50EDB238061; Mon, 30 Jul 2012 13:49:02 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 30 Jul 2012 13:48:54 +0200 From: To: "Bernie Volz (volz)" , Dave Thaler , "dhcwg@ietf.org" Date: Mon, 30 Jul 2012 13:48:53 +0200 Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAJFlwDA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E910@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "pcp@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 11:49:06 -0000 Dear Bernie, See inline. Cheers, Med =20 >-----Message d'origine----- >De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >la part de Bernie Volz (volz) >Envoy=E9 : vendredi 27 juillet 2012 16:47 >=C0 : Dave Thaler; dhcwg@ietf.org >Cc : pcp@ietf.org >Objet : Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 > >Dave: > >As the options as defined contain a domain name (encoded per=20 >RFC 1035) are address literals really appropriate? This also=20 >has consequences for configuring the option data in the=20 >servers. And, it seems rather bad to take an encoded name,=20 >convert it to a string, only to convert it back into an=20 >encoded name. But, alas, that is likely given the common APIs. > >Also, given that RFC 1035 section 3.1 states:=20 > > Since every domain name ends with the null label of > the root, a domain name is terminated by a length byte of zero. > >And the option is to accommodate a list of domain names=20 >(knowing that each terminates in the null label makes it=20 >possible to separate them), how do you propose that literals=20 >(10.1.2.3) be encoded so that it not end up as the domain name=20 >"10.1.2.3.". > >Perhaps there is a convention used to do this somewhere? (I=20 >admit I haven't looked at draft-iab-identifier-comparison carefully.) > > >When reviewing this and commenting the other day, I originally=20 >had thought about commenting on the rather strict rules as to=20 >how the results of DNS queries could be used and was thinking=20 >that it might be appropriate to relax them some. Just doing=20 >normal DNS lookups and using the results (AAAA if v6 is=20 >available, A if v4 is available, etc.) would likely make=20 >implementing this much easier and require less specialized code. > > >> 6) Section 5.2 says: >> "The DHCPv4 client MUST verify that the >> option length does not exceed 255 octets [RFC1035])." > >Good catch. This should be removed as we have the ability to=20 >support long v4 options - see RFC 3396. > >Note that per section 4 of this RFC: > > Let us divide all DHCP options into two categories - those that, by > definition, require implementation of the mechanisms defined in this > document, and those that do not. We will refer to the former as > concatenation-requiring options, and the latter as non- > concatenation-requiring options. In order for an option to be a > concatenation-requiring option, the protocol specification that > defines that option must require implementation of option splitting > and option concatenation as described in this document, by > specifically referencing this document. > >So the draft should reference RFC 3396 and indicate that this=20 >is a concatenation-requiring option. Med: I added this text to Section 5.1.=20 The OPTION_PCP_SERVER DHCPv4 option is a concatenation-requiring option. As such, the mechanism specified in [RFC3396] MUST be used if the PCP Server Name option exceeds the maximum DHCPv4 option size of 255 octets. Does this solves your concern?=20 > >- Bernie > >-----Original Message----- >From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >On Behalf Of Dave Thaler >Sent: Thursday, July 26, 2012 5:59 PM >To: dhcwg@ietf.org >Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 > >I keep mangling the WG mailing list address, so forwarding. > >-----Original Message----- >From: Dave Thaler >Sent: Thursday, July 26, 2012 2:58 PM >To: 'pcp@ietf.org' >Cc: 'dhc@ietf.org' >Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 > >Missed responding to section 7 before sending... > >7) Re "A PCP Server configured using OPTION_PCP_SERVER over=20 >DHCPv4 is likely > to be resolved to IPv4 address(es)." > I don't think I'd agree with that assumption. If I put a=20 >DNS name in the option, > it'll be resolved to whatever records are in DNS of a type=20 >the client queries for. > The document currently doesn't say what type(s) to query=20 >for (A vs AAAA). > Per my comment on 2, I believe the types to query for=20 >should be independent of > how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or=20 >whatever else). > =20 > "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be > resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" > By the same reasoning as my previous comment above, it may=20 >also be resolved > to IPv4 addresses. If I have a dual-stack PCP server, I=20 >should be able to put > the same DNS name in both a DHCPv4 option and a DHCPv6=20 >option, rather > than requiring me to have two separate names for the same server. > >8) Pursuant to a discussion I've been having with some folks on > draft-iab-identifier-comparison section 3.1.1 and some=20 >changes I'll be making to > it as a result, it got me thinking. I'm thinking it would=20 >be good to have a short > subsection on Guidance to Administrators on what to=20 >configure in their DHCP > server to return in these options, or more importantly,=20 >what not to configure. > Specifically, strings like "10.0.258", "0xA000001", and=20 >"012.0x102" would > all be a bad idea to configure (unless you specified how=20 >they're to be interpreted > which is an option, though probably not the most expedient=20 >one). I'm still strongly > in favor of retaining the fact that it's a string that can=20 >be passed to name > resolution APIs, but that means it's best to avoid strings=20 >that are interpreted > differently by different such APIs. > >9) On the same point, Section 4.2 currently states: > "Once each Name conveyed in the OPTION_PCP_SERVER option is=20 >validated, > each included Name is passed to the name resolution library (e.g., > Section 6.1.1 of [RFC1123] or [RFC6055])" > The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in=20 >particular are=20 > problematic because as worded a client that chose not to=20 >support IP literals > would be legal, and it would try to resolve "10.11.12.13"=20 >in DNS, which we > don't want. Surprising (as=20 >draft-iab-identifier-comparison already points out), > even [RFC1123] allows this to be optional (a "SHOULD") in: =20 >"The host SHOULD check > the string syntactically for a dotted-decimal number before=20 >looking it up in=20 > the Domain Name System." > > Instead it's important here to require that the client be able to=20 > use IP literals. Most name resolution APIs=20 >(gethostbyname, getaddrinfo, > etc.) all meet that criteria. > >-Dave > >> -----Original Message----- >> From: Dave Thaler >> Sent: Thursday, July 26, 2012 2:32 PM >> To: pcp@ietf.org >> Cc: dhc@ietf.org >> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Here's my personal comments on draft -03... I have a few editorial=20 >> nits I'll just send to the authors. >>=20 >> 1) I agree with the conclusion of the rationale but the sentence >> "DHC WG's position is this flexibility have some=20 >drawbacks such as inducing >> errors." >> isn't intelligible. What does "inducing errors" mean? =20 >Either explain or >> remove. >>=20 >> 2) The text on what to do with a name conveyed in an option=20 >is duplicated in >> Section 4.2 and 5.2. I'd prefer that this be specified=20 >only once, to avoid >> opportunities for discrepancies. That is, section=20 >4.2's first two paragraphs >> are >> fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 >> about how to get >> the name out of the option. The rest isn't DHCPv4 or=20 >DHCPv6 specific and >> should be in its own subsection. >>=20 >> 3) Re "It is RECOMMENDED to associate a validity lifetime=20 >with any address >> resulting from resolving the Name". The text should be=20 >more specific about >> what the validity lifetime should be. If the name is=20 >resolved in DNS, I'd >> say the validity lifetime should be the TTL of the DNS record. >>=20 >> 4) Re "When an >> application issues a PCP request to a PCP Server, the=20 >source address >> of the request MUST be among those assigned on the=20 >interface to which >> the destination PCP Server is bound. >>=20 >> This doesn't belong in a DHCP-specific document, it's out=20 >of scope. That's >> the job of the pcp-base spec. >>=20 >> 5) Same as point 4, but for all of section 6. In my view it=20 >belongs either in >> pcp-base or perhaps more likely in a separate spec that's=20 >not DHCP specific. >> E.g., if I manually configure one or more names, the same=20 >behavior=20 >> should apply. >>=20 >> 6) Section 5.2 says: >> "The DHCPv4 client MUST verify that the >> option length does not exceed 255 octets [RFC1035])." >>=20 >> What does this mean? The length field is only 1 byte so=20 >cannot contain >> a value larger than 255 anyway. So what exactly is a=20 >client supposed to >> "verify" here? >>=20 >> -Dave >>=20 >> > -----Original Message----- >> > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 >> > Of Dave Thaler >> > Sent: Wednesday, July 18, 2012 2:21 PM >> > To: pcp@ietf.org >> > Cc: dhc@ietf.org >> > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >> > >> > As discussed at last IETF, the authors believe that all issues=20 >> > raised so far have been addressed. No new issues have been raised=20 >> > since then, so this message begins a Working Group Last Call on >> > draft-ietf-pcp- >> dhcp-03. >> > >> > This call would normally conclude in two weeks but that is during=20 >> > IETF week, so the last call is extended to conclude at the end of=20 >> > IETF (as of the Friday PCP meeting). >> > >> > We also agreed in Vancouver that this last call will be=20 >cross-posted=20 >> > to the DHC list, hence cc'ing the DHC WG. >> > >> > We need at least 5 reviewers. Please send comments to the list. >> > >> > Thanks, >> > -Dave Thaler >> > >> > _______________________________________________ >> > pcp mailing list >> > pcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www.ietf.org/mailman/listinfo/dhcwg >= From mohamed.boucadair@orange.com Mon Jul 30 07:36:14 2012 Return-Path: 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 0F2D711E8098 for ; Mon, 30 Jul 2012 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] 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 L3tdLMPFPVcG for ; Mon, 30 Jul 2012 07:36:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5211E808E for ; Mon, 30 Jul 2012 07:36:12 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9F0FA324075; Mon, 30 Jul 2012 16:36:11 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8160A238056; Mon, 30 Jul 2012 16:36:11 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 30 Jul 2012 16:36:03 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Mon, 30 Jul 2012 16:36:02 +0200 Thread-Topic: WG last call on draft-ietf-pcp-upnp-igd-interworking-01 Thread-Index: Ac1hMjoDlGipwl5IQFyJZsQqTYBRegLI1VtwAICVqQA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E9B9@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B6EC46F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B726CBE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B726CBE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.30.134529 Subject: Re: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 14:36:14 -0000 Dear Dave, Thank you for the detailed review.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : samedi 28 juillet 2012 02:32 >=C0 : pcp@ietf.org >Objet : Re: [pcp] WG last call on=20 >draft-ietf-pcp-upnp-igd-interworking-01 > >A marked up version with my full comments is available at: >http://research.microsoft.com/~dthaler/draft-ietf-pcp-upnp-igd- >interworking-01.pdf > >A summary of the main non-editorial issues follows: > >1) The UPnP IGD state variables and methods fall into two=20 >categories: those >relevant to port mapping, and those not relevant to port=20 >mapping. Currently >some the latter are listed as "not applicable", some are=20 >omitted from the document, >and of those not omitted, I think some of the statements=20 >aren't correct. Instead, >I think this doc should be scoped to only discussion of the=20 >first category and say >the rest are covered in [IGD2], without enumerating them. =20 Med: I removed non-applicable variables from the document. >And I think we should >also say that an IGD with the IWF MUST be compliant to [IGD2].=20 > I believe that >will maximize the chance of interoperability with UPnP-IGD clients. > Med: Added to Section 4.1 this sentence:=20 "The UPnP IGD-PCP Interworking Function MUST support IGD:2 behavior." =20 >2) The doc currently assumes that there's only one=20 >ExternalIPAddress. Med: Yes, it assumes one external IP address is assigned per CPE not per UP= nP CP. This is aligned with REQ#2 of http://tools.ietf.org/html/draft-ietf-= behave-lsn-requirements-08. I don't >think that's as scalable, and it's certainly not required by=20 >the PCP protocol. >Instead, I think we should explicitly state that the=20 >ExternalIPAddress should be stored >on a per control-point basis, so that different control points=20 >could see different=20 >values. Each value comes from the PCP responses for mappings=20 >for that control point. >This means that just because there's a collision in external=20 >port for some other >control point doesn't mean that adding a mapping will fail. =20 >It would only fail >if that other control point used the same ExternalIPAddress as=20 >the requesting one. >If the requesting control point hadn't yet been assigned an=20 >ExternalIPAddress, then >the request should be relayed to the PCP server(s). [See=20 >also my comment #10 >on the pcp-dhcp draft.] Section 11.3 of the pcp-base spec=20 >already has logic where >the server will accept a port MAP request even when one IP=20 >already has a mapping, >as long as it has another available external IP that can=20 >service the request. Med: I don't have a problem to relax this constraint to be on a per CP basi= s rather than per CPE. If there is no objection from the WG, I will impleme= nt the change you are requesting for. =20 > >3) It would be good to add a paragraph, say in the discussion=20 >of Figure 4=20 >(Cascaded NAT scenario), explaining that without the PCP IWF,=20 >the control point >would see an "ExternalIPAddress" and port of the WAN link=20 >between the IGD >and NAT2, not the public address/port on the Internet. With=20 >the PCP IWF, >the control point will instead see the public address/port on=20 >the Internet. >It will no longer see the intermediate address/port between the IGD and >NAT2, even though it would be useful for communication with another >host behind the same NAT2 but not behind the IGD. Such=20 >learning is not >supported, and so it would be good to point that out. This=20 >helps the reader >understand the point of the rest of the logic. Med: I added this new text: Without the involvement of the IGD-PCP Interworking Function, the UPnP CP would retrieve an external IP address and port number having a limited scope and which can not be used to communicate with hosts located beyond NAT2 (i.e., assigned by the IGD and not the ones assigned by NAT2 in Figure 4). > >4) Renewals are mentioned in passing under the=20 >"PortMappingLeaseDuration" >state variable. However the behavior is never specified. =20 >This should be added >as a new section 5.10. > Med: I added this new section: 5.10. Renewal Because of the incompatibility of mapping lifetimes between UPnP IGD and PCP, the IGD-PCP Interworking Function MUST simulate long and even infinite lifetimes. Indeed, for requests having a requested PortMappingLeaseDuration longer than 65535 or infinite, the IGD-PCP Interworking Function MUST set the requested PCP Lifetime of the corresponding PCP request to 65535. Furthermore, the IGD-PCP Interworking Function MUST maintain an additional timer set to the initial requested PortMappingLeaseDuration. Upon receipt of a positive answer from the PCP server, the IGD-PCP Interworking Function relays the corresponding UPnP IGD response to the requesting UPnP CP with PortMappingLeaseDuration set to the same value as the one of the initial request. Then, the IGD-PCP Interworking Function MUST renew the instructed PCP mapping until the expiry of PortMappingLeaseDuration. Responses received when renewing the mapping MUST NOT be relayed to the UPnP CP. In case an error is encountered during mapping renewal, the IGD-PCP Interworking Function has no means to inform the UPnP CP. >5) The assumption in UPnP-IGD is that=20 >GetSpecificPortMappingEntry() can not >return something that wouldn't be returned by=20 >GetGenericPortMappingEntry() >and GetListOfPortMappings(). Section 5.8 breaks that,=20 >without giving any justification. >That is, it says GetListOfPortMappings and=20 >GetGenericPortMappingEntry are >served locally, never relayed, but that=20 >GetSpecificPortMappingEntry can be >relayed when no mapping is found. This is inconsistent. I=20 >think it should be >handled locally as well, to retain consistency. Yes that=20 >means you can't use >it to look up third party information about other IGDs. And=20 >that's a good thing. Med: The motivation for this is as mentioned in the draft:=20 "some applications uses GetSpecificPortMapping() to check whether a mapping exists." These applications check whether a specific mapping is instantiated, if not= these applications sent a request to install that mapping.=20 If GetSpecificPortMappingEntry() is served locally, this will lead to appli= cation error. It is efficient to relay GetSpecificPortMappingEntry() rather= than serving it locally. > >-Dave > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of Dave >> Thaler >> Sent: Friday, July 13, 2012 1:08 PM >> To: pcp@ietf.org >> Subject: [pcp] WG last call on=20 >draft-ietf-pcp-upnp-igd-interworking-01 >>=20 >> From the IETF 83 minutes: >> > 1330-1340 UPnP-IGD Interworking Function =20 >(Mohamed Boucadair, 10) >> > Document: draft-ietf-pcp-upnp-igd-interworking-01 >> > Slides:=20 >http://www.ietf.org/proceedings/83/slides/slides-83-pcp-1.pdf >> > >> > Any objections to starting a WG Last Call on this? >> > Francis objected that the issue of an IGD client that asks=20 >for a lifetime >> > longer than the PCP server is willing to grant can=20 >never be solved, >> > and therefore the entire work item is futile. >> > Dave: This is an issue, but not an open issue. >> > Dave: will confer with Alain about whether to start WG Last Call. >>=20 >> The chairs have agreed to start a WG last call. We've seen=20 >no additional >> discussion on this draft since last IETF, so this email=20 >initiates a last call on >> draft-ietf-pcp-upnp-igd-interworking-01. This call will=20 >conclude in two >> weeks (Friday July 27th), just prior to IETF. Hopefully=20 >that will allow >> for discussion of WGLC comments in Vancouver. >>=20 >> We need at least 5 reviewers. Please send comments to the list. >>=20 >> Thanks, >> -Dave >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From zhangdacheng@huawei.com Tue Jul 31 03:53:07 2012 Return-Path: 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 BF23021F86B2 for ; Tue, 31 Jul 2012 03:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 z7fxWloAhXrl for ; Tue, 31 Jul 2012 03:53:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68521F86B0 for ; Tue, 31 Jul 2012 03:53:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIF71922; Tue, 31 Jul 2012 06:53:06 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 03:51:01 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 03:51:00 -0700 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.120]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Tue, 31 Jul 2012 18:50:57 +0800 From: "Zhangdacheng (Dacheng)" To: "pcp@ietf.org" Thread-Topic: About selecting a key management for PCP Thread-Index: AQHNbwnvoZws8buZFUaBTiMDCJuBlw== Date: Tue, 31 Jul 2012 10:50:56 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Margaret Wasserman Subject: [pcp] About selecting a key management for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 10:53:07 -0000 Hi, All:=0A= =0A= We have a discussion about the selection of a key management mechanism for = PCP, but there is not a conclusion yet. Basically, people focus on two solu= tions, using PANA or generating an in-band authenticaiton mchanism for PCP = (actually a simplified PANA). Now, there is a new draft draft-ohba-pcp-pana= -00, which tries to specify the first one. So, maybe it is the right time t= o raise this disucssion again and decide the key management solution for PC= P eventually.=0A= =0A= Cheers=0A= =0A= Dacheng= From dthaler@microsoft.com Tue Jul 31 10:13:40 2012 Return-Path: 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 07AED21F8733 for ; Tue, 31 Jul 2012 10:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NZEGomAAeGZJ for ; Tue, 31 Jul 2012 10:13:39 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 469F321F8732 for ; Tue, 31 Jul 2012 10:13:39 -0700 (PDT) Received: from mail247-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 17:13:38 +0000 Received: from mail247-ch1 (localhost [127.0.0.1]) by mail247-ch1-R.bigfish.com (Postfix) with ESMTP id 5607D1D0024A for ; Tue, 31 Jul 2012 17:13:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail247-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail247-ch1 (localhost.localdomain [127.0.0.1]) by mail247-ch1 (MessageSwitch) id 1343754816476559_10350; Tue, 31 Jul 2012 17:13:36 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail247-ch1.bigfish.com (Postfix) with ESMTP id 681336C0048 for ; Tue, 31 Jul 2012 17:13:36 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 17:13:35 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 17:13:35 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 10:13:34 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 31 Jul 2012 10:13:34 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Volunteers for notetaker and jabber scribe Thread-Index: Ac1vP22q8nSN5aRmTX+q5XNEr+ISRQ== Date: Tue, 31 Jul 2012 17:13:34 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B73049F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B73049FTK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Volunteers for notetaker and jabber scribe X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 17:13:40 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B73049FTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As usual, we need at least one notetaker and a jabber scribe. It's usually easy for us to find a notetaker (Stuart Cheshire and Paul Selkirk have both been great at volunteering for this), but often harder to find a jabber scribe. Please let me know if you are willing to volunteer. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B73049FTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As usual, we need at least one notetaker and a jabbe= r scribe.

 

It’s usually easy for us to find a notetaker (= Stuart Cheshire and

Paul Selkirk have both been great at volunteering fo= r this), but

often harder to find a jabber scribe.

 

Please let me know if you are willing to volunteer.<= o:p>

 

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B73049FTK5EX14MBXW604w_-- From volz@cisco.com Fri Jul 27 07:47:06 2012 Return-Path: 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 E290D21F87BF; Fri, 27 Jul 2012 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 LAQeg+Xg6B74; Fri, 27 Jul 2012 07:47:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4B421F87B9; Fri, 27 Jul 2012 07:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=9431; q=dns/txt; s=iport; t=1343400425; x=1344610025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MLkZ/ShM+/2Wb3p/c59ImJFB3UY3AWoj8BeDVKNXzeo=; b=bVbaJ87OmjpemUggroZkTYOl9y8FCf0ZpJoatrKDDSZmICBQECF6GJAc 6bIxNF4mR1eOhoqQPXTUIFy53b4/cbLAf3USAeIoJ8EbcNPotBL6NIRuX nRUwbnN1dbxDNyeycyVRcUwGeExigbHhVQNyH/eTQS/X2gqAjXw4TgoUN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGGpElCtJV2c/2dsb2JhbABFuTyBB4IgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBCxQJBycLFAkIAQEEAQ0FCBqHZQYLmXugVwSLUAqGCmADkWWSCoFmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,667,1336348800"; d="scan'208";a="106019554" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2012 14:47:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6REl40E021995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 14:47:04 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 09:47:04 -0500 From: "Bernie Volz (volz)" To: Dave Thaler , "dhcwg@ietf.org" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTw Date: Fri, 27 Jul 2012 14:47:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--76.412700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 31 Jul 2012 14:03:41 -0700 Cc: "pcp@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 14:47:07 -0000 Dave: As the options as defined contain a domain name (encoded per RFC 1035) are = address literals really appropriate? This also has consequences for configu= ring the option data in the servers. And, it seems rather bad to take an en= coded name, convert it to a string, only to convert it back into an encoded= name. But, alas, that is likely given the common APIs. Also, given that RFC 1035 section 3.1 states:=20 Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. And the option is to accommodate a list of domain names (knowing that each = terminates in the null label makes it possible to separate them), how do yo= u propose that literals (10.1.2.3) be encoded so that it not end up as the = domain name "10.1.2.3.". Perhaps there is a convention used to do this somewhere? (I admit I haven't= looked at draft-iab-identifier-comparison carefully.) When reviewing this and commenting the other day, I originally had thought = about commenting on the rather strict rules as to how the results of DNS qu= eries could be used and was thinking that it might be appropriate to relax = them some. Just doing normal DNS lookups and using the results (AAAA if v6 = is available, A if v4 is available, etc.) would likely make implementing th= is much easier and require less specialized code. > 6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." Good catch. This should be removed as we have the ability to support long v= 4 options - see RFC 3396. Note that per section 4 of this RFC: Let us divide all DHCP options into two categories - those that, by definition, require implementation of the mechanisms defined in this document, and those that do not. We will refer to the former as concatenation-requiring options, and the latter as non- concatenation-requiring options. In order for an option to be a concatenation-requiring option, the protocol specification that defines that option must require implementation of option splitting and option concatenation as described in this document, by specifically referencing this document. So the draft should reference RFC 3396 and indicate that this is a concaten= ation-requiring option. - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of D= ave Thaler Sent: Thursday, July 26, 2012 5:59 PM To: dhcwg@ietf.org Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 I keep mangling the WG mailing list address, so forwarding. -----Original Message----- From: Dave Thaler Sent: Thursday, July 26, 2012 2:58 PM To: 'pcp@ietf.org' Cc: 'dhc@ietf.org' Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 Missed responding to section 7 before sending... 7) Re "A PCP Server configured using OPTION_PCP_SERVER over DHCPv4 is likel= y to be resolved to IPv4 address(es)." I don't think I'd agree with that assumption. If I put a DNS name in = the option, it'll be resolved to whatever records are in DNS of a type the client q= ueries for. The document currently doesn't say what type(s) to query for (A vs AAAA)= . Per my comment on 2, I believe the types to query for should be independ= ent of how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or whatever els= e). =20 "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" By the same reasoning as my previous comment above, it may also be resol= ved to IPv4 addresses. If I have a dual-stack PCP server, I should be able= to put the same DNS name in both a DHCPv4 option and a DHCPv6 option, rather than requiring me to have two separate names for the same server. 8) Pursuant to a discussion I've been having with some folks on draft-iab-identifier-comparison section 3.1.1 and some changes I'll be = making to it as a result, it got me thinking. I'm thinking it would be good to h= ave a short subsection on Guidance to Administrators on what to configure in their = DHCP server to return in these options, or more importantly, what not to con= figure. Specifically, strings like "10.0.258", "0xA000001", and "012.0x102" wou= ld all be a bad idea to configure (unless you specified how they're to be = interpreted which is an option, though probably not the most expedient one). I'm = still strongly in favor of retaining the fact that it's a string that can be passed to= name resolution APIs, but that means it's best to avoid strings that are int= erpreted differently by different such APIs. 9) On the same point, Section 4.2 currently states: "Once each Name conveyed in the OPTION_PCP_SERVER option is validated, each included Name is passed to the name resolution library (e.g., Section 6.1.1 of [RFC1123] or [RFC6055])" The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in particular a= re=20 problematic because as worded a client that chose not to support IP lite= rals would be legal, and it would try to resolve "10.11.12.13" in DNS, which = we don't want. Surprising (as draft-iab-identifier-comparison already poi= nts out), even [RFC1123] allows this to be optional (a "SHOULD") in: "The host SH= OULD check the string syntactically for a dotted-decimal number before looking it u= p in=20 the Domain Name System." Instead it's important here to require that the client be able to=20 use IP literals. Most name resolution APIs (gethostbyname, getaddrinfo= , etc.) all meet that criteria. -Dave > -----Original Message----- > From: Dave Thaler > Sent: Thursday, July 26, 2012 2:32 PM > To: pcp@ietf.org > Cc: dhc@ietf.org > Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >=20 > Here's my personal comments on draft -03... I have a few editorial=20 > nits I'll just send to the authors. >=20 > 1) I agree with the conclusion of the rationale but the sentence > "DHC WG's position is this flexibility have some drawbacks such as i= nducing > errors." > isn't intelligible. What does "inducing errors" mean? Either expla= in or > remove. >=20 > 2) The text on what to do with a name conveyed in an option is duplicated= in > Section 4.2 and 5.2. I'd prefer that this be specified only once, t= o avoid > opportunities for discrepancies. That is, section 4.2's first two p= aragraphs > are > fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 > about how to get > the name out of the option. The rest isn't DHCPv4 or DHCPv6 specif= ic and > should be in its own subsection. >=20 > 3) Re "It is RECOMMENDED to associate a validity lifetime with any addres= s > resulting from resolving the Name". The text should be more specific= about > what the validity lifetime should be. If the name is resolved in DN= S, I'd > say the validity lifetime should be the TTL of the DNS record. >=20 > 4) Re "When an > application issues a PCP request to a PCP Server, the source addres= s > of the request MUST be among those assigned on the interface to whi= ch > the destination PCP Server is bound. >=20 > This doesn't belong in a DHCP-specific document, it's out of scope. = That's > the job of the pcp-base spec. >=20 > 5) Same as point 4, but for all of section 6. In my view it belongs eith= er in > pcp-base or perhaps more likely in a separate spec that's not DHCP spe= cific. > E.g., if I manually configure one or more names, the same behavior=20 > should apply. >=20 > 6) Section 5.2 says: > "The DHCPv4 client MUST verify that the > option length does not exceed 255 octets [RFC1035])." >=20 > What does this mean? The length field is only 1 byte so cannot conta= in > a value larger than 255 anyway. So what exactly is a client supposed= to > "verify" here? >=20 > -Dave >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 > > Of Dave Thaler > > Sent: Wednesday, July 18, 2012 2:21 PM > > To: pcp@ietf.org > > Cc: dhc@ietf.org > > Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 > > > > As discussed at last IETF, the authors believe that all issues=20 > > raised so far have been addressed. No new issues have been raised=20 > > since then, so this message begins a Working Group Last Call on > > draft-ietf-pcp- > dhcp-03. > > > > This call would normally conclude in two weeks but that is during=20 > > IETF week, so the last call is extended to conclude at the end of=20 > > IETF (as of the Friday PCP meeting). > > > > We also agreed in Vancouver that this last call will be cross-posted=20 > > to the DHC list, hence cc'ing the DHC WG. > > > > We need at least 5 reviewers. Please send comments to the list. > > > > Thanks, > > -Dave Thaler > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From volz@cisco.com Fri Jul 27 13:38:06 2012 Return-Path: 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 55F3921F85F3; Fri, 27 Jul 2012 13:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 S87UFP-oCm6o; Fri, 27 Jul 2012 13:38:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37421F85F2; Fri, 27 Jul 2012 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=16068; q=dns/txt; s=iport; t=1343421483; x=1344631083; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e12zZGbyi+Z5+u6hid4FO/fTuEJjXIAPyJItlu5b8AI=; b=NbGDrG7lsALLcnUTxL/3T1JI4J/F0aQN4mgBakS12veBruM4jK2z6GuU z+rWeoHqvJZeGqxHjTyToZNvgxEVJDNmYT6yX7E2HEr/b9wgBfdhmHFpg lnpWymI6kDiRC5qh62qbq9ClPuwtJG578DKM0T0/JI6ThBBhQeMEgFlXK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFANn6ElCtJV2Z/2dsb2JhbABFgkqmIogOAYhXgQeCIAEBAQQSARpMEAIBCBEEAQELHQcyFAkIAgQBDQUIEweHawuaR6Bgi1AVhX9gA5ZcjROBZoJfgVcI X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208,217";a="106134007" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2012 20:38:03 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6RKc2Wv001074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 20:38:02 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.206]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 15:36:10 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Dave Thaler Thread-Topic: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAAl/+jAAD/3vgAAN07dw Date: Fri, 27 Jul 2012 20:16:53 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E02CE85@xmb-rcd-x04.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B72551C@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19068.001 x-tm-as-result: No--46.700100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 31 Jul 2012 14:03:41 -0700 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 20:38:06 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted: I think sending domains names for the client to process is far more dynamic= . Also, the draft specifies use of domain names. When does the DHCP server do this resolution (from domain name to address)? - During configuration (which doesn't allow for any change in the = information) - i.e., when the operator first enters the information. - During startup (i.e., when the server reads the configuration) -= (which would require a reload and might have serious performance issues if= DNS is unavailable when the server is reloaded) - During each client request (which have serious performance issue= s if DNS is unavailable) You can see that these three approaches (and perhaps there are more) are mu= ch less dynamic than having the client get the information when needed and = also don't negatively impact the DHCP server (and thus other clients that m= ight not be relying on DNS) when DNS is unavailable. One might limit the ti= me one waits for the resolution, but what do you send if you can't resolve? This is the grand old debate about whether one should send addresses, domai= n names, or both (in which case we've sometimes defined two options or defi= ned suboptions or an encoding format). And, we sadly have never really solv= ed this issue within the DHC WG. The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does s= eem to indicate your solution, but it never specifies "when" this resolutio= n should be done. I think that's likely and issue we need to discuss about = this guidelines draft. (There's a few other oddities in that draft that sho= uld be corrected - why for example is it picking on DHCPv6 - "DHCPv6 stands= for Dynamic Host Configuration Protocol for IPv6. Contrary to its name, i= s many contexts it is not dynamic."; DHCPv4 was no better and actually wors= e since ForceRenew is really not implemented.) But that is likely for anoth= er email thread or for discussion on Monday at the DHC WG meeting. - Bernie From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Friday, July 27, 2012 3:34 PM To: Dave Thaler Cc: Bernie Volz (volz); dhcwg@ietf.org; pcp@ietf.org Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote: Right. I think the goal should be to minimize the amount of processing th= e client has to do with the option contents... just pass it to getaddrinfo() = or equivalent was what the WG had discussed. Remembering that the DHCP server automatically translates names to IP addre= sses in its configuration, why is it necessary to place this burden on the = client? Traditionally DHCP just sends IP addresses, not names, precisely = because it minimizes the burden on the client while maintaining the flexibi= lity of doing name translation on the server. I assume you already consid= ered this, because I'm pretty sure you've seen debates about this go by bef= ore, but I'm curious as to why you decided to send a name rather than an IP= address. --_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ted:

 <= /p>

I think sending domains n= ames for the client to process is far more dynamic. Also, the draft specifi= es use of domain names.

 <= /p>

When does the DHCP server= do this resolution (from domain name to address)?

- =          During configurat= ion (which doesn’t allow for any change in the information) – i= .e., when the operator first enters the information.

- =          During startup (i= .e., when the server reads the configuration) - (which would require a relo= ad and might have serious performance issues if DNS is unavailable when the server is reloaded)

- =          During each clien= t request (which have serious performance issues if DNS is unavailable)

You can see that these th= ree approaches (and perhaps there are more) are much less dynamic than havi= ng the client get the information when needed and also don’t negatively impact the DHCP server (and thus other clients that might not b= e relying on DNS) when DNS is unavailable. One might limit the time one wai= ts for the resolution, but what do you send if you can’t resolve?

 <= /p>

This is the grand old deb= ate about whether one should send addresses, domain names, or both (in whic= h case we’ve sometimes defined two options or defined suboptions or an encoding format). And, we sadly have never really solved this issue = within the DHC WG.

 <= /p>

The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does seem to indicate your solution, but it never specifies “when” this resolution should= be done. I think that’s likely and issue we need to discuss about th= is guidelines draft. (There’s a few other oddities in that draft that= should be corrected – why for example is it picking on DHCPv6 - “DHCPv6 stands for Dynamic Host Configuration Protocol for = IPv6.  Contrary to its name, is many contexts it is not dynamic.”= ;; DHCPv4 was no better and actually worse since ForceRenew is really not i= mplemented.) But that is likely for another email thread or for discussion on Monday at the DHC WG meeting.

 <= /p>

- =          Bernie=

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Friday, July 27, 2012 3:34 PM
To: Dave Thaler
Cc: Bernie Volz (volz); dhcwg@ietf.org; pcp@ietf.org
Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03

 

On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote:=

Righ= t.   I think the goal should be to minimize the amount of process= ing the
client has to do with the option contents.= .. just pass it to getaddrinfo() or
equivalent was what the WG had discussed.<= /span>

 

Remembering that the DHCP server automatically trans= lates names to IP addresses in its configuration, why is it necessary to pl= ace this burden on the client?   Traditionally DHCP just sends IP addr= esses, not names, precisely because it minimizes the burden on the client while maintaining the flexibility of do= ing name translation on the server.   I assume you already considered = this, because I'm pretty sure you've seen debates about this go by before, = but I'm curious as to why you decided to send a name rather than an IP address.

 

--_000_489D13FBFA9B3E41812EA89F188F018E02CE85xmbrcdx04ciscocom_-- From volz@cisco.com Mon Jul 30 06:18:33 2012 Return-Path: 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 3A4AC21F878B; Mon, 30 Jul 2012 06:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 sHfQzCmzTuO1; Mon, 30 Jul 2012 06:18:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BBBB621F8786; Mon, 30 Jul 2012 06:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=11169; q=dns/txt; s=iport; t=1343654311; x=1344863911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DJvMD6H3iXkRN/y36sGZ40OG+R9JuWwuR5NBJvJ86lo=; b=YDdnnVUvr333dhI5OpvREPVcHYYt0IyhG1gQyAIUiuB8PT5VvKYSWn8D SNRfqRKadbhQkQnRKxIHiB/PU2So9QCDmfaHUQHCzn3HeLs7zRzAGPjJj qO8fhP9MsmOOj+7KSCJj9/vrd+9qZ4HzIUnhu568f2sEMcHjKAMYjnvvj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPaIFlCtJV2a/2dsb2JhbABFuVaBB4IgAQEBAwEBAQEPAVsLBQcEAgEIEQQBASgHJwsUCQgCBA4FIodlBguaVJ9cBItQCoV4YAOIGIlOg2OOJ4Fmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,679,1336348800"; d="scan'208";a="106630400" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2012 13:18:31 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6UDIVF5021058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 13:18:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 08:18:30 -0500 From: "Bernie Volz (volz)" To: "mohamed.boucadair@orange.com" Thread-Topic: WGLC on draft-ietf-pcp-dhcp-03 Thread-Index: Ac1lKbWyQQI76YWORI2Pw5j/xa2lTwGSVp6QAAD2YUAAALuhAAAiadTwAJFlwDAAAy4+fA== Date: Mon, 30 Jul 2012 13:18:29 +0000 Message-ID: <3EDDE74B-8637-4D47-AABD-0226036E9496@cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B70B231@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7235BF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <489D13FBFA9B3E41812EA89F188F018E02CD82@xmb-rcd-x04.cisco.com>, <94C682931C08B048B7A8645303FDC9F36E4A17E910@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E910@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19072.005 x-tm-as-result: No--78.520400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 31 Jul 2012 14:03:41 -0700 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 13:18:33 -0000 Yes, assuming you removed the text in 5.2 that Dave pointed out. - Bernie On Jul 30, 2012, at 7:49 AM, "mohamed.boucadair@orange.com" wrote: > Dear Bernie, >=20 > See inline. >=20 > Cheers, > Med >=20 >=20 >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De=20 >> la part de Bernie Volz (volz) >> Envoy=E9 : vendredi 27 juillet 2012 16:47 >> =C0 : Dave Thaler; dhcwg@ietf.org >> Cc : pcp@ietf.org >> Objet : Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Dave: >>=20 >> As the options as defined contain a domain name (encoded per=20 >> RFC 1035) are address literals really appropriate? This also=20 >> has consequences for configuring the option data in the=20 >> servers. And, it seems rather bad to take an encoded name,=20 >> convert it to a string, only to convert it back into an=20 >> encoded name. But, alas, that is likely given the common APIs. >>=20 >> Also, given that RFC 1035 section 3.1 states:=20 >>=20 >> Since every domain name ends with the null label of >> the root, a domain name is terminated by a length byte of zero. >>=20 >> And the option is to accommodate a list of domain names=20 >> (knowing that each terminates in the null label makes it=20 >> possible to separate them), how do you propose that literals=20 >> (10.1.2.3) be encoded so that it not end up as the domain name=20 >> "10.1.2.3.". >>=20 >> Perhaps there is a convention used to do this somewhere? (I=20 >> admit I haven't looked at draft-iab-identifier-comparison carefully.) >>=20 >>=20 >> When reviewing this and commenting the other day, I originally=20 >> had thought about commenting on the rather strict rules as to=20 >> how the results of DNS queries could be used and was thinking=20 >> that it might be appropriate to relax them some. Just doing=20 >> normal DNS lookups and using the results (AAAA if v6 is=20 >> available, A if v4 is available, etc.) would likely make=20 >> implementing this much easier and require less specialized code. >>=20 >>=20 >>> 6) Section 5.2 says: >>> "The DHCPv4 client MUST verify that the >>> option length does not exceed 255 octets [RFC1035])." >>=20 >> Good catch. This should be removed as we have the ability to=20 >> support long v4 options - see RFC 3396. >>=20 >> Note that per section 4 of this RFC: >>=20 >> Let us divide all DHCP options into two categories - those that, by >> definition, require implementation of the mechanisms defined in this >> document, and those that do not. We will refer to the former as >> concatenation-requiring options, and the latter as non- >> concatenation-requiring options. In order for an option to be a >> concatenation-requiring option, the protocol specification that >> defines that option must require implementation of option splitting >> and option concatenation as described in this document, by >> specifically referencing this document. >>=20 >> So the draft should reference RFC 3396 and indicate that this=20 >> is a concatenation-requiring option. >=20 > Med: I added this text to Section 5.1.=20 >=20 > The OPTION_PCP_SERVER DHCPv4 option is a concatenation-requiring > option. As such, the mechanism specified in [RFC3396] MUST be used > if the PCP Server Name option exceeds the maximum DHCPv4 option size > of 255 octets. >=20 > Does this solves your concern?=20 >=20 >=20 >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >> On Behalf Of Dave Thaler >> Sent: Thursday, July 26, 2012 5:59 PM >> To: dhcwg@ietf.org >> Subject: [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> I keep mangling the WG mailing list address, so forwarding. >>=20 >> -----Original Message----- >> From: Dave Thaler >> Sent: Thursday, July 26, 2012 2:58 PM >> To: 'pcp@ietf.org' >> Cc: 'dhc@ietf.org' >> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>=20 >> Missed responding to section 7 before sending... >>=20 >> 7) Re "A PCP Server configured using OPTION_PCP_SERVER over=20 >> DHCPv4 is likely >> to be resolved to IPv4 address(es)." >> I don't think I'd agree with that assumption. If I put a=20 >> DNS name in the option, >> it'll be resolved to whatever records are in DNS of a type=20 >> the client queries for. >> The document currently doesn't say what type(s) to query=20 >> for (A vs AAAA). >> Per my comment on 2, I believe the types to query for=20 >> should be independent of >> how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or=20 >> whatever else). >>=20 >> "A PCP Server configured using OPTION_PCP_SERVER over DHCPv6 may be >> resolved to IPv4-mapped IPv6 address(es) or IPv6 address(es)" >> By the same reasoning as my previous comment above, it may=20 >> also be resolved >> to IPv4 addresses. If I have a dual-stack PCP server, I=20 >> should be able to put >> the same DNS name in both a DHCPv4 option and a DHCPv6=20 >> option, rather >> than requiring me to have two separate names for the same server. >>=20 >> 8) Pursuant to a discussion I've been having with some folks on >> draft-iab-identifier-comparison section 3.1.1 and some=20 >> changes I'll be making to >> it as a result, it got me thinking. I'm thinking it would=20 >> be good to have a short >> subsection on Guidance to Administrators on what to=20 >> configure in their DHCP >> server to return in these options, or more importantly,=20 >> what not to configure. >> Specifically, strings like "10.0.258", "0xA000001", and=20 >> "012.0x102" would >> all be a bad idea to configure (unless you specified how=20 >> they're to be interpreted >> which is an option, though probably not the most expedient=20 >> one). I'm still strongly >> in favor of retaining the fact that it's a string that can=20 >> be passed to name >> resolution APIs, but that means it's best to avoid strings=20 >> that are interpreted >> differently by different such APIs. >>=20 >> 9) On the same point, Section 4.2 currently states: >> "Once each Name conveyed in the OPTION_PCP_SERVER option is=20 >> validated, >> each included Name is passed to the name resolution library (e.g., >> Section 6.1.1 of [RFC1123] or [RFC6055])" >> The ambiguity of "e.g." and "section 6.1.1 of [RFC1123]" in=20 >> particular are=20 >> problematic because as worded a client that chose not to=20 >> support IP literals >> would be legal, and it would try to resolve "10.11.12.13"=20 >> in DNS, which we >> don't want. Surprising (as=20 >> draft-iab-identifier-comparison already points out), >> even [RFC1123] allows this to be optional (a "SHOULD") in: =20 >> "The host SHOULD check >> the string syntactically for a dotted-decimal number before=20 >> looking it up in=20 >> the Domain Name System." >>=20 >> Instead it's important here to require that the client be able to=20 >> use IP literals. Most name resolution APIs=20 >> (gethostbyname, getaddrinfo, >> etc.) all meet that criteria. >>=20 >> -Dave >>=20 >>> -----Original Message----- >>> From: Dave Thaler >>> Sent: Thursday, July 26, 2012 2:32 PM >>> To: pcp@ietf.org >>> Cc: dhc@ietf.org >>> Subject: RE: WGLC on draft-ietf-pcp-dhcp-03 >>>=20 >>> Here's my personal comments on draft -03... I have a few editorial=20 >>> nits I'll just send to the authors. >>>=20 >>> 1) I agree with the conclusion of the rationale but the sentence >>> "DHC WG's position is this flexibility have some=20 >> drawbacks such as inducing >>> errors." >>> isn't intelligible. What does "inducing errors" mean? =20 >> Either explain or >>> remove. >>>=20 >>> 2) The text on what to do with a name conveyed in an option=20 >> is duplicated in >>> Section 4.2 and 5.2. I'd prefer that this be specified=20 >> only once, to avoid >>> opportunities for discrepancies. That is, section=20 >> 4.2's first two paragraphs >>> are >>> fine, as are the first 1 1/2 paragraphs of 5.2, since those are=20 >>> about how to get >>> the name out of the option. The rest isn't DHCPv4 or=20 >> DHCPv6 specific and >>> should be in its own subsection. >>>=20 >>> 3) Re "It is RECOMMENDED to associate a validity lifetime=20 >> with any address >>> resulting from resolving the Name". The text should be=20 >> more specific about >>> what the validity lifetime should be. If the name is=20 >> resolved in DNS, I'd >>> say the validity lifetime should be the TTL of the DNS record. >>>=20 >>> 4) Re "When an >>> application issues a PCP request to a PCP Server, the=20 >> source address >>> of the request MUST be among those assigned on the=20 >> interface to which >>> the destination PCP Server is bound. >>>=20 >>> This doesn't belong in a DHCP-specific document, it's out=20 >> of scope. That's >>> the job of the pcp-base spec. >>>=20 >>> 5) Same as point 4, but for all of section 6. In my view it=20 >> belongs either in >>> pcp-base or perhaps more likely in a separate spec that's=20 >> not DHCP specific. >>> E.g., if I manually configure one or more names, the same=20 >> behavior=20 >>> should apply. >>>=20 >>> 6) Section 5.2 says: >>> "The DHCPv4 client MUST verify that the >>> option length does not exceed 255 octets [RFC1035])." >>>=20 >>> What does this mean? The length field is only 1 byte so=20 >> cannot contain >>> a value larger than 255 anyway. So what exactly is a=20 >> client supposed to >>> "verify" here? >>>=20 >>> -Dave >>>=20 >>>> -----Original Message----- >>>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf=20 >>>> Of Dave Thaler >>>> Sent: Wednesday, July 18, 2012 2:21 PM >>>> To: pcp@ietf.org >>>> Cc: dhc@ietf.org >>>> Subject: [pcp] WGLC on draft-ietf-pcp-dhcp-03 >>>>=20 >>>> As discussed at last IETF, the authors believe that all issues=20 >>>> raised so far have been addressed. No new issues have been raised=20 >>>> since then, so this message begins a Working Group Last Call on >>>> draft-ietf-pcp- >>> dhcp-03. >>>>=20 >>>> This call would normally conclude in two weeks but that is during=20 >>>> IETF week, so the last call is extended to conclude at the end of=20 >>>> IETF (as of the Friday PCP meeting). >>>>=20 >>>> We also agreed in Vancouver that this last call will be=20 >> cross-posted=20 >>>> to the DHC list, hence cc'ing the DHC WG. >>>>=20 >>>> We need at least 5 reviewers. Please send comments to the list. >>>>=20 >>>> Thanks, >>>> -Dave Thaler >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg