Subject: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 19 Jan 2017 04:51:17 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-6man-rdnss-rfc6106bis-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think this is the first "configure my DNS" thing to come
before the IESG since DPRIVE has gotten an output, so it seems
fair to ask now:

Why doesn't the DNS server information include a port now that
we have both 53 and 853 as options?  Without that, how is a
host supposed to know which to use? Did the WG consider
DPRIVE? If so, what was the conclusion? If not, what is the
right thing to do? (Add the port no? Define a new DHCPv6 option
for DNS/TLS? Something else?)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jan 2017 10:36:43 -0300

> https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/

FWIW, this is a revision of an existing standard, aimed at fixing known
problems. Giving how critical it is to IPv6 deployment to convey DNS
information, I'd personally expect that something like you suggest
(which is sensible), would be done in a separate document -- e.g., in a
brand-new option.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Jan 2017 14:31:18 +0000

> (which is sensible), would be done in a separate document -- e.g., in a

I do agree that helping IPv6 deployment is more important at
this stage than ensuring DPRIVE is handled as an integral
part of this draft. OTOH, I'd be even happier if that's a WG
consensus position and not just you and I:-)

Cheers,
S.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Jan 2017 14:38:45 +0000

Hi Stephen,

> On Jan 19, 2017, at 8:36 AM, Fernando Gont <[email-masked]> wrote:
> 

I think you have a fair point but it was not really within scope of what the WG wanted to accomplish with this document (which is to fix some issues that were discovered during implementation/deployment). 

> (which is sensible), would be done in a separate document -- e.g., in a

Yes. Given that this fixes some important issues like DNS information expiry on lossy links as well as reduction of unnecessary multicast traffic, I would hate to hold this document up. I would much rather have a separate document that extends this option with port info.

Thanks
Suresh

---

From: Tim Chown <[email-masked]>
Date: Thu, 19 Jan 2017 14:50:57 +0000

Hi,

> On 19 Jan 2017, at 14:38, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Stephen,
> 

> Yes. Given that this fixes some important issues like DNS information expiry on lossy links as well as reduction of unnecessary multicast traffic, I would hate to hold this document up. I would muc…

I agree, as you’d then also (I presume) be needing to extend DHCPv6 options to support conveying the same information, so could cover off both methods in one doc in a similar way to the RFC7710 "Rick Roll" option.

Tim