Re: [mif] WGLC for draft-ietf-mif-mpvd-id

[Tommy Pauly <[e-mail]>]

Hello,

We’ve just had a meeting with various interested parties from the mif and homenet groups, and the question of PvD ID format came up as a point of confusion.

I wanted to resurrect this thread and strongly agree with Ian’s point that the ID type and format should converge to a single, well-known, fixed-size type. Specifically, many of us support the idea that there is a UUID type that can be used in all atomic provisioning exchanges (RAs, DHCP, IKE, etc), which can then be used for subsequent lookups of meta-data. This meta-data may include properties of the PvD that are relevant for the client, and can certainly also include the FQDN or more-string based types of identification.

Concerns with the many types of ID described in draft-ietf-mif-mpvd-id include:
- The size of the ID, although bounded in the draft to 255 bytes, may be far too large for RAs, etc. A fixed, small number of bytes is much more usable
- The content of the ID if it is a richer type (string, FQDN, etc) will be opaque to client devices, and essentially useless. If there is no added information, having more types and more lengths only adds processing overhead.

From the client perspective, whatever type the PvD has will have to mapped down to a fixed length identifier for use on a system, so communicating using that type on the network will be far simpler.

Thoughts?

Thanks,
Tommy

> On Jul 23, 2015, at 12:21 AM, Ian Farrer <[e-mail]> wrote:
> 
> Hi Jouni,
> 
> A set top box supplied by an operator could ship pre-configured to look for the PvD based on the UUID (if this is the chosen single unique identifier format). This UUID is advertised in RAs to the STB, so it can select it. It’s a closed system, so it’s achievable.
> 
> But the user may want to access the same content over the same PvD, but this time with a 3rd party streaming client on their laptop. Now there’s no pre-configured PvD to look for, so it would be useful to present something descriptive and human readable to the user to give them a chance of being able to select the right PvD for their app (e.g. you add the meta-data, associated with the same UUID as above, say the FQDN format ’streamingtv.bigtelco.com <http://streamingtv.bigtelco.com/>’). The FQDN format is standard, so the app without any knowledge of the operator’s network can interpret this and offer it to the user as a choice. Once the app is configured, it’s looking for the associated UUID as the unique identifier for the streaming PvD (i.e., if the laptop was moved to another subnet in the house that was running PvDs over RAs without the FQDN meta-data option, it would still be able to identify the right one to use).
> 
> Maybe you also want to attach an additional meta-data message in the DHCPv6 provisioning containing a URL for a page telling the user how to configure their client correctly. The URL is also associated with the PvD-ID (alongside the FQDN meta-data). Again, the URL would need to be a standard format.
> 
> And so on...
> 
> So, the extensible format allows for the mechanism to be augmented in the future (within the limits of what is implementable in a client / provisioning protocol). Several of these in different formats may be used and associated with a single PvD. Clients can ignore meta-data that they don’t understand, or a not configured to parse. Standard formats mean that devices/applications can interpret offered meta-data without having to be pre-configured (somehow) to run within a specific operators PvD architecture. 
> 
> Cheers,
> Ian
> 
> 
>> On 22 Jul 2015, at 11:28, Jouni Korhonen <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Now I do not really understand the desire for standardized format for metadata. You basically move to burden of multiple, some more descriptive IDs, to fully flexible/standardized metadata. Does not seem to improve the situation.
>> 
>> - Jouni
>> 
>> 7/21/2015, 4:17 AM, Ian Farrer kirjoitti:
>>> The meta-data formats would be standardised formats as well so that they
>>> can potentially be universally understood.
>>> 
>>> i.e. the id-formats that are enumerated in section 3 of the pad-id
>>> document (with the exception of the format which is chosen as the single
>>> unique Identifier) would form the initial set of PVD-ID meta data.
>>> 
>>> However, on thinking about this, maybe defining an additional type for
>>> 'PVD-ID owner binary blob’ could be an idea if people see a need for it.
>>> 
>>> Cheers,
>>> Ian
>>> 
>>> 
>>>> On 21 Jul 2015, at 12:44, Jouni Korhonen <[e-mail] <mailto:[e-mail]>
>>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
>>>> Thanks Ian,
>>>> 
>>>> And the metadata is just a binary blob only understood by the PVD-ID
>>>> "owner"?
>>>> 
>>>> - Jouni
>>>> 
>>>> 7/21/2015, 2:02 AM, Ian Farrer kirjoitti:
>>>>> Hi Jouni,
>>>>> 
>>>>> The specific things that I think need to be addressed here are:
>>>>> 
>>>>> 1, Removing the decision making process for an operator looking to
>>>>> choose the right format to use. This needs to be common across the whole
>>>>> of an operator’s network and so needs to be supported by all devices and
>>>>> advertising/provisioning protocols present and future. Once deployed at
>>>>> any scale, changing this will be non-trivial.
>>>>> 
>>>>> 2, At this stage in the development of the PvD architecture, it is very
>>>>> difficult to know how this will need to evolve and be extended in the
>>>>> future, so it is almost impossible to make an informed decision about
>>>>> what the best PvD format to choose is.
>>>>> 
>>>>> So, this is why I think that choosing a single format with a high
>>>>> probability of uniqueness and a small, defined size. But this needs to
>>>>> be combined with extensibility for adding meta-data to take advantage of
>>>>> the capabilities of less constrained devices and advertising protocols
>>>>> so that additional information can be supplied to allow clients /
>>>>> applications / users to make an informed decision about the PvD.
>>>>> 
>>>>> How I would see this working is that the PvD-ID itself would be a single
>>>>> format - e.g. UUID. This must be advertised in all provisioning
>>>>> messages. An additional DHCPv6/PIO option would then be defined that
>>>>> allows an operator to add additional meta-data options which are
>>>>> associated with the PVD-ID according to their needs / the capabilities
>>>>> of the device/protocols etc (i.e. the other PvD-ID formats that have
>>>>> been described in the draft).
>>>>> 
>>>>> This allows for the mechanism to be extended as needed without the need
>>>>> to change the PvD-ID formats that are in use in existing devices. If you
>>>>> want to extend your PvD architecture so that new devices have new logic
>>>>> for selecting the correct PvD based on new logic, then you can add a new
>>>>> PvD-ID meta-data option linked to an existing PvD-ID without needing to
>>>>> change the underlying PvD architecture or devices that you have deployed.
>>>>> 
>>>>> With the current mechanism as described, to make any changes to your PvD
>>>>> architecture to support new client PvD selection logic requires
>>>>> deploying another PvD format in parallel to the existing one. This is,
>>>>> by the PvD architecture a new PvD, even if the service properties are
>>>>> identical to an existing PvD which you have already deployed. Then, your
>>>>> provisioning protocols need to advertise duplicate configuration for
>>>>> both of the PvDs, even thought that configuration is the same, with the
>>>>> exception of the PvD-ID.
>>>>> 
>>>>> So, the short answer to your question is: Single PvD-ID format (I like
>>>>> UUID) + extensible associated meta-data.
>>>>> 
>>>>> Cheers,
>>>>> Ian
>>>>> 
>>>>> 
>>>>>> On 20 Jul 2015, at 20:08, Jouni Korhonen <[e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>>>> 
>>>>>> Ian,
>>>>>> 
>>>>>> So would UUID be adequate PVD-ID format as suggested below?
>>>>>> 
>>>>>> What about the additonal information part? Not needed?
>>>>>> 
>>>>>> - Jouni
>>>>>> 
>>>>>> 
>>>>>> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Before this document can proceed, I think that there is still a
>>>>>>> significant open point. Multiple or single PVD ID formats?
>>>>>>> 
>>>>>>> This question has been raised a few times at WG meetings, but there is
>>>>>>> no reflection in the draft as it stands. This is an excerpt from the
>>>>>>> IETF91 minutes:
>>>>>>> 
>>>>>>> Margaret: 2 changes proposed: move to single unique short ID (UUID)
>>>>>>> and allow for additional info to be a part of the ID. So can we
>>>>>>> try to reach consensus on each?
>>>>>>> 
>>>>>>> Who thinks we should move to one unique format?
>>>>>>> (a couple of hands; 2nd time asking had about 10 hands)
>>>>>>> Who thinks we should not use a single unique format?
>>>>>>> (no hands)
>>>>>>> OK. Single unique.
>>>>>>> 
>>>>>>> So, I would like to see this discussion take place before the document
>>>>>>> progresses.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Ian
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 14 Jul 2015, at 17:18, Hui Deng <[e-mail] <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>>>>>> 
>>>>>>>> Hello all,
>>>>>>>> 
>>>>>>>> We would like to have a 3 weeks WGLC for the below document:
>>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ <http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/>
>>>>>>>> 
>>>>>>>> Please help to send your comments to this thread.
>>>>>>>> This WGLC will end on Aug. 5th.
>>>>>>>> 
>>>>>>>> Many thanks
>>>>>>>> 
>>>>>>>> DENG Hui
>>>>>>>> _______________________________________________
>>>>>>>> mif mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail] <mailto:[e-mail]>><mailto:[e-mail] <mailto:[e-mail]>><mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> mif mailing list
>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>><mailto:[e-mail] <mailto:[e-mail]>>
>>>>>>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif