Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

Please see inline From: Pete Resnick [mailto:presn...@qti.qualcomm.com] Sent: Wednesday, September 7, 2016 8:53 PM To: Suresh Krishnan Cc: IESG ; General Area Review Team ; draft-ietf-tram-turn-mobility@ietf.org; t...@ietf.org Subject: Re: GenART post-telechat comment on draft-ietf-tram-turn-

Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

Stephen, As per my reply to Suresh: It is often the case that the gratuitous use of "MUST"s hides ambiguities in meaning that need to be fixed anyway. And for the sake of keeping things the same as they were when I was on the IESG, I say to you, with great affection: :-b pr On 7 Sep 2016,

Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

[Trimming down a bit] On 6 Sep 2016, at 22:57, Suresh Krishnan wrote: OLD: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766] NEW: If a

Re: [Gen-art] Telechat Review of draft-ietf-httpauth-extension-08

Hello Oiwasan, Thank you for your response, and look forward to reading the next revision. As for that uncompleted thought; my apologies, it should not have been included! When I had started that thought, I had not yet finished all of section 5. I think, for an experiment, the interaction of we

Re: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

> On Sep 6, 2016, at 11:34 PM 9/6/16, Tirumaleswar Reddy (tireddy) > wrote: > > Hi Ralph, > > Please see inline [TR] > > From: Ralph Droms [mailto:rdroms.i...@gmail.com > ] > Sent: Thursday, September 1, 2016 4:36 PM > To: Jari Arkko mailto:jari.ar...@piuha.net>

Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

Hi Pete, On 06/09/16 16:55, Pete Resnick wrote: > However, I believe Suresh was incorrect in suggesting the first "MUST", > and it should be removed. There is no harm being prevented here. "If a > client wants X, it MUST send Y" is absolutely no different protocol-wise > from "If a client wants X