Subject: 63rd IETF - DRAFT Agenda

From: IETF Agenda <[email-masked]>
Date: Tue, 19 Jul 2005 21:01:21 -0400

Below, please find the latest DRAFT Agenda.  Some requests for changes have been
made, in trying to make others, it created conflicts as well.  If there is
something that absolutely needs to be changed, please give a suggestion, with
both the working chair and area directors giving input and/or approval.  Please
send comments to [email-masked]

Draft Agenda of the Sixty-third IETF
July 31 - August 5, 2005
As of 7/19/2005

SUNDAY, July 31, 2005
1200-1900 Registration - 
1300-1430 Newcomer’s Training (English) - 
1300-1500 Routing, Bridging and Switching -
1500-1630 Newcomer's Training (French) -
1500-1700 RFC Editor Tutorial -
1500-1700 DNS Tutorial - 
1700-1900 Welcome Reception -  

MONDAY, August 1, 2005
0800-1800 IETF Registration - 
0800-0900 Beverages - 
0900-1000 Morning Session I 
APP   apparea   Applications Open Area Meeting
INT   netlmm    Network-based Localized Mobility Management BOF
OPS   ipcdn     IP over Cable Data Network WG
RTG   rpsec     Routing Protocols Security Requirements WG
SEC   openpgp   An Open Specification for Pretty Good Privacy WG
TSV   ieprep    Internet Emergency Preparedness WG

1000-1030 Break (Beverages provided) – 
1030-1230 Morning Session II
INT   intarea   Internet Area Meeting
OPS   dnsop     Domain Name System Operations WG
RTG   mpls      MultiProtocol Label Switching WG
RTG   forces    Forwarding and Control Element Separation WG
SEC   kitten    Kitten (GSS-API Next Generation) WG
TSV   ippm      IP Performance Metrics WG
TSV   sip       Session Initiation Protocol WG

1230-1400 Break 
1400-1600 Afternoon Session I
APP   geopriv   Geographic Location/Privacy WG
INT   hip       Host Identity Protocol WG
INT   pana      Protocol for Carrying Authentication for Network Access WG
OPS   capwap    Control and Provisioning of Wireless Access Points WG
OPS   v6ops     IPv6 Operations WG
RTG   rtgarea   Routing Area Open Meeting
SEC   krbwg     Kerberos WG
TSV   mmusic    Multiparty Multimedia Session Control WG

1600-1630 Break (Refreshments provided) - 
1630-1800 Afternoon Session II
INT   autoconf  Ad Hoc Network Configuration BOF
INT   l3vpn     Layer 3 Virtual Private Networks WG
IRTF  p2prg     Peer-to-Peer Research Group
OPS   ipfix     IP Flow Information Export WG
SEC   ltans     Long-term Archive and Notary Services WG
TSV   rohc      Robust Header Compression WG
TSV   rmt       Reliable Multicast Transport WG

1815-1945 Afternoon Session III
INT   l3vpn     Layer 3 Virtual Private Networks WG
INT   mip4      Mobility for IPv4 WG
OPS   grow      Global Routing Operations WG
SEC   hash      One-way Hash Function BOF
TSV   rserpool  Reliable Server Pooling WG
TSV   xcon      Centralized Conferencing WG

TUESDAY, August 2, 2005
0800-1800 IETF Registration - 
0800-0900 Beverages - 
0900-1000 Morning Session I
APP   calsify   Calendaring and Scheduling Standards Simplification WG
INT   shim6     Site Multihoming by IPv6 Intermediation WG
OPS   psamp     Packet Sampling WG
RTG   isis      IS-IS for IP Internets WG

1000-1030 Break (Beverages provided) – 
1030-1230 Morning Session II
APP   lemonade  Enhancements to Internet email to Support Diverse Service
Environments WG
INT   mipshop   MIPv6 Signaling and Handoff Optimization WG
INT   pwe3      Pseudo Wire Emulation Edge to Edge WG
OPS   bmwg      Benchmarking Methodology WG
RTG   pim       Protocol Independent Multicast WG
SEC   secmech   Security Mechanisms BOF
TSV   avt       Audio/Video Transport WG
TSV   ecrit     Emergency Context Resolution with Internet Technologies WG

1230-1400 Break 
1400-1600 Afternoon Session I
INT   eap       Extensible Authentication Protocol WG
INT   ipv6      Internet Protocol Version 6 WG
IRTF  dtnrg     Delay Tolerant Networking Research Group
RTG   pce       Path Computation Element WG
SEC   pkix      Public-Key Infrastructure (X.509) WG
TSV   nfsv4     Network File System Version 4 WG
TSV   sip       Session Initiation Protocol WG

1600-1630 Break (Refreshments provided) - 
1630-1800 Afternoon Session II
APP   rui       Remote UI BOF
INT   mip6      Mobility for IPv6 WG
INT   ntp       Network Time Protocol WG
OPS   imss      Internet and Management Support for Storage WG
RTG   l1vpn     Layer One Virtual Private Networks WG
SEC   sasl      Simple Authentication and Security Layer WG
TSV   behave    Behavior Engineering for Hindrance Avoidance WG

1815-1945 Afternoon Session III
APP   sieve     Sieve Mail Filtering Language WG
INT   mip6      Mobility for IPv6 WG
RTG   rtgwg     Routing Area WG
SEC   msec      Multicast Security WG
TSV   ips       IP Storage WG
TSV   tcpm      TCP Maintenance and Minor Extensions WG

WEDNESDAY, August 3, 2005
0800-1700 IETF Registration - 
0800-0900 Beverages - 
0900-1000 Morning Session I
APP   ldapbis   LDAP (v3) Revision WG
INT   shim6     Site Multihoming by IPv6 Intermediation WG
INT   pwe3      Pseudo Wire Emulation Edge to Edge WG
OPS   opsec     Operational Security Capabilities for IP Network Infrastructure
WG
RTG   bfd       Bidirectional Forwarding Detection WG
SEC   pki4ipsec Profiling Use of PKI in IPSEC WG
TSV   avt       Audio/Video Transport WG  

1000-1030 Break (Beverages provided) – 
1030-1230 Morning Session II
APP   imapext   Internet Message Access Protocol Extension WG
INT   ipdvb     IP over Digital Video Broadcast WG
INT   l2vpn     Layer 2 Virtual Private Networks WG
OPS   radext    RADIUS Extensions WG
RTG   ospf      Open Shortest Path First IGP WG
SEC   inch      Extended Incident Handling WG
SEC   sacred    Securely Available Credentials WG
TSV   sipping   Session Initiation Protocol Investigation WG

1230-1400 Break 
1400-1630 Afternoon Session I
APP   lemonade  Enhancements to Internet email to Support Diverse Service
Environments WG
INT   dnsext    DNS Extensions WG
INT   nemo      Network Mobility WG
OPS   imad      IPv4 Multicast Address Architecture BOF
RTG   ccamp     Common Control and Measurement Plane WG
SEC   alien     Anonymous Identifiers BOF
SEC   mobike    IKEv2 Mobility and Multihoming WG
TSV   tsvwg     Transport Area WG

1630-1700 Break (Refreshments provided) - 
17:00-19:30 IETF Operations and Administration Plenary - Main Amphitheatre
(Level 1)
        Session Chair: Brian Carpenter
        Welcome and introduction
        Host presentation (France Telecom VP)
        ISOC update (Lynn St Amour) and Postel Award
             (Daniel Karrenberg)
        NOC team says hello (Jim Martin, France Telecom)
        IASA Report
          - General report: IAOC Chair
          - Operations report: IAD
          - RFC Editor report
          - IANA report
        Tools team report
        Where next? (Brian Carpenter)
        Town Hall Meeting - IETF Admin and Operations topics

2200    Late Night Session
        PGP Key Signing 

THURSDAY, August 4, 2005
0800-1700 IETF Registration - 
0800-0900 Beverages – 
0900-1000  Morning Session I
APP   crisp     Cross Registry Information Service Protocol WG
INT   6lowpan   IPv6 over Low Power WPAN WG
INT   lrw       Lightweight Reachability softWires BOF
OPS   netconf   Network Configuration WG
SEC   btns      Better Than Nothing Security WG
TSV   nsis      Next Steps in Signaling WG
TSV   xcon      Centralized Conferencing WG

1000-1030 Break (Beverages provided) – 
1030-1230 Morning Session II
APP   rui       Remote UI BOF
INT   dhc       Dynamic Host Configuration WG
INT   trill     Transparent Interconnection of Lots of Links WG
IRTF  mobopts   IP Mobility Optimizations RG
RTG   idr       Inter-Domain Routing WG
SEC   isms      Integrated Security Model for SNMP WG
SEC   mass      Message Authentication Signature Service  BOF
TSV   sipping   Session Initiation Protocol Investigation WG

