Racom Card Found

[Christian Vogt]

Folks,

we found a Racom card yesterday (Monday) afternoon in
Ballroom 1.  It's at the reception of the main hotel now.

Cheers,
- Christian


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

Re: Last Call: draft-ietf-sieve-refuse-reject (procedural nits)

[Frank Ellermann]

<[EMAIL PROTECTED]> wrote:

> I certainly have no problem if the consensus changes during
> last call to agree with me ;-)

Points where we disagree are more interesting :-)  There were
various points where we agreed on "this could/should be tuned".

 Frank

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

Re: Last Call: draft-ietf-sieve-refuse-reject

[Steven M. Bellovin]

On Tue, 29 Jul 2008 00:13:42 +0200
"Frank Ellermann" <[EMAIL PROTECTED]> wrote:

> <[EMAIL PROTECTED]> wrote:
> 
> > you appears to be complaining that the definition given
> > in this RFC in fact agrees with yours, perhaps modulo
> > emphasizing that the intent is to hurt the person whose
> > address is forged.
> 
> Another attempt:  "Joe Jobs" are about hurting an alleged
> sender, not about spamming.  Joe Jobs are relatively rare. 
> 
> Forged return-paths are standard operation in spam, they
> are about spamming.  The backscatter is not the intention.
> 
> Somebody who gets tons of backscatter likely doesn't care
> if that was intentional or not, because (s)he's annoyed.
> 
> Nevertheless using the term "Joe Job" is a distraction,
> because it is about a limited problem, unlike the global
> problem with the name "backscatter".
> 

Sorry -- I'm with Ned on this one.  Joe Jobs are Joe Jobs; the intent
isn't important.  Backscatter is an effect of the technique; it isn't
the act itself.


--Steve Bellovin, http://www.cs.columbia.edu/~smb
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-sieve-refuse-reject

[Frank Ellermann]

<[EMAIL PROTECTED]> wrote:

> you appears to be complaining that the definition given
> in this RFC in fact agrees with yours, perhaps modulo
> emphasizing that the intent is to hurt the person whose
> address is forged.

Another attempt:  "Joe Jobs" are about hurting an alleged
sender, not about spamming.  Joe Jobs are relatively rare. 

Forged return-paths are standard operation in spam, they
are about spamming.  The backscatter is not the intention.

Somebody who gets tons of backscatter likely doesn't care
if that was intentional or not, because (s)he's annoyed.

Nevertheless using the term "Joe Job" is a distraction,
because it is about a limited problem, unlike the global
problem with the name "backscatter".

> So the solution is to change from a term that is widely
> used and well understood, up to and including a Wikipedia
> definition, to another that is nowhere near as widely
> used or well understood?



The second sentence in the head section of the "Joe Job"
article has a link to this backscatter article and says:

| For a related phenomenon that is not targeted directly
| at a particular victim, see "backscatter of email spam"

The article version I looked at has the date 2008-06-21.
The very serious difference is:

Back in 2002 and 2003, when this was new, some folks had
the idea that "Joe jobs" are a *social* problem.  A very
prominent example from my POV was the execellent (at this
time) German e-mail abuse FAQ by B. Fink.

*Social* problem means "call the cops, nothing to do here
from an engineering POV".  But other folks never believed
that this is the whole truth, and considered "backscatter"
as a *technical* problem that has to be fixed.  And they
did in various drafts and RFCs (RMX, MTAMARK, nullmx, CSV,
SIQ, SES, BATV, 4408, 5068, 5230, MINGER, and much more).

So when somebody says "Joe Job", but means "backscatter", 
then I dislike this as some kind of Orwellian "newspeak". 

> As long as that needs to be address I guess I have no
> obection to discussing the term's history a little more
> or something along those lines.

There's also the point that my impression is based on what
I read years ago including the German mail abuse newsgroup.

But I don't recall discrepancies with English uses on say
the Spamcop lists.  Or later the ASRG + MARID + SPF lists.

>> explaining why step 1 is a good recipe at the border,
>> and far too late to avoid real havoc for a later relay.
 
> I would not object to that but I don't think it is necessary.

AFAIK nobody else does so far explain it in simple words,
neither 2821bis, nor e-mail-arch.  Neither 4408, nor 5068.

The draft is in a good position to explain this.  This
problem apparently motivated the introduction of the new
'ereject' - my first impression was that the draft *tries*
to do the right thing.  Until the 'reject' section, where
it gives up trying.

> Oversimplification is a problem and I agree this document
> gets close to the line on that. It is, however, far 
> preferable to falling down a rathole and having no
> document discussing the reject issue. Our primary attempt
> to get these sorts of details out into the open - the
> email architecture document - is still stuck AFAIK.

e-mail-arch won't admit that something like a "border MTA"
exists - and adding this as a foul compromise could break
the consistent POV presented in this document.  It looks
at the architecture from the top, and identifies relays
sending mail from hop to hop, clustered into ADMDs.

It doesn't looks at the picture with the question "what is
an MX ?"  That would remove some details discussed in this
memo, and add details not discussed, terms like MON + MRN
at an orthogonal level of abstraction.

For the purpose of 'ereject' and "backscatter" e-mail-arch
misses the point.  We could discuss for ages if that is a
feature or bug or what else, but it is clearly no accident.

> Then by all means suggest specific text to add.

Add a note that "step 1" (in 2.1) is the best choice for a
script talking with a "border MTA", while that MTA has not
yet accepted the mail.  Leave "border MTA" undefined, folks
either know what it is, or won't understand an explanation.

Add a note that "step 2" might discard legit mail when the
"clearly forged return-path" is less clear than expected.

Add a note that "step 3" sending potentially hostile content
in a DSN to innocent bystanders (forged return-path) or to
clueless users (good return-path) might be a very bad idea.

For 2.2 - because you won't accept the radical proposal to
delete this - add a note that "unsolicited MDNs" are today 
considered as abuse when they go to forged return-paths.

For 2.3 I still don't get why it is there, 'ereject' can be
so much better than 'reject'.  Maybe 2.3 needs a motivation.

[...skipping the i18n questions in 2.1.2 as less important...]

>> In practice I'd consider MDNs about mails I never sent as
>> spam.  And in 2008 this (ab)use, intenti

Re: Last Call: draft-ietf-sieve-refuse-reject (procedural nits)

[ned+ietf]

> > 'Sieve Email Filtering: Reject and Extended Reject Extensions '
> >   as a Proposed Standard

> The draft wants to "update" RFC 3028, but this RFC was obsoleted
> by RFC 5228.  Good riddance wrt 'reject', reviving this "CANSPAM"
> recipe appears to be a bad idea.

I, OTOH, am a lot more comfortable exaplining how to do something correctly
than I am not telling people anything and having them go it alone and get it
wrong.

> LMTP happens after final SMTP delivery.

If it does, then you're dealing with a deeply broken implementation. If LMTP is
used it *is* the final delivery step.

> At this point it is not
> more possible to cause a "real" SMTP reject while talking with an
> alleged sender.

That's an issue quite separate from when final delivery occurs. The problem
here is that once the SMTP server has accepted the message it is no longer
possible to turn back the clock and reject it at the SMTP level. Final delivery
isn't really relevent.

Now, one way to partially address this in an implementation is to overlap the
SMTP and LMTP sessions. But even this cannot possbly cover all cases - suppose
there are multiple recipients and the LMTP server returns a mixture of success
and failure responses after the final dot. The LMTP client/SMTP server then has
no choice but to return a success in the session and subsequently send back
DSNs.

> That is the main issue in this draft.  I'm not
> yet convinced that an LMTP "downref" is appropriate or necessary.

Finally, a point we can agree on. I have real misgivings about the way this
draft discusses LMTP server-side implementations, for several reasons. Besides
the previously mentioned issue that there are cases which unavoidably cause
DSNs to be sent no matter how clever the client is, a server has no way of
knowing that the client talking to it is one of these clever ones anyway. (And
it certainly cannot count on it.)

I believe we'd be better off if most of the discussion of server-side LMTP
implementation was simply removed from this document, perhaps to be replaced
with a statement that ereject cannot be properly implemented in this context
and reject is problematic since it cannot be promoted to an SMTP-level failure.

However, the consensus of the group was to keep this in spite of my misgivings.
But I certainly have no problem if the consensus changes during last call to
agree with me ;-)

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

RE: [Capwap] Last call comments for capwap-protocol-specification-11

[Pat Calhoun (pacalhou)]

Thanks for the review, Pasi.

We use tracker to keep track of all of our issues. My plan is to create
a unique tracker entry for all of the substantial issues you raised
here, and a single one for the minor claritifications/nits you include
below. Please see below for information on the issues I created. 

I plan to create a new thread as we attack each issue, one by one
(except the minor points that will be dealt with as a whole). I will CC
you on each one of these since I do not know that you are on the CAPWAP
list.

PatC


> I read capwap-protocol-specification-11 on my way to Dublin; here are
some comments/observations. 
> 
> Substantial topics first:
> 
> Section 3.5: The text about MTU discovery doesn't look right; Section
> 3.5 seems to assume that after the WTP has discovered the AC it wishes
to communicate with, RFC 1191/1981/4821 would 
> provide it with the MTU, and then the WTP would establish the CAPWAP
session.  But those RFCs don't specify e.g. what 
> packets would be used for probing for the MTU.

Created as Issue 151:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue151
> 
> Section 4.6.29: Using MD5 in a new protocol, and not providing
algorithm agility for moving to new algorithms, is 
> probably not such a great idea.

Created as Issue 152:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue152

> 
> The linking of control and data channels, and how DTLS session
resumption is used here, seems unnecessarily 
> complicated.  Normally session resumption is totally TLS internal
optimization, and applications running over TLS don't 
> know (and have no need to know) whether full or abbreviated TLS
handshake was used. It seems this document wouldn't 
> really need to say anything about session resumption; if the WTP
provides the Session ID in data channel, and AC checks 
> that both DTLS connections were established by the same authenticated
client, that seems sufficient.  This would seem 
> to remove much implementation complexity; e.g. the requirement in
4.4.3 that "The AC DTLS implementation MUST NOT 
> accept a session resumption request for a DTLS session in which the
control channel for the session has been torn 
> down" doesn't follow the usual TLS/DTLS module boundaries.

Created as Issue 153:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue153

> 
> Section 3.3: Should IPv4 use a well-known multicast address (instead
of broadcast), too? Why not?

Created as Issue 154:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue154

> 
> The protocol allows the AC to add and delete static MAC ACL entries,
but it seems the AC can't check what the current 
> ACL entries are.
> This means the WTP and AC could get out-of-sync, right? (The AC can't
delete the unneeded static MAC ACL entries if it 
> doesn't know what they are.) 

Created as Issue 155:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue155

> 
> Section 3.3: there's a single sentence about DNS-based discovery;
probably slightly more details would be useful.

Created as Issue 156:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue156

> 
> Section 2.4.3: handling of cookies that fail to validate is really a
DTLS detail, and shouldn't be in this 
> specification. RFC 4347 doesn't say what the DTLS server should do,
but I think the right approach is to treat an 
> invalid cookie the same as no cookie (and not discard the whole
message, as is suggested here -- I think that could 
> lead to weird failure modes even in the absence of malicious
attackers).  I'll raise this on the TLS mailing list, so 
> it can be clarified in DTLS 1.2 update.

Created as Issue 157:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue157

> 
> Section 4.3: it seems that allocation of WBIDs (and message element
numbers in 4.6) would be better done in the 
> document specifying the binding. Considering that WBID allocations
require Standards Action, especially allocating 
> WBIDs for technologies for which not even an Internet-Draft exists yet
seems premature.

Created as Issue 158:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue158

> 
> Section 4.5.3: Is CAPWAP control protocol strictly "lock-step" (once
you send a Request, you must wait for Response 
> until you send another Request), or are multiple outstanding requests
allowed?  Can you "give up" a Request (stop 
> retransmitting it even though you haven't received a Response), and
move to the next Request?  What should you do if 
> you receive a Request with a Sequence Number that's too old (less than
previous Request you've seend) or too new 
> (greater than previous Request+1)?

Created as Issue 159:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue159

> 
> Replay protection is an optional feature in RFC 4347. Should this
document say something about it? (e.g. MUST use?)

Created as Issue 160:
http://www.capwap.org/cgi-bin/roundup.cgi/CAPWAP/issue160

> 
> There's some inconsistency about NAT detection: Sections 4.6.12,
4.6.13, and 4.6.15 say it's done using "CA

Re: Last Call: draft-ietf-sieve-refuse-reject

[ned+ietf]

> <[EMAIL PROTECTED]> wrote:

>  [Joe Job]
> > This is the original meaning of the term - you can find the
> > history behind the term in the Wikipedia entry.

> Yes, I recall it, about six years ago, when spammers figured
> out that they can actually abuse any plausible return-path.

> > You are correct to say that current usage has drifed somewhat
> > from the original

> IIRC not really.

Well, now I'm confused, because you appears to be complaining that the
definition given in this RFC in fact agrees with yours, perhaps modulo
emphasizing that the intent is to hurt the person whose address is forged.

> The assumption was always that a "Joe Job"
> is not about mere spamming, but about hurting the (forged)
> sender.  The content of these "Joe Jobs" was often an ugly
> mix talking about selling drugs, weapons, and child porn -
> intended to trigger hostile reactions against the (alleged)
> sender.  A "Joe Job" is not trying to sell offered "goods",
> it tries to get the alleged sender in all sorts of trouble.
> Often anti-spammers were targets of "Joe Jobs".

> > if there's general consensus that the old usage is now
> > incorrect I haven't seen it.

> Now you have seen it - I'm too lazy to fix Wikipedia today
> if it says something else.

It's likely you won't find anything change, although it does appear from the
discussion page that Wikipedia is headed towards deemphasizing the matter of
intent, so you may not like how this evolves.

> > as long as the term is well defined and used consistently
> > within the document I see no justification for changing
> > anything here.

> Our disagreement about basic terminology indicates that this
> draft did not yet get broader review. 

in fact this draft has been discussed so many times with so many people it
isn't funny.

> The problem of forged
> return-paths is not limited to rare "Joe Jobs".  A better
> term could be "backscatter".  Or "blowback", as you used it:

So the solution is to change from a term that is widely used and well
understood, up to and including a Wikipedia definition, to another that is
nowhere near as widely used or well understood?

Sorry, I think changing terms here is a bad idea. Even if someone reading this
is used to the term being used in a more specific sense, the definition given
should address that.

I do see a real issue here, which is that now that I look the definition only
apppears in the abstract. My understanding of RFC Editor rules is that the
abstract is considered to be essentially separated from the rest of the
document and that this really belongs in the document proper. As long as that
needs to be address I guess I have no obection to discussing the term's history
a little more or something along those lines.

> > As for stressing this even more, the problem with that is
> > that there are cases, such as when operating on a relay
> > MTA that's past the ingress point to an administrative
> > domain, where taking action 1 will in fact generate
> > blowback and is therefore NOT preferable to 2.

> Yes, and the draft doesn't adequately explain the problem
> in this case.  There should be ASCII art with a border MTA
> and a final delivery MTA, explaining why step 1 is a good
> recipe at the border, and far too late to avoid real havoc
> for a later relay.

I would not object to that but I don't think it is necessary.

> Discard is bad if "clearly forged" was in fact legit mail.
> Bounce is bad if the return-path is forged.  All we know in
> general is a roughly 90% probability for "forged".

> IMO 90% isn't "clearly" enough, otherwise we would rarely
> (SPF PASS or similar) or never reach step 3.  Just in case,
> I don't insist on 90, it could be also 75, 80, or 95 today.

> > there is a general preference order here, but overstressing
> > it is IMO not a good idea.

> The same goes for an oversimplification:  The draft doesn't
> care about its context.  LMTP (post final SMTP delivery) or
> any scenario where the mail was accepted at the border is
> one class.  And a scenario where the mail can be rejected
> while talking with an MTA of the sending side is the good
> class, where an 'ereject' can work as it SHOULD.

Oversimplification is a problem and I agree this document gets close to the
line on that. It is, however, far preferable to falling down a rathole and
having no document discussing the reject issue. Our primary attempt to get
these sorts of details out into the open - the email architecture document - is
still stuck AFAIK. If and when that document comes unstuck them maybe
discussions of these detail will be possible. But until then...

> The draft already goes into details wrt the good class, as
> it mentions the issue of the not (yet) existing "selective
> reject" of mails for multiple receivers in SMTP.  But that
> isn't the only important detail, other details are missing.

Then by all means suggest specific text to add.

> > These sorts of attempts to overspecify behavior are at
> > best silly, at worst

Re: Last Call: draft-ietf-sieve-refuse-reject (procedural nits)

[Scott Kitterman]

On Mon, 28 Jul 2008 18:35:11 +0200 "Frank Ellermann" 
<[EMAIL PROTECTED]> wrote:
>Alexey Melnikov wrote:
>
>> nothing prevents the final SMTP server from passing commands
>> to the LMTP server, before replying to the SMTP client.
>
>Thanks for info, I wasn't aware of that possibility.  Maybe
>it is unnecessary to have the LMTP reference as "normative",
>but based on your info I agree that a "downref" is no issue.
>
Possible in theory.  In practice unless and MTA's internal architecture is 
designd for this it would likely require substantial redesign to do so.

Isn't SMTP supposed to be store-and-forward?  I'm not sure if it's the case 
here, but if we are tampering with the store-and-forward paradigm, I think 
it's problematic.

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

Re: Last Call: draft-ietf-sieve-refuse-reject (procedural nits)

[Frank Ellermann]

Alexey Melnikov wrote:

> nothing prevents the final SMTP server from passing commands
> to the LMTP server, before replying to the SMTP client.

Thanks for info, I wasn't aware of that possibility.  Maybe
it is unnecessary to have the LMTP reference as "normative",
but based on your info I agree that a "downref" is no issue.

 Frank

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

RE: request for comments -- how to?

[michael.dillon]

> I have an idea for a new anonymous routing protocall -- and I 
> was wondering what I should do to get input. I was told by 
> some people to post here.

First Steps
---
Write a document that describes the protocol. If you can implement it as
well, great, but to start you need to have a document. Then set up a
mailing list where people can discuss your design. Find people who are
interested in your protocol by talking about it in places where this
kind of person hangs out. 

Next Steps
--
Once you have a group of people on your mailing list discussing the
protocol design, then have a look at this page
. Find out which area you
think your work belongs in and send a message to one of the ADs (Area
Directors) asking them what you need to do to change your discussion
group into an IETF working group.

Focus on the first steps for now because if you can't get over that
hurdle without IETF help then you probably don't have something that
belongs in an IETF working group.

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

request for comments -- how to?

[dig asm]

I have an idea for a new anonymous routing protocall -- and I was wondering
what I should do to get input. I was told by some people to post here.

If this is the wrong place please let me know where I should go to.
~digasm~
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-sieve-refuse-reject (procedural nits)

[Alexey Melnikov]

Frank Ellermann wrote:


The IESG wrote:
 


'Sieve Email Filtering: Reject and Extended Reject Extensions '
 as a Proposed Standard
   


The draft wants to "update" RFC 3028, but this RFC was obsoleted
by RFC 5228.  Good riddance wrt 'reject', reviving this "CANSPAM"
recipe appears to be a bad idea.
 


The main editor already fixed this in his copy.


LMTP happens after final SMTP delivery.  At this point it is not
more possible to cause a "real" SMTP reject while talking with an
alleged sender.  That is the main issue in this draft.  I'm not
yet convinced that an LMTP "downref" is appropriate or necessary.
 

I think you are confusing implementation detail with logical 
architecture: nothing prevents the final SMTP server from passing 
commands to the LMTP server, before replying to the SMTP client.


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

Re: NATs necessary for IPv6, says IETF chair

[Brian E Carpenter]

The headline is pretty misleading. The content seems accurate.

Brian

On 2008-07-29 00:55, Marc Manthey wrote:
> morning all,
> 
> i was a bit confused after i read this 2 articles
> 
>>  NAT gets added to IPv6 after all
> 
> http://www.techworld.com/networking/features/index.cfm?featureid=4167&pagtype=all
> 
> 
>> NATs necessary for IPv6, says IETF chair
> 
> http://www.networkworld.com/news/2008/072109-nat-housley-qna.html
> 
> i am afraid that after 10 Years of NAT that it will survive and itojun
> would turn into his grave.
> 
> http://ipv6samurais.com/ipv6samurais/demystified/nat-problem.html
> 
> just my 2 cents
> 
> greetings
> 
> Marc
> 
> -- 
> 
> Les enfants teribbles - research and deployment
> Marc Manthey - head of research and innovation
> Hildeboldplatz 1a D - 50672 Köln - Germany
> Tel.:0049-221-3558032
> Mobil:0049-1577-3329231
> jabber :[EMAIL PROTECTED]
> blog : http://www.let.de
> ipv6 http://stattfernsehen.com
> xing : https://www.xing.com/profile/Marc_Manthey
> 
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

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

Re: NATs necessary for IPv6, says IETF chair

[Lars Eggert]

On 2008-7-28, at 13:55, ext Marc Manthey wrote:

> NATs necessary for IPv6, says IETF chair
http://www.networkworld.com/news/2008/072109-nat-housley-qna.html


The quote form the article is: "They are necessary for a smooth  
transition from IPv4 to IPv6 so that the important properties of the  
Internet are preserved." IMO the shortened sound-bite in the headline  
mischaracterizes what was actually said.


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

Found Safeword Platinum tokencard

[Julien Laganier]

Folks,

I found a Safeword Platinum tokencard on a lunch table on first floor 
above terminal room. I will hand it to the registration desk after this 
session finishes so you can pick it up from there c.a. 15:00.

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

NATs necessary for IPv6, says IETF chair

[Marc Manthey]

morning all,

i was a bit confused after i read this 2 articles

>  NAT gets added to IPv6 after all

http://www.techworld.com/networking/features/index.cfm?featureid=4167&pagtype=all

> NATs necessary for IPv6, says IETF chair

http://www.networkworld.com/news/2008/072109-nat-housley-qna.html

i am afraid that after 10 Years of NAT that it will survive and itojun  
would turn into his grave.


http://ipv6samurais.com/ipv6samurais/demystified/nat-problem.html

just my 2 cents

greetings

Marc

--

Les enfants teribbles - research and deployment
Marc Manthey - head of research and innovation
Hildeboldplatz 1a D - 50672 Köln - Germany
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
jabber :[EMAIL PROTECTED]
blog : http://www.let.de
ipv6 http://stattfernsehen.com
xing : https://www.xing.com/profile/Marc_Manthey





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

Re: Chairs: Helping out remote participants

[Dan York]

One other request from someone else who is also remote for this meeting:

- Can chairs (or others) please ask those going to microphones to  
raise questions to *please* state their names as they start to speak?


Some people are frequent commenters and their voices are well-known...  
but others are not.  It's helpful to remote folks to know who is  
talking.


Thanks,
Dan

P.S. And +1 to Philip's other points.

On Jul 28, 2008, at 7:19 AM, Philip Matthews wrote:

Just a quick note on what chairs could do to help out remote  
participants, from someone who is trying to participate remotely for  
the first time this week.


In order of priority (most important first):

1) Ensure all meeting materials are uploaded before the session  
begins. Ideally, the various presentations would be listed (on the  
meeting materials page) in the same order as they appear in the  
agenda, but otherwise they should have good names so  the correct  
presentation can be easily found. [Following a presentation without  
seeing the slides can be VERY difficult.]


2) Ensure everyone uses a microphone.

3) Ensure someone monitors the jabber chat room. If you cannot find  
a scribe, at least have someone watching for questions, especially  
simple questions like "what slide are we on now" or "who is that at  
the mic?".


4) Ensure all presentations have slide numbers and have the jabber  
person type in slide changes. (It is often hard to tell from just  
audio clues).



Thanks!

- Philip



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


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

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free





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

Chairs: Helping out remote participants

[Philip Matthews]

Just a quick note on what chairs could do to help out remote  
participants, from someone who is trying to participate remotely for  
the first time this week.


In order of priority (most important first):

1) Ensure all meeting materials are uploaded before the session  
begins. Ideally, the various presentations would be listed (on the  
meeting materials page) in the same order as they appear in the  
agenda, but otherwise they should have good names so  the correct  
presentation can be easily found. [Following a presentation without  
seeing the slides can be VERY difficult.]


2) Ensure everyone uses a microphone.

3) Ensure someone monitors the jabber chat room. If you cannot find a  
scribe, at least have someone watching for questions, especially  
simple questions like "what slide are we on now" or "who is that at  
the mic?".


4) Ensure all presentations have slide numbers and have the jabber  
person type in slide changes. (It is often hard to tell from just  
audio clues).



Thanks!

- Philip



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