On December 5, 2017 at 9:25:39 AM, [email protected] ( [email protected]) wrote:
> > [...] > > > M8. References > > > M8.1. TUNNEL-ENCAP (aka ) should be > Normative, which btw is marked to Obsolete rfc5512; I mention this > because both are listed in several parts, so you should take > rfc5512 out. > > > This was debated on a while ago, and this is somehow the conclusion of > the discussion: > > https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w > > Copy-paste: > ---- > We'll also add idr-tunnel-encaps a Informative reference. With respect > to Tunnel Encap Extended Community (which is the only part of > idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft > itself references RFC 5512. > > During the course of WG LC and RFC editorship of evpn-overlay draft, if > we see that idr-tunnel-encap is progressing fast, then we can drop the > reference to RFC 5512 and make the reference to idr-tunnel-encap > Normative. Otherwise, we'll keep both references with RFC 5512 as > Normative and idr-tunnel-encap as Informative. > ---- > > The question probably is whether or not idr-tunnel-encap progress is > sufficient. > If anything, both references should at least be of the same type: I can see no reasoning why one would be Normative and the other Informative. In this case, idr-tunnel-encap already went through WGLC (according to the datatracker) — we can’t ignore the fact that idr has consensus on deprecating rfc5512. Again, we don’t need both references. > > > > > M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, > RFC4023 > > > My process fu is weakening, but if this specification is standard track > (and I believe it should be), I believe it can't normatively depend on > Informative specs and some of the above are in this category. > It can if we call the Down References out in the IETF Last Call and no one opposes. I think we already processed at least one document with a DownRef toVXLAN, so I don’t think that’s a problem. In any case, the type of Reference should be decided based on the real dependency of the document, not on its status. Thanks! Alvaro.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
