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

[Brandner Rudolf <[e-mail]>]

One minor nit:
Regarding the vovi draft in ITEM 3. it is written that sip:voice and sip:video is contentious, which is true. However, the vovi draft has been about voice:sip and video:sip, which are contentious, too.

Besides that, I would like to thank Brian Rosen for having taken the minutes. Job very well done.

Rudi

> -----Original Message-----
> From: Richard Shockey [mailto:[e-mail]]
> Sent: Mittwoch, 9. April 2003 21:03
> To: [e-mail]
> Subject: [Enum] Raw Preliminary Meeting notes from IETF ENUM WG in San
> Francisco
> 
> 
> 
> 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
> 
_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum