From nobody Sun Nov 1 07:08:43 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 5B1AA1B8506 for ; Sun, 1 Nov 2015 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, 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 aB6ZoN7KhAfe for ; Sun, 1 Nov 2015 07:08:40 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 9329D1B84FE for ; Sun, 1 Nov 2015 07:08:40 -0800 (PST) Received: by wikq8 with SMTP id q8so37177934wik.1 for ; Sun, 01 Nov 2015 07:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=pC6gcgiOCd5U22rx7s+e+TaSJGjnGQDCrRnatraMWxY=; b=QlspJOo1cI2Ec+Jn85933KArbTnyf+2zN2lqwcF8rbEBg9x9P+lHO+cwHJiJnvoGVU KAmhddOAHxbrvJMV+wrofH6hnceSzZIzvPCRkFFE3Wu21v6RX30Q6tAqsrZKcF9ViB/W TDUW3CId6iZyaPSMH0o5nfSBxuVVuva/xUQ9SAuec6rQE6XlnFnw3ASkdaAQRngZoiSH oyLMBxcFFoKuBbz66rxNf0xELSDJUiTxHJ/sWgKHcRmOfA6raStBSpxUyPnSqKsJRV+7 m1Cq29CHh/m6/1HjYSoZ1hlPAgv24aK2KtsIhHps0H7i2X1i9uxM/4Rn9rDcrnQfwAMa +Yfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=pC6gcgiOCd5U22rx7s+e+TaSJGjnGQDCrRnatraMWxY=; b=Fs8vVoH2SrBaU2cQDPDLOSFUQ4hPXFS77wcYTcKXAJsY/jggGgmY878/WkyFtVN15+ EI7wDKnysTlH+pt5H12EZi1ZE+QeHd339pdxleCOc5rgH0yiCJ8v+UB7zhTSTUe5NdY/ AmMMrgWJh4gXcPTNLcNIOMM2yRkybqlMqnAg69154WOIqQFT1/FxehO21MyjDeKeVmqb 7UX3Hl7whuI+YJUmtoQ8Qa4O36EB9h0qW72n87RVqbR8FslYKyEdE0g3k0sc/Qd5mwYd d4bDPcjYCGVO3ov0JCP9WdzB2GiRaJ6Ek4vfeM9SpOJfvYg/TJxvp2KKSZNBvclBALTA auTg== X-Gm-Message-State: ALoCoQlmP/CFaeOJKexqo0CEhgWMakbNYmxGfpk1gPEinLvI3RHj5Z3SHYdByNrD/ks/FK/4bcPv X-Received: by 10.195.11.33 with SMTP id ef1mr18074758wjd.34.1446390519061; Sun, 01 Nov 2015 07:08:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.2 with HTTP; Sun, 1 Nov 2015 07:08:19 -0800 (PST) In-Reply-To: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> From: Erik Kline Date: Mon, 2 Nov 2015 00:08:19 +0900 Message-ID: To: "mif@ietf.org" Content-Type: multipart/alternative; boundary=089e01494ea018b42505237c096e Archived-At: Subject: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-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: Sun, 01 Nov 2015 15:08:42 -0000 --089e01494ea018b42505237c096e Content-Type: text/plain; charset=UTF-8 All, Quite, quite late, but I took a stab at scrapping the presentation from Prague and writing instead an MPvD API requirements document. -ek ---------- Forwarded message ---------- From: Date: 2 November 2015 at 00:03 Subject: New Version Notification for draft-kline-mif-mpvd-api-reqs-00.txt A new version of I-D, draft-kline-mif-mpvd-api-reqs-00.txt has been successfully submitted by Erik Kline and posted to the IETF repository. Name: draft-kline-mif-mpvd-api-reqs Revision: 00 Title: Multiple Provisioning Domains API Requirements Document date: 2015-11-01 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-kline-mif-mpvd-api-reqs-00.txt Status: https://datatracker.ietf.org/doc/draft-kline-mif-mpvd-api-reqs/ Htmlized: https://tools.ietf.org/html/draft-kline-mif-mpvd-api-reqs-00 Abstract: RFC 7556 [RFC7556] provides the essential conceptual guidance an API designer would need to support use of PvDs. This document aims to capture the requirements for an API that can be used by applications that would be considered "advanced", according to section 6.3 [1] of RFC 7556 [RFC7556]. The "basic" [2] and "intermediate" [3] API support levels can in principle be implemented by means of layers wrapping the advanced API. 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. The IETF Secretariat --089e01494ea018b42505237c096e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Quite, quite late, but = I took a stab at scrapping the presentation from Prague and writing instead= an MPvD API requirements document.

-ek
=

---------- Forwarded message -----= -----
From: <internet-drafts@ietf.org>
Date: 2 November 2015 at 00:03
Subject: New Version Notificatio= n for draft-kline-mif-mpvd-api-reqs-00.txt



A new version of I-D, draft-kline-mif-mpvd-api-reqs-00.txt
has been successfully submitted by Erik Kline and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kline-mif-mpvd-api-reqs=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multiple Provisioning Domains API = Requirements
Document date:=C2=A0 2015-11-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-kline-mif-mpv= d-api-reqs-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kline-mif-mpvd-api-reqs/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-kline-mif-mpvd-api-reqs-00


Abstract:
=C2=A0 =C2=A0RFC 7556 [RFC7556] provides the essential conceptual guidance = an API
=C2=A0 =C2=A0designer would need to support use of PvDs.=C2=A0 This documen= t aims to
=C2=A0 =C2=A0capture the requirements for an API that can be used by applic= ations
=C2=A0 =C2=A0that would be considered "advanced", according to se= ction 6.3 [1] of
=C2=A0 =C2=A0RFC 7556 [RFC7556].=C2=A0 The "basic" [2] and "= intermediate" [3] API
=C2=A0 =C2=A0support levels can in principle be implemented by means of lay= ers
=C2=A0 =C2=A0wrapping the advanced API.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e01494ea018b42505237c096e-- From nobody Mon Nov 2 01:44:23 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 79CA21A0262 for ; Mon, 2 Nov 2015 01:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 XnOQnaZdWy-T for ; Mon, 2 Nov 2015 01:44:19 -0800 (PST) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6249A1A024E for ; Mon, 2 Nov 2015 01:44:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id F0FCA3B7C04C; Mon, 2 Nov 2015 10:44:16 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obul+gJi66+w; Mon, 2 Nov 2015 10:44:15 +0100 (CET) Received: from w540.sistemnet.local (Enel.zemris.fer.hr [161.53.65.34]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 27F883B7C047; Mon, 2 Nov 2015 10:44:15 +0100 (CET) References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> To: Erik Kline From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER Message-ID: <5637306E.40006@fer.hr> Date: Mon, 2 Nov 2015 10:44:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OQEQwOaKfMTMSEpIW9XSB4fAlNrvI34wW" Archived-At: Cc: mif@ietf.org Subject: Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-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, 02 Nov 2015 09:44:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OQEQwOaKfMTMSEpIW9XSB4fAlNrvI34wW Content-Type: multipart/alternative; boundary="------------070801060504070909050204" This is a multi-part message in MIME format. --------------070801060504070909050204 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Erik, Thank you for the draft. I have few comments/questions. First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case? In section 3.4 there is a note/question about "loopback PvD". What we were thinking/discussing is that there should be such a PvD for backwards compatibility, i.e. for non-PvD aware applications that for some reason expect all available connections and interfaces (PvDs) to be present (non-PvD aware mpTCP and SCTP applications, UDP applications, debugging applications like tcpdump/wireshark). This configuration we called internally "root network name space". SG On 01.11.2015 16:08, Erik Kline wrote: > All, > > Quite, quite late, but I took a stab at scrapping the presentation > from Prague and writing instead an MPvD API requirements document. > > -ek > > > ---------- Forwarded message ---------- > From: > > Date: 2 November 2015 at 00:03 > Subject: New Version Notification for draft-kline-mif-mpvd-api-reqs-00.= txt > > > > A new version of I-D, draft-kline-mif-mpvd-api-reqs-00.txt > has been successfully submitted by Erik Kline and posted to the > IETF repository. > > Name: draft-kline-mif-mpvd-api-reqs > Revision: 00 > Title: Multiple Provisioning Domains API Requirements > Document date: 2015-11-01 > Group: Individual Submission > Pages: 15 > URL: =20 > https://www.ietf.org/internet-drafts/draft-kline-mif-mpvd-api-reqs-00.t= xt > Status: =20 > https://datatracker.ietf.org/doc/draft-kline-mif-mpvd-api-reqs/ > Htmlized: =20 > https://tools.ietf.org/html/draft-kline-mif-mpvd-api-reqs-00 > > > Abstract: > RFC 7556 [RFC7556] provides the essential conceptual guidance an API= > designer would need to support use of PvDs. This document aims to > capture the requirements for an API that can be used by applications= > that would be considered "advanced", according to section 6.3 [1] of= > RFC 7556 [RFC7556]. The "basic" [2] and "intermediate" [3] API > support levels can in principle be implemented by means of layers > wrapping the advanced API. > > > > > 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 > . > > The IETF Secretariat > > --------------070801060504070909050204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Erik,

Thank you for the draft.

I have few comments/questions.

First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case?

In section 3.4 there is a note/question about "loopback PvD". What we were thinking/discussing is that there should be such a PvD for backwards compatibility, i.e. for non-PvD aware applications that for some reason expect all available connections and interfaces (PvDs) to be present (non-PvD aware mpTCP and SCTP applications, UDP applications, debugging applications like tcpdump/wireshark). This configuration we called internally "root network name space".<= br>
SG

On 01.11.2015 16:08, Erik Kline wrote:
All,

Quite, quite late, but I took a stab at scrapping the presentation from Prague and writing instead an MPvD API requirements document.

-ek


---------- Forwarded message ---------= -
From: <internet-drafts@ie= tf.org>
Date: 2 November 2015 at 00:03
Subject: New Version Notification for draft-kline-mif-mpvd-api-reqs-00.txt



A new version of I-D, draft-kline-mif-mpvd-api-reqs-00.txt
has been successfully submitted by Erik Kline and posted to the
IETF repository.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-kline-mif-mpvd-api-reqs
Revision:=A0 =A0 =A0 =A000
Title:=A0 =A0 =A0 =A0 =A0 Multiple Provisioning Domains API Req= uirements
Document date:=A0 2015-11-01
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 15
URL:=A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/int= ernet-drafts/draft-kline-mif-mpvd-api-reqs-00.txt
Status:=A0 =A0 =A0 =A0 =A0https://datatracker.ietf= =2Eorg/doc/draft-kline-mif-mpvd-api-reqs/
Htmlized:=A0 =A0 =A0 =A0https://tools.ietf.org/h= tml/draft-kline-mif-mpvd-api-reqs-00


Abstract:
=A0 =A0RFC 7556 [RFC7556] provides the essential conceptual guidance an API
=A0 =A0designer would need to support use of PvDs.=A0 This docu= ment aims to
=A0 =A0capture the requirements for an API that can be used by applications
=A0 =A0that would be considered "advanced", according to sectio= n 6.3 [1] of
=A0 =A0RFC 7556 [RFC7556].=A0 The "basic" [2] and "intermediate= " [3] API
=A0 =A0support levels can in principle be implemented by means = of layers
=A0 =A0wrapping the advanced API.




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.

The IETF Secretariat



--------------070801060504070909050204-- --OQEQwOaKfMTMSEpIW9XSB4fAlNrvI34wW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWNzBuAAoJELZD5ReLhUf0IxsH/jUAmCOGPmeiBFqP1hhzITpv RrmM6xJpeJLDcGYAeWWg1vwRi49Y/MTg9swxWV7SgJtrUTpJ8cZ0ppMl6YxVh4N/ /Q+BWBffyo8xp4igVCbBFop7BzNOiudKZ1hXL/7/ilCOuKsYXHNMIi3HaFpGW59X wmF/yN9TRAjS3l+edhgHEmHojfleapaxRzNT+dlMcwHxZVCGrxEv5zsKT2qllN3r k2HbVt/qGnoaeZd56VOkPWOze9U8xmPVa5HvBH4hrhdB3Zp9LqR/c2AoDHK3Q83X mx7BMyJtWd8FesKo7rBWuZUwFS1gydUGwQ9W2Ft43Hq29uTDpyBlANYOU8QpIKE= =M6Cz -----END PGP SIGNATURE----- --OQEQwOaKfMTMSEpIW9XSB4fAlNrvI34wW-- From nobody Mon Nov 2 04:18:52 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 CDF4A1A8739 for ; Mon, 2 Nov 2015 04:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 jXSLQ0WacFzz for ; Mon, 2 Nov 2015 04:18:49 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 BE4E11A873B for ; Mon, 2 Nov 2015 04:18:48 -0800 (PST) Received: by wmeg8 with SMTP id g8so58939354wme.1 for ; Mon, 02 Nov 2015 04:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SKBraHw0LvlWavtn9Gu2eZtgwyhj2juNFCXg3RCvIUg=; b=Ai/q2FLlXEaM6zjEJVewi9XrTtOVREuO+jy5J8pTR8U9UtiY+TZNFJlqhchI5uGOSC waBK9LFhMSn87ZQOsXJ+ifZeb/yJA9JzQsdntKEBZSUJH6xjIYZAa++HVhE08vMNvAWk FgLNMbdozNC0nj9TuyCl42Rnry8G6I5oq9Y5NM4YTTjVu32KNtVNVkIh56nVDJXrFSv9 bhZV0fA4UJ95ufctgY+f6dOR3Zu3BAUXHm9GnuoCL5nYUngn0DjnRwv4/lfpsJSG++kU S/h9J90lDzZsSsczqffvGHjMXnbD50yKVDyAR2dy7tr8DFuAPrPA+TppTk7a9e9hkzfw g7oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SKBraHw0LvlWavtn9Gu2eZtgwyhj2juNFCXg3RCvIUg=; b=amwvNbKq7fDinkoPYQB7BJp4FbMyUbLuLmhlZIKhwdLC7g1QFpIsnIlHjq9zRWUqPK RFPBYL9LWaJ4dy2Mbzm9TmhI4fcL/3+dUqbhP2r0hY1J7VwHbIjxJQEXv86XY3Pg9z55 OhA23Xant0SQbXf/7B0o96wLBL7lKZV8Oh5phPShtaKYrBbph5Y35Q2IA0OPKc6/45bh n/iDQyNrYVrg7oBivsBBzQLR+JMd46soerhvFNCJJljftSFpw+XdYtHA7lJwQVftyDQA djsGco77RhwHMSfuTYmr2SzfIVe1FKzWPsTvNM51FAmZg/Dr74uRdiOACkX0/nBZV8Ku xtpQ== X-Gm-Message-State: ALoCoQmo6WAwLFvQQvgnbBE7ewfqIcysQ0za+AoFqbauKhtDX6koy/l36erjBMsK8PpTFZLgrTIp X-Received: by 10.28.23.66 with SMTP id 63mr12498922wmx.4.1446466727144; Mon, 02 Nov 2015 04:18:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.2 with HTTP; Mon, 2 Nov 2015 04:18:27 -0800 (PST) In-Reply-To: <5637306E.40006@fer.hr> References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> <5637306E.40006@fer.hr> From: Erik Kline Date: Mon, 2 Nov 2015 21:18:27 +0900 Message-ID: To: =?UTF-8?Q?Stjepan_Gro=C5=A1?= Content-Type: multipart/alternative; boundary=001a11468aa873d23c05238dc784 Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-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, 02 Nov 2015 12:18:51 -0000 --001a11468aa873d23c05238dc784 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 wrote: > Hi Erik, > > Thank you for the draft. > > I have few comments/questions. > > First, what I'm reading from the draft is that each PvD aware application > should have access to a single PvD at any single moment? If that is so, > what about mpTCP and SCTP applications that are PvD aware? They should ha= ve > access to multiple PvDs simultaneously for a fail over reasons. So, how > this draft takes into account that use case? > Not quite: they should be able to specify only one PvD per function call, per thread (for example). An app can have multiple sockets, each one using one PvD. An app can have something like a single unconnected datagram socket and call sendto() with a different PvD for each sendto() call. That kind of thing is more what I meant to write, but I guess was not very clear. (Clearly, I have a bunch of sockets-y things in my head but am trying to write things in a more general, non-sockets-dependent way.) The confusion may be arising in part from the resolution of which PvD to use for a given function call if no PvD is specified. In those cases, the system checks for "defaults" at increasingly general levels. So a process could set a process default PvD and avoid having to specify the PvD for each an every call, but still make individual socket calls or query DNS on a different PvD whenever it wants to. Does this make more sense? There are necessarily going to be sequences of function calls after which trying to change a PvD will be non-sensical. For example, after I have a connected TCP socket: a source address has been chosen from a PvD and the PvD's routing table is in use for every write()/send() I call. Attempting to change which PvD is use is a bit non-sensical at that point, and I think perhaps that an API should not really allow it. In section 3.4 there is a note/question about "loopback PvD". What we were > thinking/discussing is that there should be such a PvD for backwards > compatibility, i.e. for non-PvD aware applications that for some reason > expect all available connections and interfaces (PvDs) to be present > (non-PvD aware mpTCP and SCTP applications, UDP applications, debugging > applications like tcpdump/wireshark). This configuration we called > internally "root network name space". > That sounds a bit different from what I was thinking of a loopback PvD. What you describe sounds like how things are today in a totally non-PvD-aware system, which has the kinds of problems we're aiming to solve, yes? -ek --001a11468aa873d23c05238dc784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 <stjepan.gros@fer.hr<= /a>> wrote:
=20 =20 =20
Hi Erik,

Thank you for the draft.

I have few comments/questions.

First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case?

Not quite: they should be able to specify only one PvD per function = call, per thread (for example).=C2=A0 An app can have multiple sockets, eac= h one using one PvD.=C2=A0 An app can have something like a single unconnec= ted datagram socket and call sendto() with a different PvD for each sendto(= ) call.=C2=A0 That kind of thing is more what I meant to write, but I guess= was not very clear. =C2=A0(Clearly, I have a bunch of sockets-y things in = my head but am trying to write things in a more general, non-sockets-depend= ent way.)

The confusion may be arising in part fro= m the resolution of which PvD to use for a given function call if no PvD is= specified.=C2=A0 In those cases, the system checks for "defaults"= ; at increasingly general levels.=C2=A0 So a process could set a process de= fault PvD and avoid having to specify the PvD for each an every call, but s= till make individual socket calls or query DNS on a different PvD whenever = it wants to.

Does this make more sense?
=
There are necessarily going to be sequences of function call= s after which trying to change a PvD will be non-sensical.=C2=A0 For exampl= e, after I have a connected TCP socket: a source address has been chosen fr= om a PvD and the PvD's routing table is in use for every write()/send()= I call.=C2=A0 Attempting to change which PvD is use is a bit non-sensical = at that point, and I think perhaps that an API should not really allow it.<= /div>

In section 3.4 there is a note/question about "loopback PvD"= ;. What we were thinking/discussing is that there should be such a PvD for backwards compatibility, i.e. for non-PvD aware applications that for some reason expect all available connections and interfaces (PvDs) to be present (non-PvD aware mpTCP and SCTP applications, UDP applications, debugging applications like tcpdump/wireshark). This configuration we called internally "root network name space= ".

That sounds a bit diffe= rent from what I was thinking of a loopback PvD.=C2=A0 What you describe so= unds like how things are today in a totally non-PvD-aware system, which has= the kinds of problems we're aiming to solve, yes?

=
-ek
--001a11468aa873d23c05238dc784-- From nobody Mon Nov 2 05:13:40 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 DB0801B362A for ; Mon, 2 Nov 2015 05:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 0xQnrMJirCWe for ; Mon, 2 Nov 2015 05:13:35 -0800 (PST) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 646B81B3626 for ; Mon, 2 Nov 2015 05:13:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id 559F23B7C04C; Mon, 2 Nov 2015 14:13:34 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4baznNOJ4i+Z; Mon, 2 Nov 2015 14:13:25 +0100 (CET) Received: from w540.sistemnet.local (Enel.zemris.fer.hr [161.53.65.34]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 579B23B7C047; Mon, 2 Nov 2015 14:13:25 +0100 (CET) To: Erik Kline References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> <5637306E.40006@fer.hr> From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER Message-ID: <56376171.7060203@fer.hr> Date: Mon, 2 Nov 2015 14:13:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CFniuhGdjmfMvnlgULOoTpMuJ9JecpfQB" Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-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, 02 Nov 2015 13:13:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CFniuhGdjmfMvnlgULOoTpMuJ9JecpfQB Content-Type: multipart/alternative; boundary="------------020902050802050606090307" This is a multi-part message in MIME format. --------------020902050802050606090307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02.11.2015 13:18, Erik Kline wrote: > > On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 > wrote: > > Hi Erik, > > Thank you for the draft. > > I have few comments/questions. > > First, what I'm reading from the draft is that each PvD aware > application should have access to a single PvD at any single > moment? If that is so, what about mpTCP and SCTP applications that > are PvD aware? They should have access to multiple PvDs > simultaneously for a fail over reasons. So, how this draft takes > into account that use case? > > > Not quite: they should be able to specify only one PvD per function > call, per thread (for example). An app can have multiple sockets, > each one using one PvD. An app can have something like a single > unconnected datagram socket and call sendto() with a different PvD for > each sendto() call. That kind of thing is more what I meant to write, > but I guess was not very clear. (Clearly, I have a bunch of sockets-y > things in my head but am trying to write things in a more general, > non-sockets-dependent way.) > > The confusion may be arising in part from the resolution of which PvD > to use for a given function call if no PvD is specified. In those > cases, the system checks for "defaults" at increasingly general > levels. So a process could set a process default PvD and avoid having > to specify the PvD for each an every call, but still make individual > socket calls or query DNS on a different PvD whenever it wants to. > > Does this make more sense? I was thinking on functions like sctp_bindx that explicitly expect multiple IP addresses to be present at a point when the function is called. mpTCP could be even bigger problem because, as I understand it, Linux kernel autonomously decides which local IP addresses to use. > > There are necessarily going to be sequences of function calls after > which trying to change a PvD will be non-sensical. For example, after > I have a connected TCP socket: a source address has been chosen from a > PvD and the PvD's routing table is in use for every write()/send() I > call. Attempting to change which PvD is use is a bit non-sensical at > that point, and I think perhaps that an API should not really allow it.= > > In section 3.4 there is a note/question about "loopback PvD". What > we were thinking/discussing is that there should be such a PvD for > backwards compatibility, i.e. for non-PvD aware applications that > for some reason expect all available connections and interfaces > (PvDs) to be present (non-PvD aware mpTCP and SCTP applications, > UDP applications, debugging applications like tcpdump/wireshark). > This configuration we called internally "root network name space". > > > That sounds a bit different from what I was thinking of a loopback > PvD. What you describe sounds like how things are today in a totally > non-PvD-aware system, which has the kinds of problems we're aiming to > solve, yes? Probably I missed the point here, i.e. there is no point of having something like "all addresses" when we are talking about PvD aware applications that can find out all of them via PvD API. Yet, I believe that something like "all addresses present" will have to exists on a system due to the backwards compatibility with legacy applications which will be with us for a long time. Now, I don't know if that is something that should be covered by PvD API or not, probably depends on use-cases. SG P.S. When I'm discussing these issues I'm thinking about general Linux Workstation, like Fedora, and in addition I'm also I'm in terms of network name spaces as the way to implement PvD separation. > -ek --------------020902050802050606090307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 02.11.2015 13:18, Erik Kline wrote:

On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 <stjep= an.gros@fer.hr> wrote:
Hi Erik,

Thank you for the draft.

I have few comments/questions.

First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case?

Not quite: they should be able to specify only one PvD per function call, per thread (for example).=C2=A0 An app c= an have multiple sockets, each one using one PvD.=C2=A0 An app= can have something like a single unconnected datagram socket and call sendto() with a different PvD for each sendto() call.=C2=A0 That kind of thing is more what I meant to writ= e, but I guess was not very clear. =C2=A0(Clearly, I have a bu= nch of sockets-y things in my head but am trying to write things in a more general, non-sockets-dependent way.)
=

The confusion may be arising in part from the resolution of which PvD to use for a given function call if no PvD is specified.=C2=A0 In those cases, the system ch= ecks for "defaults" at increasingly general levels.=C2=A0 So a process could set a process default PvD and avoid having to specify the PvD for each an every call, but still make individual socket calls or query DNS on a different PvD whenever it wants to.

Does this make more sense?

I was thinking on functions like sctp_bindx that explicitly expect multiple IP addresses to be present at a point when the function is called. mpTCP could be even bigger problem because, as I understand it, Linux kernel autonomously decides which local IP addresses to use.


There are necessarily going to be sequences of function calls after which trying to change a PvD will be non-sensical.=C2=A0 For example, after I have a connected T= CP socket: a source address has been chosen from a PvD and the PvD's routing table is in use for every write()/send() I call.=C2=A0 Attempting to change which PvD is use is a bi= t non-sensical at that point, and I think perhaps that an API should not really allow it.

In section 3.4 there is a note/question about "loopback PvD". What we were thinking/discussing is that there should be such a PvD for backwards compatibility, i.e. for non-PvD aware applications that for some reason expect all available connections and interfaces (PvDs) to be present (non-PvD aware mpTCP and SCTP applications, UDP applications, debugging applications like tcpdump/wireshark). This configuration we called internally "root network name space".

That sounds a bit different from what I was thinking of a loopback PvD.=C2=A0 What you describe sounds like how thi= ngs are today in a totally non-PvD-aware system, which has the kinds of problems we're aiming to solve, yes?

Probably I missed the point here, i.e. there is no point of having something like "all addresses" when we are talking about PvD aware applications that can find out all of them via PvD API. Yet, I believe that something like "all addresses present" will have to exists on a system due to the backwards compatibility with legacy applications which will be with us for a long time. Now, I don't know if that is something that should be covered by PvD API or not, probably depends on use-cases.

SG

P.S. When I'm discussing these issues I'm thinking about general Linux Workstation, like Fedora, and in addition I'm also I'm in terms of network name spaces as the way to implement PvD separation.<= br>
-ek

--------------020902050802050606090307-- --CFniuhGdjmfMvnlgULOoTpMuJ9JecpfQB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWN2FxAAoJELZD5ReLhUf0Oh8H/RGexj0Hq8KTv8MJqqD2hAK0 DTcRrp18Y+oTxENUWsfJl1bv3vg1p4WDPwTfqLy6HRjyKVVrXKHW8XL5RWVs/MZO JOWQBv8vqstwh8TAHJjebnNL0uF9kPzIo5PRDhcxRpo1na64+1XMgIKm+1Yjswvn stBzozK1VTjTIBeHvdXMHIablUivDpCMD2s5JsbQKp+fyQM/y+QTeW6c2cjVj+0L VSdgSfckWdKclYsd7dHO2033p1QALDRaKrTpV7BDO6cgIiKsBeSznR5gnQ7A9Zye O/4k+hI775pdInDrkaI0rV49KlhvDwMvh2SiqTuBowloEfbCixgVZqlGIpK2eA8= =DhB5 -----END PGP SIGNATURE----- --CFniuhGdjmfMvnlgULOoTpMuJ9JecpfQB-- From nobody Tue Nov 3 22:11:37 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 786331ACE5E for ; 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 ; 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 ; 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 Content-type: multipart/alternative; boundary="Apple-Mail=_01914FFF-77ED-43A9-A136-2C4190843A11" Message-id: MIME-version: 1.0 (Mac OS X Mail 9.2 \(3106\)) Date: Wed, 04 Nov 2015 15:11:29 +0900 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: Ian Farrer , "mif@ietf.org" , Hui Deng 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: 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, 04 Nov 2015 06:11:35 -0000 --Apple-Mail=_01914FFF-77ED-43A9-A136-2C4190843A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, We=92ve 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=92s 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. =46rom 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 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=_01914FFF-77ED-43A9-A136-2C4190843A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello,

We=92ve 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=92s 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.

=46rom 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=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=_01914FFF-77ED-43A9-A136-2C4190843A11-- From nobody Tue Nov 3 23:58:23 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 90EAD1B2B1A for ; Tue, 3 Nov 2015 23:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, 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 kESFfZlusCuF for ; Tue, 3 Nov 2015 23:58:20 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 237451B2B20 for ; Tue, 3 Nov 2015 23:58:20 -0800 (PST) Received: by ykek133 with SMTP id k133so59175167yke.2 for ; Tue, 03 Nov 2015 23:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=r6oVUxs74DIpNDdMQkg88Gn7BcKpVGEY9mtUBOj/iJ0=; b=krg52Cl4wRhP2T5f+/dLcvGBW7h21qT1g2xjFpL89ntdAB7RQp1D5NxLx8OlwJO6p3 Yo53zMFs+7cbaRIvEXUJfEH8EiaWwKzRfUG3SMl5rD8VCiOyfNRvQuOSA9Gj4TXZMZR5 XJ5FncwUIsKsaMrKljnE4gwCtPjP22dNOyPEvanZUXyCZI17qZVPu53BVtTdEMJb/IGN q9SSYfMRBgnnra/4PM/2aQC2kS1Wlsx74Po/IIuvWlBeebiDAMr8aE1yOp0p8WKCRrNb XJsXOUu7c7VG51v818sfJTUH5X9K+exJ+8Ky3U6E55zziaJz3itya5MPoQbV7R2O6gqy mfKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=r6oVUxs74DIpNDdMQkg88Gn7BcKpVGEY9mtUBOj/iJ0=; b=crJOxVp6fkchcGHi0DUATc1VnYa7wlX14K8Lw8G0RHEv0i2/9K33htHtEHdBHLFC/W dxDf8usJE1nJc3Fchhh2rS6STCMaT7GqLxSLpS63a0v8IbueX8aFdNv87HATEUols+g8 QPECzK32sQEq7//9PEoWW5XdCyx1vQHDMzD6Ie+P5SkBp1jmhMsEKBtZEYZmUhlKF+/L Ba4GOVGUIgdQFR51a3ZvqIFB23DH9I94hl/Wj7/NPbX1PRk3TWaQgXefm0DPNQ0GIjo7 EdAWEjVV0JADV4ZNABr8/MOLk5vz0aBkbQZ8ozELTTPegbK+7qBNhDYDnKTktDIPQmWw zsnA== X-Gm-Message-State: ALoCoQkoC7bYSHdWbIXds0mkMBjdZhYawkfUKBshv9x3NI9bSyJaCbaUq1tFyxBf+F4xZHQMKnHz X-Received: by 10.129.44.3 with SMTP id s3mr88612yws.141.1446623899299; Tue, 03 Nov 2015 23:58:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.87.197 with HTTP; Tue, 3 Nov 2015 23:57:59 -0800 (PST) In-Reply-To: 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: Lorenzo Colitti Date: Wed, 4 Nov 2015 16:57:59 +0900 Message-ID: To: Tommy Pauly Content-Type: multipart/alternative; boundary=001a114278dea49c240523b25fbb 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, 04 Nov 2015 07:58:21 -0000 --001a114278dea49c240523b25fbb Content-Type: text/plain; charset=UTF-8 On Wed, Nov 4, 2015 at 3:11 PM, Tommy Pauly wrote: > 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. > +1. A fixed-length ID (64 or 128 bits) would be much easier to support. --001a114278dea49c240523b25fbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 4, 2015 at 3:11 PM, Tommy Pauly <tpauly@apple.com> wr= ote:
=
Concerns with the many types of ID described in=C2=A0draft-ietf-mif-mp= vd-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 numbe= r 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 esse= ntially useless. If there is no added information, having more types and mo= re lengths only adds processing overhead.

=
+1. A fixed-length ID (64 or 128 bits) would be much easier to s= upport.=C2=A0
--001a114278dea49c240523b25fbb-- From nobody Wed Nov 4 01:05:45 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 D5DE61A0140 for ; Wed, 4 Nov 2015 01:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, 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 C6APGKQscErL for ; Wed, 4 Nov 2015 01:05:42 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 2B6791A00F5 for ; Wed, 4 Nov 2015 01:05:42 -0800 (PST) Received: by padhx2 with SMTP id hx2so39473362pad.1 for ; Wed, 04 Nov 2015 01:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5465uHI3qXhFnYtQkiVhTxZLawzUtRnAuFfswNR6Lu0=; b=HrDeRlRJDZ6TFN429eVcLsImc83Q5r/ks+NxbVOJpm8mYg0uXzrMw1ST5HZAaC+lEM xF3xqbd1sfP0Ph7O9l+M1mILcxUlJGZIfBGXuTN+lRRhtqqH4B9XSCqi088dA21v5Azf VYRMHTcFF+bOlTzudL1T6FVaAPVujUBkMZjGdxSFP/9QzOUITm9peQSKYsT2Xu0jVa4G g79XzsZ+SkpRg08mIJ78a7p+ZccS/VdBAOqTpumIHK7whHZ20LHon/54PXbMO1kxq1OH 7qAIi+BEnotnj9wDaaYYBxY02qqHd1h0sY+0Z+9Ynrpc+aAJM3mt0HG7GA2HFlLzYblf B71w== X-Received: by 10.68.78.66 with SMTP id z2mr467374pbw.144.1446627941804; Wed, 04 Nov 2015 01:05:41 -0800 (PST) Received: from ?IPv6:2601:647:4204:228b:9484:5d97:bc5e:118e? ([2601:647:4204:228b:9484:5d97:bc5e:118e]) by smtp.gmail.com with ESMTPSA id cn4sm619307pbc.94.2015.11.04.01.05.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Nov 2015 01:05:41 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Wed, 4 Nov 2015 01:05:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6178F689-9321-41AD-B9AA-550C8A12FF05@gmail.com> 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: Tommy Pauly X-Mailer: Apple Mail (2.2104) 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, 04 Nov 2015 09:05:45 -0000 Just a clarifying question. =93Strongly agree=94 is only for the = fixed-size type (e.g., UUID), not for the extensible additional metadata = carried along with the fixed-size type (as advocated in Ian=92s mails)? - Jouni > On 03 Nov 2015, at 22:11, Tommy Pauly wrote: >=20 > Hello, >=20 > We=92ve 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. >=20 > I wanted to resurrect this thread and strongly agree with Ian=92s = 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. >=20 > 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. >=20 > =46rom 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. >=20 > Thoughts? >=20 > Thanks, > Tommy >=20 >> On Jul 23, 2015, at 12:21 AM, 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 >>=20 >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From nobody Wed Nov 4 01:13:22 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 74EE91B2B9E for ; Wed, 4 Nov 2015 01:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMwWU1xd8d3U for ; Wed, 4 Nov 2015 01:13:17 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2831A1A038C for ; Wed, 4 Nov 2015 01:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1446628395; x=2310541995; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0POzXrFValK62yD9DklfVIvwpjTpBbqLpOorbAZdI2k=; b=qtWalt9oulRkGsXQP+i5WnbCmZBpqEb6VXcRv2SqVAppsTE0C4dgV8rZT5RfcCUV 1l9xnxt/CW2h6Mf2NFM7GPF16bWnQKygDwZLORvR9QXuAh7nGB5Y2vtpMxP/1fuz KdIp+m5jYmkVpVe4UIqYVURK9/BGnfoMJRlf7uRnZM0OlvwhUYurq1ky7sjtdU4o ikLiNuN45vB95wCFUmw3VT6//AT6tLYT0Svgu+zDM3+MlvvNG4awgeHHfNXyk5IG DKxPWvH313e2/dDtE5olNa5m7a2Qnd1LUR+FN3rnSH1u6MT3sxlYnj73DZJU/d6W tVoYMy3PlnajGF+2lS+dHQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 15.BD.12069.B2CC9365; Wed, 4 Nov 2015 01:13:15 -0800 (PST) X-AuditID: 11973e12-f79c06d000002f25-70-5639cc2bf65b Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id EB.5C.29028.B2CC9365; Wed, 4 Nov 2015 01:13:15 -0800 (PST) Received: from [17.83.115.85] (unknown [17.83.115.85]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NXA00M399M1L340@spicerack.apple.com> for mif@ietf.org; Wed, 04 Nov 2015 01:13:15 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (1.0) From: Tommy Pauly X-Mailer: iPhone Mail (13A342) In-reply-to: <6178F689-9321-41AD-B9AA-550C8A12FF05@gmail.com> Date: Wed, 04 Nov 2015 18:13:15 +0900 Content-transfer-encoding: quoted-printable Message-id: <28FFBD43-EEBC-4C65-8BA3-CE2E93A9DB2C@apple.com> References: <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> <6178F689-9321-41AD-B9AA-550C8A12FF05@gmail.com> To: Jouni X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUi2FCYpqt9xjLM4MEPbYuuPTeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfOoY8GOuIqJc/4wNzAe8e1i5OSQEDCRWDP7ERuELSZx4d56 MFtIYB+jxK59ETA102efZoaIT2aSeLihpIuRC8iexCSx/O0xoAQHh7CAhMTmPYkgJrOAusSU Kbkg5bwC4hKvj05hBLGFBYwkzq49wgpiswmoSBz/tgGsU0JATmJFKydImFPAVqJ74312EJtF QFXi769/YK3MAqkS/7dfYYKwtSWevLvACjHeRmLVgevMENfsYpZY03gArFlEQEliSfsqNpCE hMASNoltPx+zTmAUmYVw3iwk581CMncBI/MqRqHcxMwc3cw8E73EgoKcVL3k/NxNjKCwnm4n tIPx1CqrQ4wCHIxKPLwN/y3ChFgTy4orcw8xSnOwKInzHtKyDBMSSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAaO5hwlTvZRz21HvFVv8pWpG3QqoXCioVz/i9cdZJ5cjtUdt+sgZ5rXy91kPh aNvdLVsba462Jhbv/Pbz2aZlG30PZO1dE3/pzZ99AcF1r7h9Qrl1VZ6vfcIbVi1rPu9WzbsT Xze8/m4xd97rqJ+aRaf2ZZvF9BxMeu0Qoue0/t++tQnXv/xvKFBiKc5INNRiLipOBABPrWcj TAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUi2FCsoat9xjLM4GWjhkXXnhtMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuHnUsWBHXMXEOX+YGxiP+HYxcnJICJhITJ99mhnCFpO4cG89 G4gtJDCZSeLhhpIuRi4gexKTxPK3x4CKODiEBSQkNu9JBDGZBdQlpkzJBSnnFRCXeH10CiOI LSxgJHF27RFWEJtNQEXi+LcNYJ0SAnISK1o5QcKcArYS3Rvvs4PYLAKqEn9//QNrZRZIlfi/ /QoThK0t8eTdBVaI8TYSqw5cZ4a4ZhezxJrGA2DNIgJKEkvaV7FNYBSchXDRLCQXzUIyagEj 8ypGgaLUnMRKC73EgoKcVL3k/NxNjOBALEzbwdi03OoQowAHoxIPb8N/izAh1sSy4srcQ4wS HMxKIrympyzDhHhTEiurUovy44tKc1KLDzEmAz0wkVlKNDkfGCV5JfGGJiYGJsbGZsbG5ibm pAkrifOWbjUPExJITyxJzU5NLUgtgtnCxMEp1cDI9YBl5ZmZbKLbV3JuNRY8Krb4Zzt3Gc/t PdvCZj79bfVk+ub0BH72L/Mfz8ic0yV22ECeddaUQoczCyedtLH/e2VPEQcXd42j4f7w0uez G9ZyROR95fDT/Dcvrbj+yQu94vXejm6Omw8c97bje1HK9PrLq78HJH7w3OXln8W7uT7ySdcp 2eVvlViKMxINtZiLihMBLI6+s4gCAAA= Archived-At: 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, 04 Nov 2015 09:13:20 -0000 The agreement is strongest for the fixed size type.=20 I do think this ID should be associated with extensible metadata, but that m= ay or may not be carried along in the same protocol as the type. We discusse= d several options for looking up the metadata after receiving the ID up fron= t.=20 Thanks, Tommy > On Nov 4, 2015, at 6:05 PM, Jouni wrote: >=20 >=20 > Just a clarifying question. =E2=80=9CStrongly agree=E2=80=9D is only for t= he fixed-size type (e.g., UUID), not for the extensible additional metadata c= arried along with the fixed-size type (as advocated in Ian=E2=80=99s mails)?= >=20 > - Jouni >=20 >> On 03 Nov 2015, at 22:11, Tommy Pauly wrote: >>=20 >> Hello, >>=20 >> We=E2=80=99ve 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 poin= t of confusion. >>=20 >> I wanted to resurrect this thread and strongly agree with Ian=E2=80=99s p= oint that the ID type and format should converge to a single, well-known, fi= xed-size type. Specifically, many of us support the idea that there is a UUI= D 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 met= a-data may include properties of the PvD that are relevant for the client, a= nd can certainly also include the FQDN or more-string based types of identif= ication. >>=20 >> Concerns with the many types of ID described in draft-ietf-mif-mpvd-id in= clude: >> - The size of the ID, although bounded in the draft to 255 bytes, may be f= ar too large for RAs, etc. A fixed, small number of bytes is much more usabl= e >> - The content of the ID if it is a richer type (string, FQDN, etc) will b= e opaque to client devices, and essentially useless. If there is no added in= formation, having more types and more lengths only adds processing overhead.= >>=20 >> =46rom the client perspective, whatever type the PvD has will have to map= ped down to a fixed length identifier for use on a system, so communicating u= sing that type on the network will be far simpler. >>=20 >> Thoughts? >>=20 >> Thanks, >> Tommy >>=20 >>> On Jul 23, 2015, at 12:21 AM, Ian Farrer wrote: >>>=20 >>> Hi Jouni, >>>=20 >>> A set top box supplied by an operator could ship pre-configured to look f= or 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= =E2=80=99s a closed system, so it=E2=80=99s achievable. >>>=20 >>> But the user may want to access the same content over the same PvD, but t= his time with a 3rd party streaming client on their laptop. Now there=E2=80=99= s no pre-configured PvD to look for, so it would be useful to present someth= ing descriptive and human readable to the user to give them a chance of bein= g able to select the right PvD for their app (e.g. you add the meta-data, as= sociated with the same UUID as above, say the FQDN format =E2=80=99streaming= tv.bigtelco.com=E2=80=99). The FQDN format is standard, so the app without a= ny knowledge of the operator=E2=80=99s network can interpret this and offer i= t to the user as a choice. Once the app is configured, it=E2=80=99s looking f= or 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 PvD= s over RAs without the FQDN meta-data option, it would still be able to iden= tify the right one to use). >>>=20 >>> Maybe you also want to attach an additional meta-data message in the DHC= Pv6 provisioning containing a URL for a page telling the user how to configu= re their client correctly. The URL is also associated with the PvD-ID (along= side 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 th= e future (within the limits of what is implementable in a client / provision= ing protocol). Several of these in different formats may be used and associa= ted with a single PvD. Clients can ignore meta-data that they don=E2=80=99t u= nderstand, or a not configured to parse. Standard formats mean that devices/= applications can interpret offered meta-data without having to be pre-config= ured (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 m= etadata. You basically move to burden of multiple, some more descriptive IDs= , to fully flexible/standardized metadata. Does not seem to improve the situ= ation. >>>>=20 >>>> - Jouni >>>>=20 >>>> 7/21/2015, 4:17 AM, Ian Farrer kirjoitti: >>>>> The meta-data formats would be standardised formats as well so that th= ey >>>>> 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 sing= le >>>>> 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=E2=80=99 could be an idea if people see a ne= ed 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 w= hole >>>>>>> of an operator=E2=80=99s 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 v= ery >>>>>>> difficult to know how this will need to evolve and be extended in th= e >>>>>>> future, so it is almost impossible to make an informed decision abou= t >>>>>>> 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 t= o >>>>>>> be combined with extensibility for adding meta-data to take advantag= e of >>>>>>> the capabilities of less constrained devices and advertising protoco= ls >>>>>>> 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 si= ngle >>>>>>> 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 capabiliti= es >>>>>>> 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 n= eed >>>>>>> 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 lo= gic >>>>>>> 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 depl= oyed. >>>>>>>=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 i= s, >>>>>>> by the PvD architecture a new PvD, even if the service properties ar= e >>>>>>> identical to an existing PvD which you have already deployed. Then, y= our >>>>>>> provisioning protocols need to advertise duplicate configuration for= >>>>>>> both of the PvDs, even thought that configuration is the same, with t= he >>>>>>> exception of the PvD-ID. >>>>>>>=20 >>>>>>> So, the short answer to your question is: Single PvD-ID format (I li= ke >>>>>>> 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 ther= e is >>>>>>>>> no reflection in the draft as it stands. This is an excerpt from t= he >>>>>>>>> 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 docu= ment >>>>>>>>> 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 >>>=20 >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >>=20 >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >=20 From nobody Wed Nov 4 04:01:47 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 83C7D1B2DEE for ; Wed, 4 Nov 2015 04:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 NtUA_9INAk9D for ; Wed, 4 Nov 2015 04:01:43 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 60F851B2DE9 for ; Wed, 4 Nov 2015 04:01:43 -0800 (PST) Received: by wmeg8 with SMTP id g8so39479687wme.1 for ; Wed, 04 Nov 2015 04:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+DgfkkCVy1Fk5T/tcEaGgNSMFSsYqpmAeop9DFNeLOE=; b=Mwcpc2HnWIe3iXGxvu0xfQjEblFpFHMYCBvy93othPk6BV9yCx9/to8C2nTNG0HcB4 jmHIRod8TGHb4TM5x1k++L8gmQXFHv4HuLvT+S1mD0imrpD5Lb/kEduI8sCi94XWYy4q xRj5Gl4NsuNroOyXdw9EL0Tjcgr/7EbMCkz6FcCePqSzeBXm2izx9uXbUEcmLDzW04Pp ts8TliNmB/fJnpHKAWkQXcdgCV9EAhZQhdORnTDa6xNQpCHK8J1nHbVQ1Fl3XEDGXtY7 2BFUZIQYmas8pj5xhRrOjR1SjTiBsuYRpy+kkQWvqhO/qXKG4zofUEVcmLwZTl09TEXi ZrUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+DgfkkCVy1Fk5T/tcEaGgNSMFSsYqpmAeop9DFNeLOE=; b=Gu76V516bLevxIQ/JyvlaROXhy1p+O1Y+pjMSoLpUWmTKbDDUOTarwaieoDzQU9t1s ZFooIRo31fbf5QtTbttHNe1R7vllwk9y6GlsseZ3Qd1vKyCq5lxzDCPS7I5L8Fu/E9XF BsRW5ghGcj+gC36CtpREhJFCgcrV0F1K3x7CrGrjy1eQLWoZPmNdxuNm4CfqTWKV5Dc+ OU7Rvk0IHiSJ7ym0GPgmcM3c0rlLuHYXkzGvIlbTSkARmU8ZueS+hy5meel8OvdxBbEb 5TuaWwz9cj49YMTlaCsjdeytY6xg8tlbB+Lbip0jPQtcXoa8BsMHVhuxP6eBemjQGc4q z2AQ== X-Gm-Message-State: ALoCoQkck2QRscRfNoqssWl+RqDHs3a9Frw8+5O47AHnJbvz9lfw+zduAh+ib5ozAuxzxZ+gRKd2 X-Received: by 10.28.11.13 with SMTP id 13mr2822639wml.4.1446638501691; Wed, 04 Nov 2015 04:01:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.27.2 with HTTP; Wed, 4 Nov 2015 04:01:22 -0800 (PST) In-Reply-To: <56376171.7060203@fer.hr> References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> <5637306E.40006@fer.hr> <56376171.7060203@fer.hr> From: Erik Kline Date: Wed, 4 Nov 2015 21:01:22 +0900 Message-ID: To: =?UTF-8?Q?Stjepan_Gro=C5=A1?= Content-Type: multipart/alternative; boundary=001a114424e803784c0523b5c6f1 Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-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: Wed, 04 Nov 2015 12:01:45 -0000 --001a114424e803784c0523b5c6f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 November 2015 at 22:13, Stjepan Gro=C5=A1 wrote: > > On 02.11.2015 13:18, Erik Kline wrote: > > > On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 wrot= e: > >> Hi Erik, >> >> Thank you for the draft. >> >> I have few comments/questions. >> >> First, what I'm reading from the draft is that each PvD aware applicatio= n >> should have access to a single PvD at any single moment? If that is so, >> what about mpTCP and SCTP applications that are PvD aware? They should h= ave >> access to multiple PvDs simultaneously for a fail over reasons. So, how >> this draft takes into account that use case? >> > > Not quite: they should be able to specify only one PvD per function call, > per thread (for example). An app can have multiple sockets, each one usi= ng > one PvD. An app can have something like a single unconnected datagram > socket and call sendto() with a different PvD for each sendto() call. Th= at > kind of thing is more what I meant to write, but I guess was not very > clear. (Clearly, I have a bunch of sockets-y things in my head but am > trying to write things in a more general, non-sockets-dependent way.) > > The confusion may be arising in part from the resolution of which PvD to > use for a given function call if no PvD is specified. In those cases, th= e > system checks for "defaults" at increasingly general levels. So a proces= s > could set a process default PvD and avoid having to specify the PvD for > each an every call, but still make individual socket calls or query DNS o= n > a different PvD whenever it wants to. > > Does this make more sense? > > > I was thinking on functions like sctp_bindx that explicitly expect > multiple IP addresses to be present at a point when the function is calle= d. > mpTCP could be even bigger problem because, as I understand it, Linux > kernel autonomously decides which local IP addresses to use. > Ah, thank you, that kind of call is an important consideration. I believe I have a solution that will work: when determining the intended PvD in the case of existing APIs that specify source addresses (and/or maybe even interfaces) we should use PvDs that are uniquely identified by this information. What to do if an address does not unique identify a PvD is another matter. For both of these issues I'm hoping to have some discussion in Friday's mif meeting. > P.S. When I'm discussing these issues I'm thinking about general Linux > Workstation, like Fedora, and in addition I'm also I'm in terms of networ= k > name spaces as the way to implement PvD separation. > > FWIW, for Android's mif implementation network namespaces were considered and rejected. Among other things, I don't think it's really possible to write an application that can have multiple sockets with each one "bound" to a different network namespace. Instead, it's a bit more like implicit PvDs are used with one interface belonging to one and only one PvD and each PvD gets its own routing table. This model is, obviously, not as general as mif work is trying to address (i.e. m:n interfaces to PvDs are not supported). (but it has been sufficient to gain some experience with how an API would look and behave) --001a114424e803784c0523b5c6f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 2 November 2015 at 22:13, Stjepan Gro=C5=A1 <stjepan.gros@fer.hr<= /a>> wrote:
=20 =20 =20

On 02.11.2015 13:18, Erik Kline wrote:

On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 <stjepan.gros@fer.hr> wrote:
Hi Erik,

Thank you for the draft.

I have few comments/questions.

First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case?

Not quite: they should be able to specify only one PvD per function call, per thread (for example).=C2=A0 An app can have multiple sockets, each one using one PvD.=C2=A0 An app c= an have something like a single unconnected datagram socket and call sendto() with a different PvD for each sendto() call.=C2=A0 That kind of thing is more what I meant to write, but I guess was not very clear. =C2=A0(Clearly, I have a bunc= h of sockets-y things in my head but am trying to write things in a more general, non-sockets-dependent way.)

The confusion may be arising in part from the resolution of which PvD to use for a given function call if no PvD is specified.=C2=A0 In those cases, the system chec= ks for "defaults" at increasingly general levels.=C2= =A0 So a process could set a process default PvD and avoid having to specify the PvD for each an every call, but still make individual socket calls or query DNS on a different PvD whenever it wants to.

Does this make more sense?

 I was thinking on functions like sctp_bindx that explicitly expect multiple IP addresses to be present at a point when the function is called. mpTCP could be even bigger problem because, as I understand it, Linux kernel autonomously decides which local IP addresses to use.

Ah, thank you, that kind of = call is an important consideration.=C2=A0 I believe I have a solution that = will work: when determining the intended PvD in the case of existing APIs t= hat specify source addresses (and/or maybe even interfaces) we should use P= vDs that are uniquely identified by this information.

<= div>What to do if an address does not unique identify a PvD is another matt= er.=C2=A0 For both of these issues I'm hoping to have some discussion i= n Friday's mif meeting.
=C2=A0
P.S. When I'm discussing these issues I'm thinking about genera= l Linux Workstation, like Fedora, and in addition I'm also I'm in terms of network name spaces as the way to implement PvD separation.

=

FWIW, for Android's mif implementation network name= spaces were considered and rejected.=C2=A0 Among other things, I don't = think it's really possible to write an application that can have multip= le sockets with each one "bound" to a different network namespace= .

Instead, it's a bit more like implicit PvDs = are used with one interface belonging to one and only one PvD and each PvD = gets its own routing table.=C2=A0 This model is, obviously, not as general = as mif work is trying to address (i.e. m:n interfaces to PvDs are not suppo= rted). =C2=A0(but it has been sufficient to gain some experience with how a= n API would look and behave)
--001a114424e803784c0523b5c6f1-- From nobody Wed Nov 4 04:43:21 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 2C9931ACC85; Wed, 4 Nov 2015 04:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=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 TT2eyDdg7ya6; Wed, 4 Nov 2015 04:43:17 -0800 (PST) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 4F4C51B2E4E; Wed, 4 Nov 2015 04:43:17 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZtxPG-0001oi-I5 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 04 Nov 2015 13:43:14 +0100 To: "mif-chairs@ietf.org" From: Steven Barth Message-ID: <5639FD5B.5040507@openwrt.org> Date: Wed, 4 Nov 2015 13:43:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: [mif] MIF draft issues 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, 04 Nov 2015 12:43:20 -0000 As requested in the DT meeting, here is a summary of the issues and from my reviews of the 3 "core drafts". To be honest I'm totally put off by the lack of responsiveness from all draft authors and will probably not do any more reviews here if there isn't a significant improvement on this matter. Cheers, Steven *** Conceptual (apply to all 3) *** 1. Lack of metadata Neither draft defines any kind of metadata or seems to consider any addition of it. Currently only opaque identifiers are used which must be previously acquired via other means to understand a PVD, i.e. it is not possible to convey: * if the PVD offers intenet access or not * if use of the PVD is metered or not * general constraints of using the PVD * even a human readable name *** mpvd-id *** It is not clear why this multitude of types is needed. If it is kept there should be some guidance on why it is not possible to simply use one unique type format like FQDN or a reasonably small unique fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD owner followed by a small localy significant ID. 1+3. "Any source that does not provide either guaranteed or probabilistic uniqueness is probably not a good candidate for identifying provisioning domains." - I don't see how type "UTF-8 string" fits this definition. Abstract: the abstract claims the document "describes several methods of generating identification information for provisioning them". However I can't find that anywhere, I can only find a TLV-definition. 3: It is unclear what the actual format for the specified id-types is, at least for some of them, e.g. is the UUID in binary format or string-representation? FQDN is unclear as well, RFC1035 never mentions this abbreviation and also given it would be clear it still doesn't say if it uses the textual or label sequence representation? 4: Security Considerations do not apply at all. Your abstract says: "This document describes several methods of generating identification information for provisioning them and a format for carrying such identification in configuration protocols." however your security considerations explain attacks on (2 specific) protocols the TLV might be used in instead of security implications of using different types of identifiers e.g. like security considerations of UUID in RFC4122 5: IANA Section lacks policy for further allocations (see RFC5226) 3: "The configuration protocol used and its extensions are meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse. *** ndp-support *** 1. It is unclear what to do with enclosed TLVs Section 5 defines what TLVs can and cannot be enclosed, however it is unclear how any enclosed TLVs are treated or whether and in what respect they are treated differently from if they would occur on the top-level. To be more concrete, what should a PVD-aware node do if it receives e.g. a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then use it at will as defined in RFC 4862 ('Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the point of the exercise of the container? Supposedly similar things could be said about RDNSS, DNS-Search or other enclosed PVD types as well. 2. The solicitation mechanism using RS seems underspecified. It is not mentioned how the router should react to receiving a PVD CO / ID (e.g., include PVD-information only in the specific reply, or in all subsequent unsolicited RAs for an undefined period of time, ...). This is unclear esp. considering that hosts do not send RS regularly and the draft does not place an such requirements on hosts. The draft also does. Also it is unclear what the semantic difference between an RS with a PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if there is none, what the reasoning for this redundancy is. 3. Hosts not supporting security cannot use secured PVD information. The length of the fields "Key Hash" and "Digital Signature" depend on the meaning of the field "Name Type" and are thus unskippable in general. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear is your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. However nonces do not seem particularly effective for unsolicited RAs and timestamps rely on accurate wall-clocks on both server and client side which is not mentioned. Also the suggested use of SeND would not provide replay protection for the PVD_CO however only for the whole RA being secured. 7. It is unclear how TLVs are enclosed in the PVD_CO The PVD_CO definition does not mention where TLVs are enclosed, i.e., before or after either Header, Key Hash, Digital Signature, Padding etc. 8. General Design is very space-intensive. Notably for support of both PVD-aware and unaware nodes enclosed TLVs need to occur both inside and outside of the container. Also if some enclosed TLVs apply to multiple PVDs they will be duplicated in different containers. In addition in-band security and signatures can easily increase the size of the overall messages very much, especially since RSA is the only defined scheme. 9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ a provisioning domain." *** dhcp-support *** 0. This draft cannot be freely implemented in open source software. 1. It is unclear what to do with enclosed TLVs The reasoning is similar to the NDP TLVs in the other draft: The draft defines what TLVs can be enclosed but not how the enclosing affects the meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still generally applicable for all purposes and if not how is the meaning changed specifically? This is especially problematic since the draft does not disallow any TLVs from being inside the container, see also 2. 2. It is unclear how this draft interacts with the Identity Association state machines defined in RFC3315 i.e. how are IAs and addresses and prefixes actually enclosed here. The draft needs to specify clearly what happens to identity associations / address assignments and how they are associated to PVDs especially taking into account the possibility of having multiple IAs (e.g. IA_NA and IA_PD) or addresses from different PVDs in the same IA. See also 3. 3. It is unclear where the PVD container option can occur. Is it restricted to only occur on the top-level or can it occur also inside other containers (e.g. Identity Associations), if the latter is true, how does it affect what options can be enclosed in it. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear if your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD container. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. Also the suggested use of DHCPv6 AUTH would not provide replay protection for the PVD container but for the whole DHCPv6 message being secured. 7. Contradicting requirements language #1: "The PVD container option SHOULD contain at most one (i.e. zero or one) OPTION_PVD_AUTH." #2: "If present, the OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD option." #1 implies I could choose to send more than one OPTION_PVD_AUTH (by not following the SOHULD) however #2 implies there can only be 0 or 1. 8. Missing normative reference to RFC 3971 (see Section 5). 9. Client and Server Behavior inconsistent Section 7.1 only instructs client to send an ORO in SOLICIT messages, however in Section 7.3. servers expect it to be sent (only?) in request messages. 10. Security concept seems mostly redundant Since addresses or prefixes are expected to be part of most PVD containers, DHCPv6 servers need to modify PVD containers in nearly all cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options). Therefore - aside for very special cases - the DHCPv6 server would need the private key for signing in any case so plain DHCPv6 authentication could be used in the first place. From nobody Wed Nov 4 06:26:06 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 BA1F01B306E; Wed, 4 Nov 2015 06:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 0lFFXCfOOTE0; Wed, 4 Nov 2015 06:25:59 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4D81B306A; Wed, 4 Nov 2015 06:25:59 -0800 (PST) X-AuditID: c6180641-f792c6d00000686a-e0-5639a805c719 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.0C.26730.508A9365; Wed, 4 Nov 2015 07:39:02 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 09:25:57 -0500 From: Suresh Krishnan To: "mif-chairs@ietf.org" , "cyrus@openwrt.org" Thread-Topic: [mif] MIF draft issues Thread-Index: AQHRFv5nROJZ0uoSVk+SmDFBENDXQZ6L63Rr Date: Wed, 4 Nov 2015 14:25:56 +0000 Message-ID: References: <5639FD5B.5040507@openwrt.org> In-Reply-To: <5639FD5B.5040507@openwrt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF63AA170F5eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonXJdthWWYwaWpfBbnDm9isji1/BmL RdeeG0wOzB5Llvxk8tiyOCOAKYrLJiU1J7MstUjfLoErY3vPAtaClVsZK/YuymhgXDqVsYuR k0NCwETi/boF7BC2mMSFe+vZuhi5OIQEjjBK3N3SygSSEBJYxigxv1cTxGYDatiw8zNYXEQg SuLs9xYwm1lAUWLtn68sILawgLLEtGvH2CBqVCR+rJ4CVW8k8ejQezCbBSi+dvV9sBpeAV+J p+++s0Ds0pJYtHMOWJxTQFviyKPtYMcxAh33/dQaqF3iEreezGeCOFpAYsme88wQtqjEy8f/ WCFq8iV+7P7FCDFfUOLkzCcsExhFZiFpn4WkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZC Fl/AyL6KkaO0OLUsN93IcBMjMI6OSbA57mBc8MnyEKMAB6MSD++GyRZhQqyJZcWVuYcYJTiY lUR4TU9ZhgnxpiRWVqUW5ccXleakFh9ilOZgURLnnTfjfqiQQHpiSWp2ampBahFMlomDU6qB cY3x2gax81mKtyOfMe+/E3P/jvfrB8+OvbI6+CDUMsEl8pTbdYGu3qsPRItf9Ouel9+4U+Tb /B4L5VzR39csMn6Xbt28ukaW2fGp7eNvp676HS3pVPKe8t/Ldlvm/mz2M0EWp1RtFHJm+LZ9 451Sk1d4SO3b+dutF9OvpUn8Za5YHx/A5LrERYmlOCPRUIu5qDgRANr2KZGfAgAA Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] MIF draft issues 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, 04 Nov 2015 14:26:04 -0000 --_000_E87B771635882B4BA20096B589152EF63AA170F5eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steven, Thanks for your review. I will create an issue tracker to keep track of eac= h issue you raised. There are some decisions the WG needs to make to procee= d further with some of the changes required and I hope we can get some dire= ction during and after this Friday's session. Thanks Suresh -----Original Message----- From: Steven Barth [cyrus@openwrt.org] Received: Wednesday, 04 Nov 2015, 9:43PM To: mif-chairs@ietf.org [mif-chairs@ietf.org] CC: mif@ietf.org [mif@ietf.org] Subject: [mif] MIF draft issues As requested in the DT meeting, here is a summary of the issues and from my reviews of the 3 "core drafts". To be honest I'm totally put off by the lack of responsiveness from all draft authors and will probably not do any more reviews here if there isn't a significant improvement on this matter. Cheers, Steven *** Conceptual (apply to all 3) *** 1. Lack of metadata Neither draft defines any kind of metadata or seems to consider any addition of it. Currently only opaque identifiers are used which must be previously acquired via other means to understand a PVD, i.e. it is not possible to convey: * if the PVD offers intenet access or not * if use of the PVD is metered or not * general constraints of using the PVD * even a human readable name *** mpvd-id *** It is not clear why this multitude of types is needed. If it is kept there should be some guidance on why it is not possible to simply use one unique type format like FQDN or a reasonably small unique fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD owner followed by a small localy significant ID. 1+3. "Any source that does not provide either guaranteed or probabilistic uniqueness is probably not a good candidate for identifying provisioning domains." - I don't see how type "UTF-8 string" fits this definition. Abstract: the abstract claims the document "describes several methods of generating identification information for provisioning them". However I can't find that anywhere, I can only find a TLV-definition. 3: It is unclear what the actual format for the specified id-types is, at least for some of them, e.g. is the UUID in binary format or string-representation? FQDN is unclear as well, RFC1035 never mentions this abbreviation and also given it would be clear it still doesn't say if it uses the textual or label sequence representation? 4: Security Considerations do not apply at all. Your abstract says: "This document describes several methods of generating identification information for provisioning them and a format for carrying such identification in configuration protocols." however your security considerations explain attacks on (2 specific) protocols the TLV might be used in instead of security implications of using different types of identifiers e.g. like security considerations of UUID in RFC4122 5: IANA Section lacks policy for further allocations (see RFC5226) 3: "The configuration protocol used and its extensions are meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse. *** ndp-support *** 1. It is unclear what to do with enclosed TLVs Section 5 defines what TLVs can and cannot be enclosed, however it is unclear how any enclosed TLVs are treated or whether and in what respect they are treated differently from if they would occur on the top-level. To be more concrete, what should a PVD-aware node do if it receives e.g. a PIO with A=3D1 inside a PVD_CO? Assign an address, perform DAD and then use it at will as defined in RFC 4862 ('Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the point of the exercise of the container? Supposedly similar things could be said about RDNSS, DNS-Search or other enclosed PVD types as well. 2. The solicitation mechanism using RS seems underspecified. It is not mentioned how the router should react to receiving a PVD CO / ID (e.g., include PVD-information only in the specific reply, or in all subsequent unsolicited RAs for an undefined period of time, ...). This is unclear esp. considering that hosts do not send RS regularly and the draft does not place an such requirements on hosts. The draft also does. Also it is unclear what the semantic difference between an RS with a PVD_ID inside a PVD_CO (with S=3D0) and an RS with a PVD_ID is and if there is none, what the reasoning for this redundancy is. 3. Hosts not supporting security cannot use secured PVD information. The length of the fields "Key Hash" and "Digital Signature" depend on the meaning of the field "Name Type" and are thus unskippable in general. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear is your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. However nonces do not seem particularly effective for unsolicited RAs and timestamps rely on accurate wall-clocks on both server and client side which is not mentioned. Also the suggested use of SeND would not provide replay protection for the PVD_CO however only for the whole RA being secured. 7. It is unclear how TLVs are enclosed in the PVD_CO The PVD_CO definition does not mention where TLVs are enclosed, i.e., before or after either Header, Key Hash, Digital Signature, Padding etc. 8. General Design is very space-intensive. Notably for support of both PVD-aware and unaware nodes enclosed TLVs need to occur both inside and outside of the container. Also if some enclosed TLVs apply to multiple PVDs they will be duplicated in different containers. In addition in-band security and signatures can easily increase the size of the overall messages very much, especially since RSA is the only defined scheme. 9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ a provisioning domain." *** dhcp-support *** 0. This draft cannot be freely implemented in open source software. 1. It is unclear what to do with enclosed TLVs The reasoning is similar to the NDP TLVs in the other draft: The draft defines what TLVs can be enclosed but not how the enclosing affects the meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still generally applicable for all purposes and if not how is the meaning changed specifically? This is especially problematic since the draft does not disallow any TLVs from being inside the container, see also 2. 2. It is unclear how this draft interacts with the Identity Association state machines defined in RFC3315 i.e. how are IAs and addresses and prefixes actually enclosed here. The draft needs to specify clearly what happens to identity associations / address assignments and how they are associated to PVDs especially taking into account the possibility of having multiple IAs (e.g. IA_NA and IA_PD) or addresses from different PVDs in the same IA. See also 3. 3. It is unclear where the PVD container option can occur. Is it restricted to only occur on the top-level or can it occur also inside other containers (e.g. Identity Associations), if the latter is true, how does it affect what options can be enclosed in it. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear if your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD container. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. Also the suggested use of DHCPv6 AUTH would not provide replay protection for the PVD container but for the whole DHCPv6 message being secured. 7. Contradicting requirements language #1: "The PVD container option SHOULD contain at most one (i.e. zero or one) OPTION_PVD_AUTH." #2: "If present, the OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD option." #1 implies I could choose to send more than one OPTION_PVD_AUTH (by not following the SOHULD) however #2 implies there can only be 0 or 1. 8. Missing normative reference to RFC 3971 (see Section 5). 9. Client and Server Behavior inconsistent Section 7.1 only instructs client to send an ORO in SOLICIT messages, however in Section 7.3. servers expect it to be sent (only?) in request messages. 10. Security concept seems mostly redundant Since addresses or prefixes are expected to be part of most PVD containers, DHCPv6 servers need to modify PVD containers in nearly all cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options). Therefore - aside for very special cases - the DHCPv6 server would need the private key for signing in any case so plain DHCPv6 authentication could be used in the first place. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --_000_E87B771635882B4BA20096B589152EF63AA170F5eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Steven,
Thanks for your review. I will create an issue tracker to keep track of eac= h issue you raised. There are some decisions the WG needs to make to procee= d further with some of the changes required and I hope we can get some dire= ction during and after this Friday's session.

Thanks
Suresh

-----Original Message-----
From: Steven Barth [cyrus@openwrt.org]
Received: Wednesday, 04 Nov 2015, 9:43PM
To: mif-chairs@ietf.org [mif-chairs@ietf.org]
CC: mif@ietf.org [mif@ietf.org]
Subject: [mif] MIF draft issues

As requested in the DT meeting, here is a summary = of the issues and from
my reviews of the 3 "core drafts".

To be honest I'm totally put off by the lack of responsiveness from all
draft authors and will probably not do any more reviews here if there
isn't a significant improvement on this matter.


Cheers,

Steven


*** Conceptual (apply to all 3) ***

1. Lack of metadata
Neither draft defines any kind of metadata or seems to consider any
addition of it. Currently only opaque identifiers are used which must be previously acquired via other means to understand a PVD, i.e. it is not
possible to convey:
* if the PVD offers intenet access or not
* if use of the PVD is metered or not
* general constraints of using the PVD
* even a human readable name


*** mpvd-id ***

It is not clear why this multitude of types is needed. If it is kept
there should be some guidance on why it is not possible to simply use
one unique type format like FQDN or a reasonably small unique
fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD
owner followed by a small localy significant ID.

1+3. "Any source that does not provide either guaranteed or
probabilistic uniqueness is probably not a good candidate for
identifying provisioning domains." - I don't see how type "UTF-8 = string"
fits this definition.

Abstract: the abstract claims the document "describes several methods = of
generating identification information for provisioning them". However = I
can't find that anywhere, I can only find a TLV-definition.

3: It is unclear what the actual format for the specified id-types is,
at least for some of them, e.g. is the UUID in binary format or
string-representation? FQDN is unclear as well, RFC1035 never mentions
this abbreviation and also given it would be clear it still doesn't say
if it uses the textual or label sequence representation?

4: Security Considerations do not apply at all. Your abstract says:
"This document describes several methods of generating
identification information for provisioning them and a format for
carrying such identification in configuration protocols."
however your security considerations explain attacks on (2 specific)
protocols the TLV might be used in instead of security implications of
using different types of identifiers e.g. like security considerations
of UUID in RFC4122

5: IANA Section lacks policy for further allocations (see RFC5226)

3: "The configuration protocol used and its extensions are
meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support]
[I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse.



*** ndp-support ***

1. It is unclear what to do with enclosed TLVs

Section 5 defines what TLVs can and cannot be enclosed, however it is
unclear how any enclosed TLVs are treated or whether and in what respect they are treated differently from if they would occur on the top-level.
To be more concrete, what should a PVD-aware node do if it receives e.g. a PIO with A=3D1 inside a PVD_CO? Assign an address, perform DAD and then use it at will as defined in RFC 4862 ('Initially, an address is
"preferred", meaning that its use in arbitrary communication is unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the point of the exercise of the container? Supposedly similar things could
be said about RDNSS, DNS-Search or other enclosed PVD types as well.

2. The solicitation mechanism using RS seems underspecified.

It is not mentioned how the router should react to receiving a PVD CO /
ID (e.g., include PVD-information only in the specific reply, or in all
subsequent unsolicited RAs for an undefined period of time, ...). This
is unclear esp. considering that hosts do not send RS regularly and the
draft does not place an such requirements on hosts. The draft also does.
Also it is unclear what the semantic difference between an RS with a
PVD_ID inside a PVD_CO (with S=3D0) and an RS with a PVD_ID is and if
there is none, what the reasoning for this redundancy is.

3. Hosts not supporting security cannot use secured PVD information.

The length of the fields "Key Hash" and "Digital Signature&q= uot; depend on
the meaning of the field "Name Type" and are thus unskippable in = general.

4. Signature calculation is unclear.

The signature generation defined in RFC 3971 includes several other
components (e.g. a CGA message type tag, a kind of pseudoheader, etc.)
besides the actual NDP message being signed. It is unclear is your
signature mechanism uses the same header fields or if the intention was
just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO.

5. Mandatory to implement security seems outdated.

The use of SHA-1 as only mandatory hash for key identification and as
only defined hash for signatures seems a bit outdated these days
especially in the light of recent advancements in its cryptanalysis.

This seems especially problematic since there does not seem to be a way
to signal the use of a different signature algorithm.

6. Replay Protection seems not adequately addressed.

No specific mechanism is defined. It is suggested to use either
timestamps or a nonce of an undefined format. However nonces do not seem particularly effective for unsolicited RAs and timestamps rely on
accurate wall-clocks on both server and client side which is not mentioned.=
Also the suggested use of SeND would not provide replay protection for
the PVD_CO however only for the whole RA being secured.

7. It is unclear how TLVs are enclosed in the PVD_CO

The PVD_CO definition does not mention where TLVs are enclosed, i.e.,
before or after either Header, Key Hash, Digital Signature, Padding etc.

8. General Design is very space-intensive.

Notably for support of both PVD-aware and unaware nodes enclosed TLVs
need to occur both inside and outside of the container. Also if some
enclosed TLVs apply to multiple PVDs they will be duplicated in
different containers.

In addition in-band security and signatures can easily increase the size of the overall messages very much, especially since RSA is the only
defined scheme.

9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ = a
   provisioning domain."



*** dhcp-support ***

0. This draft cannot be freely implemented in open source software.

1. It is unclear what to do with enclosed TLVs

The reasoning is similar to the NDP TLVs in the other draft: The draft
defines what TLVs can be enclosed but not how the enclosing affects the
meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still
generally applicable for all purposes and if not how is the meaning
changed specifically?

This is especially problematic since the draft does not disallow any
TLVs from being inside the container, see also 2.

2. It is unclear how this draft interacts with the Identity Association
state machines defined in RFC3315

i.e. how are IAs and addresses and prefixes actually enclosed here. The
draft needs to specify clearly what happens to identity associations /
address assignments and how they are associated to PVDs especially
taking into account the possibility of having multiple IAs (e.g. IA_NA
and IA_PD) or addresses from different PVDs in the same IA. See also 3.

3. It is unclear where the PVD container option can occur.

Is it restricted to only occur on the top-level or can it occur also
inside other containers (e.g. Identity Associations), if the latter is
true, how does it affect what options can be enclosed in it.

4. Signature calculation is unclear.

The signature generation defined in RFC 3971 includes several other
components (e.g. a CGA message type tag, a kind of pseudoheader, etc.)
besides the actual NDP message being signed. It is unclear if your
signature mechanism uses the same header fields or if the intention was
just to use a plain RSASSA-PKCS1-v1_5 over the PVD container.

5. Mandatory to implement security seems outdated.

The use of SHA-1 as only mandatory hash for key identification and as
only defined hash for signatures seems a bit outdated these days
especially in the light of recent advancements in its cryptanalysis.

This seems especially problematic since there does not seem to be a way
to signal the use of a different signature algorithm.

6. Replay Protection seems not adequately addressed.

No specific mechanism is defined. It is suggested to use either
timestamps or a nonce of an undefined format.
Also the suggested use of DHCPv6 AUTH would not provide replay
protection for the PVD container but for the whole DHCPv6 message being
secured.

7. Contradicting requirements language
#1: "The PVD container option SHOULD contain at most one (i.e. zero or=
one) OPTION_PVD_AUTH."
#2: "If present, the OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD option."
#1 implies I could choose to send more than one OPTION_PVD_AUTH (by not
following the SOHULD) however #2 implies there can only be 0 or 1.

8. Missing normative reference to RFC 3971 (see Section 5).

9. Client and Server Behavior inconsistent
Section 7.1 only instructs client to send an ORO in SOLICIT messages,
however in Section 7.3. servers expect it to be sent (only?) in request
messages.

10. Security concept seems mostly redundant
Since addresses or prefixes are expected to be part of most PVD
containers, DHCPv6 servers need to modify PVD containers in nearly all
cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options).
Therefore - aside for very special cases - the DHCPv6 server would need
the private key for signing in any case so plain DHCPv6 authentication
could be used in the first place.

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/= mailman/listinfo/mif
 --_000_E87B771635882B4BA20096B589152EF63AA170F5eusaamb107erics_-- From nobody Wed Nov 4 07:45:11 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 982021B31FC for ; Wed, 4 Nov 2015 07:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 vYd9S6hBByYj for ; Wed, 4 Nov 2015 07:45:05 -0800 (PST) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 553291B31F5 for ; Wed, 4 Nov 2015 07:45:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id 2F99D3B7C04C; Wed, 4 Nov 2015 16:44:59 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zULwmkdTwKD2; Wed, 4 Nov 2015 16:44:57 +0100 (CET) Received: from w540.sistemnet.local (93-139-83-90.adsl.net.t-com.hr [93.139.83.90]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 96B1B3B7C047; Wed, 4 Nov 2015 16:44:57 +0100 (CET) To: Erik Kline References: <20151101150337.10435.25207.idtracker@ietfa.amsl.com> <5637306E.40006@fer.hr> <56376171.7060203@fer.hr> From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER Message-ID: <563A27EC.70000@fer.hr> Date: Wed, 4 Nov 2015 16:44:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo" Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] Fwd: New Version Notification for draft-kline-mif-mpvd-api-reqs-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: Wed, 04 Nov 2015 15:45:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo Content-Type: multipart/alternative; boundary="------------040503090709050602040007" This is a multi-part message in MIME format. --------------040503090709050602040007 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04.11.2015 13:01, Erik Kline wrote: > > > On 2 November 2015 at 22:13, Stjepan Gro=C5=A1 > wrote: > > > On 02.11.2015 13:18, Erik Kline wrote: >> >> On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 > > wrote: >> >> Hi Erik, >> >> Thank you for the draft. >> >> I have few comments/questions. >> >> First, what I'm reading from the draft is that each PvD aware >> application should have access to a single PvD at any single >> moment? If that is so, what about mpTCP and SCTP applications >> that are PvD aware? They should have access to multiple PvDs >> simultaneously for a fail over reasons. So, how this draft >> takes into account that use case? >> >> >> Not quite: they should be able to specify only one PvD per >> function call, per thread (for example). An app can have >> multiple sockets, each one using one PvD. An app can have >> something like a single unconnected datagram socket and call >> sendto() with a different PvD for each sendto() call. That kind >> of thing is more what I meant to write, but I guess was not very >> clear. (Clearly, I have a bunch of sockets-y things in my head >> but am trying to write things in a more general, >> non-sockets-dependent way.) >> >> The confusion may be arising in part from the resolution of which >> PvD to use for a given function call if no PvD is specified. In >> those cases, the system checks for "defaults" at increasingly >> general levels. So a process could set a process default PvD and >> avoid having to specify the PvD for each an every call, but still >> make individual socket calls or query DNS on a different PvD >> whenever it wants to. >> >> Does this make more sense? > > I was thinking on functions like sctp_bindx that explicitly expect > multiple IP addresses to be present at a point when the function > is called. mpTCP could be even bigger problem because, as I > understand it, Linux kernel autonomously decides which local IP > addresses to use. > > > Ah, thank you, that kind of call is an important consideration. I > believe I have a solution that will work: when determining the > intended PvD in the case of existing APIs that specify source > addresses (and/or maybe even interfaces) we should use PvDs that are > uniquely identified by this information. You mean like having some separate function which is called before sctp_bindx with the same arguments so that appropriate PvDs can be activated? We were thinking about some kind of a PvD activation function (e.g. pvd_attach_pvd(pvdid *id) and possibly also pvd_detach_pvd) so that application can attach any combination of PvDs it wants to have access to. This, at least to me, seems to be the most flexible solution? > > What to do if an address does not unique identify a PvD is another > matter. For both of these issues I'm hoping to have some discussion > in Friday's mif meeting. > =20 > > P.S. When I'm discussing these issues I'm thinking about general > Linux Workstation, like Fedora, and in addition I'm also I'm in > terms of network name spaces as the way to implement PvD separation= =2E > > > FWIW, for Android's mif implementation network namespaces were > considered and rejected. Among other things, I don't think it's > really possible to write an application that can have multiple sockets > with each one "bound" to a different network namespace. That's interesting. Namely, I wrote a test application that does the following: 1. creates a socket (just calls socket function) in the default namespace= 2. then, it switches to some other namespace using setns. This new namespace doesn't have any connectivity. 3. test application connects to a server and issues HTTP GET request 4. writes response to the stdout In short, this worked which made us conclude that the socket is bound to whatever namespace was active at the time socket was created. Application can switch to other namespaces after that at will, even within a single thread. This means that you can use multiple namespaces from within the single application at will. You have to only take care to activate namespace you need before issuing socket call. Did you try to do something like that? The issue we have though, with respect to namespaces, is that we might end up in a situation in which two namespaces share the same IP address. It is almost equivalent to having two machines on the network with the same IP address. We have some half-baked ideas for solutions for this issue, and nothing that works. > > Instead, it's a bit more like implicit PvDs are used with one > interface belonging to one and only one PvD and each PvD gets its own > routing table. This model is, obviously, not as general as mif work > is trying to address (i.e. m:n interfaces to PvDs are not supported). > (but it has been sufficient to gain some experience with how an API > would look and behave) This probably could work for Android, but this brings up two points when we talk about some general Linux distribution: 1. Is it really necessary to support multiple interfaces with a single PvD instance? And by single PvD instance I mean PvD with the same parameters, i.e. same address on multiple interfaces. In that case it seems to me that bridging is a better approach. 2. How do you intend to control which process uses which interface/PvD? SG --------------040503090709050602040007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 04.11.2015 13:01, Erik Kline wrote:=


On 2 November 2015 at 22:13, Stjepan= Gro=C5=A1 <stj= epan.gros@fer.hr> wrote:
=

On 02.11.2015 13:18, Erik Kline wrote:

On 2 November 2015 at 18:44, Stjepan Gro=C5=A1 <stjepan.gros@fer.hr> wrote:
Hi Erik,

Thank you for the draft.

I have few comments/questions.

First, what I'm reading from the draft is that each PvD aware application should have access to a single PvD at any single moment? If that is so, what about mpTCP and SCTP applications that are PvD aware? They should have access to multiple PvDs simultaneously for a fail over reasons. So, how this draft takes into account that use case?

Not quite: they should be able to specify only one PvD per function call, per thread (for example).=C2=A0 An app can have multiple= sockets, each one using one PvD.=C2=A0 An app= can have something like a single unconnected datagram socket and call sendto() with a different PvD for each sendto() call.=C2=A0 T= hat kind of thing is more what I meant to write, but I guess was not very clear. =C2=A0(Clearl= y, I have a bunch of sockets-y things in my head but am trying to write things in a more general, non-sockets-dependent way.)

The confusion may be arising in part from the resolution of which PvD to use for a given function call if no PvD is specified.=C2= =A0 In those cases, the system checks for "defaults" at increasingly general levels.=C2= =A0 So a process could set a process default PvD and avoid having to specify the PvD for each an every call, but still make individual socket calls or query DNS on a different PvD whenever it wants to.

Does this make more sense?

 I was thinking on functions like sctp_bindx that explicitly expect multiple IP addresses to be present at a point when the function is called. mpTCP could be even bigger problem because, as I understand it, Linux kernel autonomously decides which local IP addresses to use.

Ah, thank you, that kind of call is an important consideration.=C2=A0 I believe I have a solution that will work: when determining the intended PvD in the case of existing APIs that specify source addresses (and/or maybe even interfaces) we should use PvDs that are uniquely identified by this information.

You mean like having some separate function which is called before sctp_bindx with the same arguments so that appropriate PvDs can be activated?

We were thinking about some kind of a PvD activation function (e.g. pvd_attach_pvd(pvdid *id) and possibly also pvd_detach_pvd) so that application can attach any combination of PvDs it wants to have access to. This, at least to me, seems to be the most flexible solution?


What to do if an address does not unique identify a PvD is another matter.=C2=A0 For both of these issues I'm hopin= g to have some discussion in Friday's mif meeting.
=C2=A0
P.S. When I'm discussing these issues I'm thinking about general Linux Workstation, like Fedora, and in addition I'm also I'm in terms of network name spaces as the way to implement PvD separation.


FWIW, for Android's mif implementation network namespaces were considered and rejected.=C2=A0 Among other things, I don't think it's really possible to write an application that can have multiple sockets with each one "bound" to a different network namespace.

That's interesting. Namely, I wrote a test application that does the following:

1. creates a socket (just calls socket function) in the default namespace
2. then, it switches to some other namespace using setns. This new namespace doesn't have any connectivity.
3. test application connects to a server and issues HTTP GET request<= br> 4. writes response to the stdout

In short, this worked which made us conclude that the socket is bound to whatever namespace was active at the time socket was created. Application can switch to other namespaces after that at will, even within a single thread. This means that you can use multiple namespaces from within the single application at will. You have to only take care to activate namespace you need before issuing socket call.

Did you try to do something like that?

The issue we have though, with respect to namespaces, is that we might end up in a situation in which two namespaces share the same IP address. It is almost equivalent to having two machines on the network with the same IP address. We have some half-baked ideas for solutions for this issue, and nothing that works.


Instead, it's a bit more like implicit PvDs are used with one interface belonging to one and only one PvD and each PvD gets its own routing table.=C2=A0 This model is, obviously, not as general as mif work is trying to address (i.e. m:n interfaces to PvDs are not supported). =C2=A0(but= it has been sufficient to gain some experience with how an API would look and behave)

This probably could work for Android, but this brings up two points when we talk about some general Linux distribution:

1. Is it really necessary to support multiple interfaces with a single PvD instance? And by single PvD instance I mean PvD with the same parameters, i.e. same address on multiple interfaces. In that case it seems to me that bridging is a better approach.

2. How do you intend to control which process uses which interface/PvD?

SG

--------------040503090709050602040007-- --vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWOifsAAoJELZD5ReLhUf0/w0IAKj3EEW/ordhZQOhGIX5/mKq B3xFEYdkEtJMaojVw/BUBTfFSb9Gnn8GXtaXcl3fNiV7R8FtIlMs3H97h0StERCB OYgriYiciC8PRPS60MCDhQVYmNVGEYGzyOoTxpt3lETcu3zxAwcBllwqbaYAbBGP +MS9Alh8AVwjDHpcD6qo2S8MzSt32hcJmKQ2AIP1bERLVvQmNpGC5zE7NbgQjxhN PT9a5Wt/UimQypXTgZD4UGC2D0YwaVa6uSVDhlRGxMn7I5LN6kF1jtMx3mQBb/kj 0KmvlSetGsPpUQeoVlUDwuzjgH+NeSB7V0urkI8jpUXHtIbNIMUQf2XiWbkQalU= =4YCb -----END PGP SIGNATURE----- --vFkFWGgvnUbnTSVoid8DaeftSRcq6jXFo-- From iben.rodriguez@gmail.com Thu Nov 5 01:20:29 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 CB6201A8908 for ; Thu, 5 Nov 2015 01:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 clTkrJUSNxn8 for ; Thu, 5 Nov 2015 01:20:26 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 23E221A1A69 for ; Thu, 5 Nov 2015 01:20:25 -0800 (PST) Received: by oifu63 with SMTP id u63so43834380oif.2 for ; Thu, 05 Nov 2015 01:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YROf4FIKgR2aCgaPvnW2QpYp0BF4DJNmTK+ftoC1VwE=; b=tKRdexun42E6lPUBEzOJdYobY20NAh0HRs4YBD5MVzP9PHcN2jdLmzvQFuPPaeDJ8p nrmrW0GojLnTY7467DTk+qJul/WqWOFXH+HYXWiy/mF00TbA/nBQU4ZfJbubEb9KHww4 tGWTjFuXgdOAqWPKQBKf2ZrJuXlNQHzWY3JN65f0pVK+KQXe0NCC8rMPwO3o5dXx8slt shq23CAaAKCHPWVD80bP1FdshF5DybnFXD3OT5vTxdDZFxlKQb1FUfxZmPisn5iG0YFv Kce90gr7q6t06b2/E5DR36KZfLPHpPy/VQG3Uzsy56nvOX9qMu8609hsHzaJCRa6jdVy iqgQ== MIME-Version: 1.0 X-Received: by 10.202.52.5 with SMTP id b5mr3669208oia.120.1446715224607; Thu, 05 Nov 2015 01:20:24 -0800 (PST) Received: by 10.182.43.201 with HTTP; Thu, 5 Nov 2015 01:20:24 -0800 (PST) Date: Thu, 5 Nov 2015 18:20:24 +0900 Message-ID: From: Iben Rodriguez To: mif@ietf.org Content-Type: multipart/alternative; boundary=001a113d56460dd56b0523c7a354 Archived-At: Subject: [mif] OpenWRT enhancements requests for MIF and HomeNet from OPNFV 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, 05 Nov 2015 09:26:07 -0000 --001a113d56460dd56b0523c7a354 Content-Type: text/plain; charset=UTF-8 We are working with OPNFV community to automatically build an open source network test bed with various tests being run on a regular basis as part of a Continuous Integration Pipeline. These tests basically deploy a topology or machines and networks then run some scripts and collect the results uploading them to a centralized dashboard. We currently have over 13 labs some with many pods. Tests being developed cover both functional and performance tests for various use cases and protocols. As a start I figured out how to convert the OpenWRT RAW image from trunk and import it to a vmware hypervisor - we also want to get it working on OpenStack. Please see my wish list here - http://wiki.openwrt.org/doc/howto/vmware - and let me know your thoughts on how best to proceed. Many thanks! I b e n --001a113d56460dd56b0523c7a354 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are working with OPNFV community to automatically = build an open source network test bed with various tests being run on a reg= ular basis as part of a Continuous Integration Pipeline. These tests basica= lly deploy a topology or machines and networks then run some scripts and co= llect the results uploading them to a centralized dashboard. We currently h= ave over 13 labs some with many pods.

Tests being developed co= ver both functional and performance tests for various use cases and protoco= ls.

As a start I figured out how to convert the OpenWRT RAW image from trunk= and import it to a vmware hypervisor - we also want to get it working on O= penStack. Please see my wish list here - http://wiki.openwrt.org/doc/howto/vmware - and let m= e know your thoughts on how best to proceed.

Many thanks!

<= br>I b e n


=

--001a113d56460dd56b0523c7a354-- From nobody Thu Nov 5 12:45:48 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 1559C1A026E; Thu, 5 Nov 2015 12:45:46 -0800 (PST) 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 lsaxJkO31GSA; Thu, 5 Nov 2015 12:45:42 -0800 (PST) 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 484F61A0020; Thu, 5 Nov 2015 12:45:38 -0800 (PST) Received: by pacdm15 with SMTP id dm15so73346600pac.3; Thu, 05 Nov 2015 12:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=ivq4tpLNhZM0cUCcPyyvqtmtmd9ZeiTjO47rLw1prqA=; b=i6L0j7zRN5+xUgPGcd0EJZDqBZ/MNsizXakHu6IICLe7tYg9OFzCyVrA/UUCFRpigR YNQ+Ia1xS7ujrDKXqhwURheJ02ifXc24L6hkx9D7uk53mDjj1VPAYW2N04A3HAFjiYlf rVyUrsOqtn/Q5G2M1WomntYH68TVZDxs6xsQHwXL33ZlDNKwxRpZ86F3Wwa8t8jPxgd7 oVdA+GttYEseYsoGJAAvq/XD68zQfENHRug0DenWQhDE0Am+3Caqs6TYbxDSHTwI/qbb dgEaT9UW+dKCjBrpRkCDujQLFAaKorIaJ7XWO2fnPs2+dqu09+TeM7EfMrLpwovGOKkg 1AzA== X-Received: by 10.67.5.193 with SMTP id co1mr11601936pad.134.1446756337826; Thu, 05 Nov 2015 12:45:37 -0800 (PST) Received: from ?IPv6:2601:647:4204:228b:719d:f15f:ca8e:a8e0? ([2601:647:4204:228b:719d:f15f:ca8e:a8e0]) by smtp.googlemail.com with ESMTPSA id yi8sm9544517pab.22.2015.11.05.12.45.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2015 12:45:37 -0800 (PST) To: Steven Barth , "mif-chairs@ietf.org" References: <5639FD5B.5040507@openwrt.org> From: Jouni Korhonen Message-ID: <563BBFF0.5010907@gmail.com> Date: Thu, 5 Nov 2015 12:45:36 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5639FD5B.5040507@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] MIF draft issues 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, 05 Nov 2015 20:45:46 -0000 Steven, Thanks for the comments. See inline. 11/4/2015, 4:43 AM, Steven Barth kirjoitti: > As requested in the DT meeting, here is a summary of the issues and from > my reviews of the 3 "core drafts". > > To be honest I'm totally put off by the lack of responsiveness from all Huh?? Anyway, I'll be unresponsive till "ndp-support" part of this mail. > draft authors and will probably not do any more reviews here if there > isn't a significant improvement on this matter. > > > Cheers, > > Steven > > > *** Conceptual (apply to all 3) *** > > 1. Lack of metadata > Neither draft defines any kind of metadata or seems to consider any > addition of it. Currently only opaque identifiers are used which must be > previously acquired via other means to understand a PVD, i.e. it is not > possible to convey: > * if the PVD offers intenet access or not > * if use of the PVD is metered or not > * general constraints of using the PVD > * even a human readable name > > > *** mpvd-id *** > > It is not clear why this multitude of types is needed. If it is kept > there should be some guidance on why it is not possible to simply use > one unique type format like FQDN or a reasonably small unique > fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD > owner followed by a small localy significant ID. > > 1+3. "Any source that does not provide either guaranteed or > probabilistic uniqueness is probably not a good candidate for > identifying provisioning domains." - I don't see how type "UTF-8 string" > fits this definition. > > Abstract: the abstract claims the document "describes several methods of > generating identification information for provisioning them". However I > can't find that anywhere, I can only find a TLV-definition. > > 3: It is unclear what the actual format for the specified id-types is, > at least for some of them, e.g. is the UUID in binary format or > string-representation? FQDN is unclear as well, RFC1035 never mentions > this abbreviation and also given it would be clear it still doesn't say > if it uses the textual or label sequence representation? > > 4: Security Considerations do not apply at all. Your abstract says: > "This document describes several methods of generating > identification information for provisioning them and a format for > carrying such identification in configuration protocols." > however your security considerations explain attacks on (2 specific) > protocols the TLV might be used in instead of security implications of > using different types of identifiers e.g. like security considerations > of UUID in RFC4122 > > 5: IANA Section lacks policy for further allocations (see RFC5226) > > 3: "The configuration protocol used and its extensions are > meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support] > [I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse. > > > > *** ndp-support *** > > 1. It is unclear what to do with enclosed TLVs Explain what you mean by TLV in the context of this draft? This word/acronym is not used in the draft. > Section 5 defines what TLVs can and cannot be enclosed, however it is > unclear how any enclosed TLVs are treated or whether and in what respect > they are treated differently from if they would occur on the top-level. > To be more concrete, what should a PVD-aware node do if it receives e.g. > a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then > use it at will as defined in RFC 4862 ('Initially, an address is > "preferred", meaning that its use in arbitrary communication is > unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the > point of the exercise of the container? Supposedly similar things could > be said about RDNSS, DNS-Search or other enclosed PVD types as well. I would advice to read RFC7556 Section 5. This draft mainly concerns the transport of the PVD related configuration information. > > 2. The solicitation mechanism using RS seems underspecified. > > It is not mentioned how the router should react to receiving a PVD CO / > ID (e.g., include PVD-information only in the specific reply, or in all > subsequent unsolicited RAs for an undefined period of time, ...). This > is unclear esp. considering that hosts do not send RS regularly and the .. with IPv6 RA messages. However, if a host wants to solicit information for a specific provisioning domain it can include the PVD identity option into an RS message .. So it is a hint to a router that someone is interested in a specific PVD. I do not think we need to define the implementation details on this part further. The router is free to react to the hint as it wishes. > draft does not place an such requirements on hosts. The draft also does. The draft also does what? > > Also it is unclear what the semantic difference between an RS with a > PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if > there is none, what the reasoning for this redundancy is. ...include the PVD identity option into an RS message and use the PVD container to sign the PVD identity option. So, the difference should be clear. If you want to sign the idenitity -> put it inside PVD_CO with S=1. > > 3. Hosts not supporting security cannot use secured PVD information. > > The length of the fields "Key Hash" and "Digital Signature" depend on > the meaning of the field "Name Type" and are thus unskippable in general. Hmm seems I missed this from previous comments. If one does not understand the used security -> skip the PVD_CO. I'll add this clarification. > 4. Signature calculation is unclear. > > The signature generation defined in RFC 3971 includes several other > components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) > besides the actual NDP message being signed. It is unclear is your > signature mechanism uses the same header fields or if the intention was > just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO. Fair point. I will clarify. > 5. Mandatory to implement security seems outdated. > > The use of SHA-1 as only mandatory hash for key identification and as > only defined hash for signatures seems a bit outdated these days > especially in the light of recent advancements in its cryptanalysis. > > This seems especially problematic since there does not seem to be a way > to signal the use of a different signature algorithm. > > 6. Replay Protection seems not adequately addressed. ... information. This specification does not define a replay protection solution. Rather it is assumed that if replay protection is... > No specific mechanism is defined. It is suggested to use either > timestamps or a nonce of an undefined format. However nonces do not seem > particularly effective for unsolicited RAs and timestamps rely on > accurate wall-clocks on both server and client side which is not mentioned. > Also the suggested use of SeND would not provide replay protection for > the PVD_CO however only for the whole RA being secured. And replay protecting whole RA would be somehow worse than just protecting PVD_CO? > 7. It is unclear how TLVs are enclosed in the PVD_CO TLV? > The PVD_CO definition does not mention where TLVs are enclosed, i.e., > before or after either Header, Key Hash, Digital Signature, Padding etc. The PVD container option (PVD_CO) is used to mark the start of the configuration options that belong to the explicitly identified provisioning domain. The PVD container option MUST encapsulate ... Also, there is no "place" for other NDP options inside PVD_CO. For clarity refer Appendix A. > 8. General Design is very space-intensive. > > Notably for support of both PVD-aware and unaware nodes enclosed TLVs > need to occur both inside and outside of the container. Also if some > enclosed TLVs apply to multiple PVDs they will be duplicated in > different containers. Yes. An unfortunate side effect. > In addition in-band security and signatures can easily increase the size > of the overall messages very much, especially since RSA is the only > defined scheme. Yes. An unfotunate side effect. We are open for more compact solutions. > > 9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ a > provisioning domain." Ack. Will fix. - jouni > > > > *** dhcp-support *** > > 0. This draft cannot be freely implemented in open source software. > > 1. It is unclear what to do with enclosed TLVs > > The reasoning is similar to the NDP TLVs in the other draft: The draft > defines what TLVs can be enclosed but not how the enclosing affects the > meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still > generally applicable for all purposes and if not how is the meaning > changed specifically? > > This is especially problematic since the draft does not disallow any > TLVs from being inside the container, see also 2. > > 2. It is unclear how this draft interacts with the Identity Association > state machines defined in RFC3315 > > i.e. how are IAs and addresses and prefixes actually enclosed here. The > draft needs to specify clearly what happens to identity associations / > address assignments and how they are associated to PVDs especially > taking into account the possibility of having multiple IAs (e.g. IA_NA > and IA_PD) or addresses from different PVDs in the same IA. See also 3. > > 3. It is unclear where the PVD container option can occur. > > Is it restricted to only occur on the top-level or can it occur also > inside other containers (e.g. Identity Associations), if the latter is > true, how does it affect what options can be enclosed in it. > > 4. Signature calculation is unclear. > > The signature generation defined in RFC 3971 includes several other > components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) > besides the actual NDP message being signed. It is unclear if your > signature mechanism uses the same header fields or if the intention was > just to use a plain RSASSA-PKCS1-v1_5 over the PVD container. > > 5. Mandatory to implement security seems outdated. > > The use of SHA-1 as only mandatory hash for key identification and as > only defined hash for signatures seems a bit outdated these days > especially in the light of recent advancements in its cryptanalysis. > > This seems especially problematic since there does not seem to be a way > to signal the use of a different signature algorithm. > > 6. Replay Protection seems not adequately addressed. > > No specific mechanism is defined. It is suggested to use either > timestamps or a nonce of an undefined format. > Also the suggested use of DHCPv6 AUTH would not provide replay > protection for the PVD container but for the whole DHCPv6 message being > secured. > > 7. Contradicting requirements language > #1: "The PVD container option SHOULD contain at most one (i.e. zero or > one) OPTION_PVD_AUTH." > #2: "If present, the OPTION_PVD_AUTH option MUST be the last option > inside the OPTION_PVD option." > #1 implies I could choose to send more than one OPTION_PVD_AUTH (by not > following the SOHULD) however #2 implies there can only be 0 or 1. > > 8. Missing normative reference to RFC 3971 (see Section 5). > > 9. Client and Server Behavior inconsistent > Section 7.1 only instructs client to send an ORO in SOLICIT messages, > however in Section 7.3. servers expect it to be sent (only?) in request > messages. > > 10. Security concept seems mostly redundant > Since addresses or prefixes are expected to be part of most PVD > containers, DHCPv6 servers need to modify PVD containers in nearly all > cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options). > Therefore - aside for very special cases - the DHCPv6 server would need > the private key for signing in any case so plain DHCPv6 authentication > could be used in the first place. > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Thu Nov 5 14:18:30 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 AC4D31B3C61; Thu, 5 Nov 2015 14:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=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 mDXFoxmt0a4y; Thu, 5 Nov 2015 14:18:27 -0800 (PST) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 822FA1B3C64; Thu, 5 Nov 2015 14:18:16 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZuSrF-0006bs-4V with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 05 Nov 2015 23:18:13 +0100 To: Jouni Korhonen , "mif-chairs@ietf.org" References: <5639FD5B.5040507@openwrt.org> <563BBFF0.5010907@gmail.com> From: Steven Barth Message-ID: <563BD59E.6010101@openwrt.org> Date: Thu, 5 Nov 2015 23:18:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0 MIME-Version: 1.0 In-Reply-To: <563BBFF0.5010907@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] MIF draft issues 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, 05 Nov 2015 22:18:29 -0000 >> *** ndp-support *** >> >> 1. It is unclear what to do with enclosed TLVs > > Explain what you mean by TLV in the context of this draft? This > word/acronym is not used in the draft. Well, ICMPv6 option. > >> Section 5 defines what TLVs can and cannot be enclosed, however it >> is unclear how any enclosed TLVs are treated or whether and in what >> respect they are treated differently from if they would occur on >> the top-level. To be more concrete, what should a PVD-aware node do >> if it receives e.g. a PIO with A=1 inside a PVD_CO? Assign an >> address, perform DAD and then use it at will as defined in RFC 4862 >> ('Initially, an address is "preferred", meaning that its use in >> arbitrary communication is unrestricted.'). If all PVD SLAAC >> addresses are unrestricted what is the point of the exercise of the >> container? Supposedly similar things could be said about RDNSS, >> DNS-Search or other enclosed PVD types as well. > > I would advice to read RFC7556 Section 5. This draft mainly concerns > the transport of the PVD related configuration information. I know that RFC. It is mentioned once in the intro of your draft, but that doesn't really help here. Anyway even if there would be a proper reference to Section 5 here: I guess your intention is that all the TLVs inside the container only "apply" to that PVD for some obscure definition of apply. As someone who has implemented one or two RFCs, I think that is much too vague to result in anything remotely interoperable. Let's simply say I get a RFC 4191 RIO. Now quoting that RFC "Then as the host processes Route Information Options in the Router Advertisement message body, it updates its routing table for each such option." Now what happens if that thing is in a PVD_CO? I still update my routing table? I suddenly need one routing table per PVD? (Note RFC 7556 doesn't explain routing anywhere). The same is true for most RA options that could possibly be enclosed. > >> >> 2. The solicitation mechanism using RS seems underspecified. >> >> It is not mentioned how the router should react to receiving a PVD >> CO / ID (e.g., include PVD-information only in the specific reply, >> or in all subsequent unsolicited RAs for an undefined period of >> time, ...). This is unclear esp. considering that hosts do not send >> RS regularly and the > > .. with IPv6 RA messages. However, if a host wants to solicit > information for a specific provisioning domain it can include the > PVD identity option into an RS message .. > > So it is a hint to a router that someone is interested in a specific > PVD. I do not think we need to define the implementation details on > this part further. The router is free to react to the hint as it > wishes. Okay, so as a host I can send an RS with PVD IDs in it, but since it is unspecified I do not know if or how the router would react. Your draft also doesn't mandate for hosts when or when not to solicit other than "when it wants" so the router can make no assumptions as well. So since there is no defined state machine or similar this "mechanism" is there to... provide un-interoperability? I mean clearly since there are no requirements here I can only use that if I control both the router and the client, e.g. for piggibagging obscure proprietary behavior into it. >> Also it is unclear what the semantic difference between an RS with >> a PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and >> if there is none, what the reasoning for this redundancy is. > > ...include the PVD identity option into an RS message and use the PVD > container to sign the PVD identity option. > > So, the difference should be clear. If you want to sign the idenitity > -> put it inside PVD_CO with S=1. Please reread my paragraph above, it is unclear what the difference is between a top-level PVD_ID and a PVD_CO with S=0 so an unsigned container in an RS and / or why both seem to be allowed. >> 3. Hosts not supporting security cannot use secured PVD >> information. >> >> The length of the fields "Key Hash" and "Digital Signature" depend >> on the meaning of the field "Name Type" and are thus unskippable in >> general. > > Hmm seems I missed this from previous comments. If one does not > understand the used security -> skip the PVD_CO. I'll add this > clarification. Okay, so the intention is basically that if the router signs a PVD_CO, hosts that do not support authentication cannot use the PVD information even if they don't care about the signature. I do not particularly like that, but if that was your intention please write it out in the draft. >> 6. Replay Protection seems not adequately addressed. > > ... information. This specification does not define a replay > protection solution. Rather it is assumed that if replay protection > is... > >> No specific mechanism is defined. It is suggested to use either >> timestamps or a nonce of an undefined format. However nonces do not >> seem particularly effective for unsolicited RAs and timestamps rely >> on accurate wall-clocks on both server and client side which is not >> mentioned. Also the suggested use of SeND would not provide replay >> protection for the PVD_CO however only for the whole RA being >> secured. > > And replay protecting whole RA would be somehow worse than just > protecting PVD_CO? Well the scope is different, what it tells me is that the RA wasn't replayed. However the one authenticating the RA could have "sniffed" a foreign PVD container somewhere and just inserted it into its RA. The result is, you have a known-unreplayed RA from person A with a replayed PVD_CO of person B. >> 7. It is unclear how TLVs are enclosed in the PVD_CO > > TLV? I apologize, ICMPv6 options... > >> The PVD_CO definition does not mention where TLVs are enclosed, >> i.e., before or after either Header, Key Hash, Digital Signature, >> Padding etc. > > The PVD container option (PVD_CO) is used to mark the start of the > configuration options that belong to the explicitly identified > provisioning domain. The PVD container option MUST encapsulate ... Okay so if it "marks the start" then the intention is all options are put on the top-level? But how does that "encapsulate options?" My main problem is that your PVD_CO seems to be defined as a "closed" option (in the diagram, which seems to be the source for the on-the-wire-encoding) without any variable length fields anywhere so it is unknown where and how someone could "encapsulate" options into it, which btw. should be explained somewhere what you mean by that term exactly. > Also, there is no "place" for other NDP options inside PVD_CO. For > clarity refer Appendix A. >From the example in your Appendix it seems to be that there is an undefined variable field at the end of your PVD_CO where options are just dumped in. If that is the intention, then please specify that. > >> 8. General Design is very space-intensive. >> >> Notably for support of both PVD-aware and unaware nodes enclosed >> TLVs need to occur both inside and outside of the container. Also >> if some enclosed TLVs apply to multiple PVDs they will be >> duplicated in different containers. > > Yes. An unfortunate side effect. I guess this should be noted in an Applicability section. >> In addition in-band security and signatures can easily increase the >> size of the overall messages very much, especially since RSA is the >> only defined scheme. > > Yes. An unfotunate side effect. We are open for more compact > solutions. Well obvious choices are e.g. to use EdDSA. Also there should be an applicability section somewhere that deals with this. Say I have 2 different authenticated PVDs that are secured with a 4096-bit RSA key and want to use SeND on top of that (or 3 PVD_COs with SeND) then even the PVD_CO "headers" might exceed my MTU. Guidance on how to avoid that is missing. From nobody Thu Nov 5 14:32:50 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 370681B3C8E; Thu, 5 Nov 2015 14:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=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 1RnVzuy5IyNf; Thu, 5 Nov 2015 14:32:47 -0800 (PST) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 02A371B3C9A; Thu, 5 Nov 2015 14:32:36 -0800 (PST) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZuT57-0006xa-UA with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 05 Nov 2015 23:32:34 +0100 From: Steven Barth To: Jouni Korhonen , "mif-chairs@ietf.org" References: <5639FD5B.5040507@openwrt.org> <563BBFF0.5010907@gmail.com> Message-ID: <563BD8FC.10002@openwrt.org> Date: Thu, 5 Nov 2015 23:32:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0 MIME-Version: 1.0 In-Reply-To: <563BBFF0.5010907@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] MIF draft issues 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, 05 Nov 2015 22:32:49 -0000 Sorry resending, message got garbled. On 05.11.2015 21:45, Jouni Korhonen wrote: >> *** ndp-support *** >> 1. It is unclear what to do with enclosed TLVs > > Explain what you mean by TLV in the context of this draft? This > word/acronym is not used in the draft. Well, ICMPv6 option. > >> Section 5 defines what TLVs can and cannot be enclosed, however it is >> unclear how any enclosed TLVs are treated or whether and in what respect >> they are treated differently from if they would occur on the top-level. >> To be more concrete, what should a PVD-aware node do if it receives e.g. >> a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then >> use it at will as defined in RFC 4862 ('Initially, an address is >> "preferred", meaning that its use in arbitrary communication is >> unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the >> point of the exercise of the container? Supposedly similar things could >> be said about RDNSS, DNS-Search or other enclosed PVD types as well. > > I would advice to read RFC7556 Section 5. This draft mainly concerns > the transport of the PVD related configuration information. I know that RFC. It is mentioned once in the intro of your draft, but that doesn't really help here. Anyway even if there would be a proper reference to Section 5 here: I guess your intention is that all the TLVs inside the container only "apply" to that PVD for some obscure definition of apply. As someone who has implemented one or two RFCs, I think that is much too vague to result in anything remotely interoperable. Let's simply say I get a RFC 4191 RIO. Now quoting that RFC "Then as the host processes Route Information Options in the Router Advertisement message body, it updates its routing table for each such option." Now what happens if that thing is in a PVD_CO? I still update my routing table? I suddenly need one routing table per PVD? (Note RFC 7556 doesn't explain routing anywhere). The same is true for most RA options that could possibly be enclosed. > >> >> 2. The solicitation mechanism using RS seems underspecified. >> >> It is not mentioned how the router should react to receiving a PVD CO / >> ID (e.g., include PVD-information only in the specific reply, or in all >> subsequent unsolicited RAs for an undefined period of time, ...). This >> is unclear esp. considering that hosts do not send RS regularly and the > > .. > with IPv6 RA messages. However, if a host wants to solicit > information for a specific provisioning domain it can include the PVD > identity option into an RS message .. > > So it is a hint to a router that someone is interested in a specific > PVD. I do not think we need to define the implementation details on > this part further. The router is free to react to the hint as it wishes. So since there is no defined state machine or similar this "mechanism" is there to... provide un-interoperability? I mean clearly since there are no requirements here I can only use that if I control both the router and the client, e.g. for piggibagging obscure proprietary behavior into it. > >> Also it is unclear what the semantic difference between an RS with a >> PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if >> there is none, what the reasoning for this redundancy is. > > ...include the PVD > identity option into an RS message and use the PVD container to sign > the PVD identity option. > > So, the difference should be clear. If you want to sign the idenitity > -> put it inside PVD_CO with S=1. > Please reread my paragraph above, it is unclear what the difference is between a top-level PVD_ID and a PVD_CO with S=0 so an unsigned container in an RS and / or why both seem to be allowed. >> >> 3. Hosts not supporting security cannot use secured PVD information. >> >> The length of the fields "Key Hash" and "Digital Signature" depend on >> the meaning of the field "Name Type" and are thus unskippable in >> general. > > Hmm seems I missed this from previous comments. If one does not > understand the used security -> skip the PVD_CO. I'll add this > clarification. Okay, so the intention is basically that if the router signs a PVD_CO, hosts that do not support authentication cannot use the PVD information even if they don't care about the signature. I do not particularly like that, but if that was your intention please write it out in the draft. > >> >> 6. Replay Protection seems not adequately addressed. > > ... > information. This specification does not define a replay protection > solution. Rather it is assumed that if replay protection is... Well, what's the point of specifying this authentication then if you leave it open to attacks? > >> No specific mechanism is defined. It is suggested to use either >> timestamps or a nonce of an undefined format. However nonces do not seem >> particularly effective for unsolicited RAs and timestamps rely on >> accurate wall-clocks on both server and client side which is not >> mentioned. >> Also the suggested use of SeND would not provide replay protection for >> the PVD_CO however only for the whole RA being secured. > > And replay protecting whole RA would be somehow worse than just > protecting PVD_CO? Well the scope is different, what it tells me is that the RA wasn't replayed. However the one authenticating the RA could have "sniffed" a foreign PVD container somewhere and just inserted it into its RA. The result is, you have a known-unreplayed RA from person A with a replayed PVD_CO of person B. > >> 7. It is unclear how TLVs are enclosed in the PVD_CO > > TLV? ICMPv6 option > >> The PVD_CO definition does not mention where TLVs are enclosed, i.e., >> before or after either Header, Key Hash, Digital Signature, Padding etc. > > The PVD container option (PVD_CO) is used to mark the start of the > configuration options that belong to the explicitly identified > provisioning domain. The PVD container option MUST encapsulate > ... Okay so if it "marks the start" then the intention is all options are put on the top-level? But how does that "encapsulate options?" My main problem is that your PVD_CO seems to be defined as a "closed" option (in the diagram, which seems to be the source for the on-the-wire-encoding) without any variable length fields anywhere so it is unknown where and how someone could "encapsulate" options into it, which btw. should be explained somewhere what you mean by that term exactly. > > Also, there is no "place" for other NDP options inside PVD_CO. For > clarity refer Appendix A. > >From the example in your Appendix it seems to be that there is an undefined variable field at the end of your PVD_CO where options are just dumped in. If that is the intention, then please specify that. >> 8. General Design is very space-intensive. >> >> Notably for support of both PVD-aware and unaware nodes enclosed TLVs >> need to occur both inside and outside of the container. Also if some >> enclosed TLVs apply to multiple PVDs they will be duplicated in >> different containers. > > Yes. An unfortunate side effect. > I guess this should be noted in an Applicability section. >> In addition in-band security and signatures can easily increase the size >> of the overall messages very much, especially since RSA is the only >> defined scheme. > > Yes. An unfotunate side effect. We are open for more compact solutions. > Well obvious choices are e.g. to use EdDSA. Also there should be an applicability section somewhere that deals with this. Say I have 2 different authenticated PVDs that are secured with a 4096-bit RSA key and want to use SeND on top of that (or 3 PVD_COs with SeND) then even the PVD_CO "headers" might exceed my MTU. Guidance on how to avoid that is missing. From nobody Thu Nov 5 17:08:40 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 BB4C91A8A78 for ; Thu, 5 Nov 2015 17:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 1hicMNrf91nS for ; Thu, 5 Nov 2015 17:08:37 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.232]) by ietfa.amsl.com (Postfix) with ESMTP id 5717C1A8A23 for ; Thu, 5 Nov 2015 17:08:37 -0800 (PST) Received: from [192.168.43.129] (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5613C7B100BA599F; Fri, 6 Nov 2015 03:07:24 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Markus Stenberg In-Reply-To: <28FFBD43-EEBC-4C65-8BA3-CE2E93A9DB2C@apple.com> Date: Fri, 6 Nov 2015 10:08:26 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <924CA6D7-04C3-4CE3-BD88-C075BD42CA45@iki.fi> 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> <6178F689-9321-41AD-B9AA-550C8A12FF05@gmail.com> <28FFBD43-EEBC-4C65-8BA3-CE2E93A9DB2C@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.2104) 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: Fri, 06 Nov 2015 01:08:39 -0000 =46rom my point of view, main thing about the id should be to = distinguish between PVDs _already stored_ on the host. Therefore, it is = mostly a question of likeliness of conflict. I would phrase it somehow = (sorry, no wordsmith) as highly unlikely to collide 64 bit octet blob. = ULAs assume that 40 bits is enough for low collision chance on network = scale, so 64 should be plenty. That id could then map to bunch of actual PVD data. I would _personally_ = recommend id to be hash of that PVD data (actual algorithm local choice = as it should not be visble to the hosts nor their users). Some = subsections of PVD data might have to be defined to be not part of hash, = e.g. lifetimes if they change frequently. Cheers, -Markus= From nobody Tue Nov 17 09:53:25 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 D041D1B2CDB; Tue, 17 Nov 2015 09:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ZDOjXnTW9zFG; Tue, 17 Nov 2015 09:53:22 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 798D11B2C99; Tue, 17 Nov 2015 09:53:22 -0800 (PST) Received: by padhx2 with SMTP id hx2so15401514pad.1; Tue, 17 Nov 2015 09:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=wFucCgLVg7VDaMg330JwPFoOssQXIBi7se4LELfn9XQ=; b=ire+qYqKlr0gqNfups7dt/K/CynEIhUeduxot5xMQMEu9EfRfqU6iA+0IVKpROil// 4GHypteSH8TllG48e713j1gBhBKhqJM9utBAY776zoHNbOB4lSdcn7t+cBEpAmGD6Bgn vdSAFYRFHaDhQc5BsDQcBrjpLXnBv9Uj6eqiENzhxH1+F7kEgsaHRXjA9L5QxZwwsKqv 5NvE96g8ZiVae68n+fQclr7cLeMVa49nA5RNHrmuqAF+XK2YyvgnInaher4fuTZLkHKE 9B8OCiKLFTasqEQ3Otp+G6OYNye6L/hSYd0Ghe1pxOfNRxvJV8bbNCNoLfu8lzA0b2X4 TDcg== X-Received: by 10.67.4.38 with SMTP id cb6mr64897181pad.34.1447782802029; Tue, 17 Nov 2015 09:53:22 -0800 (PST) Received: from [172.19.11.45] ([129.210.115.37]) by smtp.googlemail.com with ESMTPSA id ns1sm44114925pbc.67.2015.11.17.09.53.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Nov 2015 09:53:21 -0800 (PST) To: Steven Barth , "mif-chairs@ietf.org" References: <5639FD5B.5040507@openwrt.org> <563BBFF0.5010907@gmail.com> <563BD8FC.10002@openwrt.org> From: Jouni Korhonen Message-ID: <564B6990.7090007@gmail.com> Date: Tue, 17 Nov 2015 09:53:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563BD8FC.10002@openwrt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mif@ietf.org" Subject: Re: [mif] MIF draft issues 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, 17 Nov 2015 17:53:25 -0000 Thanks for resending - that was needed ;) I have finally ended my marathon travels and will get back to these comments asap. - Jouni 11/5/2015, 2:32 PM, Steven Barth kirjoitti: > Sorry resending, message got garbled. > > > On 05.11.2015 21:45, Jouni Korhonen wrote: > >>> *** ndp-support *** >>> 1. It is unclear what to do with enclosed TLVs >> >> Explain what you mean by TLV in the context of this draft? This >> word/acronym is not used in the draft. > > Well, ICMPv6 option. > > > >> >>> Section 5 defines what TLVs can and cannot be enclosed, however it is >>> unclear how any enclosed TLVs are treated or whether and in what respect >>> they are treated differently from if they would occur on the top-level. >>> To be more concrete, what should a PVD-aware node do if it receives e.g. >>> a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then >>> use it at will as defined in RFC 4862 ('Initially, an address is >>> "preferred", meaning that its use in arbitrary communication is >>> unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the >>> point of the exercise of the container? Supposedly similar things could >>> be said about RDNSS, DNS-Search or other enclosed PVD types as well. >> >> I would advice to read RFC7556 Section 5. This draft mainly concerns >> the transport of the PVD related configuration information. > > I know that RFC. It is mentioned once in the intro of your draft, but that > doesn't really help here. Anyway even if there would be a proper > reference to Section 5 here: I guess your intention is that all the TLVs > inside the container only "apply" to that PVD for some obscure definition > of apply. As someone who has implemented one or two RFCs, I think that > is much too vague to result in anything remotely interoperable. > > Let's simply say I get a RFC 4191 RIO. Now quoting that RFC > "Then as the host processes Route Information Options in the Router > Advertisement message body, it updates its routing table for each such > option." > > Now what happens if that thing is in a PVD_CO? I still update my routing > table? I suddenly need one routing table per PVD? (Note RFC 7556 > doesn't explain routing anywhere). > > The same is true for most RA options that could possibly be enclosed. > > > >> >>> >>> 2. The solicitation mechanism using RS seems underspecified. >>> >>> It is not mentioned how the router should react to receiving a PVD CO / >>> ID (e.g., include PVD-information only in the specific reply, or in all >>> subsequent unsolicited RAs for an undefined period of time, ...). This >>> is unclear esp. considering that hosts do not send RS regularly and the >> >> .. >> with IPv6 RA messages. However, if a host wants to solicit >> information for a specific provisioning domain it can include the PVD >> identity option into an RS message .. >> >> So it is a hint to a router that someone is interested in a specific >> PVD. I do not think we need to define the implementation details on >> this part further. The router is free to react to the hint as it wishes. > > So since there is no defined state machine or similar this "mechanism" > is there to... provide un-interoperability? I mean clearly since there are > no requirements here I can only use that if I control both the router > and the client, e.g. for piggibagging obscure proprietary behavior into it. > > >> >>> Also it is unclear what the semantic difference between an RS with a >>> PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if >>> there is none, what the reasoning for this redundancy is. >> >> ...include the PVD >> identity option into an RS message and use the PVD container to sign >> the PVD identity option. >> >> So, the difference should be clear. If you want to sign the idenitity >> -> put it inside PVD_CO with S=1. >> > > Please reread my paragraph above, it is unclear what the difference is > between a top-level PVD_ID and a PVD_CO with S=0 so an unsigned > container in an RS and / or why both seem to be allowed. > > >>> >>> 3. Hosts not supporting security cannot use secured PVD information. >>> >>> The length of the fields "Key Hash" and "Digital Signature" depend on >>> the meaning of the field "Name Type" and are thus unskippable in >>> general. >> >> Hmm seems I missed this from previous comments. If one does not >> understand the used security -> skip the PVD_CO. I'll add this >> clarification. > > Okay, so the intention is basically that if the router signs a PVD_CO, > hosts that do not support authentication cannot use the PVD > information even if they don't care about the signature. > > I do not particularly like that, but if that was your intention please > write it out in the draft. > > > >> >>> >>> 6. Replay Protection seems not adequately addressed. >> >> ... >> information. This specification does not define a replay protection >> solution. Rather it is assumed that if replay protection is... > Well, what's the point of specifying this authentication then if you > leave it open to attacks? > >> >>> No specific mechanism is defined. It is suggested to use either >>> timestamps or a nonce of an undefined format. However nonces do not seem >>> particularly effective for unsolicited RAs and timestamps rely on >>> accurate wall-clocks on both server and client side which is not >>> mentioned. >>> Also the suggested use of SeND would not provide replay protection for >>> the PVD_CO however only for the whole RA being secured. >> >> And replay protecting whole RA would be somehow worse than just >> protecting PVD_CO? > > Well the scope is different, what it tells me is that the RA wasn't > replayed. However the one authenticating the RA could have "sniffed" > a foreign PVD container somewhere and just inserted it into its RA. > The result is, you have a known-unreplayed RA from person A with a > replayed PVD_CO of person B. > > > >> >>> 7. It is unclear how TLVs are enclosed in the PVD_CO >> >> TLV? > ICMPv6 option >> >>> The PVD_CO definition does not mention where TLVs are enclosed, i.e., >>> before or after either Header, Key Hash, Digital Signature, Padding etc. >> >> The PVD container option (PVD_CO) is used to mark the start of the >> configuration options that belong to the explicitly identified >> provisioning domain. The PVD container option MUST encapsulate >> ... > > Okay so if it "marks the start" then the intention is all options are put > on the top-level? But how does that "encapsulate options?" > My main problem is that your PVD_CO seems to be defined as a > "closed" option (in the diagram, which seems to be the source for the > on-the-wire-encoding) without any variable length fields anywhere so > it is unknown where and how someone could "encapsulate" options > into it, which btw. should be explained somewhere what you mean > by that term exactly. > > > >> >> Also, there is no "place" for other NDP options inside PVD_CO. For >> clarity refer Appendix A. >> > > From the example in your Appendix it seems to be that there is an > undefined variable field at the end of your PVD_CO where options > are just dumped in. If that is the intention, then please specify that. > > > >>> 8. General Design is very space-intensive. >>> >>> Notably for support of both PVD-aware and unaware nodes enclosed TLVs >>> need to occur both inside and outside of the container. Also if some >>> enclosed TLVs apply to multiple PVDs they will be duplicated in >>> different containers. >> >> Yes. An unfortunate side effect. >> > > I guess this should be noted in an > Applicability section. > > >>> In addition in-band security and signatures can easily increase the size >>> of the overall messages very much, especially since RSA is the only >>> defined scheme. >> >> Yes. An unfotunate side effect. We are open for more compact solutions. >> > > Well obvious choices are e.g. to use EdDSA. > > Also there should be an applicability section somewhere that deals with > this. Say I have 2 different authenticated PVDs that are secured > with a 4096-bit RSA key and want to use SeND on top of that (or 3 > PVD_COs with SeND) then even the PVD_CO "headers" might exceed > my MTU. Guidance on how to avoid that is missing. > > From nobody Sat Nov 21 16:40:50 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 BF10E1B2F57 for ; Sat, 21 Nov 2015 16:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 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, RP_MATCHES_RCVD=-0.585, 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 FB3xpFXHbJ2g for ; Sat, 21 Nov 2015 16:40:45 -0800 (PST) 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 5AE1A1B2F58 for ; Sat, 21 Nov 2015 16:40:45 -0800 (PST) Received: from COL125-W44 ([65.55.34.71]) by COL004-OMC2S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 21 Nov 2015 16:40:45 -0800 X-TMN: [A43l+y2rlej/F0N/OdNrS7mjIcWikeKBopvyYpsexLA=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bcab6a36-3d51-433d-8111-54b3177e2c98_" From: Hui Deng To: "mif@ietf.org" , Margaret Cullen Date: Sun, 22 Nov 2015 08:40:44 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2015 00:40:45.0069 (UTC) FILETIME=[6C5A2BD0:01D124BE] Archived-At: Subject: [mif] IETF 94th MIF 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: Sun, 22 Nov 2015 00:40:48 -0000 --_bcab6a36-3d51-433d-8111-54b3177e2c98_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQogDQpBcHByZWNpYXRlIElhbiBGYXJyZXIgYW5kIFRlZCBMZW1vbiBraW5kbHkg aGVscCBmb3IgbWludXRlcw0KQWxzbyBNaWthZWwgQWJyYWhhbXNzb24gZm9yIEphYmJlcg0KIA0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvbWludXRlcy9taW51dGVzLTk0LW1p ZiANCiANClBsZWFzZSBmZWVsIGZyZWUgdG8gbGV0IGNoYWlycyBrbm93IHdoZXRoZXIgeW91IGhh dmUgc29tZSByZXZpc2lvbg0KIA0KdGhhbmtzIGEgbG90DQogDQpERU5HIEh1aQ0KIAkJIAkgICAJ CSAg --_bcab6a36-3d51-433d-8111-54b3177e2c98_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5BcHByZWNpYXRl IElhbiBGYXJyZXIgYW5kJm5ic3A7VGVkIExlbW9uIGtpbmRseSBoZWxwIGZvciBtaW51dGVzPEJS PkFsc28gTWlrYWVsIEFicmFoYW1zc29uIGZvciBKYWJiZXI8QlI+Jm5ic3A7PEJSPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L21pbnV0ZXMvbWludXRlcy05NC1t aWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L21pbnV0ZXMvbWludXRlcy05 NC1taWY8L2E+Jm5ic3A7PEJSPiZuYnNwOzxCUj5QbGVhc2UgZmVlbCBmcmVlIHRvIGxldCBjaGFp cnMga25vdyB3aGV0aGVyIHlvdSBoYXZlIHNvbWUgcmV2aXNpb248QlI+Jm5ic3A7PEJSPnRoYW5r cyBhIGxvdDxCUj4mbmJzcDs8QlI+REVORyBIdWk8QlI+IAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5 Pg0KPC9odG1sPg== --_bcab6a36-3d51-433d-8111-54b3177e2c98_-- From nobody Sun Nov 22 02:06:38 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 2403A1B2CEC for ; Sun, 22 Nov 2015 02:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 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, RP_MATCHES_RCVD=-0.585, 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 xKAD7vuvCW7l for ; Sun, 22 Nov 2015 02:06:33 -0800 (PST) Received: from COL004-OMC2S10.hotmail.com (col004-omc2s10.hotmail.com [65.55.34.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2D01B2CF6 for ; Sun, 22 Nov 2015 02:06:33 -0800 (PST) Received: from COL125-W3 ([65.55.34.73]) by COL004-OMC2S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 22 Nov 2015 02:06:33 -0800 X-TMN: [ZUi2lIXr1FMIBxRL7CnZ3lQHzNe71y0jaIVrt3McK9U=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_67029f82-f100-40c5-a011-6603a8164cce_" From: Hui Deng To: "mif@ietf.org" , Margaret Cullen Date: Sun, 22 Nov 2015 18:06:33 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2015 10:06:33.0236 (UTC) FILETIME=[77095D40:01D1250D] Archived-At: Subject: [mif] Consensus to drop MIF mpvd dhcp document 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: Sun, 22 Nov 2015 10:06:37 -0000 --_67029f82-f100-40c5-a011-6603a8164cce_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsDQoNCkR1cmluZyBJRVRGIDk0dGggbWVldGluZywgdGhlcmUgd2FzIGEgY29uc2Vu c3VzIHRvIGRyb3AgTUlGIE1QVkQgZGhjcCBkb2N1bWVudCANCmR1ZSB0byBJUFIgY2xhaW0uDQpo dHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1pZi1tcHZkLWRoY3Atc3VwcG9ydC0w Mi50eHQNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI2NDgvDQogDQpIZXJlIHdl IGNvbmZvcm0gdGhpcyBjb25jZW5zdXMgaW4gdGhlIG1haWxpbmcgbGlzdCBhZ2Fpbg0KIA0KQ29j aGFpcnMNCiANCiAJCSAJICAgCQkgIA== --_67029f82-f100-40c5-a011-6603a8164cce_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsPEJSPjxicj5EdXJpbmcgSUVURiA5NHRo IG1lZXRpbmcsIHRoZXJlIHdhcyBhIGNvbnNlbnN1cyB0byBkcm9wIE1JRiBNUFZEIGRoY3AgZG9j dW1lbnQgPEJSPmR1ZSB0byBJUFIgY2xhaW0uPEJSPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWlldGYtbWlmLW1wdmQtZGhjcC1zdXBwb3J0LTAyLnR4dCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1taWYtbXB2ZC1kaGNwLXN1cHBvcnQtMDIudHh0PC9h Pjxicj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNjQ4LyI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjY0OC88L2E+PEJSPiZuYnNwOzxCUj5IZXJl IHdlIGNvbmZvcm0gdGhpcyBjb25jZW5zdXMgaW4gdGhlIG1haWxpbmcgbGlzdCBhZ2FpbjxCUj4m bmJzcDs8QlI+Q29jaGFpcnM8QlI+PHNwYW4gc3R5bGU9J2NvbG9yOiBibGFjazsgZm9udC1mYW1p bHk6IEFyaWFsOyBmb250LXNpemU6IDI4cHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogQXJpYWw7 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAio82j0yCj0KW0pbelw6WvIjsgbXNvLWJpZGktZm9u dC1mYW1pbHk6ICttbi1jczsgbXNvLWNvbG9yLWluZGV4OiAxOyBsYW5ndWFnZTogZW4tVVM7Jz48 L3NwYW4+Jm5ic3A7PEJSPiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_67029f82-f100-40c5-a011-6603a8164cce_-- From nobody Sun Nov 22 02:41:17 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 1BC941B31B5 for ; Sun, 22 Nov 2015 02:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 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, RP_MATCHES_RCVD=-0.585, 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 XO1RHWAEhNR4 for ; Sun, 22 Nov 2015 02:41:14 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 28CEA1B31B2 for ; Sun, 22 Nov 2015 02:41:13 -0800 (PST) Received: by wmec201 with SMTP id c201so124742778wme.0 for ; Sun, 22 Nov 2015 02:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q32bXMZYgFX7fVIQHqbyRpff+kpqZLJJZKj+cKlugog=; b=Kekr+plM3FxbJ+IKeIR9/gQcHYoD4Zs2LzKZDbECqR3DhEW0SN065S0KdQ+IDOa0VR aP25KfSoEShw0Y5aaxtqj089N6Vqyan1UP51ZD6jqwhj3tHK+LlFLWzG/FLKZ8zuFHKR origjnWYf2WytSgbIw9Nm7XF0qgGI/zf/H9kqS0O13u7KgOq32wF+uPY4m5lJnV0sy1d gMP6Iaq8ZqFdqZ1HdVAdeT4xre0Or7ezizEvXvdoe2dMNFG8YN9F5ag4vdlTFGD8cnmY kfB+5OMJhJ6LxabrHz10mg611cTLjcIJPihdvN+Rf+jC4v8UcSLwGbNx/DimojbtiJPv ab3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Q32bXMZYgFX7fVIQHqbyRpff+kpqZLJJZKj+cKlugog=; b=K91wc3cD1mJ1fySB7kI43nYgfz+E3JTd24HycjLnOyd0zCKy4mar5BSBjtXXTGRjkr xZGqkXZY1hI9Kcxx060Lftit3HRVES2uClluoq9r8x9tS0GneAucKczf/WT9Rk4ACfMN zsEDOZE7JtvX4hmA2jxD7Iwn2bJwm3Lbv1Tl8sTqxw0xB3a4+BO9U4VvjTzla6IXU1ta 0mkrEKEbE9u+LuIZbvxDZk9nkL9yscf/dJa3uN33O9j2+21eym4+d6V8fzV7UOvEtwZB 76gEiYUc7rtJSqgNy78KDU8Z1zI2sKNvQnTbvJPKIJSDs3EP5wb1pyyDMlTmri8L4DmZ qkaA== X-Gm-Message-State: ALoCoQmFZmqEaW/QMMAWwnIBdQ3Fu2n9XiFWRYewomjJ0KmoZdDYNjAalRmVO0gyvVypid5rs06+ X-Received: by 10.28.153.130 with SMTP id b124mr10860888wme.12.1448188871683; Sun, 22 Nov 2015 02:41:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.223.215 with HTTP; Sun, 22 Nov 2015 02:40:51 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Sun, 22 Nov 2015 19:40:51 +0900 Message-ID: To: Hui Deng Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mif@ietf.org" , Margaret Cullen Subject: Re: [mif] Consensus to drop MIF mpvd dhcp document 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: Sun, 22 Nov 2015 10:41:16 -0000 +1 On 22 November 2015 at 19:06, Hui Deng wrote: > Hello all > > During IETF 94th meeting, there was a consensus to drop MIF MPVD dhcp > document > due to IPR claim. > https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt > https://datatracker.ietf.org/ipr/2648/ > > Here we conform this concensus in the mailing list again > > Cochairs > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From nobody Sun Nov 22 03:22: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 752EC1B323D for ; Sun, 22 Nov 2015 03:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 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, RP_MATCHES_RCVD=-0.585] 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 TzKGSX5GR_JQ for ; Sun, 22 Nov 2015 03:22:04 -0800 (PST) Received: from COL004-OMC2S16.hotmail.com (col004-omc2s16.hotmail.com [65.55.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051401B3239 for ; Sun, 22 Nov 2015 03:22:03 -0800 (PST) Received: from COL125-W3 ([65.55.34.72]) by COL004-OMC2S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 22 Nov 2015 03:22:03 -0800 X-TMN: [HuNjHLb8XdMbQaJvQwSqRrPPjMUtLr340Z+hFmGLj/E=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c08e860c-0d1f-4fb6-b35a-367f64b9d920_" From: Hui Deng To: "mif@ietf.org" , Margaret Cullen Date: Sun, 22 Nov 2015 19:22:03 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2015 11:22:03.0503 (UTC) FILETIME=[03493FF0:01D12518] Archived-At: Subject: [mif] Concensus call on MPVD ID document 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: Sun, 22 Nov 2015 11:22:09 -0000 --_c08e860c-0d1f-4fb6-b35a-367f64b9d920_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IEhlbGxvIGFsbA0KIA0KVGhlcmUgd2VyZSB0d28gY29uY2Vuc3VzIGNhbGxzIHJlbGF0ZWQgdG8g TVBWRCBJRCBkb2N1bWVudA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1taWYt bXB2ZC1pZC0wMi50eHQNCiANCjEpIFdoZXRoZXIgdGhlcmUgc2hvdWxkIGJlIGFuIGV4dGVybmFs IG1lY2hhbmlzbSB0byBsb29rIHVwIHB2ZCBpbmZvcm1hdGlvbj8NClRoZXJlIHdlcmUgMTAgcGVv cGxlIHNheSBZZXMsIDAgc2F5IE5vLg0KIA0KMikgV2hldGhlciB3ZSBzaG91bGQgd2FpdCBvbiBk ZWZpbmluZyB0aGUgUFZEIHVudGlsIDFzdCBwcm90b2NvbCB0byB1c2UgaXQNClRoZXJlIHdlcmUg MTAgcGVvcGxlIHNheSBZZXMsIDAgc2F5IE5vLg0KIA0KSGVyZSB3ZSBjb25maXJtIHRoZXNlIHR3 byBpbiB0aGUgbWFpbGluZyBsaXN0IGFnYWluDQogDQpCZXN0IHJlZ2FyZHMsDQogDQpDb2NoYWly cw0KIA0KDQogDQogCQkgCSAgIAkJICA= --_c08e860c-0d1f-4fb6-b35a-367f64b9d920_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+Jm5ic3A7SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5UaGVy ZSB3ZXJlIHR3byBjb25jZW5zdXMgY2FsbHMgcmVsYXRlZCB0byBNUFZEIElEIGRvY3VtZW50PEJS PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbWlmLW1wdmQtaWQt MDIudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1pZi1tcHZkLWlkLTAy LnR4dDwvYT48QlI+Jm5ic3A7PEJSPjEpIFdoZXRoZXIgdGhlcmUgc2hvdWxkIGJlIGFuIGV4dGVy bmFsIG1lY2hhbmlzbSB0byBsb29rIHVwIHB2ZCBpbmZvcm1hdGlvbj88QlI+VGhlcmUgd2VyZSAx MCBwZW9wbGUgc2F5IFllcywgMCBzYXkgTm8uPEJSPiZuYnNwOzxCUj4yKSBXaGV0aGVyIHdlIHNo b3VsZCB3YWl0IG9uIGRlZmluaW5nIHRoZSBQVkQgdW50aWwgMXN0IHByb3RvY29sIHRvIHVzZSBp dDxCUj5UaGVyZSB3ZXJlIDEwIHBlb3BsZSBzYXkgWWVzLCAwIHNheSBOby48QlI+Jm5ic3A7PEJS PkhlcmUgd2UgY29uZmlybSB0aGVzZSB0d28gaW4gdGhlIG1haWxpbmcgbGlzdCBhZ2FpbjxCUj4m bmJzcDs8QlI+QmVzdCByZWdhcmRzLDxCUj4mbmJzcDs8QlI+Q29jaGFpcnM8QlI+Jm5ic3A7PEJS Pjxicj4mbmJzcDs8QlI+IAkJIAkgICAJCSAgPC9kaXY+PC9ib2R5Pg0KPC9odG1sPg== --_c08e860c-0d1f-4fb6-b35a-367f64b9d920_-- From nobody Sun Nov 22 05:09:39 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 A2A0E1A887A for ; Sun, 22 Nov 2015 05:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 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, RP_MATCHES_RCVD=-0.585, 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 CCgBJ_Tstrqe for ; Sun, 22 Nov 2015 05:09:34 -0800 (PST) Received: from COL004-OMC2S12.hotmail.com (col004-omc2s12.hotmail.com [65.55.34.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21531A8879 for ; Sun, 22 Nov 2015 05:09:33 -0800 (PST) Received: from COL125-W51 ([65.55.34.73]) by COL004-OMC2S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 22 Nov 2015 05:09:33 -0800 X-TMN: [ALoXpJsfc5QFU1leS67xLiLK76XQSXbiZIfB0OBtm20=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_5b5a0c16-2bb9-45b7-98a9-d6b48313ed44_" From: Hui Deng To: "mif@ietf.org" , Margaret Cullen Date: Sun, 22 Nov 2015 21:09:32 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2015 13:09:33.0258 (UTC) FILETIME=[07A3C2A0:01D12527] Archived-At: Subject: [mif] Concensus call on host behavior of MPVD NDP document 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: Sun, 22 Nov 2015 13:09:36 -0000 --_5b5a0c16-2bb9-45b7-98a9-d6b48313ed44_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IEhlbGxvIGFsbA0KIA0KVGhlcmUgd2FzIG9uZSBjb25jZW5zdXMgY2FsbCBvbiB3aGV0aGVyIE1Q VkQgTkRQIGRvY3VtZW50IHNob3VsZCBub3QgY29udGFpbiB3aGF0IHRoZSBob3N0IGRvZXM6DQo4 IHBlb3BsZSB0aGluayBpdCBzaG91bGQgbm90DQowIHBlb3BsZSB0aGluayBpdCBzaG91bGQNCmh0 dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbWlmLW1wdmQtbmRwLXN1cHBvcnQtMDIu dHh0DQogDQpIZXJlIHdlIGNvbmZpcm0gaW4gdGhlIG1haWxpbmcgbGlzdCBhZ2Fpbg0KIA0KY29j aGFpcnMNCiAJCSAJICAgCQkgIA== --_5b5a0c16-2bb9-45b7-98a9-d6b48313ed44_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+Jm5ic3A7SGVsbG8gYWxsPEJSPiZuYnNwOzxCUj5UaGVy ZSB3YXMgb25lIGNvbmNlbnN1cyBjYWxsIG9uIHdoZXRoZXIgTVBWRCBORFAgZG9jdW1lbnQgc2hv dWxkIG5vdCBjb250YWluIHdoYXQgdGhlIGhvc3QgZG9lczo8QlI+OCBwZW9wbGUgdGhpbmsgaXQg c2hvdWxkIG5vdDxCUj4wIHBlb3BsZSB0aGluayBpdCBzaG91bGQ8QlI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1taWYtbXB2ZC1uZHAtc3VwcG9ydC0wMi50eHQi Pmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbWlmLW1wdmQtbmRwLXN1cHBvcnQt MDIudHh0PC9hPjxCUj4mbmJzcDs8QlI+SGVyZSB3ZSBjb25maXJtIGluIHRoZSBtYWlsaW5nIGxp c3QgYWdhaW48QlI+Jm5ic3A7PEJSPmNvY2hhaXJzPEJSPiAJCSAJICAgCQkgIDwvZGl2PjwvYm9k eT4NCjwvaHRtbD4= --_5b5a0c16-2bb9-45b7-98a9-d6b48313ed44_-- From nobody Mon Nov 23 01:19: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 A36311A1B05 for ; Mon, 23 Nov 2015 01:18:50 -0800 (PST) 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 QHTwAhwa5Ndc for ; Mon, 23 Nov 2015 01:18:49 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 304DF1A1B9C for ; Mon, 23 Nov 2015 01:18:49 -0800 (PST) Received: by iofh3 with SMTP id h3so181202399iof.3 for ; Mon, 23 Nov 2015 01:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=/gD3/iY6oHvxMCWOgvmTtQ0T2fvmcUnTvL2HpSMQdzY=; b=t05IlxhCpqC4wiKXOmAbkmC6rfZ3ak/gp279D88agEZzPYp1+U7icaOTipurM1CB1b TRuuKlbHX2R/anovYZA4/N+FvBrZom+RM6Jv9jgNvyr4WFrRHrPD26l2SlD61jtGiOGv TCeQROv6flZjuGGct94H+uwq3HJC9OqZsUhEW2YOYsXrnQpUmCazOK2DY3Hud9Lfo9u8 Diiir65fIDNrzWGBg++HPtcmd7+LbGaoEdPfl9mXKwzWQAq5SQVGloguTp2nqqztWlz4 V2CWgYarMLEuaA8oYah/cVFPe1F+9k4Vj8r/AxkRvxl2XyA3/0TlHaU4m35fedasl5Un Eb8Q== MIME-Version: 1.0 X-Received: by 10.107.137.226 with SMTP id t95mr23870520ioi.188.1448270328667; Mon, 23 Nov 2015 01:18:48 -0800 (PST) Received: by 10.36.154.3 with HTTP; Mon, 23 Nov 2015 01:18:48 -0800 (PST) Date: Mon, 23 Nov 2015 17:18:48 +0800 Message-ID: From: GangChen To: "mif@ietf.org" , Dave Thaler Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hui Deng , Margaret Cullen Subject: [mif] clarification on HE-MIF algorithm 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, 23 Nov 2015 09:18:50 -0000 wg, I would like to follow the meeting minutes to clarify a question from the discussion. " DT - Clarifying question - base happy happy eyeballs spec has two algos, none of them mandatory no mandatory algorithm Does this specify a mandatory algo? " The HE-MIF doesn't specify mandatory algorithm. Basically, HE-MIF is doing a similar way with RFC6555. The draft describes step-wise requirements for any candidate algorithm. BRs Gang 2015-11-22 8:40 GMT+08:00, Hui Deng : > Hello all > > Appreciate Ian Farrer and Ted Lemon kindly help for minutes > Also Mikael Abrahamsson for Jabber > > https://www.ietf.org/proceedings/94/minutes/minutes-94-mif > > Please feel free to let chairs know whether you have some revision > > thanks a lot > > DENG Hui > From nobody Mon Nov 23 08:44:11 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 BFBF61A8F40 for ; Mon, 23 Nov 2015 08:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 1YCAJxpuYVoR for ; Mon, 23 Nov 2015 08:44:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7D31A8A7E for ; Mon, 23 Nov 2015 08:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qM1w7nFwOIlw+l7+Mq9TdaXjF94Iuyiyp+TQ6iV4ZzE=; b=TsDdHzIkVveB8OVkbSolYCJeSK0WiWlduikCKdJmzxxE51d4kYKekOH7F8//s5CAKXtRdu/DC8rYHbevo9zai7HNE2DZyV0CqQLiFwtw4QoJmX9gsIgYkd0j+TXkmj7bjvRpfJ59CvDt/P1yA4JA2NFwwc3cYU8r28WJ6k7HMgA= Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.1.331.20; Mon, 23 Nov 2015 16:44:03 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0325.019; Mon, 23 Nov 2015 16:44:03 +0000 From: Dave Thaler To: GangChen , "mif@ietf.org" Thread-Topic: [mif] clarification on HE-MIF algorithm Thread-Index: AQHRJc/3XfJH8uZmyESgDQqIBlC0AJ6p0EVQ Date: Mon, 23 Nov 2015 16:44:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [67.182.144.235] x-microsoft-exchange-diagnostics: 1; BY2PR03MB409; 5:v0VZUprMoTaWDokN2sRIIfWuOnNrTyGrLzwmc09U5BVPfXz7KnLd7B7Cnwmd6STDJdgYDJ0SXAdo1AGVHD8uNoD4ewUvP3rVRLlZ9Z5nw/sfoCGFrJZ8ZSDSm2E31rddCs/fM6svzEqqR2e4jn/o1A==; 24:tYrAMOIVo06GDRF7GjixQw77EfXtXKWr5jdhldz/468CL7LCZYcQXiy07TPVuM6B3dQB1TqoUmsoI/8/aShbQqCbyvoZj355Qr2bIvyk5I0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB409; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(194151415913766)(189930954265078)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:BY2PR03MB409; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB409; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(377424004)(52044002)(189002)(53754006)(2950100001)(189998001)(586003)(2900100001)(5001960100002)(86362001)(86612001)(101416001)(87936001)(77096005)(19580405001)(19580395003)(122556002)(66066001)(2501003)(5002640100001)(15975445007)(40100003)(5003600100002)(76576001)(5008740100001)(11100500001)(92566002)(54356999)(74316001)(10090500001)(50986999)(5005710100001)(8990500004)(76176999)(10400500002)(10290500002)(5004730100002)(5001920100001)(106356001)(106116001)(33656002)(97736004)(5001770100001)(105586002)(99286002)(81156007)(102836003)(5007970100001)(6116002)(4001150100001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2015 16:44:03.2118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB409 Archived-At: Cc: Hui Deng , Margaret Cullen Subject: Re: [mif] clarification on HE-MIF algorithm 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, 23 Nov 2015 16:44:10 -0000 VGhlIGdyYW1tYXIgaW4gdGhlIG1pbnV0ZXMgbG9va3MgYmFkLiAgV2hhdCBJIHNhaWQgd2FzOg0K DQoiUkZDIDY1NTUgZG9lcyBub3Qgc3BlY2lmeSBhIG1hbmRhdG9yeSBhbGdvcml0aG0sIG9ubHkg cmVxdWlyZW1lbnRzIGZvciBhbGdvcml0aG1zLA0KYW5kIGFuIGV4YW1wbGUgYWxnb3JpdGhtLiAg RG9lcyB0aGlzIGRyYWZ0IHRyeSB0byBtYWtlIGEgcGFydGljdWxhciBhbGdvcml0aG0gbWFuZGF0 b3J5PyINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEdhbmdDaGVuIFttYWls dG86cGhkZ2FuZ0BnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMywgMjAxNSAx OjE5IEFNDQpUbzogbWlmQGlldGYub3JnOyBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQu Y29tPg0KQ2M6IE1hcmdhcmV0IEN1bGxlbiA8bXJjdWxsZW40MkBnbWFpbC5jb20+OyBIdWkgRGVu ZyA8ZGVuZ2h1aTAyQGhvdG1haWwuY29tPg0KU3ViamVjdDogW21pZl0gY2xhcmlmaWNhdGlvbiBv biBIRS1NSUYgYWxnb3JpdGhtDQoNCndnLA0KDQpJIHdvdWxkIGxpa2UgdG8gZm9sbG93IHRoZSBt ZWV0aW5nIG1pbnV0ZXMgdG8gY2xhcmlmeSBhIHF1ZXN0aW9uIGZyb20gdGhlIGRpc2N1c3Npb24u DQoNCiINCiAgRFQgLSBDbGFyaWZ5aW5nIHF1ZXN0aW9uIC0gYmFzZSBoYXBweSBoYXBweSBleWVi YWxscyBzcGVjIGhhcyB0d28NCiAgYWxnb3MsIG5vbmUgb2YgdGhlbSBtYW5kYXRvcnkgbm8gbWFu ZGF0b3J5IGFsZ29yaXRobSBEb2VzIHRoaXMNCiAgc3BlY2lmeSBhIG1hbmRhdG9yeSBhbGdvPw0K Ig0KDQpUaGUgSEUtTUlGIGRvZXNuJ3Qgc3BlY2lmeSBtYW5kYXRvcnkgYWxnb3JpdGhtLg0KQmFz aWNhbGx5LCBIRS1NSUYgaXMgZG9pbmcgYSBzaW1pbGFyIHdheSB3aXRoIFJGQzY1NTUuDQpUaGUg ZHJhZnQgZGVzY3JpYmVzIHN0ZXAtd2lzZSByZXF1aXJlbWVudHMgZm9yIGFueSBjYW5kaWRhdGUg YWxnb3JpdGhtLg0KDQpCUnMNCg0KR2FuZw0KDQoyMDE1LTExLTIyIDg6NDAgR01UKzA4OjAwLCBI dWkgRGVuZyA8ZGVuZ2h1aTAyQGhvdG1haWwuY29tPjoNCj4gSGVsbG8gYWxsDQo+DQo+IEFwcHJl Y2lhdGUgSWFuIEZhcnJlciBhbmQgVGVkIExlbW9uIGtpbmRseSBoZWxwIGZvciBtaW51dGVzIEFs c28gDQo+IE1pa2FlbCBBYnJhaGFtc3NvbiBmb3IgSmFiYmVyDQo+DQo+IGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmkN Cj4gZXRmLm9yZyUyZnByb2NlZWRpbmdzJTJmOTQlMmZtaW51dGVzJTJmbWludXRlcy05NC1taWYm ZGF0YT0wMSU3YzAxJTdjZA0KPiB0aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdjNmJkMjgxMGNhNDMz NDA1MTU1NDUwOGQyZjNlNzE4Y2IlN2M3MmY5ODhiZjg2DQo+IGYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN2MxJnNkYXRhPSUyYlJWJTJmSyUyZno4UXBmVDJoaWJzSHdmbW5aZSUyZkl0ZHINCj4gc0Y2 dmxQWHhKczNvc28lM2QNCj4NCj4gUGxlYXNlIGZlZWwgZnJlZSB0byBsZXQgY2hhaXJzIGtub3cg d2hldGhlciB5b3UgaGF2ZSBzb21lIHJldmlzaW9uDQo+DQo+IHRoYW5rcyBhIGxvdA0KPg0KPiBE RU5HIEh1aQ0KPg0K From nobody Mon Nov 23 11:35: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 83AB71B32C5 for ; Mon, 23 Nov 2015 11:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585] 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 m7q1b8oE6j8Z for ; Mon, 23 Nov 2015 11:35:13 -0800 (PST) Received: from mail.zemris.fer.hr (gandalf.zemris.fer.hr [161.53.65.11]) by ietfa.amsl.com (Postfix) with ESMTP id 275D51B32C7 for ; Mon, 23 Nov 2015 11:35:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.zemris.fer.hr (Postfix) with ESMTP id 15A6D3B7C059; Mon, 23 Nov 2015 20:35:11 +0100 (CET) X-Virus-Scanned: amavisd-new at zemris.fer.hr Received: from mail.zemris.fer.hr ([127.0.0.1]) by localhost (mail.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0LX3nkCVyAG; Mon, 23 Nov 2015 20:35:09 +0100 (CET) Received: from w540.sistemnet.local (78-0-250-138.adsl.net.t-com.hr [78.0.250.138]) by mail.zemris.fer.hr (Postfix) with ESMTPSA id 8352B3B7C04D; Mon, 23 Nov 2015 20:35:09 +0100 (CET) References: <20151123192422.32415.11982.idtracker@ietfa.amsl.com> To: "mif@ietf.org" From: =?UTF-8?Q?Stjepan_Gro=c5=a1?= Organization: UNIZG - FER X-Forwarded-Message-Id: <20151123192422.32415.11982.idtracker@ietfa.amsl.com> Message-ID: <56536A51.4010001@fer.hr> Date: Mon, 23 Nov 2015 20:34:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151123192422.32415.11982.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HPAi0t517eAif2MJU6KlXeb0FRUWWXqfJ" Archived-At: Subject: [mif] Fwd: New Version Notification for draft-sgros-dhcp-and-ipr-claim-analysis-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, 23 Nov 2015 19:35:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HPAi0t517eAif2MJU6KlXeb0FRUWWXqfJ Content-Type: multipart/alternative; boundary="------------020209040205020303010807" This is a multi-part message in MIME format. --------------020209040205020303010807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone! We did an analysis of Huawei's IPR claim and wrote a draft about our findings. In the end, our opinion is that this IPR doesn't matter. But in worst case it only partially covers what MIF did. Anyway, we are not lawyers and would appreciate a feedback. SG -------- Forwarded Message -------- Subject: New Version Notification for draft-sgros-dhcp-and-ipr-claim-analysis-00.txt Date: Mon, 23 Nov 2015 11:24:22 -0800 From: internet-drafts@ietf.org To: Leonardo Jelenkovic , Dejan Skvorc , Stjepan Gros A new version of I-D, draft-sgros-dhcp-and-ipr-claim-analysis-00.txt has been successfully submitted by Stjepan Gros and posted to the IETF repository. Name: draft-sgros-dhcp-and-ipr-claim-analysis Revision: 00 Title: DHCP configuration in MIF and associated IPR claim Document date: 2015-11-23 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-sgros-dhcp-and= -ipr-claim-analysis-00.txt Status: https://datatracker.ietf.org/doc/draft-sgros-dhcp-and-ipr= -claim-analysis/ Htmlized: https://tools.ietf.org/html/draft-sgros-dhcp-and-ipr-clai= m-analysis-00 Abstract: The purpose of this draft is to analyze different options on how DHCP can be used to configure PvD aware client. This is done in light of IPR claim made by Huawei and the necessity to find an option for implementation. In order for an option to be selected it obviously must not interfere with IPR, or, IPR has to be somehow invalidated. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------020209040205020303010807 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone!

