Re: [netmod] guidelines for top-level nodes in RFC 8407

Per Hedeland <> Fri, 22 March 2019 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 867571312DA for <>; Fri, 22 Mar 2019 10:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 laq825RF35tn for <>; Fri, 22 Mar 2019 10:09:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC5F01279AA for <>; Fri, 22 Mar 2019 10:09:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1553274564; cv=none;; s=arc-outbound20181012; b=Z4U0SkC8FbipxJDPoiNPNM96AAidrGMe7s9xLmDJ1TjvDKQboGBXRpY0cPgN5oCnotZ8VBhJAzW/a TXGETqtAYd7XL2mL5UEB+SHFb7SenZ335/OOoAjiSqG+BI2wvq8L//oz+BSrQPUU6Ekxx3+0aA3Qb1 MHdLA3Ym2VhFKRjYDaIiKq/vrLqW8QHpsxPvzGdW6h3+ZGI6r1in0nwjckzy4q/05LzeqaAuVJwch6 V6pmFC4vQByBv/Ip18nsANOpo7hrWbA1pD9hM+zC3/8AZM1wLfP7FuXS0ZFigdHBe4BbhJBmXEIBXD 8Yae4tBkACart8+wRCZTvZYsNvU3r2Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:dkim-signature:from; bh=CJXJeDfaG3vZn/snurxNPcTCpZ/3ULKGkzi63NpYU9Y=; b=OvoE7lXCB+OWhgP52ZoYQBlORlj2VVJ+TO8sY2WBQ9v/AQCwLIneFTtlRMeCZPRas3qQKn8t95kAL IrCLEaDc/QtXCSqM90lIUmRD8IKKoP6ETUGJesg3rS1rC95vOj4oiILfe1VaRwTHMHySc3k0/kn/8v yZaFcAFRm5EEoGt/0CXzTET1teeQ8ID9WMyhtxGLLlb7XCNGOIzpwKolH+5xbpRQrHwIL5k7RQQ7fW qp6kTFTuJc93WhGCiTGvXnlQ6wBLNiXAE5ahSDhonIXWYDouFRs1puS0hyh1IemRAuq/TPe3dRVV8w tfmt9PoBm4mHwndwDxy8f7JbkhYCGEg==
ARC-Authentication-Results: i=1;; spf=none smtp.remote-ip=; dmarc=none; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:from; bh=CJXJeDfaG3vZn/snurxNPcTCpZ/3ULKGkzi63NpYU9Y=; b=sM3vCyD+xqnEXxoOevUVDpgQY0WCgKHvP9aKf+OErLeKG4ZcielDBac7CmmRjh7uJmuN2uHzMciRq JaWe2zwBQflzWaSnZAs67YeT4tjXAFzsuu9MsES4yFFIbjRMINKPLVgYKjdzTYETZepMr8ur1IKGbk 3viYYGmZkHJEgU3L8h3OetHOcxZlBN9nRiws/SOFjUMu09QEY4l+5G82cpj+FaFs3Bmscdb9f2pc66 5D9dOd8Jfa4mOKnrOwdnGtXzTLw2XOHLHGiGH9EDMIVzMwHGWE6E0wXbihgvWBE1zsHm5IB/afFuAC 0FY2nZ7O+yvNlyYZwwC/l18QoIT6lXw==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 3c0451f1-4cc5-11e9-908b-352056dbf2de
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from (unknown []) by (Halon) with ESMTPSA id 3c0451f1-4cc5-11e9-908b-352056dbf2de; Fri, 22 Mar 2019 17:09:22 +0000 (UTC)
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x2MH9KMx025908 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Mar 2019 18:09:20 +0100 (CET) (envelope-from
To: Martin Bjorklund <>
References: <> <> <> <>
From: Per Hedeland <>
Message-ID: <>
Date: Fri, 22 Mar 2019 18:09:20 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] guidelines for top-level nodes in RFC 8407
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: Fri, 22 Mar 2019 17:09:29 -0000

On 2019-03-22 14:45, Ladislav Lhotka wrote:
> Martin Bjorklund <> writes:
>>>> IMO it doesn't violate the spirit of the rule.  So the question is; is
>>>> this allowed?

It seems to me that it would make sense to apply the same logic as
for "remote" augments to this rule - from RFC 7950:

    If the augmentation adds mandatory nodes (see Section 3) that
    represent configuration to a target node in another module, the
    augmentation MUST be made conditional with a "when" statement.  Care
    must be taken when defining the "when" expression [...]

I.e. the answer to your (original) question would in that case be
"yes" (at least for YANG 1.1 modules...).

--Per Hedeland