Subject: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12

From: Joel Halpern <[email-masked]>
Date: Thu, 15 Dec 2016 19:57:28 -0800

Reviewer: Joel Halpern
Review result: Ready with Issues

Major:
    This document defines a new code for use in SIP, and specifies new
behavior both for the code itself and for its use in history-info.  I
am thus confused as to how this can be an informational RFC.  It looks
like it either Proposed Standard or experimental.  Yes, I see that RFC
4458, which this updates is Informational.  But just because we did it
wrong before does not make that behavior correct now.  In addition to
my understanding of the roles of different RFCs, I note that RFC 3969
and the IANA registry both state that this assignment must be made by
a standards track RFC.

Minor:
   Given our emphasis on IPv6 over IPv4, would it not make sense for
the examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 15 Dec 2016 22:28:53 -0600

Hi Joel,

Thanks for the comments. There has been a fair amount of discussion 
about the status of the draft. The situation is clearly not optimal, and 
I welcome input on how to straighten it out.

The rational so far has been that this draft updates RFC 4588, which is 
informational. It adds some additional values and related semantics for 
the "cause" parameter from 4588. It does not register new parameters; 
rather it adds itself as a reference in the existing "cause" 
registration. This is mainly a courtesy to readers. (There is no 
sub-registry for "cause" parameter values.) We might could get by 
without that change, since in a perfect world people following the IANA 
reference to 4588 would notice the "Updated by..." tag.

The gotcha is that RFC 4588 would not be possible as an informational 
today; it would not have standing to register the "cause" parameter. But 
at the time it was published, there was a lack of clarity around the 
"standards action" policy for the SIP URI parameters registry. Making 
the new values from _this_ draft standards track, when the parameter 
itself is not, doesn't seem appropriate. We had some discussion about 
whether we should promote 4588 to PS, but there was not consensus to do 
so when it was published, and I don't see reason to expect that to have 
changed.

This draft is primarily intended to meet a need in 3GPP, where I 
understand they are effectively already doing this. Would it help to 
more tightly scope this as "Here's something 3GPP is doing..." rather 
than as a general mechanism?

Thanks!

Ben.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Dec 2016 23:35:33 -0500

I see your point about this adding a value to the entry created by RFC 4458.
Is there a reason this can not simply be PS?  The fact that 4458 is 
Informational does not, as far as I can tell, justify continuing the 
error.  While this is for a 3GPP usage, it appears to have been reviewed 
by the Dispatch WG sufficiently to justify PS.
One could argue that there is a down-ref issue, but the fact that the 
field is in a standards-track required registry would seem to make that 
a moot point.

Yours,
Joel

PS: It would seem that WG discussion of that sort is something we would 
like to see in Shepherd writeups.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Dec 2016 22:51:31 -0600

> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Is there a reason this can not simply be PS?  The fact that 4458 is Informational does not, as far as I can tell, justify continuing the error.  While this is for a 3GPP usage, it appears to have been reviewed by the Dispatch WG sufficiently to justify PS.
> One could argue that there is a down-ref issue,
> but the fact that the field is in a standards-track required registry would seem to make that a moot point.
> 

Do you think it makes sense to make some new values for “cause” into a proposed standard when “cause” itself is informational?  That seems like a pretty big downref issue, as such issues go. (For the record, I could be convinced to re-run this LC as PS, but I suspect that would lead to objections in the opposite direction.)

Right now, the situation is a standards-action registry with a informational entry. That’s clearly broken, but I’m not sure that _this_ draft is the place to fix it.

Also, if it makes any difference—even there there was discussion in dispatch, this is not a dispatch work item.

> Yours,
> Joel
> 
> PS: It would seem that WG discussion of that sort is something we would like to see in Shepherd writeups.

There’s two paragraphs on the subject in section (1) of the shepherd writeup :-)  (but it wasn’t a working group discussion per se.)

Thanks!

Ben.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Dec 2016 00:07:07 -0500

At this point I will defer to the relevant ADs.
As far as I can tell, although the entry was created by an Informational 
RFC, the registry still claims that it is standards track.
And since this document is defining behavior, it behaves more like a 
standards track document than an Informational one.

But it is up to you folks.  In teh end, all I can do is raise the 
question, not decide it :-)

Yours,
Joel

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Dec 2016 10:11:09 -0700

> On Dec 15, 2016, at 10:07 PM, Joel M. Halpern <[email-masked]> wrote:
> 

+1 on that :-)

> As far as I can tell, although the entry was created by an Informational RFC, the registry still claims that it is standards track.
> And since this document is defining behavior, it behaves more like a standards track document than an Informational one.
> 
> But it is up to you folks.  In teh end, all I can do is raise the question, not decide it :-)

