Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-06

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-intarea-nat-r

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

At 03:59 PM 4/5/2013, Dave Cridland wrote: Actually, getting rich without implementing anything seems to happen quite often enough these days - it's called acquisition. or be a Kardashian On Fri, Apr 5, 2013 at 6:12 PM, Wes Beebee (wbeebee) <wbee...@cisco.com> wrot

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

Actually, getting rich without implementing anything seems to happen quite often enough these days - it's called acquisition. On Fri, Apr 5, 2013 at 6:12 PM, Wes Beebee (wbeebee) wrote: > Or use the FTL to predict the company stock price so that you get rich > without > implementing anything. >

draft-sheffer-running-code-03 published

Hi, we have just published a new revision of this draft, defining a new, optional Implementation Status section to be included in Internet Drafts: http://tools.ietf.org/html/draft-sheffer-running-code-03 We believe this document is almost ready for IETF last call; in fact this idea has alrea

Re: (Former) IETF Chair Interview

http://www.youtube.com/watch?v=CH65RbOSrZ8 On Apr 5, 2013, at 2:14 PM, Russ Housley wrote: > This was recorded in January 2013, when I was the IETF Chair. It was not > released until March 20th, when I was no longer IETF Chair > > It is 15 minutes. It is not aimed at a technical crowd. > >

(Former) IETF Chair Interview

This was recorded in January 2013, when I was the IETF Chair. It was not released until March 20th, when I was no longer IETF Chair It is 15 minutes. It is not aimed at a technical crowd. Russ

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On 4/5/2013 6:58 AM, Michael Richardson wrote: "Loa" == Loa Andersson writes: thinking about this and assuming that the FTL Communication are deployed Loa in a not too far distant future, wouldn't we have started to receive Loapackets that was sent in the future already now? > I for one, hav

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

Or use the FTL to predict the company stock price so that you get rich without implementing anything. - Wes On 4/5/13 5:12 AM, "Adrian Farrel" wrote: >So instead of asking the community "do you have an intention to implement >and >deploy?" we should ask "have you already been going to have impl

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

Loa, On Apr 5, 2013, at 1:47 AM, Loa Andersson wrote: > Bob, > > thinking about this and assuming that the FTL Communication are deployed > in a not too far distant future, wouldn't we have started to receive > packets that was sent in the future already now? See Section 5. It may be already

Re: [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard

On Thu, Apr 4, 2013 at 12:36 PM, Benjamin Kaduk wrote: > In combination with Tom's proposed changes, this table should work well. I agree. > Agreed that some text about what qop 0 means is needed. I yes. Indeed, maybe we should even remove the qop column and state that we always use qop 0 unle

Re: [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard

Hi Tom, Nico, On Thu, 4 Apr 2013, Haynes, Tom wrote: On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk wrote: [snip. Single-DES is weak and deprecated] Hi Ben, Thanks for pointing this out - the last work on Kerberos for this bis was done before RFC 6649 was published. It did look like the

Re: [secdir] [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard

On Wed, Apr 3, 2013 at 4:07 PM, Nico Williams wrote: > Oh, well, this is just outdated text. And indeed, the GSS-API's > notion of "qop" (quality of protection) is broken: it's used in the > wrong place (per-msg token functions). The GSS qop brokenness is why > this text persists. > > OLD: ... >

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On Apr 5, 2013, at 10:29 AM, Spencer Dawkins wrote: > There are days when I'm really glad to be part of this community ... Yes, but the question is, is this such a day? :)

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On 4/5/2013 9:09 AM, Steve Crocker wrote: I too have always found at least one of the Crocker brothers {suspicious, smart, funny, irrelevant, prescient, handsome, annoying, etc.}. I've never been able to tell which is which :) There are days when I'm really glad to be part of this community .

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

--On Friday, April 05, 2013 10:03 +0100 Dave Cridland wrote: >... > Indeed, and this tells us that publication of this was > important, since we'll need to be in a position to handle the > issues that will occur much sooner than deployment, and for > that matter development of the technology. >

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

I too have always found at least one of the Crocker brothers {suspicious, smart, funny, irrelevant, prescient, handsome, annoying, etc.}. I've never been able to tell which is which :) Sent from my iPad On Apr 5, 2013, at 9:58 PM, Michael Richardson wrote: > >> "Loa" == Loa Andersson wr

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

> "Loa" == Loa Andersson writes: Loa> thinking about this and assuming that the FTL Communication are deployed Loa> in a not too far distant future, wouldn't we have started to receive Loa> packets that was sent in the future already now? I for one, have always found these Crock

Re: Less Corporate Diversity

>>The point is that *if* we had more diversity along many of the discussed >>lines, we'd be far better off. For instance, having people from multiple >>organisations provide input to a last would be preferable to just a few. >>Similarly with the other dimensions of diversity. When I talked to so

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On 2013-04-05 11:11, Brian E Carpenter wrote: On 05/04/2013 10:03, Dave Cridland wrote: On 5 Apr 2013 09:47, "Loa Andersson" wrote: Bob, thinking about this and assuming that the FTL Communication are deployed in a not too far distant future, wouldn't we have started to receive packets that

RE: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

So instead of asking the community "do you have an intention to implement and deploy?" we should ask "have you already been going to have implemented and deployed yet?" >> thinking about this and assuming that the FTL Communication are >> deployed in a not too far distant future, wouldn't we have

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On 05/04/2013 10:03, Dave Cridland wrote: > On 5 Apr 2013 09:47, "Loa Andersson" wrote: >> Bob, >> >> thinking about this and assuming that the FTL Communication are deployed >> in a not too far distant future, wouldn't we have started to receive >> packets that was sent in the future already now?

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

On 5 Apr 2013 09:47, "Loa Andersson" wrote: > > Bob, > > thinking about this and assuming that the FTL Communication are deployed > in a not too far distant future, wouldn't we have started to receive > packets that was sent in the future already now? > Indeed, and this tells us that publication

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

Bob, thinking about this and assuming that the FTL Communication are deployed in a not too far distant future, wouldn't we have started to receive packets that was sent in the future already now? /Loa On 2013-04-02 18:19, Bob Hinden wrote: AB, On Apr 1, 2013, at 5:45 PM, Abdussalam Baryun

CALL FOR CANDIDATES FOR ITOJUN SERVICE AWARD

Dear IETFers, The Itojun Service Award is presented every year to an individual or a group who has made outstanding contributions in service to the IPv6 community. The deadline for nominations for this year's award is 12 July 2013. The award will be presented at the 88th meeting of the IETF to