Re: Optimizing for what? Was Re: IETF Attendance by continent

[Clint Chaplin]

On Tue, Aug 31, 2010 at 9:15 PM, Randall Gellens  wrote:
> At 10:08 AM +0700 9/1/10, Glen Zorn wrote:
>
>>  > > Why Kauai?  You list detailed reasons why Hawaii is logical and
>>>
>>>  > solves for many of the problems, but you don't say why this island.
>>>
>>>  Because it's the nicest, obviously. :)
>>
>>  I strongly disagree: the leeward coast of Maui (in particular, Kihei &
>>  south) is far better.  Kauai is way too rainy...
>
> However, any of the Hawaiian
> islands would be a great choice, given the ease of travel arrangements, the
> warm weather which reduces the need for much of the luggage (no need for
> warm clothes),

IEEE 802 wireless interim meetings in September have been at the
Waikoloa Resort for the last few years.  The meeting rooms are so
heavily air condituoned that the attendees now know to bring a sweater
to the meeting.


>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -- Randomly selected tag: ---
> Anything labeled "NEW" and/or "IMPROVED" isn't.  The label means the
> price went up.  The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW"
> means the price went way up.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Attendance by continent

[Yoav Nir]

On Aug 31, 2010, at 4:56 PM, Iljitsch van Beijnum wrote:

>> Consider that contributors
>> usually start as newcomers, attend several meetings, then write a draft,
> 
> I don't know about you, but I wrote drafts before my first meeting.

Me too. I actually had an RFC published two months before attending my first 
meeting.

As an employee (rather than an independent consultant) if I ask my bosses to go 
to an IETF meeting, their first question is what am I going to do there.  A 
good answer is that I want to present this draft in that working group, 
participate in this discussion at another working group, and meet this person 
to talk about that subject.

If I just said I want to go to some meetings, and listen to stuff, and see if I 
hear anything interesting, they'd tell me to use the audio stream for that.

OTOH we've all seen a whole bunch of people at meetings who always sit in the 
back, faces buried in their laptops, and never participating in any discussion. 
 I'm not sure what value their employer gets from their participation, but I 
guess both models exist.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Optimizing for what? Was Re: IETF Attendance by continent

[Randall Gellens]

At 10:08 AM +0700 9/1/10, Glen Zorn wrote:


  > > Why Kauai?  You list detailed reasons why Hawaii is logical and

 > solves for many of the problems, but you don't say why this island.

 Because it's the nicest, obviously. :)


 I strongly disagree: the leeward coast of Maui (in particular, Kihei &
 south) is far better.  Kauai is way too rainy...


On this point I am in agreement with Glen.  However, any of the 
Hawaiian islands would be a great choice, given the ease of travel 
arrangements, the warm weather which reduces the need for much of the 
luggage (no need for warm clothes), and the general difficulty of 
being disagreeable in such an environment.  Many of the conference 
facilities are open-air, with roofs and protection from rain but 
still providing ample fresh air and natural light.


--
Randall Gellens
Opinions are personal;facts are suspect;I speak for myself only
-- Randomly selected tag: ---
Anything labeled "NEW" and/or "IMPROVED" isn't.  The label means the
price went up.  The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW"
means the price went way up.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Optimizing for what? Was Re: IETF Attendance by continent

[Glen Zorn]

Hadriel Kaplan [mailto://hkap...@acmepacket.com] writes:

...

> >
> > Why Kauai?  You list detailed reasons why Hawaii is logical and
> > solves for many of the problems, but you don't say why this island.
> 
> Because it's the nicest, obviously. :)

I strongly disagree: the leeward coast of Maui (in particular, Kihei &
south) is far better.  Kauai is way too rainy...

> 
> 
> >
> >>   We can even rotate islands if people get bored.
> >
> > Well, there are extensive conference facilities on Oahu, the Big
> > Island, Maui, and Kauai.  I have no information as to if they would
> > work for a group of our size and with our need for breakout rooms.
> 
> I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu)
> every few years, but they were a smaller group.  There aren't many
> restaurants nearby, but I certainly don't remember anyone ever
> complaining about it. ;)

3GPP2 used to (still does?) meet in Wailea every December.  Although that is
also a much smaller group than the IETF, the hotels dwarfed it so it might
be possible to find a reasonable venue for the IETF.  However, I think that
this is just an idle fantasy: the IETF has too much moral fiber to meet
someplace that might actually be fun ;-).

> 
> -hadriel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC

[Mark Andrews]

In message , Phil
lip Hallam-Baker writes:
> Whether or not the IAB zone is signed is of negligible consequence.
> 
> But the fact that the IAB zone signatures had expired is a highly
> significant data point: DNSSEC administration is not quite as easy as
> some of the glib claims of its more enthusiastic supporters would lead
> one to believe.

It's more a matter of choosing the right tools.  I've got signed
zones that haven't been hand signed in 3 years using a 2 month
signature validity interval.  The nameserver just re-signs the
records as they fall due.  That's several thousand automatic updates
of the zones in that period.  Yes, I've changed the non DNSSEC
content of the zones in that time.

This isn't a protocol issue.  It's a tools issue and DNSSEC tools
from all vendors are improving.

It's also extremely easy to construct tools that can warn you to
re-sign if you are doing it by hand.  You could replace awk with
perl and have a cross platform tool.  Such tools can easily be
added to network management platforms as they are just small
scripts.  If you don't have a network managment platform use
cron.

e.g.

