Re: [mif-arch-dt] sections 4.3 and 4.4

<pierrick.seite@orange.com> Mon, 09 September 2013 08:35 UTC

Return-Path: <pierrick.seite@orange.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3870E11E8111 for <mif-arch-dt@ietfa.amsl.com>; Mon, 9 Sep 2013 01:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0vbYcw22xFQ for <mif-arch-dt@ietfa.amsl.com>; Mon, 9 Sep 2013 01:35:41 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DE14921F8793 for <mif-arch-dt@ietf.org>; Mon, 9 Sep 2013 01:35:37 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D1E8B2DC138; Mon, 9 Sep 2013 10:35:36 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id ABCE54C066; Mon, 9 Sep 2013 10:35:36 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 10:35:36 +0200
From: pierrick.seite@orange.com
To: Ted Lemon <ted.lemon@nominum.com>, "Zuniga, Juan Carlos" <JuanCarlos.Zuniga@InterDigital.com>
Thread-Topic: [mif-arch-dt] sections 4.3 and 4.4
Thread-Index: AQHOq06CsqevsP14XkCyJmOUw6WCV5m9EmZA
Date: Mon, 09 Sep 2013 08:35:36 +0000
Message-ID: <4142_1378715736_522D8858_4142_270_4_81C77F07008CA24F9783A98CFD706F7111D1C6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <Prayer.1.3.5.1308010729000.16712@hermes-2.csi.cam.ac.uk> <COL125-W16BB859A16CE25C980383AB1340@phx.gbl> <D60519DB022FFA48974A25955FFEC08C054A3B51@SAM.InterDigital.com> <CBB0A6EF-8171-4714-B565-487D2E47AAE3@nominum.com>
In-Reply-To: <CBB0A6EF-8171-4714-B565-487D2E47AAE3@nominum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422
Cc: "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>
Subject: Re: [mif-arch-dt] sections 4.3 and 4.4
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2013 08:35:53 -0000

Hi Ted,

Actually, we have described current behavior where terminals do not have simultaneous connection to more than one PVD. This behavior (attach to the PVD, then perform connectivity test) is clearly not what we should advice. Section 4.3 was supposed to  give recommendation: basically, update routing once targeted PVD has been checked and confirmed. Apparently, current text is not clear enough :-), we will revise it accordingly.

Pierrick

-----Message d'origine-----
De : Ted Lemon [mailto:ted.lemon@nominum.com] 
Envoyé : samedi 7 septembre 2013 00:15
À : Zuniga, Juan Carlos
Cc : mif-arch-dt@ietf.org; SEITE Pierrick IMT/OLN
Objet : Re: [mif-arch-dt] sections 4.3 and 4.4

This looks fine, although in section 4.3, I would additionally suggest that you advice implementations to not actually enable routing on a PvD until the validation has been done.   The way you have worded it currently seems to interrupt service and then restore it, which is the wrong sequence.   Of course, the argument can also be made that we shouldn't be making recommendations in an architecture document; this stuff might be better worded by identifying the problem and talking about ways it can be addressed in the context of PVDs.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.