Subject: [rgchairs] 63rd IETF Agenda - DRAFT

From: IETF Secretariat <[email-masked]>
Date: Mon, 11 Jul 2005 17:58:55 -0400

Attached please find the 1st draft of the agenda.  Please send comments to
[email-masked]

Every effort has been made to accommodate all the requests made by the chairs,
unfortuantely, not all requests could be met.  If your working group had asked
for a longer session than the one you are scheduled in, perhaps an additional
session can be scheduled.  Due to scheduling contraints, it was not always
possible to schedule groups in their requested length of session.
==========================================================================

Draft Agenda of the Sixty-third IETF
July 31 - August 5, 2005
As of 7/11/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-1930 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	mmuisc	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
RTG	pce	Path Computation Element 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
INT	shim6	Site Multihoming by IPv6 Intermediation WG
OPS	psamp	Packet Sampling WG
SEC	kink	Kerberized Internet Negotiation of Keys 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
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
GEN	techspec	Requirements for IETF Technical Specification Publication 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
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 W
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	mobike	IKEv2 Mobility and Multihoming WG
TSV	tsvwg	Transport Area WG

1630-1700 Break (Refreshments provided) - 
17:00-19:30 Plenary - Main Amphitheatre (Level 1)

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 WG
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
INT	eap	Extensible Authentication Protocol 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 Plenary - Main Amphitheatre (Level 1)

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

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

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 12 Jul 2005 18:57:49 +0900

Dear secretariat,

I would like to request a re-schedule of the Monami6 BOF (currently on
Friday) as 2 of the people involved in the setting up of this BOF with
me would not be able to attend Friday due to early flight arrangment.

Also, the NEMO WG is allocated a 2.5 hours slot, 2 hours would be
largely enough this time.

Thanks,
Thierry

On Mon, 11 Jul 2005 17:58:55 -0400

> APP	lemonade	Enhancements to Internet email to Support Diverse
> Service Environments WG

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jul 2005 15:00:38 +0200

Thierry, note that the agenda address is [email-masked]

It's also not new that the IETF continues until Friday
lunchtime - I'm really surprised that people plan to leave
earlier. I'm sure that our scheduler will do what she can, but
the Friday slots have to be used.

     Brian

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 13 Jul 2005 10:49:53 +0900

Hi,

> Thierry, note that the agenda address is [email-masked]
Ah, yes, sorry about that, and thanks for pointing out.

> the Friday slots have to be used.

Yes, I know about that, and I'm always arranging my flight
accordingly and change it to an earlier date if there is nothing
important to attend. 

But I'm not responsive for the other people own flight arrangments,
although for this particular case I have to bear the situation of not
having the right people at hand for the success of this BOF. As the
initiator and chair, I need to ensure the success.

It's notorious that people try to arrange their flight in advance in
order to get cheaper prices, so if we really want people to organize
their trip in a way they consider staying on Friday, we:
1. must issue a draft agenda earlier (I would say 1 month in advance at
the very least
2. in case of agenda changes, no slot should be move to the extremity of
the week
3. people should get used to stay on Friday

The problem for 3 is that some WGs have to play the role of guinea-pig
and this is not acceptable. So, 1 and 2 may be the 1st category's
requirement. May be one eaay way is for some WGs to volunteer for a
Friday BOF ahead of time, with the information spread on the relevant
mailing lists.

A side note, I think it's a bad idea to schedule a BOF on Friday because
many people are not aware of the content of a BOF before they attend;
also BOF need to span a larger audience.

Thierry

>      Brian
> 
> Thierry Ernst wrote:
> > Dear secretariat,
> > 
> > I would like to request a re-schedule of the Monami6 BOF (currently
> > on Friday) as 2 of the people involved in the setting up of this BOF
> > with me would not be able to attend Friday due to early flight
> > arrangment.
> >

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Jul 2005 23:22:38 -0400

On Wednesday, July 13, 2005 10:49:53 AM +0900 Thierry Ernst 
<[email-masked]> wrote:

> order to get cheaper prices,

There's nothing wrong with doing this.  The dates and locations of IETF 
meetings (if not always the exact hotel) are announced well in advance. 
The problem arises when people want to buy tickets far in advance to get 
the cheaper price _and_ tailor their trip so they are there only for one or 
two sessions.  The two just aren't compatible, and making them compatible 
would probably require pushing the whole scheduling process so far out that 
many WG's wouldn't know whether they need to meet or how much time they 
need.

It seems we have this discussion about three times a year, usually on the 
main IETF list, and the arguments rarely change.  You can consult the 
archives to see how the discussion generally goes, or I can summarize for 
you:

A: Please don't schedule me in <time X>; I'll only be there on <day Y>
B: We can't schedule meetings around people's flights; you should plan
   on being there for the entire week of the meeting.
A: But I only want to be there for my meeting, can't you schedule things
   earlier so that I can just fly in for my timeslot?
B: We don't want people to only show up for their one meeting; we want
   them to stick around, attend other sessions, talk to people, etc.
   One big strength of the IETF is bringing together people from a wide
   variety of backgrounds and specialties, and we want to encourage that.
A: But lots of people don't have the budget to stay for a week, or can't
   afford the time away, or their employer won't send them.  Aren't we
   excluding these people?
B: Yes, but what else can we do without fragmenting the IETF into lots
   of little isolated groups.  Besides, scheduling is complicated and
   time-consuming already, making a final agenda early enough would be
   too hard.
A: But you should try, because it would be really useful to me.
B: Lots of WG's won't know that far in advance whether they need to meet
   or how much time they need.  And we don't care about helping people
   who aren't going to contribute outside their one WG.
A: You just want everyone to be forced to come the whole week, and don't
   care that you're screwing the people who can't do that!
B: You don't really care about the IETF, you just want to do whatever
   the hell you feel like doing.
A: You're a fascist!
B: You're an anarchist!
A: You're a Nazi! (*)
X: OK, so much for that thread, time to move on.

At this point, the discussion turns to an equally stimulating topic such as 
whether the IESG has too much power or why last week's major process change 
hasn't yet resulting in either a dramatic improvement in the time it takes 
to go form first-draft to full Standard or the complete implosion of the 
IETF, the Internet, the Universe, or all three.

Seriously folks, a couple of key points:
- We are in the middle of an experiment related to changing the timeline
  for meeting scheduling.  We only do this three times a year, so it is
  far too soon to have enough data to draw conclusions.  Give it some time.

- The process of scheduling an IETF meeting is really hard -- much harder
  than your average conference with several "tracks" of related talks.
  There are a huge number of constraints, a limited number of rooms and
  timeslots; there's not much time in which to get the job done, and
  whatever the outcome, someone will be unhappy.  By all means, point out
  any conflicts you see, and ask for changes you think might help.  But be
  prepared to accept that some conflicts are unavoidable, and some changes
  simply cause too many problems.

- Marcia and the other folks at the IETF Secretariat who work on this
  generally do a fabulous job making it all work out.
  Please cut them some slack.

-- Jeff

* see <http://en.wikipedia.org/wiki/Godwin's_law>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jul 2005 11:03:58 +0200

I've made a mental note that for future meetings, both the web site
and the announcements need to be much more explicit that working sessions
extend through Friday lunchtime. We have to make sure that anyone who
takes a quick glance and books a ticket is not misled.

    Brian

Jeffrey Hutzelman wrote:
> the cheaper price _and_ tailor their trip so they are there only for one 
> or two sessions.  The two just aren't compatible, and making them 
> compatible would probably require pushing the whole scheduling process 
> so far out that many WG's wouldn't know whether they need to meet or how 
> much time they need.
> 
> It seems we have this discussion about three times a year, usually on 
> the main IETF list, and the arguments rarely change.  You can consult 
> the archives to see how the discussion generally goes, or I can 
> summarize for you:
> 
> 
> At this point, the discussion turns to an equally stimulating topic such 
> as whether the IESG has too much power or why last week's major process 
> change hasn't yet resulting in either a dramatic improvement in the time 
> it takes to go form first-draft to full Standard or the complete 
> implosion of the IETF, the Internet, the Universe, or all three.
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jul 2005 13:08:39 +0200

Actually, not.

Firstly there's nothing "guinea pig" about the Friday morning
slots. They've been in regular use for years:

FRIDAY, August 4, 2000
	  	
0800-1000 IETF Registration - South Hall, The Center
0800-0900 Continental Breakfast - The Center
0900-1130 Morning Sessions  	  	  	  	  	  	
South Rm 11/12 APP beep Blocks Extensible Exchange Protocol WG
South Rm 7     APP wrec Web Replication and Caching WG
North Rm 7/12  INT ipoptr IP over Packet Transport Rings BOF *
South Rm 2     OPS snmpconf Configuration Management with SNMP WG
South Rm 10    RTG gsmp General Switch Management Protocol WG
South Rm 9     SEC idwg Intrusion Detection Exchange Format WG
North Rm 1/6   SEC ipsp IP Security Policy WG
South Rm 4     TSV rohc Robust Header Compression WG *

Secondly, it's important that BOFs are spread out over the week.
For the IESG and IAB, being sure that all BOFs are covered by both
IAB and IESG memebers is a key element of our IETF week: BOFs are
where the constituency for new work is evaluated, and IAB and IESG
members need to be there. That's not consistent with concentrating
BOFs on one half day.

     Brian

Thierry Ernst wrote:
> Actually, this is an excellent idea !
> Thierry
> 
> On Wed, 13 Jul 2005 09:00:47 +0200
> Lars Eggert <[email-masked]> wrote:
> 
> 
>>Hi,
>>
>>On 2005-7-13, at 3:49 , Thierry Ernst wrote:
>>
>>>The problem for 3 is that some WGs have to play the role of
>>>guinea-pig and this is not acceptable. So, 1 and 2 may be the 1st
>>>category's requirement. May be one eaay way is for some WGs to
>>>volunteer for a Friday BOF ahead of time, with the information
>>>spread on the relevant mailing lists.
>>>
>>>many people are not aware of the content of a BOF before they
>>>attend; also BOF need to span a larger audience.
>>
>>If you want to achieve (3), which is the right thing to do IMO, then  
>>let's make Friday "BOF day" in Vancouver, announce it well before and 
>>schedule all BOFs then. (Or the IETF after Vancouver if that's too  
>>soon.)
>>
>>Lars
>>-- 
>>Lars Eggert                                     NEC Network
>>Laboratories
>>
>>
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 13 Jul 2005 09:00:47 +0200

Hi,

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 13 Jul 2005 16:48:55 +0900

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 13 Jul 2005 16:12:34 +0800

> > schedule all BOFs then. (Or the IETF after Vancouver if that's too  

But then again, there may be the problem of two closely related BoFs
needs to be at different time slots ...

/rgds
/cwng

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 13 Jul 2005 07:47:19 -0400

In message <[email-masked]>, Lars Eggert wr
ites:

>schedule all BOFs then. (Or the IETF after Vancouver if that's too  

(a) that limits us to 7 BoFs -- not always enough
(b) the IAB tries to cover all BoFs; if there are several that demand 
the same skills, this makes it tough

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 13 Jul 2005 08:16:32 -0400

Hi,

I'm of the impression that changing your RETURN flight generally
doesn't affect the cost, only the initial leg changes flight costs.
That may depend on airlines and other factors of course, but it seems
to me that the people you want to attend the BOF should be able to
,modify their plans without a great deal of financial burden.

That said, I agree with Jeff's post on this topic about this
three-times-a-year discussion.

I suggest you think of this differently - if the people you would like
to have attend the BOF want to have a voice in the process, then they
should arrange their time to be present to be heard; the whole IETF
should not be expected to work around them to ensure their specific
voices are heard.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thierry Ernst
> Sent: Tuesday, July 12, 2005 9:50 PM
> To: Brian E Carpenter
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: 63rd IETF Agenda - DRAFT
> 
> 
> Hi,
> 
guinea-pig
> many people are not aware of the content of a BOF before they
attend;

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 14 Jul 2005 11:27:17 +0900

Hi,

A discussion that is re-started every 4 months is a discussion that
didn't get to an acceptable conclusion ;-)

I just want to point out that, on a general basis, I personaly do not
mind to have a BOF on Friday as long as the IETF is commiting to make
sure people understand they have to plan to attend Friday sessions

So, the next question is how the IETF can make sure that the exepted
people will be able to attend.

I think that yesterday's mail from Brian:
> and the announcements need to be much more explicit that working
> sessions extend through Friday lunchtime. We have to make sure that
> anyone who takes a quick glance and books a ticket is not misled.
is going into the right direction, thus I putting myself into the "wait
and see" mode.

However, I still believe the rough agenda should be planned ahead of
time. I don't buy the argument that WG chairs don't know if they need a
meeting slot and the length ahead of time. I agree that the exact WG
agenda may not be known until the last couple of days, but it's pretty
easy to know if you need to meet with a rough estimation of the time
needed.

If, 3 weeks before the meeting, some WGs think they need more time, then
it might be possible to allocate left-over time slots, if any. Rules
could be defined for that.

It's a question of self-organization, responsabilities and respect for
the people attending the meeting.

(international flight being involved, an important number of people will
still flight back on Thursday evening or Friday morning - and I think
it's a reasonable thing to do for people having a family - so we must be
sensitive about that).

One final note below:
 On Wed, 13 Jul 2005 08:16:32 -0400
> ,modify their plans without a great deal of financial burden.

Just FYI, cheap tickets, at least in the country I live in, must
generally be arranged and edited in advance and no changes are
permitted either inbound and outbound.

Thierry

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 14 Jul 2005 10:20:03 -0700

I can specifically suggest Tuesday 0900-1000 for voipeer, if the BoF  
can fit into a one hour slot.

thanks,
-rohan

On Jul 14, 2005, at 7:33, Hisham Khartabil wrote:

> There is a conflict in the agenda on Thursday Afternoon Session I. A  
> sizeable portion on the VoIP community attend SIMPLE WG meeting and  
> will be interested in attending VOIPEER BOF.
>
> It would be great that when moving the slot, to make sure that no  
> other conflicts occur with sip, sipping, enum, mmusic, ecrit, xcon,  
> behave and avt working groups. It might be much easier to move voipeer  
> since its a bof and I dont think it requires a 2.5 hour slot.
>
> Thanks,
> Hisham
>
>> sip, sipping, simple, enum, mmusic, ecrit, xcon, behave and avt
> On Jul 11, 2005, at 11:58 PM, IETF Secretariat wrote:
>

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 14 Jul 2005 16:33:00 +0200

It would be great that when moving the slot, to make sure that no other  
conflicts occur with sip, sipping, enum, mmusic, ecrit, xcon, behave  
and avt working groups. It might be much easier to move voipeer since  
its a bof and I dont think it requires a 2.5 hour slot.

Thanks,
Hisham

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Jul 2005 08:11:18 -0700

Folks,

> its a bof and I dont think it requires a 2.5 hour slot.

	First, I realize the very difficult scheduling problem
	that the secretariat is facing. I wanted, however, to
	address the time requirements for the BOF. When I was
	discussing this with the ADs, we settled on this length
	for the BOF due to the overwhelming number of folks who
	expressed interest in participating (and their various
	scheduling constraints). In any event, I would rather
	leave the 2.5 hour length as it is, or we won't be able
	to have time for everyone who has expressed interest to
	participate, and to have a reasonable amount of time for
	discussion.  

	Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Jul 2005 10:41:51 -0700

> can fit into a one hour slot.

	Well, I've already given the secretariat the constraints
	that I have, one if which is that we need the bof to be
	on Wed/Thurs due to participant constraints.

	Dave

---

From: Richard Shockey <[email-masked]>
Date: Thu, 14 Jul 2005 13:48:17 -0400

>can fit into a one hour slot.

you have to be kidding ... it could use a 2.5 day slot

It does need to be moved away from SIMPLE..

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: Hisham Khartabil <[email-masked]>
Date: Thu, 14 Jul 2005 20:15:36 +0200

It looks like SIMPLE can be moved into the same time slot (1400-1630 
Afternoon Session I) on Wednesday.

Thanks,
Hisham

---

From: Tom Taylor <[email-masked]>
Date: Thu, 14 Jul 2005 14:41:46 -0400

Is that really true given that you identified a major overlap between 
this and the ENUM potential agenda?

---

From: Richard Shockey <[email-masked]>
Date: Thu, 14 Jul 2005 14:54:31 -0400

At 02:41 PM 7/14/2005, Tom Taylor wrote:

>Is that really true given that you identified a major overlap between this 
>and the ENUM potential agenda?

oh yes...you cant discuss voipeer without understanding what is happening 
in the ENUM WG.

The first order problem is how do you discover a point of 
interconnection..this debate is raging in the ENUM WG.

I just posted our WG agenda. It should be self evident what the overlaps 
are. We are devoting a full 1 1/2 hour to the concept of 
Infrastructure/Carrier ENUM.

IETF 63  Telephone Number Mapping (ENUM) WG Agenda

Chair(s):
Patrik Faltstrom <[email-masked]>
Richard Shockey <[email-masked]>

Transport Area Advisor:
Allison Mankin  <[email-masked]>

Mailing Lists:
General Discussion:[email-masked]
To Subscribe: [email-masked]
In Body: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/

AGENDA BASHING (5 min)

1. Review of the existing drafts - Ready to go top Last call  ( 5-10 M ? )

Title           : ENUM Implementation Issues and Experiences
         Author(s)       : L. Conroy, K. Fujiwara
         Filename        : draft-ietf-enum-experiences-02.txt
         Pages           : 29
         Date            : 2005-7-1

This document captures experience in implementing systems based on
    the ENUM protocol, and experience of ENUM data that have been created
    by others.  As such, it is informational only, and produced as a help
    to others in reporting what is "out there" and the potential pitfalls
    in interpreting the set of documents that specify the protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-experiences-02.txt

2. Final disposition of  IRIS EREG, hopefully to last call. ( 5 Min? )

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newton-iris-ereg-00.txt

3. New/old  work on enumservice registrations  ( 20 M )

3.1
>         Title           : IANA Registration for Enumservice Voice
>         Author(s)       : R. Brandner, et al.
>         Filename        : draft-brandner-enum-voice-00.txt
>         Pages           : 12
>         Date            : 2005-7-7
>
>    This document registers the ENUMservice ^voice^ (which has a defined
>    sub-type ^tel^), as per the IANA registration process defined in the
>    ENUM specification RFC3761.  This service indicates that the contact
>    held in the generated URI can be used to initiate an interactive
>    voice (audio) call.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-brandner-enum-voice-00.txt

3.2
         Title           : IANA Registration for an Enumservice
                           Containing Number Portability and PSTN
                           Signaling Information
         Author(s)       : J. Livingood, R. Shockey
         Filename        : draft-livingood-shockey-enum-npd-00.txt
         Pages           : 8
         Date            : 2005-7-8

    This document registers the Enumservice "npd" and subtype "tel" using
    the URI scheme 'tel:' as per the IANA registration process defined in
    the ENUM specification, RFC 3761.  This data is used to facilitate
    the routing of telephone calls in those countries where Number
    Portability exists.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-livingood-shockey-enum-npd-00.txt

3.3

>         Title           : IANA Registration for ENUMservice Mobile Webpage
>         Author(s)       : J. Ra, et al.
>         Filename        : draft-ra-shin-enum-mobileweb-00.txt
>         Pages           :
>         Date            : 2005-7-7
>
>    This document registers the ENUMservice ^mobweb^ using the URI
>    schemes 'http:' and 'https:' as per the IANA registration process
>    defined in the ENUM specification RFC3761.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ra-shin-enum-mobileweb-00.txt

4. ENUM Validation Issues. 3 Drafts 15 -20

  4.1 ENUM Validation Architecture      draft-mayrhofer-enum-validation-arch-00

         Title           : ENUM Validation Architecture
         Author(s)       : A. Mayrhofer, B. Hoeneisen
         Filename        : draft-mayrhofer-enum-validation-arch-00.txt
         Pages           : 16
         Date            : 2005-7-11

    An ENUM domain name is tightly coupled with the underlying E.164
    number.  The process of verifying whether or not the Registrant of an
    ENUM domain name is identical to the Assignee of the corresponding
    E.164 number is commonly called ^validation^.  This document
    describes validation requirements and a high level architecture for
    an ENUM validation infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-validation-arch-00.txt

4.2  "ENUM Validation Token Format Definition" - 
draft-lendl-enum-validation-token-00.txt

         Title           : ENUM Validation Token Format Definition
         Author(s)       : O. Lendl
         Filename        : draft-lendl-enum-validation-token-00.txt
         Pages           : 16
         Date            : 2005-7-11

    An ENUM domain name is tightly coupled with the underlying E.164
    number.  The process of verifying whether the Registrant of an ENUM
    domain name is identical to the Assignee of the corresponding E.164
    number is commonly called ^validation^.  This document describes an
    signed XML data format -- the Validation Token -- with which
    Validation Entities can convey successful completion of a validation
    procedure in a secure fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lendl-enum-validation-token-00.txt

4.3  Bernie Hoeneisen

   http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.txt
   http://ietf.hoeneisen.ch/draft-ietf-enum-validation-epp-00.html

#################

5. PART 2  1/2 hours. 3 Items

The first order of business is to attempt to create some very basic common 
ground on what is the problem Carrier/Infrastructure/Private ENUM is trying 
to solve based on what we generally understand are the orthogonal interests 
of A. the E.164 number holder vs B. the carrier of record for that number. 
In addition try to place this problem statement in the over all context of 
converged carrier networks and the desire for interconnection and peering.

We are NOT going to solve the Carrier ENUM definition and problem statement 
in Paris but there needs to be some baseline before we can generally review 
the drafts at hand.

Steve Lind has attempted to capture some of the ongoing discussion. This 
was not ready before the ID cut off but anyone coming to Paris is 
encouraged to read and comment on this ID on the list.

http://www.sdlind.com/draft-lind-infrastructure-enum-reqs-00.txt

#################

Discussion of Pfautz etal drafts on Carrier ENUM - Requirements ?

>  Title           : IANA Carrier/User enumservice Registration
>         Author(s)       : P. Pfautz, et al.
>         Filename        : draft-pfautz-lind-enum-carrier-user-00.txt
>         Pages           : 10
>         Date            : 2005-6-6
>
>This document registers, pursuant to the guidelines in RFC 3761,
>    tElephone NUmber Mapping (ENUM) services to allow a single registry
>    to support end user and carrier services with independent name
>    servers holding the terminal NAPTR (Naming Authority Pointer) records
>    identifying the communication services for each.  The to-be-
>    registered enumservices make use of non-terminal NAPTR records and
>    DDDS (Dynamic Delegation Discovery System) replacement to achieve
>    this end.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-pfautz-lind-enum-carrier-user-00.txt

"Combined User and Carrier ENUM in the e164.arpa tree"

         Title           : Combined User and Carrier ENUM in the e164.arpa tree
         Author(s)       : M. Haberler, R. Stastny
         Filename        : draft-haberler-carrier-enum-00.txt
         Pages           : 10
         Date            : 2005-7-11

    ENUM as defined now in RFC3761 is not well suited for the purpose of
    interconnection by carriers, as can be seen by the use of various
    private tree arrangements based on ENUM mechanisms.  A combined end-
    user and carrier ENUM tree solution would leverage the ENUM
    infrastructure in e164.arpa, increase resolution rates, and decrease
    the cost per registered telephone number.  This document describes a
    minimally invasive scheme to provide both end-user and carrier data
    in ENUM.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-haberler-carrier-enum-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Non-Terminal NAPTR Processing: A Modest Proposal
>         Author(s)       : L. Conroy
>         Filename        : draft-conroy-enum-modestproposal-00.txt
>         Pages           : 12
>         Date            : 2005-7-6
>
>    Recent Discussions within the IETF and in other fora have highlighted
>    differences in interpretation of the set of standards associated with
>    ENUM and DDDS, on which it relies.  Specifically, the operation and
>    semantics surrounding support for non-terminal NAPTRs has led to some
>    confusion.  This document is an attempt to add clarification to non-
>    terminal NAPTR processing.  In this, it clarifies RFC3403.  A
>    subsequent document will build on this one to extend RFC3761 further,
>    permitting registration of non-terminal Enumservices.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-conroy-enum-modestproposal-00.txt

6.  Discussion of ENUM WG recharter ?

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Jul 2005 14:47:31 -0700

Folks,

	First,  I specifically asked the secretariat to avoid
	SHIM6 (which is scheduled for Tuesday AM), as I am one of
	the technical advisors there. I note, however, that the
	time slot which voipeer is currently scheduled has other
	conflicts for me (as it overlaps with MBONED), and I have
	informed the secretariat of this conflict.

	Second, as I described in an earlier email, much thought
	has gone into trying to accommodate all of the folks who
	want to participate (and their varying scheduling
	constraints), and optimize the amount of time needed, so
	I would like the BOF length as we have previously decided.

	Dave

> >>1300-1430 Newcomerâ€™s Training (English) -
> >>1000-1030 Break (Beverages provided) â€“
> >>1000-1030 Break (Beverages provided) â€“
> >>Service
> >>1000-1030 Break (Beverages provided) â€“
> >>Service
> >>0800-0900 Beverages â€“
> >>1000-1030 Break (Beverages provided) â€“

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Jul 2005 15:25:15 -0700

Marcia,

Phil and I would like to get the NETLMM BOF moved from Monday morning until
later in the week.

Wed. or Thurs. morning work better.

We also were assigned an hour slot, and think we need an hour and a half.

Can we have it changed?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Jul 2005 15:26:15 -0700

Sorry, forgot to change the subject line.

            jak

---

From: Pete Resnick <[email-masked]>
Date: Thu, 14 Jul 2005 23:06:23 -0500

On 7/11/05 at 5:58 PM -0400, IETF Secretariat wrote:

>TUESDAY, August 2, 2005
>1000-1030 Break (Beverages provided)

>TSV	sip	Session Initiation Protocol WG

I suspect that LEMONADE is not a conflict with any of these.

Just a 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: Sat, 16 Jul 2005 20:25:01 -0400

I hope we can find a way to solve this conflict. At first glance it might
not seem that these two subjects have much overlap - they don't. The problem
is that the authors of most the SIMPLE documents (and presumably the folks
who will be requesting agenda time in SIMPLE) are also folks that have very
involved and had useful opinions on some of our previous peering
discussions. 

Cullen

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 20 Jul 2005 10:00:24 -0700

Folks,

I understand that voipeer was approved and the ADs agreed on 2.5 hours. 
  My personal impression is that if a BoF requires more than 1 hour, 
either the scope is too large or there has not been enough mailing list 
or ad-hoc discussion yet.

I think the scheduling problem would be easier if we restrict BoFs to 1 
hour in the future.  Active WGs should take precedence and this is one 
way to do that.

Thanks again Marcia for making the best of an impossible situation.

thanks,
-rohan

On Jul 14, 2005, at 8:11, David Meyer wrote:
>> other

---

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

> hour in the future.  Active WGs should take precedence and this is one 

I'm not sure I'd want a rigid rule for BOFs. If a BOF is very close to being
a WG (charter out for review but not yet approved, for example) it seems
reasonable to give it a longer slot. But certainly if it's really exploratory,
it should be shorter.

    Brian