So the registry takes PS to change it. And by the current SIP rules, I suspect (not sure) that an update to 4458 would also have to be PS. So really not sure how one gets around this not being PS.

---

From: <[email-masked]>
Date: Mon, 19 Dec 2016 17:31:14 +0000

Hi,

If I can suggest an alternative: to make this document obsolete RFC4458 (adding RFC4458 content) with the argument that RFC4458 was informational but because it defined SIP protocol element and procedures, it is obsoleted to align with IETF rules and IANA registration of this parameter with no technical modification. The justification is not really strong but it would correct the current situation.

BR,
Marianne

-----Message d'origine-----
De : Cullen Jennings [mailto:[email-masked]] 
Envoyé : lundi 19 décembre 2016 18:11
À : Joel Halpern
Cc : Ben Campbell; DISPATCH; IETF; [email-masked]
Objet : Re: Review of draft-mohali-dispatch-cause-for-service-number-12

+1 on that :-)

>>> One could argue that there is a down-ref issue, but the fact that 
>>> the field is in a standards-track required registry would seem to make that a moot point.
>>> 
>> 
>> Do you think it makes sense to make some new values for “cause” into 
>> a proposed standard when “cause” itself is informational?  That seems 
>> like a pretty big downref issue, as such issues go. (For the record, 
>> I could be convinced to re-run this LC as PS, but I suspect that 
>> would lead to objections in the opposite direction.)
>> 
>> There’s two paragraphs on the subject in section (1) of the shepherd 
>> writeup :-)  (but it wasn’t a working group discussion per se.)
>> 
>> Thanks!
>> 
>> Ben.
>> 
>>> 
>>>> about the status of the draft. The situation is clearly not 
>>>> optimal, and I welcome input on how to straighten it out.
>>>> 
>>>> The rational so far has been that this draft updates RFC 4588, 
>>>> which is informational. It adds some additional values and related 
>>>> semantics for the "cause" parameter from 4588. It does not register 
>>>> new parameters; rather it adds itself as a reference in the existing "cause"
>>>> without that change, since in a perfect world people following the 
>>>> IANA reference to 4588 would notice the "Updated by..." tag.
>>>> 
>>>> The gotcha is that RFC 4588 would not be possible as an 
>>>> informational today; it would not have standing to register the 
>>>> "cause" parameter. But at the time it was published, there was a 
>>>> lack of clarity around the "standards action" policy for the SIP 
>>>> URI parameters registry. Making the new values from _this_ draft 
>>>> standards track, when the parameter itself is not, doesn't seem 
>>>> appropriate. We had some discussion about whether we should promote 
>>>> 4588 to PS, but there was not consensus to do so when it was 
>>>> published, and I don't see reason to expect that to have changed.
>>>> 
>>>> understand they are effectively already doing this. Would it help 
>>>> to more tightly scope this as "Here's something 3GPP is doing..." 
>>>> rather than as a general mechanism?
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>>>   This document defines a new code for use in SIP, and specifies 
>>>>> new behavior both for the code itself and for its use in 
>>>>> history-info.  I am thus confused as to how this can be an 
>>>>> informational RFC.  It looks like it either Proposed Standard or 
>>>>> experimental.  Yes, I see that RFC 4458, which this updates is 
>>>>> Informational.  But just because we did it wrong before does not 
>>>>> make that behavior correct now.  In addition to my understanding 
>>>>> of the roles of different RFCs, I note that RFC 3969 and the IANA 
>>>>> registry both state that this assignment must be made by a standards track RFC.
>>>>> 
>>>>> Minor:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 19 Dec 2016 11:40:56 -0600

On Mon, Dec 19, 2016 at 11:11 AM, Cullen Jennings <[email-masked]> wrote:

> So the registry takes PS to change it. And by the current SIP rules, I
> suspect (not sure) that an update to 4458 would also have to be PS. So
> really not sure how one gets around this not being PS.
>
[MB] I don't have a problem to make this document PS, but then I think we
need to revise 4458 as PS (in which case I hope we don't reopen the can of
worms around that one as it's something that I don't think we'd approve
today). [/MB]

> error.  While this is for a 3GPP usage, it appears to have been reviewed by
> the Dispatch WG sufficiently to justify PS.
> >> Do you think it makes sense to make some new values for “cause” into a
> proposed standard when “cause” itself is informational?  That seems like a
> pretty big downref issue, as such issues go. (For the record, I could be
> convinced to re-run this LC as PS, but I suspect that would lead to
> objections in the opposite direction.)
> >>
> >> Right now, the situation is a standards-action registry with a
> informational entry. That’s clearly broken, but I’m not sure that _this_
> draft is the place to fix it.
> >>
> >> Also, if it makes any difference—even there there was discussion in
> dispatch, this is not a dispatch work item.
> >>
> >>> Yours,
> >>> Joel
> >>>
> IANA

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 19 Dec 2016 12:22:38 -0600

