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
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
Precedence: list

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.boucad=
air@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