Re: [Enum] ENUM Query

Brian Rosen <br@brianrosen.net> Fri, 13 March 2020 16:01 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C903A0D9A for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 09:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O56LXp09P3TF for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 09:01:00 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2A73A0D99 for <enum@ietf.org>; Fri, 13 Mar 2020 09:00:59 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id f28so13293207qkk.13 for <enum@ietf.org>; Fri, 13 Mar 2020 09:00:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZI4miazjBo/MfqUWHUXWAGkSSJ4yHqBSgHSynYCrVco=; b=eCfe41+VNUxN0yE06v6wCT3lT5OIU9DzAuKHNPE/a1lOGjhkgy1W5v36Yjzq8uMwSl OekKXirRpXh7eO2Ga9YrQj0a7GcznmGevWCKSqJHPixNJUpL2+3uH/vOb48hB6i1U2JV uBTgYY8kEmzkWn8NNexoT5M61WVnbr+sWfEJC5qJBVuhMITlQZ2ydwyXtiGlpuRPaBAV GcetKHAIykin1bHnS3uzj3d0iqWkPDFih9iP2Sldi/S+ixEO2GEF2OhwsyFDuyL0tjWA G6CfgL3WxPKxf/xlbMcyL+3z4+FFQrJjK8Pwcj3I+lxIDQ7f6W8FtW5ZMN/bt8Vp7Bvt GGYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZI4miazjBo/MfqUWHUXWAGkSSJ4yHqBSgHSynYCrVco=; b=n83WhKV3PcGrJbJdlYWZfHEL2Z0acgsi0n8QNv5Eq7di67bp0AvhiRvU0KYVfUkDxE jPY4u4/cxSOdxaWW1mKfcV5fCDXSA6JaMzvRZGNNfRwQTzgeJ1YykSpBVpCeMWLjQ7/R UdyvK+ZsdKPwtKA+t9zhCa9gZGXKNacTYaGtFNY7uK9ppuiO/2NxqJxf0JmYbufG7uu7 bDqzLSqqxd6dcAa539G9jAvFodw+/UOa5svbM6S8/vzNxbBICGtx8oRIP2VY/CunUltx xNKr3RCUAGJmNu2P/FIwgMQG+3L/vy1kn8D4P4/X4bklOeP8IQNmoRAScwDLEAneJlkZ axOQ==
X-Gm-Message-State: ANhLgQ2h9ZxfBmeETXNNYFnRf6BjjffJOlYzndE7BqGNvfAQpi7KQrUy HEBo75Pu04zws7vmMpZOhXVvC1wK00c2ButipbgPIA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtGYLUMthhe6/HalB2MNNCsNPU7K2ot1yjL2PDp?= =?utf-8?q?+o9SLaMqNPeOQvl5H9vjIAhWwzYFt+s/rrXIwSGr0tY0W4o=3D?=
X-Received: by 2002:a37:4644:: with SMTP id t65mr12734880qka.58.1584115258391; Fri, 13 Mar 2020 09:00:58 -0700 (PDT)
MIME-Version: 1.0
References: =?utf-8?q?=3CDB7PR04MB54183341C4145762B969A0B1C3E40=40DB7PR04MB5?= =?utf-8?q?418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CADFB7C13-0783-46A8-B9C9-86D503FF87B9=40brianrosen=2Enet=3E_=3C?= =?utf-8?q?DB7PR04MB5418DCD96342D69A51AFDF3AC3E50=40DB7PR04MB5418=2Eeurprd04?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3Calpine=2EDEB=2E2=2E20=2E2003041130480=2E19506=40softronics=2Eh?= =?utf-8?q?oeneisen=2Ech=3E_=3CDB7PR04MB54186234B94264FEA913888EC3E50=40DB7P?= =?utf-8?q?R04MB5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3Calpine=2EDEB=2E2=2E20=2E2003071103230=2E19506=40softronics=2Eh?= =?utf-8?q?oeneisen=2Ech=3E_=3CDB7PR04MB5418E392AD73AF330044E0F2C3FE0=40DB7P?= =?utf-8?q?R04MB5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= <alpine.DEB.2.20.2003091520500.23510@softronics.hoeneisen.ch> =?utf-8?q?=3CA7704953-E79C-4835-9AE1-A97A567E37FC=40brianrosen=2Enet=3E_=3C?= =?utf-8?q?DB7PR04MB5418B9E732C770A3BC0788FBC3FA0=40DB7PR04MB5418=2Eeurprd04?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CCAOPrzE14Sabbc3TEBm6n2ApPkQPTU2NyVkszuDCcGQzNPE4uYg=40mail=2Eg?= =?utf-8?q?mail=2Ecom=3E_=3CDB7PR04MB541844CC8809562BC5EB407AC3FA0=40DB7PR04?= =?utf-8?q?MB5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= <CAOPrzE3zxuM3Ltfpr9Q_VhOKbLFVXRvtZgexG104Yw+Ed-BGHA@mail.gmail.com> <FD701EE7-989E-4478-A579-42FA40627AF4@shockey.us>
In-Reply-To: <FD701EE7-989E-4478-A579-42FA40627AF4@shockey.us>
From: Brian Rosen <br@brianrosen.net>
Date: Fri, 13 Mar 2020 12:00:47 -0400
Message-ID: <CAOPrzE1OehHB3aG4OQ2ShdYqztOQ5LCuNLOKKfHuRL=4u10gcA@mail.gmail.com>
To: Richard Shockey <richard@shockey.us>
Cc: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>, Wayne Cutler <wcutler@gsma.com>, "enum@ietf.org" <enum@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004292c205a0be930a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/enum/XiTkoRmS7yLFjZ0guEcplFsFk3Q>
Subject: Re: [Enum] ENUM Query
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/enum/>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 16:01:06 -0000

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 <richard@shockey.us> 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
>
> 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 <enum-bounces@ietf.org> on behalf of Brian Rosen <
> br@brianrosen.net>
> *Date: *Friday, March 13, 2020 at 10:14 AM
> *To: *Wayne Cutler <wcutler@gsma.com>
> *Cc: *"enum@ietf.org" <enum@ietf.org>rg>, Bernie Hoeneisen <
> bernie@ietf.hoeneisen.ch>
> *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.
>
>
>
> But it’s up to you how you do it.
>
>
>
> Brian
>
>
>
> On Fri, Mar 13, 2020 at 10:10 AM Wayne Cutler <wcutler@gsma.com> wrote:
>
> Thanks for the response Brian. Is there a set procedure to get “an AD to
> sponsor”?
>
>
>
> Regards,
>
> Wayne
>
>
>
> *From:* Brian Rosen [mailto:br@brianrosen.net]
> *Sent:* 13 March 2020 12:09
> *To:* Wayne Cutler <wcutler@gsma.com>
>
> *Cc:* Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>ch>; enum@ietf.org
> *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 <wcutler@gsma.com> 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:br@brianrosen.net]
> Sent: 09 March 2020 15:50
> To: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
> Cc: Wayne Cutler <wcutler@gsma.com>om>; enum@ietf.org
> 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 <bernie@ietf.hoeneisen.ch>
> 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
> > enum@ietf.org
>
> > 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
>
> ..
>
> .
>
> _______________________________________________ enum mailing list
> enum@ietf.org https://www.ietf.org/mailman/listinfo/enum
>