[bess] Referencing material behind a paywall
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 07 December 2018 21:20 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232FC130FEB; Fri, 7 Dec 2018 13:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 7gRtb_EvdeJw; Fri, 7 Dec 2018 13:20:56 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24207130FEC; Fri, 7 Dec 2018 13:20:55 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id wB7LKnpb013270; Fri, 7 Dec 2018 21:20:49 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 00B6A2203B; Fri, 7 Dec 2018 21:20:49 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id DF64F2203A; Fri, 7 Dec 2018 21:20:48 +0000 (GMT)
Received: from LAPTOPK7AS653V ([81.174.186.130]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id wB7LKlk2013315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Dec 2018 21:20:48 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Satya Mohanty (satyamoh)'" <satyamoh@cisco.com>
Cc: ietf@ietf.org, bess@ietf.org, rse@rfc-editor.org, rtg-dir@ietf.org
Date: Fri, 07 Dec 2018 21:20:47 -0000
Organization: Old Dog Consulting
Message-ID: <0f2e01d48e72$b9581340$2c0839c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdSOcFEaqToZ/E5HTCuKRToPwxsFLg==
Content-Language: en-gb
X-Originating-IP: 81.174.186.130
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24270.001
X-TM-AS-Result: No--27.167-10.0-31-10
X-imss-scan-details: No--27.167-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24270.001
X-TMASE-Result: 10--27.167000-10.000000
X-TMASE-MatchedRID: er5VKMiLVuDyha4uErRN/X8BHjT6HmzuHUEsjxm+pgiRp7TNwi8hyKWe cuVfuJfEHvcGqjQfvM8dZd35+aiIo9Oj+pyuOKHQ/jkwiY2tJnJvT/oDZNFxn7v408/GP5HqweK e47kCnaHK39U0sdfUJeZbTTx0KuX2jeaAXTNKmaOdVNZaI2n6/9ZKsq3DGpalYAwzRYoPhqxtD/ Ob6b+pjoDo0aMCQqpUWxSuMo3BgPrMBbTcHjlr2obBPrt55wnwt+hhn8Iy6GUutoY2UtFqGFdVh cU0C7v4VJB+AD3XgOUwtKuqJJyiMGYYdpefaEloMN+B8zdlz9ERNp7xD+4vUS1bKLdhloRJqlwa mkK/UX2m8h0elQQToQwYFUIMjeXdJoswqQpTupxT46Ow+EhYOK/Nc0jg2jTVyL0CMroLynXg9LI t2OdOa+PILsXcae0ztNB04F+WSPes++Q0V/nfZClrosmS0SOAbv16+gil4jcsugxReYWqZiSOmr PBOTFpn58TI6XOhAp+c4KDq3sC/m18DcO3+y6JVgfmhm+zInjDHSNFHFxB8w4AepdqPBUYFSUV/ DOyrJYeyfXfqClx0l9OShf0V2997YGIARphfZ7mAId+2bAQwmahdCNFKpJhPILl10bYlyAyEgyW hEdDbR+HsENqyy7RC79mHl6L5XZmHCESzdHlJRYUH2zzZ4zbI0ZIn3NG5Q2WZE3Bs8CDTyAUSRb oKHUgRD8alszirPliSVnIdboij5On/FuwsX5vyATMS/tDL5hWjiXAsVR2K9CmiQVJO8KAB/u1ff i/SlFjU6c4SBcfgRoZi42QUfydjlkz19bnEOCeAiCmPx4NwFkMvWAuahr8vCaAzkS8BHsCIXrkW OgT/QtuKBGekqUpIG4YlbCDECsWefvMt+drgg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/T47tlmuswbj1VFDh5QkA-p8ZMHc>
Subject: [bess] Referencing material behind a paywall
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 21:20:59 -0000
Hi, [Changed the subject line, tried to reduce the recipients (but it's still a bit much), added the RSE in case she has advice] It's tricky. Sometimes we need to reference material that is behind a paywall or simply in a paper journal. Sometimes we need to reference something from a published book. Most often such references are Informative, and that's usually considered OK so long as there is a stable reference to the material (such as a URL, or an ISBN, or a DOI). For Normative references the issue is more complex because the implication is that the reference must be read in order to understand and implement the RFC. That, of course, is a problem for an open access organisation like the IETF (you could look at https://open-stand.org/ for an overview of the principles that underlie this). In general (and I think your draft is an example of this) it is possible to describe/rewrite the pieces of normative text without infringing copyright. That usually reduces the reference to Informative and provides enough information in the RFC for implementation. Your draft is an example of this because you have described the algorithms in your text with enough detail to allow an implementation: the reference is really only there to provide context and proof of the algorithms. (And anyway, having found a freely accessible copy of the reference in your draft, we are probably home and dry.) Cheers, Adrian -----Original Message----- From: Satya Mohanty (satyamoh) <satyamoh@cisco.com> Sent: 07 December 2018 17:12 To: Adrian Farrel <adrian@olddog.co.uk>; rtg-dir@ietf.org Cc: draft-ietf-bess-evpn-df-election-framework.all@ietf.org; ietf@ietf.org; bess@ietf.org Subject: Re: Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06 Hi Adrian, Thank you very much for your detailed review and comments. We will take care of all the nits that you have pointed out and include the reference to the IEEE/ACM TON paper (the link you have pointed out is indeed correct). However, I had one query. Most of the time research journal/conference papers will be behind a paywall and there may not be a free cached copy available online. How do we get across this problem? Best, --Satya On 12/7/18, 7:20 AM, "Adrian Farrel" <adrian@olddog.co.uk> wrote: Reviewer: Adrian Farrel Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-bess-evpn-df-election-framework-06.txt Reviewer: Adrian Farrel Review Date: 2018-12-07 IETF LC End Date: 2018-12-18 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document addresses issues in the default election algorithm used for Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by defining a new election algorithm and a capability to influence the election result for a VLAN, depending on the state of the associated Attachment Circuit. This is an exceptionally clear and well written document. The authors and the working group are to be congratulated. During my review I observed a number of small issues and editorial nits. I don't believe any of these is cause for discussion in the working group, but it would be sensible to resolve them before publication. Thanks and Happy Christmas, Adrian -- It's Christmas. Buy someone you love a book of fairy tales. https://www.feedaread.com/profiles/8604/ Available from your favourite online bookseller. Or contact me to receive a signed copy by mail. === Major Issues: No major issues found === Minor Issues: HRW1999 is provided as a normative reference, and from the text I can see why. But no URL (stable or otherwise) is given for the reference. Using my favorite search engine, I looked for and found a copy of the referenced document on the IEEE site behind a paywall. I don't think that will do at all. However, there is a version at https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf That appears to be dated 1998, but otherwise could be the same paper. --- When I read in Section 3... In addition, since the specification in EVPN [RFC7432] does leave several questions open as to the precise final state machine behavior of the DF election, section 3.1 describes precisely the intended behavior. ... I wondered whether this document is updating 7432 in that respect. Other features later in the document (such as section 5) confirm this. --- Notwithstanding the mention of backward compatiblity in section 6, I think it would be a good idea to include a very short section 3.2.1. 3.2.1. Backward Compatibility Legacy implementations (i.e., those that predate this specification) will not advertise the DF Election Extended Community. That means that all other participating PEs will not receive DF preferences and will revert to the defailt algorithm without AC-Influenced DF Election. Similarly, a legacy implementation receiving a DF Election Extended Community will ignore it and will continue to use the default algorithm. --- On first reading, I missed an important subtlty in 3.2. The paragraph... - Otherwise if even a single advertisement for the type-4 route is not received with the locally configured DF Alg and capability, the default DF Election algorithm (modulus) algorithm MUST be used as in [RFC7432]. ...is really important because it handles what to do if different participating PEs disagree about which algorithm to use. Your text is perfectly fine and adequate, but the "locally configured" sort of hid it from me first time around. Maybe add a sentence to the end of the bullet point to say... "This procedure handles the case where participating PEs disagree about the DF algorithm and capability to apply." --- Section 4 introduces 8124 for the first time. It's good that this is applicable to private wire EVPN as well as 7432 EVPN. Maybe bring this into focus in the Introducion? It does make me wonder whether you are also updating 8124. --- I think section 7 is good. Since you note that the "unfair" situation may be created maliciously, should you note that there is also scope for a downgrade attach where the advertisement from one PE is hidden, the preferred algorithm is modified to any unexpected value, or any unexpected bit in the capabilities bitfield is set? I think such an attack assumes either a subversion of the PE (perhaps via its configuration) or modification of the BGP message. Thus, it is not a probable if adequate existing security mechanisms are used. === Nits: The RFC Editor will require that the first section in the document is the Introduction. --- You use VNI and I-SID without expansion. --- 2.1 s/proposes/defines/ --- 2.3 s/procedure Generally,/procedure. Generally,/ --- 3.2 has For the DF election procedures to be consistent and unanimous, it is necessary that all the participating PEs agree on the DF Election algorithm and capabilities to be used. This is exactly the type of statement I was hoping for when I opened the document, so thanks. But... :-) This depends slightly on the definition of "all participating PEs". You don't need all PEs in the EVPN to use the same algorithm, only the PEs that share multi-homing connections. You also use the term in 2.1 and other places in the document, so perhaps I am worrying too much. --- 4. s/the state of the server states/the server states./ s/on Unix utilities rand and srand/on the Unix utilities rand and srand/ --- I am not sure why you describe Wrand2 in section 4.2 because you immediately decide to not use it. Maybe you can just describe Wrand and observe that does the job? --- 4.2 s/HRW solves the disadvantage/HRW solves the disadvantages/
- [bess] Referencing material behind a paywall Adrian Farrel
- Re: [bess] Referencing material behind a paywall Heather Flanagan
- Re: [bess] Referencing material behind a paywall Carsten Bormann
- Re: [bess] Referencing material behind a paywall Stephen Farrell
- Re: [bess] Referencing material behind a paywall Satya Mohanty (satyamoh)