At Tue, 18 Apr 2017 15:15:37 +0100, Fernando Gont <[email protected]> wrote:
> > You will probably save everyone a lot of energy if you just admit > > you had missed it, and moved on. > > Huh? > > I obviously missed it. But this should still be in RFC2460 (or > rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding > for IPv6 packets. > > Having important requirements spread into a number of documents where > they don't belong doesn't help, and in the long run takes more energy > (and creates more problems) than spending the energy in doing what is right. I see your point, but this is not the only case where a description in RFC4443 could also be in RFC2460 but isn't. Destination unreachable code 2 (Beyond scope of source address) is also related to forwarding, but it's not documented in RFC2460. Code 4 (Port unreachable) is a matter of upper layer consideration, but it's not documented in Section 8 of RFC2460. I'm sure there are more. In the ideal world we could make all these points perfect: everything is documented everywhere consistently with minimal redundancy or scattering but still avoiding to push everything in a single monster document. Obviously it's an impossible goal in the real world, and we should accept some level of redundancy or scattering (or even inconsistency as a matter of fact). In this particular case I personally think it's acceptable: the ICMPv6 specification is so fundamental, so I'd say it's reasonable to say that any serious implementer should read it carefully. There should always be someone who overlooks some particular point (like you missed this specific one), but that doesn't necessarily mean we should update the documentation so that that particular person would not have missed it. There would still be someone who miss it no matter redundantly we describe it. In that sense, I tend to agree with Ole. (But I wouldn't be opposed to making this in rfc2460bis either if that's the wg consensus, although at this moment no one else seems to think this is an issue to be fixed). -- JINMEI, Tatuya _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
