Subject: [dispatch] Observations on process after reviewing the iotl draft

From: Robert Sparks <[email-masked]>
Date: Thu, 18 Dec 2014 15:20:44 -0600

All -

I just sent in a gen-art LC review on the iotl draft. While putting that 
review together, I went back through the email discussion of the draft, 
and when taking it in all at once like that I saw a few things I think 
we should discuss.

First, Christer has worked very hard to do the right thing, and to get 
the IETF community to do the right thing with this draft. Thank you 
Christer. Please keep doing that.

Our response as a community was underwhelming, and very slow. I don't 
think we need to beat any individuals up about that, but I do think we 
have an opportunity to study how this went, so we can do better with 
other things.

There were concerns raised early (last May) about the design (URI 
parameter vs header field parameter) that I don't think were well 
resolved on list. When that discussion came up, I think we should have 
taken it as a flag that this would have benefited from a WG discussing 
it with a chair driving the discussion. When we decide to send something 
off to AD sponsorship in the future, the AD should watch for similar 
conversations and send it back to us (and we should help the AD of the 
time recognize what's happening). Again, I'm not trying to call what's 
in this document into question at this point. I just wish we had done 
better back in May.

Much of the discussion danced around URI parameters requiring 
standards-track, and header parameters only requiring informational, 
rather than which of those things (or something else) might have the 
most technical merit (and based on the conversation, there were 
implementors vested in the choice that had been made before the draft 
came here). As we've often seen, this points to bringing the problem 
here earlier, rather than the solution.

It also points out that the current standards-track requirement for URI 
parameters is probably overkill. I'd like to suggest we change that to 
specification required with expert review. The expert would not allow 
parameters that changed the semantics of the protocol unless the 
specification happened to be an IETF stream standards track document.

It was an interesting experiment using the dispatch list to refine the 
document's technical content. In my opinion, we should not do that again.

RjS

---

From: Andrew Allen <[email-masked]>
Date: Thu, 18 Dec 2014 23:10:05 +0000

+1 to changing URI parameters registration requirements to only require specification with expert review. I never understood why the bar was so high for IANA registration of URI parameters when other things like media feature tags only require expert review and can have as great if not greater impact on the protocol.

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: Thursday, December 18, 2014 4:21 PM
To: [email-masked]
Subject: [dispatch] Observations on process after reviewing the iotl draft

All -

I just sent in a gen-art LC review on the iotl draft. While putting that review together, I went back through the email discussion of the draft, and when taking it in all at once like that I saw a few things I think we should discuss.

First, Christer has worked very hard to do the right thing, and to get the IETF community to do the right thing with this draft. Thank you Christer. Please keep doing that.

Our response as a community was underwhelming, and very slow. I don't think we need to beat any individuals up about that, but I do think we have an opportunity to study how this went, so we can do better with other things.

There were concerns raised early (last May) about the design (URI parameter vs header field parameter) that I don't think were well resolved on list. When that discussion came up, I think we should have taken it as a flag that this would have benefited from a WG discussing it with a chair driving the discussion. When we decide to send something off to AD sponsorship in the future, the AD should watch for similar conversations and send it back to us (and we should help the AD of the time recognize what's happening). Again, I'm not trying to call what's in this document into question at this point. I just wish we had done better back in May.

Much of the discussion danced around URI parameters requiring standards-track, and header parameters only requiring informational, rather than which of those things (or something else) might have the most technical merit (and based on the conversation, there were implementors vested in the choice that had been made before the draft came here). As we've often seen, this points to bringing the problem here earlier, rather than the solution.

It also points out that the current standards-track requirement for URI parameters is probably overkill. I'd like to suggest we change that to specification required with expert review. The expert would not allow parameters that changed the semantics of the protocol unless the specification happened to be an IETF stream standards track document.

It was an interesting experiment using the dispatch list to refine the document's technical content. In my opinion, we should not do that again.

RjS

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Dec 2014 10:55:47 -0500

> +1 to changing URI parameters registration requirements to only require specification with expert review. I never understood why the bar was so high for IANA registration of URI parameters when oth…

I think this could work. The key, which we usually don't do well, is to 
specify clear criteria for the expert to use when evaluating a new 
parameter.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Dec 2014 19:50:56 +0000

+1

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 19 December 2014 17:56
To: [email-masked]
Subject: Re: [dispatch] Observations on process after reviewing the iotl draft

> +1 to changing URI parameters registration requirements to only require specification with expert review. I never understood why the bar was so high for IANA registration of URI parameters when oth…

I think this could work. The key, which we usually don't do well, is to specify clear criteria for the expert to use when evaluating a new parameter.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Dec 2014 16:38:45 -0500

> have an opportunity to study how this went, so we can do better with 

My response was hindered by certain unusual features of this draft, and
I suspect that other people were affected in the same way.  The
mechanism is 3GPP-specific, to the point where people had no idea how it
could be generalized to wider use.  The need for some mechanism of this
nature is clear.  The mechanism itself is (IMO) not an entirely proper
use of URI parameters -- but there is no better alternative.  So I've
not opposed the draft, but the circumstances inhibited me from giving it
the review it needed.

> specification happened to be an IETF stream standards track document.

I agree with that.

SIP systems seem to all be organized to ignore any URI parameters that
they don't understand.  As far as I know, there's no standard that says
that, but it seems to be the universal practice.  That principle
minimizes the risk of malfunction if a URI containing a parameter
"leaks" outside of the systems which implement the parameter.  That
means that we do not have to be deeply careful about introducing new URI
parameters.

Dale