bert hubert writes: > 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.
This is definitely a problem. Even though Akamai had previously agreed to specify under what IETF-acceptable terms the IPR would be made available, it clearly hasn't yet specified them. I've contacted them to get a timeline on when the legal department can take care of this, and the first order response is that the DNS team is trying to get the ball rolling again with legal this week. > 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. As previously noted in this very thread, at least one of the authors, Puneet, agrees with you. When I wrote the text that way it was because of the also not-unreasonable viewpoint that if someone were to be implementing the example then the text could be considered normative as to how to do that. It's even softened by having no MUSTs at all, just SHOULD. In addition, I'm dubious as to the claim that people would cause meaningful pain to demand compliance with an example, and not be adequately refuted when it is pointed out to them that it is a clearly marked as an example. That said, since I had waffled on it myself at time of composition and I don't actually have a very strong feeling about it, in the end wouldn't fight over downcasing it. Yet I think it should be settled at a level above dnsop because ultimately it's an issue that should be consistent across IETF documentation. Unless there's already an explicitly stated IETF policy about this, and not just ad hoc past cases to point to, I think it is best to sort out with the RFC editor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop