Subject: [Dhcpv6bis] [dhcpv6bis] #163 (XML 3315): Address Michael's comments

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 15 Jun 2016 18:17:50 -0000

#163: Address Michael's comments

 Michael Richardson posted lots of useful comments on May 11th to the list
 (https://mailarchive.ietf.org/arch/msg/dhcpv6bis/q1KuADRBgwFPF9EChBDhxni_L9s).

 This ticket is created as a reminder that there's some outstanding work to
 do here.

 The changes are on mcr_review_201605 branch. This ticket is about going
 through
 them and either merging/cherry-picking it to master, rejecting them or
 creating new tickets for those that are considered controversial.

 Michael's comments are:
 {{{
 Is a version of xml2rfc newer than 2.5.1, which maybe permits <street>
 to be omitted?  I had to add <street></street> to Tim Winter's address
 to get xml2rfc to pass.  I didn't find a version newer than 2.5.1.

 Please forgive this stream-of-consciousness email, I haven't made
 edits for all of my comments, because some of them I don't know what to
 do.
 I can turn them into tickets if desired.

 Also, the .xml file has lots of trailing whitespace which is generally
 a bad idea in git, as it sees that as gratuitous changes.
 Commit: 5117803 cleans that up.

 I've created a branch: mcr_review_201605 with my commits.
 You may git merge, or git cherry-pick as it suits.
   https://github.com/dhcwg/rfc3315bis/compare/mcr_review_201605?expand=1

 * I think that the figure and associated description in section 5.3
 (prefix
   delegation), should be moved into section 5.4 (DHCP for Customer Edge
 Routers)
   commit ID:

 On the text (section: 10.0):
    The motivation for having more than one type of DUID is that the DUID
    must be globally unique, and must also be easy to generate.

 I wonder if: MUST be globally unique?  I suspect that we want SHOULD here
 though, if we upcase it.

 re: text
     The sort
     of globally-unique identifier that is easy to generate for any given
     device can differ quite widely.  Also, some devices may not contain
     any persistent storage.  Retaining a generated DUID in such a device
     is not possible, so the DUID scheme must accommodate such devices.

 I'm bothered by "Also, ..." not as a concept, but just as easy to
 understand English.

 * I think that UUID-based DUIDs should get a section, even if it's rather
   empty, and I added one, commit-ID:

 section 11:
   - when we speak about "A client", I think we really mean "A client
 system"
     rather than "a client dhcp instance".   I say this because I think
 that
     the common use on Linux of Network Manager and Android to spawn off
     multiple dhclient instances for each interface is incorrect.  They
 likely
     pick different DUIDs, and also I don't know if they re-use the
 constant IAID
     across multiple interfaces.
     I'm not sure if MIF says anything about multiple provisioning domains.
     How can a client *know* when it's speaking in multiple provisioning
     domains, or when it should treat (bridged) wifi and ethernet as if it
 was
     the same domain?

 section 13.1: is nice advice on how clients should behave.
     But:
                 Rate limiting of forwarded DHCP messages and server-side
                 messages are out of scope of this specification.
     seems to beg for a security review red flag!

 section 14:

    >A client is not expected to listen for a response during the entire
    >period between transmission of Solicit or Information-request
    >messages.

    I don't understand this.  is it saying that client can go into low-
 power
    mode?
    I think it's saying that after receiving a reply, (or timing out
 receiving
    one), that a client can ignore DHCP messages until it is interesting in
 a
    (trying) a renewal again.

 section 17:
    "The client which is performing..."
     found english awkward, commit: 0f86fc0

    also, deleted later paragraph that
    "If the client will accept a Reply message with committed leases..."

    probably the whole rapid commit discussion should go in a single place?
    probably the next paragraph, "Servers that can assign..." should be
 moved
    too?

    Split the reasons for initiating configuration exchange into numbered
    list, for future reference: commit: 528f53f

 section 1.4/1.5 and 17 intentionally overlap, but I don't feel that
 the introductory sections set the stage for section 17 well enough.

 Why do we write this:

    The client MUST NOT be using any of the
    addresses or delegated prefixes for which it tries to obtain the
    bindings by sending the Solicit message.  In particular, if the
    client had some valid bindings and has chosen to start the server
    solicitation process to obtain the bindings from a different server,
    the client MUST stop using the addresses and delegated prefixes for
    the bindings it had obtained from the previous server, and which it
    is now trying to obtain from a new server.

 are we really saying that this is a break-before-make situation?
 Is there a reason for this?

 There is a LOT of information in section 17; it seems almost like a random
 assembly of things...  We have section 17.1

 section 17.1:
    When a client detects it may have moved to a new link, it uses
    Confirm if it only has addresses and Rebind if it has delegated

 ... I'm not sure what the correct behaviour is for a virtual PPP link,
     such as DSL/PPPoE.   In the field, I do not observe this behaviour
     from dnsmasq.  It starts with Request every time the link drops.

     added some text about faked Reconfigure messages.

 re: DISCUSSION, do we have any field experience that enabling unicast
     communication is really occuring, and really has useful benefits?
     a) Could this be something that we might drop based upon the belief
        that DHCP relay agents provide useful information?
     b) if it is multicasting and message duplication that we care to
 avoid,
        could the client be told to unicast to the DHCP relay?

 I think that the 17.1.1 text about Rapid Commit is too convoluted.
 I would like either section 17.1.1 or 20.14 to say more about why the
 client
 would use the Rapid Commit option.  Who should use this?

 I edited the Rapid Commit vs Advertise text, I think that there is an
 interval missing during which the client notes the Advertise messages, but
 does not act on them while it looks for a Reply-with-Rapid commit.
 commit: e1509b3

 The two paragraphs starting with:
    If the client is waiting for an Advertise message, the mechanism in

 just seem to jump in the middle like a weird photo-bomb. I understood all
 the
 words, but couldn't figure out what's going on.  I think that maybe it has
 nothing to do with Rapid Commit, but is the primary text on how to listen
 to
 advertise messages.

 In that case, I suggest that those two paragraphs be moved upwards, and
 the
 Rapid Commit discussion come after the "first RT" interval has been
 explained.
       commit: 1c9dab0

 I stopped for lunch at 17.1.2, which my editor says is only 38% in.
 }}}

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

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

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 15 Jun 2016 18:18:05 -0000

Changes (by [email-masked]):

 * owner:   => [email-masked]

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

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