Subject: [Dhcpv6bis] [dhcpv6bis] #161 (XML 3315): The text should reference RFC4242

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

#161: The text should reference RFC4242

 We decided to not include RFC4242 text in 3315bis. However, this is a
 mechanism that is there and should be referenced, possibly with a single
 sentence explaining how it work.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [email-masked]         |  [email-masked]
     Type:  task                     |     Status:  new
 Priority:  P1 blocker               |  Milestone:  D stateful issues
Component:  XML 3315                 |   Keywords:
 Due Date:  21/05/2016               |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/161>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

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

Changes (by [email-masked]):

 * milestone:  D stateful issues => E Editor issues

> sentence explaining how it work.

New description:

 We decided to not include RFC4242 text in 3315bis. However, this is a
 mechanism that is there and should be referenced, possibly with a single
 sentence explaining how it works.

--

Comment:

 I have added the following text in Section 17.1.6. Creation and
 Transmission of Information-request Messages:

 [RFC4242] defines Information Refresh Time option that allows servers
 to specify when clients should refresh their configuration parameters
 received in Information-Request message.

 Do you think it would be ok to make support for RFC4242 mandatory? It's a
 simple and very useful mechanism. Without it, the clients could get stuck
 with the outdated configuration information.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]         |  [email-masked]
     Type:  task                     |      Status:  new
 Priority:  P1 blocker               |   Milestone:  E Editor issues
Component:  XML 3315                 |  Resolution:
 Keywords:                           |    Due Date:  21/05/2016
-------------------------------------+-------------------------------------

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Sat, 21 May 2016 18:11:10 -0000

Comment (by [email-masked]):

 The text in RFC 4242 is:

    A client MUST request this option in the Option Request Option (ORO)
    when sending Information-Request messages to the DHCPv6 server.  A
    client MUST NOT request this option in the ORO in any other messages.

 But this allows an out as a client may not support RFC 4242.

 However, I think we should make it mandatory, so I agree that adding a
 sentence about this in section 17.1.6 would be good.

 Why not remove what you added (see comment1) and update the following
 paragraph:

    The client MUST include an Option Request option (see Section 20.7)
    to request the INF_MAX_RT option (see Section 20.24) and any other
    options the client is interested in receiving.  The client MAY
    include options with data values as hints to the server about
    parameter values the client would like to have returned.

 To:

    The client MUST include an Option Request option (see Section 20.7)
    to request the INF_MAX_RT option (see Section 20.24), the Information
    Refresh Time option [RFC4242], and any other
    options the client is interested in receiving.  The client MAY
    include options with data values as hints to the server about
    parameter values the client would like to have returned.

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