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
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03
Precedence: list

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
>=