Alvaro
Minor correction, there is also
https://datatracker.ietf.org/doc/draft-wkumari-intarea-safe-limited-domains/
for a more generic approach on limited domains
-éric
From: spring on behalf of Alvaro Retana
Date: Thursday, 28 March 2024 at 13:03
To: SPRING WG List
Cc:
Thank you, Cheng, for your reply and the amended draft.
Regards
-éric
From: Cheng Li
Date: Monday, 27 November 2023 at 17:20
To: Eric Vyncke (evyncke) , The IESG
Cc: draft-ietf-spring-mpls-path-segm...@ietf.org
, spring-cha...@ietf.org
, spring@ietf.org ,
james.n.guich...@futurewei.com
As said this morning during the SPRING WG meeting, the authors may consider
taking input from RFC 6169 (Security Concerns with IP Tunneling) and RFC 9099
(Operational Security Considerations for IPv6 Networks).
Hope this helps
-éric (obviously no hat)
Thank you, Rishabh, for your quick reply. I had a look at the revised -16.
As you know, all my points were and are just non-blocking comments, see below
for EV>
Regards
-éric
From: Rishabh Parekh
Date: Monday, 31 July 2023 at 22:05
To: Eric Vyncke
Cc: The IESG ,
why the IETF has put in the requirement which he
wants to violate.
Yours,
Joel
On 10/10/2022 5:57 AM, Eric Vyncke (evyncke) wrote:
Hmmm I really wonder why a transit network should look into my packets (to
check for SRH) and decide to drop my packets; assuming of course that my
packets are not damaging
Hmmm I really wonder why a transit network should look into my packets (to
check for SRH) and decide to drop my packets; assuming of course that my
packets are not damaging the transit network (like some hop-by-hop years ago)
or attempting to trick my network (anti-spoofing or using transit
Bruno, Jim, Joel,
Without any hat, or only with the experience of reviewing so many I-Ds from
different areas and having implemented a couple of proof-of-concept
implementations of various IETF drafts.
The following are just comments for discussion, not criticisms because indeed
running code
[Wearing no hat, except my Cisco affiliation]
Tony,
Your email prompted me to check in the data tracker DB and with Cisco legal
dept about the timeline for this IPR disclosure about RFC 8402.
I am afraid that the chronology leaves out two previous clusters of disclosures
by Cisco, in 2013 and
Hello Carlos,
Thank you again for your INT directorate review, it is always important to have
multiple pairs of eyes when reviewing a document.
As you may have seen in the spring mailing list, I have relied heavily on your
review.
¡Muchos gracias !
-éric
On 13/02/2022, 22:24, "Int-dir on
Thanks,
Pablo.
-Original Message-
From: Eric Vyncke (evyncke)
Sent: jueves, 24 de septiembre de 2020 12:16
To: Pablo Camarillo (pcamaril) ; The IESG
Cc: draft-ietf-spring-srv6-network-programm...@ietf.org;
spring-cha...@ietf.org; spring@ietf.org; Bruno De
Pablo,
Thank you for your reply. See inline for EV>
-éric
-Original Message-
From: "Pablo Camarillo (pcamaril)"
Date: Wednesday, 23 September 2020 at 18:20
To: Eric Vyncke , The IESG
Cc: "draft-ietf-spring-srv6-network-programm...@ietf.org"
, "spring-cha...@ietf.org"
,
Brian,
Thank you for your detailed reviewed of this document in the framework on
INT-DIR.
I will refer to your review for my ballot next week.
Regards
-éric
-Original Message-
From: Int-dir on behalf of Brian Haberman via
Datatracker
Reply-To: Brian Haberman
Date: Monday, 14
Dear authors,
Nothing dramatic but the three YANG modules included in this I-D start with an
invalid syntax (the trailing '-->' is wrong):
file "ietf-srv6-ty...@2020-07-13.yang" -->
This means that:
1) the included YANG modules are extracted neither in YangCatalog.Org nor by
the YANG
[not related to this specific Working Group Last Call (WGLC): Martin, the
responsible AD, has explained the specifics again in another email]
But, for information, let me share my experience as an Area Director (AD) as I
had similar situations in my first year as AD:
1. Document is proposed
Writing this without any hat,
Please note that on the logical side, it still have to be "proven" that this
idea is strictly forbidden by RFC 8200. Moreover, this 'proof' can technically
wait until the IETF last call or even until the IESG ballot. I see little point
in postponing the closing of
15 matches
Mail list logo
