RE: My view of the IAOC Meeting Selection Guidelines

[Lawrence Rosen]

Iljitsch van Beijnum wrote:
> So that means every meeting has to bring in $800k, which is a bit more
> than the current number of attendees x the current registration fee.

Fred Baker wrote:
> One thing the IAOC is looking at at this instant is our phone bill.
> The IETF's phone budget for 2008 is
> 
> IESG:   $58,800
> IAB:$22,500
> Nomcom: $30,000
> IASA/IAOC:  $17,235
>-
> $128,535

It seems to me that the $800k budget for a single conference can buy an
awful lot of telephony (or VoIP) bandwidth so that inefficient and expensive
in-person meetings can be replaced by web meetings. Perhaps that money could
even be used to pay programmers to create a workable web-based voice and
video system for technical meetings -- open source, of course.

I understand that these budget items aren't directly transferrable, but I'm
struck by how much we pay for bad ways to meet, and how relatively little we
pay for all the other electronic communications that gets the real work
done. 

Fred Baker further wrote:
> I won't go through the budget line by line, but you get the idea. In
> a $4.9M budget, we are looking at a few line items in 6 digits and a
> number more in five digits, and asking in each case how to change N
> digits to N-1.

This doesn't even count the ever-increasing cost in travel and lodging
expenses that individuals and their companies pay to attend IETF meetings.
That's why I never attend, for example: Too expensive, even when I'd rather
be there to vote!

Surely we can find a way to work together without always having to fly to
distant climes? And we'd save the environment too, if technical
professionals got together electronically.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen


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

Re: IETF 72 --> Dublin!

[Clint Chaplin]

It strikes me that this discussion could use some of the same methods
that are promulgated in "Moose Turd Pie"
: if a person
complains, they're required to take over the job.

On 2/8/08, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 08, 2008 at 04:00:26PM -0500, David Harrington wrote:
> > I think the complaints would simply be slurred more, and we might have
> > to worry about lynch mobs (which would remind me of the reasonableness
> > of this discussion so far).
>
> To be fair, I think most of the concerns raised on this discussion
> have been relatively reasonable, although perhaps people have been
> worrying without having enough information.  It appears that they may
> be some restaurants other than those in the hotel; whether they are
> sufficient is unclear at the moment, but either way, the die is seems
> to be cast and even if there are not sufficient restaurants, it seems
> too late to do anything about it.  (Except maybe for adjusting the
> schedule so people have time to take the buses into Dublin, or some
> such, if it really is an issue.)
>
> One sugestion that I would make for the people who are tasked to do
> site surveys is to collect a list of resturants nearby, with
> addresses, type of cuisine, average cost for lunch/dinner, distance
> from the hotel, and number of diners they can handle.  I suspect the
> concierge for the conference hotel has the information on hand
> already, so collecting it shouldn't be difficult; just asking them to
> make the information available should be all that's needed.
>
> Placing this information on the web site would be extremely useful for
> IETF attendees who are trying to determine where they can get
> sustenance without mobbing the concierge, and it would also serve to
> ease the minds of people who might have various dietary restrictions,
> or just want to make sure that there are alternatives beyond buying
> lunchmeat at a local convenience store or paying $24 for a coffee and
> a pastry at an expensive resort restaurant.  (I've paid that much in
> Venice when on vacation; never again...)
>
>- Ted
> ___
> Ietf mailing list
> Ietf@ietf.org
> http://www.ietf.org/mailman/listinfo/ietf
>


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

Re: My view of the IAOC Meeting Selection Guidelines

[Fred Baker]

On Feb 8, 2008, at 12:30 PM, Iljitsch van Beijnum wrote:
> I suggest we start thinking about this now rather than at the point  
> where the IETF can't pay its bills anymore. Where do we draw the  
> line on meeting fee increases? Is there any way to save costs? What  
> was the cost structure 10 or 15 years ago when meeting attendance  
> was much smaller?

Thanks. Yes, the IAOC is thinking about that too. We spent Monday and  
Tuesday this week in Helsinki on exactly that question. The IETF  
didn't cover our travel :-)

To be honest, a lot of the data regarding meetings 15 years ago isn't  
available. We don't know what the costs were. "Better financial  
insight" was one of the reasons we went through the process of moving  
the secretariat away from CNRI in the first place. I'll also bicker  
with your numbers a bit; in March 1998 we were comparable in size to  
what we do now, and we were spending the last of our NSF subsidy  
funding. In 1993 we had our first meeting in Amsterdam, ~700 people  
in the RAI conference center, funded in part by US research funding.  
I'm not sure we're apples and apples in this.

Before 1992, the IETF largely met in academic donated meeting  
facilities. When the meeting went above ~500 people, that became  
untenable, and we have used hotels and conference centers since. One  
option is to look again at donated facilities. We have asked hotels  
to provide a vendor selling sandwiches for lunch; we could have a  
vendor sell coffee and cookies. One thing I'm hoping AMS can do  
better for us than CNRI/Foretec/Neustar did is meeting cost  
negotiations - I suspect there is still some blood in that turnip.

One thing the IAOC is looking at at this instant is our phone bill.  
The IETF's phone budget for 2008 is

IESG:   $58,800
IAB:$22,500
Nomcom: $30,000
IASA/IAOC:  $17,235
   -
$128,535