% dig axfr dv.isc.org @bsdi.dv.isc.org | awk '$4 == "RRSIG" && $9 < WARN { 
print }' WARN=`date -u -v +7d +%Y%m%d%H%M%S`
%

% dig axfr dv.isc.org @bsdi.dv.isc.org | awk '$4 == "RRSIG" && $9 < WARN { 
print }' WARN=`date -u -v +1m +%Y%m%d%H%M%S`
bind9-test-8.dv.isc.org. 86400  IN  RRSIG   NSEC 5 4 86400 20100929190221 
20100731184853 14436 dv.isc.org. 
2jHCGeJqH23dO0RV48Uqqp2hXIl1wp3kIslqmdz686uaCNz3WZZUhKzX 
EH+8iKc6QQWMZhFzhJoqruiTO6RyIA==
BRNEE8E63.dv.isc.org.   1800IN  RRSIG   A 5 4 1800 20100929190221 
20100731184853 14436 dv.isc.org. 
ZhD6uAbGQYDWJ6rob9iyvRNWZ7Tod1as4WEtPV8C+mLF8aJbakwp/76/ 
f7r7jz/fQOtIMQ/NjXBRT7O4507gIA==
BRNEE8E63.dv.isc.org.   1800IN  RRSIG   TXT 5 4 1800 20100929190221 
20100731184853 14436 dv.isc.org. 
Xl3nk8lf2exwGGy2iI2BxVjXO3emvI+8GRmkj+vi7n8rddmP6oJRqPGZ 
wmNoZVxMN9XMTghly6w6Cmj8aNAILQ==
BRNEE8E63.dv.isc.org.   86400   IN  RRSIG   NSEC 5 4 86400 20100929190221 
20100731184853 14436 dv.isc.org. 
JUR1M8GmlFFYF73v6oh+bdwYuKK0YBMe7b4mDsMBs1bdBqHB52KUZ8eS 
KNCRD3GTp8VzwxB1TGmuIq+dGr57lQ==
% 

With a minor change it will print out just the zone.

