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

[Jouni Korhonen <[e-mail]>]

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]>> 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]>> 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/
>>>>>>
>>>>>> 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]>
>>>>>> https://www.ietf.org/mailman/listinfo/mif
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mif mailing list
>>>>> [e-mail] <mailto:[e-mail]><mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/mif
>