Subject: [Rum] New Version has some changes requested, and not others

From: Brian Rosen <[email-masked]>
Date: Mon, 14 Jun 2021 17:41:07 -0400

The latest (-05) version  <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>of rum-rue has a number of changes requested by commenters including:
I changed the digest requirement to require RFC8760 and mandate at least SHA-512 support.  There isn’t any good reason I can think of to make the mandatory algorithm specified in the configuration.  Once you implement SHA-anything with any current library, you get SHA-256 and SHA-512.  Support doesn’t require a change in password, but it does require an operation to recalculate the digest.  I think that’s reasonable, and it’s easy to support backwards compatibility in the server side with both MD5 and SHA-512 with one password and two digests.  The text does specify that the username/password for REGISTER must be different from other uses like websites and support services.
Added password in the configuration.  It’s optional.  If it’s returned, the device retains it, and uses it for SIP/STUN/TURN for subsequent invocations.  If it’s never returned, then the credentials for the configuration interface are used for SIP/STUN/TURN.
I added an instance identifier to the configuration data query to support emergency call location.  I noticed I hadn’t defined the API Key parameter in the OpenAPI yaml, so I added both parameters in this version.
Support for SIP PUSH (RFC8599) is required if the RUE/Provider supports mobile devices/clients

I did not make several requested changes.  It will be a chair call, assisted by Area Directors, to determine if rough consensus exists to make this changes, and if there is, then I will do them.  As editor, I am obligated to make the document conform to rough consensus as determined by chairs, and I will do so to the best of my ability.
I left IPv6 required.  We basically don’t do IPv4 work anymore.  It would be tough for a new document like this to get through the IETF with only V4.  Both ends are mandated to support V6.  I did add text using my interpretation of the SIPconnect no-dual-stack-required text.  It says you can have more than one server specified in the SRV record, where each server has an A or AAAA record, but not both.  You can, of course, support dual stack if you want to.
I left the contact sync as is for now.  Let’s see what rough consensus is.  I could change from jCard to xCard but that really does seem backwards for a new spec.  I have reason to believe there would not be a problem with the US FCC over using jCard.  YMMV.  Again, I will go with rough consensus on that.  Having done conversions from one to the other, I know it’s easy.  It’s just syntax, not semantics.
I don’t feel all that strongly about dropping VP8 video codec support, but I’m reluctant to lose WebRTC compatibility.  I feel much more strongly about retaining support for OPUS.  Again, I will go with whatever consensus we have.  We deliberately put support for compatibility with WebRTC in the charter.  A gateway to SIP would be required to use it.  What we have in our spec is mostly the media stuff, not the signaling.
I feel strongly that MWI support is required as there are no other standards for this functionality and proprietary-only seems wrong to me.  Again, we’ll have to determine consensus.  There was other list traffic in support of MWI.  
Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2021 11:09:43 -0400

Hello RUMers,

I hope with this version we are close to done with RUM. What we need now 
are careful and thoughtful reviews, especially by those who will be 
impacted by this spec. (This isn't yet a work group last call review. 
I'll leave the decision about that to the upcoming meeting.)

To people representing VRS providers:

Please do a thoughtful review from the provider perspective. While we 
don't know what the FCC will do, it is entirely possible that it may 
require that all VRS services be provided via RUM-compliant devices. 
Please identify anything about this document that would prevent that 
from happening, or that would render it a poorer offering than what you 
currently offer.

To VRS users:

Is there anything you get today using a provider-proprietary device that 
you couldn't get from a RUM device? Is there any end-user feature that 
you would like to see that is lacking?

	Thanks,
	Paul, as RUM co-chair

On 6/14/21 5:41 PM, Brian Rosen wrote:
> Thelatest (-05) version 
> <https://datatracker.ietf.org/doc/draft-ietf-rum-rue/>of rum-rue has a 
> number of changes requested by commenters including:
> 
>   * I changed the digest requirement to require RFC8760 and mandate at
>     least SHA-512 support.  There isn’t any good reason I can think of
>     to make the mandatory algorithm specified in the configuration.
>       Once you implement SHA-anything with any current library, you get
>     SHA-256 and SHA-512.  Support doesn’t require a change in password,
>     but it does require an operation to recalculate the digest.  I think
>     that’s reasonable, and it’s easy to support backwards compatibility
>     in the server side with both MD5 and SHA-512 with one password and
>     two digests.  The text does specify that the username/password for
>     REGISTER must be different from other uses like websites and support
>     services.
>   * Added password in the configuration.  It’s optional.  If it’s
>     returned, the device retains it, and uses it for SIP/STUN/TURN for
>     subsequent invocations.  If it’s never returned, then the
>     credentials for the configuration interface are used for SIP/STUN/TURN.
>   * I added an instance identifier to the configuration data query to
>     support emergency call location.  I noticed I hadn’t defined the API
>     Key parameter in the OpenAPI yaml, so I added both parameters in
>     this version.
> 
>   * Support for SIP PUSH (RFC8599) is required if the RUE/Provider
>     supports mobile devices/clients
> 
> 
> 
> I did not make several requested changes.  It will be a chair call, 
> assisted by Area Directors, to determine if rough consensus exists to 
> make this changes, and if there is, then I will do them.  As editor, I 
> am obligated to make the document conform to rough consensus as 
> determined by chairs, and I will do so to the best of my ability.
> 
>   * I left IPv6 required.  We basically don’t do IPv4 work anymore.  It
>     would be tough for a new document like this to get through the IETF
>     with only V4.  Both ends are mandated to support V6.  I did add text
>     using my interpretation of the SIPconnect no-dual-stack-required
>     text.  It says you can have more than one server specified in the
>     SRV record, where each server has an A or AAAA record, but not both.
>       You can, of course, support dual stack if you want to.
>   * I left the contact sync as is for now.  Let’s see what rough
>     consensus is.  I could change from jCard to xCard but that really
>     does seem backwards for a new spec.  I have reason to believe there
>     would not be a problem with the US FCC over using jCard.  YMMV.
>       Again, I will go with rough consensus on that.  Having done
>     conversions from one to the other, I know it’s easy.  It’s just
>     syntax, not semantics.
>   * I don’t feel all that strongly about dropping VP8 video codec
>     support, but I’m reluctant to lose WebRTC compatibility.  I feel
>     much more strongly about retaining support for OPUS.  Again, I will
>     go with whatever consensus we have.  We deliberately put support for
>     compatibility with WebRTC in the charter.  A gateway to SIP would be
>     required to use it.  What we have in our spec is mostly the media
>     stuff, not the signaling.
>   * I feel strongly that MWI support is required as there are no other
>     standards for this functionality and proprietary-only seems wrong to
>     me.  Again, we’ll have to determine consensus.  There was other list
>     traffic in support of MWI. 
> 
> Brian
> 
> 
> 
> 
> 
>