Subject: Re: [Dhcpv6bis] 2015-01-07 DHCPv6bis team meeting minutes

From: Marcin Siodelski <[email-masked]>
Date: Mon, 02 Feb 2015 14:05:59 +0100

On 01/07/15 15:54, Tomek Mrugalski wrote:
> Marcin said that he's waiting for the editors (Bernie and Tomek) to make
> decision regarding the merge strategy. Bernie said that specific
> questions would be helpful. Marcin will send questions to the editors
> regarding open issues.
> 

Sorry for getting back a little late with this. Here are my questions to
the editors team.

1. The RFC3633 sections for the message processing have been recently
merged to sections 18, 19 and 20 of the RFC3315bis. The way we have done
that was to copy-paste the whole sections of RFC3633 into separate
sub-sections of the aforementioned 18, 19, 20 of RFC3315bis. I think it
was the right think to do, given that the message processing is going to
be heavily impacted by the changes in the stateful issues. So, with the
current text (having the NAs and PDs processing separate) it should be
easy to apply changes from stateful issues. However, once we're done
with that, there is a question if we still want to keep this separation
or we want to combine the texts into common sections. For example:

Today we have:
18. DHCP Server Solicitation
18.1.1. Creation of Solicit Messages
....
18.2. Server Behavior
....
18.3. Client Behavior for Prefix Delegation
18.4. Server Behavior for Prefix Delegation

And perhaps, sections 18.3. and 18.4. should be combined into the
preceding sections, resulting in having a common text for address
assignment and prefix delegation.

I'd be in favor of combining the texts eventually, but not earlier than
before we apply the changes from stateful issues draft: tickets #59
through #66, as the stateful issues draft provides updates to RFC3315
and RFC3633 respectively, and no combined text.

What do the editors think about this merge strategy?

2. If we decide to combine the texts for message processing for the
address assignment and prefix delegation we will be facing the problem
of referring to both addresses and prefixes, e.g. "if the Reply message
contains no addresses or prefixes". I presume we should use the
"allocable resource" or shorter "resource" to refer to both of them as
much as possible. So for example: "if the Reply message contains no
allocable resources...". I think this was the reason why the "allocable
resource" has been introduced to the terminology, but wanted to make sure.

3. As a followup to 2. If we have a common term for resources, there is
also a question of the status codes returned. The IA_NA and IA_PD may
carry different status codes from the server. Specifically, will have to
deal with the fragments of text where the client takes a specific action
if any of "NoAddrsAvail" or "NoPrefixAvail" is in the appropriate IA.
So, for example (I made the text up):

"The client includes all IAs for which it has received a NoAddrsAvail or
NoPrefixAvail status code in subsequent Renew messages to the server to
request allocation of the bindings."

I wonder if we want to come up with a new term like "no resources
available status code" or just stick to the form as in the example
above. But the latter basically precludes extending the protocol with
more allocable resources for which a different status code will be
returned. Note that the term "allocable resource" allows for resources
other than addresses or prefixes. But again, maybe we don't care about
additional resources right now because there are none?

This specific question was inspired by Tomek's comment about stateful
issues draft which I included in the
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/140

where Tomek proposes using non-success status code in the Reply message
processing. Although, the non-success could work in this case, it is
broader than just NoAddrsAvail and NoPrefixAvail and may become
inappropriate if some additional status codes are ever added.

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Feb 2015 08:13:40 -0500

> What do the editors think about this merge strategy?

This seems like a good approach to me.   It was definitely intended that we ultimately merge those sections, not keep them separate.

> I presume we should use the
> much as possible.

How about "allocated state?"  But I think "addresses or prefixes" may actually be clearer.   One could say "allocated state (addresses or prefixes)" the first time and thereafter just "allocated state" of course.

> request allocation of the bindings."

The text is pretty bad anyway.   How about:

The client includes all IAs that are still valid but not previously renewed (e.g. received NoAddrsAvail or NoPrefixAvail status code in a previous response) in subsequent Renew messages to the server to
request allocation of the bindings."

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 02 Feb 2015 14:54:06 +0100

On 02/02/15 14:13, Ted Lemon wrote:
> This seems like a good approach to me.   It was definitely intended
> that we ultimately merge those sections, not keep them separate.
>
> How about "allocated state?"  But I think "addresses or prefixes" may
> actually be clearer.   One could say "allocated state (addresses or
> prefixes)" the first time and thereafter just "allocated state" of course.
>

If we use a "resource" it makes it shorter. The "allocated state" sounds
good to me (after thinking about it for a while), but it has a down side
that there is no way to abbreviate it, because "state" would be too
ambiguous.

> The client includes all IAs that are still valid but not previously
> renewed (e.g. received NoAddrsAvail or NoPrefixAvail status code in a
> previous response) in subsequent Renew messages to the server to

The example I made up was not really meant to be 100% accurate and
RFC-ready, but I wanted to point out in what type of sentence that may
appear. Also, this example was describing the case (supported by
stateful-issues) that the client had requested allocation of addresses
or prefixes in the IA and the server refused to allocate them (e.g. in
the Request time), so the client includes the IAs with no
addresses/prefixes in the Renew messages to try to allocate them. In
that case "still valid but not previously renewed" is not applicable.

To give more real life example (18.1.8)

"The client uses addresses and other
   information from any IAs that do not contain a Status Code option
   with the NoAddrsAvail code."

would now be:

"The client uses addresses and other
   information from any IAs that do not contain a Status Code option
   with the NoAddrsAvail or NoPrefixAvail code."

Marcin

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Feb 2015 09:22:11 -0500

> that there is no way to abbreviate it, because "state" would be too

One principal of good writing is to remove as much text as possible, but no more than that.   I think it's better to use a clear term that's longer rather than a less clear term that's shorter.

>   with the NoAddrsAvail or NoPrefixAvail code."

Yup, sounds good.   Sorry about dissing your text--I thought that was from the RFC, and therefore probably my fault.  :}