Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

[Jouni Korhonen <[e-mail]>]

Ted,

On Nov 24, 2013, at 4:56 AM, Ted Lemon <[e-mail]> wrote:

> On Nov 23, 2013, at 3:19 PM, Jouni Korhonen <[e-mail]> wrote:
>> For me UUID is a binary blod. Obviously you need to know to type of the
>> binary you are carrying.
> 
> You are just stating an opinion—what are we supposed to do with that?   Can you say what the reason is behind your opinion, and how you intend for your blob to work?

The starting point was unifying the encoding of PVD-IDs across protocols they get carried over and having the PVD-IDs defined in one place. Therefore, from the protocol point of view that carries the PVD-ID, it is always considered as a binary blob; for example in case of DHCPv6 or NDP the PVD-ID option would just be Type(PDV-ID)+Length(PVD-ID with necessary paddings)+Value(binary blob).

Then a spec (to be) that defines the PVD-IDs with unified encoding describes how the "binary blob" is interpreted. That would then be Type(ID)+ID_specific_fields.

The receiver and sender can know what the "binary blob" is for the PVD-ID and how to process it. Also the parsing is unified to a degree that a receiver can skip the ID if it does not understand its type.

Anyway, back to "human readable" part. Say that my PVD-ID is basically a binary construction. I see no reason to add another set of data to make my binary encoded PVD-ID human readable on wire. That is just unnecessary and duplicate information. Any parser or diagnostic tool that understands the used PVD-ID type can display something user friendly out of it - when needed. 

- Jouni