Subject: My view of the IAOC Meeting Selection Guidelines

From: Bob Hinden <[email-masked]>
Date: Fri, 8 Feb 2008 10:29:52 +0200

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
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 8 Feb 2008 11:27:01 -0500

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Feb 2008 21:30:29 +0100

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

> The budget information can be found

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
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Feb 2008 13:51:38 -0800

On Feb 8, 2008, at 12:30 PM, Iljitsch van Beijnum wrote:
> 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
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Lawrence Rosen" <[email-masked]>
Date: Fri, 8 Feb 2008 19:00:46 -0800

> The IETF's phone budget for 2008 is

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. 

> number more in five digits, and asking in each case how to change N

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

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 9 Feb 2008 09:06:38 -0500

On Feb 8, 2008, at 3:30 PM, Iljitsch van Beijnum wrote:

> go down.

Or the IETF will have to start charging for non-meeting services
currently provided gratis to participants.

These are primarily document related expenses.

Regards
Marshall

> (I'm assuming non meeting fee fund raising is already maxed
> out.)
>

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 9 Feb 2008 09:38:32 -0500

And this coming from the Standards body that has developed SIP ...
unbelievable. I don't think I'm going to listen to any more arguments about
IPv6 experiments during Plenary's any more.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Feb 2008 13:46:42 -0800

> aren't sufficiently baked just yet to pass aromas around.

What follows is a topic that too-easily invites injudicious comment, so I'll 
preface by saying that I'm posting this publicly only as a means of soliciting 
public comment on one particular cost:  RFC draft proofreading.

After some years of hiatus, I again started working with the RFC Editor on the 
details of publishing some documents.  So I was surprised to experience the kind 
offices of professional proofreading.

My own assessment is that it has improved the documents. The proofreaders have 
their own views of what is correct and that sometimes requires discussion, but 
mostly I consider their intervention to have a positive impact.

The question to me -- and which I am posing to everyone else -- is whether the 
improvement is worth the cost?

Professional proofreading is not cheap.

While we can easily cite the dangers of badly written specifications, I'll also 
note that we got along for a couple of decades without this extra service. IETF 
documents that get to the editor have gone through extensive reviewing. We can, 
I think easily rely on that fact, since we successfuly did so for 25+ years.

I'll also suggest that any strategic problems that a specification might suffer 
cannot be fixed with professional proofreading.

Thoughts?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 10 Feb 2008 00:28:15 +0100

> IPv6 experiments during Plenary's any more.

Gizmo Project uses SIP and has free conference calling:

http://gizmoproject.com/conf-calling.html

Not sure what the limitations are, though.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: SM <[email-masked]>
Date: Sat, 09 Feb 2008 13:56:46 -0800

>video system for technical meetings -- open source, of course.

In-person meetings do not have the same dynamics as web 
meetings.  People would react differently if they were interacting 
through a voice and video system.  The aim of a meeting is usually to 
have all the people in one place away from the "distractions" of 
their regular work.

>professionals got together electronically.

When technical professionals get together electronically, they have 
flame wars. :-)

Regards,
-sm

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 10 Feb 2008 13:17:25 -0500

>> video system for technical meetings -- open source, of course.

Having thought about this a little, I think that the real question  
is, what is the cost of a failed IESG meeting.
(Or IAB or IAOC or...)

It is not just a question of doing it cheaper. It is a question of  
doing it cheaper and not impacting the work done by the IETF.

I could set up, and I suspect various other readers of the list could  
set up, a phone bridge with bandwidth for a few thousand US $ per  
year, maybe less, maybe even for "free." There would be, however, a  
significant chance for failures :

- That some participants would not be able to get in, if say they had  
no access to IP. (Now, there are local numbers and if all else fails  
they can be called by the teleconference vendor.)

- That the entire call would fail, say due to a failure of the bridge  
or of a Nic card. (Now, if that happened, we would fire the vendor,  
as they should have fully redundant services.)

I would regard any _free_ service has having a substantial  
probability of failure, given enough usage over time. It costs money  
to protect against failure.

I would give a single IESG call a rough implied value of, say, $  
40,000 (that would equate the year's worth of IESG calls to ~ $ 1  
million USD, which seems the right order of magnitude given the total  
budget, and works out to about $ 600 per AD per hour). I know how  
hard it would be to reschedule one (which I would put in the "not  
going to happen" category), and I strongly suspect the IESG would be  
intolerant to even one missed call. Note that this rough valuation  
implies that one missed IESG call would be worth roughly the entire  
IESG Telecoms budget for the year.

So, the failure rate needs to be << 4 % (one call per year) to make a  
cheaper service truly worthwhile. The solution might be, set up  
several cheaper or free services, round robin between them, and if  
one fails, go to another.

(I set up the rough valuations, and focus on the IESG, merely to  
frame the debate, but similar things could be sad about the other  
phone charges.)

Regards
Marshall

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 10 Feb 2008 20:16:10 +0000

On Sun, 10 Feb 2008 13:17:25 -0500

> doing it cheaper and not impacting the work done by the IETF.

And there have indeed been problems; I recall a fair number of IESG
calls where we had to get a human operator to troubleshoot some major
voice quality problem.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 09 Feb 2008 08:39:13 -0800

> IPv6 experiments during Plenary's any more.

Henning Schulzrinne and Mark Handley (ietf participants) designed SIP. 
IETF (particants) standardized and extended SIP. A lot of work brought 
to the ietf isn't used by it's participants.

>>  The IETF's phone budget for 2008 is

So, it ought to be feasible to achieve substantial cost savings while 
supporting legacy pstn interconnection. There are an number of players 
in this space it's just a question of evaluating them on their merits or 
rolling your own if they prove to be inadequate.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 10 Feb 2008 21:46:05 -0000

Hi Dave,

Readability is valuable. Of course, it should be the case that WG last call, 
WG chair review, and IESG review produce something good and clean, but 
history shows that this is not the case. Indeed, it is unreasonable to 
expect participation at this level by non-native speakers without some 
assistance.

I hope that we are using copyediting services not proofreading. The skills 
are different, but the costs are probably similar.

As a WG chair, I see a fair number of I-Ds come back from the RFC Editor 
process. Some have been cleaned (a bit like running lint over code) and 
sometimes (one in five?) a small issue of interpretation pops out. Of 
course, I don't know whether this shows up in the copyedit or from the RFC 
Editor work.

It might be valuable to consider how to constrain the copyeditor's input. 
Assuming that the first 90% of the work takes the first 90% of the time, and 
the other 10% of the work takes the other 90% (sic) of the time, there may 
be some financial savings to be made by directing the copyeditor quite 
strongly.

Cheers,
Adrian

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: "IAOC" <[email-masked]>; "ietf" <[email-masked]>
Sent: Saturday, February 09, 2008 9:46 PM
Subject: RFC Editor costs - Proofreading (was Re: My view of the IAOC 
MeetingSelection Guidelines)

---

From: Dan York <[email-masked]>
Date: Mon, 11 Feb 2008 11:55:54 -0500

I'm with Richard on this one.  I have to think that among the many  
companies that make up the IETF there exists a couple with  
conferencing bridges that can support SIP endpoints! ;-)  Can we move  
some of this conversation in the bill below onto the Internet using  
systems where our costs essentially go to $0?  (Obviously we still  
need to communicate to non-wired folks across the PSTN, such as event  
location facilities, etc.)

Or is the issue really that, as Jonathan Christensen of Skype states,  
the original vision of SIP for rich communications remains  
"unrealistic"[1]?  That as a practical matter we *can't* use SIP  
endpoints due to NAT traversal, security issues, federation/trust  
issues, etc?

My 2 cents,
Dan

P.S. How many folks out there have phones (hard or soft) from which  
they can place calls to other random SIP endpoints?  (I do, but also  
realize I'm in a minority.)

[1] http://blogs.voxeo.com/speakingofstandards/2008/02/09/ecomm2008- 
jonathan-christensen-of-skype-and-the-unreal-vision-of-sip/

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859    http://www.voxeo.com
SIP: [email-masked]   Skype: danyork
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: [email-masked]
Date: 11 Feb 2008 17:19:23 -0000

>realize I'm in a minority.)

Probably enough of us.

I agree that SIP conferencing doesn't work perfectly, but POTS
conferencing, even rather high priced POTS conferencing, is often
pretty bad, particularly when people are on cell phones or calls over
other noisy or slow links.  It's certainly worth a few experiments to
see if a $0 conference is really worse than a $1000 conference.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Feb 2008 19:21:48 +0200

On 2008-2-11, at 18:55, ext Dan York wrote:
> Can we move some of this conversation in the bill below onto the  
> Internet using systems where our costs essentially go to $0?   
> (Obviously we still need to communicate to non-wired folks across  
> the PSTN, such as event location facilities, etc.)

I do hope we can reduce costs, but the requirements that Marshall  
described are valid:

   - need to be able to call in from the PSTN, worldwide
     (Many of us call in from hotels, airports, trains, etc.)

   - need to be able to have an operator dial out to someone
     (Calling in form a hotel sometimes just doesn't work.)

   - need to be able to get technical support during the call
     (Audio issues, lines getting dropped, calling out, etc.)

There's a baseline cost associated with all that 24/7 support. Having  
some people call in over IP vs. the PSTN may save some money, but I  
doubt that the savings would be dramatic.

If saving money is the issue and not dogfood eating, an alternative  
proposal may be to rotate the calls among the corporate phone bridges  
of willing I* folks. (This is what we're doing for various area and WG  
telechats, anyhow.)

Lars

---

From: <[email-masked]>
Date: Mon, 11 Feb 2008 17:47:26 -0000

>	P.S. How many folks out there have phones (hard or soft) from
which they can 
> place calls to other random SIP endpoints?  (I do, but also realize
I'm in a minority.)

The only reason that the average corporate desktop phone can make long
distance calls to anywhere in the world is that their local PABX
supports routing those calls.

In the same way, any arbitrary SIP phone (hard or soft) can also make
calls to arbitrary SIP endpoints if they are connected to a SIP PABX
that supports routing the calls. See <http://www.asterisk.org> for the
leading open-source SIP PABX software.

Even if the IETF needs something that Asterisk can't do today, it would
be wise to implement it anyway so that Asterisk developers can see the
need.

--Michael Dillon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 11 Feb 2008 18:10:36 +0000

On Mon, 11 Feb 2008 19:21:48 +0200
Lars Eggert <[email-masked]> wrote:

> There's a baseline cost associated with all that 24/7 support.
> Having some people call in over IP vs. the PSTN may save some money,
> but I doubt that the savings would be dramatic.

Precisely.  The issue is a *service*, not a technology.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Feb 2008 19:25:51 +0100

> realize I'm in a minority.)

Unfortunately, SIP providers on average only seem interested in  
providing "last mile over the internet" service, which gives you the  
downsides of the IP network AND the downsides of the POTS network only  
to save a few cents a minute.

It seems to be a well-kept secret that you don't actually need a SIP  
server to receive (or make) calls over the internet: for a single user  
under a (sub-) domain, a few DNS records are all that's required. I've  
set things up so that I can be called using SIP at my email address,  
but I rarely remember to run the client because nobody ever does...
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Feb 2008 10:53:34 -0800

> improvement is worth the cost?

Speaking strictly for myself...

Over the past year or so, while we have been using this service, the  
RFC Editor has been able to clean up the backlog. To my knowledge, we  
have made no other changes to the RFC Editor's office. Speaking  
absent data - the RFC Editor's office is largely a black box to me -  
that suggests that improving the quality of what goes in reduces the  
time it takes to produce what comes out.

Now, that brings several possibilities to mind. One is to suggest  
widening the pre-processing effort. Another is to suggest that the  
pre-processing effort is successful with the resources applied, and  
so needs no widening. A third is to suggest that the RFC Editor  
increase its copy-editing staff, drop the *separate* pre-processing,  
but encourage the RFC Editor to skim documents that show up in the  
IESG's workload and opportunistically start its editing processes early.

I have occasionally found myself wondering whether a grammar checker  
that could read our XML files (about 1/3 of our posted drafts have  
XML source posted with them) and make suggestions would be of value.  
In converting what is now RFC 1716 to RFC 1812, which was a HUGE  
editing task, I used a brand new tool that is now a popular grammar  
checker. It complained about "which" vs "that", which is neither here  
nor there, but also complained about misspellings, passive voice, and  
sentences that it couldn't parse. Apart from the technical  
differences (changing "subnet" to "prefix" and applying then-new CIDR  
concepts, deprecating RIP, etc), the vast majority of the changes I  
made could be described as copy-editing in response to those  
complaints, and folks seemed to think the result was an improvement.  
With the new posting tool, the idnits checker is run against every  
submission, which simplifies the life of the document shepherd. If  
the upload includes an XML file, would it make sense to similarly  
grammar check it, which the result being advice for the document author?

As you say, the heavy lifting has to be done by people that  
understand the semantics. But there are ways to improve the syntax,  
and as I say, the available data would suggest that improving what  
goes in to the RFC Editor helps them produce the output.

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Feb 2008 14:04:47 -0500

On 11-Feb-2008, at 13:53, Fred Baker wrote:

> nor there,

Well, not quite. "That" is for defining relative clauses, and "which"  
for non-defining relative clauses. It's surprising that a piece of  
software could tell between them, though.

Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 11 Feb 2008 19:16:57 -0000

> for non-defining relative clauses.

An interesting fact is that the RFC Editor process is particularly hot on 
"that"/"which". This may be a function of the use of copyeditor function 
since these folk tend to care about English usage and for them (and for me) 
it *is* much more than "neither here nor there". It could even have an 
impact on meaning in an RFC.

A

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Feb 2008 11:33:53 -0800

At Mon, 11 Feb 2008 19:16:57 -0000,
> impact on meaning in an RFC.

This kind of grammar theead usually ends in tears.

That said, the CMS is pretty wishy-washy on this:

S 5.42
A distinction has traditionally been made between the relative
pronouns which and that, the latter having been long regarded
as introducing a restrictive clause and the former, a nonrestrictive
one. Although the distinction is often disregarded in contemporary
writing, the careful writer and editor should bear in mind that such
indifference may result in misreading or uncertainty, as in the
sentence below.

Ambiguous:
The report which Marshall had tried to suppress was greeted with
hilarity.

Which of the following is meant:
The report, which Marshall had tried to suppress, was greated
with hilarity.
or
The report that Marshally had tried to suppress was greeted
with hilarity.

When the commas intended to set off a nonrestrictive lcause are
ommitted, perhaps with the purpose of using which restrictively,
the reader may well wonder whether the omission was inadvertant.
Some uncertainty will persist.

The MLA handbook is even less prescriptive:

S 3.2.2:
"Note that some writers prefer to use which to introduce 
norestrictive clauses and that to introduce restrictive
clauses".

Given that the distinction between which and that is not
universally observed and that our documents are intended
to be consumed in part by those who are not native
English speakers, ISTM that any case where the distinction
between which and that is important to meaning would benefit
from some rephrasing for increased clarity.

-Ekr

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 11 Feb 2008 21:05:22 +0100

Dan York wrote:
[..]
> P.S. How many folks out there have phones (hard or soft) from which they 
> can place calls to other random SIP endpoints?  (I do, but also realize 
> I'm in a minority.)

I know quite a number of people who have and are actively using SIP 
phones. I personally am a great fan of the Siemens S450IP/S675IP[1], 
just plug it in, go to the webpage, configure, works, and the fun thing 
is, it is a normal phone, thus plug in POTS and that also keeps on 
working. I donated one to my folks, and now it is publically known how I 
can call up my mum for free (except inet&hardware&power etc costs) for a 
couple of hours if I am cooking something up again ;)

The problem at the moment with SIP is:
  - STUN works, but is sorta annoying to setup
  - E164 support is not there yet (just try to get your number
    registered in e164.arpa, workaround: use e164.org)

One big solution would be using IPv6 of course ;)

But:
  - most hardphones don't support this
  - Asterisk doesn't come out of the box with IPv6 *yet*, see [2]

With IPv6 enabled, one can at least avoid the STUN tricks and routing 
the packets over the PBX (eg asterisk) and that would make latency 
better (unless you have bad IPv6 connectivity) and thus even more enjoyable.

Currently, the S675IP with a Asterisk box works like a charm though and 
it is what I use daily for calling up people and getting called.

Greets,
  Jeroen

[1] = http://www.voip-info.org/wiki/view/Siemens+Gigaset+S675IP
[2] = http://www.asteriskv6.org/

---

From: Ray Pelletier <[email-masked]>
Date: Mon, 11 Feb 2008 15:54:09 -0500

>from some rephrasing for increased clarity.
Perhaps the RFC Editor Style Manual 
(http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt) can 
offer some insight here:

*  "which" and "that" should follow the rules:

      o  "which" is non-restrictive and is used parenthetically.  It
         follows a comma and provides non-essential information.
         Example:

              "The XYZ Protocol, which is proprietary, may be vulnerable
              to session hijacking"

      o  "that" is restrictive and introduces information that is
         essential to the meaning of the sentence.  Example:

              "A protocol that is less robust may be more vulnerable to
              session hijacking"

Ray

>IAOC mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/iaoc
>
>
>  
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Feb 2008 13:11:45 -0800

At Mon, 11 Feb 2008 15:54:09 -0500,
>               "A protocol that is less robust may be more vulnerable to

Yeah, but the question at hand is whether the RFC Editor *should*
be enforcing this style.

-Ekr

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 11 Feb 2008 21:11:08 -0000

> This kind of grammar theead usually ends in tears.

Too right.
And, no doubt, we are shortly to be thoroughly flamed for being off-topic.

I think what it points out is that, those of us who do not know enough about 
grammar, should not presume to suggest that fixes to grammar are 
unimportant. Bar-room gramarians are, perhaps, as unhelpful in the IETF as 
bar-room lawyers, and the reason why we stoop to employ professionals is 
because we are not qualified to distinguish our defining elbows from our 
non-restrictive arses.

You might go to Strunk and White for a good and clear view of the topic 
since this work is particular to the American usage that we are required to 
turn out our RFCs in.

"That" is the defining, or restrictive, pronoun, "which" the nondefining, or 
nonrestrictive... But it would be a convenience to all if these two pronouns 
were used with precision. Careful writers go which-hunting, remove the 
defining whiches, and by so doing improve their work.

If you have time, you should read Fowler's essayon the topic and extensive 
examples (prefering an old edition since modern editors have tended to 
remove his "ramblings" in later editions). He gives a simple sentence that 
should clearly illustrate the difference...

I always buy his books that/which have influenced me greatly.
Buy them all - "which"
Buy a subset - "that"

Better yet, let us construct an example in the context of a protocol 
definition...

The defined protocol error conditions which/that are carried in the Notify 
message are for information only and MUST NOT cause any change in the 
processing rules.

"which" - all defined protocol error conditions are for information only, 
they are carried in the Notify message.

"that" - the protocol error conditions carried in the Notify message are for 
information only, but there may be other error conditions.

Cheers,
Adrian

PS. I thought the Chicago definition clear, and the example poor.

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 11 Feb 2008 15:28:11 -0600

Eric,

	I believe the answer is "yes."

	In an interesting twist on (what I think was your own
argument), allowing missuse of the English language does not 
help the people for whom it is not their first language.  In
addition, allowing abuse of grammar rules in cases that don't 
matter as much is not a good idea for those people that don't 
understand why they don't matter as much in those cases.

	Also, there are better examples of where the use of the
wrong choice is more noticeably incorrect.

	The style manual is correct, and it makes sense for the
RFC Editor to encourage correctness, hence the RFC editor is
at least not incorrect in pointing this out.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: Monday, February 11, 2008 4:12 PM
> To: Ray Pelletier
> Cc: ietf; IAOC; Fred Baker; Adrian Farrel
> Subject: Re: [IAOC] RFC Editor costs - Proofreading (was Re: 
> Myview of theIAOC Meeting Selection Guidelines)
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Feb 2008 22:57:03 +0100

On 11 feb 2008, at 22:11, Adrian Farrel wrote:

> because we are not qualified

That's nonsense. You don't need a degree to use language.

If a grammar rule is so complex that the group of people who created  
things like the "simple" network management protocol can't figure it  
out, it would be a mistake to make use of semantics that depend on  
that rule. It may be useful to employ people who had training in  
spotting these issues, especially as not all RFC authors are native  
English speakers, but there is a reason the name of the author is put  
above an RFC, and not the name of the (copy) editor. I.e., it's always  
the author's fault.

> the American usage that we are required to
> turn out our RFCs in.

Unless this is kept a secret so only those of us who are RFC authors  
know of it, this is not a requirement.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Feb 2008 17:39:47 -0500

On 11-Feb-2008, at 17:38, Marshall Eubanks wrote:

> But then shouldn't the question be whether the style manual should  
> be changed ?

 From "consistent with English grammar" to something else?

Joe

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 11 Feb 2008 17:42:16 -0500

<cc list shortened>

> Yeah, but the question at hand is whether the RFC Editor *should*

But then shouldn't the question be whether the style manual should be  
changed ?

By the way, those reports of me suppressing reports are nothing more  
than
scurrilous rumors, which should be suppressed.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 11 Feb 2008 17:44:56 -0500

>  From "consistent with English grammar" to something else?

This was a point of order. If you don't like the Style Manual,  
agitate to change it, not to ignore it.

Regards
Marshall

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 11 Feb 2008 17:14:35 -0600

Iljitsch,

	There are many ways to divide people into groups. For example,
it has been said that there are three groups of people in the world:
those that are good at math and those that are not.

	One clear way to divide people into two groups, however, is to
distinguish those who use language primarily with an intent to convey
content (i.e. to communicate), and those who mostly use a language
for some other purpose.  Without going into what such other purposes
might be, I think it is pretty clear that those who intend to use a
language for communication generally like and respect grammar rules.
If nothing else, grammar rules give you something to break - when the
need exists - and a framework for correctly interpretting meaning in
at least most other cases.

	That said, I think it is also clear that we may want to focus on
what is different about the level of "education" required to: 

1)	"use a language", 

2)	"represent one self as sufficiently expert in its use to 
	critique the (ab)use of a language by someone else" and 

3)	"represent one self as sufficiently expert in its use to 
	critique the criticism of an expert (on the basis of whose 
	presumed expertise) we've hired explicitly to critique the 
	(ab)use of a specific language by (presumed) non-experts."

What I believe we might discover is that Adrian said we probably
should require greater expertise from anyone who wants to do 3,
while what you've apparently accused him of is having said that
level of expertise is required to do 1.

	Sorry, but I don't see how you come up with that.

	By the way, we should also not confuse the expertise needed
to construct one set of rules with ability (or even desire) to
correctly employ another.

--
Eric Gray
Principal Engineer
Ericsson  

> Behalf Of Iljitsch van Beijnum
> Sent: Monday, February 11, 2008 4:57 PM
> To: Adrian Farrel
> Cc: IETF Discussion
> My view of theIAOC Meeting Selection Guidelines)
>

---

From: John Levine <[email-masked]>
Date: 11 Feb 2008 23:33:37 -0000

>That's nonsense. You don't need a degree to use language.

Of course not, but I can tell you from experience having written quite
a few books that if you want a set of documents to have a consistent
readable style, we authors just can't do it.  I think I write just
fine, but copy edits always, and I repeat ALWAYS, make the writing
more consistent and readable.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Feb 2008 15:37:45 -0800

At Mon, 11 Feb 2008 21:11:08 -0000,
Adrian Farrel wrote:
At Mon, 11 Feb 2008 21:11:08 -0000,
Adrian Farrel wrote:
> unimportant.

