Re: [pcp] draft-ietf-pcp-dhcp-05.txt

[Stuart Cheshire <[e-mail]>]

On 6 Nov 2012, at 3:41, [e-mail] wrote:

> Med: The new text in my local copy is as follows:
> 
>   o  Name is a string that can be passed to getaddrinfo (Section 6.1 of
>      [RFC3493]), such as a DNS name, address literals, etc.  The name
>      MUST NOT contain spaces or nulls.

It would be helpful to spell out exactly what strings are legal, for example:
 Dotted decimal IPv4 addresses - e.g. "10.1.2.3"
 IPv6 addresses in RFC 2373 text representation format - e.g. "FE80::A"
  - IPv6 addresses containing a scope identifier ("%en0") MUST be silently ignored
 Fully-Qualified Domain Names (ending with a dot) - e.g. "natgateway-7.isp.net."
  - Domain Names not ending in a trailing dot MUST be silently ignored

>>   Motivations for defining PCP option as a name and not an IP address
>>   are discussed in Appendix A.
> 
> Med: The sentence above is to say the option is not encoded as an IP address but as a name.

When I write the IP address "10.1.2.3" using ASCII characters it's still an IP address, not a name. Calling "10.1.2.3" a "name" is confusing to most readers. Call it an address.

> What about changing:
> 
> OLD:
> 
>   Motivations for defining PCP option as a name and not an IP address
>   are discussed in Appendix A.
> 
> NEW:
> 
>   Motivations for not defining PCP option as an IP address
>   are discussed in Appendix A

How about:
   Motivations for expressing the PCP option as a textual string rather than a 32- or 128-bit binary address are discussed in Appendix A.

> Med: 1035 encoding was abandoned as per the last IETF meeting. I added a reference to RFC3629. The new text is:
> 
>      The name is encoded as a UTF-8 [RFC3629] string.  When several
>      names are included, a space character is used as separator.

I suggest Net-Unicode [RFC5198].

Is the string null-terminated like a conventional C string?

Is there any precedent in DHCP for using space-separated strings in an option? I'm not aware of any DHCP precedent.

I'd suggest specifying that it's multiple null-terminated Net-Unicode strings packed into the option. Alternatively, define the option to hold exactly one string (no need for null-terminator) and allow the DHCP message to contain multiple occurrences of the option if multiple PCP server strings are being specified.

As a final observation, most existing DHCP options pass an IP address to the client rather than a name string, on the basis that the DHCP server is typically better connected than the DHCP client, so the server can look up a host name faster than the client can, and passing the resulting IP address to the client typically takes less space in the packet than the host name would have. The DHCP server configuration still uses a host name, but the DHCP server resolves it on demand and passes the resulting address(es) to the client in the DHCP OFFER.

Is there a reason that the PCP DHCP option needs to be different?

Stuart Cheshire