I feel, but haven't received opinions from Bernhard or Bela, that there is a lot of text required for security reasons. So I would like to consider writing a new draft and introduce the bit in that draft. We can keep this draft experimental. Comments?
We can say its a protocol specification for the use-case documented in draft-haindl-lisp-gb-atn. Dino > On Apr 28, 2022, at 9:07 AM, Alvaro Retana <[email protected]> wrote: > > > [WG participant hat on.] > > Dino: > > Hi! > > I agree that the behavior could be implementation-specific: just configure > both > sides. > > It would be valuable to document it. If it is an optional implementation > configuration and there are no bits involved, the specification could even go > in the current draft: > > An implementation MAY consider more specifics...more details... > The xTRs and Map-Servers in the network MUST be explicitly configured > if this optional functionality is used. > > This is an example of a possible deployment: [describe a case > where a single message would be used -- doesn't have to be specific > to ICAO's application]. > > > A couple of paragraphs should do it. ;-) > > > My 2c, > > Alvaro. > > On April 26, 2022 at 5:32:52 PM, Dino Farinacci ([email protected]) wrote: > >> > Interesting, there might be use-cases for that. Maybe that is something we >> > can work as an extension of the base PubSub, once the base spec is done? >> >> So from the discussion with the ICAO guys (Bela and Bernhard), they want a >> "more-specific" type processing of both Subscribe-Requests and >> Map-Registers. For example: >> >> (1) subcribe 10.1.1.1/32, 10.1.1.2/32, then unsubscribe for 10.1.1.0/24 >> which unscribes all the more-specifics to 10.1.1.0. >> >> (2) Map-Register 10.1.1.1/32, 10.1.1.2/32, then deregister for 10.1.1.0/24 >> which unscribes all the more-specifics to 10.1.1.0. >> >> We don't spec this out in either the pubsub or 6833bis and an implementation >> could do this with no new flag bits required, but if we wanted to standarize >> this a Map-Register and Map-Request would need a >> "process-all-more-specifics" flag bit. >> >> And, the aggregate that "undoes" all the more-specifics would have to use >> the same authentication key and signature used for all the specific >> registered. >> >> We are still discussing this privately. We took the discussion off the list, >> but I wanted to update everyone on the status of the discussion. >> >> Any comments? >> >> It is of my opinion, that this is a moderate protocol change but they need >> it so they can send one message rather than possibly more than one message >> with a list of specifics. And I am not sure we should update specs for this >> since an implementation can be configured on both the xTR side and the >> map-server side to do this functionality. >> >> Comments about documenting this? >> >> Dino >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
