Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> Thu, 08 February 2018 08:28 UTC

Return-Path: <bart.bogaert@nokia.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 0AA99126D0C for <netmod@ietfa.amsl.com>; Thu, 8 Feb 2018 00:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 P6qfya-o6sON for <netmod@ietfa.amsl.com>; Thu, 8 Feb 2018 00:28:08 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EFB120726 for <netmod@ietf.org>; Thu, 8 Feb 2018 00:28:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MsMMpUd88fQ+ZHO6FByWLNVBIDCeImSCkdwJ4mrYb9c=; b=HqA5r8fyyW6ial9A0U19w+QOS9Aq8Oq9RBpvGZ0bWvLIi8LSh4gErfMmSyExIqSKWnOb1cz8QXcXZDWWRhnAa0OEn6eLrVRA8ruZW1KGB5dxdDvhBnv0Csag0RM6uULf+lc6WObB1BtSKmHpYBFRALkAcYCsZygtAY8iMDyTKtg=
Received: from VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) by VI1SPR8PMB116.eurprd07.prod.outlook.com (10.163.248.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.5; Thu, 8 Feb 2018 08:28:05 +0000
Received: from VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1]) by VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1%14]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 08:28:05 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos
Thread-Index: AdOgqtnl8wUy/91/QhiSAjsfnnWWZwAC04gAAAAQeSA=
Date: Thu, 08 Feb 2018 08:28:04 +0000
Message-ID: <VI1PR07MB17251270C3FBF4469DED474394F30@VI1PR07MB1725.eurprd07.prod.outlook.com>
References: <VI1PR07MB172523110F57300A070A102F94F30@VI1PR07MB1725.eurprd07.prod.outlook.com> <20180208.092354.1733219897860431005.mbj@tail-f.com>
In-Reply-To: <20180208.092354.1733219897860431005.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.245.212.218]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1SPR8PMB116; 6:pKGU9In4W061PGsNNd7lRKs641iUJZ+dz6bMfUQMc/hWOw3Bv22EqKeUdBstXH7jQbRQSziePfBOXDSEs3Jr0FlU2VEGpt+mM9EQtiQrVaV0o0zMJzEG3rMqWRcePGvxO5qEvEoj4ukGIOPpYEEhPwUUTKJA6vn3o8LsLGT86AoUBRDy291Ol633OvY0WYUmPbBUcFpUgUyAwOzI01b3f84ny15nAz9sPcbNgvkUGapucvxz5eYFxJxpfX/fZsnlOKzwNq3Exh0vUDUi6iz0HBgPdFwNT40ERA6MOJJY4wsU+gfBmxx+D7zBP+GBk6hrkRAlK5QOJmySA56HtsUhYWCjY7ix3QZf2DYXwfZ4FZsLLnP/+FSZxUA1iYRoF94d; 5:ZkzKEnyaQWvnt4i2q2KhXNNaOzD6HtifOi4gQM09CjbckkC1Js/Xg4y5kOxred2rLfGHylyI8ogxeHAmQTYQy+xhLLLcLQ2PZPI9XJQVifgChZA2UEVXtJ971pFDxaByk6WmHWvM/TZUc6ohdeZS1hVsK5yQOt7soTaCXYmju80=; 24:rAcmyeyyAghVzTnOw1RBFd8tUiewojv+IuRUStZ2NyPIXSVHJGGDywT4z96g9OTpr9azRQ8Iwt10cHP+ORceJ7HPstpD7Z2H0q7DQhlcVPs=; 7:XDrngPuNuBCSMho/TXMOR0lkP65bLYpvj5uVhEByw/ar+MWPZD8HVmojcOWmIqoKCx0KRlMd/GU5t51MRjgacIagGVKgFvT8SPtEzmPeXPiD1IQE9sa6Vw87Rzz3XHWh5aX//DO+NO/dm6TYb/8C2Vl9gQd2ogO9WCLPFCSwliM3KWgeFGoL6iWuuS83reYhwCNZc4JWr2DsXz5WMuUd7HNixK2SNnQM616N4j6+Y+d1heBtDgtUDq/uCxseGQVz
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: df7931fa-0e89-4866-ef00-08d56ecde02e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:VI1SPR8PMB116;
x-ms-traffictypediagnostic: VI1SPR8PMB116:
x-microsoft-antispam-prvs: <VI1SPR8PMB11692C8026E070D58BDAEEF94F30@VI1SPR8PMB116.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(82608151540597);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(11241501184)(806099)(2400082)(944501161)(6055026)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:VI1SPR8PMB116; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR8PMB116;
x-forefront-prvs: 0577AD41D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39380400002)(366004)(39860400002)(199004)(189003)(13464003)(229853002)(74316002)(7736002)(5660300001)(9686003)(97736004)(6116002)(6436002)(55016002)(7696005)(68736007)(66066001)(26005)(2906002)(6346003)(3846002)(102836004)(99286004)(186003)(305945005)(76176011)(53546011)(6506007)(316002)(33656002)(4326008)(81156014)(81166006)(8676002)(6246003)(86362001)(5250100002)(106356001)(25786009)(105586002)(3280700002)(478600001)(53936002)(14454004)(3660700001)(6916009)(2950100002)(2900100001)(8936002)(145543001)(145603002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1SPR8PMB116; H:VI1PR07MB1725.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com;
x-microsoft-antispam-message-info: qpGF3Q9uJFrIwE0YNS2Pwz0dZVT2RE5WqWo8AVhUfJHZvWF6do3JHJoFirhRlVbPQ21q43vYiiMAi/kaemP8p7Rete5lMENd/4TVBdgl2s7t5Zg31hE2Y3nrJe2xqmst
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: df7931fa-0e89-4866-ef00-08d56ecde02e
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 08:28:04.9753 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR8PMB116
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NZG-2lWCP-xturAiHRFl2oasNAw>
Subject: Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 08 Feb 2018 08:28:11 -0000

Thanks Martin, this makes sense.

Regards, Bart

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Thursday, February 8, 2018 9:24 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.bogaert@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> wrote:
> Hi,
> 
> During implementation we came across the following anomaly:
> 
> According to RFC 6933 entPhysicalParentRelPos the value should be set 
> to -1 in case there is no parent.
> The hardware YANG model defines this leaf as int32 with range "0 .. 
> 2147483647",  To be in-line with the referred RFC, shouldn't the range 
> be extended as "-1 .. 2147483647"?

In MIBs, people often use special values to indicate that the underlying thing doesn't exist.  In YANG we try to avoid this, and instead not instantiate the node.  This should probably have been clarified in the YANG module.


/martin