> Thanks a lot for the comments. I don't see myself ever requesting a > new extension header and I would use Options instead, but since someone > has the option to request one, we need to tighten up the spec.
Actually, I disagree with your conclusion. Just because something isn't explicitely disallowed, doesn't mean we need to clarify anything (unless there was a real, actual, problem). That is an endless (and possibly pointless) task. First, let's be pragmatic. If there is no real problem to fix here, can we please spend our cycles on problems where we might actually make a difference in the real world? > I would be just as happy if a new document or RFC2460bis (if any) > would explicitly state that no new extension headers would be added Why should we rule that out? Besides, such a proclamation would be useless, since we could easily overrule it if we ever came up with a justification for defining a new extension header. > or even strongly cautions against using extension headers. Why? If someone later comes up with a problem, and extension headers (despite any drawbacks w.r.t. deployed code) seem like the best answer, we can have a conversation about the pros and cons then. > The way I see it, RFC2460 mentions that we can use either extension > headers or options, but without mentioning the issues with adding > new extension headers. Again, no standard is 100% complete and covers every imaginable scenario. You yourself admit that you don't have a real need for an extension to point to. If there is no real, compelling problem to solve, can we please just drop the discussion and move on to something with some actual importance? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
