From nobody Mon Aug 3 10:31:19 2015 Return-Path: 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 204711B2D30; Mon, 3 Aug 2015 10:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZA_80eNTkN9A; Mon, 3 Aug 2015 10:31:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E51B2D31; Mon, 3 Aug 2015 10:31:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150803173112.7745.39066.idtracker@ietfa.amsl.com> Date: Mon, 03 Aug 2015 10:31:12 -0700 Archived-At: Cc: brian@innovationslab.net, mif@ietf.org, margaretw42@gmail.com, denghui02@hotmail.com, ipr-announce@ietf.org Subject: [mif] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:31:16 -0000 Dear Jouni Korhonen, Suresh Krishnan, Shwetha Bhandari: An IPR disclosure that pertains to your Internet-Draft entitled "Support for multiple provisioning domains in DHCPv6" (draft-ietf-mif-mpvd-dhcp-support) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2648/). The title of the IPR disclosure is " Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mif-mpvd-dhcp-support" Thank you IETF Secretariat From nobody Wed Aug 5 18:24:08 2015 Return-Path: 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 546421B35BF for ; Wed, 5 Aug 2015 18:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 neHS2oLB3wSs for ; Wed, 5 Aug 2015 18:24:03 -0700 (PDT) Received: from COL004-OMC2S7.hotmail.com (col004-omc2s7.hotmail.com [65.55.34.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8C81B35BA for ; Wed, 5 Aug 2015 18:24:00 -0700 (PDT) Received: from COL125-W1 ([65.55.34.73]) by COL004-OMC2S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 5 Aug 2015 18:23:59 -0700 X-TMN: [RJHSAQtF35xjDmTywHgk8mA9OcpyYslMscf0DZdtXOM=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_3684cd5c-362d-4d76-bd6d-b19f183282d6_" From: Hui Deng To: "mif@ietf.org" Date: Thu, 6 Aug 2015 09:23:59 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2015 01:23:59.0607 (UTC) FILETIME=[92344070:01D0CFE6] Archived-At: Subject: [mif] MIF 93th minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 01:24:05 -0000 --_3684cd5c-362d-4d76-bd6d-b19f183282d6_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpCZWxvdyBpcyBvdXIgbWVldGluZyBtaW51dGVzLCBmZWVsIGZyZWUgdG8g bGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gZG8gYW55IGNvcnJlY3Rpb24uDQpodHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9taW51dGVzL21pbnV0ZXMtOTMtbWlmDQogDQpNYW55 IHRoYW5rcyB0byBJYW4gRmFycmVyJ3Mga2luZGx5IGhlbHAgdG8gdGFrZSB0aGUgbWVldGluZyBt aW51dGVzDQpBcHByZWNpYXRlIERhdmUgVGhhbGVyJ3MgaGVscCBmb3IgamFiYmVyIHNjcmliZS4N CiANCkJlc3QgcmVnYXJkcywNCiANCkRFTkcgSHVpDQogCQkgCSAgIAkJICA= --_3684cd5c-362d-4d76-bd6d-b19f183282d6_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5CZWxvdyZuYnNw O2lzIG91ciBtZWV0aW5nIG1pbnV0ZXMsIGZlZWwgZnJlZSB0byBsZXQgdXMga25vdyBpZiB5b3Ug d2FudCB0byBkbyZuYnNwO2FueSBjb3JyZWN0aW9uLjxCUj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85My9taW51dGVzL21pbnV0ZXMtOTMtbWlmIj5odHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85My9taW51dGVzL21pbnV0ZXMtOTMtbWlmPC9hPjxCUj4m bmJzcDs8QlI+TWFueSB0aGFua3MgdG8mbmJzcDtJYW4gRmFycmVyJ3Mga2luZGx5IGhlbHAgdG8g dGFrZSB0aGUgbWVldGluZyBtaW51dGVzPEJSPkFwcHJlY2lhdGUmbmJzcDtEYXZlIFRoYWxlcidz IGhlbHAgZm9yIGphYmJlciBzY3JpYmUuPEJSPiZuYnNwOzxCUj5CZXN0IHJlZ2FyZHMsPEJSPiZu YnNwOzxCUj5ERU5HIEh1aTxCUj4gCQkgCSAgIAkJICA8L2Rpdj48L2JvZHk+DQo8L2h0bWw+ --_3684cd5c-362d-4d76-bd6d-b19f183282d6_-- From nobody Wed Aug 5 21:15:44 2015 Return-Path: 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 B9ED61B38B8 for ; Wed, 5 Aug 2015 21:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 S96iZ8m-EWIU for ; Wed, 5 Aug 2015 21:15:42 -0700 (PDT) Received: from COL004-OMC2S11.hotmail.com (col004-omc2s11.hotmail.com [65.55.34.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434DB1B38B6 for ; Wed, 5 Aug 2015 21:15:42 -0700 (PDT) Received: from COL125-W52 ([65.55.34.71]) by COL004-OMC2S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 5 Aug 2015 21:15:41 -0700 X-TMN: [nacFFmahyBfhpQ53GA6QTJqd7xnm89tW6Ks0fADvfHc=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_4b556374-1bbc-435f-b094-6b2689a019a1_" From: Hui Deng To: "mif@ietf.org" Date: Thu, 6 Aug 2015 12:15:41 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Aug 2015 04:15:41.0875 (UTC) FILETIME=[8ED59830:01D0CFFE] Archived-At: Subject: [mif] End of WGLC X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 04:15:43 -0000 --_4b556374-1bbc-435f-b094-6b2689a019a1_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KIA0KV2UgaGF2ZSBlbmQgb2YgV0dMQyBmb3IgdGhyZWUgZG9jdW1lbnRzIHRv ZGF5LCB3aWxsIHNlZSB3aGV0aGVyIHdlIG5lZWQgMm5kIFdHTEMgYWZ0ZXIgc29sdmVpbmcgYWxs IGlzc3VlcyANCiANCnRoYW5rcyBhIGxvdA0KIA0KREVORyBIdWkNCiAJCSAJICAgCQkgIA== --_4b556374-1bbc-435f-b094-6b2689a019a1_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsLDxCUj4mbmJzcDs8QlI+V2UgaGF2ZSBl bmQgb2YgV0dMQyBmb3IgdGhyZWUgZG9jdW1lbnRzJm5ic3A7dG9kYXksIHdpbGwgc2VlIHdoZXRo ZXIgd2UgbmVlZCAybmQgV0dMQyZuYnNwO2FmdGVyIHNvbHZlaW5nIGFsbCBpc3N1ZXMgPEJSPiZu YnNwOzxCUj50aGFua3MgYSBsb3Q8QlI+Jm5ic3A7PEJSPkRFTkcgSHVpPEJSPiAJCSAJICAgCQkg IDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_4b556374-1bbc-435f-b094-6b2689a019a1_-- From nobody Wed Aug 5 23:41:04 2015 Return-Path: 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 0DF6E1A1B69 for ; Wed, 5 Aug 2015 23:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=no 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 RjacRrav1Knh for ; Wed, 5 Aug 2015 23:41:00 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAC31A1B7B for ; Wed, 5 Aug 2015 23:41:00 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZNErJ-0004ud-UN with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for mif@ietf.org; Thu, 06 Aug 2015 08:40:58 +0200 To: mif@ietf.org References: <20150803173112.7745.39066.idtracker@ietfa.amsl.com> From: Steven Barth Message-ID: <55C30178.8080309@openwrt.org> Date: Thu, 6 Aug 2015 08:40:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150803173112.7745.39066.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mif-mpvd-dhcp-support X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 06:41:02 -0000 Am 03.08.2015 um 19:31 schrieb IETF Secretariat: > An IPR disclosure that pertains to your Internet-Draft entitled "Support > for multiple provisioning domains in DHCPv6" > (draft-ietf-mif-mpvd-dhcp-support) was submitted to the IETF Secretariat on and > has been posted on the "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2648/). Naive question: the IPR says "Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee" doesn't that practically mean that this cannot be implemented or shipped within anything open source, say ISC's clients / servers or in general a lot of host, server & CPE DHCP implementations? Cheers, Steven From nobody Thu Aug 6 02:06:03 2015 Return-Path: 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 BE6F81B2A7C for ; Thu, 6 Aug 2015 02:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 UsTcvU2loop2 for ; Thu, 6 Aug 2015 02:06:02 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63851B2A4A for ; Thu, 6 Aug 2015 02:06:01 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so13692457wic.1 for ; Thu, 06 Aug 2015 02:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=N2spLDQ824xkxoRdahgt7+72HIJZlq5h5Ais5UvQtsQ=; b=NZK0i/nOJCW06aYEbnYax3ZO4a+lM9CtXmYGMur42vpW4KdpzV5l3jiwsZkGsNLHXJ by0d3tXyDcFpUtigzlN+gJBu3vDuWiVExdCAQiLrCmh3KmExkXnzgaCyueyDMa9ZYzge YqI9B86BSZSYbmDmE2rAKdp+4ZshzxDIV8GCHzxEZ9F2KVFJ0/SlbrltdXHb55CERU5E 6Bb/ML7nw/AD6zPYGz2RLvFd/jq9gTcP7tArxA5ZeVqbhgwxG4EqxLy4pk18eLLD08wT 7Nlp7wv47Ez3LKI40jSY8ROkk8s/B61ndj1IaCmzp6KmfxBLBfpuz4CaACaQHxWipKIS fwrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=N2spLDQ824xkxoRdahgt7+72HIJZlq5h5Ais5UvQtsQ=; b=O+i91o3HElS7Zdgk22lLAqTdoz8GBujlbqZYfpGOwAXCFjCRMGzDsnH3Us7gPD0Ofk wG+gCGiXD5v6v5yjFglgAYLWdBy3vnhYtZvGqLVQKiI6UrLyKt784bJNBQeGywgzCZJX 82QXtLKRHpCKfrckPcdZ4Yoh/YmTW2LI1VNZhJuA1bAJ3ZPtH67WWt6AvPGfyjyCvqIx BM30M/hasHurqpSAsmdZqjmY0DQ7TnhOhE+uUDujGDFsUcr4Hqn31ED7vLC6flXKekuA kDTZMCI1SFkuO4nrQ96o4e8uDV1EnRvGsghlFViWIHopXUUQTVcF9NG6a+YT80p8Shpn c9hA== X-Gm-Message-State: ALoCoQlM8rG8wrrMf9cVgRwlsIxmjumB+dYxgxsziPV7z8Bu1wigxOXq1z4WX61mLxed5yuQ4g5m X-Received: by 10.194.187.40 with SMTP id fp8mr1321679wjc.34.1438851960561; Thu, 06 Aug 2015 02:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Thu, 6 Aug 2015 02:05:40 -0700 (PDT) From: Erik Kline Date: Thu, 6 Aug 2015 18:05:40 +0900 Message-ID: To: "mif@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [mif] draft-ietf-mif-mpvd-id-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:06:02 -0000 I have no real objection to this document. One clarification that is probably important is what the FQDN format means: [1] "pvd.example.com", "xn--idnbits.cc.tld", ... or [2] "\03pvd\07example\03com\00" (RFC 1035 section 3.1 style) or something else (I'm sure the DNS folks have some proper terminology somewhere). --- [ nits ] - section 3, paragraph 1: s/The used configuration protocol/The configuration protocol used/ ? From nobody Thu Aug 6 03:26:16 2015 Return-Path: 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 17FF51B2C30 for ; Thu, 6 Aug 2015 03:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 4lVfPAk6aLpT for ; Thu, 6 Aug 2015 03:26:14 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143231B2C2F for ; Thu, 6 Aug 2015 03:26:14 -0700 (PDT) Received: by wijp15 with SMTP id p15so16577503wij.0 for ; Thu, 06 Aug 2015 03:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=nwELNt9shz3foE3SndulZ++owZ163C/aw3y0dPlBLHk=; b=jfuoASDpUmE1IXbyWIT36Bsq6OEHdchZIraHa3+EU/w+iXcqx2UDQ92h7g+PIHze9+ hI+Pq4FVtd+1BSk8JORgm9EicHewvMgu+Z5YU0sHWr4GPav7ocILxY7Jt+h7w6NOGof6 /pXgLH2EQTzTTU+HTWXbvSiqiQ8j87y3IPEMhEDZBpia+5g6qlFoW1E7S8NSsNCPKUq7 gN/F0suC+elAJkDKnIsjc5E4Nii39/ST6+xLBsH5MSJ9CRMkM6oI9aXNm9K4g2wo5zT5 5FQRgWQyj0T0axtwm3GllgxBu/a82ybI7vdQyJBqLGWqP3+rZCpdEHP1IBpLnDS3JVTV ALGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=nwELNt9shz3foE3SndulZ++owZ163C/aw3y0dPlBLHk=; b=es+xvQrIWCOeAnxYj9wjqrVGOzq/Z5kSOZAUwJrqMtozCNH/sUOZ0/T5tRSHyY2Z0t 6C5mgSfClyKWu9IMYL6sySUiap8r8t22tEThDkvxw2v2X1VSEkvAyhMA+Hkl5M6/F1YB jE/esYsFzXPK/xYvrJ8pZJhSCc1eor+32YNk6tiMzj+igobKM1GgdPNDw3lc5I5i+nXv BzRTjS9CmUzeA59fV4bX/cKTS7upYPpGfB27jz+Gi2j+vbZScX6GwARHz4t3TFsf0aOt G94kQGfqj3jzz2iJO9vI4m7xG72b2B4nv/esWSS9S0IX6A0v5/YthZ4cTd1BMVCcIJxD JSqQ== X-Gm-Message-State: ALoCoQnTqUp4JxCGhwCpEZDOsMD1PVyn+4456LuzmbbAJD0A7v6PBDS0cetaZT6SogDap/4MnE87 X-Received: by 10.194.187.40 with SMTP id fp8mr1923233wjc.34.1438856772809; Thu, 06 Aug 2015 03:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Thu, 6 Aug 2015 03:25:53 -0700 (PDT) From: Erik Kline Date: Thu, 6 Aug 2015 19:25:53 +0900 Message-ID: To: "mif@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [mif] draft-ietf-mif-mpvd-ndp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:26:15 -0000 Mostly LGTM. I am slightly worried about the size of RAs, as I really don't think they should be permitted to be fragmented and it's nice if they're kept under 1280, but that's probably just unjustified paranoia on my part. From nobody Mon Aug 10 07:04:09 2015 Return-Path: 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 82E991B35B2 for ; Mon, 10 Aug 2015 07:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 F57iTEsbTBJw for ; Mon, 10 Aug 2015 07:04:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00A61B35B6 for ; Mon, 10 Aug 2015 07:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3085; q=dns/txt; s=iport; t=1439215447; x=1440425047; h=from:to:subject:date:message-id:references:mime-version; bh=4t2hPmYsufM9VN3Cs6GB+GVRqymYzJq047fua6rmFJk=; b=UmP7Chjs4mkzzLgaK3G1kkSfPmfPFDDPu/sbn368e0fDb6rVaMslvB6p F0ciMO9GdznnpAAjRRyncA+QTfFL+sewVFwBKePOTACDmpRkyCMQOYFjS V0NtuvMo9ClJV963IOx7ql1ohm7Xdod3u/mcgVXtaC8YeabOXl+R0gPwj U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlAwD0rshV/5pdJa1dgxtUaQa9MAmBegqFeQKBLjgUAQEBAQEBAX8LhCMBAQEDAQEBAWsQCwIBGQMBAi8nCxQHAggCBBMJBYgYCA3PBAEBAQEBAQEBAgEBAQEBAQEBARmLUYR4EwuCKE0dgRQFlQsBgjyBXGmHYYFJRoNfjGaHKSaDfXEBgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,645,1432598400"; d="asc'?scan'208";a="177145177" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 10 Aug 2015 14:03:49 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t7AE3nKn022120 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Aug 2015 14:03:49 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 10 Aug 2015 09:03:48 -0500 Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 10 Aug 2015 09:03:48 -0500 Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 09:03:47 -0500 From: "Fred Baker (fred)" To: "mif@ietf.org" Thread-Topic: I-D Action: draft-baker-6man-multi-homed-host-00.txt Thread-Index: AQHQ0R8TtalPea2GBkaP/zHTUd5sMA== Date: Mon, 10 Aug 2015 14:03:47 +0000 Message-ID: <01A096FF-9E7E-406E-BE2E-14EDB99A2D2D@cisco.com> References: <20150807144043.10132.18362.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.30] Content-Type: multipart/signed; boundary="Apple-Mail=_CF55B624-43AF-4D9F-A3CC-6264FD0D9BF0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [mif] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 14:04:08 -0000 --Apple-Mail=_CF55B624-43AF-4D9F-A3CC-6264FD0D9BF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is actually being discussed in 6man, as the chairs requested it = there, but MIF might have comments to pass along. > Begin forwarded message: >=20 > From: > Subject: I-D Action: draft-baker-6man-multi-homed-host-00.txt > Date: August 7, 2015 at 7:40:43 AM PDT > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Host routing in a multi-prefix network > Authors : Fred Baker > Brian Carpenter > Filename : draft-baker-6man-multi-homed-host-00.txt > Pages : 6 > Date : 2015-08-07 >=20 > Abstract: > This note describes expected host behavior in a network that has = more > than one prefix, each allocated by an upstream network that > implements BCP 38 filtering. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_CF55B624-43AF-4D9F-A3CC-6264FD0D9BF0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVcivQkayAOS/EQ8MAQLOMA//RYGW/LW+CPgXbsKiXRP3jvSVIzqdCGO5 VhyzJT1phB5dM9byhfWUS6PYQkF2pE1+tSqVrfXNRX9ltpDGbWEjibjpJxby6NKJ HTB+aQ2O7HaJfFQybjuIMLizVs0+NLyN0h5hDBCaTz3l+zmjErpHz6OGwJZZboZz ccyvFFAKoA4SPjZab6n1yAVW+U0a0h8feZ+yO6JyZPrE68+6LHMdnhGoR9lVEy9q XW/aacaI0ttLlVOSNwwcUlCNDdzCI3XUOHN9F5GJ2LlXbORGDU/1hqgS4IaZGkRm XIRhs+6Rrayu5ouO5mWwCsqLLk9auFiLHzqaISRkor7IkbRgNGUT86Nrw70coGS9 hYPWVlbT012PjB1aUN0tFd9gqxoXxVy1/yKLjLJZh5QK8RYNA3rEyXnOJfrohfm+ b6VZkVhJXclmo9oGqsRhlP6iHHXbpHU0EvBp+YHToyKgWamqUdsNLgLO+VX6f0sL F21b7sYWbmRVvt3M893f4F99kPKz/M+9teDaI9ACvvmgkP8hdxg+OWrJ4Y1b13i0 tKL+9fm+5OKW8vk1/EK1BfbauQC6sRzzfnU1FSrM947LnrEadrhixcLg9sWMrF1X MWlpgJ0Ey+uzacs++N2LlA+uerocZncu7/fT4/Ux/y9N9Dj8qdhKNOe6MIpUY8t1 S65+t+2rm/I= =plrX -----END PGP SIGNATURE----- --Apple-Mail=_CF55B624-43AF-4D9F-A3CC-6264FD0D9BF0-- From nobody Tue Aug 18 00:54:01 2015 Return-Path: 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 BED441B2B20; Sun, 16 Aug 2015 21:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.302 X-Spam-Level: **** X-Spam-Status: No, score=4.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IXHASH_X3=3.5, MIME_QP_LONG_LINE=0.001] autolearn=no 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 0Bgn5URFflct; Sun, 16 Aug 2015 21:04:52 -0700 (PDT) Received: from mta2b.krios.info (mta2b.krios.info [78.155.25.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48AE1B2B24; Sun, 16 Aug 2015 21:04:39 -0700 (PDT) Received: from ([116.102.235.180]) by mta2b.krios.info (IceWarp 10.4.5) with ASMTP (SSL) id 201508170604340849; Mon, 17 Aug 2015 06:04:34 +0200 From: Meetecho Team To: Jamal , Jana Iyengar , Jeremy , Joe Milton , Joern Krebs , John Menard , John Pansewicz , Jonathan Lennox , jose , jose-chairs , King Daniel , kyotoclub-support , Lavori Pubblici - Comune di Bruino , Lee Atkinson , lime , Linlin Zhou , lisp , llorenzin , Lorenzin Lisa , Lorenzo Miniero , Luigi Tanghetti , LUIS MIGUEL CONTRERAS MURILLO , luismiguel.contrerasmurillo , Maddy Conner , Marc Blanchet , Mark Arik , Mark Watson , Mary Washburn , Meetecho IETF support , Melinda Shore , Michael Picher , Michal Suchon , mif , MiguelAngel.ReinaOrtega , mile , mile-chairs Date: Mon, 17 Aug 2015 06:03:50 +0200 Message-ID: <6dcb29111ca5ee5e.662459421ffd6b@meetecho.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_64b5_4198_166f" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDdK0GIiEFV46NTTBIZLz4vOGfuNg== Content-Language: en-us Archived-At: X-Mailman-Approved-At: Tue, 18 Aug 2015 00:54:00 -0700 Subject: [mif] Fw: try it out X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 04:04:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_64b5_4198_166f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey! Have you already seen it? http://kralovnaeliska.cz/honest.php?ad3 Meetecho Team ------=_NextPart_000_64b5_4198_166f Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey!

 

Have = you already seen it? http://kralovnaeliska.cz/honest.php?84

 

Meetecho Team

 

 

 

------=_NextPart_000_64b5_4198_166f-- From nobody Tue Aug 18 00:54:03 2015 Return-Path: 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 0298C1B30CC; Mon, 17 Aug 2015 19:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.637 X-Spam-Level: *** X-Spam-Status: No, score=3.637 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, IXHASH_X2=2.5, MIME_QP_LONG_LINE=0.001, TVD_SPACE_RATIO=0.001] autolearn=no 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 qb86padR9d2R; Mon, 17 Aug 2015 19:14:30 -0700 (PDT) Received: from server.servidordatum.com (server.servidordatum.com [67.23.245.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918051B30CA; Mon, 17 Aug 2015 19:14:30 -0700 (PDT) Received: from [175.142.12.241] (port=50800 helo=WORLDST-UQ3K9Q0) by server.servidordatum.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZRWPl-003g4b-0a; Mon, 17 Aug 2015 21:14:13 -0500 From: Meetecho Team To: Melinda Shore , Michael Picher , Michal Suchon , mif , MiguelAngel.ReinaOrtega , mile , mile-chairs , Mirtill Mlinarik , mmusic , modern , mptcp , netmod , netvc , nfsv4 , nicoleta munteanu , ntp , ops-area , opsec , opsec-chairs , opsec-chairs , Patrick Mourot , paws , paws-chairs , payload , perc , Roland Burger , roll , Roni Even , rtcweb , rtcweb-chairs , rtgwg , rtgwg-chairs , Sabrina Petricci , sacm , sacm-chairs , Sandra Scott-Hayward , Sara Leggio , Scheffenegger Richard , sdnrg , Seil Jeon , Simon Pietro Romano , siprec , siprec-chairs , softwire , splices-chairs , spring , stir , sunset4 , support , support@meetecho.com , Susan Hares , Date: Tue, 18 Aug 2015 04:13:21 +0200 Message-ID: <1efaf524c4f83a6d.61658c25@meetecho.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_dd61_8a99_70c7" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDftJ6U0fr+CJZtv/YCiA+okLuWwA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.servidordatum.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - meetecho.com X-Get-Message-Sender-Via: server.servidordatum.com: authenticated_id: info@ikrea.com.mx Archived-At: X-Mailman-Approved-At: Tue, 18 Aug 2015 00:54:00 -0700 Subject: [mif] Fw: important X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 02:14:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_dd61_8a99_70c7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello! Important message, visit http://allmath.ru/smile.php?x14hc Meetecho Team ------=_NextPart_000_dd61_8a99_70c7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello!

 

Important = message, visit http://allmath.ru/smile.php

 

Meetecho Team

 

 

 

------=_NextPart_000_dd61_8a99_70c7-- From nobody Tue Aug 18 09:25:20 2015 Return-Path: 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 555661A894A for ; Tue, 18 Aug 2015 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 TySP8u3UfqqL for ; Tue, 18 Aug 2015 09:25:17 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC51A1A8951 for ; Tue, 18 Aug 2015 09:25:16 -0700 (PDT) Received: by pawq9 with SMTP id q9so38876644paw.3 for ; Tue, 18 Aug 2015 09:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=2xGlA23ghsgECDvgoesaSXelnCWnaq9/MEv6otWZGVw=; b=uJOmzqLOl8gebuhfV9SrAOGc8G7NabUKoNFINdNk8exK+flWG9bRtAEZ5rNZjGoPmj rESjf0COOKr1f8HhK8gIkteUpgxcUSH9lQKyAf30B7i7uxICtTGW+Itt/pdYCIJxul00 9PohB7t96sSjam/BuPrzvH0rC/3QBOKbf21q41oJmrFRMAam1ucxHdhFPUJaNllrv0oY BXg9Dh2/YTYd7KlE2zbx8k6AIgDMps+VNwUImGIBWHFts54vzFQEWnNd4VXHGdpHNe1q C2VrffaXbVL5U6Ulqn6RnXwqpsjO+idBSoKaU37DulmUQBi5WzDwt858juKifECn3ZEr v0jA== X-Received: by 10.68.68.175 with SMTP id x15mr15053008pbt.10.1439915116611; Tue, 18 Aug 2015 09:25:16 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:d5a2:2855:8297:4b1c? ([2601:647:4204:228b:d5a2:2855:8297:4b1c]) by smtp.googlemail.com with ESMTPSA id fm3sm18659514pdb.49.2015.08.18.09.25.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2015 09:25:15 -0700 (PDT) To: Erik Kline , "mif@ietf.org" References: From: Jouni Korhonen Message-ID: <55D35C6A.4030408@gmail.com> Date: Tue, 18 Aug 2015 09:25:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mif] draft-ietf-mif-mpvd-ndp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 16:25:19 -0000 Erik, As it it was pointed out earlier in the mailing list the fragmentation text today is a bit stale. RFC6980 forbids fragmentation header in ND messages so the fragmentation part of the text will go away.. Unfortunately the size considerations still remain. The best we could do is in case of multiple PVDs to disctribute the information to multiple RAs. - Jouni 8/6/2015, 3:25 AM, Erik Kline kirjoitti: > Mostly LGTM. > > I am slightly worried about the size of RAs, as I really don't think > they should be permitted to be fragmented and it's nice if they're > kept under 1280, but that's probably just unjustified paranoia on my > part. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Tue Aug 18 11:14:00 2015 Return-Path: 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 887651A904F for ; Tue, 18 Aug 2015 11:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] 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 ik_SEnEmFtk9 for ; Tue, 18 Aug 2015 11:13:57 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E5F1A9051 for ; Tue, 18 Aug 2015 11:13:56 -0700 (PDT) Received: by pabyb7 with SMTP id yb7so137889662pab.0 for ; Tue, 18 Aug 2015 11:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=hdu8yOAHY7m25LJ3xalZzW039hX9Uh2uzhDhEoWw7j8=; b=HaOzLqdh18a0XvZUKaSJqCMe/Roi6CLtFNXTrnhvI1ylOevZi17C3JcD2xKxebp+uM iyrHnPLwozkwxzUd+Meetb2Wt9CeSVb9cjZ7TJNuxT581F6zLS/utXzp/pX5DP5iPq/U u+pe/OeFJF9CpRlBW/DZ+yWYd8tBcCITWLjJ1rRVQb+fFaMkP/vVfXIKiQCr4KNoeI3H 1VAEVEKH/bWIMe3nMTOmQYQg7ykC98nBVTqY3skIHcOzSirw/K1HknHnuueXD7+FQt7Z pLTCymsbh4xOUtGLy7zOEdcYAf9LPQhfypb/IzXKdAWKobzdJF0XZijEXiVuwNkEMmlz vbbA== X-Received: by 10.66.141.141 with SMTP id ro13mr16105863pab.68.1439921635895; Tue, 18 Aug 2015 11:13:55 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:d5a2:2855:8297:4b1c? ([2601:647:4204:228b:d5a2:2855:8297:4b1c]) by smtp.googlemail.com with ESMTPSA id ay10sm18822657pbd.13.2015.08.18.11.13.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Aug 2015 11:13:54 -0700 (PDT) To: Ian Farrer , mif@ietf.org References: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> From: Jouni Korhonen Message-ID: <55D375E1.6050707@gmail.com> Date: Tue, 18 Aug 2015 11:13:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mif] Review of draft-ietf-mif-mpvd-ndp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 18:13:59 -0000 Ian, Thanks for a detailed review! See my initial comments inline. 7/25/2015, 5:46 AM, Ian Farrer kirjoitti: > Hi, > > Here’s my review of the draft. > > Cheers, > Ian > > Please note - I’m going to be on holiday for the next couple of weeks so if I am slow in responding to any replies, then this is why. Same here.. back now ;-) > > ----------- > > These comments are in addition to the one that I have raised in the mail thread https://mailarchive.ietf.org/arch/msg/mif/3LQ6W1kj7nwOIvI_KGfbKoyOkCs > Depending on the outcome of this discussion, other changes to this document may be necessary. > > > Section 3 > > a) Which NDP messages can include this option? RA and RS messages are mentioned, but is it envisaged > that e.g. a host may make an NS request which contains the PVD_ID option, in order to > find other hosts which are configured for the same PVD? My feeling is that in this document > and at this stage of the development, they should be restricted to RS with requested PvDs > and RAs with advertised PvD NDP messages only. RA and RS are what were in my mind.. I will clarify this and limit the PDVs to RA/RS only. > > > b) I’m not clear on what the intended solicitation process for a host requesting information for a specific PvD. > The behaviour seems to be that in an RA, a client includes a list of the PVD_ID options which it is interested in receiving. You probably mean RS not RA? One of the ideas was to allow "clever" unicast RA type of PVD information delivery.. i.e. the router would typically advertise just the normal stuff that would go under implicit PVD. Once some end host solicits for a specific PVD or PVDs that information could be unicasted to that specific end host. > > But, para 2 of section 3 says that the RA can also include the PVD_CO. What is this for? Do the requested > PVD_IDs need to be in a container, or are they listed directly in the RS options (or are both allowed)? s/RA/RS If the solicitator wants to sign the PVD-ID it solicits for then the container is needed. > > c) Para 2 > The PVD container MUST NOT be fragmented" > RFC6980 prevents NDP messages from being fragmented at all, so perhaps this should be > referenced? > Would it also help to describe how to correctly handle this situation (i.e. send two RAs with > un-fragmented PvD containers) Fragmentation part is outdated and has to be done according to RFC6980. > > > Section 5 > "The PVD container option MAY be used to encapsulate any allocated IPv6 NDP options, which may appear more than once in a NDP message." > > Ambiguous text - Is the intention to say that the PVD container, or the encapsulated options may appear more than once in the NDP message? > If it is the encapsulated options, then the sentence restricts the allowable options to only those options which can appear more than once > (i.e. an option which can only appear once can not be encapsulated). I guess that this is not the intention. I'll revise the text. Did you check Appendix A.1? It shows what is meant with this. For example, it is OK one RA to contain PIOs inside and outside the container. Also, if the RA has multiple containers same NDP options (like PIO) can be used in every of those. > > Section 6 > Per PVD certificates/sigs sound like they are going to cause problems with the NDP message length. > In the appendix of RFC6980, there’s some information about message sizes when carrying > certificates. 864 bytes is given as the smallest size for the certificate itself (1024 bytes), so for a 1280 v6 MTU, > 2 and you’re bust. There is no need to carry certificates around. The key hash in the container is there for to purpose of locating a proper public key for verification. How you learn the public key / certificate is outside this specification. > > > > Language / grammar nits etc. > > Throughout: s/a NDP/an NDP > Reason: With acronyms, ‘a’ or ‘an’ before a consonant/vowel is chosen based on the sound of the letter when spoken (i.e. ’n’ is pronounced ‘en’) Ack. > > Section 1 > Old > This document describes an IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] mechanism for explicitly indicating > provisioning domain information along with any configuration that will be provided. > > New > This document describes an IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] mechanism for explicitly indicating > provisioning domain information along with any configuration which is associated with that provisioning domain. > > Reason: new wording more clearly associates the configuration with the PVD it is being provisioned for. Ack. > > Section 3 > Old: > Implementations that do not recognize the PVD container option plain ignore it and also skip PVD container > option "encapsulated" NDP options normally without associating them into any provisioning domain (since the > implementation has no notion of provisioning domains). > > New: > Implementations that do not recognize the PVD container option will ignore it, and any PVD container > option "encapsulated" NDP options without associating them into any provisioning domain (since the > implementation has no notion of provisioning domains). > > Reason: Old version reads a little ‘colloquially’ :-) Ack. > > Old: > certificates needed to sign PVD containers) belong > > New: > > certificates needed to sign PVD containers belong > > Reason: ) with no corresponding ( Ack. > > > Old: > the length of the PVD identifier option and the optional Key Hash/Digital Signature/Padding. > > New: > the length of the PVD identifier option, and the optional Key Hash/Digital Signature/Padding. > > Reason: Oxford comma. Might as well put it in now and save the editor the job. Ack ;-) > > Section 4 > Old: … the natural NDP options’ alignment. > > New: ... the natural NDP option’s alignment. > > Reason: Option is singular and doesn’t end with an ’s' Ack. > > Section 5 > Old: > If the receiver of the PVD identity option does not understand any of the ID-Types, > then anything belonging to this provisioning domain MUST be silently discarded. > This would mean the PVD identity option, the PVD container option and all other options. > > New: > If the receiver of a PVD identity option does not have one (or more) of the received > ID-Type format’s implemented, then all configuration and options which are associated with > the unimplemented PvD(s) MUST be silently discarded. > > Reason: Original wording could be mis-interpreted to mean that the entire NDP message, including > options associated with implemented ID-types must be discarded Ack. > > > Section 7 > Old: The options TBD1 and TBD2 are described in Section 3 and Section 4 > > New: Options TBD1 and TBD2 are described in Section 3 and Section 4 respectively. > > Reason: Clarity Ack. Thanks a lot, Jouni > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Wed Aug 19 01:20:46 2015 Return-Path: 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 2D7A41ACCE9 for ; Wed, 19 Aug 2015 01:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 SqdMwGhODFRM for ; Wed, 19 Aug 2015 01:20:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4DA1ACF17 for ; Wed, 19 Aug 2015 01:20:43 -0700 (PDT) Received: from ians-mbp.lan ([62.225.30.139]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MUpI8-1ZFsiC4BlE-00Y9Or; Wed, 19 Aug 2015 10:20:41 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_92B0A4CF-4F8B-44D4-B478-127B8F95A465" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Farrer In-Reply-To: <55D375E1.6050707@gmail.com> Date: Wed, 19 Aug 2015 10:20:40 +0200 Message-Id: <9DBCF0B3-3CA8-4C19-BF56-0A610F4801C7@gmx.com> References: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> <55D375E1.6050707@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:oEzJImrTQAoR6SWNW12qjC2SSIe+k33bkWaGdi/DVkjBqnj3kcL yQxYClkgYITyjIsHOQKN7eSwhSbqga8J6bKNoFj9AOz2my/skgOecfynDx7m3q3XxPPv7ws 1v1tt8wJl8AKgsPeCNprivyuMEB66BOy9NJVPXj1049xB19HWMGvhp1Vt/lLc7lFZZr2A++ am4+mIc61XVd9aryDPA/w== X-UI-Out-Filterresults: notjunk:1;V01:K0:lgD+KK72dH8=:eC66uUPpvCh6QjCqr9qJIR lNqevO5jIf08gvDIGB3oObWhqpSEgHi9UHtP/h4LXEKTn2qrNU0sFhkSiWWxAl+A2Ck0zdivj FMToCnBhrIpWHoTet4mG5FektW2yT4gnNqkwgB7XDaVC+6LB8TKw4Qbqk2iTCkfRj5uSt6hqo 0HsBPNXdn6u6mGaPPD8WHsOBJIhhHHQlPwbzaHycgDoMnmWDwrMjBOcPhrgZg453lVPFMZu81 4W3j5YPK2IXMyZ8SMo4Zu2YsCbVf5pt6NyH/nd+lHnpOeRWzXWRgqqVUqfu1jLKSsZKRKUoTs +mkKVBcKoFuTPmecx8sEQfiN6E1SDKKoZE21ZOZVBS2eyQ8b5/vXCpZ315kTuDrM0vYTtqcHn Kh7Ogis1FaNPt6TuMYLdgtJVZJIsfga2Kj8r6x65FCjGVBnTxYAc8EB1fumZ5htzXjCD3RTLN vwJAE5263qe5Xj7DzGN8spampG35S8ipGZ5z/sWR2Z4SkrDkiBrTK8C+qgDIYOUK00tCv5Mtv 07oukd9FAfbzacjQaCW4Cn4iNpvSjT/ia9k5xKA73oqF6fl8r59u4c2LkbMQa9CaNgA/5rzYn g1fp0i7qBo51yq8tySXpTm9KTmpHrUXT1HtpsVSljT054xicDvcNkuEnhwkA/Qrt1st15xWVt +ytW4MLmfTk725YwSTRyD+XPrzaOb/oclRLk6wJCjqjxh20GL1vUCt2crSCsThhwN28mY97gS oSGzufkNgoeI9z+QQ/IiytNR2huncsLTPfKLNQ== Archived-At: Cc: mif@ietf.org Subject: Re: [mif] Review of draft-ietf-mif-mpvd-ndp-support-01 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 08:20:45 -0000 --Apple-Mail=_92B0A4CF-4F8B-44D4-B478-127B8F95A465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jouni, Please see one comment below. Also, on looking through the draft again, in Figure 1, the convention = for DHCP container options is to have an =E2=80=98encapsulated = options=E2=80=99 field, but there isn=E2=80=99t one in the diagram. Is = this intentional? >=20 >>=20 >> But, para 2 of section 3 says that the RA can also include the = PVD_CO. What is this for? Do the requested >> PVD_IDs need to be in a container, or are they listed directly in the = RS options (or are both allowed)? >=20 > s/RA/RS >=20 > If the solicitator wants to sign the PVD-ID it solicits for then the = container is needed. >=20 [if] OK. That=E2=80=99s not clear from the current text. Can you add = text to clarify when the PVD_CO is/isn=E2=80=99t necessary? Actually, a section that describes the PVD RS & RA process might be the = clearest way of pulling this together in one place. Cheers, Ian --Apple-Mail=_92B0A4CF-4F8B-44D4-B478-127B8F95A465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jouni,

Please see = one comment below.

Also, on looking = through the draft again, in Figure 1, the convention for DHCP container = options is to have an =E2=80=98encapsulated options=E2=80=99 field, but = there isn=E2=80=99t one in the diagram. Is this = intentional?




But, = para 2 of section 3 says that the RA can also include the PVD_CO. What = is this for? Do the requested
PVD_IDs need to be in a = container, or are they listed directly in the RS options (or are both = allowed)?

s/RA/RS

If the solicitator wants to sign the PVD-ID it = solicits for then the container is needed.


[if] OK. That=E2=80=99s not clear from the current = text. Can you add text to clarify when the PVD_CO is/isn=E2=80=99t = necessary?

Actually, a section that = describes the PVD RS & RA process might be the clearest way of = pulling this together in one place.

Cheers,
Ian




= --Apple-Mail=_92B0A4CF-4F8B-44D4-B478-127B8F95A465-- From nobody Wed Aug 19 01:21:10 2015 Return-Path: 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 2B8A81ACCE9 for ; Wed, 19 Aug 2015 01:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 Va5VoFNAEgqD for ; Wed, 19 Aug 2015 01:21:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33361ACF5B for ; Wed, 19 Aug 2015 01:21:04 -0700 (PDT) Received: from ians-mbp.lan ([62.225.30.139]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LtZfc-1Yj2za10nE-010sVN; Wed, 19 Aug 2015 10:21:02 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_F3533EDB-77C1-4291-8E57-F75B7036AC9B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ian Farrer In-Reply-To: <352EAA2D-0D69-40F6-8C6B-8980DD780AEA@gmx.com> Date: Wed, 19 Aug 2015 10:21:02 +0200 Message-Id: References: <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: Jouni Korhonen X-Mailer: Apple Mail (2.2102) X-Provags-ID: V03:K0:hNTs8wL8khbYSyQgJzg/MrdRstqdEMfCdlbYyy4S/+qT6ksNXc5 gvpFCdW2AXPU+EEjmAJRTJQZqWcKyamN+eB62KUhuQjEnzN7AAgSQJaxQr/F2s0E3V/S/k/ BGAZVoABgVhLVXlKboOg0TzJUDfuLSHflG29AXnegV3lUtgz/SHg2dST7agcFNib5wjOQZu Ms/jiCo6eSsYraOcw9MHA== X-UI-Out-Filterresults: notjunk:1;V01:K0:i4R3DRePnDQ=:5uY5j8oKAyvLohS5UDQ3sb N07gaFP1D0aWbWKPlGxEg4ZuQqOrNzxH9Y+yi2ZWOeufoshVT9x04oIZHvKHn9VNMtEHUQTp1 U3WrRvDiVn/NRjCxo9foD7+a1mcQtg9jiqyFriYPVsRKTN6NIhAkFl7MYhq6UlDkNLd9OV2BA OBK1NJF+dLil75N0PyI0y/6tFZS3x0UNMsM66raQ6hkLf/BgXuRm9fgTLJDeQVC18YcXtZGR+ jnAvJG3G722NmtEpaUmxR50aYhzEOiFtHdqAIzfg2inM3akPr1/lyeUTGw5yk6dmDkPYpwnbH OgqM5pjTG9qNTCxG2AgRO9dDyteRIUtZrB+ZSsR5ysTz2Y+P6P4/4UibQx4y3pUO4ouc7dftR fsHshmlYNZxg7ExkQj+aR1cOORsAxGrcmf2rVYIPpoWkqtnTYv5sQLsKzOwjoXsWJsX0Tln6u yXKn2un4vUclguomQcKJyjhxl/QtGjUjNXcvBi+fA64eTc00RQYjXKIp/JxlLriz5qjIGtFBn vFfBahrQAcOBe+v/yiOBEMjJmpvzfxl/ROROlXLmgWfU+rNqW3jOX/tbkpi48L/ewKjL2hUAa Pxb78mL4MYePX42JSlscddvDgndXQkTbI2UGgc6fNA7qoLBhCDHhoA4J16b7ScgySy5GrXWIH HkZWgp5iUa/YI2CcSe5ZypyzVSQOuvuplqZhawqyvWoTn/gIzpYmVTKYxZ4j6XaRkUDwSum4s S6l64ec33VwLZ+VuOh5rn6s26eQe1QY1emIJJw== Archived-At: Cc: Hui Deng , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 08:21:08 -0000 --Apple-Mail=_F3533EDB-77C1-4291-8E57-F75B7036AC9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jouni, Did we reach a conclusion on this? Thanks, Ian > On 22 Jul 2015, at 17:21, Ian Farrer wrote: >=20 > Hi Jouni, >=20 > 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=92s a closed system, so it=92s achievable. >=20 > 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=92s 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 =92streamingtv.bigtelco.com = =92). The FQDN format is standard, so = the app without any knowledge of the operator=92s network can interpret = this and offer it to the user as a choice. Once the app is configured, = it=92s 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). >=20 > 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. >=20 > And so on... >=20 > 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=92t 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.=20 >=20 > Cheers, > Ian >=20 >=20 >> On 22 Jul 2015, at 11:28, Jouni Korhonen > wrote: >>=20 >> 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. >>=20 >> - Jouni >>=20 >> 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. >>>=20 >>> 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. >>>=20 >>> However, on thinking about this, maybe defining an additional type = for >>> 'PVD-ID owner binary blob=92 could be an idea if people see a need = for it. >>>=20 >>> Cheers, >>> Ian >>>=20 >>>=20 >>>> On 21 Jul 2015, at 12:44, Jouni Korhonen >>>> >> = wrote: >>>>=20 >>>> Thanks Ian, >>>>=20 >>>> And the metadata is just a binary blob only understood by the = PVD-ID >>>> "owner"? >>>>=20 >>>> - Jouni >>>>=20 >>>> 7/21/2015, 2:02 AM, Ian Farrer kirjoitti: >>>>> Hi Jouni, >>>>>=20 >>>>> The specific things that I think need to be addressed here are: >>>>>=20 >>>>> 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=92s 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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). >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> So, the short answer to your question is: Single PvD-ID format (I = like >>>>> UUID) + extensible associated meta-data. >>>>>=20 >>>>> Cheers, >>>>> Ian >>>>>=20 >>>>>=20 >>>>>> On 20 Jul 2015, at 20:08, Jouni Korhonen >>>>>> > >>>>>> >> = wrote: >>>>>>=20 >>>>>> Ian, >>>>>>=20 >>>>>> So would UUID be adequate PVD-ID format as suggested below? >>>>>>=20 >>>>>> What about the additonal information part? Not needed? >>>>>>=20 >>>>>> - Jouni >>>>>>=20 >>>>>>=20 >>>>>> 7/20/2015, 7:33 AM, Ian Farrer kirjoitti: >>>>>>> Hi, >>>>>>>=20 >>>>>>> Before this document can proceed, I think that there is still a >>>>>>> significant open point. Multiple or single PVD ID formats? >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> So, I would like to see this discussion take place before the = document >>>>>>> progresses. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Ian >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 14 Jul 2015, at 17:18, Hui Deng >>>>>>>> > >>>>>>>> > >>>>>>>> >> = wrote: >>>>>>>>=20 >>>>>>>> Hello all, >>>>>>>>=20 >>>>>>>> We would like to have a 3 weeks WGLC for the below document: >>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-id/ = >>>>>>>>=20 >>>>>>>> Please help to send your comments to this thread. >>>>>>>> This WGLC will end on Aug. 5th. >>>>>>>>=20 >>>>>>>> Many thanks >>>>>>>>=20 >>>>>>>> DENG Hui >>>>>>>> _______________________________________________ >>>>>>>> mif mailing list >>>>>>>> mif@ietf.org >>>>>>>> >>> >>>>>>>> https://www.ietf.org/mailman/listinfo/mif = >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 --Apple-Mail=_F3533EDB-77C1-4291-8E57-F75B7036AC9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jouni,

Did we reach a conclusion on this?

Thanks,
Ian


On 22 Jul 2015, at 17:21, 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=92s a closed system, so it=92s = 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=92s 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 =92streamingtv.bigtelco.com=92). The FQDN format is = standard, so the app without any knowledge of the operator=92s network = can interpret this and offer it to the user as a choice. Once the app is = configured, it=92s 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=92t 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=92= 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=92s 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

= --Apple-Mail=_F3533EDB-77C1-4291-8E57-F75B7036AC9B-- From nobody Wed Aug 19 01:27:18 2015 Return-Path: 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 D104C1AD0D0 for ; Wed, 19 Aug 2015 01:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] 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 T4XQIoK4f3mX for ; Wed, 19 Aug 2015 01:27:13 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [82.96.72.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5782F1A0398 for ; Wed, 19 Aug 2015 01:27:13 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZRyiF-0000kA-0V with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 19 Aug 2015 10:27:11 +0200 To: Ian Farrer , Jouni Korhonen References: <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> From: Steven Barth Message-ID: <55D43DDE.8060507@openwrt.org> Date: Wed, 19 Aug 2015 10:27:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "mif@ietf.org" , Hui Deng 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 08:27:17 -0000 As noted already in another thread, I very much second this notion of needing non-opaque properties also wrt. homenet: See also my earlier mail here: https://mailarchive.ietf.org/arch/msg/mif/TwyCKyU3e3jX-4v35BMaBPm3X_0 Am 19.08.2015 um 10:21 schrieb Ian Farrer: > Hi Jouni, > > Did we reach a conclusion on this? > > Thanks, > Ian > > >> On 22 Jul 2015, at 17:21, Ian Farrer > 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 > 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 >>>>> > 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 >>>>>>> >>>>>>> > 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> > 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 >>>>>>>>> >>>>>>>>> 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 > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >