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

[<[e-mail]>]

Dear Stuart,

Please see inline.

Cheers
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la 
>part de Stuart Cheshire
>Envoyé : mardi 6 novembre 2012 02:26
>À : PCP
>Objet : [pcp] draft-ietf-pcp-dhcp-05.txt
>
>Some comments on draft-ietf-pcp-dhcp-05.txt
>
>I found the document confusing and contradictory. In 
>"Terminology" it says:
>
>>    name may be structured as DNS qualified name or
>>    be composed of strings such as can be passed to getaddrinfo
>>    (Section 6.1 of [RFC3493]), including address literals, etc.

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.

>
>but "Introduction" says:
>
>>    Motivations for defining PCP option as a name and not an 
>IP address
>>    are discussed in Appendix A.
>
>I'm not sure which statement applies.

Med: The sentence above is to say the option is not encoded as an IP address but as a name. The definition of the name in the draft allows IP address literals to be conveyed as string in the name option.

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

>
>>    The domain name(s) is encoded as string.
>
>This is ambiguous. What kind of string? It should state 
>explicitly that it's a <character-string> as defined in RFC 1035.

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.

>
>And what can it contain? An FQDN? Does it need to end with a 
>trailing dot? Or does it need to *not* end with a trailing 
>dot, because that would be redundant (but the client MUST add 
>one before passing it to gethostbyname)? Can it contain a 
>dotted-decimal IPv4 literal? An IPv6 literal? In square 
>brackets? Are leading/trailing/interior spaces allowed? Or are 
>they illegal?

Med: See the definition above.

>
>>    When several names are included, a space character is 
>used as separator.
>
>If there's more than one, they should be concatenated together 
>as with an RFC 1035 TXT record.
>
>On the other hand, if only FQDNs are allowed, not address 
>literals, then instead of <character-string>s, it would be 
>better to use the already-defined name list format from RFC 3397.
>
>>    Once each Name conveyed in the OPTION_PCP_SERVER option 
>is validated...
>
>How is a name "validated"?

Med: This is detailed in this updated text:

   If the DHCPv6 client receives an OPTION_PCP_SERVER option from the
   DHCPv6 server, it extracts the name(s) conveyed in the
   OPTION_PCP_SERVER option.  The DHCPv6 client uses the space character
   to identify each individual name.  A name is considered as valid if
   it is a legal UTF-8 string which does not contain any spaces or
   nulls.  The DHCPv6 client MUST silently discard non valid names.

>
>Stuart Cheshire
>
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp
>