From nobody Thu May 19 17:39:51 2022 Return-Path: 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 F4005C237CE1 for ; Thu, 19 May 2022 17:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZWgByHoZVGa for ; Thu, 19 May 2022 17:39:47 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598E0C1D5AAA for ; Thu, 19 May 2022 17:39:47 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id v71so11775343ybi.4 for ; Thu, 19 May 2022 17:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m97FCxQ5BYQGHUSw8vTgmjuc1svZf8QSkkhFtIEV+No=; b=vFPqtlCA3iB4C0lwk1twXDJzFtoH1JXq3vFo/UNlANwRFE4tW2b+bZH0iw0YTm/lBN LPo+5xSPS/5hsTun6C1ATbPwDAlUhLwU8PC4TWi0x58uLkpbBYMN+k/HY94hfPQYwBgI rUhNp7LhKy+o8vNGECKjOqkjSbexYVEtd/BVn8XnBNYu30a9oi0ea1ct5p96zli4tBTT gTvRtwYKFSgMtDvCQZ3Ra3k4hOvRAbzNdGTTDfCqNQEr35IvEMJkadt3Xw8CokT2J4qd rTgFDTEK+jqercn7/xbevxs9pVVj5IjjzpaKAkd/1B3gMw1YdmfoBPpffGnI6TQFOsZ2 j/gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m97FCxQ5BYQGHUSw8vTgmjuc1svZf8QSkkhFtIEV+No=; b=F8dfKoJSBVXbyyYYPzSX142VboauBwgoRSE4cjvcdUoznYhvolw1GkcJsJ3R9YU+f3 Bd2T3tZlUtEmBbay6TyYOM9uvL0JV9OnNN7IcLuRYGppm2f8jiedbpUmd/bWnP2UYYk9 fRscrs01/6HY1oT4FZ4k4qZYUUmw0UleWRnwzsDkKfwLh22XT1/i6MJZ8GSkV+agNyir r43U9meFj8aqC2eGMsx2AS8QpXVVh/6/ijMyXfTzEa/Nun5V8AKf/GCDe7Po7m113SQG 8Saa7Mx+v6CVhnjjDA51L5n2dM6eMAy3avBLtO6ZzEb22JnvQu/9h0R7IskenxT02XXL KWyA== X-Gm-Message-State: AOAM5317307PCpeqmlwJEzQCp7xPYuvbREJwTS4ApqgnCNaJuuZVXHA6 quiwzIqJEvZ3SVuIWe66ogkwjLevDkQWwc61Z/Dg8iu6buU= X-Google-Smtp-Source: ABdhPJzUvE5GV0qPIZzskQOJEDkdKakf1TJ3TuizQZSOQK2JJ2v4dk+vQloFAKAjNpyxOWDsy3u3sXWYjmB97ffHOwQ= X-Received: by 2002:a25:3b8b:0:b0:64d:f406:d3bf with SMTP id i133-20020a253b8b000000b0064df406d3bfmr7337062yba.430.1653007185839; Thu, 19 May 2022 17:39:45 -0700 (PDT) MIME-Version: 1.0 References: <01000180a9eb37cb-85b9c576-c1eb-425a-b42c-b3cabe548fbb-000000@email.amazonses.com> <20220518.080543.825575420363032441.id@4668.se> <01000180d793d6ee-f82a4a03-28d8-4f8b-909e-7306a7fc565b-000000@email.amazonses.com> <20220519.090452.636208001533389643.id@4668.se> In-Reply-To: <20220519.090452.636208001533389643.id@4668.se> From: Andy Bierman Date: Thu, 19 May 2022 17:39:35 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: Kent Watsen , NetMod WG Content-Type: multipart/alternative; boundary="0000000000001fa4b005df66bae6" Archived-At: Subject: Re: [netmod] Does defining a feature require the module be implemented? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2022 00:39:51 -0000 --0000000000001fa4b005df66bae6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 19, 2022 at 12:05 AM Martin Bj=C3=B6rklund w= rote: > Kent Watsen wrote: > > > > > Hmm, I don't remember why this was changed in RFC 8525. Perhaps this > was by accident? The only text I can find is this in RFC 7950: > > Not by accident. I did not want the new list. The main rationale was that the 2 lists needed different keys. The import-only-module list has [name, revision] instead of just [name]. 5.6.5. Implementing a Module > > A server implements a module if it implements the module's data > nodes, RPCs, actions, notifications, and deviations. > > Which seems to indicate that "implementing a module" is NOT required > for a feature to be supported. > Agreed. - 7.20.1, para 1: not specific to modules, refers to the model - 7.20.1, para 6: "server MUST support all dependent features". No mention of modules, just features. > > 2) If it is the case that the module must be implemented to use its > > features, then I need to update some of my modules (e.g., crypto-types > > and friends) to explicitly disable the protocol-accessible tree when > > the module is implemented *only* to use its features. > > Since RFC 8525 doesn't allow a feature to be supported w/o also > implementing the module, I think this is the solution for now. And it > is not wrong even if RFC 8525 was updated to support features from > imported modules. > Deviation-stmts would be required to "undo" the base module implementation requirement. Looks like RFC 7895 got this part right. The 'feature' leaf-list may apply to imported modules. The same feature can only appear once, no matter how many revisions of a module are imported. Andy > > > 3) I wish more modules would following the pattern of having the > > global protocol accessible tree be defined via a "uses" of a grouping > > defined in the module. In another recent project, I had to hack the > > topology modules defined in RFC 8345 (to convert the containers to > > groupings) to enable a multiplicity of "abstract network topologies" > > to be configured. The assumption that only a single global instance > > is ever needed is proving to be invalid in my work time and again. > > This is a classic problem w/ any model... And you can extend it to > other things as well, not only top-level nodes; whenever you define a > leaf, perhaps someone could support multiple instances and wished it > was a leaf-list instead? And in a leaf-list, perhaps someone wanted > to add additional properites to each item, and wished it was a list > instead? And so on... > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000001fa4b005df66bae6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 19, 2022 at 12:05 AM Mart= in Bj=C3=B6rklund <mbj+ietf@4668.s= e> wrote:
Kent Watsen <kent+ietf@watsen.net> wrote:
>
>
Hmm, I don't remember why this was changed in RFC 8525.=C2=A0 Perhaps t= his
was by accident?=C2=A0 The only text I can find is this in RFC 7950:



Not by accident.
<= div>I did not want the new list.
The main rationale was that the = 2 lists needed different keys.
The import-only-module list has [n= ame, revision] instead of just [name].

=C2=A0 5.6.5.=C2=A0 Implementing a Module

=C2=A0 =C2=A0 =C2=A0A server implements a module if it implements the modul= e's data
=C2=A0 =C2=A0 =C2=A0nodes, RPCs, actions, notifications, and deviations.
Which seems to indicate that "implementing a module" is NOT requi= red
for a feature to be supported.

Agreed.<= /div>
=C2=A0 -=C2=A0 7.20.1, para 1:=C2=A0 not specific to modules, ref= ers to the model
=C2=A0 -=C2=A0 7.20.1, para 6: "server MUST= support all dependent features".
=C2=A0 =C2=A0 =C2=A0 No me= ntion of modules, just features.



> 2) If it is the case that the module must be implemented to use its > features, then I need to update some of my modules (e.g., crypto-types=
> and friends) to explicitly disable the protocol-accessible tree when > the module is implemented *only* to use its features.

Since RFC 8525 doesn't allow a feature to be supported w/o also
implementing the module, I think this is the solution for now.=C2=A0 And it=
is not wrong even if RFC 8525 was updated to support features from
imported modules.

Deviation-stmts would= be required to "undo" the base module implementation=C2=A0
=
requirement.

Looks like RFC 7895 got this par= t right.
The 'feature' leaf-list may apply to imported mo= dules.
The same feature can only appear once, no matter how many = revisions
of a module are imported.


=

Andy



> 3) I wish more modules would following the pattern of having the
> global protocol accessible tree be defined via a "uses" of a= grouping
> defined in the module.=C2=A0 In another recent project, I had to hack = the
> topology modules defined in RFC 8345 (to convert the containers to
> groupings) to enable a multiplicity of "abstract network topologi= es"
> to be configured.=C2=A0 The assumption that only a single global insta= nce
> is ever needed is proving to be invalid in my work time and again.

This is a classic problem w/ any model... And you can extend it to
other things as well, not only top-level nodes; whenever you define a
leaf, perhaps someone could support multiple instances and wished it
was a leaf-list instead?=C2=A0 And in a leaf-list, perhaps someone wanted to add additional properites to each item, and wished it was a list
instead?=C2=A0 And so on...


/martin

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000001fa4b005df66bae6--