Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03
"Bernie Volz (volz)" <volz@cisco.com> Mon, 30 July 2012 13:18 UTC
Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@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)" <volz@cisco.com>
To: "mohamed.boucadair@orange.com" <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
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=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" <mohamed.boucadair@orange.com> wrote: > Dear Bernie, > > See inline. > > Cheers, > Med > > >> -----Message d'origine----- >> De : dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] De >> la part de Bernie Volz (volz) >> Envoyé : vendredi 27 juillet 2012 16:47 >> À : 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 >> RFC 1035) are address literals really appropriate? This also >> has consequences for configuring the option data in the >> servers. And, it seems rather bad to take an encoded 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: >> >> 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 you 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 queries 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 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 >> 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 >> is a concatenation-requiring option. > > Med: I added this text to Section 5.1. > > 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? > > >> >> - Bernie >> >> -----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 >> >> 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 likely >> 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 queries 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 independent of >> how the name was obtained (DHCPv4, DHCPv6, manual, SNMP, or >> whatever else). >> >> "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 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 have 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 configure. >> Specifically, strings like "10.0.258", "0xA000001", and >> "012.0x102" would >> 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 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 >> 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 literals >> 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 points 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." >> >> Instead it's important here to require that the client be able to >> 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 >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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? >>> >>> -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 >> >> >> _______________________________________________ >> 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
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Dave Thaler
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Bernie Volz (volz)
- [dhcwg] FW: WGLC on draft-ietf-pcp-dhcp-03 Dave Thaler
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 mohamed.boucadair
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Bernie Volz (volz)
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Dave Thaler
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Dave Thaler
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Ted Lemon
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Bernie Volz (volz)
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Ted Lemon
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 mohamed.boucadair
- Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03 Bernie Volz (volz)