Subject: Re: [manet] [Technical Errata Reported] RFC7181 (4874)

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 25 Jan 2017 16:48:02 +0000

Christopher:

Thanks for looking into this report.

I don’t have an opinion as to which option is better, but I do have a question:  What is implemented and deployed?   Section 17. (Information Base Changes), which is the header for the changes the follow (including of course 17.1) makes the process normative and mandatory: “The changes described in the following sections MUST be carried out…”  So it is important to choose the “right” solution.

Thanks!

Alvaro.

On 12/1/16, 5:00 AM, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:

Author.

There is an issue, and the proposed resolution would work, and is probably the minimal textual change. But it's potentially confusing creating a tuple to immediately change it.

I can see two possible better (in my opinion) texts, I'd appreciate comment (especially from co-author) on preference to recommend as correction (including possibly for version I dislike).

NEW (1):

   If the router changes its originator address, then:

   1.  If there is an Originator Tuple with:

       *  O_orig_addr = old originator address

       then modify it as follows:

       *  O_orig_addr := new originator address
       *  O_time := current time + O_HOLD_TIME

       otherwise create an Originator Tuple with:

       *  O_orig_addr := new originator address
       *  O_time := current time + O_HOLD_TIME

NEW (2):

   If the router changes its originator address, then:

   1.  If there is an Originator Tuple with:

       *  O_orig_addr = old originator address

       then remove it.

   2.  Create an Originator Tuple with:

       *  O_orig_addr := new originator address
       *  O_time := current time + O_HOLD_TIME

I think I prefer NEW (2).

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]]
Sent: 01 December 2016 08:30
To: [email-masked]<mailto:[email-masked]>; Dearlove, Christopher (UK); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Technical Errata Reported] RFC7181 (4874)

----------------------! 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 RFC7181, "The Optimized Link State Routing Protocol Version 2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7181&eid=4874

--------------------------------------
Type: Technical
Reported by: Nikolai Malykh <[email-masked]<mailto:[email-masked]>>

Section: 17.1

Original Text
-------------
   If the router changes its originator address, then:

   1.  If there is no Originator Tuple with:

       *  O_orig_addr = old originator address

       then create an Originator Tuple with:

       *  O_orig_addr := old originator address

       The Originator Tuple (existing or new) with:

       *  O_orig_addr = new originator address

       is then modified as follows:

       *  O_time := current time + O_HOLD_TIME

Corrected Text
--------------
   If the router changes its originator address, then:

   1.  If there is no Originator Tuple with:

       *  O_orig_addr = old originator address

       then create an Originator Tuple with:

       *  O_orig_addr := old originator address

       The Originator Tuple (existing or new) with:

       *  O_orig_addr = old originator address

       is then modified as follows:

       *  O_orig_addr := new originator address

       *  O_time := current time + O_HOLD_TIME

Notes
-----
At the time of the modification Originator Tuple with O_orig_addr = new originator address does not yet exist.

Instructions:
-------------
This erratum 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 can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7181 (draft-ietf-manet-olsrv2-19)
--------------------------------------
Title               : The Optimized Link State Routing Protocol Version 2
Publication Date    : April 2014
Author(s)           : T. Clausen, C. Dearlove, P. Jacquet, U. Herberg
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: Christopher Dearlove <[email-masked]>
Date: Wed, 25 Jan 2017 12:57:56 -0500

The point should be that both produce functionally identical results, it's a question of which is clearer. Whichever is written, an implementation can always do either, or even a third option - there's a specific permission given to do whatever you like as long as you behave as if you followed the rules precisely. I'm fairly sure there are implementations that take advantage of that in places (not necessarily here).

(I'm doing this on a phone, without being able to check details. But I'm assuming the preference I gave below is still my preference. But others may have other opinions.)

--  
Christopher Dearlove
[email-masked]

> On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Christopher:
>  
> On 12/1/16, 5:00 AM, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
>  
> Author.
>  
> T:  +44 (0)1245 242194  |  E: [email-masked]
>  
> To: [email-masked]; Dearlove, Christopher (UK); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Reported by: Nikolai Malykh <[email-masked]>
>  
> Section: 17.1
>  
> Original Text
> -------------
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Justin Dean <[email-masked]>
Date: Wed, 25 Jan 2017 18:41:57 +0000

I prefer Chris' first proposal as it's what I do in my code to preserve
other metadata associated with the entry. The delete then add is just as
clean consepually but not how I tend to do things.  Both of Chris'
proposals are more clear in the intent (although functionally identical)
than the proposed change.

Justin

On Wed, Jan 25, 2017, 12:58 PM Christopher Dearlove <
[email-masked]> wrote:

> The point should be that both produce functionally identical results, it's
> a question of which is clearer. Whichever is written, an implementation can
> always do either, or even a third option - there's a specific permission
> given to do whatever you like as long as you behave as if you followed the
> rules precisely. I'm fairly sure there are implementations that take
> advantage of that in places (not necessarily here).
>
> (I'm doing this on a phone, without being able to check details. But I'm
> assuming the preference I gave below is still my preference. But others may
> have other opinions.)
>
> --
> Christopher Dearlove
> I don’t have an opinion as to which option is better, but I do have a
> question:  What is implemented and deployed?   Section 17. (Information
> Base Changes), which is the header for the changes the follow (including of
> course 17.1) makes the process normative and mandatory: “The changes
> described in the following sections MUST be carried out…”  So it is
> important to choose the “right” solution.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
> There is an issue, and the proposed resolution would work, and is probably
> the minimal textual change. But it's potentially confusing creating a tuple
> to immediately change it.
>
>
>
> I can see two possible better (in my opinion) texts, I'd appreciate
> comment (especially from co-author) on preference to recommend as
> correction (including possibly for version I dislike).
>
>
>
> NEW (1):
>
>
>
> From: RFC Errata System [mailto:[email-masked]
> <[email-masked]>]
>
> To: [email-masked]; Dearlove, Christopher (UK);
> [email-masked]; [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.
>
> This erratum 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 can log in to change the status
> and edit the report, if necessary.
>
>
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 25 Jan 2017 15:32:00 -0500

Having just re-read both, today I agree with Justin, I prefer (1). If I'm that inconsistent in my preferences, I definitely could accept either.

-- 
Christopher Dearlove
[email-masked]
[email-masked] is dead

> On 25 Jan 2017, at 13:41, Justin Dean <[email-masked]> wrote:
> 
> I prefer Chris' first proposal as it's what I do in my code to preserve other metadata associated with the entry. The delete then add is just as clean consepually but not how I tend to do things.  Both of Chris' proposals are more clear in the intent (although functionally identical) than the proposed change.
> 
> Justin
> 
> 
>> On Wed, Jan 25, 2017, 12:58 PM Christopher Dearlove <[email-masked]> wrote: