Re: Scheduling unpleasantness

Harald, Even a simpler solution. If you (meaning Iljitsch) had serious conflicts, then let the WG chairs know about these conficts. They may may not on the WG Chairs' radars. That has happened to me, where WG members were overlapping with groups that I was unaware of. John On Mon, Mar 24, 200

Re: [Ltru] Possible RFC 3683 PR-action

Russ Housley skrev: > I cannot find one. It seem to be a hole than needs filled. Solution space: At the time when I was assistant chair of the ICANN DNSO General Assembly, we had this exact problem with the many identities of "Jeff Williams"; he had enough pseudo-personalities on the list that

Re: Scheduling unpleasantness

Diving into solutions space The WG scheduling tool has 3 lists of "groups to avoid conflicts with", 1st, 2nd and 3rd priority. I don't know if these are visible to anyone but the requesting WG Chair, but they're listed on the confirmation notice from the tool; I've made it a practice to co

Re: Write an RFC Was: experiments in the ietf week

On 25 mar 2008, at 02.18, Hallam-Baker, Phillip wrote: > I am willing to have a go at it next time round but only if I have > some idea what I am expected to have on my machine and what > authentication indicata I am to expect. > > As it stands there is no way for me to evaluate an authentic

Re: amusing text from recently-published US Military standards

Charles Clancy wrote: > Text from MIL-STD-188-220D, published March 2008: > > Something tells me they haven't updated this boilerplate since the > 1980s. I'm surprised there weren't any references to GOPHER. > The use of WAIS dates it's origin to the 1991-1993 era... _

Re: Objection to Last Call - draft-ietf-eai-utf8headers-09.txt

Charles Lindsey wrote: > none of the MUAs available to me allow manual tinkering with > References (and, worse, the ietf archives don't show Message-ID > headers at all) >From my POV was still okay apart from my unnecessary (1) and (2) confusion, same as

RE: Write an RFC Was: experiments in the ietf week

I am willing to have a go at it next time round but only if I have some idea what I am expected to have on my machine and what authentication indicata I am to expect. As it stands there is no way for me to evaluate an authentic or inauthentic experience. I don't know what authentic looks like.

RE: Write an RFC Was: experiments in the ietf week

Well I would submit that there is a major problem there on the security usability front. Don't make me think. My tolerance for network configuration is vastly greater than the typical user. This has to all just work, just like my Apple Mac did on the home network the day I bought it. Not like

amusing text from recently-published US Military standards

Text from MIL-STD-188-220D, published March 2008: "Request for comments (RFCs) are available from Network Information Center, 14200 Park Meadow Drive, Suite 200, Chantilly, VA 22021. The Network Information Center (NIC) can be reached, by phone, Monday through Friday, 7 AM through 7 PM, Eastern

Re: Scheduling unpleasantness

> On 3/24/08, Brian Dickson <[EMAIL PROTECTED]> wrote: > > Eric Gray wrote: > > > > > This sort of scheduling problem is very well known > > > to be NP hard and trying to meet the scheduling conflict > > > matrix for 1500 to 2500 people would make the "N" large. > > > > > > > Universitie

RE: Possible RFC 3683 PR-action

On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema wrote a message which included: >using pseudonyms is a form of free speech I am not familiar with the specifics of this case but in the internet world pseudonyms is very common. I agree that in a standard setting body hiding identitie

RE: Scheduling unpleasantness

Brian, See below... :-) -- Eric Gray Principal Engineer Ericsson > -Original Message- > From: Brian Dickson [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 6:16 PM > To: Eric Gray > Cc: Iljitsch van Beijnum; IETF Discussion > Subject: Re: Scheduling unpleasantness >

Re: Last Call: draft-klensin-rfc2821bis

Ned Freed wrote: > If the consensus is that better interoperability can be had > by banning bare records that's perfectly fine with me. FWIW, I'd like that... >> Clarity can be established and interoperability _improved_ >> by limiting discovery to just A and MX records. Perhaps a >> note

Re: Last Call: draft-klensin-rfc2821bis

FWIW, my opinion is that if you want to accept incoming mail via IPv6, you need to advertise one or more MX records that point to ipv6-capable hosts. Treating A records (in the absence of MX records) as "implicit MX" records was a hack needed to avoid forcing everyone to advertise an MX record

Re: Scheduling unpleasantness

On 3/24/08, Brian Dickson <[EMAIL PROTECTED]> wrote: > Eric Gray wrote: > > > This sort of scheduling problem is very well known > > to be NP hard and trying to meet the scheduling conflict > > matrix for 1500 to 2500 people would make the "N" large. > > > > > Universities have been doing

Re: Scheduling unpleasantness

Eric Gray wrote: > Iljitsch, > > I'm not sure that I would say that Philadelphia was > worse than most meetings, but it may have been from your > perspective. > > Iljitsch is far from alone, just the earliest and most vocal of us. :-) > This sort of scheduling problem is very well

Re: Last Call: draft-klensin-rfc2821bis

> On Mar 24, 2008, at 11:42 AM, Ned Freed wrote: > >> John C Klensin <[EMAIL PROTECTED]> wrote: > >>> --On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis > >>> <[EMAIL PROTECTED]> wrote: > >>> > The "update" of RFC2821 is making a _significant_ architectural > change to SMTP by expli

Re: [Ltru] Possible RFC 3683 PR-action

Cher Russ, The debate about me is depressing. Only signatories to the PR-action against JFC Morfin are interested. They are not very credible. Their doctrine is globalization: internationalization of the medium (Unicode), localization of the terminal (CLDR) and identification of linguistic context

Re: Last Call: draft-klensin-rfc2821bis

On Mar 24, 2008, at 11:42 AM, Ned Freed wrote: >> John C Klensin <[EMAIL PROTECTED]> wrote: >>> --On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis >>> <[EMAIL PROTECTED]> wrote: >>> The "update" of RFC2821 is making a _significant_ architectural change to SMTP by explicitly statin

IETF Last Call for two IPR WG Dcouments

During the Wednesday Plenary at IETF 71, I gave the IETF community a "heads up" on two documents from the IPR WG that were nearing IETF Last Call. Both of the documents have now reached IETF Last call. The Last Call announcements are attached. Please review and comment. Russ == == == == ==

Re: Last Call: draft-klensin-rfc2821bis

John Leslie wrote: > Whether or not we have any consensus that this historical > practice should be deprecated (I would vote YES!), +1 > rfc2821-bis is not, IMHO, the right place to deprecate it. It could be seen as an unintended chance to keep out of this business, because RFC 2821 forgot

Re: Write an RFC Was: experiments in the ietf week

Phillip: Have you tried the SSID at the IETF meetings that is configured to make use of 802.1x? Russ At 01:49 PM 3/24/2008, Hallam-Baker, Phillip wrote: Secure WiFi Connection I would like to see some demonstration of the fact that the default WiFi configuration on all existing platforms provide

Re: Last Call: draft-klensin-rfc2821bis

> John C Klensin <[EMAIL PROTECTED]> wrote: > > --On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis > > <[EMAIL PROTECTED]> wrote: > > > >> The "update" of RFC2821 is making a _significant_ > >> architectural change to SMTP by explicitly stating > >> records are within a list of SMTP server

Re: Last Call: draft-klensin-rfc2821bis

John C Klensin <[EMAIL PROTECTED]> wrote: > --On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis > <[EMAIL PROTECTED]> wrote: > >> The "update" of RFC2821 is making a _significant_ >> architectural change to SMTP by explicitly stating >> records are within a list of SMTP server discovery re

RE: [HOKEY] EMSK Issue

Charles, > -Original Message- > From: Charles Clancy [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 23, 2008 7:18 PM > To: Narayanan, Vidya > Cc: Glen Zorn; ietf@ietf.org; [EMAIL PROTECTED]; Bernard Aboba > Subject: Re: [HOKEY] EMSK Issue > > Vidya, > > > ... do the responsible thing,

Re: Write an RFC Was: experiments in the ietf week

Phillip, > write an Internet Draft prior to the experiment, > +1 > *IPv6 Next Steps* > > The Philadelphia IPv6 outage tested one specific aspect of the > transition - is there an IPv6 network on the other side to connect to > in due course, is it possible to run a pure IPv6 network? > > I think

TLS vs. IPsec (Was: Re: experiments in the ietf week)

Phillip, Iljitsch, > If you beleive that there is an attack that SSL is vulnerable to you > should bring it up in TLS. I think Iljitsch meant that TLS cannot protect against TCP vulnerabilities, such as spoofed connection resets. This is obviously well known. The upside of TLS has of course bee

Write an RFC Was: experiments in the ietf week

Enough, already. If we are going to have experiments in IETF week then lets do the thing right and have a process. In particular - Proposer MUST write an Internet Draft prior to the experiment stating: 1) Purpose - the information to be obtained 2) Method - what it to be done 3) Resources - wha

Re: Scheduling unpleasantness

Iljitsch, Tell me about it... I had more than one WGs of my own meeting at the same time (6MAN and MEXT), triple booked on slots like the Tuesday morning slot where we had MEXT, V6OPS, and RRG at the same time, etc. INT has for years generally met (at least!) twice on every slot, and the ADs typic

RE: experiments in the ietf week

These claims are meaningless to me. Transport and network layer security have distinct objectives and purposes. They are not replacements or interchangeable in any sense. If you beleive that there is an attack that SSL is vulnerable to you should bring it up in TLS. In general the higher

Re: experiments in the ietf week

On 24 Mar 2008, at 11:18 , Marc Manthey wrote: > hello ipv6 peoples, sorry for crossposting > > how can i use ipv6 from my machine ? > > using leopard 10.5.2. mail ? > > my endpoint is 2001:6f8:1051:0:20d:93ff:fe79:f1e > > thought its automatic :-P I think you just need to make sure that the se

RE: [Ltru] Possible RFC 3683 PR-action

The closest I could find was: "Working groups SHOULD ensure that their associated mailing list is manageable. For example, some may try to circumvent the revocation of their posting rights by changing email addresses; accordingly it should be possible to restrict the new email address." from

RE: Scheduling unpleasantness

Iljitsch, I'm not sure that I would say that Philadelphia was worse than most meetings, but it may have been from your perspective. This sort of scheduling problem is very well known to be NP hard and trying to meet the scheduling conflict matrix for 1500 to 2500 people would mak

Re: Scheduling unpleasantness

one has to schedule unpleasentness, since there is so much of it. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ IETF mailing list IETF@iet

RE: [Ltru] Possible RFC 3683 PR-action

I cannot find one. It seem to be a hole than needs filled. Russ At 11:45 AM 3/23/2008, Christian Huitema wrote: >Does the IETF have a policy regarding misrepresented identities? > >In the particular incident, it is assumed that the person using the >name of a famous French aviation pioneer is

Re: experiments in the ietf week

> >> Umm... At this time, most IETF mailing lists are hosted on >> mail.ietf.org a.k.a. www.ietf.org, which is IPv6 enabled. >> (The numbers I have for active WGs are that 90 out of 120 lists >> are hosted on ietf.org). I can't really reconcile that with >> your statement above. Could you expand

Scheduling unpleasantness

Finally back at the office today... While it is a fact of life that sessions clash at IETF meetings, I must say that Philadelphia has been especially bad in this regard. Does anyone else have the same experience? If it wasn't just me, I think it's time to look at the scheduling algorithm in

Re: experiments in the ietf week

On 16 mrt 2008, at 21:42, Henrik Levkowetz wrote: > ... Nearly all IETF mailinglists are still hosted on IPv4-only >> servers, to name just one issue. > Umm... At this time, most IETF mailing lists are hosted on > mail.ietf.org a.k.a. www.ietf.org, which is IPv6 enabled. > (The numbers I have fo

Re: experiments in the ietf week

On 19 mrt 2008, at 1:46, Eric Rescorla wrote: >> A more interesting experiment would be to do away with SSL for a bit >> and use IPsec instead. > Why would this be either interesting or desirable? SSL is vulnerable to more attacks than IPsec and IPsec is more general than SSL. As such it would

Re: Gen-ART LC review of draft-ietf-eai-utf8headers-09.txt

I sigh in my own general direction ;-) 1.2. Relation to other standards This document also updates [RFC2822] and MIME, and the fact that an experimental specification updates a standards-track spec means that people who participate in the experiment have to consider

Re: Objection to Last Call - draft-ietf-eai-utf8headers-09.txt

On Wed, 19 Mar 2008 09:32:42 +0100 Frank Ellerman said: >Apologies, I confused (1) and (2): [...] >> 1 - The use of a "nested" CTE B64 if all else fails to send >> DSNs to an EAI sender with a 7bit bit hop on the route. >> 2 - The use of UTF-8 in MIME version 1.0 part headers, this >>

RE: [HOKEY] EMSK Issue

> For example, consider using a USRK to secure HTTP. If your access > provider did this to deliver firmware updates to your handset, this > might be reasonable, but if amazon.com required it for authentication, > this would be unreasonable. I do not believe that either application is reasonable.

Re: Gen-ART LC review of draft-ietf-eai-utf8headers-09.txt

Spencer Dawkins skrev: > Hi, Harald, > > Thanks for the quick feedback (Gen-ART reviewers like this because we > can remember writing the review, and at least part of what we were > thinking about :-) > > Looks like mostly goodness. If we're in synch, I dropped it from this > e-mail. > > Spencer

Re: Possible RFC 3683 PR-action

On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema <[EMAIL PROTECTED]> wrote a message of 12 lines which said: > Does the IETF have a policy regarding misrepresented identities? I don't know but, in this case, the problem is not that he used a pseudonym (after all, noone here knows if

Re: Gen-ART LC review of draft-ietf-eai-utf8headers-09.txt

Spencer Dawkins wrote: > I'm amazed that the downref isn't being called out in the > Last Call announcement I wonder if you confused "downref" with the opposite case for EAI, the drafts modify more mature RFCs, in essence 2822 and arguably MIME, that's an "upref", not a "downref". If John *woul

Re: [Ltru] Possible RFC 3683 PR-action

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] Randy Presuhn wrote: > However, the vocabulary, style, content, and peculiar world-view of > this latest missive leave me more convinced than ever that "LB" > is indeed JFC Morphin, and that under the terms of RF