Subject: [VRRP] Volunteer scribe ??

From: [email-masked]
Date: Mon, 7 Jul 2003 17:24:13 -0500

Do we have any volunteer scribe for IETF57 in the WG ??

-----Original Message-----
From: ext Marshall Rose [mailto:[email-masked]]
Sent: Monday, July 07, 2003 2:09 PM
To: [email-masked]
Subject: text conferencing at ietf57

	     Remote Access for the 57th IETF meeting in Vienna:
                             Text Conferencing

At each IETF meeting, two of the working group meeting rooms are equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 57th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    ietf.jabber.at

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.

In addition to the conference rooms for each wg that is meeting, there
are three others of general interest: bar, hallway, and plenary.

1. Before the meeting:

1.1. If you want to participate
    
If you don't already have one, get yourself a Jabber client, here are some
suggestions:

    platform    suggestion
    --------    ----------
    win32       http://exodus.jabberstudio.org
    'nix        http://gabber.sf.net
    macos       http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that. 
    
If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:
    
    list of clients:    http://www.jabber.org/user/clientlist.php
              howto:    http://www.jabber.org/user/userguide/
        server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:
    
    Group/Room: testing
    Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).
    
1.2. What the Chair does
    
If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)
    
So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?

2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

    Group/Room: foobar
    Server:     conference.ietf.jabber.com

2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.

2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along. 

2.4. Where to find the conference log
    
[ tbd: i'm still working on this one... ]
    
                                  #######

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "M. T. Hollinger" <[email-masked]>
Date: Tue, 15 Jul 2003 09:52:26 -0400

The vrrp-ipv6-spec-05 draft still specifies the use of virtual MAC
addresses, even with IPv6.

I have long disliked the use of duplicate MAC addresses for v4, which was
justified with the argument that some older ARP implementations did not
properly receive and parse gratuitous ARP messages.

That argument does not apply to IPv6.  I oppose moving this document forward
until the use of virtual MAC is removed.  (Alternatively, if there is a
strong justification, then text could be added to the document explaining
why this architecturally awful design was believed to be the best choice for
the IPv6 environment.)

           - Mark

---

From: Bob Hinden <[email-masked]>
Date: Tue, 15 Jul 2003 08:02:37 -0700

Mark,

>why this architecturally awful design was believed to be the best choice for

I don't agree that it is so bad or as you say an "architecturally awful 
design".  I have thought about it as one of the great MAC address hacks :-)

The advantage of this approach is that it works without the hosts having to 
do anything (e.g., receive and process an ND message, update tables, 
etc.).  The switch over is transparent to the hosts.

This approach is well proven in the IPv4 version of VRRP.  It is running 
operationally in many places and I am not aware of any problems.  Are you 
aware of any technical problems with the virtual MAC address approach?

Thanks,
Bob