IETF Logo Mail Archive

Re: [netmod] Liaison statement to ORAN

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 18 November 2020 18:01 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B3B3A02BC for <netmod@ietfa.amsl.com>; Wed, 18 Nov 2020 10:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Us4f7T1n3vtT for <netmod@ietfa.amsl.com>; Wed, 18 Nov 2020 10:01:39 -0800 (PST)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 739CE3A0114 for <netmod@ietf.org>; Wed, 18 Nov 2020 10:01:39 -0800 (PST)
Received: by mail-pl1-x62b.google.com with SMTP id x15so1422498pll.2 for <netmod@ietf.org>; Wed, 18 Nov 2020 10:01:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0kHpp75E3hgxXkbFYI2t7on+5mySsG485PLVt4rEWiU=; b=swXI1+xUGXA/v9yx3KhIi2FHIKfSCXF+U++Feh7zjAjztfx+qvypEaOujYRgs7zqQq CEQzPio9FziTv06I/z2MvsuezrzJrrRQe0EKmVtPYeZdWMYem/J0RX1X1tuRbo4fVBA8 O8U0kSS1ap9pL/TiyxGSTyESvGi92q8yvPdk1g+5rbaBgj9uZwY0WTM8KiXeUfTun3jg 76BAlrAl/r2kFhQ72kBjmJwHdceJbi9CmirKYziU5THCdUJzCtD9ApZpHXn4LriDlhcj T1jSCB7Q6cpcDC6ZkVSkpNIpg7vISSGF/XPtE0Ffj4dO8sXS5lJa04cK10Iq3OAFxZGe ca6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0kHpp75E3hgxXkbFYI2t7on+5mySsG485PLVt4rEWiU=; b=VTo/taSpYJqJdeMLZ9brYuYYA3o3CqMZ5e1levQ27kQE7D4FPhzMzQWp9Z5Tm1R9vF lN/b08IuGiGP52RgnqZrbKuiLFc+/MH16Xo7yP+HkRxKaSsgYRp1r86h6IAg41gI1BIk uf2aGV78Tpsz+TRGOWjOUEtdfBFocaikA6AJacbGDKiZqUTrUxobIvGwQ7EFogSYUt0D tJSxLiNvTvXC3gM1lsGdFBxRskd8X69P/vvf9Bd0HNH85cKW/8SNlSBRT0hhmG5aN3ZF ACk/ebq6yhZPCpLezSQkoQNo78T08oiqb+dVture/EXhcVcgwke1Ap6o30NPqKi/IuQd sKfA==
X-Gm-Message-State: AOAM533lVn5OU9e4h0oRwvuXMtpkKQZo3kcmSPlcP1F44/+A9AL3A5Nb uJT6ANDoxIvuQof7S0iQ6kY=
X-Google-Smtp-Source: ABdhPJws4ZBVvpbHTsXPguUYfcAXpIrGJHSPYfRUldh/jSG4l9jrnlTMtF5mkEyE8vG6fRfaUoH/Nw==
X-Received: by 2002:a17:90a:4a15:: with SMTP id e21mr246023pjh.130.1605722498753; Wed, 18 Nov 2020 10:01:38 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:2485:c867:3b9b:cd9b? ([2601:647:5600:5020:2485:c867:3b9b:cd9b]) by smtp.gmail.com with ESMTPSA id q23sm26124674pfg.192.2020.11.18.10.01.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 10:01:38 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <113ECC11-DEBB-489E-97B7-678D652EA74A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_69B7A2B5-E8B4-4A76-BB87-E168666824E8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 18 Nov 2020 10:01:36 -0800
In-Reply-To: <AM6PR0702MB3557C0E208983E81051A16BDF0E10@AM6PR0702MB3557.eurprd07.prod.outlook.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, Robert Petersen <robert.petersen@ericsson.com>, Jacqueline Beaulac S <jacqueline.s.beaulac@ericsson.com>
To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= <balazs.lengyel=40ericsson.com@dmarc.ietf.org>
References: <AM6PR0702MB3557C0E208983E81051A16BDF0E10@AM6PR0702MB3557.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/e4F6lidhcksZ4XX9LQXyj6g2lys>
Subject: Re: [netmod] Liaison statement to ORAN
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 18:01:42 -0000

Hi Balazs,

Do you have an example of where O-RAN is trying to deviate a 3GPP model? I would agree that for O-RAN to deviate a model would be a problem, and that it should be left to vendors to decide if they want to deviate the 3GPP model.

> On Nov 18, 2020, at 12:09 AM, Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hello,
> In connection to the draft https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01 <https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01> I propose to send a liaison statement from IETF Netmod to ORAN.
>  
> The issue: 3GPP is standardizing a good number of YANG modules as part of the 3gpp TS 28.541 and 28.623 (https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models <https://forge.3gpp.org/rep/sa5/MnS/tree/Rel17-draft/yang-models>). 
> ORAN plans to re-use this models, but possibly refine them in some ways. They are considering using deviations to do this. 
> E.g. change config=true schemas node to config=false. This creates problems as documented in https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 <https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1>
>  
> -   Deviations by an SDO (standard defining organization) prevent implementations from reporting their own deviations for the same nodes.
> -   Deviations by an SDO prevent implementations from conforming to the standards specified by both SDOs.
>  
> To avoid these problems I propose to send the following text to ORAN:
>  
> “IETF NETMOD working group requests ORAN to avoid using deviations as part of its specification. As documented in https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01#section-5.8.1 <https://tools.ietf.org/html/draft-ietf-netmod-yang-packages-01%23section-5.8.1> the usage of deviations would prevent:
> Vendors to implement their own deviations for the same YANG schema nodes
> Vendors to claim conformance to both ORAN and 3GPP specifications which are in some cases used as a base for the ORAN YANG models
> Note: These problems with deviations exists even if YANG modules are used without using YANG packages.
> Regards Balazs
>  
> -- 
> Balazs Lengyel                    Senior Specialist                       Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com <mailto:Balazs.Lengyel@ericsson.com>
>  
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanandani@gmail.com

v2.1.27 | Report a Bug | By Email