> Hi! > > Hmm — let’s start with the positive. The new text looks good to me. > > OTOH, even if rfc6833bis is the base specification, rfc8060 is an optional > extension…. The problem is one of references and document status: > > rfc8060 is an Experimental document — the current reference in rfc6833bis is > Informative, which is ok because there’s just a general reference to the AFI > — “LCAF-Type MUST” makes the relationship to rfc8060 Normative and changes > the behavior of rfc8060 implementations, so we should change the reference > type and formally update rfc8060, which results in a downref, which requires > community approval (new IETF LC), which requires the IESG to consider the > downref registry, . . . > > I don’t think any of us wants to reopen rfc6833bis at this point. <sigh>
Okay. > Ideally, rfc8060 would have included that one extra sentence: “an > unrecognized LCAF-Type MUST be dropped”. > > We have two other options: > > (1) Let it be. rfc8060 is Experimental, people “experimenting” with it can > figure it out, and when/if the document goes on the Standards Track we can > add the text. I know there are production deployments, but these are mostly > controlled (people shouldn’t see unknown types). Right and true. > (2) Use lisp-vendor-lcaf, which adds a new Type, to formally update rfc8060 > on what needs to be done if an unknown Type is received. Both documents are > Experimental and lisp-vendor-lcaf is in line to be approved next week by the > IESG, so there are no cumbersome process issues. So add the sentence to lisp-vendor-lcaf since we still have time. This is fine with me. > So…what does the WG want to do? reopen rfc6833bis, nothing, or use > lisp-vendor-lcaf I vote for lisp-vendor-lcaf. > [FWIW, my personal preference (as WG participant) is to use lisp-vendor-lcaf.] Well that's two people in sync. ;-) Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
