Subject: [rgchairs] RE: 63rd IETF Agenda - DRAFT

From: [email-masked]
Date: Thu, 14 Jul 2005 06:36:49 +0300

Andrew,

> > Not to pick on you specificially, but I am always dismayed folks not
> > planning to attend on Friday.
> 
> I'm not.  I know quite a few people who don't plan on attending  
> Friday sessions.  For this past meeting in Minneapolis, I knew of  
> quite a few people who left on Thursday morning.
> 
> The simple fact of the matter is that many people have limited time  
> and limited budget.  And some people have little choice regarding  
> airline schedules, either they take the 11:00am flight on Friday or  
> they wait an entire extra day for the 11:00am flight on Saturday.   
> And when meetings are held in places like Paris, some people are  
> under considerable pressure not to give the appearance of a  
> boondoggle. There are a host of real world issues many participants  
> must grapple with, and telling them that they should be more devoted  
> to the IETF is not helpful.
> 
> As for scheduling, I'd rather see the extra plenary session abandoned  
> and have that time dedicated for more working group and bof slots.

As you mentioned above (folks leaving on Thursday morning), I'm sure if
we did that - late night meeting on Thursday - we have just as many people
complaining about that, and requesting not to be scheduled on Thursday
evening because they have a flight to catch.  

IETF meetings are not mandatory for people to attend; if attending meetings
are problematic or subject to intense scrutiny by someone's travel department,
then they can just particpate on the mailing list.  There are plenty of people
who do this already.

John

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 14 Jul 2005 10:39:20 -0400

I have a conflict with then newly created TRILL working group
and idr on Thursday.  Can you move one or the other?

I would have mentioned TRILL but it's status was unclear. 

Sue Hares

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hisham Khartabil
Sent: Thursday, July 14, 2005 10:33 AM
To: IETF Secretariat
Cc: Working Group Chairs; [email-masked]; [email-masked]
Subject: Re: 63rd IETF Agenda - DRAFT 

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:

> 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âEUR(tm)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) âEUR"
> 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) âEUR"
> 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) âEUR"
> 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 âEUR"
> 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) âEUR"
> 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
>
>
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 14 Jul 2005 22:20:55 -0400

Wednesday afternoon would also conflict with LEMONADE.

Not to start a fire, but given that it is a BOF and it probably does need a
lot of time, how about Friday?

Let's face it, there are a lot of "personalities" and "emotions" on this
topic.  Holding it on Friday will self-limit participation to those that
REALLY need to be involved.  They will MAKE the effort to be there.  I don't
buy the "Friday is inconvenient" argument on this one...

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 14, 2005 2:55 PM
> To: Tom Taylor; Richard Shockey
> Cc: [email-masked]; IETF Secretariat; Working Group 
> Chairs; [email-masked]
> 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-en
> um-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-mobile
> web-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-valid
> ation-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-validatio
> n-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-ca
> rrier-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-modestp
> roposal-00.txt
> 
> 
> 6.  Discussion of ENUM WG recharter ?
> 
> 
> 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 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: Eric Burger <[email-masked]>
Date: Fri, 15 Jul 2005 06:29:13 -0400

Afternoon would conflict with SIP.  Probably more overlap with SIP than
ECRIT.  SIP & ECRIT conflict with eachother. 

-----Original Message-----
From: [email-masked]
To: IETF Secretariat
Cc: Working Group Chairs; [email-masked]; [email-masked]
Sent: 7/15/05 12:06 AM
Subject: Re: 63rd IETF Agenda - DRAFT

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

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

I suspect that LEMONADE and ECRIT are a conflict. However, later that

>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: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 15 Jul 2005 12:49:47 +0200

eric, you are certainly right. there is a large community in sip that is also interested in ecrit.

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Eric Burger
> Gesendet: Freitag, 15. Juli 2005 12:29
> An: 'Pete Resnick '; 'IETF Secretariat '
> Cc: 'Working Group Chairs '; [email-masked] '; 
> [email-masked] '
> Betreff: RE: 63rd IETF Agenda - DRAFT
> 
>