Re: [bess] Referencing material behind a paywall
Thank you Stephen, Carsten and Heather for your input. Jorge will be publishing the revised version soon. Best Regards, --Satya On 12/10/18, 2:14 PM, "Stephen Farrell" wrote: On 10/12/2018 20:41, Heather Flanagan wrote: > Ekr offered an interesting proposal that would have this kind of > reference be treated in a fashion similar to IPR declarations. Not a bad idea. I'd also make it like the downref registry [1] though, since once we've got a normative reference in one RFC to e.g. some IEEE 802 thing, then it shouldn't need new process to have a 2nd RFC do the same. Cheers, S. [1] https://datatracker.ietf.org/doc/downref/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Referencing material behind a paywall
On 10/12/2018 20:41, Heather Flanagan wrote: > Ekr offered an interesting proposal that would have this kind of > reference be treated in a fashion similar to IPR declarations. Not a bad idea. I'd also make it like the downref registry [1] though, since once we've got a normative reference in one RFC to e.g. some IEEE 802 thing, then it shouldn't need new process to have a 2nd RFC do the same. Cheers, S. [1] https://datatracker.ietf.org/doc/downref/ 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Referencing material behind a paywall
On Dec 10, 2018, at 21:41, Heather Flanagan wrote: > > similar to IPR declarations For those people who believe in “IPR”, copyrights (which is the mechanism used to protect specifications that are behind paywalls) are “IPR". So this is very logical, even if the impact of this kind of IPR on large-scale vendors is much more limited than the kinds of “IPR” we usually talk about in the IETF (i.e., patent claims). The impact on people who need to configure, diagnose, research, or otherwise assess the technology is still very relevant. Grüße, Carsten ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Referencing material behind a paywall
On 12/7/18 9:20 PM, Adrian Farrel wrote: 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 Hello all, In general, I think having an open standard normatively reference paywalled material is a terrible idea. That said, at the IESG meeting in Bangkok, we discussed this a bit. Ekr offered an interesting proposal that would have this kind of reference be treated in a fashion similar to IPR declarations. I am waiting to see a more concrete proposal along these lines--and discuss it with the other streams to see if it can apply to all--before I put anything in a future style guide. -Heather -Original Message- From: Satya Mohanty (satyamoh) Sent: 07 December 2018 17:12 To: Adrian Farrel ; rtg-...@ietf.org Cc: draft-ietf-bess-evpn-df-election-framework@ietf.org; i...@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" 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 m
[bess] Referencing material behind a paywall
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) Sent: 07 December 2018 17:12 To: Adrian Farrel ; rtg-...@ietf.org Cc: draft-ietf-bess-evpn-df-election-framework@ietf.org; i...@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" 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...
