On Sun, Mar 24, 2019 at 04:36:50AM -0700, Paul Vixie wrote: > i object to serve-stale as proposed. my objection is fundamental and goes to > the semantics. no editorial change would resolve the problem.
I too object. This is partially due to the apparently unresolved IPR issue from Akamai, who are known not to be shy asserting their IPR. https://datatracker.ietf.org/ipr/3014/ notes an Akamai IPR claim and does not yet provide a license suitable for use on an open internet. https://patents.google.com/patent/US8583801B2/en & https://en.wikipedia.org/wiki/Akamai_Techs.,_Inc._v._Limelight_Networks,_Inc. have some context. The mechanics are that once something is an RFC, operators require adherance to it. This in turn is a boon for the IPR holder, and hurts everyone else. My secondary objection is that the draft contains an example implementation that then however uses normative words. This leads to pain with operators demanding serve-stale compliance. Example algorithms should clearly be examples and not tell us what we SHOULD do. Bert _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