We did an analysis of Huawei's IPR claim and wrote a draft about our findings.=C2=A0 In the end, our opinion is that this IPR doesn'= t matter. But in worst case it only partially covers what MIF did. Anyway, we are not lawyers and would appreciate a feedback.

SG


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-sgros-dhcp-and-ipr-claim-analysis-00.txt
Dat= e: Mon, 23 Nov 2015 11:24:22 -0800
Fro= m: internet-drafts@ietf.org
To:= Leonardo Jelenkovic <leonardo.jelenkovic@fer.hr&g= t;, Dejan Skvorc <dejan.skvorc@fer.hr>, Stjepan Gros <stjepan.gros@fer.hr> 


A new version of I-D, draft-sgros-dhcp-and-ipr-claim-analysis-=
00.txt
has been successfully submitted by Stjepan Gros and posted to the
IETF repository.

Name:		draft-sgros-dhcp-and-ipr-claim-analysis
Revision:	00
Title:		DHCP configuration in MIF and associated IPR claim
Document date:	2015-11-23
Group:		Individual Submission
Pages:		11
URL:            ht=
tps://www.ietf.org/internet-drafts/draft-sgros-dhcp-and-ipr-claim-analysi=
s-00.txt
Status:         https://data=
tracker.ietf.org/doc/draft-sgros-dhcp-and-ipr-claim-analysis/
Htmlized:       https://tools.i=
etf.org/html/draft-sgros-dhcp-and-ipr-claim-analysis-00


Abstract:
   The purpose of this draft is to analyze different options on how DHCP
   can be used to configure PvD aware client.  This is done in light of
   IPR claim made by Huawei and the necessity to find an option for
   implementation.  In order for an option to be selected it obviously
   must not interfere with IPR, or, IPR has to be somehow invalidated.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--------------020209040205020303010807-- --HPAi0t517eAif2MJU6KlXeb0FRUWWXqfJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWU2pRAAoJELZD5ReLhUf0M0UH/0XhuU+1T8BMnRx1gQdzkLqJ 9nB2holYpqMABfBmXsCzU3/ex8yImsPScQiy1OMiJezIhWnu+kK7cN3TnVJHMgcZ LbJlXTU32qLi6SN0rzDJN7fOuNPLUexOgztw8FHGFRGg7jnFo4J3yQY9e1y5tOXc aQrvnZpamgN9sulD625BN3DhDcT5bLMMi5Y63yC6IQ6BOrTiB8UBDVuH7rK9jPnp 0CJbfkC8bnnh7K7/ZSS/Xxf9qBIaXzBu54sLg2vsackxv5Yl10SuXA6BkNgBazV7 I5DvmJ3PfqcQdabbyxnaz5aqL+Cc5C2VRxiYBEdiEX/1PZ0tylox5Rk+EZWup8M= =6ju6 -----END PGP SIGNATURE----- --HPAi0t517eAif2MJU6KlXeb0FRUWWXqfJ-- From nobody Mon Nov 23 22:39: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 D346F1B2EAB for ; Mon, 23 Nov 2015 22:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, 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 z2SUb5H1fVmz for ; Mon, 23 Nov 2015 22:39:06 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 71F781B2EAA for ; Mon, 23 Nov 2015 22:39:06 -0800 (PST) Received: by ykba77 with SMTP id a77so8547453ykb.2 for ; Mon, 23 Nov 2015 22:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zvAE8G9OexvwhdSckrgkrf+HabIWBdpXT//T2NYacy8=; b=a99eyxA/SVBqhBzIegrZN20US+wirH4OZB9aGP1VaNmV4pmOqeFBDRbDCP+ixZJ3OL o6uulvE2iRUAxIfYxxFQCpowTPz8H/FpbjEKlV5Z/JwKGKcN1S2CjBjv134+PMqM38v4 KVKjnEaI3L//qBgX61MpqpGKBYeBhm1xRg+hzYyQ3/ToBA3rjXgcdYkmkD1ErUF4MxGH no1KKY2snEAiO80UArOkGTLnu2qje4hMM303TYF1vAjUPHYmVBfRoNtHl/pl9HpACIh4 Y7NBzYUyoFasdSuLb7K9qMXYbJtV0ixeeJrOXPKdo5ORaoCnSIHDeeWPkddorr+ZIihC V1JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zvAE8G9OexvwhdSckrgkrf+HabIWBdpXT//T2NYacy8=; b=SWIS9taxaM4lB3i9x3UpJm7y8gCPlFDbEz0tGtyqErnkzflScPlMzt7mCx5wgy5jMe cuxIdcUOhaKJFpy0Qyix1kcH+Uaaa9qFtFKSdQCmN9q6/80wIPfMqWr8QK4qi57CI5Rn +CF9MKZ1A0kO1L6Srbthsls1uY/5uLy8rCTB8NqIvHpZZ0JYp09cF+mguAysl0rgDoFE cGo/Xk5otqNMPII0r0j+3cQiRpFJ+zV0JymTJ4Tz3j4XcwZeJ9MGRYD+RML5nkzefSgr JvB08LAd+B8twMTOmQXXgdNUOrS/CHj0++cfw0FEtCyDqApSOlKHfUEWLixY+LaUUKV8 NLOA== X-Gm-Message-State: ALoCoQkhFkkScU2HH7UY6z9J1oRxy3qhS7sm++Q/oVJWU8USlG1RVN4T7XOE2gc+W4EKt/GYBykC X-Received: by 10.129.157.70 with SMTP id u67mr26569886ywg.160.1448347145530; Mon, 23 Nov 2015 22:39:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.115.131 with HTTP; Mon, 23 Nov 2015 22:38:46 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 24 Nov 2015 15:38:46 +0900 Message-ID: To: Hui Deng Content-Type: multipart/alternative; boundary=94eb2c0b77d01f6897052543998e Archived-At: Cc: "mif@ietf.org" , Margaret Cullen Subject: Re: [mif] Consensus to drop MIF mpvd dhcp document 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, 24 Nov 2015 06:39:08 -0000 --94eb2c0b77d01f6897052543998e Content-Type: text/plain; charset=UTF-8 On Sun, Nov 22, 2015 at 7:06 PM, Hui Deng wrote: > During IETF 94th meeting, there was a consensus to drop MIF MPVD dhcp > document > due to IPR claim. > https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt > https://datatracker.ietf.org/ipr/2648/ > > Here we conform this concensus in the mailing list again > +1 --94eb2c0b77d01f6897052543998e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 22, 2015 at 7:06 PM, Hui Deng <denghui02@hotmail.com> wrote:
During IETF 94th meeting, there was a consensus to dr= op MIF MPVD dhcp document
due to IPR claim.
https= ://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt
https://datat= racker.ietf.org/ipr/2648/
=C2=A0
Here we conform this concensus i= n the mailing list again

+1=
--94eb2c0b77d01f6897052543998e-- From nobody Mon Nov 23 22:43:35 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 E09AC1A0013 for ; Mon, 23 Nov 2015 22:43:33 -0800 (PST) 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 0G6Liig69Q2y for ; Mon, 23 Nov 2015 22:43:32 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 17A731A0010 for ; Mon, 23 Nov 2015 22:43:32 -0800 (PST) Received: by igvg19 with SMTP id g19so89464900igv.1 for ; Mon, 23 Nov 2015 22:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i/Wa1mTfgw8ij1juRAhy9ViiSrYrd0rJ5fZm4nfxRsk=; b=WMDyNImFRjgZiQiEQ1Xu6wNaUFx8j+9LZ8bBzEI8lLom+j0VMEV5B9fhlwf2sziSQ7 UCUjcGQQCUqKvRUHrGlJqgGtEE9PI5IJZy2dXGGg3W8LeGM9s2ec2DsGcZXiCf1Llni4 VEYGLVOAL65qrKlqJBbbRWjVWnhScz4PJC7GcqYW8YCFjQEY6pFg33ebFIrFqCg4PQ36 UpuLwXbdsO4h+0n0nmpfNsGW+KD34vWbyJOZ3Vxb6a3yHDMtVKxC1dJ7drhE0PcVn1y0 P0Tm6AZ9u0w+TCC2Tf50ObzqtHQo5OACP2sWUHnPz8o2t5vuS+Xwe00w3jDCW2BhwK4Z pcug== MIME-Version: 1.0 X-Received: by 10.50.26.33 with SMTP id i1mr16456342igg.27.1448347411404; Mon, 23 Nov 2015 22:43:31 -0800 (PST) Received: by 10.36.154.3 with HTTP; Mon, 23 Nov 2015 22:43:31 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 14:43:31 +0800 Message-ID: From: GangChen To: Dave Thaler Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hui Deng , "mif@ietf.org" , Margaret Cullen Subject: Re: [mif] clarification on HE-MIF algorithm 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, 24 Nov 2015 06:43:34 -0000 Thank you, Dave. It's getting better understanding. The HE-MIF draft doesn't intend to make a particular algorithm mandatory. The draft also only describes requirements. Since the draft is stable for quite a while, we are seeking wglc if all questions are clarified. BRs Gang 2015-11-24 0:44 GMT+08:00, Dave Thaler : > The grammar in the minutes looks bad. What I said was: > > "RFC 6555 does not specify a mandatory algorithm, only requirements for > algorithms, > and an example algorithm. Does this draft try to make a particular > algorithm mandatory?" > > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Monday, November 23, 2015 1:19 AM > To: mif@ietf.org; Dave Thaler > Cc: Margaret Cullen ; Hui Deng > > Subject: [mif] clarification on HE-MIF algorithm > > wg, > > I would like to follow the meeting minutes to clarify a question from the > discussion. > > " > DT - Clarifying question - base happy happy eyeballs spec has two > algos, none of them mandatory no mandatory algorithm Does this > specify a mandatory algo? > " > > The HE-MIF doesn't specify mandatory algorithm. > Basically, HE-MIF is doing a similar way with RFC6555. > The draft describes step-wise requirements for any candidate algorithm. > > BRs > > Gang > > 2015-11-22 8:40 GMT+08:00, Hui Deng : >> Hello all >> >> Appreciate Ian Farrer and Ted Lemon kindly help for minutes Also >> Mikael Abrahamsson for Jabber >> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i >> etf.org%2fproceedings%2f94%2fminutes%2fminutes-94-mif&data=01%7c01%7cd >> thaler%40microsoft.com%7c6bd2810ca4334051554508d2f3e718cb%7c72f988bf86 >> f141af91ab2d7cd011db47%7c1&sdata=%2bRV%2fK%2fz8QpfT2hibsHwfmnZe%2fItdr >> sF6vlPXxJs3oso%3d >> >> Please feel free to let chairs know whether you have some revision >> >> thanks a lot >> >> DENG Hui >> > From nobody Tue Nov 24 03:30:14 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 6E14B1B2FDB for ; Tue, 24 Nov 2015 03:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 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, RP_MATCHES_RCVD=-0.585, 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 be3WAaTH0rTH for ; Tue, 24 Nov 2015 03:30:08 -0800 (PST) Received: from COL004-OMC1S6.hotmail.com (col004-omc1s6.hotmail.com [65.55.34.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778751B2FDA for ; Tue, 24 Nov 2015 03:30:08 -0800 (PST) Received: from COL125-W3 ([65.55.34.7]) by COL004-OMC1S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 24 Nov 2015 03:30:08 -0800 X-TMN: [pSxNS+agse3zOhwfQuDqIBQ5RnMMKzPCH4ZYIOh2YgM=] X-Originating-Email: [denghui02@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ed3a4cd6-0df0-4341-8416-045ddb9ad074_" From: Hui Deng To: Dave Thaler , GangChen , "mif@ietf.org" Date: Tue, 24 Nov 2015 19:30:08 +0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2015 11:30:08.0358 (UTC) FILETIME=[791BC060:01D126AB] Archived-At: Cc: Margaret Cullen Subject: Re: [mif] clarification on HE-MIF algorithm 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, 24 Nov 2015 11:30:13 -0000 --_ed3a4cd6-0df0-4341-8416-045ddb9ad074_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dGhlIG1pbnV0ZXMgaGFzIGJlZW4gdXBkYXRlZCwgaG9wZSB0aGF0IGlzIG1vcmUgY2xlYXINCmh0 dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L21pbnV0ZXMvbWludXRlcy05NC1taWYN CiANCkRFTkcgSHVpIA0KIA0KPiBGcm9tOiBkdGhhbGVyQG1pY3Jvc29mdC5jb20NCj4gVG86IHBo ZGdhbmdAZ21haWwuY29tOyBtaWZAaWV0Zi5vcmcNCj4gQ0M6IG1yY3VsbGVuNDJAZ21haWwuY29t OyBkZW5naHVpMDJAaG90bWFpbC5jb20NCj4gU3ViamVjdDogUkU6IFttaWZdIGNsYXJpZmljYXRp b24gb24gSEUtTUlGIGFsZ29yaXRobQ0KPiBEYXRlOiBNb24sIDIzIE5vdiAyMDE1IDE2OjQ0OjAz ICswMDAwDQo+IA0KPiBUaGUgZ3JhbW1hciBpbiB0aGUgbWludXRlcyBsb29rcyBiYWQuICBXaGF0 IEkgc2FpZCB3YXM6DQo+IA0KPiAiUkZDIDY1NTUgZG9lcyBub3Qgc3BlY2lmeSBhIG1hbmRhdG9y eSBhbGdvcml0aG0sIG9ubHkgcmVxdWlyZW1lbnRzIGZvciBhbGdvcml0aG1zLA0KPiBhbmQgYW4g ZXhhbXBsZSBhbGdvcml0aG0uICBEb2VzIHRoaXMgZHJhZnQgdHJ5IHRvIG1ha2UgYSBwYXJ0aWN1 bGFyIGFsZ29yaXRobSBtYW5kYXRvcnk/Ig0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogR2FuZ0NoZW4gW21haWx0bzpwaGRnYW5nQGdtYWlsLmNvbV0gDQo+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMTUgMToxOSBBTQ0KPiBUbzogbWlmQGlldGYub3JnOyBE YXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0KPiBDYzogTWFyZ2FyZXQgQ3VsbGVu IDxtcmN1bGxlbjQyQGdtYWlsLmNvbT47IEh1aSBEZW5nIDxkZW5naHVpMDJAaG90bWFpbC5jb20+ DQo+IFN1YmplY3Q6IFttaWZdIGNsYXJpZmljYXRpb24gb24gSEUtTUlGIGFsZ29yaXRobQ0KPiAN Cj4gd2csDQo+IA0KPiBJIHdvdWxkIGxpa2UgdG8gZm9sbG93IHRoZSBtZWV0aW5nIG1pbnV0ZXMg dG8gY2xhcmlmeSBhIHF1ZXN0aW9uIGZyb20gdGhlIGRpc2N1c3Npb24uDQo+IA0KPiAiDQo+ICAg RFQgLSBDbGFyaWZ5aW5nIHF1ZXN0aW9uIC0gYmFzZSBoYXBweSBoYXBweSBleWViYWxscyBzcGVj IGhhcyB0d28NCj4gICBhbGdvcywgbm9uZSBvZiB0aGVtIG1hbmRhdG9yeSBubyBtYW5kYXRvcnkg YWxnb3JpdGhtIERvZXMgdGhpcw0KPiAgIHNwZWNpZnkgYSBtYW5kYXRvcnkgYWxnbz8NCj4gIg0K PiANCj4gVGhlIEhFLU1JRiBkb2Vzbid0IHNwZWNpZnkgbWFuZGF0b3J5IGFsZ29yaXRobS4NCj4g QmFzaWNhbGx5LCBIRS1NSUYgaXMgZG9pbmcgYSBzaW1pbGFyIHdheSB3aXRoIFJGQzY1NTUuDQo+ IFRoZSBkcmFmdCBkZXNjcmliZXMgc3RlcC13aXNlIHJlcXVpcmVtZW50cyBmb3IgYW55IGNhbmRp ZGF0ZSBhbGdvcml0aG0uDQo+IA0KPiBCUnMNCj4gDQo+IEdhbmcNCj4gDQo+IDIwMTUtMTEtMjIg ODo0MCBHTVQrMDg6MDAsIEh1aSBEZW5nIDxkZW5naHVpMDJAaG90bWFpbC5jb20+Og0KPiA+IEhl bGxvIGFsbA0KPiA+DQo+ID4gQXBwcmVjaWF0ZSBJYW4gRmFycmVyIGFuZCBUZWQgTGVtb24ga2lu ZGx5IGhlbHAgZm9yIG1pbnV0ZXMgQWxzbyANCj4gPiBNaWthZWwgQWJyYWhhbXNzb24gZm9yIEph YmJlcg0KPiA+DQo+ID4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaQ0KPiA+IGV0Zi5vcmclMmZwcm9jZWVkaW5ncyUy Zjk0JTJmbWludXRlcyUyZm1pbnV0ZXMtOTQtbWlmJmRhdGE9MDElN2MwMSU3Y2QNCj4gPiB0aGFs ZXIlNDBtaWNyb3NvZnQuY29tJTdjNmJkMjgxMGNhNDMzNDA1MTU1NDUwOGQyZjNlNzE4Y2IlN2M3 MmY5ODhiZjg2DQo+ID4gZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9JTJiUlYlMmZL JTJmejhRcGZUMmhpYnNId2ZtblplJTJmSXRkcg0KPiA+IHNGNnZsUFh4SnMzb3NvJTNkDQo+ID4N Cj4gPiBQbGVhc2UgZmVlbCBmcmVlIHRvIGxldCBjaGFpcnMga25vdyB3aGV0aGVyIHlvdSBoYXZl IHNvbWUgcmV2aXNpb24NCj4gPg0KPiA+IHRoYW5rcyBhIGxvdA0KPiA+DQo+ID4gREVORyBIdWkN Cj4gPg0KIAkJIAkgICAJCSAg --_ed3a4cd6-0df0-4341-8416-045ddb9ad074_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+dGhlIG1pbnV0ZXMgaGFzIGJlZW4gdXBkYXRlZCwgaG9w ZSB0aGF0IGlzIG1vcmUgY2xlYXI8QlI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTQvbWludXRlcy9taW51dGVzLTk0LW1pZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTQvbWludXRlcy9taW51dGVzLTk0LW1pZjwvYT48QlI+Jm5ic3A7PEJSPkRF TkcgSHVpJm5ic3A7PEJSPjxiciAvPiZuYnNwOzxCUj48ZGl2Pj4gRnJvbSYjNTg7IGR0aGFsZXIm IzY0O21pY3Jvc29mdC5jb208YnI+PiBUbyYjNTg7IHBoZGdhbmcmIzY0O2dtYWlsLmNvbSYjNTk7 IG1pZiYjNjQ7aWV0Zi5vcmc8YnI+PiBDQyYjNTg7IG1yY3VsbGVuNDImIzY0O2dtYWlsLmNvbSYj NTk7IGRlbmdodWkwMiYjNjQ7aG90bWFpbC5jb208YnI+PiBTdWJqZWN0JiM1ODsgUkUmIzU4OyAm IzkxO21pZiYjOTM7IGNsYXJpZmljYXRpb24gb24gSEUtTUlGIGFsZ29yaXRobTxicj4+IERhdGUm IzU4OyBNb24sIDIzIE5vdiAyMDE1IDE2JiM1ODs0NCYjNTg7MDMgJiM0MzswMDAwPGJyPj4gPGJy Pj4gVGhlIGdyYW1tYXIgaW4gdGhlIG1pbnV0ZXMgbG9va3MgYmFkLiAgV2hhdCBJIHNhaWQgd2Fz JiM1ODs8YnI+PiA8YnI+PiAmIzM0O1JGQyA2NTU1IGRvZXMgbm90IHNwZWNpZnkgYSBtYW5kYXRv cnkgYWxnb3JpdGhtLCBvbmx5IHJlcXVpcmVtZW50cyBmb3IgYWxnb3JpdGhtcyw8YnI+PiBhbmQg YW4gZXhhbXBsZSBhbGdvcml0aG0uICBEb2VzIHRoaXMgZHJhZnQgdHJ5IHRvIG1ha2UgYSBwYXJ0 aWN1bGFyIGFsZ29yaXRobSBtYW5kYXRvcnkmIzYzOyYjMzQ7PGJyPj4gPGJyPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+PiBGcm9tJiM1ODsgR2FuZ0NoZW4gJiM5MTttYWlsdG8mIzU4 O3BoZGdhbmcmIzY0O2dtYWlsLmNvbSYjOTM7IDxicj4+IFNlbnQmIzU4OyBNb25kYXksIE5vdmVt YmVyIDIzLCAyMDE1IDEmIzU4OzE5IEFNPGJyPj4gVG8mIzU4OyBtaWYmIzY0O2lldGYub3JnJiM1 OTsgRGF2ZSBUaGFsZXIgJiM2MDtkdGhhbGVyJiM2NDttaWNyb3NvZnQuY29tJiM2Mjs8YnI+PiBD YyYjNTg7IE1hcmdhcmV0IEN1bGxlbiAmIzYwO21yY3VsbGVuNDImIzY0O2dtYWlsLmNvbSYjNjI7 JiM1OTsgSHVpIERlbmcgJiM2MDtkZW5naHVpMDImIzY0O2hvdG1haWwuY29tJiM2Mjs8YnI+PiBT dWJqZWN0JiM1ODsgJiM5MTttaWYmIzkzOyBjbGFyaWZpY2F0aW9uIG9uIEhFLU1JRiBhbGdvcml0 aG08YnI+PiA8YnI+PiB3Zyw8YnI+PiA8YnI+PiBJIHdvdWxkIGxpa2UgdG8gZm9sbG93IHRoZSBt ZWV0aW5nIG1pbnV0ZXMgdG8gY2xhcmlmeSBhIHF1ZXN0aW9uIGZyb20gdGhlIGRpc2N1c3Npb24u PGJyPj4gPGJyPj4gJiMzNDs8YnI+PiAgIERUIC0gQ2xhcmlmeWluZyBxdWVzdGlvbiAtIGJhc2Ug aGFwcHkgaGFwcHkgZXllYmFsbHMgc3BlYyBoYXMgdHdvPGJyPj4gICBhbGdvcywgbm9uZSBvZiB0 aGVtIG1hbmRhdG9yeSBubyBtYW5kYXRvcnkgYWxnb3JpdGhtIERvZXMgdGhpczxicj4+ICAgc3Bl Y2lmeSBhIG1hbmRhdG9yeSBhbGdvJiM2Mzs8YnI+PiAmIzM0Ozxicj4+IDxicj4+IFRoZSBIRS1N SUYgZG9lc24mIzM5O3Qgc3BlY2lmeSBtYW5kYXRvcnkgYWxnb3JpdGhtLjxicj4+IEJhc2ljYWxs eSwgSEUtTUlGIGlzIGRvaW5nIGEgc2ltaWxhciB3YXkgd2l0aCBSRkM2NTU1Ljxicj4+IFRoZSBk cmFmdCBkZXNjcmliZXMgc3RlcC13aXNlIHJlcXVpcmVtZW50cyBmb3IgYW55IGNhbmRpZGF0ZSBh bGdvcml0aG0uPGJyPj4gPGJyPj4gQlJzPGJyPj4gPGJyPj4gR2FuZzxicj4+IDxicj4+IDIwMTUt MTEtMjIgOCYjNTg7NDAgR01UJiM0MzswOCYjNTg7MDAsIEh1aSBEZW5nICYjNjA7ZGVuZ2h1aTAy JiM2NDtob3RtYWlsLmNvbSYjNjI7JiM1ODs8YnI+PiAmIzYyOyBIZWxsbyBhbGw8YnI+PiAmIzYy Ozxicj4+ICYjNjI7IEFwcHJlY2lhdGUgSWFuIEZhcnJlciBhbmQgVGVkIExlbW9uIGtpbmRseSBo ZWxwIGZvciBtaW51dGVzIEFsc28gPGJyPj4gJiM2MjsgTWlrYWVsIEFicmFoYW1zc29uIGZvciBK YWJiZXI8YnI+PiAmIzYyOzxicj4+ICYjNjI7IGh0dHBzJiM1ODsvL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vJiM2Mzt1cmwmIzYxO2h0dHBzJiMzNzszYSYjMzc7MmYmIzM3 OzJmd3d3Lmk8YnI+PiAmIzYyOyBldGYub3JnJiMzNzsyZnByb2NlZWRpbmdzJiMzNzsyZjk0JiMz NzsyZm1pbnV0ZXMmIzM3OzJmbWludXRlcy05NC1taWYmIzM4O2RhdGEmIzYxOzAxJiMzNzs3YzAx JiMzNzs3Y2Q8YnI+PiAmIzYyOyB0aGFsZXImIzM3OzQwbWljcm9zb2Z0LmNvbSYjMzc7N2M2YmQy ODEwY2E0MzM0MDUxNTU0NTA4ZDJmM2U3MThjYiYjMzc7N2M3MmY5ODhiZjg2PGJyPj4gJiM2Mjsg ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyYjMzc7N2MxJiMzODtzZGF0YSYjNjE7JiMzNzsyYlJWJiMz NzsyZksmIzM3OzJmejhRcGZUMmhpYnNId2ZtblplJiMzNzsyZkl0ZHI8YnI+PiAmIzYyOyBzRjZ2 bFBYeEpzM29zbyYjMzc7M2Q8YnI+PiAmIzYyOzxicj4+ICYjNjI7IFBsZWFzZSBmZWVsIGZyZWUg dG8gbGV0IGNoYWlycyBrbm93IHdoZXRoZXIgeW91IGhhdmUgc29tZSByZXZpc2lvbjxicj4+ICYj NjI7PGJyPj4gJiM2MjsgdGhhbmtzIGEgbG90PGJyPj4gJiM2Mjs8YnI+PiAmIzYyOyBERU5HIEh1 aTxicj4+ICYjNjI7PGJyPjwvZGl2PiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_ed3a4cd6-0df0-4341-8416-045ddb9ad074_-- From nobody Wed Nov 25 05:52:55 2015 Return-Path: X-Original-To: mif@ietf.org Delivered-To: mif@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61711B2CB4 for ; Wed, 25 Nov 2015 05:52:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151125135253.11261.86675.idtracker@ietfa.amsl.com> Date: Wed, 25 Nov 2015 05:52:53 -0800 From: IETF Secretariat Archived-At: Subject: [mif] Milestones changed for mif WG 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: Wed, 25 Nov 2015 13:52:54 -0000 Changed milestone "MPvD Architecture draft submitted to the IESG for publication as an Informational RFC", resolved as "Done". Deleted milestone "Initial draft on the requirements for changes to DHCPv6 and ND adopted by the WG". Deleted milestone "Initial draft on the guidance to applications adopted by the WG". Deleted milestone "Initial draft on high level MIF API adopted by the WG". Changed milestone "Initial draft on format and usage of PvD ID adoped by the WG", resolved as "Done", added draft-ietf-mif-mpvd-id to milestone. Changed milestone "Initial draft on DHCPv6 and ND extention adopted by the WG", resolved as "Done", added draft-ietf-mif-mpvd-ndp-support to milestone. Deleted milestone "Requirements for changes to DHCPv6 and ND submitted to the IESG for publication as an Informational RFC". Deleted milestone "Guidance to applications submitted to the IESG for publication as an Informational RFC". Changed milestone "MIF API extension solution to IESG for publication as an Informational RFC", set due date to July 2016 from July 2014, added draft-ietf-mif-api-extension to milestone. URL: https://datatracker.ietf.org/wg/mif/charter/ From nobody Thu Nov 26 22:47:11 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 5A51F1ACE0D for ; Thu, 26 Nov 2015 22:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 0ezB0mBjmro9 for ; Thu, 26 Nov 2015 22:47:08 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 97C621ACE0B for ; Thu, 26 Nov 2015 22:47:07 -0800 (PST) Received: from poro.lan (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5613C7B10176978D; Fri, 27 Nov 2015 08:45:08 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Markus Stenberg In-Reply-To: Date: Fri, 27 Nov 2015 08:47:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hui Deng X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "mif@ietf.org" , Margaret Cullen Subject: Re: [mif] Consensus to drop MIF mpvd dhcp document 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: Fri, 27 Nov 2015 06:47:10 -0000 > On 22.11.2015, at 12.06, Hui Deng wrote: >=20 > Hello all >=20 > During IETF 94th meeting, there was a consensus to drop MIF MPVD dhcp = document=20 > due to IPR claim. > https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt > https://datatracker.ietf.org/ipr/2648/ > =20 > Here we conform this concensus in the mailing list again=20 +1 -Markus From nobody Sun Nov 29 09:23:34 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 618941A8AC8 for ; Sun, 29 Nov 2015 09:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.885 X-Spam-Level: X-Spam-Status: No, score=-4.885 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, RP_MATCHES_RCVD=-0.585, 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 FcjBKCo02MGW for ; Sun, 29 Nov 2015 09:23:31 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D7A1A8A92 for ; Sun, 29 Nov 2015 09:23: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=1448817811; x=2312731411; 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=lGbZ5GlQ2Aot7s3/yYqFw0m/jRx+/W37S+FZlocakuQ=; b=3Z55KwNTxS1JFLq8+Z+SDDdgfmMYAKXMJh0W2Jh60W7AxLz3Vmwq6sf9IorqDwPQ s+jNPGOk0/NosRioPWZMsbtGj0KcsdVaej/mX1OsHFHpRNhVWhKKknGzAblxUppt 35xmiJ9CnseOUlkUuyQ1/h2lTSlt71LNrn+jPxnU23626EhWfEc6AmsJMfZL0Xbg fc1xguRD3hWHPlQXvhJgsPzYbkXR96ccwqw7zZ6tkMSW/k/DQWsbvxH1DCjQyq7y 4H1PUjQihviwMvsuFIu8RK37iWeUuNUDp2AsQPzabL40p8n9Jhoq5mklXSzsT9/1 f2VHzs1HTnptexh6R1DLPA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id AB.87.09556.3943B565; Sun, 29 Nov 2015 09:23:31 -0800 (PST) X-AuditID: 11973e15-f79be6d000002554-cd-565b3493e046 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 3C.6D.29392.3943B565; Sun, 29 Nov 2015 09:23:31 -0800 (PST) Received: from [17.153.86.22] (unknown [17.153.86.22]) by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NYL00BVN6Z6D630@cardamom.apple.com> for mif@ietf.org; Sun, 29 Nov 2015 09:23:31 -0800 (PST) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_23EA8D7F-F654-4FF0-8D5B-8138CB49E335" MIME-version: 1.0 (Mac OS X Mail 10.0 \(3153\)) From: Tommy Pauly In-reply-to: Date: Sun, 29 Nov 2015 09:23:29 -0800 Message-id: <5D7BB0F9-EBD7-4F08-97F2-143FA2D9FFD0@apple.com> References: To: Hui Deng X-Mailer: Apple Mail (2.3153) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYpTvZJDrM4NdceYuuPTeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMW/RQ8aCHVoVB9a5NzA+U+1i5OSQEDCRmLL0AzOELSZx4d56 ti5GLg4hgb2MEk1TJzHBFHVdbWeCSMxhkjjcdosZwuljknj44DFjFyMHh7CAhMTmPYkgDcwC SRLfP1wAa+YV0JdYtvAPG4gtLGAt0d+6mQXEZhNQkTj+bQPYZk4BS4kfPXvZQWwWAVWJd/9f gI1kFvCUWLgmA2KMjcTeP3/BSoQELCR2TLnCBFIiAjTm6vFyiDNlJd7+nAd2poTAFjaJbz97 2CYwCs9CctEsJBdBxLWB7NfMs8C26UhMXsiIKgxhfzx/hGkBI9sqRqHcxMwc3cw8M73EgoKc VL3k/NxNjKBImG4nuoPxzCqrQ4wCHIxKPLwnIqPChFgTy4orcw8xSnOwKInzzpkfFiYkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBUfie6APuazwX3+zeLF6cvfz+/kztgr4bZZPveGlNKa3U WO7mvnWNV85/65QnP0sdv308rhi7RW3mkmCmkrCAlnkn3593bIlp7dS+65J/rXWnQ8eNqZ/0 a/fqH/8ssmjrhEK+C04L3E40m3w9x7nrbpp/RjCHunLjBe8Slfvz214+Nfh0Uf7SQiWW4oxE Qy3mouJEAA32c9dlAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUi2FAcpzvZJDrMYMp5GYuuPTeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMW/RQ8aCHVoVB9a5NzA+U+1i5OSQEDCR6LrazgRhi0lcuLee rYuRi0NIYA6TxOG2W8wQTh+TxMMHjxm7GDk4hAUkJDbvSQRpYBZIkvj+4QJYM6+AvsSyhX/Y QGxhAWuJ/tbNLCA2m4CKxPFvG5hBbE4BS4kfPXvZQWwWAVWJd/9fgI1kFvCUWLgmA2KMjcTe P3/BSoQELCR2TLnCBFIiAjTm6vFyiDNlJd7+nMc0gVFgFpIjZiE5AiKuDWS/Zp4FtkBHYvJC RlRhCPvj+SNMCxjZVjEKFKXmJFaa6SUWFOSk6iXn525iBAduYdQOxoblVocYBTgYlXh4FWKi woRYE8uKK3MPMUpwMCuJ8HYZRYcJ8aYkVlalFuXHF5XmpBYfYpzICPTiRGYp0eR8YFzllcQb mpgYmBgbmxkbm5uY01JYSZy3cpV/mJBAemJJanZqakFqEcxRTBycUg2MvLozLk29bXbTOJHJ 4lBtuV3nw9593E+Xhm/c5VD71eRMY7dyW5da7b+zD9fOvbFTTNd7DuvuJULGqRWR11y8UyI3 9dYLuOeWnK04f8dPTefctTMPFugf3l6t8/98y7u/V8WTmxZN0tCdv9Fa6LHAKUN2s/PN0gJn Ofk+rbwfoRCdbWWTw7BMiaU4I9FQi7moOBEAik+00c8CAAA= Archived-At: Cc: "mif@ietf.org" , Margaret Cullen Subject: Re: [mif] Consensus to drop MIF mpvd dhcp document 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: Sun, 29 Nov 2015 17:23:33 -0000 --Apple-Mail=_23EA8D7F-F654-4FF0-8D5B-8138CB49E335 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Tommy > On Nov 22, 2015, at 2:06 AM, Hui Deng wrote: >=20 > Hello all >=20 > During IETF 94th meeting, there was a consensus to drop MIF MPVD dhcp = document=20 > due to IPR claim. > https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt = > https://datatracker.ietf.org/ipr/2648/ = > =20 > Here we conform this concensus in the mailing list again > =20 > Cochairs > =20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif = --Apple-Mail=_23EA8D7F-F654-4FF0-8D5B-8138CB49E335 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
+1

Tommy

On = Nov 22, 2015, at 2:06 AM, Hui Deng <denghui02@hotmail.com> wrote:

Hello all

During IETF 94th meeting, there was a consensus to drop MIF = MPVD dhcp document 
due to IPR claim.
https://www.ietf.org/id/draft-ietf-mif-mpvd-dhcp-support-02.txt=
https://datatracker.ietf.org/ipr/2648/
 
Here we conform this concensus in the = mailing list again
 
Cochairs
 
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

= --Apple-Mail=_23EA8D7F-F654-4FF0-8D5B-8138CB49E335--