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

[Justin Dean <[e-mail]>]

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 <
[e-mail]> 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
> [e-mail]
>
> On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) <[e-mail]>
> wrote:
>
> 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)" <
> [e-mail]> 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:  [phone]  |  E: [e-mail]
>
>
>
> 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:[e-mail]
> <[e-mail]>]
>
> Sent: 01 December 2016 08:30
>
> To: [e-mail]; Dearlove, Christopher (UK);
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]
>
> Cc: [e-mail]; [e-mail]; [e-mail]
>
> 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 <[e-mail]>
>
>
>
> 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.
>
> ********************************************************************
>
>
>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>