1230-1400 Break 
1400-1630 Afternoon Session I
APP   simple    SIP for Instant Messaging and Presence Leveraging Extensions WG
INT   dna       Detecting Network Attachment WG
OPS   mboned    MBONE Deployment WG
RTG   manet     Mobile Ad-hoc Networks WG
SEC   saag      Open Security Area Directorate
TSV   dccp      Datagram Congestion Control Protocol WG
TSV   voipeer   VoIP Peering and Interconnect BOF

1630-1700 Break (Refreshments provided) - 
17:00-19:30 Technical Plenary - Main Amphitheatre (Level 1)
            Session Chair: Leslie Daigle
            Welcome and introduction
            Technical presentation - Application Security: Threats and
Architecture
              (Steve Bellovin)
           IAB Update
           IRTF report
           Town Hall Meeting - technical topics

FRIDAY, August 5, 2005
0800-0900 Beverages - 
0900-1130 Morning Session I
GEN   newtrk    New IETF Standards Track Discussion WG
INT   monami6   Mobile Nodes and Multiple Interfaces in IPv6 BOF
IRTF  hiprg     HIP Research Group
TSV   enum      Telephone Number Mapping WG
TSV   nsis      Next Steps in Signaling WG

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 20 Jul 2005 10:15:43 +0200

It seems like the request to resolve the conflict between SIMPLE and 
VOIPEER has been ignored. Dave also pointed out that VOIPEER conflicts 
with MBONE in that session. I had earlier suggested moving SIMPLE to 
Wednesday 1400-1630 Afternoon Session I. Would moving VOIPEER to the 
Wednesday session instead resolve both conflicts? Or would it create a 
new one for you, Dave?

Thanks,
Hisham

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 20 Jul 2005 12:13:05 +0200

Emails to [email-masked] are bouncing (too many Received headers). We 
MUST fix the conflicts below.

Hisham

---

From: Pete Resnick <[email-masked]>
Date: Wed, 20 Jul 2005 07:21:38 -0500

Speaking entirely "sans chapeaux".

On 7/19/05 at 7:38 PM -0700, Ted Hardie wrote:

>ECRIT, which is opposite LEMONADE

On 7/20/05 at 10:15 AM +0200, Hisham Khartabil wrote:

>conflict between SIMPLE and VOIPEER
>VOIPEER conflicts with MBONE

It seems to me that an awful lot of the conflicts I have been seeing 
over the past several meetings are with Transport area groups, and 
(though not the case with MBONE above), most of those are conflicts 
with Applications areas groups. And although I understand the 
historical reasons, it also seems to me that a good bunch of the 
Transport groups (especially SIP-related ones) are really not 
transport layer groups at all, but are application (or at least, 
"above transport layer") groups. Also note that Applications 
currently has 14 active WGs, whereas Transport has 26 (almost 
double!).

Might I suggest that it would be a great deal easier on the 
scheduling folks at the secretariat (and they can speak up for 
themselves; they've been copied on this message) as well as 
participants if some of those more application-layer Transport groups 
were moved to the Applications Area? Certainly in the short term, 
that would mean that Transport ADs would have to remain as Technical 
Advisors to some of those groups and therefore wouldn't help much 
with the scheduling conflicts (since the ADs are still going to have 
to cover those groups). However, in the long term the Nomcom can get 
appropriate Applications ADs who can cover those groups themselves 
and the scheduling conflicts would be greatly lessened, for 
particpants and ADs alike. It would also redistribute WGs so that 
Transport does not have twice as many WGs as Applications even though 
they have the same number of ADs.

The current state of affairs seems silly.

Just a hatless suggestion.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 20 Jul 2005 09:24:26 -0400

Pete, I sort of understand what you are saying but I think that balancing
the WG between two areas is the wrong approach. I don't see the problem so
much as the ADs but the participants. There is basically a large group of
people at IETF that work in what I will loosely call "real time multimedia
systems". Any label is no doubt bad but whatever you call it, this groups
shows up in select WGs all over the place. 2/3 of the people in BEHAVE
arguing about ICMP with UDP will be out of this group - because they need
this to work. Most the people in SIMPLE arguing about what a tuple is, will
be from this group. They show up in sip, sipping, avt, mmusic, enum, xcon,
behave, simple. Some smaller subset go to lemonade, speechsc, iptel, etc.
They might go do a WG, such as midcom for awhile, then stop going once the
piece of work they were interested in was done. You know the crowd I mean.

The problem is any time we create a conflict of two groups inside this "real
time multimedia" we have a ton of people upset about it - because it causes
real problems for them. What happens in how SIP peers had profound impact
for IM applications and the SIMPLE people would like to get their
requirements in and hear what is going on.

So what's my suggestions - well I guess we could rearrange half the WG into
a new area but that sounds like it would only try to push more thought an
already rate limited pair of ADs. I think it might  be better to just
explicitly acknowledge which groups are in this "real time multimedia"
(please help me I need a better label) and do our best not to schedule
conflicts between them - we already pretty much do this. It would also help
decide if the a given area wanted to take on new groups. If we are adding a
new WG in this "real time multimedia" space, we need to consider the impact
across all the scheduling not just that one particular area it is in.

Cullen

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Jul 2005 06:44:10 -0700

> Wednesday session instead resolve both conflicts? Or would it create a 

	Hisham,

	Wednesday PM creates a new conflict for me. I've asked
	the secretariat to look into it.

	Thanks,

	Dave

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Jul 2005 09:58:35 -0400

As an innocent bystander the following question has crossed my mind:

	what were the conflict lists that were provided to Fortec
	by the affected working group chairs?

I know that for my working group I include groups that are in conflict
regardless of the area the conflicting group or bof is located in.

Jeffrey Altman

---

From: David Meyer <[email-masked]>
Date: Wed, 20 Jul 2005 07:16:46 -0700

> regardless of the area the conflicting group or bof is located in.

	FWIW, I provided an extensive set of WGs and BOFs with my
	scheduling request(s), which appears to be part of the
	problem. What I've done is to suggest to Marcia that she
	drop out as many constraints as possible wrt MBONED; this
	would be PIM (MBONED minimally needs the PIM folks),
	GROW, DNSOP, SHIM6, IMAD, and VOIPEER (my WGs/BOFs/or
	where I'm technical advisor). 

	I'm hoping this will help Marcia and the folks who are
	trying to make this all happen satisfy as many of the
	constraints as possible.

	Dave

---

From: Andrew Newton <[email-masked]>
Date: Wed, 20 Jul 2005 10:49:35 -0400

Is the RUI (Remote UI) BoF scheduled twice?

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 20 Jul 2005 11:09:44 -0400

No, it's only scheduled for the Tuesday session.  I saw this earlier and
asked Marcia the same question; she noted that the Thursday session should
have been removed when the BOF was originally scheduled for Thursday and
then moved to Tuesday.

-Scott-

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Wednesday, July 20, 2005 10:50 AM
> To: IETF Agenda
> Cc: Working Group Chairs; [email-masked]; [email-masked]
> Subject: Re: 63rd IETF - DRAFT Agenda 
>

---

From: Marcia Beaulieu <[email-masked]>
Date: Wed, 20 Jul 2005 10:24:45 -0500

Hisham,

I have seen a few comments about the list of "conflicts to avoid" being 
ignored.

Without going into a long explanation about what needs to be considered 
when scheduling
the agenda, because there is a lot to be considered, let me assure you that 
requests are
NOT being ignored.  It is just that not all conflicts can be avoided.

Marcia

At 03:15 AM 7/20/2005, Hisham Khartabil wrote:
>Wednesday session instead resolve both conflicts? Or would it create a new 
>one for you, Dave?
>
>Thanks,
>Hisham
>

---

From: Marcia Beaulieu <[email-masked]>
Date: Wed, 20 Jul 2005 10:40:45 -0500

Pete,

I wanted to thank you for your note and to let you know I appreciate that you
understand the scheduling situation.

Thanks,

Marcia

At 07:21 AM 7/20/2005, Pete Resnick wrote:
>It seems to me that an awful lot of the conflicts I have been seeing over 
>the past several meetings are with Transport area groups, and (though not 
>the case with MBONE above), most of those are conflicts with Applications 
>areas groups. And although I understand the historical reasons, it also 
>seems to me that a good bunch of the Transport groups (especially 
>SIP-related ones) are really not transport layer groups at all, but are 
>application (or at least, "above transport layer") groups. Also note that 
>Applications currently has 14 active WGs, whereas Transport has 26 (almost 
>double!).
>
>Might I suggest that it would be a great deal easier on the scheduling 
>folks at the secretariat (and they can speak up for themselves; they've 
>been copied on this message) as well as participants if some of those more 
>application-layer Transport groups were moved to the Applications Area? 
>Certainly in the short term, that would mean that Transport ADs would have 
>to remain as Technical Advisors to some of those groups and therefore 
>wouldn't help much with the scheduling conflicts (since the ADs are still 
>going to have to cover those groups). However, in the long term the Nomcom 
>can get appropriate Applications ADs who can cover those groups themselves 
>and the scheduling conflicts would be greatly lessened, for particpants 
>and ADs alike. It would also redistribute WGs so that Transport does not 
>have twice as many WGs as Applications even though they have the same 
>number of ADs.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jul 2005 09:12:45 -0700

>Speaking entirely "sans chapeaux".

I agree with Pete. It's pretty clear from an IETF-level perspective 
(not a meeting-planning perspective) that this gang of topics (or, as 
Cullen describes it, gang of people) have a lot of WGs split into two 
areas.

My proposal is that Ted and Scott and Jon and Allison figure out 
which of the WGs are really application-oriented, and in the marginal 
cases, which could become so with a small charter change. This 
discussion might even lead to the formation of a new Area for 
real-timliness, although it would be easier if the split was really 
"these are applications of real-time, these are transport issues of 
real-time".

--Paul Hoffman, Director
--VPN Consortium

---

From: Melinda Shore <[email-masked]>
Date: Wed, 20 Jul 2005 12:37:51 -0400

Paul Hoffman wrote:
> My proposal is that Ted and Scott and Jon and Allison figure out which 
> of the WGs are really application-oriented, and in the marginal cases, 
> which could become so with a small charter change. 

I think it's been clear for some time that a number of
the telephony/messaging working groups in the Transport
Area are a bad fit, although not all of them are.  Moving
working groups around wouldn't solve the scheduling problem,
though, since someone who's interested in something isn't
going to become less interested because a group is in a
different area.  Come to think of it, that may not be true,
although I do think that it's the case that someone who's
*working* on something isn't going to stop working on it
if the working group is moved.

I also think that in a lot of cases the conflicts are
with people who are interested in something rather than
people who are working on something, which is a lot less
compelling.  It might be worthwhile to find a way to
quantify this.

However, I have a different proposal, which is this:  since
the scheduling problem is basically intractible and since
the IETF nominally does its work on mailing lists and since
we have vastly improved meeting collaboration tools (including
streaming audio from all rooms and Jabber transcripts when
a "volunteer" can be coerced), it may be time for those
of us whose work touches a lot of working groups to suck it
up and either give up on being able to attend all the sessions
we'd like or rely on a colleague to provide coverage (and
with instant messaging now ubiquitous the colleague can even
contact you in real time if something comes up during a
session).  The Secretariat is facing an impossible problem
and good for them for trying to accommodate everybody but
I think we need to be realistic.

I agree that it may be time to look at reorganizing the
Transport Area, but unfortunately I don't think doing so
would solve the scheduling problem.

Melinda

---

From: Ned Freed <[email-masked]>
Date: Wed, 20 Jul 2005 10:38:34 -0700 (PDT)

> Cullen describes it, gang of people) have a lot of WGs split into two

I agree as well, although I have to say when it comes to reconciling this I'm
glad I'm not an Apps AD any longer...

> "these are applications of real-time, these are transport issues of

Seems like a reasonable way to proceed.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Wed, 20 Jul 2005 14:24:51 -0400

Another conflicting cross-area "meta-grouping" that isn't nearly as
large, but definitely affects me, is the "security mechanism groups". In
particular, the SASL WG and the upcoming SECMECH BOF deal with security
mechanisms that are implemented at the application layer. The people
that attend these will be a cross section of applications folk and
security folk. (SECMECH, according to the BOF description, is attempting
to subsume to a degree SASL, GSSAPI, EAP, and others.)

The associated conflict with this meta-grouping is LEMONADE's first
meeting with the SECMECH BOF. But I don't have any suggestion on how to
resolve the conflict because of the extensive number of APP and SEC
meetings already spread out across the week.

	Tony Hansen
	[email-masked]

The conflict I see from above is

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2005 01:11:02 +0200

Let's be clear: it is literally impossible to avoid all clashes.
Whatever we do, and I have full confidence that Marcia does
the best possible, there will always be some people who find
that they need to be in two or even three places at once.

When that has happened to me in the past, I have approached
the WG chairs concerned to get an idea of the likely timings,
and watched the jabber rooms in order to decide when to
switch meetings.

Now if someone is supposed to be chairing two meetings
at the same time, that can be tricky... but please try and
state that problem explicitly if it arises.

     Brian

Marcia Beaulieu wrote:
> the agenda, because there is a lot to be considered, let me assure you 
> that requests are
>>> 1300-1430 NewcomerâEUR^(TM)s Training (English) -
>>> 1000-1030 Break (Beverages provided) âEUR"
>>> 1000-1030 Break (Beverages provided) âEUR"
>>> 1000-1030 Break (Beverages provided) âEUR"
>>> 0800-0900 Beverages âEUR"
>>> 1000-1030 Break (Beverages provided) âEUR"

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2005 01:19:44 +0200

> Seems like a reasonable way to proceed.

It may be worth thinking about, but as has been pointed out, if the subject
matter of two WGs clashes, juggling the Areas will do nothing to reduce
agenda clashes.

    Brian

---

From: Ned Freed <[email-masked]>
Date: Wed, 20 Jul 2005 16:48:20 -0700 (PDT)

> matter of two WGs clashes, juggling the Areas will do nothing to reduce

Actually, I don't think that's true. A key scheduling constraint is trying
to make it possible for the ADs to be at the right meetings. A situation
where there's a serious imbalance of WGs in one area versus another
makes that constraint much harder to satisfy.

				Ned

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Jul 2005 18:58:02 -0500

>regardless of the area the conflicting group or bof is located in.

I think part of the problem is that, while WG chairs know very well 
ahead of time what other WGs they conflict with, it's not always as 
clear cut in the case of BOFs. The specific conflict that Hisham is 
highlighting -- SIMPLE and VOIPEER -- is between a working group and a 
BOF that the SIMPLE chair who requested the slot may not have been aware 
of. (I have not validated this theory, but it is a situation that I can 
easily envision myself in).

/a

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 20 Jul 2005 23:33:30 -0400

Hi Brian,

>matter of two WGs clashes, juggling the Areas will do nothing to reduce

While this seems logical, it actually isn't correct...

One of the criteria used in scheduling is that an AD should be able 
to go to all of the WGs for which he/she is the responsible AD 
(assuming they will fit in the available slots).  Also, both ADs from 
an area will typically attend their own area meeting and any BOFs in 
their area. This means that related WGs within an area are unlikely 
to conflict with each other (because they will often have the same 
AD) and that there will typically be no more than one or two WGs from 
the same area that are meeting at the same time.

So, if there are 5 WGs in the IETF that are related, they all want a 
2 hours slot, and they are all in the same area with the same 
responsible AD, the AD/area scheduling constraints will be aligned 
with the desire for those groups not to overlap, and they probably 
won't.

If those five groups are spread across three different areas with 
three different ADs, then it is possible that up to three of them 
will be scheduled opposite each other (unless folks explicitly 
request otherwise), especially if the ADs involved all state that 
they want to attend an overlapping set of other meetings (such 
general area groups, an open IAB meeting or particular BOFs).

Margaret

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Jul 2005 11:50:14 +0300

We clearly do have serious scheduling problems in a number
of cases -- not because of Marcia (thanks for the hard work
you are doing!) but because a lot of meetings need to be
packed in a short amount of time, often with overlapping
subjects and the same key people.

The IETF does have  a large set of people interested
in the multimedia/voice/realtime communication/signaling
work. And the transport/apps split between WGs has
been a bit confusing at times. There may also be other topic
areas that have a lot of conflicts, I've at least personally
felt that its hard to cover all mobility/wireless topics.

But before we spring into action, lets think a little bit
about the different types of constraints that create
problems for our scheduling. We are limited by

o  IETF meeting wall time (including the early leavers)
o  Meeting site room configuration
o  Availability of the WG chairs
o  Having ADs be present in the meetings, particularly BOFs
o  Availability of the key contributors (editors, authors, reviewers,
    people who have read the drafts)
o  Availability of the other people in the WG (though I'm unsure if
    this should be a major consideration if they don't belong to the
    above group)

It may be worthwhile to think about ways to address
all these issues. Brian already took actions to make it
clearer to everyone that Friday is a meeting day too.
But getting even a significant amount of additional meeting
time is actually easy: just organize more interim meetings.
Perhaps the multimedia communication folks have already
organized joint interim meetings, but if not, they should.
And maybe if you just held a 3-day interim meeting you
could do with one 2.5 hour slot in the real meeting, instead
of 2x2.5?

My gut feeling is that room configuration is not
a limiting factor. Others may have better info.

Chairs -- from what I can see, most IETF WG chairs
are relatively experienced (read: need to go to several
groups). Hiring more junior chairs as 2nd or 3rd chairs
would make it possible to run a meeting even if one
of the chairs has a conflict.

I believe the 'key contributor' conflicts are pretty serious.
I don't know if others have had the same feeling, but ever
since the industry downturn it has seemed that its more
and more the same people who attempt to do everything
-- we've got people who contribute in a dozen working
groups, folks who write up to 50 Internet Drafts etc.
What would help here is convincing your company/
institution that they can actually send MORE people to the
meeting, instead of expecting the same old person(s) to handle
all IETF work. Of course, this helps only if those new persons
actually get some tasks, such as editor, chair, design team
member, etc. positions. And its going to be tough because
those new people are not going to be as experienced as you
regular 12-WG contributor is. But its time talk to your manager
about hiring some new people.

AD availability may be improved through a reorg,
but only if you move WGs from an overloaded AD
to a less overloaded AD. Adding ADs might also help,
or letting some stable groups meet on their own. Merging
groups would help otherwise, but IMHO many of the
groups we have in, say, the multimedia communication
area are already too large to begin with. And cutting down
the amount of work IETF does in this area would obviously
help this and other constraints, but I wouldn't like that to
happen -- its important work and we need to get it right
if we care for the Internet.

--Jari

---

From: Richard Shockey <[email-masked]>
Date: Wed, 20 Jul 2005 22:13:09 -0400

Melinda Shore wrote:

>> cases, which could become so with a small charter change. 
>
>
> different area.

Well we could face the issue that in many respects this is becoming the 
Internet Telephony Engineering Task Force. :-) 

Just look at the WG numbers.  So what it is now 5 SIP WG's ..SIP SIPPING 
SIMPLE XCON..and dont forget ENUM what is ENUM if not to support SIP. 
Looked at the attendence numbers ? What percent of total IETF 
participation is related to these WG's?

> would solve the scheduling problem.

no it will not ...

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1
815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 21 Jul 2005 07:59:52 -0700

Richard,

XCON is not a "SIP" working group.  XCON is chartered to be protocol 
agnostic.  The "SIPish" working groups are SIP, SIPPING, and SIMPLE.  
MMUSIC definitely has an affinity for SIP, but XCON is more like AVT.  
Its output can be used by anyone.

Still, I agree that there are enough WGs around that are related to 
"interactive multimedia" and/or "internet telephony" that we should 
consider reshuffling or adding a new area.

thanks,
-rohan

On Jul 20, 2005, at 19:13, Richard Shockey wrote:

>>> which of the WGs are really application-oriented, and in the 
>>> marginal cases, which could become so with a small charter change.
>>
>>
> Well we could face the issue that in many respects this is becoming 
> the Internet Telephony Engineering Task Force. :-)
> Just look at the WG numbers.  So what it is now 5 SIP WG's ..SIP 
> SIPPING SIMPLE XCON..and dont forget ENUM what is ENUM if not to 
> support SIP. Looked at the attendence numbers ? What percent of total 
> IETF participation is related to these WG's?
>
>>

---

From: Derek Atkins <[email-masked]>
Date: Thu, 21 Jul 2005 16:32:27 -0400

Hi,

Sorry to be a pain, but the editor of the OpenPGP draft just let
me know that he wont be arriving until 10am on Monday, which makes
it hard for him to present at 9am.  Is there any chance OpenPGP
could be moved?  Maybe to Tuesday at 9am?

Thanks,

-derek

IETF Agenda <[email-masked]> writes:

[snip]
> Draft Agenda of the Sixty-third IETF
[snip]
> TSV   ieprep    Internet Emergency Preparedness WG
[snip]

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant