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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 May 2014 10:19:38 +0000

Wearing my author hat, I agree with this erratum. But then I would, as I also submitted it. OK, over to the rest of you.

(I was very tempted to make an additional editorial wording change in those paragraphs, "on which" to "that". But resisted as that just muddies the waters.)

The parenthetical comment in the Notes is about a bug in the RFC erratum tool, I've sent that to the RFC editor separately. If the RFC editor (or IESG) can restore the indentation and remove the comment, fine by me.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]] 
Sent: 29 May 2014 10:46
To: [email-masked]; Dearlove, Christopher (UK); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Dearlove, Christopher (UK); [email-masked]; [email-masked]
Subject: [Technical Errata Reported] RFC5444 (4003)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

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

--------------------------------------
Type: Technical
Reported by: Christopher Dearlove <[email-masked]>

Section: Appendix B

Original Text
-------------
  o  <msg-hop-limit> field, if present, contains the number of hops on
     which the packet is allowed to travel before being discarded by a
     MANET router.  The <msg-hop-limit> is set by the message
     originator and is used to prevent messages from endlessly
     circulating in a MANET.  When forwarding a message, a MANET router
     should decrease the <msg-hop-limit> by 1, and the message should
     be discarded when <msg-hop-limit> reaches 0.

  o  <msg-hop-count> field, if present, contains the number of hops on
     which the packet has traveled across the MANET.  The <msg-hop-
     count> is set to 0 by the message originator and is used to
     prevent messages from endlessly circulating in a MANET.  When
     forwarding a message, a MANET router should increase <msg-hop-
     count> by 1 and should discard the message when <msg-hop-count>
     reaches 255.

Corrected Text
--------------
  o  <msg-hop-limit> field, if present, contains the number of hops on
     which the message is allowed to travel before being discarded by a
     MANET router.  The <msg-hop-limit> is set by the message
     originator and is used to prevent messages from endlessly
     circulating in a MANET.  When forwarding a message, a MANET router
     should decrease the <msg-hop-limit> by 1, and the message should
     be discarded when <msg-hop-limit> reaches 0.

  o  <msg-hop-count> field, if present, contains the number of hops on
     which the message has traveled across the MANET.  The <msg-hop-
     count> is set to 0 by the message originator and is used to
     prevent messages from endlessly circulating in a MANET.  When
     forwarding a message, a MANET router should increase <msg-hop-
     count> by 1 and should discard the message when <msg-hop-count>
     reaches 255.

Notes
-----
Two changes of "packet" to "message". Message is consistent with the normative Section 5.2 that defines these fields (which may appear in each message, so are not uniquely defined for a packet), the text introducing these bullet points, and the remainder of these paragraphs.

(Note that the original and corrected text has had indentation reduced by one space.)

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 May 2014 11:34:52 +0100

Christopher,

I went ahead and approved this report, except I "downgraded" it to an Editorial
issue because:
- it is in a non-normative appendix
- I don't believe that the error would have caused any mis-implementation or
interop problem

Thanks,
Adrian

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: 29 May 2014 11:20
> To: RFC Errata System; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Technical Errata Reported] RFC5444 (4003)
> 
> Wearing my author hat, I agree with this erratum. But then I would, as I also
> submitted it. OK, over to the rest of you.
> 
> (I was very tempted to make an additional editorial wording change in those
> paragraphs, "on which" to "that". But resisted as that just muddies the
waters.)
> 
> The parenthetical comment in the Notes is about a bug in the RFC erratum tool,
> I've sent that to the RFC editor separately. If the RFC editor (or IESG) can
restore
> the indentation and remove the comment, fine by me.
> 
> --
> Christopher Dearlove
> To: [email-masked]; Dearlove, Christopher (UK);
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> ----------------------! WARNING ! ---------------------- This message
originates from
> outside our organisation, either from an external partner or from the
internet.
> The following errata report has been submitted for RFC5444, "Generalized
> Mobile Ad Hoc Network (MANET) Packet/Message Format".
> 
> Two changes of "packet" to "message". Message is consistent with the normative
> Section 5.2 that defines these fields (which may appear in each message, so
are
> not uniquely defined for a packet), the text introducing these bullet points,
and
> the remainder of these paragraphs.
> 
> 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.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 May 2014 11:38:57 +0000

Well, actually it arose (Charlie spotted it, but not as an erratum) because it was threatening  mis-implementation, or at least mis-specification, in AODVv2. But really it is editorial, because the number of surrounding uses of message should have been a strong hint that it really was about messages, not packets, and it certainly was an editorial sort of error by the authors. I can live with it either way.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 29 May 2014 11:35
To: Dearlove, Christopher (UK); 'RFC Errata System'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Technical Errata Reported] RFC5444 (4003)

Christopher,

I went ahead and approved this report, except I "downgraded" it to an Editorial issue because:
- it is in a non-normative appendix
- I don't believe that the error would have caused any mis-implementation or interop problem

Thanks,
Adrian

> Wearing my author hat, I agree with this erratum. But then I would, as 
> I also submitted it. OK, over to the rest of you.
> 
> (I was very tempted to make an additional editorial wording change in 
> those paragraphs, "on which" to "that". But resisted as that just 
> muddies the
waters.)
> 
> The parenthetical comment in the Notes is about a bug in the RFC 
> erratum tool, I've sent that to the RFC editor separately. If the RFC 
> editor (or IESG) can
restore
> Senior Principal Engineer, Communications Group Communications, 
> Networks and Image Analysis Capability BAE Systems Advanced Technology 
> Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales 
> No: 1996687
> 
> 
originates from
internet.
> Follow the 'Report Suspicious Emails' link on IT matters for 
> instructions on reporting suspicious email messages.
> The following errata report has been submitted for RFC5444, 
> "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format".
> 
> Two changes of "packet" to "message". Message is consistent with the 
> normative Section 5.2 that defines these fields (which may appear in 
> each message, so
are
and
> (Note that the original and corrected text has had indentation reduced 
> by one
> space.)
> 
> Instructions:
> -------------
All"
reached,
report, if

---

From: RFC Errata System <[email-masked]>
Date: Thu, 29 May 2014 02:45:54 -0700 (PDT)

Section: Appendix B

Original Text
-------------

Corrected Text
--------------

Notes
-----

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.