Re: [manet] [Technical Errata Reported] RFC7181 (4874)
Christopher Dearlove <christopher.dearlove@gmail.com> Wed, 25 January 2017 20:32 UTC
Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4538E129BC6 for <manet@ietfa.amsl.com>; Wed, 25 Jan 2017 12:32:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqr0F2AzVrAi for <manet@ietfa.amsl.com>; Wed, 25 Jan 2017 12:32:05 -0800 (PST)
Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92195129BC2 for <manet@ietf.org>; Wed, 25 Jan 2017 12:32:03 -0800 (PST)
Received: by mail-qt0-x244.google.com with SMTP id l7so33657699qtd.3 for <manet@ietf.org>; Wed, 25 Jan 2017 12:32:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=LSWHD5tMsY0jS1EXMTNfRU+5YYvAPQwnJgcsEGWw7Hs=; b=sPtniZGiwDaucvU52ARHm8YQ1Oh6aw44d5h3lMN2hqsaxGq2zBwE+eIDr6YS1BEIkl /I3zvzcZbcv/lXRyKoZSK4kwqh7KkBIbWpoki62p+rcZsVAkx/JfEHLENGYFLbNlg12n vB4QI5X3lD2f2j3yqD9Pwe0shrvr6XgXOZE0YT5CKKIVtHuf2k4+VX69EpJy2BFGtowv LGeRD3QIjqCodxIk+t2l4kp8w3yhrdSzo96gfkXAGYupOvrdBdkI2olYmrK78htt2RSD Gh94Ursbr04ED3FCAzCqfbQl6ZX0dGinGqZC8k3Ij1tpmjoyZ4CwoTJitVN1yUgjev2A HavQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=LSWHD5tMsY0jS1EXMTNfRU+5YYvAPQwnJgcsEGWw7Hs=; b=roDygEKmbaTx7J1aJ5rnnume4AMz33e2gV/vFaH4IzXYczTCVHHfTBl6P7X73YWmI+ 9TE9nQEyP+ACdzw3yT9Cl4lUP1M8viCSHJcohii3JUC0HZvFqz+R/Olsv21IMhr01qui 4oK5i7Hdgs4fEGCbO6EYyd3crs4eF319CnnqGyaukusLmuvI3eYpSJWeOUUX5Q9Q7c+7 RGikg7paUbzXNhmYhhdhQIAS+LCNIG6VFXft0VP3wcR9mU2tUo2i1ZXrCtx5HfP91app 2IU60xh8jL+Nwk8Cr7cLUQUvrNRYDwfMexVu79Qz6DsTqWKy+K1h3U9mqsH3lO3lAaY6 w6kA==
X-Gm-Message-State: AIkVDXL9noe3fIl8C/tblueOqkm5BweTJJfvVkFSPZbUC5ZL2UyblG6psStrnEJeTxEUmQ==
X-Received: by 10.55.148.71 with SMTP id w68mr29838739qkd.130.1485376322631; Wed, 25 Jan 2017 12:32:02 -0800 (PST)
Received: from [9.59.144.242] ([129.34.8.20]) by smtp.gmail.com with ESMTPSA id h33sm18491385qtc.42.2017.01.25.12.32.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 12:32:01 -0800 (PST)
References: <20161201082942.785D0B801CF@rfc-editor.org> <B31EEDDDB8ED7E4A93FDF12A4EECD30DA1F28647@GLKXM0002V.GREENLNK.net> <FEE0854C-4E26-43AD-934B-7A15F603724C@cisco.com> <F003421B-9314-4A0B-84EE-539520B7706A@gmail.com> <CA+-pDCfiWwoTg0NmMXM9CQBeNQpnqOmOg==n1S3hWAgBbx_pGg@mail.gmail.com>
In-Reply-To: <CA+-pDCfiWwoTg0NmMXM9CQBeNQpnqOmOg==n1S3hWAgBbx_pGg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="Apple-Mail-7ECF6846-A810-44E1-855F-7438F1B26C92"
Message-Id: <5CF1E8A2-DC63-4A0E-9363-C2F8E3DFE95F@gmail.com>
X-Mailer: iPhone Mail (14C92)
From: Christopher Dearlove <christopher.dearlove@gmail.com>
Date: Wed, 25 Jan 2017 15:32:00 -0500
To: Justin Dean <bebemaster@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/9C0SwlexslEvUL0Rem8M0yVfJ9w>
X-Mailman-Approved-At: Wed, 25 Jan 2017 12:44:34 -0800
Cc: "nmalykh@gmail.com" <nmalykh@gmail.com>, "db3546@att.com" <db3546@att.com>, "T.Clausen@computer.org" <T.Clausen@computer.org>, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>, "manet@ietf.org" <manet@ietf.org>, "akatlas@gmail.com" <akatlas@gmail.com>, "philippe.jacquet@alcatel-lucent.com" <philippe.jacquet@alcatel-lucent.com>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [manet] [Technical Errata Reported] RFC7181 (4874)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2017 20:32:15 -0000
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 christopher.dearlove@gmail.com chris@mnemosyne.demon.co.uk is dead > On 25 Jan 2017, at 13:41, Justin Dean <bebemaster@gmail.com> 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 <christopher.dearlove@gmail.com> 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 >> christopher.dearlove@gmail.com >> >>> On 25 Jan 2017, at 11:48, Alvaro Retana (aretana) <aretana@cisco.com> 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)" <chris.dearlove@baesystems.com> 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: chris.dearlove@baesystems.com >>> >>> >>> >>> 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:rfc-editor@rfc-editor.org] >>> >>> Sent: 01 December 2016 08:30 >>> >>> To: T.Clausen@computer.org; Dearlove, Christopher (UK); philippe.jacquet@alcatel-lucent.com; ulrich@herberg.name; akatlas@gmail.com; db3546@att.com; aretana@cisco.com; sratliff@idirect.net; bebemaster@gmail.com >>> >>> Cc: nmalykh@gmail.com; manet@ietf.org; rfc-editor@rfc-editor.org >>> >>> 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 <nmalykh@gmail.com> >>> >>> >>> >>> 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 >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet
- [manet] [Technical Errata Reported] RFC7181 (4874) RFC Errata System
- Re: [manet] [Technical Errata Reported] RFC7181 (… Dearlove, Christopher (UK)
- Re: [manet] [Technical Errata Reported] RFC7181 (… Alvaro Retana (aretana)
- Re: [manet] [Technical Errata Reported] RFC7181 (… Christopher Dearlove
- Re: [manet] [Technical Errata Reported] RFC7181 (… Justin Dean
- Re: [manet] [Technical Errata Reported] RFC7181 (… Christopher Dearlove