Hi, Balazs,
Thanks for your thorough review and valuable comments!
To be brief, I will incorporate some of them to the update, but I think there
are still a couple of comments that need further discussion, like:
· Terminology to differentiate between the same(-path) data nodes in
differe
Hi Andy,
Thank you for sharing the feedback.
For the paragraph you quoted, I removed the normative language from the first
sentence.
The other parts of that paragraph are useful as they call an important aspect
that is only supported with identities + the guideline to document the
reasoning.
Hi,
I read the -02 draft.
It does not conflict with RFC 8407.
I don't think sec 3, para 3 is really needed, but the guideline to document
the
reasoning behind using enum vs. identity is more relevant for IANA modules
than other modules.
Andy
On Fri, Mar 25, 2022 at 8:05 AM wrote:
> Re-,
>
> T
Hi Tom,
This part from 8407 is worth to be considered:
If an appropriate derived type exists in any standard module, such as
[RFC6991], then it SHOULD be used instead of defining a new derived
type.
Unless I'm mistaken, the idr I-D defines a new identity afi-safi which is not
**direct
Hello,
I would like your support to clarify the usage of 'parent-reference' in the
schema-mount RFC 8528.
Let me take a simple example of a module 'profile-abc' that looks like this:
module: profile-abc
+--rw profile-abc
+--rw profile* [name]
+--rw namestrin
From: netmod on behalf of Jürgen Schönwälder
Sent: 25 March 2022 10:37
Thanks Lada,
this is useful input I think.
Another thing that we experienced in some corners of the IETF is that
IANA registries are often tied to specific protocols and it is
sometimes tempting to reuse a registry for a s
