Subject: [Enum] ENUM Query

From: Wayne Cutler <[email-masked]>
Date: Tue, 3 Mar 2020 11:00:56 +0000

Dear ENUM List,

I have an ENUM Registry query that I'd like to run past you to solicit expert feedback/recommendations on the best way forward.

The scenario that is applicable concerns the deployment of MMTEL (Multi-Media Telephony) & Advanced RCS Messaging by MNOs (Mobile Network Operators). For historic reasons, there are two different ways that MNOs have deployed MMTEL & RCS Messaging services :-

i)                    Both MMTEL & RCS Messaging services are provided by a single IMS Core Network and the UE registers to this single IMS core to receive all of its services. All terminating service requests are required to be routed to the single IMS network. Therefore, the existing ENUM infrastructure is fine for this scenario as the telephone number of a given user resolves to a SIP URI that identifies the target IMS core network.

ii)                   The MMTEL and RCS services are provided by 2 separate IMS Core Networks - one for MMTEL and one for RCS Messaging. In this scenario, the UE registers to both IMS core networks (so-called "dual registration") and gets its full suite of services via a combination of the 2 IMS cores.  The same IMPU (IMS Public User Id) is used for both IMS registrations and the same phone number is used to route terminating service requests for both MMTEL & RCS Messaging related requests. Therefore, in this case, an ENUM request for a given telephone number needs to be able to identify 2 different target IMS cores. The related service request can then be passed onto the correct IMS core based on the its context (i.e. does the request relate to a MMTEL or RCS Messaging service). This is the scenario that doesn't seem to be covered in the existing ENUM Registry.

So, the problem we have is how to resolve a single telephone number to 2 different SIP URIs. Looking at the existing ENUM registry, there seems to be 3 options :-

*       Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764 to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" - with the absence of a sub-type meaning "all services".

*       Re-use (or perhaps re-interpret?) an existing result (e.g. ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but this feels like a kludge,

*       Define a new ENUM registry entry to identify RCS Messaging.

I would be grateful of any advice / recommendation that you have and am happy to answer any further questions for clarification.

Best Regards,

Wayne Cutler

.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Mar 2020 12:51:23 -0500

One question: are the services that are provided on these two networks distinct?  
Do one or both of them supply messaging service?  Calling Service?

If both, then how is a message/call to the TN routed?

I think we would want to have some service differentiation as the discriminator if its one network that supplies each service.

Brian

> On Mar 3, 2020, at 6:00 AM, Wayne Cutler <[email-masked]> wrote:
> 
> Dear ENUM List,
> I have an ENUM Registry query that I’d like to run past you to solicit expert feedback/recommendations on the best way forward.
>  
> ·       Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764 to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" - with the absence of a sub-type meaning "all services".
> ·       Re-use (or perhaps re-interpret?) an existing result (e.g. ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but this feels like a kludge,
> ·       Define a new ENUM registry entry to identify RCS Messaging.
>  
> _______________________________________________
> enum mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/enum <https://www.ietf.org/mailman/listinfo/enum>

---

From: Wayne Cutler <[email-masked]>
Date: Wed, 4 Mar 2020 08:52:27 +0000

Hi Brian,
Thanks for your questions. Please see below in line..

Regards,
Wayne

From: Brian Rosen [mailto:[email-masked]]
Sent: 03 March 2020 17:51
To: Wayne Cutler <[email-masked]>
Cc: [email-masked]
Subject: Re: [Enum] ENUM Query

“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”

One question: are the services that are provided on these two networks distinct?
WC - Yes.  The service-sets offered on the two networks do not intersect.

Do one or both of them supply messaging service?  Calling Service?
WC - Yes.  RCS offers a number of messaging services.  MMTEL offers voice and video calling.  For historic reasons,  SMS (which is technically a messaging service) is part of the service-set associated with MMTEL. So, in the dual-IMS core scenario, one IMS core provides voice/video/SMS and the second IMS Core provides RCS Messaging.

If both, then how is a message/call to the TN routed?
WC - GSMA defines two disjoint sets of services, which we refer to as RCS and MMTEL.  The desire is that the ENUM response provide 2 URIs, one for each service-set, each of which resolve to an entry point to the network providing that service-set.  These URIs can be the same or different (i.e. covering the single/dual IMS core(s) use cases).

I think we would want to have some service differentiation as the discriminator if its one network that supplies each service.
WC - Agreed.  GSMA is responsible for the mapping of service requests to a service-set.  We intend that the ENUM response provide a URI for each service-set.  What seems to be lacking is an ENUM service for the RCS Messaging service-set.

Brian

On Mar 3, 2020, at 6:00 AM, Wayne Cutler <[email-masked]<mailto:[email-masked]>> wrote:

Dear ENUM List,

So, the problem we have is how to resolve a single telephone number to 2 different SIP URIs. Looking at the existing ENUM registry, there seems to be 3 options :-
•       Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764 to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" - with the absence of a sub-type meaning "all services".
•       Re-use (or perhaps re-interpret?) an existing result (e.g. ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but this feels like a kludge,
•       Define a new ENUM registry entry to identify RCS Messaging.

Best Regards,
Wayne Cutler

.
_______________________________________________
enum mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/enum<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fenum&data=02%7C01%7Cwcutler%40gsma.com%7Ca3a3a076ea7d438c93e908d7bf9b816b%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637188546946136534&sdata=%2FuEdiPIO68Sfj%2F7CSf3O9KnP%2BXpUTvoq27CkTBSspGI%3D&reserved=0>

.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 4 Mar 2020 11:44:15 +0100 (CET)

Hi Wayne

To better assess the scope, I also have some questions:

1) What URI Schemes are currently specified to be used in the NAPTR RRs of 
the ENUM response (for each of the services RCS and MMTEL)?

2) How likely do you think is it that further URI Schemes will be added 
in future (for each of the services RCS and MMTEL)?

3) How do you think that further services (in addition to RCS and MMTEL) 
will be added in future?

