[Roll] DTSN increment and DAO-ACK

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> wrote:
    >     * how to handle DTSN increment? want to also check how BIER does

..

    >     * MCR: excellent work, should adopt it. Lots of useful
    > points. Hadn't realized that the spec was ambiguous.
    >     * MCR: one document with solution: e.g. DTSN increment is clearly a
    > bug in the spec.
    >     * MCR: another document to discuss issues we don't have a solution
    > for.

My impression is that there is some clarification needed in 6550.
I don't know if this should be done as errata or as an Updates, bacause
I haven't internalized the scale of the issue.

    >     * Pascal: explains thinking about DAO-ACK. We need something to
    > solve the end-to-end delivery.

    >     * MCR: seems Pascal agrees. Just clarified a lot of things. 6550
    > did not capture that clearly. Low hanging fruit document should only
    > include non-controversial points.
    >     * MCR: a bunch of knowledge just exposed, glad it's captured on
    > tape. Want to capture it in text quickly.

What I took home from the discussion is that DAO-ACK SHOULD be used on
networks where this is no L2 confirmation.  That it's not end-to-end
(which is what I implemented!), and if we want end-to-end ACK, it
would be a new extension.


    >     * Rahul: will go to the mailing list to get consensus on what is
    > non-controversial

Just a reminder...  Here a a few options that I was thinking about:

1) It's time to do rfc6550bis.  This could be a non-trivial amount of work.
   It can be bounded in time, but it's hard to do.

2) We should write a document that Updates RFC6550.
2a) The *WG* creates a design team to create a low-hanging fruit document.
    It would start with a document (already adopted by the WG. The DHCP WG
    did this wrong in my opinion) that is essentially starts empty.
    The design team would scavenge content from Rahul's document and
    apply WG consensus to it being non-controversial.  Lather.Rinse.Repeat.

2b) We adopt Rahul's document, or a version of, and then discover which
    parts are controversial, and remove them until we have a simple
    document.  If left with empty set, STOP.

    Constroversial items go into new documents.

3) We adopt Rahul's document as a BCP and it contains non-normative
   language only.

    >     * Rahul: understand could maintain this draft as long as needed,
    > and develop solutions in other documents?
    >     * Carsten: in the past in RoHC WG, have kept a standing doc for 5
    > years.

That's reasonable for some things, but not for others.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-