Which is why I cited the two standard style manuals, the
CMS, and the MLA handbook.

> nonrestrictive... 

And yet the MLA doesn't endorse this rule and the CMS only
barely does. I appreciate that this is a rule that used to
be strictly enforced but now, like split infinitives, it
is mostly an opportunity for pedantry.

> I always buy his books that/which have influenced me greatly.

As I said in my original message: if your sentence relies on
this distinction to be unambigous, you should rewrite it
to remove the that/which ambiguity.

> information only, but there may be other error conditions.

Again, these sentences should be written without the ambiguity.
In fact, in this particular case you've only managed to induce
it by removing the commas which should ordinarily surround the
nonrestrictive clause.

-Ekr

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Feb 2008 18:22:25 -0800

Could we come to order, please?

I was commenting that the use of pre-RFC-editor copy editors had been  
beneficial, and there was something possibly to be learned. I  
suggested one variation - tool, and mentioned as supporting context  
that I had used such a tool.

The six hours on the IETF list since then have been amazing. They  
have been about anything but how to improve the input to the RFC  
Editor, or the presupposition that this is in fact what has helped.

Wow...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Feb 2008 10:50:29 +0100

> more consistent and readable.

The way I see it, it's not the job of an editor and certainly not a  
copy editor to rewrite significant amounts of text because the author  
has trouble expressing him/herself. Readability and a consistent style  
are the jobs of the author, with guidance from an editor, if any. Copy  
editors work at a lower level by flagging ambiguities and cleaning up  
rough patches in the author's command of the language.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Tue, 12 Feb 2008 10:46:09 -0000

> Which is why I cited the two standard style manuals, the CMS, 
> and the MLA handbook.

It might be a good idea to look at some of the style manuals
for International English which deal explicitly with the 
problem of communicating unambiguously within the large
community of people who speak English as a second language
or who learned it as a native language outside of American
culture. There is more than one such style manual which
might be adopted by the IETF.

> this distinction to be unambigous, you should rewrite it to 
> remove the that/which ambiguity.

The thing is that a single person, whose experience of English 
is largely formed by the culture from which they learned the
language, generally cannot identify all such ambiguity issues.
That's why copy editors and reviewers exist.

Recourse to rules is not the best way to improve the clarity of
a piece of work, considering that the English language and its
rules are continuously changing. In addition, the various English
dialects are moving further apart from one another. That's why
there are now explicit style guides for International English, 
sometimes called Global English.

--Michael Dillon

---

From: Dave Cridland <[email-masked]>
Date: Tue, 12 Feb 2008 10:51:05 +0000

On Mon Feb 11 23:14:35 2008, Eric Gray wrote:
> might be,

Hithertofore, I have remained silent on this issue, in trepidation of  
questioning the wherefore of grammar, whence surely clarity comes  
forth.  Yet one observes herein a contrary group of folk who would  
busy themselves more with language than content; hence, I should  
think, the concerns of many, who would question whether the RFC  
Editor's employment of copy editors is a dalliance mindful of  
grammar, or clarity, at the forefront.

Naturally, all present value clarity of content; all value the use of  
grammar whence this derives - to simply strike a line through one's  
rules of English and ignore the learned experts who would advise us  
would be obviously foolish; however one must be mindful that the acme  
of language is perfection of communication; not that of grammar.

Yet grammar remains the wellspring of clarity - ambiguity festers in  
the cracks of one's application thereof, but none of us could  
ingenuously claim ourselves experts in that field. Thus abetment is  
required from professionals whom the RFC Editor has retained for this  
purpose.  One therefore hopes that the RFC Editor would use copy  
editors to provide clarity through grammar, and furthermore that any  
changes resultant are subject to approval by the author.

Since this does indeed appear to be the case, one must assume that  
for those who have concerns, these concerns are addressed to their  
satisfaction, and henceforth this list might return to whatever  
pressing subject previously occupied it, which will no doubt remain  
as elucidating as the regnant matter.

A final point worth raising is that those concerned with whether the  
benefit outweighs the cost might observe the differences between  
final draft and published RFC; trivial to do, and it would no doubt  
enlighten those who are concerned with the cost. Without this action,  
one must assume that arguments are based on opinion, and not fact,  
which is concerning - and highly irregular for this august list, as I  
hardly need mention.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 12 Feb 2008 11:07:41 -0800

It is not a cheap solution, but it is probably a cheaper one: why not copy the W3C setup?
 
They have a compunetix box that is hooked up to IRC in wierd and somewhat useful ways. So you can put yourself on the speaking queu and such. It is a hack but a useful one.
 
The ideal would be for some group to take some of the open source VOIP software and packaged it. Asterisk and such may or may not work but the number of users is going to remain much lower than the potential until someone put in the work necessary to make it turnkey.
 
Last time I visited the site I could not work out how the thing connected up to the PSTN at all, much less want to spend a month or two trying to coax it into action.

________________________________

From: [email-masked] on behalf of Steven M. Bellovin
Sent: Mon 11/02/2008 1:10 PM
To: Lars Eggert
Cc: 'IETF Discussion'; Richard Shockey
Subject: Re: Eating our own dog food and using SIP for telephony... (was Re:My view of the IAOC Meeting Selection Guidelines)

---

From: Morgan Sackett <[email-masked]>
Date: Wed, 13 Feb 2008 07:19:40 +0530

> see if a $0 conference is really worse than a $1000 conference.

Not sure about the cost side of this, as running a SIP server that can  
handle a decent number of calls does have an expense.  However, I use  
SIP for most of the calling that I do.  My entire office runs off of  
SIP, though it still has to connect to the PSTN at some point.  I  
would prefer to use my spare bits to transport voice all the way  
through to the destination if at all possible.  Even the conferencing  
that we do sounds good when all parties are dialed into our SIP based  
bridge.  There are just too many variables that go into voice networks  
to say that one technology or another is responsible for how *good* it  
is.

--Morgan

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 17 Feb 2008 08:42:18 -0800

There are free conference bridges that only use the PSTN - they make  
money by reverse termination charges (for example /www.freeconference.com 
). There are very expensive conference bridges that do cool tricks SS7  
technology. There are free confernce bridges that use SIP/H.323/IAX/ 
Skype (but as far as I know, not Jingle). There are very expensinve  
confernce bridges that use SIP - actually SIP seems to be the  
preferred way to build a really expensive conference service these days.

The cost of a conference bridge has pretty close to nothing to do with  
the signaling protocol. It has to do with if you can reach a human  
operator and say "can you phone me back at room 252 in the following  
hotel in Istanbul, I don't know the country code and have no idea if  
the hotel phone number I have includes anything like an city code". Or  
you can ask the operator to find the line with the bad echo and  
disconnect it.

I'm sure that opinions vary widely on if we need this level of  
conference bridge or not but today we have that and when you need it,  
well it is nice to have. My personal opinion as a someone that has  
been on these calls is that I could live with the following:

1) a bridge that worked every single time

2) web interface where one could initiate dial out to DID numbers

3) web interface where someone could mute participants that had put  
the conference on music on hold

4) would be nice to have web interface that showed active speaker

This is blasphemy but I don't care if it has an VoIP interface or not,  
but I absolutely have to be able to call it from my mobile phone.  
Obviously I think it would be cool if I could use VoIP with wideband  
audio.

Cullen

PS - as a WAG on the budget estimate below, I would guess the IESG  
uses something like 150 hours of conferencing a year.

On Feb 11, 2008, at 8:55 AM, Dan York wrote:

> conferencing bridges that can support SIP endpoints! ;-)  Can we  
> move some of this conversation in the bill below onto the Internet  
> using systems where our costs essentially go to $0?  (Obviously we  
> still need to communicate to non-wired folks across the PSTN, such  
> as event location facilities, etc.)
>
> Or is the issue really that, as Jonathan Christensen of Skype  
> states, the original vision of SIP for rich communications remains  
> [1] http://blogs.voxeo.com/speakingofstandards/2008/02/09/ecomm2008-jonathan-christensen-of-skype-and-the-unreal-vision-of-sip/
>
>
>