4) What is your prediction on SMS to be moved to RCS in future?

All the Best,
  Bernie Hoeneisen, IESG Appointed Designated Expert for ENUM

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

On Wed, 4 Mar 2020, Wayne Cutler wrote:

> WC - Yes.  RCS offers a number of messaging services.  MMTEL offers voice and video calling.  For historic reasons,  SMS (which is
> technically a messaging service) is part of the service-set associated with MMTEL. So, in the dual-IMS core scenario, one IMS core
> provides voice/video/SMS and the second IMS Core provides RCS Messaging.
> 
>  
> 
> WC - GSMA defines two disjoint sets of services, which we refer to as RCS and MMTEL.  The desire is that the ENUM response provide 2
> URIs, one for each service-set, each of which resolve to an entry point to the network providing that service-set.  These URIs can be
> the same or different (i.e. covering the single/dual IMS core(s) use cases).
> 
>  
> 
> WC - Agreed.  GSMA is responsible for the mapping of service requests to a service-set.  We intend that the ENUM response provide a URI
> for each service-set.  What seems to be lacking is an ENUM service for the RCS Messaging service-set.
> 
>  
> 
> Brian
> 
> 
>
> The scenario that is applicable concerns the deployment of MMTEL (Multi-Media Telephony) & Advanced RCS Messaging by MNOs (Mobile
> Network Operators). For historic reasons, there are two different ways that MNOs have deployed MMTEL & RCS Messaging services :-
> 
> i)                    Both MMTEL & RCS Messaging services are provided by a single IMS Core Network and the UE registers to this
> single IMS core to receive all of its services. All terminating service requests are required to be routed to the single IMS
> network. Therefore, the existing ENUM infrastructure is fine for this scenario as the telephone number of a given user resolves to
> a SIP URI that identifies the target IMS core network.
> 
> ii)                   The MMTEL and RCS services are provided by 2 separate IMS Core Networks - one for MMTEL and one for RCS
> Messaging. In this scenario, the UE registers to both IMS core networks (so-called "dual registration") and gets its full suite of
> services via a combination of the 2 IMS cores.  The same IMPU (IMS Public User Id) is used for both IMS registrations and the same
> phone number is used to route terminating service requests for both MMTEL & RCS Messaging related requests. Therefore, in this
> case, an ENUM request for a given telephone number needs to be able to identify 2 different target IMS cores. The related service
> request can then be passed onto the correct IMS core based on the its context (i.e. does the request relate to a MMTEL or RCS
> Messaging service). This is the scenario that doesn't seem to be covered in the existing ENUM Registry. 
> 
>  
> 
> ·       Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764 to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" -
> with the absence of a sub-type meaning "all services".
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/enum
> 
>  
> 
> .
> 
> 
>

---

From: Wayne Cutler <[email-masked]>
Date: Wed, 4 Mar 2020 12:45:09 +0000

Hi Bernie,
See below..

Best Regards,
Wayne Cutler

-----Original Message-----
From: Bernie Hoeneisen [mailto:[email-masked]]
Sent: 04 March 2020 10:44
To: Wayne Cutler <[email-masked]>
Cc: Brian Rosen <[email-masked]>; [email-masked]
Subject: Re: [Enum] ENUM Query

Hi Wayne

1) What URI Schemes are currently specified to be used in the NAPTR RRs of the ENUM response (for each of the services RCS and MMTEL)?

WC - At the current time, the SIP URI scheme (RFC 3764) is specified in GSMA document NG.105 (" ENUM Guidelines for Service Providers and IPX Providers") for addressing a target IMS network. This is fine for MMTEL-only and MMTEL/RCS via single registration. It is intended to enhance NG.105 to account for the dual registration case - hence this thread. The document NG.105 describes "Carrier ENUM" - a private ENUM infrastructure for the telecommunications industry.

2) How likely do you think is it that further URI Schemes will be added in future (for each of the services RCS and MMTEL)?

WC - Highly unlikely. This is about routing SIP requests to the correct IMS network.

3) How do you think that further services (in addition to RCS and MMTEL) will be added in future?

WC - Difficult one to answer without a crystal ball. I would say that there may be future MNO-provided services may be non-SIP/IMS based and such services may be able to use other existing ENUM responses or not. In this case, we are focussed on SIP/IMS based MNO-provided services and the need to address the dual registration deployment option. It is likely that further services will be added to the RCS suite of services - but all RCS related service requests would be routed identically to the appropriate IMS core network.

