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

Tommy Pauly <tpauly@apple.com> Wed, 04 November 2015 09:13 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE91B2B9E for <mif@ietfa.amsl.com>; Wed, 4 Nov 2015 01:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMwWU1xd8d3U for <mif@ietfa.amsl.com>; Wed, 4 Nov 2015 01:13:17 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2831A1A038C for <mif@ietf.org>; Wed, 4 Nov 2015 01:13:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1446628395; x=2310541995; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0POzXrFValK62yD9DklfVIvwpjTpBbqLpOorbAZdI2k=; b=qtWalt9oulRkGsXQP+i5WnbCmZBpqEb6VXcRv2SqVAppsTE0C4dgV8rZT5RfcCUV 1l9xnxt/CW2h6Mf2NFM7GPF16bWnQKygDwZLORvR9QXuAh7nGB5Y2vtpMxP/1fuz KdIp+m5jYmkVpVe4UIqYVURK9/BGnfoMJRlf7uRnZM0OlvwhUYurq1ky7sjtdU4o ikLiNuN45vB95wCFUmw3VT6//AT6tLYT0Svgu+zDM3+MlvvNG4awgeHHfNXyk5IG DKxPWvH313e2/dDtE5olNa5m7a2Qnd1LUR+FN3rnSH1u6MT3sxlYnj73DZJU/d6W tVoYMy3PlnajGF+2lS+dHQ==;
Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 15.BD.12069.B2CC9365; Wed, 4 Nov 2015 01:13:15 -0800 (PST)
X-AuditID: 11973e12-f79c06d000002f25-70-5639cc2bf65b
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id EB.5C.29028.B2CC9365; Wed, 4 Nov 2015 01:13:15 -0800 (PST)
Received: from [17.83.115.85] (unknown [17.83.115.85]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NXA00M399M1L340@spicerack.apple.com> for mif@ietf.org; Wed, 04 Nov 2015 01:13:15 -0800 (PST)
Sender: tpauly@apple.com
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (1.0)
From: Tommy Pauly <tpauly@apple.com>
X-Mailer: iPhone Mail (13A342)
In-reply-to: <6178F689-9321-41AD-B9AA-550C8A12FF05@gmail.com>
Date: Wed, 04 Nov 2015 18:13:15 +0900
Content-transfer-encoding: quoted-printable
Message-id: <28FFBD43-EEBC-4C65-8BA3-CE2E93A9DB2C@apple.com>
References: <COL125-W4170BE78E2C2F41BC3A6B4B19B0@phx.gbl> <79C18793-758C-421A-A0C6-2F5625F1E17E@gmx.com> <55AD3922.8090009@gmail.com> <69E5A45D-C11A-4383-A4EE-AEF05675E718@gmx.com> <55AE2288.5070509@gmail.com> <74F2D07D-4FB2-4FB6-B482-EF202B4D533F@gmx.com> <55AF625B.5040506@gmail.com> <352EAA2D-0D69-40F6-8C6B-8980DD780AEA@gmx.com> <F3183EA8-8933-4592-A2DE-4602B6668696@apple.com> <6178F689-9321-41AD-B9AA-550C8A12FF05@gmail.com>
To: Jouni <jouni.nospam@gmail.com>
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FCYpqt9xjLM4MEPbYuuPTeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfOoY8GOuIqJc/4wNzAe8e1i5OSQEDCRWDP7ERuELSZx4d56 MFtIYB+jxK59ETA102efZoaIT2aSeLihpIuRC8iexCSx/O0xoAQHh7CAhMTmPYkgJrOAusSU Kbkg5bwC4hKvj05hBLGFBYwkzq49wgpiswmoSBz/tgGsU0JATmJFKydImFPAVqJ74312EJtF QFXi769/YK3MAqkS/7dfYYKwtSWevLvACjHeRmLVgevMENfsYpZY03gArFlEQEliSfsqNpCE hMASNoltPx+zTmAUmYVw3iwk581CMncBI/MqRqHcxMwc3cw8E73EgoKcVL3k/NxNjKCwnm4n tIPx1CqrQ4wCHIxKPLwN/y3ChFgTy4orcw8xSnOwKInzHtKyDBMSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAaO5hwlTvZRz21HvFVv8pWpG3QqoXCioVz/i9cdZJ5cjtUdt+sgZ5rXy91kPh aNvdLVsba462Jhbv/Pbz2aZlG30PZO1dE3/pzZ99AcF1r7h9Qrl1VZ6vfcIbVi1rPu9WzbsT Xze8/m4xd97rqJ+aRaf2ZZvF9BxMeu0Qoue0/t++tQnXv/xvKFBiKc5INNRiLipOBABPrWcj TAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUi2FCsoat9xjLM4GWjhkXXnhtMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuHnUsWBHXMXEOX+YGxiP+HYxcnJICJhITJ99mhnCFpO4cG89 G4gtJDCZSeLhhpIuRi4gexKTxPK3x4CKODiEBSQkNu9JBDGZBdQlpkzJBSnnFRCXeH10CiOI LSxgJHF27RFWEJtNQEXi+LcNYJ0SAnISK1o5QcKcArYS3Rvvs4PYLAKqEn9//QNrZRZIlfi/ /QoThK0t8eTdBVaI8TYSqw5cZ4a4ZhezxJrGA2DNIgJKEkvaV7FNYBSchXDRLCQXzUIyagEj 8ypGgaLUnMRKC73EgoKcVL3k/NxNjOBALEzbwdi03OoQowAHoxIPb8N/izAh1sSy4srcQ4wS HMxKIrympyzDhHhTEiurUovy44tKc1KLDzEmAz0wkVlKNDkfGCV5JfGGJiYGJsbGZsbG5ibm pAkrifOWbjUPExJITyxJzU5NLUgtgtnCxMEp1cDI9YBl5ZmZbKLbV3JuNRY8Krb4Zzt3Gc/t PdvCZj79bfVk+ub0BH72L/Mfz8ic0yV22ECeddaUQoczCyedtLH/e2VPEQcXd42j4f7w0uez G9ZyROR95fDT/Dcvrbj+yQu94vXejm6Omw8c97bje1HK9PrLq78HJH7w3OXln8W7uT7ySdcp 2eVvlViKMxINtZiLihMBLI6+s4gCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/p_BQpHwyVLr2FK8YduZqPEjodvY>
Cc: Hui Deng <denghui02@hotmail.com>, "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-id
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 09:13:20 -0000

The agreement is strongest for the fixed size type. 

I do think this ID should be associated with extensible metadata, but that may or may not be carried along in the same protocol as the type. We discussed several options for looking up the metadata after receiving the ID up front. 

Thanks,
Tommy

> On Nov 4, 2015, at 6:05 PM, Jouni <jouni.nospam@gmail.com> wrote:
> 
> 
> Just a clarifying question. “Strongly agree” is only for the fixed-size type (e.g., UUID), not for the extensible additional metadata carried along with the fixed-size type (as advocated in Ian’s mails)?
> 
> - Jouni
> 
>> On 03 Nov 2015, at 22:11, Tommy Pauly <tpauly@apple.com> wrote:
>> 
>> 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 <ianfarrer@gmx.com> 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’). 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 <jouni.nospam@gmail.com> 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 <jouni.nospam@gmail.com
>>>>>> <mailto:jouni.nospam@gmail.com>> 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 <jouni.nospam@gmail.com
>>>>>>>> <mailto:jouni.nospam@gmail.com>
>>>>>>>> <mailto:jouni.nospam@gmail.com>> 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 <denghui02@hotmail.com
>>>>>>>>>> <mailto:denghui02@hotmail.com>
>>>>>>>>>> <mailto:denghui02@hotmail.com>
>>>>>>>>>> <mailto:denghui02@hotmail.com>> 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
>>>>>>>>>> mif@ietf.org
>>>>>>>>>> <mailto:mif@ietf.org><mailto:mif@ietf.org><mailto:mif@ietf.org>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mif
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> mif mailing list
>>>>>>>>> mif@ietf.org <mailto:mif@ietf.org><mailto:mif@ietf.org>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mif
>>> 
>>> _______________________________________________
>>> mif mailing list
>>> mif@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mif
>> 
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>