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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf