Re: [Rum] Call for WG adoption of: draft-rosen-rue-01

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 16 September 2019 19:28 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0516212010D for <rum@ietfa.amsl.com>; Mon, 16 Sep 2019 12:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 RpoLg1T0eNOf for <rum@ietfa.amsl.com>; Mon, 16 Sep 2019 12:28:03 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87B11200FE for <rum@ietf.org>; Mon, 16 Sep 2019 12:28:03 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x8GJRwdK017484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Sep 2019 15:27:59 -0400
To: Brian Rosen <br@brianrosen.net>
Cc: James Hamlin <james.hamlin@purple.us>, "rum@ietf.org" <rum@ietf.org>, Richard Shields <richard@sorenson.com>
References: <f3c1d9fe-8785-86e9-4220-e7d7971b29d4@alum.mit.edu> <ef8dec34-af0d-d4e4-be33-a28a0c9bd0b4@alum.mit.edu> <1568385648772.69603@purple.us> <MWHPR04MB09910881CB5EBC510E9A350CC5B30@MWHPR04MB0991.namprd04.prod.outlook.com> <1568387962077.82824@purple.us> <MWHPR04MB0991B268CB26104EF61AC058C5B30@MWHPR04MB0991.namprd04.prod.outlook.com> <1568390112344.87888@purple.us> <da240598-fbed-8720-b045-b6b9edd11853@alum.mit.edu> <1568650521915.9877@purple.us> <075887d0-fa00-ed1a-e2de-0ea35e077d41@alum.mit.edu> <ADEE569D-6EE5-4570-8A54-B1A3310CE739@brianrosen.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <1d887e2b-6d30-1a3e-b22b-641b8892dcab@alum.mit.edu>
Date: Mon, 16 Sep 2019 15:27:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <ADEE569D-6EE5-4570-8A54-B1A3310CE739@brianrosen.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/l1F9POG2XQ3NFGQvr74q_fsRfTI>
Subject: Re: [Rum] Call for WG adoption of: draft-rosen-rue-01
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 19:28:10 -0000

On 9/16/19 3:07 PM, Brian Rosen wrote:
> I agree that the current language is not very clear, and not really what we want.  As Paul says, we’re defining an interface between a device and a provider.  We probably do care that if two rue-compliant devices talked to one another through a provider, that all the features worked, but I don’t think we would imply anything else about what a provider did.  I think we would probably say that we wished providers had rue-compatible endpoints at, for example, a CA position, but I don’t think an IETF spec could or should say anything like that.

Perhaps it would be helpful to have the draft reference Drawing 1 of:

VRS US Providers Profile TWG-6-1.0 
<https://www.sipforum.org/download/vrs-us-providers-profile-twg-6-1-0-pdf/?wpdmdl=2783&refresh=5d7fdfea794471568661482>

and say that the goal is to define interface U2. That diagram was 
developed in the early days of the SIP Forum work on VRS. At that time 
the scope was expected to be broader, but was eventually limited to the 
R1 interface. This figure gives an overview of the bigger picture and 
helps put the work into context.

(Note that a revision to that profile is in progress, but it won't 
change that figure.)

	Thanks,
	Paul