I support adoption.
As Aijun and Christian discussed in this thread, I agree this could be
directly adopted as is clarifications to ASLA and does not really need to
go through the WG adoption process.
Kind Regards
Gyan
On Mon, Aug 8, 2022 at 6:21 AM Christian Hopps wrote:
>
> Hi Folks,
>
>
Christian Hopps writes:
[[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps
(trust ultimate) created at 2022-08-09T20:50:17-0400 using
RSA]]
Aijun Wang writes:
Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
This is a valid
Aijun Wang writes:
Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
This is a valid point. I will consult with Acee and John, perhaps doing an
adoption call was unneeded, and they should be considered adopted already as
they are only clarification
On 8/9/22, 7:34 PM, "Aijun Wang" wrote:
Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
I would like to illustrate my opinions again:
Application specific attributes just one small part of the application
based solution, there are other
Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
I would like to illustrate my opinions again:
Application specific attributes just one small part of the application based
solution, there are other issues needed to be considered and solved. And I
think the
The Link State Routing (lsr) WG will hold
a virtual interim meeting on 2022-09-07 from 10:00 to 12:00 America/New_York
(14:00 to 16:00 UTC).
Agenda:
IGP Flexible Algorithms Reverse Affinity Constraint
Peter Psenak (5 mins)
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : YANG Data Model for IS-IS Segment Routing
Authors : Stephane Litkowski
Yingzhen
We were asked by the AD to process these clarifications using bis drafts,
rather than errata. That is what this is. There should be no controversy here.
Let's not create any, please.
Thanks,
Chris.
Aijun Wang writes:
Hi, Acee, Peter:
If there is no significant updates for these two RFCs,
Aijun,
RFC8919 and RFC8920 are both existing RFCs, we are just adding some
clarification text to them.
If you want to come up with some new architecture, feel free, but don't
try to neglect the existing ones.
thanks,
Peter
On 09/08/2022 08:26, Aijun Wang wrote:
Hi, Acee, Peter:
If
Hi, Acee, Peter:
If there is no significant updates for these two RFCs, I recommend we delay the
obsolete of them, also the adoption call for these two bis drafts.
What we should do is to find other more scalable, extensible and systematic
approaches for the application specified
Hi Aijun,
And the BIS changes are more clarifications than changes to the existing RFC
8919 and RFC 8920 RFCs.
Thanks,
Acee
On 8/9/22, 5:57 AM, "Peter Psenak" wrote:
Aijun,
On 09/08/2022 05:35, Aijun Wang wrote:
> Hi,
>
> I am wondering why we are so hurry to
Aijun,
On 09/08/2022 05:35, Aijun Wang wrote:
Hi,
I am wondering why we are so hurry to obsolete RFC8919, given that only the
minor parts are updated (mainly the zero length SABM/UABM, and other
interoperability issues).
There may be other methods to advertise the application specific
Hi,
I am wondering why we are so hurry to obsolete RFC8919, given that only the
minor parts are updated (mainly the zero length SABM/UABM, and other
interoperability issues).
There may be other methods to advertise the application specific attributes.
>From my POV, the rules, implementation of
I support progressing this draft as a co-author. This draft is a basic protocol
extension of OSPFv3 for SRv6, which is useful and necessary.
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr
Cc:
14 matches
Mail list logo
