Re: [Rum] draft-ietf-rum-rue-02.txt

Brian Rosen <br@brianrosen.net> Tue, 18 February 2020 00:08 UTC

Return-Path: <br@brianrosen.net>
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 51C0B120866 for <rum@ietfa.amsl.com>; Mon, 17 Feb 2020 16:08:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 4nkpS86Cdo0r for <rum@ietfa.amsl.com>; Mon, 17 Feb 2020 16:08:04 -0800 (PST)
Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 1CB1812002E for <rum@ietf.org>; Mon, 17 Feb 2020 16:08:04 -0800 (PST)
Received: by mail-yw1-xc34.google.com with SMTP id 10so8645596ywv.5 for <rum@ietf.org>; Mon, 17 Feb 2020 16:08:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4MC59faEMz2Ys0s9xqMO9626IrPeDsRfnTiwx8CLuJg=; b=yV54dJdOhchgx+xotKK8acb1YJ1baISCW6XJCkrbwLY6pBmk/oBcmb13+Lui1ouITL /EzryKXkF0sKEDB5sWoDrVYyajcta9+eCViQQK698UBgZ3SGuEy+vXZTcXZoTBl/LzQh I3vcQy8lhjYn87IhpVmJostq6uP3JCWJw3+A3C4dcmBzMQz5vbcc4kM+MsF3dzC44O3h GSajk0cxuikgGW03yoZJpvWqWDAaF1Jx2j1yWcEugB5wiuWOtPbHQw+Vsf43eBjWZJJL h4DMDKMFHhzaa/RCck2xuPm6CyrP05+3zKYL+/niq16udoIsvtX8KhCr+t0KVud87jIb Q2kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4MC59faEMz2Ys0s9xqMO9626IrPeDsRfnTiwx8CLuJg=; b=lq5SHp5BFRdV5NvyXtow5mlpFD8KVFgFMsGTcSOzM2xABagDC9olbOD04qMDUZEroC NN2Tme9/GnW/pY5S/MjG/w37cBJJMtqG8Mw5Kh51RunmhOOyi6Vm79OF3n9bHxOhdyY0 6ZrNF44OATE23jVYsssxmiPPhKNKie+cG7cLljwXRVr6/8ds+VU+0QAtgTobEhWeQL/w 902slSt7Ldc4a5si9Jo8kqUNM+AhWmLsunevcLYBIYEb3A8kwK5Eqcf3BB7fhNe/bQ2q i35+AMMJCRoU/wt9bdS7h8Dh1oTYkUKUkLkgaTWG4J1IotG3yZCmIJ5KUDR5QY5UEp7v YkmQ==
X-Gm-Message-State: APjAAAWimXZSBkVnxSIhc+kv1AxwPznB/FJ8EXtkJQJvt4caJX8jmevQ 9F3YcSwrZhZSeD0sI18y9bU6SA3EfPM=
X-Google-Smtp-Source: APXvYqyh0Zn7ny2iHRRG5JZv7Fvc+y6MEruhA/Xzh8NBZaKU/srOhih4JYayrtrovcDXKAxmCfcFPw==
X-Received: by 2002:a81:11d7:: with SMTP id 206mr15861189ywr.150.1581984482942; Mon, 17 Feb 2020 16:08:02 -0800 (PST)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id o4sm971455ywd.5.2020.02.17.16.08.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2020 16:08:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <ccc9ecd9-2c73-ca5c-7e51-fce59b1e8654@alum.mit.edu>
Date: Mon, 17 Feb 2020 19:08:00 -0500
Cc: rum@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <24D0B5F1-C1C1-447F-9E8B-E711ADD18F36@brianrosen.net>
References: <158033443345.2803.14350232562292068648@ietfa.amsl.com> <ccc9ecd9-2c73-ca5c-7e51-fce59b1e8654@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/JgV3hvcsnH2ZwP66YDCJ3ksDWT8>
Subject: Re: [Rum] draft-ietf-rum-rue-02.txt
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: Tue, 18 Feb 2020 00:08:06 -0000

Inline

