[Enum] Raw Preliminary Meeting notes from IETF ENUM WG in San Francisco

[Richard Shockey <[e-mail]>]

Many thanks to Brian for taking these notes. I apologize for not having 
posted these sooner. I've added text based on my memory if there are any 
clarifications here let me know. I'll clean up the text in the meantime ...

Remind me about the right initials behind the right folks

ENUM Meeting Minutes - Brian Rosen Scribe

WEDNESDAY, March 19, 2003
0900-1130 Morning Sessions
TSV     enum      Telephone Number Mapping WG


AGENDA BASH

   JP Jon Peterson - vovi clarifications helped, do we need less time..can 
this be devoted to 2916
   RS Rich Shockey - we'll take it's much time as we need to finish the 
review of 2916bis this is the most important task for this meeting.

Thanks to Scott Bradner for the creation of the ENUM WG and his support for 
many many years.  ( Applause )

ITEM 1 . 2916bis 04  review...

a) Some feel DNSSEC with opt-in makes it possible to deploy

PF- Patrik Faltstrom  Don't see any connection.  WG should be neutral
KM - helpful
SB Scott Bradner - Well discussed in other venues, no need to discuss ??  - 
DNSSEC without opt-in still useful

hum for if it should remain neutral - WIDE AGREEMENT

b) Some requests to make latest proposed DNSSEC language stronger.  Want to 
be MUST, but DNSSEC not ready yet

PF  Patrik Faltstrom Patrik Faltstrom- DNSSEC at SHOULD needs some language
MM Mike Mealling - Text talks about ongoing work should be deleted
SB Scott Bradner - SHOULD is strong guidance
JP Jon Peterson - IESG wants mandatory-to-implement language
SB - DNSSEC is not baked, so can't require it yet.  Could announce intentions
HA - Can say it will be a MUST some day
JH - Talking futures doesn't make much sense.  May want under some 
circumstances to do other things
RS - Rich Shockey What do we do?
DC Dave Crocker - Doesn't like future intentions text.  State why it wasn't
      a MUST, and that's good enough. State requirements for MUST.
JP - Jon Peterson Might consider add more text in responsibilities of service
      designers part of security considerations
SB Scott Bradner - DC's idea good, put short synopsis of DNSSEC in 
doc,  say "when it's available, SHOULD becomes MUST"

No significant objections to SHOULD.
Will add some text to security section on consequences of not implementing it.
Text to list within a few hours

c) Issues surrounding partial number resolution

Client given number outside dialing plan, doesn't know it's not a full
E.164, but you don't know it.  May get into middle of ENUM, not edge.
Do we need a way to figure out that it's busted

JP - Jon Peterson Little error handling is available.  Need to give 
advice.   Okay if just simple statement that it could happen
LC - Intentional partial lookup may be okay.  Don't restrict anything
JP - Jon Peterson Intentional query for partial is a bad idea because we 
don't have any meaning for it, so don't allow.
RS - Intential Partial Resolution is out of scope for this doc
LC - Don't know if there is a good reason to do it, but there might 
be.  Okay for a heads-up on no definition of what  can be found.
KM - This is an application issue, don't need to see any text
DC - Out of scope is right, don't even mention it
JP - Jon Peterson Still wants to warn about the problem
DC - Dave Crocker Needs OPS discussion because will cause massive numbers 
of failed queries, much more than current operation
D? - Worried about numbers that are subsets of other numbers
JP - Jon Peterson Tel URI worried about that, we don't think it's possible
KD - Sub-addresses are not E.164.  Service numbers are not E.164s  Doesn't 
believe it can happen
?? - It happens in common practice, doesn't matter if they aren't E.164s
?? - "Pilot" numbers exist
?? - Public space means E.164, problem doesn't exist
JP - Jon Peterson If you have any subset E.164s, send them to list

hum on Text in draft is acceptable - NO ROUGH CONSENSUS

Option 1 - current text
Option 2 - change text to say that things could be at partial nodes, but 
not E2Us, and thats's all we spec
option 3 - declare partial resolution is out of scope

Show of hands - little sentiment for option 1.  NO ROUGH CONSENSUS
between option 2 and 3.

LC - I have a pair of subset (Austria)

?? - Might be able to come up with text that works

Possible to do this before end of meeting, but move on at the moment

ITEM 2. draft-toyoda-faxservice-enum-00.txt

Fax over email.  Better if you can use telephone number as an address.
So, map telephone numbers to an email address, using ENUM.
Defines the NAPTR for this purpose.  ifax service and mailto URI.

RS Rich Shockey Document will move forward in the FAX WG

ITEM 3. draft-brandner-enumservice-msg-00.txt RBrandner
    draft-brandner-enumservice-vovi-00.txt
    draft-brandner-enumservice-webft-00.txt

webft - obvious, but since it's a public database, don't put usernames or 
paswords in there!

msg - will incorporate MMS comments.  Solicit other comments

hum for accepting these two into enum - ROUGH CONSENSUS TO MAKE THESE 
DOCUMENTS WG ITEMS

Allison Mankin- Do we have the right people looking at the MMS stuff?
Lawrence Conrad - Yes, the one response we got was from an MMS person

vovi - lots of argument on list.  Split into two drafts.

Non contentious and contentious.  Basically the sip:voice and sip:video are 
the contentious parts.

H.323 stuff is still there.  Some issues regarding H.323 version capability 
and what is deployed.  Current deployed H.323 could use the current 
proposed mechanisms.

Orit Levin - Still need discussions to reach consensus.  SIP and    current 
H.323 work in similar ways.
LC - V4 H.323 would have same issues as sip, current stuff
    could use vovi
OL - vovi for V2 H.323 is usefull.
FA - H.323 versions won't matter much, vovi is usefull
CJ - version issues are more nuanced, but it doesn't matter

Hum - accept vovi without sip stuff as a WG item - NO OPPOSITION, BUT 
LITTLE SUPPORT.

JP - Jon Peterson Not a lot of support, let's not make it a WG item
BR - Brian Rosen can be an individual effort
LC - Larry Conroy Is there something we should fix?  Many people are not 
here, can still be

WG consensus to progress the vovi draft sans references to SIP
Hum for WG item vs individual draft - NO CONSENSUS

PF - Patrik Faltstrom If we are discussing it, then wants it listed
AM - Allison Mankin acceptable to continue to discuss without making it a 
WG item
PF Patrik Faltstrom - Service can be created without making it a WG item
?? - Don't understand what the problem is
JP Jon Peterson - It happens, sometimes there is no enthusiasm to work on 
something
      Group doesn't have to have a reason
LCLayrry Conroy - If there are technical objections, please put them on the 
list
      What is the process if there is no WGLC?
AM Allison Mankin- AD does an extended Last Call.  Submit to AD.  WG needs 
to do the review.

ITEM 4. LC - Experimental should be allowed to be an enum service (ie 
allowed to be IANA registered) X- is not registered.

PF  Patrik Faltstrom- Could make a simple mod to allow this
JP - Jon Peterson Want to exclude INFO
PF Patrik Faltstrom- Don't want to have proprietary registrations
      Restricting to standards track is too strong

Will make some adjustments

ITEM 5. Back to partial resolutions.  Propose to add applicability 
statement that says:
ENUM is for E.164 only MUST only query for what it thinks is a valid E.164.
E2U MUST NOT be used for non E.164

Some real time discussion over "what it thinks".

JK - Be careful about how explicit rules are
BR Brian Rosen- real time editing often doesn't work, ask for general 
consensus and debate wording on list
RS - Rich Shockey - Would like to finish this
JP - Jon Peterson even E.164 could change; specs move.
PF  Patrik Faltstrom- Can't do wordsmithing in a meeting
JH - Change to something simpler (cc+some number of digits)

RS Rich Shockey- SEND TEXT TO THE LIST !

ITEM 6. draft-peterson-enum-pres-00.txt
Jon Peterson defines e2U+pres exact protocol is not specified in enum - 
negotiated per IMPP (cpp) presence for telephone requires more spec work

RG - where would extensions for presence be done? SPIRITS?
JP - Apps area or transport area maybe
JH - What is relationship to e2u+sip
JP - other presence protocols, e.g. mobile telephones,...
JR Jonathan Rosenberg - draft assumes presence of phone.  Don't have to do 
that, E.164 to pres uri, doesn't matter what kind of phone
JP - True but E.164 represents something in the PSTN
      Generalizable beyond presence for a phone
JH - Looks like rerun of vovi.
JP - Accommodates other presence protocols
JR - pres URI won't get you a sip uri!
JP - yeah, you will be able to get to a sip service
RS - Rich Shockey Confused
JP - pres: uri dereferences to a service, could be sip, jabber,...
LC Layry Conroy - Point is that ENUM gets you pres: and then you are out of 
DDDS

hum should this be a WG item - CONSENUS TO MAKE IT A WG ITEM

Meeting closes.



 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum