Hi, I stick to my answer to Christer, we should update 8060 ;-)
Ciao L. > On 14 Apr 2022, at 13:39, Alvaro Retana <[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> > > > 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). > > (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…what does the WG want to do? reopen rfc6833bis, nothing, or use > lisp-vendor-lcaf > > [FWIW, my personal preference (as WG participant) is to use lisp-vendor-lcaf.] > > Thanks! > > Alvaro. > > On April 13, 2022 at 3:02:28 PM, Dino Farinacci ([email protected] > <mailto:[email protected]>) wrote: > >>> Just confirm, the behavior is not specified in rfc8060, right? It seems to >>> me that it would be good to specify it somewhere and >>> draft-ietf-lisp-vendor-lcaf looks as good a place as any - do you agree? >> >> I search as well and it wasn't obviously stated. But 6833bis has this text: >> >> <PastedGraphic-7.png> >> >> Which doesn't make clear if the LCAF AFI is supported but the LCAF type is >> NOT supported, the LCAF type should be dropped. >> >> Should we add this to rfc6833bis? >> >> The suggested text would be: >> >> . . . LISP control-plane messages that include an unrecognized AFI or >> LCAF-Type MUST be dropped . . . >> >> Dino
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
