Subject: [Dhcpv6bis] Merged RFC7083 into RFC3315bis

From: Marcin Siodelski <[email-masked]>
Date: Mon, 07 Apr 2014 18:21:50 +0200

Hi,

I resolved tickets #25 and #51. The latter ticket is a merge of RFC7083
(SOL_MAX_RT and INF_MAX_RT). Although I think that no further changes
are now required for this ticket, there is one  question I want to ask
the group before I close the ticket.

I deliberately didn't include the first paragraph of section 8 of
RFC7083 in the bis document, because I think it is redundant and doesn't
really bring any new information. Are people fine with that? See
http://wiki.tools.ietf.org/group/dhcpv6bis/ticket/51#comment:3 for details.

The second issue described in this comment has become void when I
resolved #25.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Apr 2014 02:13:23 +0000

Marcin:

In 17.1.3, the text:

   The client MUST ignore any IAs in an Advertise message that include a
   Status Code option containing the value NoAddrsAvail, with the
   exception that the client MAY display the associated status message
   to the user.

Will need additional changes when the IA_PD text is included since IAs here should not include IA_PDs? Perhaps:

   The client MUST ignore any IA_NA and IA_TA in an Advertise message that include a
   Status Code option containing the value NoAddrsAvail, with the
   exception that the client MAY display the associated status message
   to the user.

I'm also wondering why we have this text say this since the IA_NA and IA_TA should not be returned anyway?

Hum ... it seems section 18.2.1 has broken from what it was before with:

   If the server will not assign any addresses to any IA in a subsequent
   Request from the client, the server MUST send an Advertise message to
   the client that includes the IA containing a Status Code option with
   status code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, a Client Identifier option

The old text was:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.

And I thought we agreed NOT to change this behavior (the stateful issues draft clearly says to keep the old behavior). (I didn't look to see who and when this was changed.)

---

Regarding the other issues, OK.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Monday, April 07, 2014 12:22 PM
To: DHCPv6 bis list
Subject: [Dhcpv6bis] Merged RFC7083 into RFC3315bis

Hi,

I resolved tickets #25 and #51. The latter ticket is a merge of RFC7083 (SOL_MAX_RT and INF_MAX_RT). Although I think that no further changes are now required for this ticket, there is one  question I want to ask the group before I close the ticket.

I deliberately didn't include the first paragraph of section 8 of
RFC7083 in the bis document, because I think it is redundant and doesn't really bring any new information. Are people fine with that? See
http://wiki.tools.ietf.org/group/dhcpv6bis/ticket/51#comment:3 for details.

The second issue described in this comment has become void when I resolved #25.

Marcin

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Apr 2014 02:33:45 +0000

> Hum ... it seems section 18.2.1 has broken from what it was before with:

That should have said section 17.2.2, Creation and Transmission of Advertise Messages.

The combined text will be messy since it will have to say something like:

   If the server will not assign any addresses to any IAs (IA_NAs and IA_TAs) in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID. However, the server SHOULD continue to process
   IA_PD requests as "normal" and include them in the Advertise.

(That isn't proposed to be the final text.)

It might also be best to handle this a bit more logical and write:

  The server forms the Advertise message as follows:

  - The server sets the "msg-type" field to ADVERTISE and copies the contents of the transaction-id field from the Solicit message received from the client to the Advertise message.
  - The server adds the Client ID option.
  - The server adds the Server ID option.
  - If the client requested the SOL_MAX option and the server has been configured to send a value, the server adds the SOL_MAX option.
  - Ditto for INF_MAX.
  - If there were one or more IA_NA and/or IA_TAs but no addresses were assigned, the server includes a Status Code option with NoAddrsAvail and does not include any IA_NA/IA_TA options.
    Otherwise, the server includes the IA_NA and IA_TA options and any addresses assigned.
  - If there were one or more IA_PD options, the server includes the IA_PD options and any prefixes delegated or a Status Code option with NoPrefixAvail (encapsulated in the IA_PD).
  - If the server included at least one IA_NA, IA_TA, or IA_PD option, it adds any other options requested by the client. 

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, April 07, 2014 10:13 PM
To: Marcin Siodelski; DHCPv6 bis list
Subject: Re: [Dhcpv6bis] Merged RFC7083 into RFC3315bis

Marcin:

In 17.1.3, the text:

The old text was:

---

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Monday, April 07, 2014 12:22 PM
To: DHCPv6 bis list
Subject: [Dhcpv6bis] Merged RFC7083 into RFC3315bis

Hi,

Marcin

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 08 Apr 2014 12:29:31 +0200

>    exception that the client MAY display the associated status message
In the combined text we could also say:

 The client MUST ignore any IAs in an Advertise message that include a
   Status Code option containing the value NoAddrsAvail or NoPrefixAvail, with the
   exception that the client MAY display the associated status message
   to the user.

> I'm also wondering why we have this text say this since the IA_NA and IA_TA should not be returned anyway?
I am not clear. I actually thought that the server would return status
code in the global scope (and no IAs) only if it was unable to allocate
the addresses for all IAs:

So, my take on this was that the server may return an IA in Advertise,
if some of bindings can be created, even if other bindings can't.
 
It seems that your understanding of this paragraph is that "if at least
for one IA there will be no binding created, a status code is sent in
the global scope and no other IAs are included".?

> And I thought we agreed NOT to change this behavior (the stateful issues draft clearly says to keep the old behavior). (I didn't look to see who and when this was changed.)
Since this text will have to be rewritten to address IA_PDs, and also it
is  not really clear (at least to me) what the original text "means", I
reverted the change to the original for the time being. In fact, the
placement of status codes should be resolved in ticket #60, so we will
not loose the track of this problem.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Apr 2014 14:04:38 +0000

There are two "error" cases (sticking to RFC 3315):

1.       The server will allocate NO addresses: The Advertise in this case has no IA_* options in the Advertise and only the NoAddrsAvail status code option.

2.       The server allocated one or more addresses, but not in some IA_* options: The Advertise has no status code option (the IA_* for which no addresses were allocated have no IAADDR options).

The IA_PD is kind of separate because this is not addresses and the NoPrefixAvail status code option is inside the IA_PD.

-          Bernie

From: Marcin Siodelski [mailto:[email-masked]]
Sent: Tuesday, April 08, 2014 6:30 AM
To: Bernie Volz (volz); DHCPv6 bis list
Subject: Re: [Dhcpv6bis] Merged RFC7083 into RFC3315bis

Marcin:

In 17.1.3, the text:

   to the user.

   to the user.

   to the user.

I'm also wondering why we have this text say this since the IA_NA and IA_TA should not be returned anyway?
I am not clear. I actually thought that the server would return status code in the global scope (and no IAs) only if it was unable to allocate the addresses for all IAs:

   option with the client's DUID.
So, my take on this was that the server may return an IA in Advertise, if some of bindings can be created, even if other bindings can't.

It seems that your understanding of this paragraph is that "if at least for one IA there will be no binding created, a status code is sent in the global scope and no other IAs are included".?

The old text was:

And I thought we agreed NOT to change this behavior (the stateful issues draft clearly says to keep the old behavior). (I didn't look to see who and when this was changed.)
Since this text will have to be rewritten to address IA_PDs, and also it is  not really clear (at least to me) what the original text "means", I reverted the change to the original for the time being. In fact, the placement of status codes should be resolved in ticket #60, so we will not loose the track of this problem.

Marcin