Wednesday, November 10, 2004

ENUM at the IETF61 

The ENUM WG meet on Monday with this agenda:

Karen Mulberry from MCI gave a short status report and the planned activities on ENUM in CC1 and the ENUM LLC. According to this one can hope that North America will catch up with the ENUM activities in the rest of the world until End of 2005. An ENUM delegation will be requested soon from RIPE NCC.

I presented the ENUM dip indicator (enumdi), co-authored by Rich Shockey and Lawrence Conroy. Although the draft was primarily targeted for the IPTEL WG, it was also presented of course because of the topic to the ENUM WG. The only issue raised on the mailing list by Cullen Jennings: "if the network element receiving a E.164 number with the enumdi set MUST NOT or SHOULD NOT make an ENUM query" was discussed and the ENUM WG decided unanimously for SHOULD NOT. This decision was forwarded to IPTEL.

A. Newton (Verisign) presented I-D, which extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries.

Regarding validation Bernd Hoeneisen ( presented and Michael Haberler (IPA) presented Since the second variant is a superset of the first, the two authors proposed to combine the two documents. US delegates considered both proposals very country specific and too far advanced and requested a requirements document first (maybe aslo to gain some time until CC1 catches up). The authers promised to provide such a document.

Note: for German speaking folks see also IETF: Standards für Validierung von Telefondomains

Related to on-going work I-D was not presented, because there where no open issues raised on the mailing-list. The authors will provide within some weeks a new version for WGLC.

Same for I-D The authors requested last inputs, if any within the next weeks and then this document should also go to WGLC.


The ENUM dip indicator was also presented to the IPTEL WG on Tuesday (agenda). The decision on SHOULD NOT was accepted by the WG, but another issue was dicussed: should the enumdi parameter only be valid for ENUM in and defined in RFC3761, or should it be extended with a context e.g., being the default. The arguments of the authors where that ENUM is only defined for, to keep it simple and to progress this document as fast a possible. Since the audience was split 50:50 on this, the chairs finally decided to progress as is.

It was also decided to make this draft a WG item. A new draft will be submitted by the authors immediately, covering all issues raised.

The remainder of the IPTEL was not directly related to ENUM, but for completeness I give the summary of decisions as distributed by Jonathan Rosenberg (co-chair) via the IPTEL mailing list:

At the iptel meeting today, there was consensus in the room on plans formoving forward with various drafts. I'd like to verify that consensus by asking the list if folks are OK proceeding with the following:
* Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears inthe archives* Proceed to wglc on immediately following the ietf
* adopt a work item of iptel
* do not adopt as a work item. The author will take it directly to IESG as anindividual draft.
* do not adopt the expired tel cpc draft( as awork item. If folks have a problem that they believe is addressed bythis work, please bring that forward in the next few weeks.
* tgrep will go to IESG after a revision incorporating comments fromCullen and the pending comments from Jonathan

Comments: Post a Comment

This page is powered by Blogger. Isn't yours?