All, I’ve just update the shepherd write-up updating the IANA section according to Alvar’s review. I’ve also stated that this document will update RFC8060, which seems to me that is what we have converged on.
The next revision of the document, which should include Éric‘s comments, must include an explicit statement about updating 8060. (But this can be done after the IESG telechat so to include also any further comment). Ciao L. Sent from my iPad > On 14 Apr 2022, at 22:00, Dino Farinacci <[email protected]> wrote: > > >> >> 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
