Re: Review of draft-ietf-dna-simple

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am OK with publication of the document if Bernard's comments are addressed.

- Ralph

On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:

> Overall, I think the document the document looks good.  Some comments:
>  
> Section 2.4
>  
>    The host uses a combination of unicast
>    Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
>    and DHCPv6 message exchanges in order to determine whether previously
>    encountered routers are present on the link, and if they are not,
>    acquire the new configuration information.
>  
> [BA] Since DHCPv6 operation isn’t affected, it might be more accurate to say the following:
>  
>    The host uses a combination of unicast
>    Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs)
>    in order to determine whether previously
>    encountered routers are present on the link, in which case an
>    existing configuration can be reused.  If previously encountered
>    routers are not present then either IPv6 Stateless Address Autoconfiguration
>    and/or DHCPv6 is used for configuration.  
>  
>  
> Section 5.3
>  
>    o  Sending of neighbor discovery and/or DHCPv6 probes
>  
> [BA] When Simple DNA is used, neighbor discovery probes are always sent, and DHCPv6 operation is not affected.  So I’d change this to:
>  
> ·         Sending of neighbor discovery probes.
>  
>  
> 5.7.2.  Receiving Router Advertisements
> 
>    On reception of a Router Advertisement the host MUST go through the
>    SDAT and mark all the addresses associated with the router (both
>    SLAAC and DHCPv6 acquired) as inoperable.  The host MUST then process
>    the Router Advertisement as specified in Section 6.3.4. of [RFC4861].
>  
> [BA] I don’t understand why the first sentence is necessary in the case where
> the addresses have already been confirmed via Neighbor probes. 
>  
> Section 5.11
>  
>    If a response is received to any unicast Neighbor Solicitation or
>    Router Solicitation message, pending retransmissions MUST be
>    canceled.
>  
> [BA] Why should receipt of a response to a Neighbor Solicitation cancel pending retransmissions of a Router Solicitation?
>  
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]