--- 1/draft-ietf-dhc-dhcpv6-stateful-issues-01.txt	2012-10-22 18:15:00.509508964 +0200
+++ 2/draft-ietf-dhc-dhcpv6-stateful-issues-02.txt	2012-10-22 18:15:00.553508682 +0200
@@ -1,19 +1,19 @@
 
 Network Working Group                                           O. Troan
 Internet-Draft                                                   B. Volz
 Updates: 3315,3633 (if approved)                     Cisco Systems, Inc.
-Intended status: Standards Track                         October 6, 2012
-Expires: April 9, 2013
+Intended status: Standards Track                        October 22, 2012
+Expires: April 25, 2013
 
               Issues with multiple stateful DHCPv6 options
-              draft-ietf-dhc-dhcpv6-stateful-issues-01.txt
+              draft-ietf-dhc-dhcpv6-stateful-issues-02.txt
 
 Abstract
 
    Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
    with the expectation that additional stateful DHCPv6 options would be
    developed.  IPv6 Prefix Options for Dynamic Host Configuration
    Protocol (DHCP) version 6 shoe-horned the new options for Prefix
    Delegation into DHCPv6.  Implementation experience of the CPE model
    described in has shown multiple issues with the DHCPv6 protocol in
    supporting multiple stateful options.
@@ -26,21 +26,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on April 9, 2013.
+   This Internet-Draft will expire on April 25, 2013.
 
 Copyright Notice
 
    Copyright (c) 2012 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -201,20 +201,26 @@
    is only applicable to IA_NA/IA_TA, it may be problematic to make this
    assumption for all status codes.  Ideally the Status Code option
    should be encapsulated in the IA option for all DHCP messages.  This
    makes Advertisement messages equal to Reply messages.
 
    Proposed solution: No change.  For backwards compatibility, the
    NoAddrsAvail Status Code option when no addresses are available will
    be kept in the global scope for Advertise messages.  Other IA option
    types MUST encapsulate the Status Code option within the IA option.
 
+   To clarify further: the expected Advertise message from a server when
+   a client requests both address assignment (IA_NA) and prefix
+   delegation (IA_PD) and the server can only delegate prefixes, is a
+   Status Code Option with the NoAddrsAvail status code, no IA_NA
+   option(s), and the IA_PD option(s) with IAPREFIX option(s).
+
 4.3.  T1/T2 timers
 
    The T1 and T2 timers determine when the client will contact the
    server to extend lifetimes of information received in an IA.  How
    should a client handle the case where multiple IA options have
    different T1 and T2 timers?
 
    In a multiple IA option types model, the T1/T2 timers are protocol
    timers, that should be independent of the IA options themselves.  If
    we were to redo the DHCP protocol from scratch the T1/T2 timers