On 4/5/2010 9:04 AM, Scott Lawrence wrote: > 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... OK, I am saying that because the IETF allows any level of implementation of any of its protocols it has nothing to say about how much of any protocol or practice is implemented... unless there is a BCP saying that this is the minimum acceptable implementation for the use of the IETF's license. > >>>>> 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. | No its the victims they take down with them who suffer... Todd 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. > > >
begin:vcard fn:Todd Glassey n:Glassey;Todd email;internet:TGlassey@xxxxxxxxxxxxx x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf