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

From: Dave Thaler <[email-masked]>
Date: Wed, 18 Jul 2012 21:50:21 +0000

Correcting DHC WG email address.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
> Thaler
> Sent: Wednesday, July 18, 2012 2:21 PM
> To: [email-masked]
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 19 Jul 2012 16:08:41 +0000

The document seems OK (reviewing from the DHC WG perspective).

Minor nits:

1)

2. Terminology
   o  DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315].
   o  DHCP client (or client) denotes a node that initiates requests to
      obtain configuration parameters from one or more DHCP servers
      [RFC3315].
   o  DHCP server (or server) refers to a node that responds to requests
      from DHCP clients [RFC3315].

Why are DHCP client / DHCP server just RFC 3315 and use of "DHCP" here implies RFC 2131 and 3315 from the earlier terminology.

2)

4.1.  Format

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_PCP_SERVER        |         Option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                    PCP Server Domain Name                     :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: PCP Server Name DHCPv6 Option

   The fields of the option shown in Figure 1 are as follows:

   o  Option-code: OPTION_PCP_SERVER (TBA, see Section 9.1)
   o  Option-length: Length of the 'PCP Server Domain Name' field in
      octets.
   o  PCP Server Domain Name: The domain name of the PCP Server to be
      used by the PCP Client.  The domain name is encoded as specified
      in Section 8 of [RFC3315].

   The OPTION_PCP_SERVER option can include multiple PCP Server Domain
   Names; each Name is treated as a separate PCP Server.

Would it not be appropriate to change the "PCP Server Domain Name" to be "PCP Server Domain Name(s)"? And make the description clear that it can be one or more rather than adding this later (where it easily might be missed).

The same applies to the DHCPv4 option (section 5.1).

3)

Be nice if the DHCPv4 domain name encoding clarified that compression was not allowed (though RFC 1035 section 3.1 does not say anything about that topic)? Perhaps use the RFC 3315 Section 8 text:

   A domain name, or list of domain  names, in DHCP MUST NOT be stored in compressed form, as described in
   section 4.1.4 of RFC 1035.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Wednesday, July 18, 2012 5:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Dave Thaler
> 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.
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Dave Thaler <[email-masked]>
Date: Thu, 26 Jul 2012 21:59:14 +0000

I keep mangling the WG mailing list address, so forwarding.

-----Original Message-----
From: Dave Thaler 
Sent: Thursday, July 26, 2012 2:58 PM
To: [email-masked]'
Cc: [email-masked]'
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

> From: Dave Thaler
> Sent: Thursday, July 26, 2012 2:32 PM
> To: [email-masked]
> Cc: [email-masked]
> 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
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Dave Thaler
> > 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).
> >

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 10:24:56 +0200

Dear Bernie,

Thank you for the review. 

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Bernie Volz (volz)
>Envoyé : jeudi 19 juillet 2012 18:09
>À : Dave Thaler; [email-masked]
>Cc : [email-masked]
>Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03
>
>Why are DHCP client / DHCP server just RFC 3315 and use of 
>"DHCP" here implies RFC 2131 and 3315 from the earlier terminology.
>

Med: Fixed. The new text is: 

   o  DHCP client (or client) denotes a node that initiates requests to
      obtain configuration parameters from one or more DHCP servers.
   o  DHCP server (or server) refers to a node that responds to requests
      from DHCP clients.

>Would it not be appropriate to change the "PCP Server Domain 
>Name" to be "PCP Server Domain Name(s)"? And make the 
>description clear that it can be one or more rather than 
>adding this later (where it easily might be missed).
>

Med: Done.  The new text is:

   o  PCP Server Domain Name(s): The domain name s) of the PCP Server to
      be used by the PCP Client.  The OPTION_PCP_SERVER option can
      include multiple PCP Server Domain Names; each Name is treated as
      a separate PCP Server.  The domain name(s) is encoded as specified
      in Section 8 of [RFC3315].

And 

   o  PCP Server Domain Name(s): The domain name(s) of the PCP Server to
      be used by the PCP Client when issuing PCP messages.  The
      OPTION_PCP_SERVER option can include multiple PCP Server Domain
      Names; each Name is treated as a separate PCP Server.  The
      encoding of the domain name(s) is described in Section 3.1 of
      [RFC1035].  

>
>3)
>
>Be nice if the DHCPv4 domain name encoding clarified that 
>compression was not allowed (though RFC 1035 section 3.1 does 
>not say anything about that topic)? Perhaps use the RFC 3315 
>Section 8 text:
>
>   A domain name, or list of domain  names, in DHCP MUST NOT 
>be stored in compressed form, as described in

Med: I added this sentence to Section 5: 

"The domain name(s) MUST NOT be stored in compressed
      form, as described in Section 4.1.4 of [RFC1035]."

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Jul 2012 14:47:04 +0000

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.

>      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.

- Bernie

-----Original Message-----
From: Dave Thaler
Sent: Thursday, July 26, 2012 2:58 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: WGLC on draft-ietf-pcp-dhcp-03

   

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 27 Jul 2012 19:06:27 +0000

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Friday, July 27, 2012 7:47 AM
> To: Dave Thaler; [email-masked]
> Cc: [email-masked]
> 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.
>
> 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.)

(draft-iab-identifier-comparison isn't relevant to that particular question.)
The WG goal was to be able to configure a set of strings that can be passed to
an API such as getaddrinfo() where the string can be either an IP literal or a
domain name.   I take your point as saying that using the encoding defined
in RFC 1035 section 3.1 isn't sufficient without an additional statement
that the trailing dot should be removed.   The only other alternative
I see would be to not use that encoding but define some other encoding.

> 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.

Right.   I think the goal should be to minimize the amount of processing the
client has to do with the option contents... just pass it to getaddrinfo() or
equivalent was what the WG had discussed.

> concatenation-requiring option.

Agree.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 27 Jul 2012 19:20:01 +0000

> Sent: Friday, July 27, 2012 12:19 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03
> 
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Friday, July 27, 2012 2:01 AM
> > To: Dave Thaler; [email-masked]
> > Cc: [email-masked]
> > Dear Dave,
> > >De : [email-masked] [mailto:[email-masked]] De la part de
> > >Dave Thaler Envoyé : jeudi 26 juillet 2012 23:32 À : [email-masked] Cc :
> > >[email-masked] Objet : Re: [pcp] WGLC on draft-ietf-pcp-dhcp-03
> > >
> > >   isn't intelligible.   What does "inducing errors" mean?
> > >Either explain or remove.
> >
> > Med: This is point is discussed in detail here:
> > http://tools.ietf.org/html/draft-
> > ietf-dhc-option-guidelines-08#section-7. Would you be fine if we add a
> reference to that draft?
> 
> Yes, good idea.
> 
> > >    opportunities for discrepancies.   That is, section 4.2's
> > >first two paragraphs are
> > Med: There is some duplication there but it does not harm IMHO. I
> > prefer to maintain the text as it is.
> 
> I think it does harm.   The fact that the text is not identical means that
> a reader might interpret them differently, and have different implementations
> with different behavior.   That would not be correct.   So I think it's safest
> to have only one copy of the text.
> 
> Do others have an opinion on this?
> 
> > Med: I updated the text as follows:
> >
> >    It is RECOMMENDED to associate a validity lifetime (e.g., TTL of DNS
> >    record if the Name is resolved using DNS) with any address resulting
> >    from resolving the Name conveyed in a OPTION_PCP_SERVER DHCPv4
> option
> >    when stored in a local name resolution cache.
> >
> > Is this better?
> 
> Yes.
> 
> > >4) Re "When an
> > Med: I removed that sentence.
> >
> > Med: Dave, Section 6 is there because you requested it: see
> > http://www.ietf.org/mail-archive/web/pcp/current/msg01793.html. Since
> > we have the text now, I vote for keeping it. No need to create another
> > dependency with another document to come.
> 
> Thanks for the reminder and the pointer.   I agree that this spec needs to
> say something.  My preference would be to separate it into something
> non-DHCP specific.   But you're right about that possibly delaying the doc.
> So I'd suggest the following:
> 
> 1) Introduce a section header called something like "Use of PCP Server Names"
> 2) Make the section start with an introductory sentence saying this section
>    is applicable to any mechanism that configures server names, not just DHCP.
>    The first sentence of section 6 is a partial starting point for that.
> 3) Move the text I mentioned in point 2 (that I didn't want duplicated) to
>     a subsection of it, since that text isn't necessarily DHCP specific either.
> 4) Move section 6 under the "Use of PCP Server Names" section.
> 
> This allows any other future name configuration mechanism (CLI, SNMP, YANG,
> or whatever else) to reference a single section of this document, which has all
> the non-DHCP-specific content under it.
> 
> > >6) Section 5.2 says:
> > Med: The text does not talk about the length of the field but the value it
> carries.
> 
> I was talking about the value.
> See the exchange between Bernie and I for what this needs to say instead.
> 
> > >
> > >-Dave
> > >

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Jul 2012 19:34:10 +0000

