On Mon, 2010-04-05 at 08:43 -0700, todd glassey wrote: > > >> Obviously you could make the expiration interval long, but however > >> long you make it will be as long as the worst-case config-change time, > >> in case the Subscription server failed/restarted in-between. So that > >> same time is also how long the polling interval could/would be if the > >> UA just checked the HTTP server instead. > > > > You assume that the configuration server looses subscription state on a > > restart... that would be a pretty shabby implementation, especially > > given that one would expect the subscription times to be very long (if I > > were going to make a suggestion, it would be at least a week). > > NOTHING can be "assumed about an IETF Standard which does not have an > accompanying use model or BCP" for its use, so this is in fact relevant > and appropriate. I'm not sure what you're suggesting here... > >>> If the UA is behind a NAT... > >>> [snipped text] > >> > >> Of course - I only mentioned the NAT issue because some folks had > >> talked about the subscription going to a config-server directly > >> without going through edge proxies. > > > > Again, that would be very poor design on the part of the provider, and > > is entirely within the providers control since they are setting the URL > > value and all the DNS records that control routing for the domain in > > that URL. > > But since you have not restricted them from doing this really stupid > thing you cannot assume they wont. In either of the above cases, the party who is making poor design or implementation choices is the party that suffers. In neither case does the Internet suffer any appreciable damage, since the mandated retry backoff prevents undo traffic. I suppose that the document could specify that subscription state must be preserved across restarts, or could specify that anyone deploying a configuration service must ensure that the configured routing is such that NAT keepalive traffic is the same as that needed for other purposes. The former seems pretty obvious to me, but I guess I would not object to it; the latter is a constraint on deployments that we can't test in an implementation anyway, so I don't quite see the point. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf