On 04/06/2022 22:57, Kent Watsen wrote:
Hi Robert,
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
Hi Robert,
>> 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
Hello Kent,
On 18/05/2022 16:30, Kent Watsen wrote:
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
> Kent Watsen wrote:
>> YANG Doctors,
>>
>>
>> Does "foo" need to be "implemented", in order for its feature to be
>> define?
>>
>> module foo {
>>yang-version 1.1;
>>namespace "https://example.net/foo;;
>>prefix "f";
>>
>>feature foo-feature;
>>
>>
Kent Watsen writes:
> Hi Lada,
>
>> But the alternative behaviour exists as well. I don't think this can be
>> fixed by an erratum.
>
> Please say some more. Are you referring to now-obsolete RFC 7895? What does
> Yangson support?
No, I am talking about RFC 7950, which defines the concept
Hi Lada,
> But the alternative behaviour exists as well. I don't think this can be fixed
> by an erratum.
Please say some more. Are you referring to now-obsolete RFC 7895? What does
Yangson support?
K.
___
netmod mailing list
netmod@ietf.org
Kent Watsen writes:
> Hi Andy,
>
>> I feel vindicated, but also feel that Martin is right about this being the
>> solution for now. I don't even feel that it is necessarily bad. But I do
>> think we should act on this in some way. Here are some options:
>>
>> 1) put a "document only"
On Mon, May 23, 2022 at 6:57 AM Kent Watsen wrote:
> Hi Andy,
>
> I feel vindicated, but also feel that Martin is right about this being the
>> solution for now. I don't even feel that it is necessarily bad. But I do
>> think we should act on this in some way. Here are some options:
>>
>> 1)
Hi Andy,
> I feel vindicated, but also feel that Martin is right about this being the
> solution for now. I don't even feel that it is necessarily bad. But I do
> think we should act on this in some way. Here are some options:
>
> 1) put a "document only" errata on RFC 8525.
> 2) put a
On Fri, May 20, 2022 at 6:15 AM Kent Watsen wrote:
> Martin, Andy,
>
> > 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
>> >
Martin, Andy,
> > 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.
>
>
On Thu, May 19, 2022 at 12:05 AM Martin Björklund wrote:
> 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
On Thu, May 19, 2022 at 12:05 AM Martin Björklund wrote:
> Kent Watsen wrote:
> >
> >
> > > On May 18, 2022, at 2:05 AM, Martin Björklund
> > > wrote:
> > >
> > >> PS: the answer to this impacts the "crypto-types and friends" drafts
> > >> in the NETCONF WG, where it is assumed (and various
Kent Watsen wrote:
>
>
> > On May 18, 2022, at 2:05 AM, Martin Björklund
> > wrote:
> >
> >> PS: the answer to this impacts the "crypto-types and friends" drafts
> >> in the NETCONF WG, where it is assumed (and various tools agreed, sans
> >> a recent change in `yanglint`) that the
On Wed, May 18, 2022 at 10:52 PM Jan Lindblad wrote:
> Andy wrote:
>
> A server can support a module without any protocol-accessible objects in 3
> ways
>- implement the module with no features supported
>- implement the module with features supported
>- import the module without
Andy wrote:
> A server can support a module without any protocol-accessible objects in 3
> ways
>- implement the module with no features supported
>- implement the module with features supported
>- import the module without implementing it
>
> To Martin's point, it is not clear that
On Wed, May 18, 2022 at 7:30 AM Kent Watsen wrote:
>
>
> On May 18, 2022, at 2:05 AM, Martin Björklund wrote:
>
> PS: the answer to this impacts the "crypto-types and friends" drafts
> in the NETCONF WG, where it is assumed (and various tools agreed, sans
> a recent change in `yanglint`) that
> On May 18, 2022, at 2:05 AM, Martin Björklund wrote:
>
>> PS: the answer to this impacts the "crypto-types and friends" drafts
>> in the NETCONF WG, where it is assumed (and various tools agreed, sans
>> a recent change in `yanglint`) that the implementation-status of a
>> module is
Hi,
Kent Watsen wrote:
> YANG Doctors,
>
>
> Does "foo" need to be "implemented", in order for its feature to be
> define?
>
> module foo {
> yang-version 1.1;
> namespace "https://example.net/foo;;
> prefix "f";
>
> feature foo-feature;
>
>
On Tue, May 17, 2022 at 11:03 AM Kent Watsen wrote:
> Hi Andy,
>
> Thanks for your response, but I'm having trouble parsing it. At first I
> thought it was just me, but I asked someone else and they said the same.
> Can you state either:
>
> 1) a module MUST be implemented in order for its
Hi Andy,
Thanks for your response, but I'm having trouble parsing it. At first I
thought it was just me, but I asked someone else and they said the same. Can
you state either:
1) a module MUST be implemented in order for its features to be defined.
2) feature-defintion and
On Fri, May 13, 2022 at 8:49 AM Robert Varga wrote:
> On 13/05/2022 17:03, Kent Watsen wrote:
> > True, the current YANG Library structure allows features to be declared
> > only for implemented modules, but I'm unsure how intentional that was.
> >
> > We always talk about how a module needs to
On 13/05/2022 17:03, Kent Watsen wrote:
True, the current YANG Library structure allows features to be declared
only for implemented modules, but I'm unsure how intentional that was.
We always talk about how a module needs to be "implemented" in order for
its Identities to be defined, but we
True, the current YANG Library structure allows features to be declared only
for implemented modules, but I'm unsure how intentional that was.
We always talk about how a module needs to be "implemented" in order for its
Identities to be defined, but we don't ever talk about the same being true
Hi,
I would just like to explicitly mention that the current YANG library
does not allow to report features for non-implemented modules and the
feature list is in a grouping called
`module-implementation-parameters`[1] so it would seem the authors of
that RFC thought one must implement a
YANG Doctors,
Does "foo" need to be "implemented", in order for its feature to be define?
module foo {
yang-version 1.1;
namespace "https://example.net/foo;;
prefix "f";
feature foo-feature;
...
}
Specifically, using the
26 matches
Mail list logo
