Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

[David Farmer <[e-mail]>]

I would think a summary of the changes just made needs to be added to 
Appendix B.  To accurately reflect the changes since RFC6106 and help 
implementers know what they need to change to comply with the new 
specification.

Other than that looks good to me.

Thanks

On 8/10/15 15:31 , Mr. Jaehoon Paul Jeong wrote:
> Hi all,
> I reflected Ole's suggestion on the revised draft:
> https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-01
>
> If you have further comments, please let us know.
>
> Thanks.
>
> Paul
>
> On Fri, Jul 24, 2015 at 2:00 AM, Ole Troan <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Mark, et al:
>
>     looking more closely at the issues Mark has pointed out, I fear we
>     have to fix a few more bugs than I originally intended.
>
>     possible set of changes:
>
>     Section 5.1:
>     OLD:
>     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.  Hosts MAY send a Router Solicitation to
>                         ensure the RDNSS information is fresh before the
>                         interval expires.  The value of Lifetime SHOULD by
>                         default be at least 3 * MaxRtrAdvInterval where
>                         MaxRtrAdvInterval is the Maximum RA Interval defined
>                         in [RFC4861].  A value of all one bits (0xffffffff)
>                         represents infinity.  A value of zero means that the
>                         RDNSS address MUST no longer be used.
>
>     NEW:
>     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. The value of Lifetime SHOULD by
>                         default be at least 3 * MaxRtrAdvInterval where
>                         MaxRtrAdvInterval is the Maximum RA Interval defined
>                         in [RFC4861].  A value of all one bits (0xffffffff)
>                         represents infinity.  A value of zero means that the
>                         RDNSS address MUST no longer be used.
>
>     Section 5.2
>     OLD:
>     Note:  An RDNSS address or a DNSSL domain name MUST be used only as
>            long as both the RA router Lifetime (advertised by a Router
>            Advertisement message [RFC4861]) and the corresponding option
>            Lifetime have not expired.  The reason is that in the current
>            network to which an IPv6 host is connected, the RDNSS may not be
>            currently reachable, that the DNSSL domain name is not valid any
>            more, or that these options do not provide service to the host's
>            current address (e.g., due to network ingress filtering
>            [RFC2827][RFC5358]).
>     NEW:
>        <deleted paragraph>
>
>     Section 5.3.1
>     OLD:
>         When the IPv6 host has gathered a sufficient number (e.g., three) of
>         RDNSS addresses (or DNS search domain names), it SHOULD maintain
>         RDNSS addresses (or DNS search domain names) by the sufficient
>     number
>         such that the latest received RDNSS or DNSSL is more preferred
>     to the
>         old ones; that is, when the number of RDNSS addresses (or DNS search
>         domain names) is already the sufficient number, the new one replaces
>         the old one that will expire first in terms of Lifetime.  As an
>         exceptional case, if the received RDNSS addresses (or DNS search
>         domain names) already exist in the IPv6 host, their Lifetime fields
>         update their Expiration-time, that is, when the corresponding DNS
>         information expires in the IPv6 host; note that when the Lifetime
>         field has zero, the corresponding RDNSS (or DNS search domain name)
>         is deleted from the IPv6 host.  Except for this update, the IPv6
>     host
>         SHOULD ignore other RDNSS addresses (or DNS search domain names)
>         within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
>         DNSSL) options within an RA.  Refer to Section 6 for the detailed
>         procedure.  Note that the sufficient number is a system
>     parameter, so
>         it can be determined by a local policy.  Also, separate parameters
>         can be specified for the sufficient number of RDNSS addresses and
>         that of DNS search domain names, respectively.  In this document,
>         three is RECOMMENDED as a sufficient number considering both the
>         robust DNS query and the reasonably time-bounded recognition of the
>         unreachability of DNS servers.
>
>     NEW:
>         <deleted>
>         (I tried making sense of this paragraph, I think the document
>     would read better without it, but if someone can propose correct
>     text that would be fine)
>
>     cheers,
>     Ole
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[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] <mailto:[e-mail]>,
> [e-mail] <mailto:[e-mail]>
> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================