Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Marcin Siodelski <> Tue, 16 August 2016 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A30612D67E for <>; Tue, 16 Aug 2016 03:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Lob1ySig09Q for <>; Tue, 16 Aug 2016 03:04:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABE2E12D62D for <>; Tue, 16 Aug 2016 03:04:22 -0700 (PDT)
Received: by with SMTP id f65so133397624wmi.0 for <>; Tue, 16 Aug 2016 03:04:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=EK0HDh122+tFKg2WOcCaOnYre//RPBu1JQPI5iJYuAM=; b=fQpCxe6cuoXsSRLlfGrPhMod8WaJeW7Ikk9wcwZImmwYvvWZ1eCudohZ19fb2mpDw2 6KFHFEu95uN4nMezJYQg8gQDEBW5Ut4XCea7U4KbHcrg0Rc20b9GvBLnmeifJl+3f36p zs2lBZW8CdKNUX12IRgAHlaBe4qctHMdIW9x2axf3y7Gprsp54xfsR9BCQLR+dRzVhco hGWNs7qDtDcBk9p7E3JOjqlV9TKqW6oIKU517e1KhFcp1vKSoRW+GhJpEI4Tx8Qbl0Nu C037h4fcweFikivDpBU47g8kBQNSgcTO+O75dR6O2buPk+uGrNDvY95ad1JDixjAXF9q VUVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EK0HDh122+tFKg2WOcCaOnYre//RPBu1JQPI5iJYuAM=; b=SKwGH00f2LFxZMbRVzb8l4vTlZLMR+F5L0TsuZ5eMX+h+vfCHrjaVoGQI/70/MucQw n6DxLVyB9SoXtRw6N8BnAJdish2tYyXxSEK+kDs3odY6AJq5D/Q9jAUo04ReadDZqd+e /UF0l+80eIPLB728JPd4Mg6vANnHdvWMrtuWSDvFRdJAfYGMs0LrvsjGBT1/FjGqZg/x 34Uo27Xx0RUdbZ4siN/ZpudSuQCdYif7IYIJz/TDxPzaL2mAMFgeen61OcFrIhtbMihE 2WWtHTkWLACVJ8LiOrb8TT1O6Ku5p5L3IRFdH7yjxVBHxDRc1j9AI7TLxNVhCJveTCsI yIGw==
X-Gm-Message-State: AEkoousl3xuz6KptsHIWUKTKtccATcawfJuOneWOLCE0SSU4pejQmO1/3pzWFaOwIqlGaw==
X-Received: by with SMTP id t75mr5555745lfe.133.1471341860452; Tue, 16 Aug 2016 03:04:20 -0700 (PDT)
Received: from MacBook-Pro-Marcin.local ( []) by with ESMTPSA id 205sm685916ljj.47.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 03:04:19 -0700 (PDT)
To: Tomek Mrugalski <>, dhcwg <>
References: <>
From: Marcin Siodelski <>
Message-ID: <>
Date: Tue, 16 Aug 2016 12:04:16 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Aug 2016 10:04:28 -0000

On 08.07.2016 19:03, Tomek Mrugalski wrote:
> Hi all,
> So the day finally has come. Authors working on RFC3315bis believe that
> after over two years of work, this document is ready for working group
> last call. This call initiates the working group last call on
> draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document (130+
> pages), there's upcoming meeting and a holiday period, chairs decided to
> do an extended last call that will last 4 weeks. Please post your
> comments by August 8th.
> We do have a slot reserved for this work in Berlin. We will present the
> overview of the document (some areas are organized differently than
> original 3315), go over the most important changes and will discuss any
> comments raised to date.
> If you would like to review more important changes, looking at
> appendices A anb B seems like a good place to start. If you like to see
> the list of tickets addressed, see [2]. Many smaller issues were
> discussed on dhcpv6bis mailing list [3].
> This is the most important document the DHC working group is currently
> working on. Please review it thoroughly. Since both co-chairs are also
> co-authors, our shepherd, Ralph Droms, will determine consensus and wrap
> up the WGLC. Thank you Ralph for stepping up and helping with this!
> 1.
> 2.
> 3.
> Cheers,
> Bernie & Tomek

As a co-author of this document I strongly support moving it forward. I
have read the entire document and provide a couple of
comments/suggestions below.


1.1.  Relation to previous DHCPv6 standards

"prefix delegation [RFC3633],stateless [RFC3736], "

"prefix delegation [RFC3633], stateless DHCPv6 service [RFC3736],"

1.2.  Relation to DHCP in IPv4

"The operational models and relevant configuration information for
   DHCPv4 [RFC2132][RFC2131]"

"The operational models and relevant configuration information for
   DHCPv4 [RFC2131]"

1.4.  Client-server Exchanges Involving Two Messages

Didn't we at some point consider removing sections 1.4 and 1.5 as they
present exchanges of messages before we even got to the terminology?

We may consider mentioning after the following paragraph:
"The server sends a Reply message to the client with the new
   lifetimes, allowing the client to continue to use the address or
   delegated prefix without interruption"


"If the server is unable to extend the lifetime of an address or
delegated prefix it indicates that by returning the address or delegated
prefix with lifetimes of 0. At the same time, the server may assign
another address or delegated prefix instead."

4.2.  DHCP Terminology
binding: this should be updated to also include delegated prefixes.

Currently it says:

"A binding (or, client binding) is a group of server data records
containing the information the server has about the addresses in an IA"

and further it says:
"... where IA-type is the type of address in the IA ..."

So again, no mention of delegated prefixes.

Similarly, for the IA, is this ok to say:
" Each IA holds one type of address ..." ?. It implies that the prefix
is an address.

IA_PD: I think the following can be removed:
" Each IA_PD has an associated IAID.  A requesting router may have more
than one IA_PD assigned to it; for example, one for each of its

as it duplicates the text for "IA".

singleton option: this seems to be underspecified. In particular,
"appear only once". The question is where? In a message or other option.

6.3.  DHCP Message Types
Message descriptions should probably be updated to use the term
"leases", instead of addresses.

7.  Client/Server Message Formats
msg-type: In wonder if we should add that: "additional message types are
defined in other specifications", to not create impression that those in
section 6.3 are the only valid messages. For example those in RFC7341.

13.1.  Rate Limiting

 "This method of bounding burstiness also guarantees that the long-term
transmission rate will not exceed."

 "This method of bounding burstiness also guarantees that the long-term
transmission rate will not exceed:" (colon, rather than period at the end).

15.  Message Validation


17.  DHCP Configuration Exchanges
Some paragraphs of this section require fixing punctuation.

The enumeration of reasons why the client would start DHCP message
exchange could be better placed earlier in this section. Perhaps, right
after the first paragraph.

The paragraph starting with:
"A server may initiate a message exchange with a client by sending a
   Reconfigure message to cause the client to send a Renew, Rebind or..."

could be moved to the end of the section, after the paragraphs
describing client-initiated exchanges.

"In any situation when a client may have moved to a new link and the
   client does not have any delegated prefixes obtained from the DHCP

This assumes that the client has delegated prefixes and is interested in
continuing to use them. But, is this also possible that the client
switching to a new link is no longer interested in using delegated
prefixes and simply wants to Confirm the addresses assigned? Is this ok
to send Confirm to verify that the addresses it has are correct, even
though it had received prefixes in previous transaction?

17.1.4. Creation and Transmission of Renew Messages
"The server determines new
   lifetimes for the leases according to the administrative
   configuration of the server.  The server may also add leases to the
   IAs.  The server can remove leases from the IAs by returning IA
   Address options (for IA_NA and IA_TA) and IA Prefix options (for
   IA_PD) with preferred and valid lifetimes set to 0."

This text is server specific and should be better moved to the server
section, or alternatively we may want to consider updating this text to
be more of a client-side type, e.g.

"The client MUST be prepared that the server removes or adds new leases
to the IAs. The leases are removed when server sets their preferred and
valid lifetimes to 0, in which case the client MUST stop using them."

17.1.9. Receipt of Advertise Messages

I'd suggest we put this paragraph at the beginning of the section:

 "Upon receipt of one or more valid Advertise messages, the client
   selects one or more Advertise messages based upon the following

as it is the first for the client to select the Advertise message.

Then, it should be followed by: "The client MUST ignore any Advertise...
with the exception of SOL_MAX_RT and INF_MAX_RT", because we want the
client to process SOL_MAX_RT and INF_MAX_RT from a selected Advertise
message, not from all messages. Reply for Solicit (with Rapid Commit), Request, Renew or Rebind.

The new text starting with:
" 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..."

includes Information-request but this section is not about the
Information-request case. One of the option would be to include
Information-request in the section title, but then there is a lot of
text in this section that is not relevant to Information-request.
Perhaps it would be better to have a separate section that includes this
text, e.g. "Lack of Previously Received Options in Reply"

17.2. Server Behavior
Spurious "In most instances".

Duplicated "as indicated by the Reconfigure".

17.2.1. Receipt of Solicit Messages
"the servers discard the Solicit message"

"the server discards the Solicit message"

 "Sending this option back to the client may useful using server
   selection process."

 "Sending this option back to the client may be useful in server
   selection process."

17.2.6. Receipt of Information-request Messages
In the following sentence:
"The server includes options containing configuration information to
   be returned to the client as described in Section 17.2. "

it sounds odd to direct the reader to section 17.2. while the reader is
in fact in section 17.2. (specifically 17.2.6).

17.2.9. Creation and Transmission of Advertise Messages
"Prefix Excluded"

"Prefix Exclude"

24. Obsoleted mechanisms
Together with obsoleting the lifetime hints we obsoleted T1/T2 hints,
which we should probably mention here