Re: [Enum] ENUM Query

[Brian Rosen <[e-mail]>]

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 <[e-mail]> wrote:

> Thanks for the response Brian. Is there a set procedure to get “an AD to
> sponsor”?
>
>
>
> Regards,
>
> Wayne
>
>
>
> *From:* Brian Rosen [mailto:[e-mail]]
> *Sent:* 13 March 2020 12:09
> *To:* Wayne Cutler <[e-mail]>
>
> *Cc:* Bernie Hoeneisen <[e-mail]>; [e-mail]
> *Subject:* Re: [Enum] ENUM Query
>
>
>
> “This email has been received from an external source – please review
> before actioning, clicking on links, or opening attachments”
>
>
>
> 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 <[e-mail]> wrote:
>
> 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
> <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:[e-mail]]
> Sent: 09 March 2020 15:50
> To: Bernie Hoeneisen <[e-mail]>
> Cc: Wayne Cutler <[e-mail]>; [e-mail]
> Subject: Re: [Enum] ENUM Query
>
> “This email has been received from an external source – please review
> before actioning, clicking on links, or opening attachments”
>
>
> 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 <[e-mail]>
> wrote:
> >
> > 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.
> >>
> >> 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.
> >
> > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> > 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
> > 6216699%7C0%7C0%7C637193658237974160&amp;sdata=ZhNt08ISuQHn%2FYRJUWBFo
> > HvmKS7MPI%2FI3SyUG9HWxY8%3D&amp;reserved=0
> >
> >> 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
> >
> > _______________________________________________
> > enum mailing list
> > [e-mail]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > 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
> > .com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827621
> > 6699%7C0%7C0%7C637193658237974160&amp;sdata=epNTFgp51vkSOeKW0PjJWVyHv9
> > wbuvpbvHzllK1C%2B4M%3D&amp;reserved=0
>
> .
>
> .
>