The problem is operators using this advice as if it were BCP - and later docs treating the suggestions as recommended advice. This treats everything unknown as an attack (a disease I’ve noted in many similar docs for years), where it should also consider that doing so is *itself* an attack on the very flexibility we design in as standard. We really need to do a better job of not letting informational docs get out of hand this way. Joe > On Nov 24, 2018, at 12:21 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > >> On 2018-11-25 06:04, Joe Touch wrote: >> Equally worrisome that this doc appears to make recommendations that imply BCP, when it is merely informational. >> >> IMO, it’s overstepping to do so. > > Possibly, but it's not forbidden by rule, as far as I know. However, the > draft is inconsistent in its use of SHOULD vs should (see my previous > message for an example of a lower case should which might or might not > be intended pseudo-normatively). > > Brian >> >> Joe >> >>> On Nov 23, 2018, at 11:53 AM, Michael Scharf <michael.scharf@xxxxxxxxxxxxxxx> wrote: >>> >>> Reviewer: Michael Scharf >>> Review result: Ready >>> >>> This document has been reviewed as part of the transport area review team's >>> ongoing effort to review key IETF documents. These comments were written >>> primarily for the transport area directors, but are copied to the document's >>> authors and WG to allow them to address any issues raised and also to the IETF >>> discussion list for information. >>> >>> When done at the time of IETF Last Call, the authors should consider this >>> review as part of the last-call comments they receive. Please >>> always CC tsv-art@xxxxxxxx if you reply to or forward this review. >>> >>> I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent >>> transport issues. The proposed filtering could slow down the deployment of >>> experimental protocols that use IPv6 options, but the tradeoffs are explained >>> in the document. >>> >>> Thanks >>> >>> Michael >>> >> >> >