Hi,

Am I correct in assuming that you would intend the merged draft as PS? 
If so, there's no _functional_ difference between that and promoting 
4458 to PS. It seems to me that a key issue in this discussion is about 
whether it would be _necessary_ and _reasonable_ to promote 4458 (or the 
mechanism therein) in order to make this draft PS.

Given that this draft depends on the mechanism in RFC 4458, promoting it 
to PS and not also promoting 4458 would create a downref. While the IESG 
can approve downrefs, I'm not sure it would make sense to approve this 
particular downref unless people already think 4458 is mature enough to 
promote. (I have my doubts that they do, based on the comment from Mary 
and offline comments from others.)

Thanks,

Ben.

On 19 Dec 2016, at 11:31, [email-masked] wrote:

> Hi,
>
> If I can suggest an alternative: to make this document obsolete 
> RFC4458 (adding RFC4458 content) with the argument that RFC4458 was 
> informational but because it defined SIP protocol element and 
> procedures, it is obsoleted to align with IETF rules and IANA 
> registration of this parameter with no technical modification. The 
> justification is not really strong but it would correct the current 
> situation.
>
> BR,
> Marianne
>
> Cc : Ben Campbell; DISPATCH; IETF; 
> [email-masked]
> Objet : Re: Review of 
> draft-mohali-dispatch-cause-for-service-number-12
>
>
>> As far as I can tell, although the entry was created by an 
>> Informational RFC, the registry still claims that it is standards 
>> track.
>>>> Informational does not, as far as I can tell, justify continuing 
>>>> the error.  While this is for a 3GPP usage, it appears to have been 
>>>> reviewed by the Dispatch WG sufficiently to justify PS.
>>> informational entry. That’s clearly broken, but I’m not sure 
>>> that _this_ draft is the place to fix it.
>>>
>>> Also, if it makes any difference—even there there was discussion 
>>> in dispatch, this is not a dispatch work item.
>>>
>>>> Yours,
>>>> Joel
>>>>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 19 Dec 2016 12:31:34 -0600

>> At this point I will defer to the relevant ADs.

:-)

> So the registry takes PS to change it.

To reiterate a previous comment on the thread: This draft does not add 
an entry to the registry, rather it adds a reference to an existing 
entry. The only point of the registry change is to make it convenient 
for implementors to discover that this draft updates 4458, which 
registered the entry in the first place. I'm not convinced that's 
completely necessary. But it might make sense to relax the standards 
action for this particular entry for historical reasons.

(Recognizing that the SIP URI parameter registry is messed up, also for 
"historical reasons".)

> And by the current SIP rules, I suspect (not sure) that an update to 
> 4458 would also have to be PS. So really not sure how one gets around 
> this not being PS.

I think this is the important decision to make. Setting the draft status 
based on the registration policy is an exercise in dog-wagging.

>>>> but the fact that the field is in a standards-track required 
>>>> registry would seem to make that a moot point.
>>>>
>>>
>>> Do you think it makes sense to make some new values for “cause” 
>>> into a proposed standard when “cause” itself is informational?  
>>> That seems like a pretty big downref issue, as such issues go. (For 
>>> the record, I could be convinced to re-run this LC as PS, but I 
>>> suspect that would lead to objections in the opposite direction.)
>>>
>>> There’s two paragraphs on the subject in section (1) of the 
>>> shepherd writeup :-)  (but it wasn’t a working group discussion 
>>> per se.)
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>>
>>>>> optimal, and
>>>>> which is
>>>>> informational
>>>>> to
>>>>>> new

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Dec 2016 16:49:36 -0600

On 12/15/16 22:28, Ben Campbell wrote:
> today; it would not have standing to register the "cause" parameter. 
> But at the time it was published, there was a lack of clarity around 
> the "standards action" policy for the SIP URI parameters registry.

I don't think that's true. We're talking about a registry established by 
RFC 3969, which says:

   "SIP and SIPS URI parameters and values for these parameters MUST be
    documented in a standards-track RFC in order to be registered by
    IANA."

...and...

   "For the purposes of this registry, the parameter for which IANA
    registration is requested MUST be defined by a standards-track RFC."

These are not ambiguous statements. We just botched our communication 
with IANA.

But I think we can do the right thing here without going back and fixing 
all of the issues with our ancestral documents. I mean, sure, maybe we 
should clean that up too, but I don't see the value in blocking new work 
on doing so.

In terms of publishing draft-mohali-dispatch-cause-for-service-number, I 
think there are two reasonable paths forward:

The first would be forming consensus that the two statements I quote 
from 3969 above -- and the reinforcing statement in 5727 -- were all 
incorrect, and that we want to explicitly (i.e., in a new document) 
reverse those statements and update the corresponding registration 
policy. Then, we publish -mohali- as informational.[1]

The second would be implicitly accepting established consensus around 
this registry, and consequently changing -mohali- to PS.

Rather than figuring out which of these is easier (clearly, the second 
is less work), I think the real question here is: do we think we got the 
registration policy for SIP URI parameters wrong?

/a

____
[1] We *might* or might *not* also decide to then do something about RFC 
4458 in this case, but that's a completely separate decision.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 20 Dec 2016 17:03:06 -0600

On 20 Dec 2016, at 16:49, Adam Roach wrote:

> I don't think that's true. We're talking about a registry established 
> by RFC 3969, which says:
>

For the record, I did not say the RFC was ambiguous. I said "we had a 
lack of clarity". I think having one policy listed in IANA and another 
in the RFC counts. I offer as evidence of said lack of clarity the fact 
that RAI got things wrong with 4458 (My typo of it as 4588 above 
upthread couldn't help, either) :-)
>
> But I think we can do the right thing here without going back and 
> fixing all of the issues with our ancestral documents. I mean, sure, 
> maybe we should clean that up too, but I don't see the value in 
> blocking new work on doing so.
>
> In terms of publishing draft-mohali-dispatch-cause-for-service-number, 
> I think there are two reasonable paths forward:
>

I think a potential third option is to consider whether -mohali- really 
needs to modify the registry. (I'm not saying it doesn't--I'm saying we 
should think about it.)

> is less work), I think the real question here is: do we think we got 
> the registration policy for SIP URI parameters wrong?
>

Keep in mind that the registry is not the only concern mentioned so far. 
Both 4458 and -mohali- define protocol. Reviewers have objected to that 
as well.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Dec 2016 17:27:45 -0600

I still think the shepherd's writeup caught this correctly:

>     draft-mohali-dispatch-service-number-translation
>     does not register a URI parameter; it just adds a reference
>     to an existing registration. The decision to keep these
>     documents informational is not intended to set precedent;
>     RFC 5727 remains the BCP for the SIP change process.

I personally see no win in trying to force this document to be PS (and 
fixing the things in it, and in what 3gpp plans to do with it to let it 
fly as PS) or in changing the registry at this point. This has an odor, 
but it is not really making the world worse, and the energy that it 
would require from ours and the 3gpp communities to remove the odor does 
not strike me as the right place to make our investements.

Hold your noses and let this go please.

One more general comment inline below:

RjS

On 12/20/16 5:03 PM, Ben Campbell wrote:
>>> lack of clarity around the "standards action" policy for the SIP URI 
>>> parameters registry.
>>
> in the RFC counts. I offer as evidence of said lack of clarity the 
> fact that RAI got things wrong with 4458 (My typo of it as 4588 above 
>> In terms of publishing 
>> draft-mohali-dispatch-cause-for-service-number, I think there are two 
>> reasonable paths forward:
>>
> I think a potential third option is to consider whether -mohali- 
> really needs to modify the registry. (I'm not saying it doesn't--I'm 
> saying we should think about it.)
>
>>
>> Rather than figuring out which of these is easier (clearly, the 
>> second is less work), I think the real question here is: do we think 
>> we got the registration policy for SIP URI parameters wrong?
>>
>
> Keep in mind that the registry is not the only concern mentioned so 
> far. Both 4458 and -mohali- define protocol. Reviewers have objected 
> to that as well.
We have _MANY_ Informational documents that define protocol. That, by 
itself, is not the metric for "not Informational".

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 20 Dec 2016 17:49:01 -0600

On 20 Dec 2016, at 17:27, Robert Sparks wrote:

> fixing the things in it, and in what 3gpp plans to do with it to let 
> it fly as PS) or in changing the registry at this point. This has an 
> odor, but it is not really making the world worse, and the energy that 
> it would require from ours and the 3gpp communities to remove the odor 
> does not strike me as the right place to make our investements.
>

In case it has been unclear from my other comments, this is my 
preference as an individual as well.

One thing for people to keep in mind is that, as mentioned in the quote 
above, all the registration change does is add this draft to the 
references for the entry that 4458 originally registered. Given that 
this draft updates 4458, that seems appropriate. The fact that 4458 
registered that incorrectly is a problem we might fix someday, but that 
doesn't mean _this_ draft has to fix it.

> One more general comment inline below:

[...]

> itself, is not the metric for "not Informational".

Would people find the informational status more palatable if the draft 
clarified that this is for 3GPP, and that we don't endorse it for other 
contexts?