Summary on wildcard requests. Please correct me if I misunderstood what has been expressed. Nobody supports (2) and (4). It rests:
1. only keep (legacy) wildcard requests, and reply with a full dump. 3. Send a non-specific wildcard request for non-specific routes, a source-specific wildcard request for source-specific routes, a tos-specific wildcard request for tos-specific routes, a source-and-tos-specific wildcard request for source-and-tos-specific routes, etc. Send all this kind of requests for a full dump. Juliusz prefers (3) because (1) is less conservative than (3) in the sense that a legacy Babel speaker may receive unsolicited routes. David prefers (3). Toke prefers (1), because (3) increases implementation complexity while not solving anything (no use case). I prefer (1), mainly because (3) is a pain to define. An extension (like the TOS one) will have to consider all previous extensions to consider the possible combinations, which I consider confusing. I'm not so afraid by the implementation complexity induced by (3), because an implementation can send an update at any time. It results that an implementation MAY send a full dump regardless the request received. In other terms, a receiver may implement (1) even if (3) is standardized. On the requester side, a wildcard request is statically defined, so from an implementation point of view it's not worth it. Thoughts ? Matthieu _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users