Hello all, I don't think we can infer from RFC 8200 that something is mandated and something is strongly suggested. If guys with different interests can infer from an "Internet Standard" what they are interested, the standard is ambiguous and deserves a bis.
If the standard is clear, we MUST obey it, especially for the result after intensive debates, do we need to repeat the discussion again? Best Regards, Zhenqiang Li ________________________________ li_zhenqi...@hotmail.com From: Fernando Gont<mailto:fg...@si6networks.com> Date: 2019-09-05 09:23 To: Ron Bonica<mailto:rbonica=40juniper....@dmarc.ietf.org>; Ole Troan<mailto:otr...@employees.org>; Fernando Gont<mailto:ferna...@gont.com.ar> CC: draft-voyer-6man-extension-header-insertion<mailto:draft-voyer-6man-extension-header-insert...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; Suresh Krishnan<mailto:suresh.krish...@gmail.com>; spring@ietf.org<mailto:spring@ietf.org>; draft-ietf-spring-srv6-network-programming<mailto:draft-ietf-spring-srv6-network-programm...@ietf.org> Subject: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function) On 4/9/19 21:27, Ron Bonica wrote: > Ole, > > Yes, a deep breath and some introspection are always a good thing. > > First, I think that we need to make a distinction between the "spirit" and > "letter" of the law. Next, we need to make a statement regarding good > engineering practice. > > RFC 8200 mandates some things. For example, In an IPv6 header, the source > address must precede the destination address. Any attempt to reverse those > two would violate the letter of the law. > > By contrast, RFC 8200 strongly suggests other things. For example, transit > nodes should not insert or delete extension headers. I don't think it "suggests" this. It clearly forbids it. > In general, these suggestions should be heeded. But exemptions can be > granted, on a case-by-case basis, An exception about this would be a major change regarding what IPv6 is and its operation. > For better or worse, RFC 8200 does not use RFC 2119 language. So it is > difficult to distinguish between the spirit and letter of the law. I think you can talk about spirit when there's room for interpretation, or the text is not clear. I don't think there's any of that in RFC8200 regarding EH insertion being forbidden. In fact, we added the text we added to make it clear that it was forbidden. > Beyond that, we need to make a statement regarding good engineering practice. I would like to contribute one: if one is to get into publishing specs, new specs should comply with the specs they depend on (i.e. the normative references). That means: 1) Don't violate other specs, or, 2) If you strongly feel like it, you first update the target spec, so that you behave nicely (you eventually comply with it). > If a technology violates the spirit of RFC 8200 once, with good reason, that > is fine. I tend to differ here. If a technology is violating an aspect of a spec on which we spend a long time and energy, that's not fine. If we (IETF) do it, that would seem to be an indication of issues in the standardization process -- we publishing specs that not even us comply with doesn't seem to look nice. Doing this kind of major surgery (EH insertion) after elevating IPv6 to "Internet Standard" would bring another set of uncomfortable questions. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
