Hi,
I had previously provided a review of this document (at revision -04),
and the authors worked to address my comments through the subsequent
revisions.
I have now re-read this document during WG last call. Most of my
comments are nits, but there are a few suggestions of substance.
On Tue, Apr 12, 2022 at 7:45 AM Kent Watsen wrote:
>
>
> For me, the only sensible option (other than accepting that types are
> named the way they are) is to introduce ip-address-with-zone and to
> deprecate ip-address and stop there. Yes, this means coexistance of
> inet:ip-address and
I am curious about the extensions introduced.
It looks like all containers and lists are tagged as 'object'.
[Qin Wu] No, the container , leaf-list, list can also be tagged as metric tag,
the most important tag value is metric tag value,
With metric tag value , we can easily capture all KPI
On Tue, Apr 12, 2022 at 03:10:12PM +, Acee Lindem (acee) wrote:
> Jürgen - I'm not sure how you could extrapolate the basic requirement for
> IPv6 link-local addresses to support for YANG configuration support of
> link-local addresses with zone indexes...
>
I would be surprised if the
Hi, Jurgen:
I understand your comment, is to investigate more use cases and see how one
mechanism can be generalized to cover more use cases.
But the idea of this draft is to capture characteristics data (e.g., KPI data )
using data node tag. Data node tag module can only convey enumerated tag
On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> Jürgen Schönwälder wrote:
>
> [...]
>
> > For me, the only sensible option (other than accepting that types are
> > named the way they are) is to introduce ip-address-with-zone and to
> > deprecate ip-address and stop there.
Jürgen - I'm not sure how you could extrapolate the basic requirement for IPv6
link-local addresses to support for YANG configuration support of link-local
addresses with zone indexes...
Acee
On 4/12/22, 11:06 AM, "Jürgen Schönwälder"
wrote:
Acee,
if you believe link local
Acee,
if you believe link local addresses do not exist or do not need to be
supported, then you may want to bring the news to other WGs.
/js
On Tue, Apr 12, 2022 at 02:54:16PM +, Acee Lindem (acee) wrote:
> That was a hypothetical example based on IPv6 Link Local addresses - not one
>
That was a hypothetical example based on IPv6 Link Local addresses - not one
anyone has implemented or deployed.
Thanks,
Acee
On 4/12/22, 10:47 AM, "Joel M. Halpern" wrote:
Juergen posted an example of where ip-address is used and zones are
expected.
Yours,
Joel
On
Hi, Balazs:
Thanks for your valuable comments, I have incorporated your comments into
https://github.com/billwuqin/draft-ietf-netmod-node-tags/blob/main/draft-ietf-netmod-node-tags-07.txt
please see reply inline below.
-邮件原件-
>发件人: Balázs Lengyel
Jürgen Schönwälder wrote:
[...]
> For me, the only sensible option (other than accepting that types are
> named the way they are) is to introduce ip-address-with-zone and to
> deprecate ip-address and stop there. Yes, this means coexistance of
> inet:ip-address and ip-address-with-zone until
Juergen posted an example of where ip-address is used and zones are
expected.
Yours,
Joel
On 4/12/2022 9:24 AM, Acee Lindem (acee) wrote:
Joel,
There are plenty of examples of where the ip-address types are used and a zone
is not accepted. Show me the examples where it is expected? I do
> For me, the only sensible option (other than accepting that types are
> named the way they are) is to introduce ip-address-with-zone and to
> deprecate ip-address and stop there. Yes, this means coexistance of
> inet:ip-address and ip-address-with-zone until YANG is getting
> replaced.
As a
Joel,
There are plenty of examples of where the ip-address types are used and a zone
is not accepted. Show me the examples where it is expected? I do have reason to
believe there aren't any significant usages of the ip-address types where zone
is accepted. Show me the models
Acee
On
From: netmod on behalf of Andy Bierman
Date: Tuesday, April 12, 2022 at 4:54 AM
To: Martin Björklund
Cc: "l...@ietf.org" , NetMod WG , Robert Wilton
Subject: Re: [netmod] [Lsr] I-D Action:
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund
On Tue, Apr 12, 2022 at 12:26 AM Martin Björklund wrote:
> Hi,
>
> Here's another suggestion. We keep the ip-address pattern as is, but
> document in the description that implementations do not have to
> support the optional zone index. This would essentially document the
> behavior of most
Hi,
Here's another suggestion. We keep the ip-address pattern as is, but
document in the description that implementations do not have to
support the optional zone index. This would essentially document the
behavior of most current implementations. (This is actually what I
suggested in the
On Mon, Apr 11, 2022 at 01:43:56PM -0400, Joel M. Halpern wrote:
> Do we have reason to believe that no one outside the IETF has used
> ip-address as we published in ways that need a zone?
>
> It seems to me that the first step in the plan below is reasonable. But
> changing ip-address itself
Nice. I think this a fine way forward with or without step 2. I say leave out
the 2 years (or any) deadline, and let people argue over how and when to do
step 2 for however long it takes.
Given the questions already raised on this thread, we should probably add
explicit guidance to
19 matches
Mail list logo
