Re: [netmod] Liaison statement to ORAN

Mahesh Jethanandani <> Wed, 18 November 2020 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1B3B3A02BC for <>; Wed, 18 Nov 2020 10:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Us4f7T1n3vtT for <>; Wed, 18 Nov 2020 10:01:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 739CE3A0114 for <>; Wed, 18 Nov 2020 10:01:39 -0800 (PST)
Received: by with SMTP id x15so1422498pll.2 for <>; Wed, 18 Nov 2020 10:01:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with ESMTPSA id q23sm26124674pfg.192.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 10:01:38 -0800 (PST)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_69B7A2B5-E8B4-4A76-BB87-E168666824E8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 18 Nov 2020 10:01:36 -0800
In-Reply-To: <>
Cc: "" <>, Robert Petersen <>, Jacqueline Beaulac S <>
To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= <>
References: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [netmod] Liaison statement to ORAN
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:
> Hello,
> In connection to the draft <> 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 ( <>). 
> 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 <>
> -   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 <> 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: <>
> _______________________________________________
> netmod mailing list
> <>
> <>
Mahesh Jethanandani