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

[Ian Farrer <[e-mail]>]

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]> 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]>>> 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]>>> 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]>>
>>>>> 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]>>
>>>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif>