Re: [mif] WGLC for draft-ietf-mif-mpvd-id
Tommy Pauly <tpauly@apple.com> Wed, 04 November 2015 06:11 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 786331ACE5E for <mif@ietfa.amsl.com>; Tue, 3 Nov 2015 22:11:35 -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, HTML_MESSAGE=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 QI56p_XU13yu for <mif@ietfa.amsl.com>; Tue, 3 Nov 2015 22:11:31 -0800 (PST)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3021ACE2F for <mif@ietf.org>; Tue, 3 Nov 2015 22:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1446617491; x=2310531091; 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=LbxUJ3JmIFtf2KtupFWJAnNiEsIb/JGqJajSPjJyULM=; b=Jvb+gSjqQuX3qdQcISY+XQkM82QViZzMpsOfQPLZ6Lf6sYLS+DCUsU/e2EdgZIVy Z3ARO9xNd1xJmsypqBnr+dRrR/uwSt3MJbTytak+xvy5uGdC14uLMfikbPlOpxTC y+Tlps4aBmhOiY3JAlIH8q/GCcWxPwcGmfLdbguKb2CevYFjUsi/9dITHHYG+5pg kBdpHOByPFNPurs9qEnSKl1VhE5fclMKUKfQzYM70IN3Nuzzq7re4wfXJUTDcsnb J+5WKVCg4hMzTzPxVPkJbgTGWrqQiaYv9jLaE70ryM1RS78sGDoZQwKs3QRVr++T yK8lk05Fm+SkP3H3hVP5Lg==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 73.B5.30381.291A9365; Tue, 3 Nov 2015 22:11:30 -0800 (PST)
X-AuditID: 11973e16-f79a26d0000076ad-db-5639a192d221
Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 35.CF.29392.291A9365; Tue, 3 Nov 2015 22:11:30 -0800 (PST)
Received: from [17.153.82.174] (unknown [17.153.82.174]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NXA00KAI173DN30@chicory.apple.com> for mif@ietf.org; Tue, 03 Nov 2015 22:11:30 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_01914FFF-77ED-43A9-A136-2C4190843A11"
Message-id: <F3183EA8-8933-4592-A2DE-4602B6668696@apple.com>
MIME-version: 1.0 (Mac OS X Mail 9.2 \(3106\))
Date: Wed, 04 Nov 2015 15:11:29 +0900
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>
To: Ian Farrer <ianfarrer@gmx.com>, "mif@ietf.org" <mif@ietf.org>, Hui Deng <denghui02@hotmail.com>
In-reply-to: <352EAA2D-0D69-40F6-8C6B-8980DD780AEA@gmx.com>
X-Mailer: Apple Mail (2.3106)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUi2FAYpTtpoWWYQfN0G4uuPTeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsf3ZLZaCY28YK9Z9WsvUwLj2JGMXIyeHhICJxNT/U5ghbDGJ C/fWs3UxcnEICexllDjbfx2uqGHNUWaIRD+TROftNiYIp49J4uGRrUAZDg5hAQmJzXsSQRrY BFQkjn/bADaVWSBJoufWDlYQm1fARmL/hZ9sIOW8AnoSa49XgoSFBYwkzq49AlbCIqAq8WDb REaI8VeYJG4t+cAOkhARSJWYfOIsC4jNKWAtcXr7c6jjZCU6u+6CNUgIbGCTeHhvA+sERqFZ SHbPQtgHEdaWWLbwNTOEbSDxtPMVK6a4vsSbd3OYFjCyrWIUyk3MzNHNzDPXSywoyEnVS87P 3cQICv3pdmI7GB+usjrEKMDBqMTDe4PRMkyINbGsuDL3EKM0B4uSOO9WLaCQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxqR5rTvWvz9r8fHKuYZt+WYMrzmmLJhoO3NTrSbPeh7OxrkaewJT 6v1eckhrX+Hf2KrPGGRpzy5RzBbYWt7k8Ec27tnbCcndT9ZnrDtudq8/tSCoj+mK0ykjl73M az7PuVtaJ6bs+nxLd+xjRo5jEsWXDN49Xyu47nSKlkges/+XeX/UFePTlFiKMxINtZiLihMB uuSs414CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUi2FCcrDtpoWWYweabZhZde24wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/uzWywFx94wVqz7tJapgXHtScYuRk4OCQETiYY1R5khbDGJ C/fWs3UxcnEICfQzSXTebmOCcPqYJB4e2QpUxcEhLCAhsXlPIkgDm4CKxPFvG8CamQWSJHpu 7WAFsXkFbCT2X/jJBlLOK6AnsfZ4JUhYWMBI4uzaI2AlLAKqEg+2TWSEGH+FSeLWkg/sIAkR gVSJySfOsoDYnALWEqe3P4c6VFais+su4wRG/llI1s1CWAER1pZYtvA1M4RtIPG08xUrpri+ xJt3c5gWMLKtYhQoSs1JrDTTSywoyEnVS87P3cQIDtXCqB2MDcutDjEKcDAq8fA2/LcIE2JN LCuuzD3EKMHBrCTCW+lnGSbEm5JYWZValB9fVJqTWnyIcSIj0GcTmaVEk/OBkZRXEm9oYmJg YmxsZmxsbmJOS2Elcd7SreZhQgLpiSWp2ampBalFMEcxcXBKNTBaSU3RuvBmQSxzy5OiFE+f yDwW9cWsPhWmczztZTyOiNb7bPzdxZZnVRd4obbLbp9PzOkpzLP5Ju4/fHeK3Q4W//bTZXO8 VxoJfby3wN/A7Ei1+IVN69bPcX+p6yS/7dryvJNFVkt7GYQOFC9cWacgOXmpZ6LlzeXnmcXE Pvyfx/0+KzXHvlaJpTgj0VCLuag4EQCutLVDyAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/V-mdUWBfYFRskCt8Izx-ONILRCA>
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 06:11:35 -0000
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 <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 <jouni.nospam@gmail.com <mailto: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> >>>> <mailto: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 <mailto: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>> >>>>>>>> <mailto: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/ <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>><mailto:mif@ietf.org <mailto:mif@ietf.org>><mailto:mif@ietf.org <mailto:mif@ietf.org>> >>>>>>>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mif mailing list >>>>>>> mif@ietf.org <mailto:mif@ietf.org> <mailto:mif@ietf.org <mailto:mif@ietf.org>><mailto:mif@ietf.org <mailto:mif@ietf.org>> >>>>>>> https://www.ietf.org/mailman/listinfo/mif <https://www.ietf.org/mailman/listinfo/mif> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif
- [mif] WGLC for draft-ietf-mif-mpvd-id Hui Deng
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Ian Farrer
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Jouni Korhonen
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Ian Farrer
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Jouni Korhonen
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Ian Farrer
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Jouni Korhonen
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Ian Farrer
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Ian Farrer
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Steven Barth
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Tommy Pauly
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Lorenzo Colitti
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Jouni
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Tommy Pauly
- Re: [mif] WGLC for draft-ietf-mif-mpvd-id Markus Stenberg