Re: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Bing,
I tried to address your comments in the following draft:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-08

Could you double-check whether your comments are resolved well or not?

Also, I put my answers inline with =>.

If you have some unclear parts, please let me clarify them.

BTW, I added your name in Acknowledgements.

Thanks.

Paul

On Thu, Feb 25, 2016 at 10:52 PM, Liubing (Leo) <[e-mail]>
wrote:

> Hi Dear authors,
>
> I've read the draft. It was my first time to read it, so please pardon me
> if I iterated some questions that had been addressed before.
>
> 1. Since RFC5006 was already obsolete by RFC6106, and this document is
> going to obsolete 6106, I guess this draft should not necessary to mention
> 5006 anymore?
> When the document says it defines a "new" option (DNSSL), it is still
> comparing to 5006. But it is not "new" comparing to 6106. So this is a bit
> confusing for me.
> So I'd suggest the whole text be tweaked in the perspective of obsolete
> RFC6106, not just iterate it.
>
>  => Done.


> 2. Section 1.1, page3
> "  Furthermore,
>    the host learns this DNS configuration from the same RA message that
>    provides configuration information for the link, thereby avoiding
>    also running DHCPv6."
> Do you mean the host decides not to initial DHCPv6?
> I think "avoiding also running DHCPv6" should not be a principle from
> hosts' perspective. That should come from the administrator's deployment
> plan.
>
 => I removed "thereby avoiding also running DHCPv6" for the
administrator's deployment plan in the text.

>
> 3. Section 5.3.2
> " Second, if different DNS information is provided on different network
>    interfaces, this can lead to inconsistent behavior.  The IETF is
>    working on solving this problem for both DNS and other information
>    obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE]. "
>
> Regarding MIF problems, I think it's nice to mention RFC6731 here, which
> is the solution for DNSS selection.
> Btw, the [MIF-PROBLEM][MIF-PRACTICE] are already RFC6418 and RFC6419.
>
>  => Reflected the text as follows:
      Second, if different DNS information is provided on different network
      interfaces, this can lead to inconsistent behavior.  The IETF worked
      on solving this problem for both DNS and other information obtained
      by multiple interfaces [RFC6418][RFC6419], and standardized the
      solution for RDNSS selection for multi-interfaced nodes in [RFC6731],
      which is based on DHCP.


> 4. Section 7.2
> "It is RECOMMENDED that ND use SEND to
>    allow all the ND options including the RDNSS and DNSSL options to be
>    automatically included in the signatures."
> I think recommending SEND is not very specific to this document. We should
> have more considerations whether to use SEND, not only in term of
> protecting RDNSS/DNSSL options.
>
>  => I replaced "RECOMMENDED" with "MAY" to tell that SEND can be used as a
mitigation approach.


> 5. Section 1.1, page 3
> "However, when in many networks some additional information needs to be
> distributed, those networks are likely to employ DHCPv6."
> This sentence reads a bit odd. I guess you intended to mean like this:
> " However, for networks that need to distribute additional information,
> DHCPv6 is likely to be employed."
>
>  => Done.

 Thanks.

 Best Regards,
 Paul


> Best regards,
> Bing
>
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of
> > [e-mail]
> > Sent: Tuesday, February 09, 2016 5:54 PM
> > To: 6man WG
> > Cc: [e-mail]
> > Subject: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis
> >
> > This message starts a two week 6MAN Working Group Last Call on
> > advancing:
> >
> >      Title    : IPv6 Router Advertisement Options for DNS Configuration
> >      Authors  : J. Jeong, S. Park, L. Beloeil, S. Madanapalli
> >      Filename : draft-ietf-6man-rdnss-rfc6106bis-06
> >      Pages    : 17
> >      Date     : 2015-10-09
> >
> >     https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-06
> >
> > as a Proposed Standard.  Substantive comments and statements of support
> > for publishing this document should be directed to the mailing list.
> Editorial
> > suggestions can be sent to the authors.  This last call will end on 23
> > February 2016.
> >
> > We would like this document to follow the experimental document shepherd
> > procedure. We will need a volunteer document shepherd, before we can
> > advance this document.
> >
> > Best regards,
> > Ole & Bob
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>