Re: [Roll] DTSN increment and DAO-ACK

[Rahul Jadhav <[e-mail]>]

Hi Michael, 

I agree to all of the things that you mentioned.  

There are few more points that we had not added in the observations draft because of lack of time for Ietf101. We wanted to add only after getting some performance figures and more clarifications. Expect an update for the observations draft in couple of weeks.

Thanks for initiating the discussion.

Regards,

Rahul 

https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?iconUrl=http%3A%2F%2Fmail-online.nosdn.127.net%2Fa8f46e6224238090e9bbe72a9963d42f.jpg&name=Rahul%20Jadhav&uid=example%40163.com&ftlId=3&items=%5B%22%E9%82%AE%E7%AE%B1%EF%BC%9Arahul.ietf%40gmail.com%22%5D" width="400" rel="nofollow">

http://mail-online.nosdn.127.net/a8f46e6224238090e9bbe72a9963d42f.jpg">

Rahul Jadhav 邮箱：[e-mail]

签名由 https://mail.163.com/dashi/dlpro.html?from=mail88" rel="nofollow">网易邮箱大师 定制

On 04/06/2018 00:14, Michael Richardson wrote:

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 =-



_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll