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

[<[e-mail]>]

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
>