On Thu, Mar 21, 2019 at 12:59 AM Jeffrey Haas <jh...@pfrc.org> wrote:
> Authors, > > Some various comments on the draft in no particular order: > - Consider using the document ASes from the reserved ranges; i.e. RFC 5398 > - Construct a unified table of the "results" and a short term for their > meaning. One of my least favorite thing in RFCs that tend to be placed > into code is calling something a "type X". It leads to rather confusing > conversations unless you're a protocol expert. > > Case in point -- one of my "favorite" RFCs -- RFC7281 - Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) Basically, we realized that arguing whether users should publish TLSA records of type 3, selector 1, matching 1, or 3, 0, 1 or ... is super-unhelpful, but recommending DANE-TA, SPKI, SHA2-256 is much simpler. W > A final comment is another infrequent case a provider's AS may end up in > the > AS-Path: Intentionally forcing that provider to discard a route *you* own. > > Consider the case where AS 64512 owns 192.0.2/24. AS 64512 is under a > heavy > DDoS attack that is substantially originated from AS 65535. By prepending > 65535 to the AS-Path upon origination, 65535 will lose the route to > 192.0.2/24 and, if default-free, much of the attack traffic goes away. > > -- Jeff > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
