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

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

Hi Jinmei,
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.

Thanks.

Paul

On Thu, Feb 25, 2016 at 4:27 AM, 神明達哉 <[e-mail]> wrote:

> At Tue, 9 Feb 2016 10:54:16 +0100,
> [e-mail] wrote:
>
> > 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.
>
> I've reviewed the 06 version.  I don't have a particular opinion on
> whether to publish it, but I have some comments:
>
> - Section 5
>
>    The IPv6 DNS configuration mechanism in this document needs two new
>    ND options in Neighbor Discovery: (i) the Recursive DNS Server
>    (RDNSS) option and (ii) the DNS Search List (DNSSL) option.
>
>   "new" sounds like awkward since, well, it's not new any more.  I
>   don't know the usual practice (if any) in cases like this for "-bis"
>   specifications, but I'd suggest just removing "new".
>
>  => Done.


> - Section 5.1
>
>      Lifetime      32-bit unsigned integer.  The maximum time, in
>                    seconds (relative to the time the packet is sent),
>                    over which this RDNSS address MAY be used for name
>                    resolution.
>
>   Shouldn't "relative to the time the packet is sent" actually be
>   "relative to the time the packet is received"?  In practice these
>   two wouldn't be different very much anyway, but, technically, the
>   former looks awkward to me since the recipient can't know that time.
>
>  => Done.


> - Section 5.1
>
>    Note:  [...]  The link zone indices SHOULD be
>       represented in the textual format for scoped addresses as
>       described in [RFC4007].
>
>   Perhaps the actual intent is "The link-local addresses SHOULD be
>   represented with their link zone indices in the textual format for
>   scoped addresses as described in [RFC4007]."?  Also, it's not very
>   clear to me why it's a "SHOULD".  Maybe because it's convenient as
>   the DNS client (stub resolver) implementation can simply pass the
>   textual text (whether it's link-local or not) to a utility function
>   like getaddrinfo()?  If so, that's understandable, but I guess it's
>   not obvious and should be explained explicitly.  Also, I'm not sure
>   if this convenience (if that's the reason for the SHOULD) is worth
>   the RFC2119 keyword.  While it'd certainly be convenient, this seems
>   to be a pure implementation choice.
>
>  => Done.


> - Section 5.2: s/name/names/
>
>      Lifetime      32-bit unsigned integer.  The maximum time, in
>                    [...]
>                    (0xffffffff) represents infinity.  A value of zero
>                    means that the DNSSL domain name MUST no longer be
>                    used.
>
>  => Done.


> - Section 5.2
>
>      Domain Names of DNS Search List
>                    One or more domain names of DNS Search List that MUST
>                    be encoded using the technique described in Section
>                    3.1 of [RFC1035].
>
>   The word "technique" sounds awkward to me as it's the standard wire
>   format of domain names.  I suggest, e.g., just saying "...encoded as
>   described in Section 3.1 of [RFC1035]".
>
>  => Done.


> - Section 6
>
>    In environments where the DNS information is stored in user space and
>    ND runs in the kernel, it is necessary to synchronize the DNS
>    information (i.e., RDNSS addresses and DNS search domain names) in
>    kernel space and the Resolver Repository in user space.  For the
>    synchronization, an implementation where ND works in the kernel
>    should provide a write operation for updating DNS information from
>    the kernel to the Resolver Repository.  One simple approach is to
>    have a daemon (or a program that is called at defined intervals) that
>    keeps monitoring the Lifetimes of RDNSS addresses and DNS search
>    domain names all the time.  [...]
>
>   This seems to assume that "ND runs in the kernel" means that all
>   information in RAs is managed in the kernel.  I don't know if
>   there's such an implementation (does Linux work that way?), but it
>   doesn't necessarily have to be so, and is actually different from
>   the BSD implementation: the FreeBSD's rtsol(d) completely works as a
>   user space application, receives RA via an ICMPv6 socket using the
>   standard advanced socket API (RFC3542), and manages RDNSS
>   implementation independently from the kernel (even if some other
>   parts of the RA are managed in the kernel).  So, I'd at least
>   suggest clarifying that this kind of approach is only necessary for
>   some deviant protocol stack implementation that doesn't even support
>   RFC3542.  And, I'd also mention the FreeBSD-style approach as it
>   should be more generic and portable.
>
>  => I tried the current text as follows:
      In environments where the DNS information is stored in user space and
      ND runs in the kernel, it is necessary to synchronize the DNS
      information (i.e., RDNSS addresses and DNS search domain names) in
      kernel space and the Resolver Repository in user space.  In these
      environments, a user space application cannot receive RA via an
      ICMPv6 socket using the standard advanced socket Application Program
      Interface (API) in [RFC3542].


> - Section 6.3: this section largely repeats the text of Section 6.2
>   and looks redundant to me.  I'd consider unifying these two sections
>   and eliminate unnecessary duplicates.
>
>  => Done. I removed the redundant ones and specified a different in Step
(b).
      In Step (b), if the DNSSL domain name already exists in the DNS
      Search List and the DNSSL option's Lifetime field is set to zero,
      delete the corresponding DNSSL entry from both the DNS Search List
      and the Resolver Repository in order to prevent the DNSSL domain name
      from being used any more for certain reasons in network management,
      e.g., the termination of the usage of the DNSSL domain name.  That
      is, the DNSSL domain name may not be used any more by the policy of
      the network.


> - Section 6.3: on a related point, this text looks awkward:
>
>       Step (b): For each DNSSL domain name, check the following: [...]
>       [...] for certain reasons in network management,
>       e.g., the termination of the RDNSS or a renaming situation.  That
>       is, the RDNSS can resign from its DNS service because the machine
>       running the RDNSS is out of service intentionally or
>       unintentionally.  Also, under the renaming situation, the DNSSL
>
>   How can the termination of a particular RDNSS mean that DNSSL names
>   are not usable anymore?  There may be a case where one event is
>   realted to the other, but I don't see any obvious relationship
>   between these two (the RDNSS may simply be replaced with a new,
>   different node).  This text rather seems to be a result of a naive
>   copy of Section 6.2.
>
>  => Done like the previous answer.


> - Section 7.1, second paragraph.  Most of the text in this paragraph
>   is irrelevant to this protocol and looks redundant to me.  I'd
>   consider just referring to some other document for the general
>   issue.
>
>  => Removed.


> - Section 7.2
>
>    The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a
>    security mechanism for ND.  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 don't think this "RECOMMENDED" is realistic.  As a matter of fact,
>   SEND isn't even widely implemented, and, IMO, its deployability
>   issues are not easily resolved.  I don't have a specific suggestion
>   on how to make the whole text realistic, but I'd at least suggest
>   stopping to make such an unrealistic requirement, especially with an
>   RFC2119 keyword.
>
>  => I replaced "RECOMMENDED" with "MAY" as follows:
      The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used
      as a security mechanism for ND.  In this case, ND can use SEND to
      allow all the ND options including the RDNSS and DNSSL options to be
      automatically included in the signatures.  Other approaches specified
      in [RFC4861] can be used for securing the RA options for DNS
      configuration.

 Thanks.

 Best Regards,
 Paul


--
> JINMEI, Tatuya
>
> --------------------------------------------------------------------
> 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>