WC - I would say that SMS will never be moved to RCS.

All the Best,

--

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fucom.ch%2F&amp;data=02%7C01%7Cwcutler%40gsma.com%7C5ea0021bf0614dd5441108d7c028fde4%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637189155206270379&amp;sdata=Gm1avA8WQRFrNffpPZ1Km7xlJD%2BywiWTv%2BtAdKQn%2Fvg%3D&amp;reserved=0
Modern Telephony Solutions and Tech Consulting for Internet Technology

On Wed, 4 Mar 2020, Wayne Cutler wrote:

> WC - Yes.  RCS offers a number of messaging services.  MMTEL offers
> voice and video calling.  For historic reasons,  SMS (which is
> technically a messaging service) is part of the service-set associated with MMTEL. So, in the dual-IMS core scenario, one IMS core provides voice/video/SMS and the second IMS Core provides RCS Messaging.
>
>
>
> WC - GSMA defines two disjoint sets of services, which we refer to as
> RCS and MMTEL.  The desire is that the ENUM response provide 2 URIs,
> one for each service-set, each of which resolve to an entry point to the network providing that service-set.  These URIs can be the same or different (i.e. covering the single/dual IMS core(s) use cases).
>
>
>
> WC - Agreed.  GSMA is responsible for the mapping of service requests
> to a service-set.  We intend that the ENUM response provide a URI for each service-set.  What seems to be lacking is an ENUM service for the RCS Messaging service-set.
>
>
>
> Brian
>
>
>
> The scenario that is applicable concerns the deployment of MMTEL
> (Multi-Media Telephony) & Advanced RCS Messaging by MNOs (Mobile
> Network Operators). For historic reasons, there are two different ways
> that MNOs have deployed MMTEL & RCS Messaging services :-
>
> single IMS core to receive all of its services. All terminating
> service requests are required to be routed to the single IMS network.
> Therefore, the existing ENUM infrastructure is fine for this scenario as the telephone number of a given user resolves to a SIP URI that identifies the target IMS core network.
>
> Messaging. In this scenario, the UE registers to both IMS core
> networks (so-called "dual registration") and gets its full suite of
> services via a combination of the 2 IMS cores.  The same IMPU (IMS
> Public User Id) is used for both IMS registrations and the same phone
> number is used to route terminating service requests for both MMTEL &
> RCS Messaging related requests. Therefore, in this case, an ENUM request for a given telephone number needs to be able to identify 2 different target IMS cores. The related service request can then be passed onto the correct IMS core based on the its context (i.e. does the request relate to a MMTEL or RCS Messaging service). This is the scenario that doesn't seem to be covered in the existing ENUM Registry.
>
>
>
> So, the problem we have is how to resolve a single telephone number to
> 2 different SIP URIs. Looking at the existing ENUM registry, there
> seems to be 3 options :-
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fenum&amp;data=02%7C01%7Cwcutler%40gsma
> .com%7C5ea0021bf0614dd5441108d7c028fde4%7C72a4ff82fec3469daafbac827621
> 6699%7C0%7C0%7C637189155206270379&amp;sdata=9KAN9TKpLdPVv%2Fwxbyy5Cgmz
> uQrAjMHzjs8k0VkZiA8%3D&amp;reserved=0
>
>
>
> .
>
>
>
.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Sat, 7 Mar 2020 11:55:01 +0100 (CET)

Hi Wayne

Thanks for your response.

I think I am getting closer to understand the challenges reagarding ENUM 
in IMS. (It's been a while since my last 3GPP/IMS meeting, which dates 
back to year 2002:ish.)

In the following a preliminery assessment of your options (incl. further 
questions):

> · Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764 
> to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" - with the absence of 
> a sub-type meaning "all services".

This is a no-go, as RFC 6117 does not forsee to use subtype strings other 
than different URI Schemes for Protocol-Based Enumservices. cf. 
https://tools.ietf.org/html/rfc6117#section-4.2.2.2

> · Re-use (or perhaps re-interpret?) an existing result (e.g. 
> ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but this 
> feels like a kludge,

Questions:

- What are the differences between im (Enumservice) and RCS as used in 
IMS?

- What are the differences between unifmsg (Enumservice) and RCS as used 
in IMS?

> · Define a new ENUM registry entry to identify RCS Messaging.

Given the information I currently have/understand, this appears to be the 
cleanest approach, i.e.  to define a new Application-Based Enumservice:

- "rcs:sip" with URI Schemes "sip" and "sips"

or both

- "rcs:sip" with URI Scheme "sip"
- "rcs:sips" with URI Scheme "sips"

(depending on the implementation, see also:
https://tools.ietf.org/html/rfc6117#section-4.2.3.2 )

If we go down this road, you may also want to consider the same for MMTEL, 
to replace your legacy approach that uses the Protocol-Based Enumservice 
"sip", e.g.:

- "mmtel:sip" with URI Schemes "sip" and "sips"

Note that anything I write here is pre-liminery and MUST NOT be 
interpreted in any way as "decision by the Dedicated Expert for ENUM" (or 
alike), but rather help you to find the right direction for a possible 
upcoming formal IANA registration process.

cheers,
  Bernie

--

http://ucom.ch/

---

From: Wayne Cutler <[email-masked]>
Date: Mon, 9 Mar 2020 14:04:44 +0000

Hi Bernie,
Thanks for your email.

So, we are after a mechanism to get a SIP URI for the RCS Messaging Services, and these services comprise things like 1:1 Chat, File Transfer, Geolocation Push etc.

Regarding the differences between RCS Messaging and im/unifmsg, I would say that :-
1) im allows users to send and receive typically short, often textual messages in near real-time - which sounds a lot like RCS Chat  - and returns an IM URI. So, I think that RCS is more general than im and also the need to translate from the im URI to a SIP URI is an additional minor nuisance.
2) unifmsg is about having a unified (voice/video) mailbox capability in the event of a user being unreachable. The RCS services aren't really about the  user being unreachable and so this is not really a good fit IMO.

So, I think the proposal to have a new Application-Based Enumservice seems reasonable to me. What would be the next steps? Writing an Internet Draft presumably?

Regarding the suggestion to also take a similar approach for MMTEL, I think there are backwards compatibility issues as there are implementations already out there that use the Protocol-Based Enumservice "sip" for MMTEL. Therefore, this is something we wouldn't want to do.

Regards,
Wayne

-----Original Message-----
From: enum [mailto:[email-masked]] On Behalf Of Bernie Hoeneisen
Sent: 07 March 2020 10:55
To: Wayne Cutler <[email-masked]>
Cc: [email-masked]
Subject: Re: [Enum] ENUM Query

Hi Wayne

I think I am getting closer to understand the challenges reagarding ENUM in IMS. (It's been a while since my last 3GPP/IMS meeting, which dates back to year 2002:ish.)

> a sub-type meaning "all services".

This is a no-go, as RFC 6117 does not forsee to use subtype strings other than different URI Schemes for Protocol-Based Enumservices. cf.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6117%23section-4.2.2.2&amp;data=02%7C01%7Cwcutler%40gsma.com%7C262c586851d74d20944d08d7c2860dfe%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637191753343095966&amp;sdata=J7CThb34%2FxNtzDR%2FtHv0d8Nq56HdtScQEcSf8x4CWc4%3D&amp;reserved=0

> ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but
> this feels like a kludge,

Questions:

- What are the differences between im (Enumservice) and RCS as used in IMS?

- What are the differences between unifmsg (Enumservice) and RCS as used in IMS?

> · Define a new ENUM registry entry to identify RCS Messaging.

Given the information I currently have/understand, this appears to be the cleanest approach, i.e.  to define a new Application-Based Enumservice:

or both

(depending on the implementation, see also:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6117%23section-4.2.3.2&amp;data=02%7C01%7Cwcutler%40gsma.com%7C262c586851d74d20944d08d7c2860dfe%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637191753343095966&amp;sdata=usCYD0Ero7VeqEhJ%2B5JRW79ol5tHp754VDLnDlt8PL0%3D&amp;reserved=0 )

If we go down this road, you may also want to consider the same for MMTEL, to replace your legacy approach that uses the Protocol-Based Enumservice "sip", e.g.:

Note that anything I write here is pre-liminery and MUST NOT be interpreted in any way as "decision by the Dedicated Expert for ENUM" (or alike), but rather help you to find the right direction for a possible upcoming formal IANA registration process.

cheers,
  Bernie

--

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fucom.ch%2F&amp;data=02%7C01%7Cwcutler%40gsma.com%7C262c586851d74d20944d08d7c2860dfe%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637191753343095966&amp;sdata=GRQ1ZA4KkN%2BVemSIKST%2FXism9CmbbWvbwiPHTqH36hA%3D&amp;reserved=0
Modern Telephony Solutions and Tech Consulting for Internet Technology
.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 9 Mar 2020 15:49:48 +0100 (CET)

Hi Wayne

My comments inline.

On Mon, 9 Mar 2020, Wayne Cutler wrote:

> So, we are after a mechanism to get a SIP URI for the RCS Messaging 
> Services, and these services comprise things like 1:1 Chat, File 
> Transfer, Geolocation Push etc.
>
> 1) im allows users to send and receive typically short, often textual 
> messages in near real-time - which sounds a lot like RCS Chat - and 
> returns an IM URI. So, I think that RCS is more general than im and also 
> the need to translate from the im URI to a SIP URI is an additional 
> minor nuisance.

> 2) unifmsg is about having a unified (voice/video) mailbox capability in 
> the event of a user being unreachable. The RCS services aren't really 
> about the user being unreachable and so this is not really a good fit 
> IMO.

Thanks for clarification.

> So, I think the proposal to have a new Application-Based Enumservice 
> seems reasonable to me. What would be the next steps? Writing an 
> Internet Draft presumably?

RFC 6117 defines the process in details
cf. https://tools.ietf.org/html/rfc6117#section-6

> Regarding the suggestion to also take a similar approach for MMTEL, I 
> think there are backwards compatibility issues as there are 
> implementations already out there that use the Protocol-Based 
> Enumservice "sip" for MMTEL. Therefore, this is something we wouldn't 
> want to do.

Not sure this creates a new backward compatibility issue. AFAICT, 
using two new Enumservices, new systems would be more efficient and less 
prone to ambiguities. And in the long run you'd get a clean system.

- for old systems you probably need to maintain "sip" (only)
   (provision and lookup). You may add a recommendation to at
   least provision also the new Enumservices "mmtel:sip" and "rcs:sip"
   (pointing to the same as "sip"), which is easy to implement.

- for new systems you could specify:

   - Lookup: use "rcs:sip" or "mmtel:sip" (with priority);
     use "sip", only if no hit with rcs or mmtel (fallback)

   - Provision: "rcs:sip" and "mmtel:sip" would point to the respecive
     services,
     while "sip" could be provisioned to help old systems to find the
     correct service, e.g. a redirection service (or alike) or a system
     that can deal with requests for the "wrong" (mmtel vs. rcs) service.

You could deprecate "sip" Enumservice and after a long enough transition 
period, you may get rid of the "sip" Enumservice altogether.

Does this make sense for your environment?

cheers
  Bernie

---

From: Brian Rosen <[email-masked]>
Date: Mon, 9 Mar 2020 11:50:15 -0400

I think adding new enumservices for both rcs and mmtel is a good way forward.

While we could eventually not see anyone using the sip enumservice for messaging, it is, and will be widely used for voice calls.  

Brian

> On Mar 9, 2020, at 10:49 AM, Bernie Hoeneisen <[email-masked]> wrote:
> 
> Hi Wayne
> 
> My comments inline.
> 
> Not sure this creates a new backward compatibility issue. AFAICT, using two new Enumservices, new systems would be more efficient and less prone to ambiguities. And in the long run you'd get a clean system.
> 
> You could deprecate "sip" Enumservice and after a long enough transition period, you may get rid of the "sip" Enumservice altogether.
>

---

From: Wayne Cutler <[email-masked]>
Date: Fri, 13 Mar 2020 11:54:49 +0000

Thanks Brian & Bernie for your feedback.

I can see that adding mmtel.sip does compliment rcs.sip and is unambiguous in the service set provided by such a result.

The current sip enumservice is currently used for MMTEL and both MMTEL & RCS. In the former case, a number of those MNOs haven't launched RCS - and therefore the sip enumservice means "all SIP-based services" or unified communications. So, I don't think we would deprecate the use of the sip enumservice - but could consider introducing the mmtel.sip service for "MMTEL only". I will consult with parties internally and see what the consensus is.

As I've said previously, it is intended to use the new ENUM result(s) in the so-called "Carrier ENUM" - a private ENUM infrastructure for the telecommunications industry which uses the top level domain of "e164enum.net" as opposed to "e164.arpa". Given that this is a private infrastructure, using a different top level domain,  would this new ENUM service be appropriate for a standards track or informational RFC and would it be permitted for the related internet draft to refer to the private "e164enum.net" top level domain ?

Best Regards,
Wayne

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: 09 March 2020 15:50
To: Bernie Hoeneisen <[email-masked]>
Cc: Wayne Cutler <[email-masked]>; [email-masked]
Subject: Re: [Enum] ENUM Query

Brian

> RFC 6117 defines the process in details cf.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Frfc6117%23section-6&amp;data=02%7C01%7Cwcutler%40g
> sma.com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827
> 6216699%7C0%7C0%7C637193658237974160&amp;sdata=ZhNt08ISuQHn%2FYRJUWBFo
> HvmKS7MPI%2FI3SyUG9HWxY8%3D&amp;reserved=0
>
> (provision and lookup). You may add a recommendation to at  least
> provision also the new Enumservices "mmtel:sip" and "rcs:sip"
> .com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827621
> 6699%7C0%7C0%7C637193658237974160&amp;sdata=epNTFgp51vkSOeKW0PjJWVyHv9
> wbuvpbvHzllK1C%2B4M%3D&amp;reserved=0

.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Mar 2020 08:09:18 -0400

The registry is “specification required” which allows an Informational. I
would avoid discussing the root. You don’t need to do that. Just describe
the problem and create the new enumservices.

Since the work group doesn’t exist anymore, you need an AD to sponsor it.

Brian

On Fri, Mar 13, 2020 at 7:54 AM Wayne Cutler <[email-masked]> wrote:

> I can see that adding mmtel.sip does compliment rcs.sip and is unambiguous
> in the service set provided by such a result.
>
> The current sip enumservice is currently used for MMTEL and both MMTEL &
> RCS. In the former case, a number of those MNOs haven't launched RCS - and
> therefore the sip enumservice means "all SIP-based services" or unified
> communications. So, I don't think we would deprecate the use of the sip
> enumservice - but could consider introducing the mmtel.sip service for
> "MMTEL only". I will consult with parties internally and see what the
> consensus is.
>
> As I've said previously, it is intended to use the new ENUM result(s) in
> the so-called "Carrier ENUM" - a private ENUM infrastructure for the
> telecommunications industry which uses the top level domain of "
> e164enum.net" as opposed to "e164.arpa". Given that this is a private
> infrastructure, using a different top level domain,  would this new ENUM
> service be appropriate for a standards track or informational RFC and would
> it be permitted for the related internet draft to refer to the private "
> e164enum.net" top level domain ?
>
> Best Regards,
> Wayne
>
> “This email has been received from an external source – please review
> before actioning, clicking on links, or opening attachments”
>
>
> While we could eventually not see anyone using the sip enumservice for
> messaging, it is, and will be widely used for voice calls.
>
> Brian
>
> Services, and these services comprise things like 1:1 Chat, File Transfer,
> Geolocation Push etc.
> >>
> messages in near real-time - which sounds a lot like RCS Chat - and returns
> an IM URI. So, I think that RCS is more general than im and also the need
> to translate from the im URI to a SIP URI is an additional minor nuisance.
> >
> >> 2) unifmsg is about having a unified (voice/video) mailbox capability
> in the event of a user being unreachable. The RCS services aren't really
> about the user being unreachable and so this is not really a good fit IMO.
> >
> seems reasonable to me. What would be the next steps? Writing an Internet
> Draft presumably?
> >
> think there are backwards compatibility issues as there are implementations
> already out there that use the Protocol-Based Enumservice "sip" for MMTEL.
> Therefore, this is something we wouldn't want to do.
> >
> > Not sure this creates a new backward compatibility issue. AFAICT, using
> two new Enumservices, new systems would be more efficient and less prone to
> ambiguities. And in the long run you'd get a clean system.
> >

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 13 Mar 2020 14:51:35 +0100 (CET)

Wayne,

independent stream is also an option. But as Brian said, just make an 
Internet-Draft and I will help you to sort out the RFC-stream later. You 
may want to (re-)read the relevant section in RFC 6117 on the process, 
where all this stuff is specified.

cheers,
  Bernie

--

http://ucom.ch/

On Fri, 13 Mar 2020, Brian Rosen wrote:

> The registry is “specification required” which allows an Informational. I would avoid discussing the root. You don’t need to do that.
> Just describe the problem and create the new enumservices. 
> 
>       The current sip enumservice is currently used for MMTEL and both MMTEL & RCS. In the former case, a number of those MNOs
>       haven't launched RCS - and therefore the sip enumservice means "all SIP-based services" or unified communications. So, I
>       don't think we would deprecate the use of the sip enumservice - but could consider introducing the mmtel.sip service for
>       "MMTEL only". I will consult with parties internally and see what the consensus is.
>
>       As I've said previously, it is intended to use the new ENUM result(s) in the so-called "Carrier ENUM" - a private ENUM
>       infrastructure for the telecommunications industry which uses the top level domain of "e164enum.net" as opposed to
>       "e164.arpa". Given that this is a private infrastructure, using a different top level domain,  would this new ENUM service
>       be appropriate for a standards track or informational RFC and would it be permitted for the related internet draft to refer
>       to the private "e164enum.net" top level domain ?
>
>       Best Regards,
>       Wayne
>
>       >> So, we are after a mechanism to get a SIP URI for the RCS Messaging Services, and these services comprise things like 1:1
>       Chat, File Transfer, Geolocation Push etc.
>       >>
>       >> 1) im allows users to send and receive typically short, often textual messages in near real-time - which sounds a lot
>       like RCS Chat - and returns an IM URI. So, I think that RCS is more general than im and also the need to translate from the
>       im URI to a SIP URI is an additional minor nuisance.
>       >
>       >> 2) unifmsg is about having a unified (voice/video) mailbox capability in the event of a user being unreachable. The RCS
>       services aren't really about the user being unreachable and so this is not really a good fit IMO.
>       >
>       >> So, I think the proposal to have a new Application-Based Enumservice seems reasonable to me. What would be the next
>       steps? Writing an Internet Draft presumably?
>       >
>       >> Regarding the suggestion to also take a similar approach for MMTEL, I think there are backwards compatibility issues as
>       there are implementations already out there that use the Protocol-Based Enumservice "sip" for MMTEL. Therefore, this is
>       something we wouldn't want to do.
>       >
>       > Not sure this creates a new backward compatibility issue. AFAICT, using two new Enumservices, new systems would be more
>       efficient and less prone to ambiguities. And in the long run you'd get a clean system.
>       >

---

From: Wayne Cutler <[email-masked]>
Date: Fri, 13 Mar 2020 14:10:28 +0000

Thanks for the response Brian. Is there a set procedure to get “an AD to sponsor”?

Regards,
Wayne

From: Brian Rosen [mailto:[email-masked]]
Sent: 13 March 2020 12:09
To: Wayne Cutler <[email-masked]>
Cc: Bernie Hoeneisen <[email-masked]>; [email-masked]
Subject: Re: [Enum] ENUM Query

The registry is “specification required” which allows an Informational. I would avoid discussing the root. You don’t need to do that. Just describe the problem and create the new enumservices.

Brian

On Fri, Mar 13, 2020 at 7:54 AM Wayne Cutler <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Brian & Bernie for your feedback.

As I've said previously, it is intended to use the new ENUM result(s) in the so-called "Carrier ENUM" - a private ENUM infrastructure for the telecommunications industry which uses the top level domain of "e164enum.net<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754209838&sdata=kmAMbfvW8%2FRljQKrhZX%2F7kTp%2BOhtEI1eq4iK1N6DLB0%3D&reserved=0>" as opposed to "e164.arpa". Given that this is a private infrastructure, using a different top level domain,  would this new ENUM service be appropriate for a standards track or informational RFC and would it be permitted for the related internet draft to refer to the private "e164enum.net<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=bimoboKOVoAtahauG%2FeIwNqVtiJES9AGX6vpd%2FlmJ8c%3D&reserved=0>" top level domain ?

Best Regards,
Wayne

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 09 March 2020 15:50
To: Bernie Hoeneisen <[email-masked]<mailto:[email-masked]>>
Cc: Wayne Cutler <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Enum] ENUM Query

Brian

> On Mar 9, 2020, at 10:49 AM, Bernie Hoeneisen <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Wayne
>
> My comments inline.
>
> s.ietf.org<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.ietf.org%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=iiJOlm7JcSniW3Ix4XOwgOzm1cYxvnXUg%2BD5%2BZB0N%2BA%3D&reserved=0>%2Fhtml%2Frfc6117%23section-6&amp;data=02%7C01%7Cwcutler%40g
> sma.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsma.com%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754229827&sdata=qGupiox%2FXWxRi2ncOsKcBa9%2BWeYxlaL%2F2okiMV9hJs0%3D&reserved=0>%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827
> ietf.org<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754229827&sdata=wY4Pt4dFpeKD2Spq3p1UB47gdXpHcDJ2GX1kp%2BWGo2Q%3D&reserved=0>%2Fmailman%2Flistinfo%2Fenum&amp;data=02%7C01%7Cwcutler%40gsma

.

.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Mar 2020 10:14:18 -0400

Nope, you just ask one. As a practical matter, you should probably recruit
an experienced IETFer to help you through this. It will be much easier on
everyone.

I’m personally not a fan of independent stream for this. It’s squarely in
the IETF area of expertise and I think we want the full IETF consensus
process.

But it’s up to you how you do it.

Brian

On Fri, Mar 13, 2020 at 10:10 AM Wayne Cutler <[email-masked]> wrote:

> *From:* Brian Rosen [mailto:[email-masked]]
> *Sent:* 13 March 2020 12:09
> *To:* Wayne Cutler <[email-masked]>
>
> *Cc:* Bernie Hoeneisen <[email-masked]>; [email-masked]
> *Subject:* Re: [Enum] ENUM Query
>
>
>
> e164enum.net
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754209838&sdata=kmAMbfvW8%2FRljQKrhZX%2F7kTp%2BOhtEI1eq4iK1N6DLB0%3D&reserved=0>"
> as opposed to "e164.arpa". Given that this is a private infrastructure,
> using a different top level domain,  would this new ENUM service be
> appropriate for a standards track or informational RFC and would it be
> permitted for the related internet draft to refer to the private "
> e164enum.net
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=bimoboKOVoAtahauG%2FeIwNqVtiJES9AGX6vpd%2FlmJ8c%3D&reserved=0>"
> top level domain ?
>
> Best Regards,
> Wayne
>
> > s.ietf.org
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.ietf.org%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=iiJOlm7JcSniW3Ix4XOwgOzm1cYxvnXUg%2BD5%2BZB0N%2BA%3D&reserved=0>
> %2Fhtml%2Frfc6117%23section-6&amp;data=02%7C01%7Cwcutler%40g
> > sma.com
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsma.com%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754229827&sdata=qGupiox%2FXWxRi2ncOsKcBa9%2BWeYxlaL%2F2okiMV9hJs0%3D&reserved=0>
> %7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827
> > ietf.org
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754229827&sdata=wY4Pt4dFpeKD2Spq3p1UB47gdXpHcDJ2GX1kp%2BWGo2Q%3D&reserved=0>
> %2Fmailman%2Flistinfo%2Fenum&amp;data=02%7C01%7Cwcutler%40gsma

---

From: Richard Shockey <[email-masked]>
Date: Fri, 13 Mar 2020 11:47:42 -0400

I certainly don’t have a problem with the independent stream. IMHO this is exactly what the system was designed to do.

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: enum <[email-masked]> on behalf of Brian Rosen <[email-masked]>
Date: Friday, March 13, 2020 at 10:14 AM
To: Wayne Cutler <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Bernie Hoeneisen <[email-masked]>
Subject: Re: [Enum] ENUM Query

Nope, you just ask one. As a practical matter, you should probably recruit an experienced IETFer to help you through this. It will be much easier on everyone. 

I’m personally not a fan of independent stream for this. It’s squarely in the IETF area of expertise and I think we want the full IETF consensus process. 

Brian

Regards,

Wayne

Brian

Best Regards,
Wayne

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: 09 March 2020 15:50
To: Bernie Hoeneisen <[email-masked]>
Cc: Wayne Cutler <[email-masked]>; [email-masked]
Subject: Re: [Enum] ENUM Query

Brian

> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..

..

.

_______________________________________________ enum mailing list [email-masked] https://www.ietf.org/mailman/listinfo/enum

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Mar 2020 12:00:47 -0400

Opinions differ :)

I think we want the full review that AD sponsored gets.  Independent stream
just gets the “We don’t object” review.

In this case I think we want the full review.

On Fri, Mar 13, 2020 at 11:47 AM Richard Shockey <[email-masked]> wrote:

>
>
> I certainly don’t have a problem with the independent stream. IMHO this is
> exactly what the system was designed to do.
>
>
>
>
>
> —
>
> Richard Shockey
>
> Shockey Consulting LLC
>
> *From: *enum <[email-masked]> on behalf of Brian Rosen <
> [email-masked]>
> *Date: *Friday, March 13, 2020 at 10:14 AM
> *To: *Wayne Cutler <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Bernie Hoeneisen <
> [email-masked]>
> *Subject: *Re: [Enum] ENUM Query
>
>
>
> <https://eur03.safelinks.protection.outlook..com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=bimoboKOVoAtahauG%2FeIwNqVtiJES9AGX6vpd%2FlmJ8c%3D&reserved=0>"
> top level domain ?
>
> Best Regards,
> Wayne
>
> _______________________________________________ enum mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/enum
>

---

From: Jim Reid <[email-masked]>
Date: Fri, 13 Mar 2020 16:14:07 +0000

> On 13 Mar 2020, at 16:00, Brian Rosen <[email-masked]> wrote:
> 
> I think we want the full review that AD sponsored gets.  Independent stream just gets the “We don’t object” review. 
> 

Why? Could you define “we” too?

What’s the problem with just defining a new enumservice and being done with it?

New DNS RRtypes don’t need AD review and I think that should apply to new enumservices too.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Mar 2020 12:51:49 -0400

Because it’s somewhat of a change of what we previously thought of as an enumservice.  I do think it’s the right thing to do, but I would want the community to review that.
“We” = IETF.  I can’t speak for the community, this is just my personal opinion.  

In the end, the IESG would decide if they object to independent stream, assuming that it’s done that way.  

Not worth a lot of argument, IMO.

Brian

> On Mar 13, 2020, at 12:14 PM, Jim Reid <[email-masked]> wrote:
> 
> 
>

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 13 Mar 2020 21:21:00 +0100 (CET)

Brian,

As you likely know, I am the Designated Expert for ENUM appointed by the 
IESG and my tasks is to sort out questions like this. The process as 
defined in RFC 6117 includes community review and I will ensure this is 
happening. In fact my first action was to point Wayne to this list (after 
I was contacted by IANA acting as a relay), so that the community can 
engage.

Which people/groups beyond the community subscribed to this ENUM list you 
believe are essential to engage in this case?

YMMV, but I can't see a point to run this through the whole IETF process, 
as the know-how on ENUM beyond this list is rather limited, i.e. we gain 
almost nothing if we did. On the other hand, we increase the workload of 
many people, most having little clue on what ENUM is about.

As a member of the current NomCom I learned that IESG workload related to 
document review is a major challenge its members, so let's not add even 
more to their pile, if there is little to gain.

cheers,
  Bernie

--

http://ucom.ch/

On Fri, 13 Mar 2020, Brian Rosen wrote:

> Because it’s somewhat of a change of what we previously thought of as an 
> enumservice.  I do think it’s the right thing to do, but I would want 
> the community to review that.
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 13 Mar 2020 16:38:36 -0400

+1  

— 
Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

On 3/13/20, 4:21 PM, "enum on behalf of Bernie Hoeneisen" <[email-masked] on behalf of [email-masked]> wrote:

    Brian,

    

    cheers,
      Bernie

    
    --
    
    http://ucom.ch/

    On Fri, 13 Mar 2020, Brian Rosen wrote:
    
    > https://www.ietf.org/mailman/listinfo/enum_______________________________________________
    enum mailing list
    [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Mar 2020 16:43:16 -0400

Of course, it’s actually up to whomever writes the document, certainly not me, to decide how to proceed.

But as I said, it doesn’t matter that much, so I’ll just stop.

Brian

> On Mar 13, 2020, at 4:21 PM, Bernie Hoeneisen <[email-masked]> wrote:
> 
> Brian,
> 
> As you likely know, I am the Designated Expert for ENUM appointed by the IESG and my tasks is to sort out questions like this. The process as defined in RFC 6117 includes community review and I will ensure this is happening. In fact my first action was to point Wayne to this list (after I was contacted by IANA acting as a relay), so that the community can engage.
> 
> Which people/groups beyond the community subscribed to this ENUM list you believe are essential to engage in this case?
> 
> YMMV, but I can't see a point to run this through the whole IETF process, as the know-how on ENUM beyond this list is rather limited, i.e. we gain almost nothing if we did. On the other hand, we increase the workload of many people, most having little clue on what ENUM is about.
> 
> As a member of the current NomCom I learned that IESG workload related to document review is a major challenge its members, so let's not add even more to their pile, if there is little to gain.
> 
> cheers,
> Bernie
> 
> 
> 
> 
> --
> 
> http://ucom.ch/
>>>> I think we want the full review that AD sponsored gets.  Independent stream just gets the “We don’t object” review. In this case I think we want the full review.