% dig axfr dv.isc.org @bsdi.dv.isc.org | awk '$4 == "RRSIG" && $9 < WARN { 
print "WARNING:", $12, "needs re-signing" ; exit }' WARN=`date -u -v +1m 
+%Y%m%d%H%M%S`
WARNING: dv.isc.org. needs re-signing
% 

Wrap it is a while loop and you can do all your zones.  The getline
is so we don't generate error messages in the nameserver logs by
causing the axfr to be aborted.

#!/bin/sh -f
WARN=`date -u -v +7d +%Y%m%d%H%M%S`
while read zone server
do
dig axfr "$zone" "@$server" | \
awk '$4 == "RRSIG" && $9 < WARN 
{ print "WARNING:", $12, "needs re-signing."; while (getline) ; }' \
WARN=$WARN
done

Mark

> On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS)  wrote:
> > Community -
> >
> > The DNS zone files have been re-signed, and we will look into alternative=
> s to
> > the original DNSSEC tools that were in use (which seem to be broken.)
> >
> > And just a reminder that, while posting complaints to this list might feel
> > more therapeutic, the secretariat has an address set up for trouble repor=
> ts,
> > which is ietf-act...@ietf.org . =A0Sending complaints to that address will
> > generally get much faster results.
> >
> > Thank you!
> >
> > Glen
> > Glen Barney
> > IT Director
> > AMS (IETF Secretariat)
> >
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> >
> 
> 
> 
> -- =
> 
> Website: http://hallambaker.com/
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-saintandre-tls-server-id-check

[=JeffH]

fwiw, I concur with Peter's analysis and conclusions.

=JeffH
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Dave CROCKER]

On 8/31/2010 12:21 PM, Bob Braden wrote:


The history of the development of email protocols is contained in the RFC
series. Those interested might for example look at RFCs 196, 458, 524, 772, and
788.



One of the myths that these early RFCs dispel is that email was a casual 
addition to FTP.  I got involved in time for the very last FTP meeting, so I 
wasn't privy to any of the email discussions.  I had heard a rumor that email 
got added as a result of a Saturday night's casual suggestion of an MIT grad 
student who happened to be passing by Abhay Bhushan's office -- he authored the 
FTP spec.  About 10 years ago he reassured me that the real story was nothing 
like that.  These RFCs bear that out.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Dave CROCKER]

On 8/31/2010 10:54 AM, Noel Chiappa wrote:

 >  From: Fernando Gont
 >email
 >  was a couple of FTP commands?

That was more back in the NCP days (prior to TCP/IP). SMTP came in about the
time TCP/IP was really starting to roll (don't recall the exact timing, but
it would have been circa 1980 or so).



SMTP was defined in 1982.  So was the DNS.  It took both some years to gain 
production levels of use of each.  The Internet's TCP/IP had code start running 
in 1976 and went into production operation in 1983.


Hence there was a period of time during which the Internet relied on the 
original FTP-based mail commands.  SMTP's primary enhancement was support for 
multiple addressees per transaction.  By and large, this improvement was 
invisible to email users.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Fwd: IPR Disclosure: CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11

[Phillip Hallam-Baker]

Dear Msr DE FURST

I note your filing of an IPR claim against the HTTP Digest
Authentication method described in RFC 4768 and RFC 2069.

I note further that the claim is made in respect of a patent
application made in 2008 whereas RFC 2069 was published in 1997 and
the original proposal on which it was based was published by myself on
the www-talk mailing list in 1993.

In what imaginable universe could you possibly conceive that a patent
application made in 2008 would establish a proprietary claim over
prior art published as an international standard fifteen years prior?

The purpose of an IPR filing is to declare an interest in an existing
specification. It is not for soliciting interest in the addition of
features to support a subsequent invention.

Further, I believe that if your clients were to fully consider their
proposed realization that it is in any case anticipated in United
States Patent Application   20050021982, to which an offer of
Royalty-Free Reasonable and Non-Discriminatory licensing for
implementation in RFC 4226 is already on file:

https://datatracker.ietf.org/ipr/1104/


I am Sir, yours etc,

Phillip Hallam-Baker

-- Forwarded message --
From: IETF Secretariat 
Date: Tue, Aug 31, 2010 at 11:14 AM
Subject: IPR Disclosure: CNRS's Statement about IPR related to RFC
4768, RFC 2069, RFC 4169, and draft-ietf-httpbis-p7-auth-11
To: j...@math.nwu.edu, j...@spyglass.com, ph...@hallambaker.com
Cc: alexey.melni...@isode.com, stpe...@stpeter.im,
ipr-annou...@ietf.org, hous...@vigilsec.com


Dear John Franks, Jeffery Hostetler, Phillip Hallam-Baker:

An IPR disclosure that pertains to your RFC entitled "An Extension to HTTP:
Digest Access Authentication" (RFC2069) was submitted to the IETF Secretariat on
2010-08-31 and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/1398/). The title of the IPR
disclosure is "CNRS's Statement about IPR related to RFC 4768, RFC 2069, RFC
4169, and draft-ietf-httpbis-p7-auth-11."

The IETF Secretariat





-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[John C Klensin]

--On Monday, August 30, 2010 21:57 +0200 Olaf Kolkman
 wrote:

> The recent remark on bias against individuals[*] made me think
> about weighing the location preference by number of
> participants from certain regions.
> 
> Suppose an individual from Asia attends all IETFs then her
> costs are that for attending 6 IETFs she gets to travel 1x
> regional and 5x interregional. 
> 
> While an individual from the US travels 3x regional and 3x
> interregional. Clearly there is a bias agains our Asian
> colleague in with respect of the costs.
> 
> Using participation/contribution numbers to weigh locations
> minimizes the global costs (total amount of miles flown,
> carbon spend, lost hours by the collective, total amount of
> whining) but nothing of that flows back to the individual
> engineer that attends every time.
> 
> If you want to be fair to the individual participants you have
> to optimize in such a way that attending 6 meetings costs the
> same for every individual that regularly attends the IETF.
> Obviously one can only approximate that by putting fairly
> large error bars on the costs but isn't the X-Y-Z distribution
> where X= approx Y= approx Z  the closest optimum? (or finding
> one place that sucks equally for everybody)
> 
> Am I missing something? 

Well,...

Speaking as one of those independent consultants who, in the
last eight years or so has attended every IETF meeting and paid
all of my own costs to all but one of them (I had a registration
fee waived once), and who was previously sometimes in the
approval loop for corporate permission/sponsorship by others...

If you want to go very far down the path you outline, you have
to ask some questions that we have never asked and to which
you/we may not want to know the answers.  Examples:

* Are there differences in different regions as to the
ratio between those who are really participating as
individuals and those who have corporate sponsorship?

* If a corporation typically sends a lot of people to
IETF but has overall cost constraints such that some
choices of location might reduce the total number of
people they sent, would that really reduce overall IETF
effectiveness?  Put differently, if such a corporation
cut participation by Go-ers and various other forms of
tourists and damage-preventers, leaving only those who
actively contribute to the IETF's work, would that
result in a worse or slower IETF product?

* Coming back to another optimization discussion, would
you want to adjust the weightings to favor those who are
actively participating in a variety of IETF efforts over
those who come to participate in one or two WGs and
otherwise have spare time?

* Remember that, for some people and some companies, the
perceived costs of having someone with real design or
product responsibility away from his or her desk may
completely dominate any travel or registration costs.
For other situations, that is definitely not the case.

If one really wants to look at costs in depth, I would also
point out that the Beijing meeting has a de facto minimum
registration fee (registration + minimum visa fee) for US
citizens of $775 and one for most others of $110 less.  Because
of differences in visa policies in other countries, meetings in
other locations may impose differentials disfavoring other
groups.

And all of that is in addition to points made by others
including that distance is not a very good surrogate for overall
costs (or even airfares), that some of these optimizations may
pessimize overall attendance or attendance by active
participants, etc.

So, while I might personally benefit from the sort of revision
in formula you suggest, I have significant doubts that you can
really make those measurements and that optimization correctly
(for some sensible value of "correct").  Unless "we" can figure
out how to control overall costs and the cost-efficiency ratio
for just about everyone, I know I'm going to need to stop
attending meetings face to face for which I don't have (or seek)
sponsorship.  That is just how it is; I'd much rather see the
focus on controlling overall costs to everyone, examining
locations and meeting schedules for their consequences on time
away from home (which translates into lost billable hours for
some of us and irritated families for some others), whether a
meeting in a particular location requires making a tradeoff
between staying in an inconvenient place and staying in an
expensive luxury hotel, and so on.

john


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[Donald Eastlake]

On Tue, Aug 31, 2010 at 12:06 PM, Hadriel Kaplan  wrote:
>
> On Aug 30, 2010, at 6:21 PM, Randall Gellens wrote:
>>
>> Why Kauai?  You list detailed reasons why Hawaii is logical and
>> solves for many of the problems, but you don't say why this island.
>
> Because it's the nicest, obviously. :)

See http://www.pothole.com/~dee3/kauai.html

Donald

>>>   We can even rotate islands if people get bored.
>>
>> Well, there are extensive conference facilities on Oahu, the Big
>> Island, Maui, and Kauai.  I have no information as to if they would
>> work for a group of our size and with our need for breakout rooms.
>
> I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu) every 
> few years, but they were a smaller group.  There aren't many restaurants 
> nearby, but I certainly don't remember anyone ever complaining about it. ;)
>
> -hadriel
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

NAT behavior for IP ID field

[John Kristoff]

I'm trying to locate an RFC that spells out the behavioral
requirements, expectations or guidelines for NAT handling of the IP ID
field, particularly for UDP messages.  Section 3.2.5 in RFC 3235
briefly mentions issues surrounding IP fragmentation and reassembly,
but  it doesn't specifically say if NATs should re-write IDs as a
general rule.

RFC 4787 doesn't seem to address this either.

If this is not written down anywhere, do NATs generally rewrite the ID
field with or without the MF bit set?

For background and reference, I refer you to Steve Bellovin's 'A
Technique for Counting NATted Hosts', particularly section IV.

Thanks for any pointers,

John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[John C Klensin]

--On Tuesday, August 31, 2010 13:54 -0400 Noel Chiappa
 wrote:

> > From: Fernando Gont 
> 
> > As far as I recall *reading* (I wasn't around at the
> time :-) ) email > was a couple of FTP commands? 
> 
> That was more back in the NCP days (prior to TCP/IP). SMTP
> came in about the time TCP/IP was really starting to roll
> (don't recall the exact timing, but it would have been circa
> 1980 or so).

Yes.

But, regardless of whether one counts from FTP-based email or
from SMTP, the statement that email was the only application is
simply nonsense.  Telnet was alive and well, FTP was heavily
used (and I trust it is obvious that we could have had FTP-based
email without FTP), user and system information protocols like
finger and whois were around and in use, and so were a bunch of
things that are "applications" or not depending on one's
definitions and a fairly large collection of applications (not
just applications-support protocols) built directly on TCP (or
NCP, or later on various socket layers) whose descriptions never
made it into the RFC series.

 john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Bob Braden]

The history of the development of email protocols is contained in the 
RFC series.  Those interested might for example look at RFCs 196, 458, 
524, 772, and 788.


Bob Braden

On 8/31/2010 10:54 AM, Noel Chiappa wrote:

 >  From: Fernando Gont

 >  As far as I recall *reading* (I wasn't around at the time :-) ) email
 >  was a couple of FTP commands?

That was more back in the NCP days (prior to TCP/IP). SMTP came in about the
time TCP/IP was really starting to roll (don't recall the exact timing, but
it would have been circa 1980 or so).

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-saintandre-tls-server-id-check

[Peter Saint-Andre]

On 8/30/10 5:10 PM, Bernard Aboba wrote:
> Peter St. Andre said:
> 
> "an SRV record can be used for two quite different purposes:
> 
> 1. To point from an application service name to a particular
> host/domain name in the same administrative domain (e.g.,
> _imap._example.com points to mailhost.example.com for its IMAP
> service).
> 
> 2. To delegate an application service name to a hosting provider
> outside in the administrative domain of the application service
> (e.g., example.com delegates its IMAP service to
> apps.example.net).
> 
> As I see it, RFC 4985 glosses over the foregoing distinction."
> 
> [BA] It took some adjustment for me, but as I understand it, the
> underlying assumption of RFC 4985 is that if the certificate is
> considered valid by RFC 5280 path validation (e.g. chains to a valid
> trust anchor, etc.) then delegations both within and outside the
> source administrative domain can be validated. This logic, if
> pursued, could apply beyond SRV RR validation, to things like NAPTR
> validation via a URI/IRI in the certificate.

If that's the logic, I'd at the least like to see a "4985bis" spec make
that clear, because IMHO it's not spelled out now.

> Scoping (EKUs, name constraints, etc.) is a different question.

Agreed.

> Peter also said:
> 
> "However, the question arises: what is the client supposed to check
> if an SRV lookup for _imap._example.com yields apps.example.net? My
> reading of RFC 4985 leads me to think that the certificate presented
> by apps.example.net is supposed to contain an SRV-ID of
> _imap.example.com, which means roughly "this certificate indicates
> that this provider is authorized to provide IMAP service for the
> example.com domain". (How the certification authority determines that
> the delegation is indeed authorized is outside the scope of this
> I-D.)
> 
> [BA] That's also my reading of RFC 4985, but I'll let others more
> knowledgeable (like the author) weigh in.

That would indeed be helpful.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Noel Chiappa]

> From: Fernando Gont 

> As far as I recall *reading* (I wasn't around at the time :-) ) email
> was a couple of FTP commands? 

That was more back in the NCP days (prior to TCP/IP). SMTP came in about the
time TCP/IP was really starting to roll (don't recall the exact timing, but
it would have been circa 1980 or so).

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Fernando Gont]

Phillip Hallam-Baker wrote:

> At the time email was a special case because it was the *only* application.

As far as I recall *reading* (I wasn't around at the time :-) ) email
was a couple of FTP commands? -- I seem to recall John Day writing about
this in his book..

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: secdir review of draft-ietf-simple-msrp-sessmatch

[Christer Holmberg]

Hi,

The purpose of this e-mail is to address the secdir comments given by Richard
Barnes and Ted Hardie. Due to summer vacations, standardization meetings
etc it took a while to put the e-mail together, and we appologise for that.

GENERAL
===

First, the draft does NOT propose any changes to the TLS authentication
procedures – that will be clarified. The changes are only related to the
procedure for matching an incoming MSRP message to an MSRP session that
has been negotiated using SDP – once any TLS authentication procedure has
already taken place.

So, in case of TLS and name based authentication, if an SBC/ALG modifies
the a=path MSRP URI, the TLS authentication WILL fail. That is the current
behavior, and sessmatch doesn’t change that.

We understand that this fact needs to be clearly indicated in the draft.

Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs
and SIP aware firewalls can be in the SIP signaling path without acting as
MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays
the SBC/ALG needs to act as MSRP B2BUA, as today.

Sessmatch aims to extend the usability of MSRP peer to peer communication to
scenarios where simple ALGs/SBCs are used, and at least in our experience
customer interest for standard MSRP has grown (from more or less zero)
dramatically due to sessmatch. And, OMA, which previously used a *non-standard*
version of MSRP (with no interoperability with standard MSRP), has also agreed
to switch to sessmatch (even if it required a number of changes in their
specifications).

Second, the intention of sessmatch is not to modify the MSRP URI matching rules,
but rather to not use MSRP URI matching for session matching.

Please also note that when we talk about SBCs/ALGs, we refer to entities that
normally do NOT have the capability to act as MSRP B2BUAs.

We will comment the individual comments based on the assumptions above.


Comments from Richard
=

>I have reviewed this document as part of the security directorate's ongoing
>effort to review all IETF documents being processed by the IESG. These
>comments were written primarily for the benefit of the security area directors.
>Document editors and WG chairs should treat these comments just like any other
>last call comments.
>
>This document changes the URI matching algorithm used in MSRP.  MSRP sessions
>are typically initiated using SDP bodies in SIP.  These SDP
>bodies contain MSRP URIs that the peers use to contact each other.
>When one peer receives a request to initiate a session, he verifies that the
>URI being requested is one that he initiated in SDP, thereby using the URI as a
>shared secret to authenticate that the originator of the session actually
>received the SDP body in question.
>
>According to the current SDP specification, this comparison is performed over
>the whole URI; this document restricts the comparison to the "session-id"
>component, omitting the host, port, and transport components.  The goal of the
>document is to facilitate a certain class of man-in-the-middle attack, namely
>to allow a signaling intermediary to insert a media intermediary.  The
>restriction on the URI comparison is needed in order for the media intermediary
>not to have to modify URIs in MSRP packets to reflect the modifications to URIs
>in SDP bodies performed to redirect traffic through the media intermediary.

When an MSRP UA receives an MSRP packet it performs msrp session matching in 
order
to verify that the msrp packet belongs to an existing SDP negotiated msrp 
session
at the UA. RFC4975 prescribes that URI matching should be used for session 
matching.
We argue that the namespace scoping of the session-id values that use of URI 
matching
brings is unnecessary. The 80-bit randomness of the session-id and the fact 
that it
was the UA itself that decided on the session-id value and can ensure that it is
unique within the UA makes the session-id sufficiently unique for session 
matching.
Sessmatch is not changing the MSRP URI matching algorithm, it is changing the 
session
matching algorithm not to use MSRP URI matching.

>I have a few significant reservations about this document:
>
>1) This extension makes it more difficult for MSRP entities to secure their
>communications against attackers in the signaling path.  The current model
>provides a basic integrity protection, in that signaling intermediaries cannot
>redirect traffic to an arbitrary third party; they must at least advise the
>third party about how to modify MSRP packets. The proposed modification would
>remove even this cost.

If we do not introduce the sessmatch change then the only alternative for MSRP
connections to be able to be set up when SBCs or SIP aware firewalls are in the
SIP signaling path is for these to introduce MSRP B2BUA support. This is 
probably
not feasible for most SBCs and SIP aware firewalls, and if it actually were
feasible then it would mean as big a security problem, or 

Tools logins -- Aaaargh!

[Worley, Dale R (Dale)]

There is probably a better place to complain about this, but...

There are various IETF "tools" web pages.  But I have a devil of a time using 
them because they do not identify themselves usefully when asking for a login.  
There are multiple login databases in the whole IETF tools suite, and 
experienced users know which database controls access to which tool.  But for 
us unwashed masses, there is no way to guess which web pages demand which 
password because they are named inconsistently.

Let me propose:

* Each password database has a *single* name which is the only name that it is 
ever referred to by, such as "IETF tools login" and "IETF datatracker login".

* Each login prompt gives the *single* name of the password database that it is 
driven by.

Otherwise we get such messes as "trac.tools.ietf.org" demanding an IETF tools 
login -- not IETF datatracker login -- and its login prompt identifying the 
realm only as "IETF".  Which is pretty useless to the uninitiated, since 
"track", "tools", and "IETF" are all present.

(I'm continuously amused by the fact that a roomful of computer geeks, who 
spend their days making unambiguous descriptions of operations to computers are 
unable to make an unambiguous description of an operation to humans.)

Dale
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[Hadriel Kaplan]

On Aug 30, 2010, at 6:21 PM, Randall Gellens wrote:
> 
> Why Kauai?  You list detailed reasons why Hawaii is logical and 
> solves for many of the problems, but you don't say why this island.

Because it's the nicest, obviously. :)


> 
>>   We can even rotate islands if people get bored.
> 
> Well, there are extensive conference facilities on Oahu, the Big 
> Island, Maui, and Kauai.  I have no information as to if they would 
> work for a group of our size and with our need for breakout rooms.

I used to attend IEEE 802 and they met in Kauai (Grand Hyatt in Poipu) every 
few years, but they were a smaller group.  There aren't many restaurants 
nearby, but I certainly don't remember anyone ever complaining about it. ;)

-hadriel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC

[Donald Eastlake]

Hi Phil,

On Tue, Aug 31, 2010 at 11:02 AM, Phillip Hallam-Baker  wrote:
> Whether or not the IAB zone is signed is of negligible consequence.
>
> But the fact that the IAB zone signatures had expired is a highly
> significant data point: DNSSEC administration is not quite as easy as
> some of the glib claims of its more enthusiastic supporters would lead
> one to believe.

Sounds like a straw man to me. Can you provide a pointer to some of
these glib claims?

For years I have been hearing, correctly I believe, that lack of
logistical and administrative tools and support for DNSSEC was the
main problem slowing deployment. Recent developments like RFC 5011
(Automated Updates of DNS Security (DNSSEC) Trust Anchors) have
improved things a lot. And, as an original architect of DNSSEC, I
admit that the early proposal set was deficient in this area.

Donald

> On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS)  wrote:
>> Community -
>>
>> The DNS zone files have been re-signed, and we will look into alternatives to
>> the original DNSSEC tools that were in use (which seem to be broken.)
>>
>> And just a reminder that, while posting complaints to this list might feel
>> more therapeutic, the secretariat has an address set up for trouble reports,
>> which is ietf-act...@ietf.org .  Sending complaints to that address will
>> generally get much faster results.
>>
>> Thank you!
>>
>> Glen
>> Glen Barney
>> IT Director
>> AMS (IETF Secretariat)
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC

[Phillip Hallam-Baker]

Whether or not the IAB zone is signed is of negligible consequence.

But the fact that the IAB zone signatures had expired is a highly
significant data point: DNSSEC administration is not quite as easy as
some of the glib claims of its more enthusiastic supporters would lead
one to believe.



On Tue, Aug 31, 2010 at 10:36 AM, Glen Barney (AMS)  wrote:
> Community -
>
> The DNS zone files have been re-signed, and we will look into alternatives to
> the original DNSSEC tools that were in use (which seem to be broken.)
>
> And just a reminder that, while posting complaints to this list might feel
> more therapeutic, the secretariat has an address set up for trouble reports,
> which is ietf-act...@ietf.org .  Sending complaints to that address will
> generally get much faster results.
>
> Thank you!
>
> Glen
> Glen Barney
> IT Director
> AMS (IETF Secretariat)
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is hard to get right

[Phillip Hallam-Baker]

DNSSEC is a PKI and running a PKI is never a trivial matter.

One of the reasons I have serious concern about the prospects for
deployment of DNSSEC is that the answer to many of my questions is
either a blank stare, an off the cuff answer clearly made up on the
spot or the claim that it is something for the market to decide on.

As things stand we have an excellent architecture for securing
distribution of DNS A and  records. We are thus confident of our
ability to transfer attacks from the DNS system where the effect of
attacks is pretty much localized to the BGP system whose fragility was
demonstrated only last Friday by RIPE. Is this really progress?


Out in Iraq, there is a water treatment plant that cost $110 million
to build. So far it has delivered absolutely no clean water to any
homes because nobody considered the need to build a pipe to connect
the water treatment plant to the city water mains.

There is a metaphor there if people want to see it.


On Tue, Aug 31, 2010 at 7:07 AM, Richard L. Barnes  wrote:
> Another view, for the visually inclined:
> 
>
>
> On Aug 31, 2010, at 2:41 AM, Stephane Bortzmeyer wrote:
>
>> % check-sig iab.org
>> Name iab.org has an expired signature (20100829223019)
>>
>> :-(
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is hard to get right

[Jiankang YAO]

I propose a lightweight DNSSEC.

http://www.ietf.org/id/draft-yao-dnsext-msig-00.txt

which may push the dnssec to be deployed easily.

:)


Jiankang Yao


- Original Message - 
From: "Stephane Bortzmeyer" 
To: 
Sent: Tuesday, August 31, 2010 2:41 PM
Subject: DNSSEC is hard to get right


>% check-sig iab.org
> Name iab.org has an expired signature (20100829223019)
> 
> :-(
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Attendance by continent

[Dave CROCKER]

On 8/30/2010 12:54 PM, Peter Saint-Andre wrote:

On 8/30/10 1:53 PM, Patrik Fältström wrote:

I was expecting something like:

pi:e:sqrt(-1)


Given the irrationality this topic evokes, that seems about right. ;-)



could lead to a new branch of the field:  affective computing.

or at least an extension to related work:  affective logic.

the result of a computation depends upon how you feel about it.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Phillip Hallam-Baker]

At the time email was a special case because it was the *only* application.

In any case, my point was not that we should follow the original
intent of the founders except to the extent that they faced a
particular set of problems and technical and social constraints and
looked for the best ways to solve them. We should certainly understand
why they came to the conclusions they did, but refusing to accept a
particular interpretation of their intent does not make someone
'ignorant' or 'marginally informed'.


On Mon, Aug 30, 2010 at 1:58 PM, Noel Chiappa  wrote:
>    > From: Phillip Hallam-Baker 
>
>    > What made the Internet unique was the fact that it was the only
>    > inter-network that was designed to play nice with other networks that
>    > existed at the time. You could run DECNET or SNA or anything you chose
>    > on your campus and still exchange mail with the rest of the world.
>    >
>    > IP to the edge was a special case.
>
> Ah, no. There were eventually tweaks to the _email_ system to enable it to
> interoperate with other email systems (others will remember those far better
> than I), but that has nothing to do with the network/transport layers. The
> vast bulk of the early Internet work was focused on just the people using
> TCP/IP - and to run any of that, you needed "IP to the edge". (I am
> remembering of the pain we suffered at LCS before we got an IMP port so we
> could bring up our first IP gateway to the rest of the world...)
>
> And as for ability to run DECNET and IP on one's campus at the same time as
> IP - that was not the original direction taken at many places. Certainly at
> MIT we spent (wasted, to be honest) a lot of time trying to create an
> underlying data-carriage layer to carry both IP and CHAOS (and other stuff)
> before we went with the 'ships in the night' approach, and the multi-protocol
> router.
>
> But this is getting a bit off track. If you want to continue, let's move
> this to 'internet-hist...@postel.org'.
>
>        Noel
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Meeting Venue Preference Survey

[Dave CROCKER]

On 8/30/2010 10:53 AM, Marshall Eubanks wrote:

On Aug 29, 2010, at 8:10 PM, Dave CROCKER wrote:

The premise to these anecdotes appears to be that IETF meetings are
designed for people who have:

* hefty corporate travel funding-- so money is largely no object


As someone who frequently pays for IETF travel out of my own pocket, I can
assure you that this is not true for me. Ditto for meeting and travel time
sinks.



Since my note specifically challenged the tendency to indulge in personal 
anecdotes, I can't guess why you responded with a personal perspective. Worse, 
it appears to have had nothing to do with the point I was making.


Since you are on the IAOC, your posting is particularly confusing.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Is this true?

[Phillip Hallam-Baker]

No, if IP to the edge had been the only idea in the Internet
architecture it would have been no different and no better than any of
the other networking schemes on offer at the time.

What made the Internet unique was the fact that it was the only
inter-network that was designed to play nice with other networks that
existed at the time. You could run DECNET or SNA or anything you chose
on your campus and still exchange mail with the rest of the world.

IP to the edge was a special case.

The technology we need to manage the IPv4 to IPv6 transition is
already in the Internet DNA. All it takes is to jettison the ideology
and accept that for at least the next twenty years we will be dealing
with heterogeneous networks, only this time they will be IPv4/IPv6
rather than IPv4/DECNET/OSI/SNA/CHAOS etc as was the case in the 80s
and early 90s.


The endpoints that matter are people.

Unless I am mistaken, people don't have IPv4 or IPv6 addresses.

So no HMI protocol is ever IP clean end to end.


On Mon, Aug 30, 2010 at 11:45 AM, Noel Chiappa  wrote:
>    > From: Phillip Hallam-Baker 
>
>    > Ironically we are returning to the original model of the Internet. Only
>    > we are returning to the 1970s model of Clark, Cerf et. al. in which the
>    > only constant is that every network uses the Internet Protocol for
>    > communication across the Internetwork. IP to the endpoint was actually
>    > a later idea.
>
> Say what? Internetwork packets directly to the end-host (with TCP on top) was
> a constant in the internet architecture from before IP even existed (i.e.  TCP
> 1, TCP 2, etc).
>
>        Noel
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Meeting Venue Preference Survey

[Andrew Sullivan]

On Sat, Aug 28, 2010 at 10:17:20AM -0700, Dave CROCKER wrote:

> We really need to get these surveys produced by someone with training in 
> survey design.

Or stop using the surveys.  It isn't clear to me that the surveys are
a good idea at all, not just because of sampling biases and survey
design issues, but because they may lead to apparent statements of
preference that don't conform to the general principles that ought to
undergird IAOC decisions.

Surveys are a good way to make a decision look democratic, but there
are well-known and serious problems with collective preference
expression.  (If you don't believe this, you might start by looking up
Kenneth Arrow, whose exploration of this issue is the most famous.
There's a large body of work around this general topic, however.)

If we have general principles for venue selection (for instance), then
asking people to complete a survey is not the right thing to do:
either a given site can be shown to conform to the venue selection
principles, or it can't.  If it does conform, then a survey might
actually reveal a collective "preference" to go elsewhere, but that
would not be a rational preference.  (I wonder in fact whether the
decision to go to Québec will turn out this way.)

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC

[todd glassey]

On 8/31/2010 7:36 AM, Glen Barney (AMS) wrote:
> Community - 
> 
> The DNS zone files have been re-signed, and we will look into alternatives to
> the original DNSSEC tools that were in use (which seem to be broken.)
> 
> And just a reminder that, while posting complaints to this list might feel
> more therapeutic, the secretariat has an address set up for trouble reports,
> which is ietf-act...@ietf.org .  Sending complaints to that address will
> generally get much faster results.
> 
> Thank you!
> 
> Glen
> Glen Barney
> IT Director
> AMS (IETF Secretariat)

Glen your real issue is why DNSSEC was released in this condition and
the damage to the world in the form of wasted effort this causes.
Something that for what its worth provides yet another black-eye for the
IETF (and the parties making GSO and the IETF their career).

Todd Glassey
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.851 / Virus Database: 271.1.1/3103 - Release Date: 08/30/10 
> 11:34:00
> 


-- 
//-


This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.

Thank you for your cooperation.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC

[Glen Barney (AMS)]

Community - 

The DNS zone files have been re-signed, and we will look into alternatives to
the original DNSSEC tools that were in use (which seem to be broken.)

And just a reminder that, while posting complaints to this list might feel
more therapeutic, the secretariat has an address set up for trouble reports,
which is ietf-act...@ietf.org .  Sending complaints to that address will
generally get much faster results.

Thank you!

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Attendance by continent

[Iljitsch van Beijnum]

On 31 aug 2010, at 1:13, Tobias Gondrom wrote:

> My vote is strongly in favor of 1:1:1.

> 1. First, the location _is_ a significant barrier to entry for newcomers
> and other contributors. Optimizing only for the current status quo does
> create a strong perpetual cycle of self reinforcing structure of
> contributors from the favored location(s).

You assume that having a meeting on your home continent magically makes 
attending a meeting much easier.

I don't think that's necessarily the case. Just consider the language issue. I 
think we can safely assume that everyone who thinks about attending IETF 
meetings speaks English. So attending a meeting in a country where English is 
the official language is much easier than in a place where few people speak it. 
Even in the Netherlands, where virtually everyone speaks at least some English, 
there was a bit of a language barrier because signs, menus, etc where often 
only available in Dutch.

Also, flying across a big continent can take just as long as flying across an 
ocean. And although there is a correlation between travel distance and cost, 
that correlation is well below 1. Sometimes intercontinental flights are the 
same price or cheaper than regional flights, and often the difference is small 
enough that it disappears in the noise of hotel prices, ground transportation 
costs, food expenses and the like.

Last but not least, attendance is only one metric. If it were the only relevant 
one, we'd have to meet on a Cisco campus once every three years, as about 10% 
of the attendees are employed by Cisco. Even though Asian attendance has been 
on the rise, contributions from Asian IETFers seem to be lagging their 
attendance numbers. (For instance, as far as I can tell from the names, none of 
the IESG members is from Asia.)

For all these reasons, I think that 1:1:1 is not warrented at this time. Maybe 
it will be in a few more years, but I think we should first see how well 
meetings in places like Beijing go before committing to having a meeting in 
Asia every year. Meeting in Europe seems to lead to compromises. Maybe Asia 
will turn out to be better in this regard, maybe worse. I don't think we want 
to have meetings with more compromises just to appear balanced.

> Consider that contributors
> usually start as newcomers, attend several meetings, then write a draft,

I don't know about you, but I wrote drafts before my first meeting.

> join more WGs and maybe chair a WG. But if you make it hard for
> newcomers to attend several meetings they are at a severe disadvantage
> to become future contributors.

If that were true we'd need to go to places where we _don't_ have attendees 
yet, not to Asia which has been sending a steady supply in recent years.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[Yoav Nir]

On Aug 31, 2010, at 10:43 AM, t.petch wrote:

>>> If you want to be fair to the individual participants you have to optimize
> in such a way that attending 6 meetings costs the same for every individual 
> that
> regularly attends the IETF. Obviously one can only approximate that by putting
> fairly large error bars on the costs but isn't the X-Y-Z distribution where X=
> approx Y= approx Z  the closest optimum? (or finding one place that sucks
> equally for everybody)

One place that sucks for everybody has the great advantage of reducing the 
stress associated with travel. A lot of people were stressed about the various 
ways of getting to Maastricht, and a lot more are stressed about getting to 
Beijing (what with various kinds of visas, hotels and taxi drivers who don't 
speak any language other than Chinese)

If we standardize on one place, then by your second meeting, you know 
everything about the place, and people can cut&paste their complaints from the 
previous meeting.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: DNSSEC is hard to get right

[Richard L. Barnes]

Another view, for the visually inclined:



On Aug 31, 2010, at 2:41 AM, Stephane Bortzmeyer wrote:


% check-sig iab.org
Name iab.org has an expired signature (20100829223019)

:-(
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Optimizing for what? Was Re: IETF Attendance by continent

[t.petch]

- Original Message -
From: "Iljitsch van Beijnum" 
To: "Olaf Kolkman" 
Cc: "IETF-Discussion list" 
Sent: Monday, August 30, 2010 10:33 PM

> On 30 aug 2010, at 21:57, Olaf Kolkman wrote:
>
> > If you want to be fair to the individual participants you have to optimize
in such a way that attending 6 meetings costs the same for every individual that
regularly attends the IETF. Obviously one can only approximate that by putting
fairly large error bars on the costs but isn't the X-Y-Z distribution where X=
approx Y= approx Z  the closest optimum? (or finding one place that sucks
equally for everybody)
>
> > Am I missing something?
>
> Yes.
>
> Optimizing for min(X+Y+Z) WITH the constraint X=Y=Z is almost certainly going
to produce a higher X+Y+Z than without that constraint. In other words, if you
want to be fair the total expense for the entire community will be larger.
>
> Contrary to popular belief, distance is not the most important factor in
travel expenses. My flight from Madrid to Dublin cost almost what I paid to fly
from Amsterdam to Minneapolis a few years before. Hotel rates have a much bigger
impact, especially now that the official IETF hotels seem to be getting more
expensive every time we meet.

I agree about the distance.  I see America as the travel industry's equivalent
of the sociometric star, and would happily go for 6:0:0 since it is travel costs
that dictate my presence (usually absence:-(   By contrast, almost anywhere in
Europe is more expensive to get to (from the UK).

Tom Petch
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf