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

[Tim Chown <[e-mail]>]

Hi,

> On 19 Jan 2017, at 14:38, Suresh Krishnan <[e-mail]> wrote:
> 
> Hi Stephen,
> 
>> On Jan 19, 2017, at 8:36 AM, Fernando Gont <[e-mail]> wrote:
>> 
>> On 01/19/2017 09:51 AM, Stephen Farrell wrote:
>>> 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?)
> 
> 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). 

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

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