Re: [babel] proposed info model change

"STARK, BARBARA H" <bs7652@att.com> Thu, 18 February 2021 17:30 UTC

Return-Path: <bs7652@att.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C686C3A1492 for <babel@ietfa.amsl.com>; Thu, 18 Feb 2021 09:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com
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 aPhgs1h58ks7 for <babel@ietfa.amsl.com>; Thu, 18 Feb 2021 09:30:17 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEC13A14AF for <babel@ietf.org>; Thu, 18 Feb 2021 09:30:17 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 11IHPaUj026417; Thu, 18 Feb 2021 12:30:15 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 36sscemgtk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Feb 2021 12:30:14 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 11IHUDhN029466; Thu, 18 Feb 2021 12:30:13 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 11IHUAHH029337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Feb 2021 12:30:11 -0500
Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id D432D4009E67; Thu, 18 Feb 2021 17:30:10 +0000 (GMT)
Received: from GAALPA1MSGED2AB.ITServices.sbc.com (unknown [135.50.89.121]) by zlp30487.vci.att.com (Service) with ESMTP id A87B84009E65; Thu, 18 Feb 2021 17:30:10 +0000 (GMT)
Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGED2AB.ITServices.sbc.com (135.50.89.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 18 Feb 2021 12:30:09 -0500
Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Thu, 18 Feb 2021 12:30:09 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.106) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2176.2; Thu, 18 Feb 2021 12:30:01 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eMocHptXMax6Nig0pGpLTy56H+L7jm4jBgX1Z6v9vYPyOLb86iU4y+lFfniFernW/7eTK/uSWsIPa5TITzXQr6koY3e3hZkbauLBbKIy0HuXcK5B2imlV2umnDSwX8PqxjigSyumX9ROcy6KYKEK7w/nb8TorrneuQWA1s+FfVoKRv3H34FFXVk7Wtde2rPsWipy2Erh8js/73W1cq5M4XqDD3vlsSs/XGDhppb7WPFBmjCFF3CrYmP5EtjbBPrJPZ4A+qoAe3uy/bXWvEGyfYjFp0grUE6tMpx6YX7f6LdP8pAEdGQ68NGL3wFXTnPDsDh6y0UBYx4BJEPNpGQrCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7iUamwx+TkpYSp3V3Xaep6H7qq+MwPrhfEh4+B0cHJk=; b=G275FxOuBCX3wjh9aPXZvYFN03R2dWaXUYihZ2EfHdKx/kUdL4VCp3JnLM6tkeeZLazX1SRT93+XX39l5YCwA7aRB3ZmtgjtoMGq+QGbOnU9fwhuRv3LQ10KhrotWq9Atvk9o7pUUx3lJ6sYi4LUbU7Hu8Uh8oXf+fCHW5hVyl9JK8Me0dz/2mUwkadussXDx+gMOqqzYK1RtIuTrphfUYHDIamiEpfIFJ1O2xasB0qhnphmElgMgP7VwsP0L5h7uZzKTPZU9raBoKt6CM4DDZRWJNnO6MqQ1U8XmxULCZLq7Fzp4GZ4ydJKvSSZomtofPhmKVrbYK/FpK049nnLtw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7iUamwx+TkpYSp3V3Xaep6H7qq+MwPrhfEh4+B0cHJk=; b=BjK+dqkpuw0ptOxLVjAmixBB/pdoXuyGKVli1vgMGjkK41rMl5lSSi5tPmpsaGwQ0bgRnyAr0JBvq/R9ewX6j1ocxC+w0lgWtxUjOu1G9YX5b69TLnVahUbGtNjYE4Rtcwjkwv0lUvKcKp2RaQrvrSoAj5a1FDvFFfUOvAO2i8Q=
Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6953.namprd02.prod.outlook.com (2603:10b6:5:253::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Thu, 18 Feb 2021 17:30:00 +0000
Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d9c0:4a62:170b:b925%6]) with mapi id 15.20.3846.043; Thu, 18 Feb 2021 17:30:00 +0000
From: "STARK, BARBARA H" <bs7652@att.com>
To: 'Mahesh Jethanandani' <mjethanandani@gmail.com>
CC: 'David Schinazi' <dschinazi.ietf@gmail.com>, 'Toke Høiland-Jørgensen' <toke=40toke.dk@dmarc.ietf.org>, "'babel@ietf.org'" <babel@ietf.org>
Thread-Topic: [babel] proposed info model change
Thread-Index: AdcAt7RXNVd/4GG3Sr6eZ25X+veoLAAAvs0AAABUpAAAAVQxgAAKytMAAAXOZYAAEdtlkABB3f0AAMe/uMAAKmIhAAAAHHOA
Date: Thu, 18 Feb 2021 17:30:00 +0000
Message-ID: <DM6PR02MB69247E8F3F7499A524847D8EC3859@DM6PR02MB6924.namprd02.prod.outlook.com>
References: <DM6PR02MB6924E3E2DD5568E247859E18C38C9@DM6PR02MB6924.namprd02.prod.outlook.com> <87blcqpau7.fsf@toke.dk> <E5F69D0C-7130-42D3-9080-C2EE5786D917@gmail.com> <878s7up8n0.fsf@toke.dk> <CAPDSy+6YWPr81uKHrWYoY=TZ0A18A_Ui3=CyLP=1K-ezwmgF-g@mail.gmail.com> <DBBE09E1-F407-4B5A-A096-669E74F25FB4@gmail.com> <DM6PR02MB69249CEAAB32A391274A8ED3C38B9@DM6PR02MB6924.namprd02.prod.outlook.com> <CAPDSy+4uor1P_HiKGEMOTihq+0gb_wuQU21shpgDmVQHNnfv3w@mail.gmail.com> <DM6PR02MB6924B3EDD46D9AD542CA06A8C3869@DM6PR02MB6924.namprd02.prod.outlook.com> <0E5484EE-1465-4E22-B021-AF430B6DA2C7@gmail.com>
In-Reply-To: <0E5484EE-1465-4E22-B021-AF430B6DA2C7@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com;
x-originating-ip: [45.18.123.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e070df4d-7d1b-439f-e320-08d8d432d1bd
x-ms-traffictypediagnostic: DM6PR02MB6953:
x-microsoft-antispam-prvs: <DM6PR02MB6953E913CF3A43873EA1591EC3859@DM6PR02MB6953.namprd02.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uY8twF5d0qQo/nG8AuIq4ebCtX0E0UcxOYVEhTngSkXb50hXSCVLZXNeJ9QndHbiNRHkTLA172k7Ff+ZVJhGl/j5d+CTs7xEirDzvE+nyN740++QUx4NreKw4GBHQ2OHw8oGH++6zuofOW4O5mGoTgLIy4gs296rv3ADtOrOqNo45yNd/3q6KaNhUzT/mBgfrhuWk8kbqtcfCyQbEkc2qY7CiUgnK9T4/THgub2CpizVMFIQ3dI8yurBoUo6gAGyr54I2XTwmlQcvF2IjTYdh8XaGMjFPe6u6ySt4ww5JHc1BkrE2mYlZmaWpxYRQI+XjqUK9B5jISrDnBTAvnAYldErF7JQPcM1DB4/oQMF5LvhYX5M1icr0z2vrITFENMxC0C8k2Kh6X/b6S3bcTnGg8x7pXFL0jRPoee00xIxFKT7YTUqklO8OX+BZspoN+ej7hvLJl/H2osum7jLXzjszozZeInNfTb3kJFdyuiz8dispN1YFB5YUSV7UwEfqUOQYPJ2N0tWxVPd2yCsM4o/9bak/psn6R1sHCyDKaUNBXV8CuLDRJcO+k2zjsVdXgTtD7HvDcPFtOOq7m0RdQ4Ki7Fx0PxNna6U5oLWJfyjjyw=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(376002)(366004)(39860400002)(55016002)(86362001)(6506007)(966005)(166002)(53546011)(76116006)(71200400001)(4326008)(66556008)(186003)(7696005)(64756008)(8676002)(5660300002)(54906003)(6916009)(8936002)(66446008)(316002)(26005)(9686003)(2906002)(66476007)(33656002)(66946007)(52536014)(9326002)(478600001)(66574015)(82202003)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: jqr4EKFCiASUVsOMOCJKmVb62StznAnGw9Ia2Gy3Db/4h1ChLVC25TYgIAkMTIItVepnMt+N1bKWUUYqqNjtB9dHIFPVaKVYFc+2HKl8gMWwOmLcFauymn079ZhFW0sEN2ONs7uA7ct8NlWheFL2ZAVDfwnWFzH+YehipS6QAvZmDfvK6SNJg8AeQ+JhW8fRW1BB575KtYcXDYd7KYsXsw3LoUaCrDEY8juiQEXkzpj6yAJGojUqrR3C8iCg60FrttkpcpRRAQT9r7Thwlev19w0dPpixmC+018clq04XVYmxAIuiP2mflmekiZ1kua8qQ9sEbdwaBSACW8PN8OovYdrYpECg4tmJhxFqVf+VEj0Hrc/u5KfEt92QA2Fef8IefIgHJdAd8gmPWozhVAqw0/nyYZPaizo/vKGkaJgGBhvR++zIPogSjuU8nZGjrlW6Z0sjYQIS8mGg6mEvbVpNQNpKz8Gzc8UVYPhmCxUQEkzlW8P7S2kLwXhVSattIJxqk4REaBhFtrfxYqgZ/fwrb0mQpJUpxjVyF9AbhM92yXn7ogXZ/ZijpMGYN0MtYgyyx66GbY0emNAJZyRsm/dqnKw23zM+pD0X1qVtr9knef9xAhYNucrUtskDRBlKZ4pegPhdwXuh9V224lgzQhhLdz8dXIp2My/igZcN19oXJaX7h5lSw2pqF/9kl23LhByp/5K5/WrpOsXFX+a9G/qS5ekNkFq2QyzeZobch1JZWCL1TXg2wzlT4IsbNIjjlY5rGJ+/YU049MR9KbrIbjJDi5TzzV5iZEMaaTavO4CC9hnGkDPXcK9h0GmDUz1DY7fHCBqQN3/slZMuKZ7z0Oua595ERQE/5YWxQQ/YKJhpzDL4j0SOwOzsxg3GWrQVQv0hTZ9fLrU4nlbj253ohHK6Zi5phZygZbw8n4RLt5mYTT/fnIRxGIzvNmYN7RBhgUNoC8iIUsheV4NR1GBNjnK4aBDe3Kb0tSZxTOKZmNLfnUYvMJQe62n7UVn6WLDaArIjnNzQIqiBXk0149e8LzI9oBM5Q5yZSTNIYodJvIwWYfd9x4pU5GEqKoOTwW7RS9gHEqgh2metNFesYxfYuKEdlkforidgMggJQA7hkur8O0+E3nw5FWDEbNoVePDkynl8iUPjjbnRf9ip+vIq1r8Smj+M1XzzRFht48Yw4nZQe4rnghK5REMYRF9TwsGIRaVIzUCUbQtz8uw7uV9WjmNYq9UOEZLh7rwWvmOcqhvdw1tE28kmoIpyGHGXrNJv/2wRoTIQzfUyMpxhrkX4eXQ3LPelVcG7EJoPSGJ9ba4OD5tN+RvNeuRKs+sdS4Hvq4W
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR02MB69247E8F3F7499A524847D8EC3859DM6PR02MB6924namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e070df4d-7d1b-439f-e320-08d8d432d1bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2021 17:30:00.4096 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vcalToaBduKTp+ZETmA+JNdAczUfkxBxyJwq7EFGk59CeQ0xhn9Q12C8ccDN6bJx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6953
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: E04CBBD8082D8B723A9428295B22D605DA599E9F6B3BBCBBF3F62768F0EB79582
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-18_09:2021-02-18, 2021-02-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 adultscore=0 bulkscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102180144
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/XsIIHgmA3sLBhB-UVoWcS-aEp2o>
Subject: Re: [babel] proposed info model change
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 17:30:20 -0000

Hi Mahesh,
Would this still allow the YANG model to use the router-id as a unique key?
Barbara

Hi Barbara,

Thanks for circling back on the question of router-id and its impact on the YANG model.

Based on the discourse on this thread, it is clear that the “router-id” has meaning when the protocol is enabled. The YANG model can therefore add a conditional statement, i.e. a must statement, that allows the read of the “router-id” only if the protocol is enabled via the “enable” flag.

Is the WG acceptable of the change?


On Feb 17, 2021, at 1:17 PM, STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>> wrote:

I’d like to circle back around to Mahesh, then, to see if this change is really a good idea from his perspective. If we do this change, then it means an implementation could start with an all-zero router-id before its enabled and then generate a “real” router-id when enabled. Which was what the original all-zero prohibition was trying to prevent. If this is acceptable for YANG (to have a changing router-id), then I see no need for any prohibition in the info model (because the protocol spec will ensure uniqueness when the “real” router-id is generated).  If not acceptable, then it seems to me we need to keep the current info model all-zero prohibition.
Barbara

Ah I see, thanks for the explanation! I'm fine with the change then.

David

On Fri, Feb 12, 2021 at 6:43 AM STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>> wrote:
Just to be clear ...
An enabled Babel instance (that is sending and receiving Babel packets) already has a requirement for unique non-zero router-id. Where we were having a problem was with not-enabled Babel instances that weren’t actively running the protocol (had maybe just been installed). I think it was babeld that was just using a default of all zeroes until it was enabled; at which time it generated its unique router-id. With this not-enabled “zero” default, the possibility exists for multiple not-enabled Babel instances to be defaulted to zero, which would lead to YANG having a problem with having a unique router-id to identify them by.

The fact that the Babel protocol forbids zero valued router-ids doesn’t mean not-enabled instances can’t have that as a default; and it doesn’t prevent there from being multiple not-enabled instances with a default value.

TR-181 doesn’t have a problem with this, because it uses a unique key distinct from the router-id. The Babel protocol spec already has what it needs to make sure the router-id for enabled instances are unique (and the data/info model doesn’t need to be involved in policing this). So this really is just about making sure the language is suitable to ensure YANG can use this parameter as a unique key, without putting constraints on the protocol. If YANG were fine with a Babel instance that started with router-id zero and then changed to something else once the protocol started running, then zero wouldn’t be a problem if there is just a single instance with that zero value.
Barbara

From: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Sent: Thursday, February 11, 2021 11:56 PM
To: David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>>
Cc: Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org<mailto:40toke.dk@dmarc.ietf.org>>; STARK, BARBARA H <bs7652@att.com<mailto:bs7652@att.com>>; babel@ietf.org<mailto:babel@ietf.org>
Subject: Re: [babel] proposed info model change

Hi David,

On Feb 11, 2021, at 7:09 PM, David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>> wrote:

We banned all-zeroes and all-ones between draft-ietf-babel-rfc6126bis-00 and draft-ietf-babel-rfc6126bis-01. If memory serves, the idea was to reserve them for future extensibility. Also, banning all-zeroes allows using that as a sentinel value in software.

Adding the uniqueness requirement sounds good to me, but removing the ban on all-zeroes/all-ones could lead to problems. If the core protocol doesn't allow it, why should the informational model allow it?

If the protocol banned it, that is a different question, and info model can reflect that. I just wanted to point out that it is not because of the data model.

Cheers.


David

On Thu, Feb 11, 2021 at 2:00 PM Toke Høiland-Jørgensen <toke=40toke.dk@dmarc.ietf.org<mailto:40toke.dk@dmarc.ietf.org>> wrote:
Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> writes:

> Hi Toke,
>
> The rational has to do with what a data model like YANG does with
> router-id. To it the router-id is a key, in the form of a string. That
> string has to be unique. YANG does not prevent it being a string of
> zeros or ones, provided that string is unique. Thus the dropping of
> the "MUST NOT” and the addition of “MUST”.

Right. I seem to recall there being some other reason why it shouldn't
be 0, but can't find the discussion now, and looking at the code that
doesn't seem to care. So no objection from me I guess :)

-Toke

_______________________________________________
babel mailing list
babel@ietf.org<mailto:babel@ietf.org>
https://www.ietf.org/mailman/listinfo/babel<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/babel__;!!BhdT!3HjRHugiRwRBmxjH7eRjssZBgzbBm5snhzyvT2apBtscBdcCqo2THFENFjzZoA$>

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>