Now, our sense is that we can improve meeting quality for the above  
and reduce the cost by using a VoIP service. One that comes quickly  
to mind is Skype; that has some issues, both with confidentiality and  
Net Neutrality. It is also currently limited to conferences of 5  
participants, 10 participants if everyone has a dual-core processor.  
For an IESG meeting, the implied peak bandwidth is quite high -  
19*70=1330 KBPS - because the data would be sent to 19 other  
participants unicast (the IESG is 20 people). My service is 384 KBPS  
upload, so I personally would have to pay a lot more money if I were  
to volunteer for the role. I don't think we're going to use Skype. So  
we're looking for something that either uses a central server and  
mixes sound, or runs IP multicast over the backbone, which is (ahem)  
not a ubiquitous service. The ISOC Board uses a webex-like package  
called Marratech (http://en.wikipedia.org/wiki/Marratech), which has  
since been acquired from Marratech by Google. ISOC purchased the  
necessary server licenses and can expand them if needed; we think  
this part of the budget can be dramatically reduced by asking  
participants to download the free software and use it. The bodies  
we'd be asking haven't yet had that discussion, but its something the  
IAOC is looking at.

We're looking pretty hard at the RFC Editor contract, which has a  
large overhead fee built into it. Stay tuned in that regard. We have  
some ideas and will be doing an RFI or RFP later this year, but they  
aren't sufficiently baked just yet to pass aromas around.

I won't go through the budget line by line, but you get the idea. In  
a $4.9M budget, we are looking at a few line items in 6 digits and a  
number more in five digits, and asking in each case how to change N  
digits to N-1.
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Comment on draft-santoni-timestampeddata-02

[Bill McQuillan]

Perusing this draft I came upon a paragraph that seemed to need comment:

 3. Compliance requirements 

...

Compliant applications SHALL always populate the fileName field of 
TimeStampedData structure with a non-empty string, which is supposed 
to be the real name of the time-stamped file. Path information MUST 
NOT be included. A valid example is "patent123.doc". An invalid 
example is "c:\Documents and settings\John\Desktop\patent123.doc". 

It seems to me that the MUST for a non-null filename presumes that there
will never be a situation where the data has no natural filename and the
identity of the data is known from other context information. If it ever
becomes necessary for a convention to arise where data, that doesn't have a
natural filename, gets some name like "unknown.name", I believe that it
would be better to allow a null name to be given.

Note that some sort of validation must be done by the consumer of the
TimeStampedData anyway to prevent a filename being used that has invalid
syntax for the consumers filesystem or would overwrite another file that
happens to have the same name, etc.

Further, it seems to me that "path information MUST NOT be included" makes
too many assumptions about the larger context. If the file happens to have
a natural name which, for instance, has date information in the path, like:
"/logs/2008/02/08/transaction.log" and is routinely sent each day, the
so-called "real name" of the file (transaction.log) is useless since it
would be the same for every version of the file.

A more appropriate requirement for both of these situations would be to put
text in the Security Considerations section requiring any consumer of
TimeStampedData to validate the entire filename according the rules of its
local filesystem and its intended usage before using some or all of the
name to store the data.

-- 
Bill McQuillan <[EMAIL PROTECTED]>

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

Re: IETF 72 --> Dublin!

[Theodore Tso]

On Fri, Feb 08, 2008 at 04:00:26PM -0500, David Harrington wrote:
> I think the complaints would simply be slurred more, and we might have
> to worry about lynch mobs (which would remind me of the reasonableness
> of this discussion so far).

To be fair, I think most of the concerns raised on this discussion
have been relatively reasonable, although perhaps people have been
worrying without having enough information.  It appears that they may
be some restaurants other than those in the hotel; whether they are
sufficient is unclear at the moment, but either way, the die is seems
to be cast and even if there are not sufficient restaurants, it seems
too late to do anything about it.  (Except maybe for adjusting the
schedule so people have time to take the buses into Dublin, or some
such, if it really is an issue.)

One sugestion that I would make for the people who are tasked to do
site surveys is to collect a list of resturants nearby, with
addresses, type of cuisine, average cost for lunch/dinner, distance
from the hotel, and number of diners they can handle.  I suspect the
concierge for the conference hotel has the information on hand
already, so collecting it shouldn't be difficult; just asking them to
make the information available should be all that's needed.

Placing this information on the web site would be extremely useful for
IETF attendees who are trying to determine where they can get
sustenance without mobbing the concierge, and it would also serve to
ease the minds of people who might have various dietary restrictions,
or just want to make sure that there are alternatives beyond buying
lunchmeat at a local convenience store or paying $24 for a coffee and
a pastry at an expensive resort restaurant.  (I've paid that much in
Venice when on vacation; never again...)

   - Ted
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

RE: IETF 72 --> Dublin!

[David Harrington]

I think the complaints would simply be slurred more, and we might have
to worry about lynch mobs (which would remind me of the reasonableness
of this discussion so far).

dbh 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Dave Crocker
> Sent: Thursday, February 07, 2008 1:25 AM
> To: David Kessens
> Cc: 'IAOC'; IAB; 'IETF Discussion'; Richard Shockey
> Subject: Re: IETF 72 --> Dublin!
> 
> David Kessens wrote:
> > PS anyways, maybe the local/Dublin restaurant scene is 
> really not what we
> >should be looking for in Ireland: should we not care more
> >about the local brews ?
> 
> 
> Open taps in each meeting room might, indeed, eliminate any 
> complaints about the 
> venue.
> 
> d/
> 
> 
> -- 
> 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net
> ___
> Ietf mailing list
> Ietf@ietf.org
> http://www.ietf.org/mailman/listinfo/ietf
> 


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

RE: IETF 72 --> Dublin!

[Richard Shockey]

>  
>  > Is there an unwritten requirement that IETFs are placed to afford
>  > us sightseeing?
>  

You mean this isn't the Individual Enlightenment and Travel Foundation
mailing list ... oh so sorry.

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

Re: [IAOC] Dublin Hotel Contract was Re: IETF 72 --> Dublin!

[Joe Abley]

On 8-Feb-2008, at 14:33, Richard Barnes wrote:

> I noticed the same thing when I was making my booking.  As a  
> precaution,
> I put a note in the "Comments" block saying that I expect the terms of
> the IETF contract to be followed, with a copy of the terms from  
> Ray's email.

Heh, and I thought I was the only one pedantic enough to do that :-)


Joe

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

Re: My view of the IAOC Meeting Selection Guidelines

[Iljitsch van Beijnum]

On 8 feb 2008, at 9:29, Bob Hinden wrote:

> The budget information can be found
> at: http://iaoc.ietf.org/.  In round numbers total expenses are about
> $4M, revenue is about $2.5M, and the ISOC contributes about $1.5M.
> If it wasn't for the ISOC we would have a big problem.

So that means every meeting has to bring in $800k, which is a bit more  
than the current number of attendees x the current registration fee.

The number of attendees is slowly but steadily going down. I don't  
think this translates in substantial net cost savings for the meetings  
(many costs are fixed; smaller attendee population will draw fewer  
hosts; hosts will pay in some relationship to meeting costs) so this  
means either the fees will have to go up even further, which won't  
help attendance, or the non-meeting costs the IETF incurs will have to  
go down. (I'm assuming non meeting fee fund raising is already maxed  
out.)

I suggest we start thinking about this now rather than at the point  
where the IETF can't pay its bills anymore. Where do we draw the line  
on meeting fee increases? Is there any way to save costs? What was the  
cost structure 10 or 15 years ago when meeting attendance was much  
smaller?
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: IETF 72 --> Dublin!

[Fred Baker]

> Is there an unwritten requirement that IETFs are placed to afford  
> us sightseeing?

Maybe we should add a pointer to the local "things to see and do in  
Ireland" page to the Meetings page.

As an engineer, I would very much encourage people to stay an extra  
day and tour NewGrange. Imagine the engineering challenge. One day,  
some guy walks into a valley with a few rolling hills in it:

 http://picasaweb.google.com/FredBakerSBA/ 
SaintPatrickSDayInIreland/photo#5141698100648551458

He decides that there just really needs to be a passage tomb in which  
light shines on the magic spot for 17 minutes on the winter equinox  
and maybe the day before and after. He then proceeds to build a hill,  
by mounding rocks in corbel construction (which is one way that  
cathedral builders build arches, the other common one being keystone  
construction), covering it with dirt, and decorating it with other  
rocks brought from a site 80 km away.

 http://picasaweb.google.com/FredBakerSBA/ 
SaintPatrickSDayInIreland/photo#5141698147893191794

So, no problem. there is no such thing as an engineering drawing. But  
he explains to his son (who 20 years later explains to his son, who  
20 years later explains to his son, who 20 years later explains to  
his son, who 20 years later explains to his son) what he wants built,  
and ends with the punchline "when all is said and done, the light  
stops here". The community walks 80 km to get rocks, carries baskets  
of dirt, and even picks up small things like the notion of putting  
gravel between the layers of rock to prevent them from grinding each  
other to sand. The result of his effort is a passage tomb that  
survives to this day, 5000 years later.

I think the engineering is fascinating...

More pictures at

 http://picasaweb.google.com/FredBakerSBA/SaintPatrickSDayInIreland

http://en.wikipedia.org/wiki/Newgrange
http://www.dublinbus.ie/sightseeing/index.aspx
http://www.irelandby.com/sightseeing/sightseeing_dublin.htm
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: [IAOC] Dublin Hotel Contract was Re: IETF 72 --> Dublin!

[Richard Barnes]

Ole,

I noticed the same thing when I was making my booking.  As a precaution, 
I put a note in the "Comments" block saying that I expect the terms of 
the IETF contract to be followed, with a copy of the terms from Ray's email.

--RB



Ole Jacobsen wrote:
> I can confirm that the confirmation letter from the hotel does not 
> reflect the terms stated by Ray, but this is presumably just a 
> limitation of their automated system. For example, the letter says:
> "These rates are not available for groups or conferences," which
> is exactly the opposite of what's going on here.
> 
> Ole
> 
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
> E-mail: [EMAIL PROTECTED]  URL: http://www.cisco.com/ipj
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> http://www.ietf.org/mailman/listinfo/ietf
> 
> 

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

Review of draft-ietf-simple-imdn

[Eric Rescorla]

$Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr Exp $

This document describes a mechanism for IM senders to request status
notifications for their IMs. The sender attaches a header specifying
the status conditions he wants to be notified of and intermediaries
and the receiving UA notify the sender (or someone else of his choice)
subject to policy constraints.

One thing I'm not clear on is how the recipient determines where to
send the IMDN. Are they supposed to read the "From" field? One thing
that I don't get is how the IMDN-Route header interacts here.
It looks to me like this gets stuffed in the "To" in the IMDN.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?
   
Overall, this document seems pretty well written and clearly lays out
the security issues.

That said, I'm concerned about the bounce/reflection threats discussed
in S 14 (where the sender asks for notification to a third party
victim).  I'm particularly concerned about the "note" field, since a
natural implementation seems to be to include an excerpt from the
message you're acknowledging.  This draft identifies the threat but
doesn't specify any mechanism for ameliorating them. I think some
suggested mechanisms would be appoprirate here, or at least some
analysis of what the potential mechanisms were and why they would or
would not work.

Other comments: I would avoid the term "non-repudiation" if at all
possible in S 5.3 and later. It's just so overloaded now that it's
hard to know what it means.

S 6.5.  A little more explanation of why IMDN-Record-Route is useful
would help.

S 7.1.1.1.  Why does Message-ID need any randomness at all as opposed
to uniqueness?  And if it needs randomness, why is 32 enough?

S 7.1.3.  Note that you can pack the state into the messageid if
you're willing to make large message ids and hte stte is small.

S 11.1

   An IMDN Payload is an XML document [6] that MUST be well formed and
   MUST be valid according to schemas, including extension schemas,
   available to the validater and applicable to the XML document.  The
   IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
   UTF-8.

Is this a requirement that the receiver validate the XML?


S 12.1.1.  Why can't anonymous senders request notifications?

S 14.3.  See above comemnts about nonrepudiation

-Ekr
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

Re: O&M Directorate Review of draft-ietf-hokey-erx-09

[Lakshminath Dondeti]

Hi Bernard,

Thanks for the followup.  Some notes inline:

On 2/8/2008 8:47 AM, Bernard Aboba wrote:
> Comments below.
> 
>  > Date: Fri, 8 Feb 2008 01:38:30 -0800
>  > From: [EMAIL PROTECTED]
>  > To: [EMAIL PROTECTED]
>  > CC: ietf@ietf.org
>  > Subject: Re: O&M Directorate Review of draft-ietf-hokey-erx-09
>  >
>  > Hi Bernard,
>  >
>  > Many thanks for your review. Please see inline for some thoughts and
>  > proposals for improvement of erx-09:
>  >
>  > On 2/6/2008 4:07 PM, Bernard Aboba wrote:
>  > > Review of draft-ietf-hokey-erx-09
>  > >
>  > > I have reviewed this document as part of the Operations and Management
>  > > directorate effort. These comments were primarily written for the
>  > > benefit of the O&M area directors. Document editors and WG chairs
>  > > should treat these comments just like any other last call comments.
>  > >
>  > > Detailed review comments are available here:
>  > > http://www.drizzle.com/~aboba/EAP/erx-review.txt
>  > >
>  > > An answer to typical O&M issues is included below:
>  > >
>  > > 1. Is the specification complete? Can multiple interoperable
>  > > implementations
>  > > be built based on the specification?
>  > >
>  > > There are a few areas of the document which are unclear to me, such 
> as how
>  > > AAA routing is accomplished, and how/when peers require the local 
> realm, and
>  > > if so, how it is to be obtained. Also, clarity with respect to 
> algorithm
>  > > agility could be improved. There are also some issues with respect 
> to the
>  > > required behavior of ERX peers and severs (use of normative language).
>  > >
>  > > There are also situations in which multiple approaches can be chosen
>  > > (such as
>  > > the various bootstrap options), without one being chosen as 
> mandatory or
>  > > default. Choosing one approach would seem to be better.
>  > >
>  > > In my judgement, addressing these issues would improve the 
> likelihood of
>  > > being able to build multiple interoperable implementations.
>  >
>  > I agree. This has been brought up by Joe and we'll clarify the text.
>  > Some of the confusion has to do with the evolution of the draft; Vidya
>  > and I spent a good amount of time cleaning up around the WGLC time, but
>  > it appears that we can do better.
>  >
>  > Pasi suggested adding a section on lower layer considerations. That
>  > should help as well.
>  >
>  > >
>  > > 2. Is the proposed specification deployable? If not, how could it be
>  > > improved?
>  > >
>  > > Based on my reading of the document, it would appear that the ERX 
> proposal
>  > > requires changes to EAP peers, authenticators and servers, as well as
>  > > RADIUS
>  > > clients, proxies and servers. It also appears possible that changes 
> to the
>  > > lower layer protocols will be required in at least some cases, such 
> as to
>  > > make the local domain available to the peer.
>  > >
>  > > Given my experience in designing and operating wireless networks,
>  > > deployments
>  > > requiring changes only to peers and authenticators (but not servers or
>  > > RADIUS
>  > > infrastructure) can take as long as 3-5 years to complete. For example,
>  > > WPA2 is still not universally deployed, even though the 
> specification was
>  > > finished in 2004.
>  >
>  > WPA2 compliance requires hardware upgrade in many cases and that may
>  > have been the reason for the delay. In addition, some enterprises found
>  > an alternative solution, i.e., IPsec VPNs, and so were not as motivated
>  > to move to WPA2.
>  >
>  > In case of ERX, a firmware upgrade should be sufficient, which is much
>  > more easier.
> 
> [BA] One thing that we've learned from the WEP/WPA experience is that
> changes that often can be delivered via firmware/software upgrade are 
> often linked
> to new hardware for efficiency reasons.  For example, while TKIP was
> designed for backward compatibility with WEP, few vendors offered
> upgrades to existing WEP APs; most introduced the changes on new
> models instead, out of the desire to only continue development on
> newer branches of the code tree.  Similar examples exist for peer
> updates (e.g. IPv6 support on legacy operating system versions).

I guess we can go on this forever as I have a different take on this and 
so far haven't seen any new information to change my mind.

In case of ERP, there are fewer messages, whereas in case of TKIP and 
IPv6 the upgrade involves additional processing requirements.  I do 
realize that processing logic is slightly more complex, but with some of 
the proposed optimizations in the recent reviews, the complexity is 
quite low.

> 
> So in practice, making changes to a component will often result in the
> need for new hardware, even if hardware changes were not required by
> the design.

Generally speaking, yeah, I do agree.  I think the one barrier for ERP 
deployment is local ER server deployment.  Everywhere else, while there 
is a need for a software/firmware upgrade, there is no need for hardware

Re: [IAOC] Dublin Hotel Contract was Re: IETF 72 --> Dublin!

[Ole Jacobsen]

I can confirm that the confirmation letter from the hotel does not 
reflect the terms stated by Ray, but this is presumably just a 
limitation of their automated system. For example, the letter says:
"These rates are not available for groups or conferences," which
is exactly the opposite of what's going on here.

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [EMAIL PROTECTED]  URL: http://www.cisco.com/ipj



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

Dublin Hotel Contract was Re: IETF 72 --> Dublin!

[Ray Pelletier]

The Citywest Contract with IETF provides;

1. Room Rates - Single: 130 EUR: Double: 160 EUR; Breakfast, Internet 
and taxes are included

2. Guest substitution permitted
3. Promotion Code: IETF

4. Guest Cancellation
Individuals can cancel the reservation without penalty until 3 days 
prior to check-in / arrival. In case of cancellation less than 3 days 
prior to the event or non-arrival or no-show, the Hotel holds the right 
to charge the individuals one nights stay as cancellation fees.


5. Check In - Check Out.  Hotel check-in is 15:00 hrs. Check-out is to 
be completed by 11:00 AM however Hotel shall reasonably accommodate 
early arrivals and late departures of the international attendees based 
on availability.


6. Non-smoking Rooms.  The Hotel's guestroom should be at least 95% 
non-smoking in inventory.


7. Renovation.  As of the date of the signing of this contract, Hotel 
has no plans for renovation and remodeling.


8. Difficulties with reservations can be addressed to Melissa at 
[EMAIL PROTECTED]


Ray

Wojciech Dec (wdec) wrote:


Hi Ray,
 
I don't want to prolong this thread much more, but the booking terms & 
conditions at the City West are unusually strict, if not incorrect 
(note the reference to the groups/conferences).

Here's what I get when using the IETF booking code:
 
---snip---

Please note the following terms & conditions relate to this booking.
 
. Bookings are non refundable and non transferable.

. Cancellations will not be accepted for online bookings
. Check in time : after 1400 hrs
. Check out time : before 1200 hrs
. Rates are per room per night.
. Rates are for accommodation only unless otherwise stated.
. These rates are not available for groups or conferences.
. Rates are non commissionable.
. Management reserve the right to assign guests to rooms in either the 
Citywest Main or Golf Hotels depending on availability
. For single adult reservations the Management reserve the right to 
provide guests with a single room instead of double room only in the 
unlikely event of all double rooms being occupied

---snip---
 
Can you confirm that indeed these are the terms we'll have to agree to 
(the non refundable, non cancellable condition is particularly annoying).
 
Thanks,

Woj.
 


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

Re: IETF 72 --> Dublin!

[Stephen Farrell]

Ray Pelletier wrote:
> If you want to see Dublin, and I recommend it, consider arriving 2 - 3 
> days early, or staying after the meeting at a hotel downtown near 
> Grafton Street and Trinity College.  The college even has dorm rooms 
> available at very reasonable rates, if you don't mind roughing it a bit..

And if you want to ask about that feel free to mail me or grab me
in Philly.

We'll gladly sell you a room in Trinity College for about €70 [1]
though I wouldn't recommend trying to commute from here.

For a few quid more, you can ask for a long room [2] :-)

Cheers,
Stephen.

[1] http://www.tcd.ie/accommodation/Visitors/
[2] http://www.tcd.ie/Library/heritage/longroom.php

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

RE: O&M Directorate Review of draft-ietf-hokey-erx-09

[Bernard Aboba]

Comments below. 

> Date: Fri, 8 Feb 2008 01:38:30 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: ietf@ietf.org
> Subject: Re: O&M Directorate Review of draft-ietf-hokey-erx-09
> 
> Hi Bernard,
> 
> Many thanks for your review.  Please see inline for some thoughts and 
> proposals for improvement of erx-09:
> 
> On 2/6/2008 4:07 PM, Bernard Aboba wrote:
> > Review of draft-ietf-hokey-erx-09
> > 
> > I have reviewed this document as part of the Operations and Management
> > directorate effort.  These comments were primarily written for the
> > benefit of the O&M area directors.  Document editors and WG chairs
> > should treat these comments just like any other last call comments.
> > 
> > Detailed review comments are available here:
> > http://www.drizzle.com/~aboba/EAP/erx-review.txt
> > 
> > An answer to typical O&M issues is included below:
> > 
> > 1. Is the specification complete?  Can multiple interoperable 
> > implementations
> > be built based on the specification?
> > 
> > There are a few areas of the document which are unclear to me, such as how
> > AAA routing is accomplished, and how/when peers require the local realm, and
> > if so, how it is to be obtained.  Also, clarity with respect to algorithm
> > agility could be improved.  There are also some issues with respect to the
> > required behavior of ERX peers and severs (use of normative language).
> > 
> > There are also situations in which multiple approaches can be chosen 
> > (such as
> > the various bootstrap options), without one being chosen as mandatory or
> > default.  Choosing one approach would seem to be better.  
> > 
> > In my judgement, addressing these issues would improve the likelihood of
> > being able to build multiple interoperable implementations.
> 
> I agree.  This has been brought up by Joe and we'll clarify the text. 
> Some of the confusion has to do with the evolution of the draft; Vidya 
> and I spent a good amount of time cleaning up around the WGLC time, but 
> it appears that we can do better.
> 
> Pasi suggested adding a section on lower layer considerations.  That 
> should help as well.
> 
> > 
> > 2. Is the proposed specification deployable?  If not, how could it be
> > improved?
> > 
> > Based on my reading of the document, it would appear that the ERX proposal
> > requires changes to EAP peers, authenticators and servers, as well as 
> > RADIUS
> > clients, proxies and servers.  It also appears possible that changes to the
> > lower layer protocols will be required in at least some cases, such as to
> > make the local domain available to the peer.
> > 
> > Given my experience in designing and operating wireless networks, 
> > deployments
> > requiring changes only to peers and authenticators (but not servers or 
> > RADIUS
> > infrastructure) can take as long as 3-5 years to complete.  For example,
> > WPA2 is still not universally deployed, even though the specification was
> > finished in 2004.
> 
> WPA2 compliance requires hardware upgrade in many cases and that may 
> have been the reason for the delay.  In addition, some enterprises found 
> an alternative solution, i.e., IPsec VPNs, and so were not as motivated 
> to move to WPA2.
> 
> In case of ERX, a firmware upgrade should be sufficient, which is much 
> more easier.

[BA] One thing that we've learned from the WEP/WPA experience is that
changes that often can be delivered via firmware/software upgrade are often 
linked
to new hardware for efficiency reasons.  For example, while TKIP was
designed for backward compatibility with WEP, few vendors offered
upgrades to existing WEP APs; most introduced the changes on new
models instead, out of the desire to only continue development on
newer branches of the code tree.  Similar examples exist for peer
updates (e.g. IPv6 support on legacy operating system versions). 

So in practice, making changes to a component will often result in the 
need for new hardware, even if hardware changes were not required by
the design. 

> 
> > 
> > By also requiring changes to AAA infrastructure, it seems to me that ERP
> > deployment will be made more difficult than upgrades to the lower layer
> > (such as IEEE 802.11r), which appear to achieve a similar objective. 
> > This puts the ERX proposal at a competitive disadvantage, and makes it
> > unlikely that it will be widely deployed in its current form.
> 
> In the context of WLANs, I can understand your argument, but in the 
> context of foo wireless network, much of the work of 11r security, needs 
> to be repeated.  

[BA] The Problem Statement document made it seem that the focus was
solely on intra-media handoff, not inter-media.  Also, at various points
in the document, it appeared that link layer changes were being required.
So if the intent is for the solution to apply to inter-media handoff, then
that needs to be clarified and there may also be a need to address
potential backward compatibility issues. 

> 11r also requires firmware upgrades t

RE: My view of the IAOC Meeting Selection Guidelines

[Richard Shockey]

Thanks Bob ..as someone who had "questions", I find this a perfectly
reasonable and rational explanation.



>  
>  In the case of Dublin, the IAOC did understand that the sites
>  distance to Dublin wasn't ideal, but it was the only site we could
>  find in the area that meet the other requirements.  In this case, we
>  will try to ameliorate this issue by providing busses to downtown
>  Dublin.  In my view we are having a meeting in Dublin because we have
>  a host to wants to host the meeting there. I don't think we would
>  have done it there if there was not a host.
>  

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

Re: IETF 72 --> Dublin!

[Ray Pelletier]

All;
So, let me provide a little more background for the IAOC decision to 
hold IETF 72 in Dublin.


There were 3 venues under consideration - Geneva, Paris and Dublin. 

Each of these Cities had venues with available dates.  After 
pre-qualifying each, a meeting and tech qualification team visitied the 
Geneva and Dublin venues. An IETF meeting had previously been held at 
the Paris facility.


For the Geneva convention center under consideration, the hotel blocks 
were small and only one was within walking distance.  We would have 
needed to contract with approximately 10 hotels in order to meet minimum 
requirements of hotel block. Hotels were spread out, some in the city, 
while others (the larger hotels) were close to the airport.  Guest room 
rates were the most expensive of the three options.  Very likely that 
the meeting space costs could have been covered, but not the network 
infrastructure. No Host.


The Paris facility quoted the most expensive meeting space costs at over 
$200,000, as well as the most expensive food and beverage costs and 
second most expensive guest room rates.  Network infrastructure costs 
not covered. No Host.


The Dublin facility has a Host to cover meeting space costs, the Welcome 
Reception, as well as providing the network infrastructure for the 
meeting at its expense.  The Citywest HQ hotel has a large room block 
(1,000 on a peak night) and the best room rates of the three, as well as 
qualified meeting space and "from the technical perspective, City West 
is the recommended site" (input from the tech visit).  Biggest con - 20 
km from the city, which we will try to ameliorate by providing shuttle 
buses to the Temple Bar area of Dublin Monday through Thursday.


Dublin was recommended by the Meetings Subcommittee and selected by the 
IAOC.  It provides a good meeting facility and guest rooms under one 
roof, with a Host, and the least financial risk to the organizations.


If you want to see Dublin, and I recommend it, consider arriving 2 - 3 
days early, or staying after the meeting at a hotel downtown near 
Grafton Street and Trinity College.  The college even has dorm rooms 
available at very reasonable rates, if you don't mind roughing it a bit..


This meeting will have the highest attendance of the year. Many hotel 
reservations have already been made.  It's not too late to make yours.  
http://www.citywesthotel.com/


Ray Pelletier
IETF Administrative Director


Eliot Lear wrote:


I wrote:
 

It's Ray's job to make the call.  It's the IAOC's job to see that he 
does his job well.  I think Ray has at least earned the benefit of the 
doubt.  Perhaps this is best viewed retrospectively since contracts 
are signed?
   



I am told the following by someone who should know:

 

Actually, Ray really does NOT make these decisions in the absence of 
much debate and analysis within the IAOC and its various committees.
   



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


 

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

Re: O&M Directorate Review of draft-ietf-hokey-erx-09

[Lakshminath Dondeti]

Hi Bernard,

Many thanks for your review.  Please see inline for some thoughts and 
proposals for improvement of erx-09:

On 2/6/2008 4:07 PM, Bernard Aboba wrote:
> Review of draft-ietf-hokey-erx-09
> 
> I have reviewed this document as part of the Operations and Management
> directorate effort.  These comments were primarily written for the
> benefit of the O&M area directors.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> Detailed review comments are available here:
> http://www.drizzle.com/~aboba/EAP/erx-review.txt
> 
> An answer to typical O&M issues is included below:
> 
> 1. Is the specification complete?  Can multiple interoperable 
> implementations
> be built based on the specification?
> 
> There are a few areas of the document which are unclear to me, such as how
> AAA routing is accomplished, and how/when peers require the local realm, and
> if so, how it is to be obtained.  Also, clarity with respect to algorithm
> agility could be improved.  There are also some issues with respect to the
> required behavior of ERX peers and severs (use of normative language).
> 
> There are also situations in which multiple approaches can be chosen 
> (such as
> the various bootstrap options), without one being chosen as mandatory or
> default.  Choosing one approach would seem to be better.  
> 
> In my judgement, addressing these issues would improve the likelihood of
> being able to build multiple interoperable implementations.

I agree.  This has been brought up by Joe and we'll clarify the text. 
Some of the confusion has to do with the evolution of the draft; Vidya 
and I spent a good amount of time cleaning up around the WGLC time, but 
it appears that we can do better.

Pasi suggested adding a section on lower layer considerations.  That 
should help as well.

> 
> 2. Is the proposed specification deployable?  If not, how could it be
> improved?
> 
> Based on my reading of the document, it would appear that the ERX proposal
> requires changes to EAP peers, authenticators and servers, as well as 
> RADIUS
> clients, proxies and servers.  It also appears possible that changes to the
> lower layer protocols will be required in at least some cases, such as to
> make the local domain available to the peer.
> 
> Given my experience in designing and operating wireless networks, 
> deployments
> requiring changes only to peers and authenticators (but not servers or 
> RADIUS
> infrastructure) can take as long as 3-5 years to complete.  For example,
> WPA2 is still not universally deployed, even though the specification was
> finished in 2004.

WPA2 compliance requires hardware upgrade in many cases and that may 
have been the reason for the delay.  In addition, some enterprises found 
an alternative solution, i.e., IPsec VPNs, and so were not as motivated 
to move to WPA2.

In case of ERX, a firmware upgrade should be sufficient, which is much 
more easier.

> 
> By also requiring changes to AAA infrastructure, it seems to me that ERP
> deployment will be made more difficult than upgrades to the lower layer
> (such as IEEE 802.11r), which appear to achieve a similar objective. 
> This puts the ERX proposal at a competitive disadvantage, and makes it
> unlikely that it will be widely deployed in its current form.

In the context of WLANs, I can understand your argument, but in the 
context of foo wireless network, much of the work of 11r security, needs 
to be repeated.  11r also requires firmware upgrades to APs and STAs; 
furthermore, when physical threats to edge devices are considered, the 
R0-KH needs to be in a safer location and that may mean more L2 
architectural considerations.  The problems don't go away; they go to a 
different standards organization :).

When considering new wireless network standards, I think ERP along with 
the EMSK key hierarchy is better.  Keys for other usages can also be 
derived (the current alternative is static key provisioning).

> 
> 3.  Does the proposed approach have any scaling issues that could affect
> usability for large scale operation?
> 
> The proposed approach introduces state into NASes, as well as RADIUS
> proxies and servers.  This state is typically of two types:  routing
> state and key state.  In terms of key state storage, it would appear
> that the RADIUS server needs to store key state for each authenticated
> user within the Session-Id lifetime, regardless of where they are
> located.  Local ERX servers store state for all local users, regardless
> of their home realms. 
> 
> In order to scale to handle a large user population, additional RADIUS
> servers are typically deployed, going against a replicated backend
> store (such as an LDAP directory).  Similarly, additional RADIUS
> proxies are deployed to handle the forwarding load.

To support the concept of local ER servers, I agree that additional 
servers need to be deployed.  However, in case of ERP with home, no 
additional devices/har

Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard

[Lakshminath Dondeti]

Hi Joe,

Sorry for the delayed response.  I was without a functional laptop for 
the better part of the last 30 or so hours and so I am behind on a few 
things here.

Please see inline:

On 2/6/2008 10:00 PM, Joseph Salowey (jsalowey) wrote:
> Thanks for your quick response, comments inline: 
> 
>> -Original Message-
>> From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] 
>> Sent: Wednesday, February 06, 2008 1:03 AM
>> To: Joseph Salowey (jsalowey)
>> Cc: [EMAIL PROTECTED]; ietf@ietf.org
>> Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP 
>> Extensions for EAP Re-authentication Protocol (ERP)) to 
>> Proposed Standard
>>
>> Thanks for the review Joe.
>>
>> On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote:
>>> In reading this draft (-09 version) I came up with a few 
>> questions and
>>> comments:
>>>
>>> Section 3 -
>>>
>>> Section 3 is a bit confusing it seems that much of the text 
>> is section
>>> 3.1 (detailed description of exchanges) should go into section 3.0 
>>> because it seems that much of the process should be the 
>> same for local 
>>> or remote cases.  Currently it is difficult to really tell what 
>>> pertains to local, remote and both.
>>>
>>> It does not appear to be clear how the peer knows if it is 
>> in the "home"
>>> case or the "local" case, whether the network is capable of 
>> ERX (and 
>>> vice versa) or how the peer knows what key to use.  Perhaps 
>> I missed 
>>> this elsewhere in the document.
>> We worked to clarify this in the last revision.  I will make 
>> another pass at it while preparing v10 and run it by you 
>> (probably sometime tomorrow).
>>
>>> Section 4 -
>>>
>>> Section 4.1.1 duplicates text in
>>> internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt.   It really
>>> should not.  It should reference KDF functions instead of PRFs.  I 
>>> believe if you replace prf+ with KDF it would be fine.  Do 
>> you want to 
>>> use the naming defined in 
>>> internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you 
>>> specifying your own?  Are these key names really necessary? 
>>  They do 
>>> no appear to be used anywhere?
>> This is true.  I think we were trying overly hard to name 
>> everything (one of 4962 things?) and I realized earlier that 
>> we have a procedure to even name the rMSKs.  But, it is not 
>> clear whether the rMSK names will be used anywhere.
>>
>> I just sent that email about naming and so we should be able 
>> to clean this stuff up now if that is acceptable to everyone.
>>
> [Joe] If this is what we discussed I believe it will help, I will take a
> look at that. 

Yes, and I am going to poll some folks to make sure that is ok with them 
too.  Please review; if you want I can provide details (might ask Dan 
for some help) for your review.

> 
>> On duplication, it seems we have two strong opinions here.  
>> You are suggesting less duplication and Alan is suggesting 
>> more :).  I guess we may have actually achieved the (un)happy medium!
>>
>> My opinion is that we should have less duplication, perhaps 
>> to the extent you are suggesting, so the idea is to not have 
>> to update (when we
>> need) text in two different drafts.  That said, there are 
>> some usage specific properties to consider, specifically we 
>> are trying to specify crypto-agility in case of ERP and for 
>> those reasons, the derivations may need to be spelled out again.
>>
> [Joe] I think if we need to spell out the derivations in this document
> there is a problem.  This would indicate there is something wrong with
> the EMSK document that needs to be fixed. 

Yeah, I tend to agree.  I am talking to Alan soon and after that propose 
a direction here.

> 
>> In the next revision, I'll see what I can do to reduce the 
>> duplication (but before that I will talk to Alan to see what 
>> he wants).
>>
>>> Why such a long key label?
>> Which one?
>> "EAP Re-authentication Root [EMAIL PROTECTED]"?  I guess we could 
>> call it "EAP rRK" but that might be an abbreviation for 
>> something else in the future.  Please suggest another name 
>> :), but hopefully one that does not involve changing the 
>> entire document (I don't want to introduce errors with too 
>> many global changes).
>>
> [Joe] I suppose it doesn't matter much, it just seems that name is
> unnecessarily long.  The point of registering the labels with IANA is to
> avoid conflicts. 
> 
>>> Section 5 -
>>>
>>> Section 5.1
>>>
>>> What state are you referencing here? I don't think the 
>>> CalledStation-ID is what you want to reference, I believe RADIUS 
>>> routing is typically done with the username when EAP is 
>> used.  Why is 
>>> it only RECOMMENDED to maintain this state?  It seems 
>> either it is a MUST or it doesn't matter.
>>> In general authenticators do not do routing, AAA does routing.
>>> Authenticators copy the correct attributes from EAP into 
>> the correct 
>>> attributes in the AAA message.  This seems much more complicated
>>> (routing, multiple attributes TLVs e

My view of the IAOC Meeting Selection Guidelines

[Bob Hinden]

Hi,

I have been on the IAOC for about a year and wanted to explain my  
view how the IAOC decides to to have an IETF meeting in a specific  
location.  I thought this might be useful given the discussion about  
IETF72 in Dublin.  This is my personal view, not anything official  
from the IAOC.

First of all and for background, the IETF uses the revenue from the  
IETF meetings to pay for the meetings themselves and for the other  
fixed costs of running the IETF.  Meeting costs include meeting  
rooms, power, power strips, AV, cookies, drinks, continental  
breakfast, network, WLAN, IETF secretariat costs associated with the  
meeting, etc., etc.  The fixed costs of running the IETF include IETF  
secretariat, phone conferences, IAD salary, RFC Editor, IT  
infrastructure to host ietf.org, software tools development (those  
not done by our great volunteer developers!), etc., etc.  The total  
expenses are greater than the total revenue.  The ISOC pays for the  
difference (e.g., the deficit).  The budget information can be found  
at: http://iaoc.ietf.org/.  In round numbers total expenses are about  
$4M, revenue is about $2.5M, and the ISOC contributes about $1.5M.   
If it wasn't for the ISOC we would have a big problem.

I believe the IAOC is trying to keep this stable and not grow the  
deficit beyond what the ISOC is willing to subsidize.

We have two kinds of IETF meetings, hosted meetings and non-hosted  
meetings.  When we have a host (e.g., Alcatel-Lucent for IETF72) they  
pay for a lot of the meeting expenses.  This reduces our expenses and  
helps support the rest of the IETF operation.  Hosts usually cover  
the expenses for the network, circuits, NOC, social, t-shirts, etc.   
Sometimes they pay the IETF to do some of these things or pay for  
them directly.  When we have a non-hosted meeting, we pay for  
everything.  Not surprisingly the IAOC prefers to have hosted  
meetings.   In most cases the host has a preference for where they  
would like to host the meeting.  For example, the host for IETF72  
wanted the meeting to be in Dublin.  As long as the facilities in  
that location are acceptable we will do it at the host's preferred  
location.  Acceptable includes the right ratio of large and small  
meeting rooms, hotel room availability and price, ability to build a  
working WLAN network, availability of transit network connections,  
availability of other hotel rooms and restaurants, etc.  We won't go  
somewhere if we don't think we can have a successful meeting.  That  
means in a location where we think people are willing to travel to,  
get visas, hotel rooms are not $500 per night, etc.  We will be more  
flexible on some of these things to meet the hosts desire for a  
specific location, but not to the point where don't think the meeting  
would be successful.

In the case of Dublin, the IAOC did understand that the sites  
distance to Dublin wasn't ideal, but it was the only site we could  
find in the area that meet the other requirements.  In this case, we  
will try to ameliorate this issue by providing busses to downtown  
Dublin.  In my view we are having a meeting in Dublin because we have  
a host to wants to host the meeting there. I don't think we would  
have done it there if there was not a host.

I hope this helps the IETF community to understand the decision  
process the IAOC uses.  We are trying hard to book meetings as far  
out in the future as possible, maintain a good balance of North  
America, Europe, and Asia, and keep the IETF financially afloat.  If  
we had some other significant source of income besides meeting  
revenue, there would be more flexibility, but until that happens we  
will continue to have a preference for hosted meetings.

Bob


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