Subject: 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

---

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...

> -----Original Message-----
> 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]
> Subject: Re: 63rd IETF Agenda - DRAFT
> 
> 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)
>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

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

>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

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
> 
>