RE: joining the IETF is luxury Re: 70th IETF - Registration
Yao, I sympathize. However, there are other things for you to consider: 1) There are available discounts - a) the price for full time students is significantly lower (although several times what it has been in the past) and requires only that you can produce a student ID card to show that you are a full-time student b) the IETF offers "fellowships" in certain cases for people who cannot otherwise attend. 2) "Membership" in the IETF is precisely what you do not need, nor can you get it right now. The right to be a participant in the IETF comes for free, and is a thing you can lose, rather than a thing you have to gain. Attending meetings is what costs money, and you don't absolutely have to attend meetings (though it is much more difficult to participate effectively if you don't). 3) An annual membership fee - as applied in several other SDOs - can actually be a larger "threshhold" that must be overcome by the small company because (without small company discounts - which are resented by those larger companies that don't qualify) the fee will typically be significantly higher than the attendance fee total (for a year's worth of IETF meetings) and is nearly always insufficient to cover meeting cost. This is because an annual fee is usually not strongly correlated to the number of attendees that a company will send. That means you will pay an additional fee (often slightly more than half of the IETF attendance fee) for each attendee. All of that said, however, it is my impression (likely exaggerated - without actually looking into it) that the meeting fees have climbed by $50 each meeting for the last several meetings. The perception is that the IETF fees may be getting out of control, and I am deeply concerned that a person wishing to attend - but unable to determine if they will be able to in advance - will soon have to pay more than a thousand US dollars to do so. It is an interesting question what changes are likely to occur in the way the IETF does business if the only people who can attend are: o those people who are sufficiently destitute as to qualify for the discounted rate (without being so destitute that they cannot actually pay even that rate), o the very small number who are so wealthy that they can afford to attend for completely altruistic purposes (betterment of mankind, etc.), o those professionals who are funded for support of one or more specific commercial or agency agendas. -- Eric Gray Principal Engineer Ericsson > -Original Message- > From: YAO [mailto:[EMAIL PROTECTED] > Sent: Friday, September 07, 2007 7:03 AM > To: IETF Secretariat; ietf@ietf.org > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: joining the IETF is luxury Re: 70th IETF - Registration > > > the early-bird > > price of USD 700.00. > > > > After Early-Bird cutoff - USD 850.00 > > so expensive. > > > joining the IETF is luxury for individual. > > IETF should not take the money from the individual pocket. > and should absorb more finance support from big company > > Why is it so expensive? > > IETF lives in more luxury hotel? > IETFer eat more than before? > Meeting room is more expensive? > Salary is higher? > > the price of ticket to join the IETF is not to encourage the > individual with little dollars and small company to join the IETF. > > Raising the ticket price is to raise the doorsill of IETF to > exclude those who want to join but not enough dollars. > > it seems that IETF is becoming a wealthy club. > > > > > > > > > > > - Original Message - > From: "IETF Secretariat" <[EMAIL PROTECTED]> > To: "IETF Announcement list" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, September 07, 2007 6:30 AM > Subject: 70th IETF - Registration > > > > 70th IETF Meeting > > Vancouver, BC, Canada > > December 2-7, 2007 > > > > Registration is now open for the 70th IETF Meeting! > > > > You can register on line at: > > http://www3.ietf.org/meetings/70-IETF.html > > > > REGISTRATION INFORMATION: > > Early-Bird Registration - USD 700.00 > > > > If you register and pay for your attendance to the IETF-70 > before NOON ET > > (17:00 UTC/GMT), Friday, 23 November 2007, you will pay the > early-bird > > price of USD 700.00. > > > > After Early-Bird cutoff - USD 850.00 > > > > You can still register and pay online at USD 850.00 until 17:00 > > Canada/Pacific Time Friday 30 November 2007 (01:00 UTC/GMT, > Saturday 1 > > December 2007). > > > > Full-time Student Registrations - USD 250.00 > > > > Full-time students with proper ID are eligible to receive a > special USD > > 250.00 student rate. Student rate is not subject to any late-fees. >
Re: joining the IETF is luxury Re: 70th IETF - Registration
Adrian Farrel wrote: We shall see, but I don't know that putting up the price necessarily fixes the registration income issue. You only have to deter a relatively small proportion of attendees to wipe out the increase in charge. I assume that the converse is also being applied: viz. cutting meeting costs. It's hard for us oiks to tell because we only see: - registration fee - breakfasts/cookies Anyway, registration is still the smallest component of attendance for me. Hotel and travel are still bigger problems, and I continue to wonder whether we could increase attendance (and hence registration income) by facilitating cheaper accommodation and travel. It is easy to rationalize away Yao's concerns, especially for old-timers. The overall cost of meeting attendance keeps going up, and $700 to attend the IETF is not a small amount of money. Simple economics tells us that the number of attendees will continue to go down, the higher the costs get. One way to deal with the cost problem is to just ignore it, and focus instead on making IETF week as valuable as possible for as many people as possible. I think there has been a lot of progress in this area (Sunday tutorials, Wednesday beer night, etc. ;-) (I wonder how much the costs would go down if the meeting ended at 4PM Thursday instead of noon on Friday, and there was only one plenary night on Wednesday.) Cheers, Adrian Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
On Fri, Sep 07, 2007 at 07:03:03PM +0800, YAO <[EMAIL PROTECTED]> wrote a message of 71 lines which said: > the price of ticket to join the IETF is not to encourage the > individual with little dollars and small company to join the IETF. I agree. > Raising the ticket price is to raise the doorsill of IETF to exclude > those who want to join but not enough dollars. Yes, but a possible solution for them is in the attached message. > it seems that IETF is becoming a wealthy club. When the meeting takes place in Chicago, the costs of travel, hotel and stay much exceed the cost of the meeting itself, at least for me. --- Begin Message --- Dear Colleagues, The Internet Society has announced that it is seeking applications for the next round of the ISOC Fellowship to the IETF program. The program offers engineers from developing countries fellowships that fund the cost of attending an IETF meeting. Individuals from developing countries who have been following and participating in the work of the IETF remotely -- but have not yet attended an IETF meeting in person -- are encouraged to apply for the Fellowship. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 70 being held in Vancouver, Canada on December 2-7 2007, and * IETF 71 being held in Philadelphia, USA on March 9-14, 2008 Up to five fellowships will be awarded for each IETF meeting. Full details on the ISOC Fellowship to the IETF, including how to apply, are located on the ISOC website at : http://www.isoc.org/educpillar/fellowship The application deadline both IETF meetings has been extended until 14 September 2007. The Internet Society formally launched the ISOC Fellowship to the IETF program in January 2007 after successfully piloting the program during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Fifteen individuals from 12 countries have participated in the program since its inception. If you have questions, please do not hesiate to contact Karen Rose <[EMAIL PROTECTED]> or Mirjam Kuehne <[EMAIL PROTECTED]>. Kind Regards, Mirjam Kuehne ISOC ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --- End Message --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
David, all, While Lars (as AD) is the final authority (e.g., on whether "it is recommended" above is strong enough language), I'd like to add a couple of sentences to recognize "dedicated network that hosted a NetFlow implementation" as a common case (to help out the network administrators who actually have to make this work): An important example of an explicitly provisioned managed network for IPFIX is use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth. OK, thanks, added. I copy below the current version of the UDP section. Let me know if you agree with it. The last changes are the beginning of the section. One last open point is whether the following text, or something similar, should be added or not: As recommended in [I-D.ietf-tsvwg-udp-guidelines] an application SHOULD NOT send UDP messages that result in IP packets that exceed the MTU of the path to the destination and SHOULD enable UDP checksums (see sections 3.2 and 3.4 of [I-D.ietf-tsvwg-udp-guidelines] respectively). thanks, Elisa --- 6.2. UDP UDP is useful in simple systems where an SCTP stack is not available, and where there is insufficient memory for TCP buffering. However, UDP is not a reliable transport protocol, and IPFIX messages sent over UDP might be lost as with partially-reliable SCTP streams. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties: o A dedicated network, o within a single administrative domain, o where SCTP is not available due to implementation constraints, o and the collector is as close as possible to the exporter. Note that because UDP itself provides no congestion control mechanisms, it is recommended to use UDP transport only on managed networks, where the network path has been explicitly provisioned for IPFIX traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. An important example of an explicitly provisioned managed network for IPFIX is use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth. Since IPFIX assumes reliable transport of templates over SCTP, this necessitates some changes for IPFIX template management over UDP. Templates sent from the Exporting Process to the Collecting Process over UDP MUST be resent at regular time intervals; these intervals MUST be configurable. We recommend a default Template resend time of 10 minutes, configurable between 1 minute and 1 day. Note that this could become an interoperability problem, e.g. if an Exporter re-sends Templates once per day, while a Collector expires Templates hourly, then they may both be IPFIX-compatible, but not be interoperable. Retransmission time intervals that are too short waste bandwidth on unnecessary template retransmissions. On the other hand, time intervals that are too long introduce additional costs or risk of data loss by potentially requiring the Collector to cache more data without having theTemplates available to decode it. To increase reliability and limit the amount of potentially lost data the Exporting Process MAY resend additional templates using a packet- based schedule. In this case Templates are resent depending on the number of packets sent. Similarly to the time interval, resending a Template every few packets introduces additional overhead while resending after a lange amount of packets have already been sent means high costs due to the data caching and potential data loss. We recommend a default Template resend interval of 20 packets, configurable between 1 and 1000 packets. Note that a sufficiently small resend time or packet interval may cause a system to become stuck, continually re-sending templates. e.g., if the resend packet interval is 2 (i.e., templates are to be sent in every other packet) but more than two packets are required to send all the templates, then the resend interval will have expired by the time the templates have been sent, and templates will be sent continuously - possibly preventing any data from being sent at all. Therefore the Template resend intervals should be considered from the last data packet, and should not be tied to specific sequence
Re: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
Lars, Paul, David,
Lars Eggert wrote:
Note that we're not singling out IPFIX here. The forthcoming revisions
to the syslog documents, for example, will have the following statement
("TLS" is "TLS over TCP"):
Because syslog can generate unlimited amounts of data, transferring this
data over UDP is generally problematic, because UDP lacks congestion
control mechanisms. Congestion control mechanisms that respond to
congestion by reducing traffic rates and establish a degree of fairness
between flows that share the same path are vital to the stable operation
of the Internet [RFC2914]. This is why the syslog TLS transport is
REQUIRED to implement and RECOMMENDED for general use.
The only environments where the syslog UDP transport MAY be used as an
alternative to the TLS transport are managed networks, where the network
path has been explicitly provisioned for UDP syslog traffic through
traffic engineering mechanisms, such as rate limiting or capacity
reservations. In all other environments, the TLS transport SHOULD be
used.
I believe a similar statement for IPFIX would be appropriate.
we currently have the following statement for IPFIX/UDP:
---
UDP is useful in simple systems where an SCTP stack is not available,
and where there is insufficient memory for TCP buffering.
However, UDP is not a reliable transport protocol, and IPFIX messages
sent over UDP might be lost as with partially-reliable SCTP streams.
UDP is not the recommended protocol for IPFIX and is intended for use
in cases in which IPFIX is replacing an existing NetFlow
infrastructure, with the following properties:
o A dedicated network,
o within a single administrative domain,
o where SCTP is not available due to implementation constraints,
o and the collector is as close as possible to the exporter.
---
Would the addition of the text below be an acceptable solution?
---
Note that because UDP itself provides no congestion control
mechanisms, it is recommended to use UDP transport only on managed
networks, where the network path has been explicitly provisioned for
IPFIX traffic through traffic engineering mechanisms, such as rate
limiting or capacity reservations.
---
thanks,
Elisa
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
See the recent email on ietf-announce: Begin forwarded message: From: "ext Kurt Erik Lindqvist" <[EMAIL PROTECTED]> Date: September 4, 2007 17:13:49 GMT+03:00 To: [EMAIL PROTECTED] Cc: IAOC Jabberr <[EMAIL PROTECTED]>, ietf@ietf.org, "IESG \(\(E-mail\) \)" <[EMAIL PROTECTED]> Subject: Vancouver meeting fees The community was told at the IETF 69 Wednesday Evening Plenary Session to expect a meeting fee increase for IETF 70 in Vancouver. The purpose of this message it to advise you of the amount of the increase and provide the reasons for the increase. We are into September, which means two-thirds of 2007 is now behind us. We know what our IETF expenses have been year-to-date, and we can project our expenses for the rest of 2007. We also know that our meeting revenue for the first two meetings have been below expectation as a result of attendance averaging one hundred fewer attendees per meeting than anticipated. With this information, we can see that the operations will incur a shortfall of more than $200K if we do not take actions for the Vancouver meeting. Accordingly, the IAOC will increase the IETF meeting fee for the Vancouver meeting by $100. By taking this action, our deficit for all of 2007 should be reduced by almost half. To address the remaining deficit, we will continue to work with the Internet Society staff in their efforts to attract additional host and sponsorship support for the Vancouver meeting and to reduce expenses wherever possible without impacting the meeting and experience of the attendees. To date, we have received generous contributions from Microsoft and Telus, which are appreciated, but are not enough to make Vancouver a fully hosted meeting. With respect to what happens in 2008, please note that the IAOC has not made any decisions yet about meeting fees for next year, but we will be actively evaluating the cost of delivering essential services, looking at new approaches to raise additional revenue, and taking another look at future meeting locations with the goal of increasing meeting attendance. More financial information is available at: http://iaoc.ietf.org/ budget.html. In particular see Budget Overview and Year End Forecast. As a final point of information, please be advised that registration for the Vancouver meeting will begin this week. Kurtis Lindqvist IAOC Chair smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
joining the IETF is luxury Re: 70th IETF - Registration
the early-bird > price of USD 700.00. > > After Early-Bird cutoff - USD 850.00 so expensive. joining the IETF is luxury for individual. IETF should not take the money from the individual pocket. and should absorb more finance support from big company Why is it so expensive? IETF lives in more luxury hotel? IETFer eat more than before? Meeting room is more expensive? Salary is higher? the price of ticket to join the IETF is not to encourage the individual with little dollars and small company to join the IETF. Raising the ticket price is to raise the doorsill of IETF to exclude those who want to join but not enough dollars. it seems that IETF is becoming a wealthy club. - Original Message - From: "IETF Secretariat" <[EMAIL PROTECTED]> To: "IETF Announcement list" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, September 07, 2007 6:30 AM Subject: 70th IETF - Registration > 70th IETF Meeting > Vancouver, BC, Canada > December 2-7, 2007 > > Registration is now open for the 70th IETF Meeting! > > You can register on line at: > http://www3.ietf.org/meetings/70-IETF.html > > REGISTRATION INFORMATION: > Early-Bird Registration - USD 700.00 > > If you register and pay for your attendance to the IETF-70 before NOON ET > (17:00 UTC/GMT), Friday, 23 November 2007, you will pay the early-bird > price of USD 700.00. > > After Early-Bird cutoff - USD 850.00 > > You can still register and pay online at USD 850.00 until 17:00 > Canada/Pacific Time Friday 30 November 2007 (01:00 UTC/GMT, Saturday 1 > December 2007). > > Full-time Student Registrations - USD 250.00 > > Full-time students with proper ID are eligible to receive a special USD > 250.00 student rate. Student rate is not subject to any late-fees. > Students will also be able to register on-site at the special student > rate. Failure to provide valid student ID on-site will revoke the special > student status. > > CANCELLATION: > > The cut-off for registration cancellation is Monday, 26 November at 17:00 > ET-US (22:00 UTC/GMT). Cancellations are subject to a 10% (ten percent) > cancellation fee if requested by that date and time. > > ON-SITE REGISTRATION: > > You can register onsite at the meeting in Vancouver, BC, Canada starting > Sunday, 2 December at 12:00 noon (local time). > > The IETF meetings start Monday morning and run through Friday lunchtime, > with late scheduling changes. Most training session take place on Sunday > afternoon 2 December. Participants should plan their travel accordingly. > > The IETF Secretariat > > > > ___ > IETF-Announce mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ietf-announce >___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [tsv-dir] Re: Transport Directorate review of draft-ietf-ipfix-implementation-guidelines-06.txt
Elisa,
> > Note that we're not singling out IPFIX here. The forthcoming
revisions
> > to the syslog documents, for example, will have the following
statement
> > ("TLS" is "TLS over TCP"):
> >
> >Because syslog can generate unlimited amounts of data,
transferring this
> >data over UDP is generally problematic, because UDP lacks
congestion
> >control mechanisms. Congestion control mechanisms that respond to
> >congestion by reducing traffic rates and establish a degree of
fairness
> >between flows that share the same path are vital to the stable
operation
> >of the Internet [RFC2914]. This is why the syslog TLS transport
is
> >REQUIRED to implement and RECOMMENDED for general use.
> >
> >The only environments where the syslog UDP transport MAY be used
as an
> >alternative to the TLS transport are managed networks, where the
network
> >path has been explicitly provisioned for UDP syslog traffic
through
> >traffic engineering mechanisms, such as rate limiting or capacity
> >reservations. In all other environments, the TLS transport SHOULD
be used.
> >
> > I believe a similar statement for IPFIX would be appropriate.
>
> we currently have the following statement for IPFIX/UDP:
>
> ---
> UDP is useful in simple systems where an SCTP stack is not
available,
> and where there is insufficient memory for TCP buffering.
> However, UDP is not a reliable transport protocol, and IPFIX
messages
> sent over UDP might be lost as with partially-reliable SCTP
streams.
> UDP is not the recommended protocol for IPFIX and is intended for
use
> in cases in which IPFIX is replacing an existing NetFlow
> infrastructure, with the following properties:
>
> o A dedicated network,
>
> o within a single administrative domain,
>
> o where SCTP is not available due to implementation constraints,
>
> o and the collector is as close as possible to the exporter.
> ---
>
> Would the addition of the text below be an acceptable solution?
>
> ---
> Note that because UDP itself provides no congestion control
> mechanisms, it is recommended to use UDP transport only on managed
> networks, where the network path has been explicitly provisioned for
> IPFIX traffic through traffic engineering mechanisms, such as rate
> limiting or capacity reservations.
> ---
While Lars (as AD) is the final authority (e.g., on whether "it is
recommended" above is strong enough language), I'd like to add a
couple of sentences to recognize "dedicated network that hosted
a NetFlow implementation" as a common case (to help out the
network administrators who actually have to make this work):
An important example of an explicitly provisioned managed
network for IPFIX is use of IPFIX to replace a functioning
NetFlow implementation on a dedicated network. In this
situation, the dedicated network should be provisioned in
accordance with the NetFlow deployment experience that flow
export traffic generated by monitoring an interface will
amount to 2-5% of the monitored interface's bandwidth.
Thanks,
--David
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED]Mobile: +1 (978) 394-7754
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
YAO writes: > joining the IETF is luxury for individual. [...] > it seems that IETF is becoming a wealthy club. I agree it's a shame, but I disagree with your conclusions. The IETF isn't a membership organization. You don't pay any dues to belong to it, and there's no requirement to go to any meeting in order to be a full participant. The official business of the IETF is still conducted -- for free and without discrimination -- on open mailing lists. I hope it always remains that way. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
We shall see, but I don't know that putting up the price necessarily fixes the registration income issue. You only have to deter a relatively small proportion of attendees to wipe out the increase in charge. I assume that the converse is also being applied: viz. cutting meeting costs. It's hard for us oiks to tell because we only see: - registration fee - breakfasts/cookies Anyway, registration is still the smallest component of attendance for me. Hotel and travel are still bigger problems, and I continue to wonder whether we could increase attendance (and hence registration income) by facilitating cheaper accommodation and travel. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
James Carlson <[EMAIL PROTECTED]> writes: > YAO writes: >> joining the IETF is luxury for individual. > [...] >> it seems that IETF is becoming a wealthy club. > > I agree it's a shame, but I disagree with your conclusions. The IETF > isn't a membership organization. You don't pay any dues to belong to > it, and there's no requirement to go to any meeting in order to be a > full participant. > > The official business of the IETF is still conducted -- for free and > without discrimination -- on open mailing lists. I hope it always > remains that way. Physical attendance is a requirement to be able to participate in the NOMCOM process in the IETF, so I would disagree that you don't have to attend meetings in order to be a full participant. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ISOC Fellowship to the IETF - seeking applicants for IETF 70 and IETF 71
Dear Colleagues, The Internet Society has announced that it is seeking applications for the next round of the ISOC Fellowship to the IETF program. The program offers engineers from developing countries fellowships that fund the cost of attending an IETF meeting. Individuals from developing countries who have been following and participating in the work of the IETF remotely -- but have not yet attended an IETF meeting in person -- are encouraged to apply for the Fellowship. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 70 being held in Vancouver, Canada on December 2-7 2007, and * IETF 71 being held in Philadelphia, USA on March 9-14, 2008 Up to five fellowships will be awarded for each IETF meeting. Full details on the ISOC Fellowship to the IETF, including how to apply, are located on the ISOC website at : http://www.isoc.org/educpillar/fellowship The application deadline both IETF meetings has been extended until 14 September 2007. The Internet Society formally launched the ISOC Fellowship to the IETF program in January 2007 after successfully piloting the program during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Fifteen individuals from 12 countries have participated in the program since its inception. If you have questions, please do not hesiate to contact Karen Rose <[EMAIL PROTECTED]> or Mirjam Kuehne <[EMAIL PROTECTED]>. Kind Regards, Mirjam Kuehne ISOC ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
On Sep 7, 2007, at 12:09 PM, Glen Zorn wrote: ... [gwz] (I wonder how much the costs would go down if the meeting ended at 4PM Thursday instead of noon on Friday, and there was only one plenary night on Wednesday.) [gwz] [gwz] Probably not at all. I only have experience with sponsoring one IETF, but in that case (& I believe generally) the meeting rooms were provided gratis. There are some perks to guaranteeing a hotel the rental of 1000+ rooms for a week or so... In the US and Canada, the catering charge pays for the meeting rooms. Elsewhere, meeting rooms are generally charged for and catering is correspondingly cheaper. In either case, there is a charge for per day. These charges are complicated and it can be misleading to just focus on one piece and not the whole package. One thing that could be done is to charge separately for breakfast, which is relatively expensive (but a pretty good bargain per attendee) and which not everyone uses. Regards Marshall Cheers, Adrian Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: joining the IETF is luxury Re: 70th IETF - Registration
*> *> The official business of the IETF is still conducted -- for free and *> without discrimination -- on open mailing lists. I hope it always *> remains that way. *> Unfortuantley, a lot of experience in the Internet community has shown us that it is very difficult to reach actual DECISIONS on mailing lists, although they work fine for DISCUSSIONs. Maybe we need an online "hum" mechanism to reach mailing-list consensus (but authentication then becomes a problem). Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: joining the IETF is luxury Re: 70th IETF - Registration
Adrian Farrel wrote: >> We shall see, but I don't know that putting up the price >> necessarily fixes the registration income issue. You only >> have to deter a relatively small proportion of attendees to >> wipe out the increase in charge. >> >> I assume that the converse is also being applied: viz. >> cutting meeting costs. It's hard for us oiks to tell because we only >> see: >> - registration fee >> - breakfasts/cookies >> >> Anyway, registration is still the smallest component of attendance >> for me. Hotel and travel are still bigger problems, and I continue >> to wonder whether we could increase attendance (and hence >> registration income) by facilitating cheaper accommodation and >> travel. Like Adrian the associated costs are a factor for myself, the meeting fee itself is very reasonable compared to other conferences. The biggest factor for me is the time. I don't seem to have the time to contribute enough even on the online possibilities let alone attend meetings. I suspect that when I will have the time, the expense will not be a factor but by then the willingness to participate will have gone. At least at present everyone has the possibility of putting forward input either online or in person with the IETF, it is one of the main attractions I see with the organisation. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
