Re: [netmod] two options for removing /foo-state trees?

"Xufeng Liu" <> Fri, 08 September 2017 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57AB4132F0F for <>; Fri, 8 Sep 2017 13:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 u0sT7Vc02myd for <>; Fri, 8 Sep 2017 13:13:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93806132F09 for <>; Fri, 8 Sep 2017 13:13:00 -0700 (PDT)
Received: by with SMTP id c80so7898321lfh.0 for <>; Fri, 08 Sep 2017 13:13:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=eNLpSXPD4WUGyy7kEA/LBli90NrAZl4BO000sCqSn9s=; b=KimBqP5OAqkNLydvj+ldY29vOWmz9+QIsuMCuXWpndr3gKeFuUu5tOcqAVJ293RwQD KpjLM+ymX2jK8lPwHnQTxQJHkNO89eTkN9lzn2tWAZ4qfED0BRACqNG4SKIi8wsn0DGk 4fy8OC14LRKeUx9NJeSgSTX2diKMj5zeT2MbcsIy4rR1ZpY7NPaOVndwxDFGhmXByv95 gr3AIWA6U7BHTzhZQe3V4rAfIa0dGpMtezX1U5ADp/F+rt6j72IN2G6NfnTXMhw6z5uk J3bquUvE+5N5q3w+HnPjXGKJAE+vgDMRf/qH0mEWnP+4Hlr2AalO2K6JCUKrstVqAooG UiWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=eNLpSXPD4WUGyy7kEA/LBli90NrAZl4BO000sCqSn9s=; b=lShNgVbIAHDv5mxJ4LPoh9hjHXeNu9pvC3ZYT+aRKm5o4eLhz6AiEIddyRd+u53tHm KYGzxP3Ag5I/0r8M24aodD513fAmNe8bL6gAQTiholNtousG0HjQHAUPEChfhmIuvRYZ EvC2L3tsZhJ504vsswA0X5WQsjx/JxmixeGG24JhSGvgAejUdFgdR4MEoUBZhHIl24Wl Ju313HU9EKE3TgYjsMPdXyb3MUpRajkyD1QKP19FSanklLHoHUvPMBLQAUJSkTUjJU0T aWTxXiR3jB2wQAWe2AMvb69Jo4tSXHv2fA9+ozWybTG6hq+ljG2o4GiSx2m0aQZnDG5C 4O3Q==
X-Gm-Message-State: AHPjjUj7tpB8auIy0mjYtRXuF3g+a5Afyr+CIy9FbC0phV3Ywb1e8iv5 QomEFFUjcWG1mg==
X-Google-Smtp-Source: AOwi7QD7i5hMG0xUHp7yiS4jeRq1mqsD8kStQ/V3QgkUHX4yQKKtRYefieRGlqrYG+uAQcQSZ7twKA==
X-Received: by with SMTP id a6mr1200689lfe.171.1504901578677; Fri, 08 Sep 2017 13:12:58 -0700 (PDT)
Received: from xliuus ( []) by with ESMTPSA id k184sm432990lfg.53.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 13:12:57 -0700 (PDT)
From: Xufeng Liu <>
To: 'Kent Watsen' <>, "'Acee Lindem (acee)'" <>, 'Lou Berger' <>, 'Martin Bjorklund' <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Fri, 08 Sep 2017 16:12:53 -0400
Message-ID: <075501d328de$dcdd7cb0$96987610$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIfPr93bBhKKI6OBZkNVcz7tJHAsQEn1MPDAccctw8A+7iScAB3YJYUAmTm3XYBY450mKHR42Vg
Content-Language: en-us
Archived-At: <>
Subject: Re: [netmod] two options for removing /foo-state trees?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Sep 2017 20:13:10 -0000

A consequence of this discussion, I have a question about writing a model to augment RFC8022bis or RFC7223bis:

The new augmentation model is NMDA compliant, but also requires immediate support for "in use" and "system created" information, as described in Sec 1.3 of the guidelines ( 

In such a case, the relevant suggestions in the guidelines are:

(b) Write a non-NMDA module that mirror the NMDA module. 
    -- This cannot be done because we are augmenting RFC8022bis or RFC7233bis, which do not have the non-NMDA modules.

(d) It is RECOMMENDED to augment only the "/foo" hierarchy of the base model. Where this recommendation cannot be followed, then any new "state" elements SHOULD be included in their own module.

The question is about the (d) above. We seem have to augment the deprecated "/foo-state" branch, right? We would also have to use the deprecated “interface-state-ref”? 

- Xufeng

> -----Original Message-----
> From: netmod [] On Behalf Of Kent Watsen
> Sent: Thursday, September 7, 2017 7:28 PM
> To: Acee Lindem (acee) <>; Lou Berger <>;
> Martin Bjorklund <>
> Cc:
> Subject: Re: [netmod] two options for removing /foo-state trees?
> >>Does this mean you're okay reposting your ID similar to Martin's?
> >>I ask as a chair interested in starting the adoption process on these
> >>nmda-update drafts.
> >
> > I would hope this is not a prerequisite? We are evaluating how bad
> > this will be. I’d ask how many implementations there are of ietf-routing?
> Yes, please provide this info when you have it.
> >>> However, what about secondary and tertiary implications of moving to
> >>> NDMA? If we change a path from “interface-state-ref” to “interface-ref”
> >>> to reference an interface, I’d hope no one would expect the old
> >>> statement to be kept around…
> >>
> >>But the old statement would be kept around, in its deprecated form.
> >>Of course, the nmda-guidelines should cause those downstream modules
> >>to be updated to NMDA as well, so hopefully just a short-lived issue.
> >
> > This could be really ugly and cascade if we are just using a different
> > path for a reference. Hopefully, all the old references are in
> > deprecated trees. Otherwise, I guess the new data leaf would need a unique
> name.
> Indeed.  Let's see what the analysis reveals.
> Kent
> _______________________________________________
> netmod mailing list