Re: [Roll] DTSN increment and DAO-ACK

yes to update 6550,

On Thu, Apr 5, 2018 at 6:14 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Michael Richardson <mcr+ietf@sandelman.ca> 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.
>

agree with 1, 2 but no.3  disagree so suggest informational if
non-normative, but if BCP then normative.

>     >     * 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.
>
>
> yes,

AB

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>