Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

2007-05-21 Thread Brian E Carpenter
Section 8 states Applications MUST not set contradictory flags at the same time. I think the document should specify what the API must do if contradictory flags are set. That would be the normative MUST, not the above statement of the obvious. Brian ___

Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

2007-05-21 Thread Jari Arkko
Brian, > Section 8 states > >>Applications MUST not set contradictory flags at the same time. > > I think the document should specify what the API must do if > contradictory flags are set. That would be the normative MUST, not > the above statement of the obvious. Thanks for your review, Bria

Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

2007-05-21 Thread Brian E Carpenter
On 2007-05-21 12:47, Jari Arkko wrote: Brian, Section 8 states Applications MUST not set contradictory flags at the same time. I think the document should specify what the API must do if contradictory flags are set. That would be the normative MUST, not the above statement of the obvious.

Gen-art review of draft-ietf-sip-e2m-sec-05.txt

2007-05-21 Thread Elwyn Davies
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Apologies for the late arri

IETF Meeting Host and Sponsor Program

2007-05-21 Thread Ray Pelletier
All; There are three opportunities each year to be a Host and Sponsor of an IETF meeting in venues throughout the world. The IETF calendar with the regions targeted for the meetings can be found at: http://www3.ietf.org/meetings/0mtg-sites.txt. The Host may even suggest a particular city f

Meeting Calendar 2011 - 2013 #2

2007-05-21 Thread Ray Pelletier
All; Based upon feedback received an adjustment was made in March of 2013. Please advise if any further modification to the proposed IETF Meeting schedule below is desired. Thanks Ray Pelletier IAD 2011 16IETF 80Mar 27 - Apr 1 17IETF 81Jul 24 - 29 18IETF 82No

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

2007-05-21 Thread Robert Sayre
On 5/19/07, Tim Bray <[EMAIL PROTECTED]> wrote: Well Rob, I think the community at large and the IESG in particular would welcome suggestions on what to do with this one. Sorry Tim, can't agree with that assertion. At least some people seem to be content with handwaving, if the current Atompub

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

2007-05-21 Thread Jeffrey Hutzelman
On Sunday, May 20, 2007 01:41:29 PM -0700 Eric Rescorla <[EMAIL PROTECTED]> wrote: I agree that these specs should explicitly specify which TLS version to support. As a practical matter, this is either 1.0 or 1.1, since 1.2 is not yet finished. Unfortunately, which one to require isn't reall

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

2007-05-21 Thread Philip Guenther
On Mon, 21 May 2007, Jeffrey Hutzelman wrote: ... It seems to me that specs should _not_ explicitly specify which TLS version to support, and should instead refer to an STD number. Applications don't generally specify which verisons of IP or TCP to use, and TLS is at a similar level of abstrac