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

[Suresh Krishnan <[e-mail]>]

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.

Thanks
Suresh