Subject: Re: [Dhcpv6bis] [dhcpv6bis] #150 (XML 3315): Clarify client MUST drop option if not received in subsequent Reply

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 04 May 2016 12:29:35 -0000

#150: Clarify client MUST drop option if not received in subsequent Reply

Comment (by [email-masked]):

 Client should behave as if it never received this option at all.  The
 values received/configured from the option might persist if there are no
 other sources for that data, and they have no external impact.  So for
 instance, a client FQDN option might cause the client to configure a
 particular hostname, and to the extent that the hostname has no external
 impacts, the client could continue using that derived hostname.  As a
 counter example, a client that received an NTP server address from that
 option MUST stop using the configured IP.  If this results in the client
 having no NTP servers, then the client MUST behave as if it had never
 received that option before. The client SHOULD be open to other sources of
 the same result (such as information from RAs or other provisioning
 domains).

-- 
----------------------------+-----------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:  C awaiting consensus
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/150#comment:3>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Sat, 21 May 2016 15:32:48 -0000

Comment (by [email-masked]):

 Added the following text:

 {{{
    When a client had received a configuration option in earlier Reply,
    then sent Renew, Rebind or Information-Request and that requested
    option does not appear in in the Reply any more, it MUST stop using
    the received configuration information.  In other words, client
    should behave as if it never received this option at all and return
    to whatever default state regarding that configuration information
    was.  If there is no viable way to stop using the information, the
    values received/configured from the option MAY persist if there are
    no other sources for that data and they have no external impact.  For
    example, a client that previously received Client FQDN option and
    used it to set up its hostname is allowed to continue using it if
    there is no reasonable way for a host to unset its hostname and it
    has no external impact.  As a counter example, a client that used to
    receive an NTP server address from the DHCP server and does not
    receive it any more, MUST stop using the configured NTP server IPv6
    address.  The client SHOULD be open to other sources of the same
    configuration information.  This behavior does not apply to any IA
    containers, as their processing is described in detail in other parts
    of this document.
 }}}

 Resolving ticket. If you disagree with the proposed text, feel free to
 reopen the ticket (or push corrections if they're small).

 I'll create a separate ticket for adding reference to RFC4242.

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/150#comment:4>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Sat, 21 May 2016 15:32:59 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
----------------------------+-----------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  closed
 Priority:  P1 blocker      |   Milestone:  C awaiting consensus
Component:  XML 3315        |  Resolution:  fixed
 Keywords:                  |    Due Date:
----------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/150#comment:5>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>