Subject: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Apr 2013 13:23:25 +0100

Hi,

It's been brought to my attention that between -02 and -03 the form of the IPv6
option number was changed. I've had a quick chat with the chairs, and I'm
jumping in because of the implications for IANA (see below).

The act bits remain the same (01) indicating that the IPv6 node MUST discard the
packet if it doesn't recognize the option type.
But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit nodes can
now change the content of the option.

I have no comment on whether this is a good idea (the WG should decide about
that), but I haven't been able to find a discussion of this change on the list.
Perhaps it is buried in a ticket?

The problem caused is that the WG went through the hoop to ask for an early code
point allocation. part of that request is confirming that the content of the
IANA section is stable. The allocation was made against the -02 revision, so now
you have a code point in the registry that you say you do not want to use :-(

Let's sort out first things first. 
- Authors, please explain why the change was made.
- WG, please wait for the authors to explain, and then
  respond with your opinions.
- Chairs, please let me know what the consensus is.

Thanks,
Adrian

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 11 Apr 2013 14:52:29 +0000

The actions taken to change the HbH option chg bit predates the posting of -03.  Here is the summary of events:

1) 13 Jul 2012

We reposted -00 as -01 to change its status back to active.  At the same time, I sent my notes to the ROLL ML on areas that we needed to address in future revisions of the draft.  Among the list of items was the following:

"I'm aware of one technical bug with the HBH Option when trying to utilize a sliding window larger than 1.  In particular, a device processing the HBH Option does not know if the Sequence value represents the largest sequence value received by the neighboring node or an older message that it happens to be retransmitting.  Ideally, a device only resets its Trickle timer when receiving indication that a neighboring device has not yet received a message yet.  I propose adding a flag to the HBH Option that indicates whether the Sequence value is the latest."

http://www.ietf.org/mail-archive/web/roll/current/msg07224.html

2) 03 Aug 2012

We sent a proposed update to -01 to the ROLL ML.  As mentioned in that email, the intent was to provide WG members some additional visibility into how we were addressing the announced deficiencies and to prime discussion during the ROLL WG meeting.  This draft included the following change to the HbH Option Header:

   M                   1-bit flag. 0 indicates that the value in
                       sequence is not the largest sequence number that
                       was received from the MPL seed.

Unfortunately, this proposed text did not include necessary updates to the chg bit.

http://www.ietf.org/mail-archive/web/roll/current/msg07246.html

3) 19 Oct 2012

We collected comments, made further changes to the proposed text from August, and posted -02.  Unfortunately again, this text did not include necessary updates to the chg bit.

http://www.ietf.org/mail-archive/web/roll/current/msg07378.html

4) 20 Dec 2012

The IEST approved a code point allocation based on the chg bit set to zero.

http://www.ietf.org/mail-archive/web/roll/current/msg07611.html

5) 14 Jan 2013

In a private email exchange, Joseph Reddy pointed out to me that -02 had an inconsistency between the 'M' flag and the chg bit.  Ralph Droms was included on that mail and he indicated that we could get it modified "although the responsible AD may be a little cranky" :)  In any case, for whatever reason, we failed to announce the issue on the ROLL ML.

6) 24 Jan 2013

We posted -03 which includes the necessary text to align the chg bit with the use of the 'M' flag.

http://www.ietf.org/mail-archive/web/roll/current/msg07656.html

And now we are where we are today.

--
Jonathan Hui

On Apr 11, 2013, at 5:23 AM, Adrian Farrel <[email-masked]> wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Apr 2013 17:19:51 +0100

Hi Jonathan and Adrian,

[Reply to request] My opinion is that it is bad idea for transit nodes to
change option content. However, I did not understand the explaination that
there was inconsistency between M and chg, how?

AB

On Thu, Apr 11, 2013 at 3:52 PM, Jonathan Hui (johui) <[email-masked]>wrote:

> We reposted -00 as -01 to change its status back to active.  At the same
> time, I sent my notes to the ROLL ML on areas that we needed to address in
> future revisions of the draft.  Among the list of items was the following:
>
> "I'm aware of one technical bug with the HBH Option when trying to utilize
> a sliding window larger than 1.  In particular, a device processing the HBH
> Option does not know if the Sequence value represents the largest sequence
> value received by the neighboring node or an older message that it happens
> to be retransmitting.  Ideally, a device only resets its Trickle timer when
> receiving indication that a neighboring device has not yet received a
> message yet.  I propose adding a flag to the HBH Option that indicates
> whether the Sequence value is the latest."
>
> We sent a proposed update to -01 to the ROLL ML.  As mentioned in that
> email, the intent was to provide WG members some additional visibility into
> how we were addressing the announced deficiencies and to prime discussion
> during the ROLL WG meeting.  This draft included the following change to
> the HbH Option Header:
>
> We collected comments, made further changes to the proposed text from
> August, and posted -02.  Unfortunately again, this text did not include
> necessary updates to the chg bit.
>
> In a private email exchange, Joseph Reddy pointed out to me that -02 had
> an inconsistency between the 'M' flag and the chg bit.  Ralph Droms was
> included on that mail and he indicated that we could get it modified
> "although the responsible AD may be a little cranky" :)  In any case, for
> whatever reason, we failed to announce the issue on the ROLL ML.
>

[Procedure comment] I recommend that any editing update should be discussed
on list not private but still this practice I see in some WGs in IETF, but
some like to reduce volume of messages. If something related to WG business
not discussed in IETF then I assume that event never occured (only personal
issues may occur). However, you now posted some details in IETF. I may be
not familiar with the registration process but why we do it before the end
of the WGLC, if before we will always get into that situation.