Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03

["Bernie Volz (volz)" <[e-mail]>]

Yes, assuming you removed the text in 5.2 that Dave pointed out.

- Bernie

On Jul 30, 2012, at 7:49 AM, "[e-mail]" <[e-mail]> wrote:

> Dear Bernie,
> 
> See inline.
> 
> Cheers,
> Med
> 
> 
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]] De 
>> la part de Bernie Volz (volz)
>> Envoyé : vendredi 27 juillet 2012 16:47
>> À : Dave Thaler; [e-mail]
>> Cc : [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] 
>> On Behalf Of Dave Thaler
>> Sent: Thursday, July 26, 2012 5:59 PM
>> To: [e-mail]
>> 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: '[e-mail]'
>> Cc: '[e-mail]'
>> 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: [e-mail]
>>> Cc: [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On Behalf 
>>>> Of Dave Thaler
>>>> Sent: Wednesday, July 18, 2012 2:21 PM
>>>> To: [e-mail]
>>>> Cc: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/pcp
>> 
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg