Subject: Re: [manet] [Technical Errata Reported] RFC5444 (3496)

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 1 Mar 2013 08:24:01 +0100

I *reject* the proposal (but agree with change needed for update),
because I read the way of errata-review as mentioned in IETF guide,

Rejected - The erratum is in error, or proposes a change to the RFC
that should be done by publishing a new RFC that replaces the current
RFC. In the latter case, if the change is to be considered for future
updates of the document, it should be proposed using channels other
than the errata process, such as a WG mailing list.

Please in future guide participants of the special way of
review/respond/judge, because it is first time for me, I was not
familiar to this,

AB

On 2/25/13, RFC Errata System <[email-masked]> wrote:
>
> The following errata report has been submitted for RFC5444,
> "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=3496
>
> --------------------------------------
> Type: Technical
> Reported by: Christopher Dearlove <[email-masked]>
>
> Section: Appendix A
>
> Original Text
> -------------
>    o  The <pkt-seq-num> field, if present, contains a sequence number
>       that is incremented by 1 for each packet generated by a node.  The
>       sequence number after 65535 is 0.  In other words, the sequence
>       number "wraps" in the usual way.
>
>
> Corrected Text
> --------------
>    o  The <pkt-seq-num> field, if present, contains a sequence number
>       that SHOULD be maintained for each participating interface and
>       incremented by 1 for each packet generated by a node for that
>       interface.  The sequence number after 65535 is 0.  In other words,
>       the sequence number "wraps" in the usual way.
>
>
> Notes
> -----
> Packet sequence number should be per interface, not per node. Uses that
> recognise missing packet sequence numbers only work in the corrected
> (intended) case.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5444 (draft-ietf-manet-packetbb-17)
> --------------------------------------
> Title               : Generalized Mobile Ad Hoc Network (MANET)
> Packet/Message Format
> Publication Date    : February 2009
> Author(s)           : T. Clausen, C. Dearlove, J. Dean, C. Adjih
> Category            : PROPOSED STANDARD
> Source              : Mobile Ad-hoc Networks
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 1 Mar 2013 09:13:05 +0100

Luckily I think you are pretty alone with this opinion.

The way the packet sequence numbers were described was definitely a
mistake. I don't think anyone who USED packet sequence numbers with
RFC5444 has used them in this way.

In addition to this there was no protocol which included usage of the
packet sequence number...

except maybe RFC 6130, but the usage described in the RFC would NOT
work unless we include this errata.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 Mar 2013 11:30:59 -0000

> what you mean by *participating interface* do you mean NHDP-RFC6130,
> how does the interface maintain such number? is there an answer in any
> MANET doc?

Erm, a "participating interface" is one that is participating in this RFC.

How does an interface maintain a sequence number?
That is an implementation detail. We don't write implementation specs.
Most people use registers, variables, or other forms of storage. I knew a vendor
that tired to use pixie dust, but they went Chapter 11.

> Why you say SHOULD not MUST, or RECOMMENDED, please advise,

RECOMMENDED would equate to SHOULD so there is no question there.
I admit I shuffled my feet over the inclusion of a new 2119 word through this
Errata Report.
My thinking was that this is what everyone is doing in their implementations and
it is clearly what was intended.
It is not mandatory to maintain the counter in this way and there may be
implementation reasons for doing something different. However, doing it
different will reduce the functionality achieved through the use of the sequence
number.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 Mar 2013 11:35:18 -0000

Resend just to the mailing list

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 01 March 2013 11:31
> To: 'Abdussalam Baryun'; 'RFC Errata System'
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]'
> Subject: RE: [manet] [Technical Errata Reported] RFC5444 (3496)
> 
> Hi,
> 
> Thanks, but you are not in a position to reject or approve anything here.
> Even Thomas may agree that sometimes the AD is empowered to make
> decisions.
> The rejection or approval of errata sits with the AD.
> 
> Thanks for your opinion.
> I did consider this text when I approved the errata.
> I do not believe that this is a change that "should be done by publishing a
new
> RFC"
> I have sent AB a private email on how the errata process works. Am willing to
> share it with others on request.
> 
> Adrian

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 1 Mar 2013 15:38:53 +0100

I think it's OK to have SHOULD here. 
But isn't it better to have a few words to explain why not MUST, or what's the consequence of not doing that in the corrected text? In that case, the implementors would know that if they are trying to tracing missing pack using packet sequence number, this must be done. 

best

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 2 Mar 2013 09:46:51 +0100

> that tired to use pixie dust, but they went Chapter 11.

The interface participating in this RFC is will usually RFC6130 (only
one using RFC5444 so far). Regarding the sequence number maintained in
MANET interfaces, I don't think it is only an implementation parameter
but also sepecification parameter. Why not add sequence number as a
new interface parameter in RFC6130-section-5.3? for not updating the
question still stands, how does RFC6130 maintain such parameter which
is assigned in RFC5444 packets?

As long as this errata mentions the interface's number, Is it a must
parameter maintain for interface that uses RFC5444? I think so yes,

<Please not that this message is only discussion as I have not
received end of discussion/date related to this errata.>

AB

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 Mar 2013 11:01:21 -0000

Hi,

Wrt end of discussion date for this errata...
Gone. Done. Ended. Errata has been verified. Move along now please, there is
nothing to see.

> >> >       interface.  The sequence number after 65535 is 0.  In other
> >> >       words, the sequence number "wraps" in the usual way.
> >>
> > Most people use registers, variables, or other forms of storage. I knew a
> > vendor that tried to use pixie dust, but they went Chapter 11.
> 

I am probably having trouble parsing what you wrote.
Let me reiterate that we do not write implementation specifications.

You asked *how* an interface maintains a sequence number, and the answer to that
is quite clearly out of scope.

You say "I don't think it is only an implementation parameter but also
sepecification parameter".  That is a thought, not an argument. Your thoughts
are very interesting to us, but only those supported with reasoning are likely
to gather support. Can you explain why it is necessary for two interoperable
implementations to know how the other stores or maintains a sequence number?

Now you reference 5.3 of 6130. This is a list of parameters that affect the
on-the-wire performance of the protocol. Several are configurable, and several
are qualities of the interface.

> parameter maintain for interface that uses RFC5444? I think so yes,

You are now talking about interface number?
That is a change of track, but anyway, this errata report does not mention
interface number.

Thanks,
Adrian