[Rum] Follow-up on RUM charter feedback

[Adam Roach <[e-mail]>]

I would respond to the ballot emails directly, but many of these appear 
to be caught in the tools snafu from earlier. Thanks again to everyone 
for taking the time to review and comment.


Alissa commented:

> "The scope of the work includes mechanisms to provision the user’s 
> device with
> common features such as speed dial lists, provider to contact, videomail
> service interface point and similar items."
>
> It's hard for me to understand the scope of what falls into "other 
> similar items." Could any "common feature" fall in here? Or is there 
> some narrower scope limitation?
Benjamin commented:

> "[M]echanisms to provision the user’s device with
> common features such as speed dial lists, provider to contact, videomail
> service interface point and similar items" are a bit far afield from 
> our usual ambit of
> "bits on the wire", but I do not object to them in this case.
Grouping these two comments together: I'm fairly sure what the 
proponents have in mind here is configuration based on RFC 6080 and/or 
RFC 6011 mechanisms. I wouldn't be surprised if they end up registering 
a new Configuration Profile Type in 
<https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-67>, 
for example. If either of you think there is a better way to phrase 
this, please propose text.


Benjamin commented:

> Do we want to give guidance on what track the document that is the 
> output of this group
> would be published?

I think I'm happy with letting the WG decide this based on the contents 
of the document they produce. The charter already indicates that no new 
protocol mechanism will be defined. I don't see the value in 
pre-deciding, e.g., Informational versus BCP.


Mirja commented:

> I still think that it is too much overhead to from a new wg for just 
> this one doc. However, I understand that there might not be a better 
> option in ART. Maybe it's worth it to consider forming some kind of 
> area group in the future that could handle these kind of proposals.
The ART community finds the DISPATCH model useful for providing focus. 
I'll note that SEC has found this useful enough that it has adopted a 
similar model in the form of SECDISPATCH.


EKR Commented:

> I note that RUM is a term of art on the Apps side of the house in ART 
> ("Real User Monitoring") so you might reconsider the name.

While I do find evidence of this usage out in the world at large, I 
don't see evidence that it collides with use inside the IETF [1]. I plan 
to keep the name as-is, and will ask the secretariat to send the charter 
for review momentarily.

/a

____
[1] https://www.google.com/search?q=site%3Aietf.org+"real+user+monitoring"