Subject: Re: [dhcwg] draft-ietf-pcp-dhcp: Exit from the loop

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Mar 2013 15:50:44 +0000

You need to pick either fqdn or address - not both. See the option guidelines draft. DHC is unlikely to support this work if you don't follow option guidelines.

- Bernie

On Mar 25, 2013, at 11:31 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

I understood no conclusion was reached in the previous pcp meeting for this I-D.
The version available at http://tools.ietf.org/html/draft-ietf-pcp-dhcp-06 reflects the consensus of the pcp wg but Ted is not happy with that design.

It seems we are looping here:
* The approach of using two formats was documented in a previous version but it was removed after a review from Bernie.
* RFC1035-based encoding was documented in a previous version but it was removed because the consensus of the pcp working group is no to over specify the options to be dns-specific.
* A more detailed background is provided here: http://www.ietf.org/proceedings/86/slides/slides-86-pcp-4.pdf.

As I have two opposite signals, I don't know how to proceed. This is why I'm expanding this to dhc chairs to have your feedback too.

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 16:56:41 +0100

Re-,

The draft does not define both; only one format is defined.

The issue is more related to what was discussed in this list: the use of utf-8 encoding.
The conclusion of that discussion is there was no consensus to adopt nor to reject that approach.

Cheers,
Med

________________________________
De : Bernie Volz (volz) [mailto:[email-masked]]
Envoyé : lundi 25 mars 2013 16:51
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Dhc Chairs ([email-masked]); Ted Lemon; [email-masked]; [email-masked]; [email-masked]
Objet : Re: draft-ietf-pcp-dhcp: Exit from the loop

- Bernie

Dear all,

Cheers,
Med

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Mar 2013 16:00:00 +0000

I understand - but draft does not follow option guidelines -- use only fqdn encoding or ipv6 address data type; utf 8 which can hold anything is not allowed.

- Bernie

On Mar 25, 2013, at 11:56 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Re-,

Cheers,
Med

Cc : Dhc Chairs ([email-masked]<mailto:[email-masked]>); Ted Lemon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

- Bernie

Dear all,

Cheers,
Med

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Mar 2013 16:01:24 +0000

Just to be clear - that approach was rejected. There is discussion in the option guidelines draft.

- Bernie

Re-,

Cheers,
Med

- Bernie

Dear all,

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 17:06:16 +0100

Re-,

To be more accurate, it was not rejected as per Ted's conclusion available here: http://www.ietf.org/mail-archive/web/dhcwg/current/msg13646.html

Cheers,
Med

Envoyé : lundi 25 mars 2013 17:01

- Bernie

Re-,

Cheers,
Med

- Bernie

Dear all,

Cheers,
Med

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Mar 2013 16:12:35 +0000

Ted's email said:

While this does not mean that this option format has been formally rejected by the working group, I would expect that an option that attempted to use this format would have similar difficulty gaining consensus in the working group.

My interpretation is that it will have a difficult road and if you want it to be OKed, follow the option guidelines.

I should have indicated all of my discussion is with WG hat chair off as these are my opinions.

- Bernie

On Mar 25, 2013, at 12:06 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Re-,

Cheers,
Med

- Bernie

Re-,

Cheers,
Med

- Bernie

Dear all,

Cheers,
Med

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 25 Mar 2013 18:00:45 +0100

On 25.03.2013 17:12, Bernie Volz (volz) wrote:
> Ted's email said:
> 
> While this does not mean that this option format has been formally
> rejected by the working group, I would expect that an option that
> attempted to use this format would have similar difficulty gaining
> consensus in the working group.
> 
> My interpretation is that it will have a difficult road and if you
> want it to be OKed, follow the option guidelines.
> 
With my DHC WG hat chair off: Although my name is mentioned in the
acknowledgements section, I did not support this particular option
format. When I was reviewing it a long time ago (-00), it had a single
FQDN option defined.

It seems that you don't care about IP family and use DHCPv4 and DHCPv6
as a transparent delivery mechanism. I remember that Dave Thaler
commented on it some time ago. For example it is ok to deliver PCP
server IPv4 address over DHCPv6 or have fqdn delivered over DHCPv4 which
resolves to AAAA only? If that is the case, I strongly suggest you
should use FQDN format.

If you need multiple PCP servers to communicate to the clients, just put
multiple instances of the option. This is normal in DHCPv6 as each
option is handled independently.

I haven't read the whole -06 draft, but just briefly looked through it
and it raises some question marks. The validation rules mentioned in
section 4.2 and 3.2 are not sufficient. We had this discussion before
(when talking about address-name-encoding draft), but some of the issues
are:

- There are more rules that govern valid fqdn. Label length equal or
shorter than 63 octets is just one of them. See RFC3315, section 8 (or
RFC1035, section 3.1 directly).

- the rules for delivering PCP server info over DHCPv4 and DHCPv6 are
inconsistent. For example you allow IPv6 address enclosed in brackets in
DHCPv4, but not in DHCPv6.

- by allowing UTF8 you bring in a lot of complexity with it. This is
something that will make all DHCPv6 clients noticeably larger and more
complex to implement. It is difficult to write validation rules for UTF8
string as there are many nuances there (e.g. many different hyphens,
accented characters or even completely different charsets, like chineese
or japaneese are there? Which of them are allowed and which are not?).
The end result is that the implementors would likely be forced to pass
received verbatim content to getaddrinfo() or choose to not support this
option. Passing the unverified content directly to internal host API is
a big security issue as it allows to exploit any discovered
vulnerabilities remotely.

In general I'd like to just +1 to what Bernie said. Please try to follow
dhc-option-guidelines if possible. This is what the DHC WG recommends.
At least that's my perception.

BTW dhc-option-guidelines will go into WGLC in around 2 weeks, so you
can bring in the UTF-8 encoding issue there.

Tomek

p.s.
Removing Bernie, Med, Ted and dhc-chairs from the recipients list as
they are all subscribed to dhcwg list.