On Jul 27, 2012, at 3:06 PM, Dave Thaler wrote:
Right.   I think the goal should be to minimize the amount of processing the
client has to do with the option contents... just pass it to getaddrinfo() or
equivalent was what the WG had discussed.

Remembering that the DHCP server automatically translates names to IP addresses in its configuration, why is it necessary to place this burden on the client?   Traditionally DHCP just sends IP addresses, not names, precisely because it minimizes the burden on the client while maintaining the flexibility of doing name translation on the server.   I assume you already considered this, because I'm pretty sure you've seen debates about this go by before, but I'm curious as to why you decided to send a name rather than an IP address.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 27 Jul 2012 20:16:53 +0000

Ted:

I think sending domains names for the client to process is far more dynamic. Also, the draft specifies use of domain names.

When does the DHCP server do this resolution (from domain name to address)?

-          During configuration (which doesn't allow for any change in the information) - i.e., when the operator first enters the information.

-          During startup (i.e., when the server reads the configuration) - (which would require a reload and might have serious performance issues if DNS is unavailable when the server is reloaded)

-          During each client request (which have serious performance issues if DNS is unavailable)
You can see that these three approaches (and perhaps there are more) are much less dynamic than having the client get the information when needed and also don't negatively impact the DHCP server (and thus other clients that might not be relying on DNS) when DNS is unavailable. One might limit the time one waits for the resolution, but what do you send if you can't resolve?

This is the grand old debate about whether one should send addresses, domain names, or both (in which case we've sometimes defined two options or defined suboptions or an encoding format). And, we sadly have never really solved this issue within the DHC WG.

The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does seem to indicate your solution, but it never specifies "when" this resolution should be done. I think that's likely and issue we need to discuss about this guidelines draft. (There's a few other oddities in that draft that should be corrected - why for example is it picking on DHCPv6 - "DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6.  Contrary to its name, is many contexts it is not dynamic."; DHCPv4 was no better and actually worse since ForceRenew is really not implemented.) But that is likely for another email thread or for discussion on Monday at the DHC WG meeting.

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, July 27, 2012 3:34 PM
To: Dave Thaler
Cc: Bernie Volz (volz); [email-masked]; [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-pcp-dhcp-03

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Jul 2012 22:30:48 +0000

On Jul 27, 2012, at 4:16 PM, Bernie Volz (volz) wrote:
The http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines does seem to indicate your solution, but it never specifies “when” this resolution should be done. I think that’s likely and issue we need to discuss about this guidelines draft.

That's an implementation issue; the same issue exists on the client.   Since you're setting up a tunnel, obviously the resolution happens when you set up the tunnel, and if the DNS changes after that, the client doesn't notice, tear down the tunnel, and set up a new one, does it?

As for how the server handles it, that's left up to the implementation.   The ISC DHCP server does the resolution when the request comes in, and if the DNS is down, it blocks.   Nominum's server does the resolution at request time too, but is a log smarter about not blocking and about responding if no answer comes from the DNS.   But really, if the DNS is down, you're hosed anyway, no matter who is doing the resolution.   You have to have reliable DNS.

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 13:48:53 +0200

Dear Bernie,

See inline.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De 
>la part de Bernie Volz (volz)
>Envoyé : vendredi 27 juillet 2012 16:47
>À : Dave Thaler; [email-masked]
>Cc : [email-masked]
>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.
>
>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:

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? 

>   don't want.   Surprising (as 
>draft-iab-identifier-comparison already points out),
>Either explain or

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 30 Jul 2012 13:18:29 +0000

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

- Bernie