Re: 5 years since last message
Bernie Hoeneisen <[email protected]> Tue, 2 Jul 2019 10:17:58 +0200 (CEST)
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-1742487168-1562055478=:19816 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT I can confirm Patrik: ENUM standard is in use, somewhat, with variatians. (We occasionally even get consultancy work assigned on ENUM deployments.) What I normally see in the wild, I would certainly not call "Public User ENUM" (what we designed ENUM / RFC 6116 for). Most of the deployments are "Private Infrastructure ENUM", some are "Private User ENUM". I have not encountered any "Public User ENUM" nor "Public Intrastructure ENUM" for some time. ["Public" meaning the root is owned and/or governed by a public / official / "higly-recognized" body, e.g. governmental, ICANN, ... ; "User" meaning Enduser has control over the content of the zone belonging to his own number (as oposed to "Infrastructure" where zone is controlled by a provider).] I wonder whether my observations match with what others see in the wild. The mailing list needs to remain open. There is a mention in RFC 6117 of this list as the central place to discuss new Enumservices. Have a nice summer and c.u. (or at least some of u) in Montreal! cheers, Bernie (another former ENUM co-chair) -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Tue, 2 Jul 2019, Patrik Fältström wrote: > Well, the standard is in use -- sort of -- with various modifications > locally (like use of a different prefix than what is assigned here in > IETF). I heard last time last week people "just saying" this is what is > and should be used for routing of communication with E.164 numbers as > destination in time of emergency/stress where centralized IN systems can > not be reached (but locally cached DNS can). > > So the list is silent, but there is some kind of usage. Does this "some > kind of usage" imply something should be done? > > I do not know. > > I personally did conclude after the first couple of years of discussions that NAPTR is incredibly stupid. Designing things to have so large RRSets is not very optimal, so other DNS types would be better. I suggested the simple URI. But it itself got stuck in the IETF process of creation of new RRTypes, and when it finally was approved, the interest in deployment was sort of gone :-( > > And people seems to have implemented NAPTR... > > Patrik > > On 2 Jul 2019, at 2:41, Livingood, Jason wrote: > >> So what needs to happen here? Seems indisputable that there's not much happening on the ENUM front... >> >> On 6/27/19, 9:48 AM, "enum on behalf of Olivier Guillard / AFNIC" <[email protected] on behalf of [email protected]> wrote: >> >> pong :-) >> >> le Tuesday 15 January à 13 H 17 , Jaap Akkerhuis a écrit : >> > Bernie Hoeneisen writes: >> > >> > > Hi Jaap >> > > >> > > Well, there is a dependency on this list in RFC 6117... >> > > >> > > On the other hand, registering new ENUM services has not been that popular >> > > either for several years... >> > > >> > > cheers >> > > Bernie (Designated Expert of the IESG and other list maintainer) >> > >> > In that case, it would make sense that you take over the maintaining >> > of this list as well. Would you? If so, let's arrange that off-list. >> > >> > jaap >> > >> > _______________________________________________ >> > enum mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/enum >> >> -- >> Olivier >> >> _______________________________________________ >> enum mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/enum >> >> >> _______________________________________________ >> enum mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/enum > --37663318-1742487168-1562055478=:19816 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list [email protected] https://www.ietf.org/mailman/listinfo/enum --37663318-1742487168-1562055478=:19816--