Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03
<mohamed.boucadair@orange.com> Mon, 30 July 2012 11:49 UTC
Return-Path: <mohamed.boucadair@orange.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 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: mohamed.boucadair@orange.com
To: "Bernie Volz (volz)" <volz@cisco.com>, Dave Thaler <dthaler@microsoft.com>, "dhcwg@ietf.org" <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" <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 11:49:06 -0000
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)