> On Jan 30, 2020, at 1:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> Here are some further comments on -02:
> 
> This update has largely expunged separate specifications for the RUE and the provider server the RUE connects to in favor of talking about the RUE Interface that both are required to implement. In some cases that makes sense because the requirements are the same on both sides. In other cases it seems to dodge the issue that the two sides have different roles and responsibilities. For instance: RFC5626 (outbound), RFC6665 (events), RFC6442 (geoloc).
You might be right about Outbound, but only in the sense that the providers don’t have to implement it at all, but if they do, then they have to do what 5656 says.
Events is sort of the same way, depending on what the final text on MWI says.
Geoloc isn’t: the provider must accept and pass Geoloc to maintain 6881 conformance.

There are some differences, but I’d prefer to use “UAC and “UAS” as the terms.

> 
> Section 5.2.1 now says:
> 
>   The all outbound calls MUST be routed through an outbound proxy if
>   configured.
> 
> (It previously specified the RUE.) IIUC this really does only apply to the RUE. AFAIK we don't specify any configuration for the provider, and presumably providers can do whatever they want that works. (Also, the language is a bit messed up.)
Yes, but doesn’t the text read correctly?

> 
> Section 5.2.3 says:
> 
>   To identify the owner of a RUE, the initial INVITE for a call from a
>   RUE, or the 200 OK accepting a call by a RUE, identifies the owner by
>   sending a Call-Info header with a purpose parameter of "rue-owner".
> 
> This new purpose parameter needs to be registered with IANA. It currently isn't mentioned in section 11.
Yes, need to do that.

> 
> Section 5.2.5 says:
> 
>   The implementations comply with [RFC6881] for handling of emergency
>   calls.
> 
> This is not a normative statement. AFAICT there is no normative requirement to support this. And this is another asymmetric case. (IIUC the provider need not include GeoLoc in outbound calls to the RUE.)
Missing the MUST.  It has to be normative (among other things, NG9-1-1 in the US requires it).

> 
> This section also uses "client" and "server" to refer to the RUE and Provider sides of a RUE Interface. This differs from using "client" to refer to UAC and "server" for UAS.
I’ll change to UAC/UAS
> 
> Section 5.5 and elsewhere use the following construction:
> 
>   Implementations MUST conform to ... with the understanding that ...
> 
> That language seems a bit vague to me. Is this relaxing any normative statements in the reference, or simply stating that only a subset of the standard will be used in practice? I'd like to see this tightened up normatively.
Could you suggest language.  I agree with you.
> 
> Section 6.3:
> 
> I think this is saying that RUEs MUST support VP8 unless they can't, while providers MUST *support* VP8 but need not use it in every call, such as when connecting to another endpoint that doesn't. I get the spirit, but it fails to make clear when an implementation is non-conforming.
> 
> For instance, is it acceptable for a provider's interpreters to use non-RUE devices that don't support VP8? Is it acceptable for the provider video-mail server to not support VP8?
I think those questions are more a regulator issue.  UACs must offer VP8.  UASs must support VP8 if both ends support VP8.  I don’t think this doc should mandate what a VideoMail server does, because that’s outside the scope (VM servers may or may not conform to this doc).  

Language suggestions welcome!
> 
> Section 8:
> 
> IIUC this means that the provider may or may not include a "mwi" entry in the configuration, but if it is configured that both sides are required to support it as specified.
Yeah, although I have a pretty hard time not mandating MWI.  I really don’t think there is a reasonable way to build a client without supporting MWI, since there is no other interface to support the function.

> 
> Section 9.1:
> 
> This makes it optional for a RUE to make the choice of provider available to the user. Is that what we want?
> 
Hmmm. Is that a UI issue, and thus beyond scope, or an interface issue and in scope?

> Section 9.3:
> 
> These schemas use the [JCR] notation. This dates back to the early versions of this document several years ago. At the time there was single accepted schema notation for JSON. JCR was under development at the time. I haven't kept up with what has been happening with JSON schemas. I just looked and it appears that draft-newton-json-content-rules-09 is the latest version of JCR. I don't know if that means it was abandoned in favor of something else. We need to investigate this.\\
Yeah, I’m pretty heavily dealing with this in other venues.  I think we want json schemas.  I’ll do that next rev.

> 
> 	Thanks,
> 	Paul
> 
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum