Subject: [Ecrit] Additional Data blocks and device specific type registries

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 14 Mar 2013 18:15:39 +0000

As I reviewed in the meeting, there are two ways to add data to additional-data:
1. Add a type to the device/service specific data type registry, and put a URL to it in the DevInfo block
2. Define a new type

Turns out there is a problem with the IANA considerations section - the device/service specific registry wasn't there.  I added it, but in doing so, I ran across a problem:
The management policy for the block registry is Expert Review and Specification required.  I think we need that, at minimum, for the device/service specific type, but I also think we want more review for new blocks that for device/service specific data.

So, should I make the blocks registry IETF Review?

We could do something more complicated which basically qualifies "Specification Required" to be some quasi-real SDO doc for the block registry, rather than, say, some vendor proprietary doc.  The latter might be okay for the device/service specific registry.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Mar 2013 15:51:27 -0400

Specification required seems adequate.  You'd have to convince me that
we have either limited space for registrations (we don't) or that
there was some risk of harm in private registrations.  The risk we run
if we do raise the bar on this is that we effectively encourage people
to extend existing blocks when a new block is the most appropriate
choice.

On 14 March 2013 14:15, Rosen, Brian <[email-masked]> wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 14 Mar 2013 19:56:40 +0000

In the end, if we make one harder than the other, then folks who have weak reasons will choose the easy one.  The "harm" is proliferation of data types that PSAPs are asked to contend with.  We don't want a whole lot of different data choices.

That said, it still seems to me that new blocks should have somewhat more scrutiny than new device/service specific data.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Mar 2013 16:06:41 -0400

On 14 March 2013 15:56, Rosen, Brian <[email-masked]> wrote:
> In the end, if we make one harder than the other, then folks who have weak reasons will choose the easy one.

This is my point exactly.

> The "harm" is proliferation of data types that PSAPs are asked to contend with.  [...]

I don't find this especially convincing.

> That said, it still seems to me that new blocks should have somewhat more scrutiny than new device/service specific data.

"seems" isn't strong enough for me.  From my perspective, a new block
can be ignored just as easily as new XML elements.  They just have
slight different ways of labelling (MIME media type vs. XML QName).

I'd like something stronger to go on than "seems to Brian", as much as
I respect the ability of your gut to discern the correct technical
solution :)

---

From: Randall Gellens <[email-masked]>
Date: Fri, 15 Mar 2013 11:36:58 -0700

>  to extend existing blocks when a new block is the most appropriate

I agree.

At 7:56 PM +0000 3/14/13, Brian Rosen wrote:

>  In the end, if we make one harder than the other, then folks who 
> have weak reasons will choose the easy one.  The "harm" is 
> proliferation of data types that PSAPs are asked to contend with. 
> We don't want a whole lot of different data choices.

I think a worse risk is mangling or misusing blocks (by shoving data 
in that doesn't belong).  If there are separate blocks, it becomes 
easier for PSAPs to accept those that are useful and they need to.

>  That said, it still seems to me that new blocks should have 
> somewhat more scrutiny than new device/service specific data.

The only advantage I can see of this is that it encourages use of the 
device block, which implicitly forces new data to be by reference, 
making it easier for a PSAP to not fetch a URL.  While that is 
advantageous, I'm not sure it's compelling enough to bias towards one 
rather than the other.

In general, it seems to me that we've caused ourselves more trouble 
when we made registration harder than easier.

I'd suggest 'specification required' for both, with guidance text for 
how to choose which way to go.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Wealth is not only money.
Wealth can be happiness in your sweetheart or your honey.
  --(Fortune cookie)