Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Hello Greg, Thank you very much for addressing all my points were applicable. I am changing my ABSTAIN into a NO OBJECTION (even if it does not really matter) Regards -éric From: iesg on behalf of Greg Mirsky Date: Monday, 21 December 2020 at 01:56 To: Eric Vyncke Cc: Stephane Litkowski , "bess-cha...@ietf.org" , The IESG , BESS , "draft-ietf-bess-mvpn-fast-failo...@ietf.org" Subject: Re: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT) Hi Eric, apologies for the belated response. Please find my answers below in-lined tagged by GIM>>. Regards, Greg On Wed, Dec 16, 2020 at 2:05 AM Éric Vyncke via Datatracker mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-bess-mvpn-fast-failover-13: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ -- COMMENT: -- Thank you for the work put into this document. I have balloted ABSTAIN in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others." because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome. Stéphane in his doc shepherd's write up states that no implementation is known for a document born in 2008... Does the IETF really want to have this on the proposed standards track ? Please find below my ABSTAIN point, some non-blocking COMMENT points (but replies would be appreciated), and one nits. I hope that this helps to improve the document, Regards, -éric == ABSTAIN == -- Section 3.1.6.1 -- I appreciate that the BFD WG relies on ":::127.0.0.0/104<http://127.0.0.0/104>" but those IPv4-mapped IPv6 addresses are assumed to never leave a node and should never be transmitted over the Internet (see https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, why not using the a link-local address or the ff02::1 link-local multicast group ? GIM>> This text has been updated. Please let me know if the new text is acceptable: NEW TEXT: o when transmitting BFD Control packets MUST set the IP destination address of the inner IP header to the internal loopback address 127.0.0.1/32<http://127.0.0.1/32> for IPv4 [RFC1122]. For IPv6, it MUST use the loopback address ::1/128 [RFC4291]. == COMMENTS == -- Section 2.3 -- The use of "upstream" and "Upstream" could be confusing... The latter could have been "Upstream PE/ABSR" (often used later in the document) or "ingress node" GIM>> We've tried to clarify the difference in the Terminology section. As I can see from grepping the document, it consistently uses "Upstream PE" (Upstream ASBR is used once). -- Section 3.1.6 -- Could the "BFD Discreminator" attribute be used for other purpose than this document? If so, then why not specifying it in *another* document? Should this document clearly state that it does not define any TLV ? GIM>> Added a note in Section 7.3 BFD Discriminator Optional TLV Type: NEW TEXT: No optional TLV types defined at the creation of the registry. == NITS == As I am probably not the only reader have difficulties to remember RFC contents by their number, may I suggest to prefix the RFC numbers with their titles ? Esp in the introduction ;-) GIM>> I understand the challenge that manner of using references might present. In the Abstract RFC 8562 is referenced by both number and its full title. I'm concerned that doing that in the body of a document might inflate the size. I use HTMLized version that conveniently links the reference and the referenced document. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Hi Eric, apologies for the belated response. Please find my answers below in-lined tagged by GIM>>. Regards, Greg On Wed, Dec 16, 2020 at 2:05 AM Éric Vyncke via Datatracker < nore...@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-bess-mvpn-fast-failover-13: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ > > > > -- > COMMENT: > -- > > Thank you for the work put into this document. > > I have balloted ABSTAIN in the sense of "I oppose this document but > understand > that others differ and am not going to stand in the way of the others." > because > of the use outside of a node of the IPv4-mapped IPv6 addresses in section > 3.1.6.1. A reply on this topic will be welcome. > > Stéphane in his doc shepherd's write up states that no implementation is > known > for a document born in 2008... Does the IETF really want to have this on > the > proposed standards track ? > > Please find below my ABSTAIN point, some non-blocking COMMENT points (but > replies would be appreciated), and one nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == ABSTAIN == > -- Section 3.1.6.1 -- > I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those > IPv4-mapped IPv6 addresses are assumed to never leave a node and should > never > be transmitted over the Internet (see > https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my > ABSTAIN. As the inner packet is sent over a tunnel, why not using the a > link-local address or the ff02::1 link-local multicast group ? > GIM>> This text has been updated. Please let me know if the new text is acceptable: NEW TEXT: o when transmitting BFD Control packets MUST set the IP destination address of the inner IP header to the internal loopback address 127.0.0.1/32 for IPv4 [RFC1122]. For IPv6, it MUST use the loopback address ::1/128 [RFC4291]. > > == COMMENTS == > > -- Section 2.3 -- > The use of "upstream" and "Upstream" could be confusing... The latter could > have been "Upstream PE/ABSR" (often used later in the document) or "ingress > node" > GIM>> We've tried to clarify the difference in the Terminology section. As I can see from grepping the document, it consistently uses "Upstream PE" (Upstream ASBR is used once). > > -- Section 3.1.6 -- > Could the "BFD Discreminator" attribute be used for other purpose than this > document? If so, then why not specifying it in *another* document? > > Should this document clearly state that it does not define any TLV ? > GIM>> Added a note in Section 7.3 BFD Discriminator Optional TLV Type: NEW TEXT: No optional TLV types defined at the creation of the registry. > > == NITS == > > As I am probably not the only reader have difficulties to remember RFC > contents > by their number, may I suggest to prefix the RFC numbers with their titles > ? > Esp in the introduction ;-) > GIM>> I understand the challenge that manner of using references might present. In the Abstract RFC 8562 is referenced by both number and its full title. I'm concerned that doing that in the body of a document might inflate the size. I use HTMLized version that conveniently links the reference and the referenced document. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Jeffrey
This would be quite positive to post this on the BESS list like you just did ;-)
And, Stéphane, I agree that the topic of "lack of implementations for a
standards track document" is wider than this document: it was really a comment
of mine and not one asking for a reply (but yours was appreciated)
-éric
-Original Message-
From: "Jeffrey (Zhaohui) Zhang"
Date: Wednesday, 16 December 2020 at 13:50
To: "slitkows.i...@gmail.com" , Eric Vyncke
, 'The IESG' , "Rabadan, Jorge (Nokia -
US/Mountain View)"
Cc: "bess-cha...@ietf.org" ,
"draft-ietf-bess-mvpn-fast-failo...@ietf.org"
, "bess@ietf.org"
Subject: RE: [bess] Éric Vyncke's Abstain on
draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Ah. Perhaps vendors forgot/neglected to respond on the implementation
question for this particular spec, I know of two implementations.
Jeffrey
-Original Message-
From: BESS On Behalf Of slitkows.i...@gmail.com
Sent: Wednesday, December 16, 2020 5:39 AM
To: 'Éric Vyncke' ; 'The IESG'
Cc: bess-cha...@ietf.org; draft-ietf-bess-mvpn-fast-failo...@ietf.org;
bess@ietf.org
Subject: Re: [bess] Éric Vyncke's Abstain on
draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
[External Email. Be cautious of content]
Hi Eric,
Speaking as BESS WG chair, you raised a very valid point on the publication
of documents that have no implementation (or plan of implementation). This is
also a concern that I have in general, as we cannot really prove that a
technology/specification is working properly if it hasn't been implemented.
I think the discussion is a bit orthogonal to this particular document.
In the routing area, each WG is free to have its own policy regarding
implementations. In BESS, the WG decided that there will be an implementation
poll then if there is no implementation, and if WG is still fine progressing
the doc without an implementation, the document will continue until
publication. Good or bad that could be discussed but this is the WG consensus
(it was there before I took over the chair seat). This policy differs across
WGs.
I don't think that the date of the doc really matters, even if the doc was
more recent, nothing says that there will be an implementation in future, so
situation will be the same. I personally don't like having non implemented
specs but it's not just up to me and again this goes beyond just this document.
Brgds,
Stephane
-Original Message-
From: Éric Vyncke via Datatracker
Sent: mercredi 16 décembre 2020 11:06
To: The IESG
Cc: draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess-cha...@ietf.org;
bess@ietf.org; Stephane Litkowski ;
slitkows.i...@gmail.com
Subject: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13:
(with COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-mvpn-fast-failover-13: Abstain
When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this introductory
paragraph, however.)
Please refer to
https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcPs169tg$
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcD1j6hff$
--
COMMENT:
--
Thank you for the work put into this document.
I have balloted ABSTAIN in the sense of "I oppose this document but
understand that others differ and am not going to stand in the way of the
others." because of the use outside of a node of the IPv4-mapped IPv6 addresses
in section 3.1.6.1. A reply on this topic will be welcome.
Stéphane in his doc shepherd's write up states that no implementation is
known for a document born in 2008... Does the IETF really want to have this on
the proposed standards track ?
Please find below my ABSTAIN point, some non-blocking COMMENT points (but
replies would be appreciated), and one nits.
I hope that this helps to improve the document,
Regards,
-éric
== ABSTAIN ==
-- Section 3.1.6.1 --
I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those
IPv4-mapped IPv6 addresses are assumed to never leave a node and should never
be transmitted over the Internet (see
https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5156*section-2.2__;Iw!!NEt6yMaO-gk!VKB
Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Ah. Perhaps vendors forgot/neglected to respond on the implementation question for this particular spec, I know of two implementations. Jeffrey -Original Message- From: BESS On Behalf Of slitkows.i...@gmail.com Sent: Wednesday, December 16, 2020 5:39 AM To: 'Éric Vyncke' ; 'The IESG' Cc: bess-cha...@ietf.org; draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess@ietf.org Subject: Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT) [External Email. Be cautious of content] Hi Eric, Speaking as BESS WG chair, you raised a very valid point on the publication of documents that have no implementation (or plan of implementation). This is also a concern that I have in general, as we cannot really prove that a technology/specification is working properly if it hasn't been implemented. I think the discussion is a bit orthogonal to this particular document. In the routing area, each WG is free to have its own policy regarding implementations. In BESS, the WG decided that there will be an implementation poll then if there is no implementation, and if WG is still fine progressing the doc without an implementation, the document will continue until publication. Good or bad that could be discussed but this is the WG consensus (it was there before I took over the chair seat). This policy differs across WGs. I don't think that the date of the doc really matters, even if the doc was more recent, nothing says that there will be an implementation in future, so situation will be the same. I personally don't like having non implemented specs but it's not just up to me and again this goes beyond just this document. Brgds, Stephane -Original Message- From: Éric Vyncke via Datatracker Sent: mercredi 16 décembre 2020 11:06 To: The IESG Cc: draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; Stephane Litkowski ; slitkows.i...@gmail.com Subject: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-bess-mvpn-fast-failover-13: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcPs169tg$ for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/__;!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcD1j6hff$ -- COMMENT: -- Thank you for the work put into this document. I have balloted ABSTAIN in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others." because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome. Stéphane in his doc shepherd's write up states that no implementation is known for a document born in 2008... Does the IETF really want to have this on the proposed standards track ? Please find below my ABSTAIN point, some non-blocking COMMENT points (but replies would be appreciated), and one nits. I hope that this helps to improve the document, Regards, -éric == ABSTAIN == -- Section 3.1.6.1 -- I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those IPv4-mapped IPv6 addresses are assumed to never leave a node and should never be transmitted over the Internet (see https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5156*section-2.2__;Iw!!NEt6yMaO-gk!VKBlE-qjDQeeCsz4ekqM-S0M5txGOaciHBeicTqvPGGcOfOv2F_kB0LkcKQDD6CU$ ). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, why not using the a link-local address or the ff02::1 link-local multicast group ? == COMMENTS == -- Section 2.3 -- The use of "upstream" and "Upstream" could be confusing... The latter could have been "Upstream PE/ABSR" (often used later in the document) or "ingress node" -- Section 3.1.6 -- Could the "BFD Discreminator" attribute be used for other purpose than this document? If so, then why not specifying it in *another* document? Should this document clearly state that it does not define any TLV ? == NITS == As I am probably not the only reader have difficulties to remember RFC contents by their number, may I suggest to prefix the RFC numbers with their titles ? Esp in the introduction ;-) ___ BESS maili
Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Hi Eric, You say "because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome." I understand your point about using IPv4-mapped IPv6 address ":::127.0.0.0/104", as it is assumed to never leave a node and should never be transmitted over the Internet (RFC5156). This I believe is something borrowed into IETF since RFC4379, which is almost the SAME time as RFC4291, when the RFC5156 hadn't been produced. Beyond this timeline reason, the use of ":::127.0.0.0/104" still has some other reasons. One reason I can see, a SINGLE loopback IPv6 address "::1" is not enough then for RFC4379 use cases ! Because RFC4379 originally designed for MPLS, so it requires a "randomly chosen" loopback address for ECMP! See below RFC4379 section 4.3: 4.3. Sending an MPLS Echo Request An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0::127/104. Ever since SRv6/IPv6 native approach is produced as an alternative of MPLS in a limited-domain, the need of "randomly chosen" loopback address is relieved because the IPv6 Flow Label could do the ECMP thing. However, many different OAM tools like Ping/trace, Twamp/Stamp, BFD need to use mechanism like RFC4379 (now updated to RFC8029), with an IPv4/IPv6 loopback address as destination address of a tunneled packet, and with different UDP destination ports to distinguish different OAM tools. Unfortunately this will open more attack threats because of the UDP ports opened. I think there is still strong need for OAM to have IPv6 loopback address block(s) instead of a SINGLE one currently in RFC4291, thus the many UDP ports for differentiating OAM tools may be reduced by using many IPv6 loopback addresses. There is also other observations and discussions from the view of internet/app (by comparison, the OAM case is from the view of limited-domain), stating that IPv6 loopback address block(s) are needed. See . Thanks Jingrong -Original Message- From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of éric Vyncke via Datatracker Sent: Wednesday, December 16, 2020 6:06 PM To: The IESG Cc: slitkows.i...@gmail.com; bess-cha...@ietf.org; draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess@ietf.org Subject: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-bess-mvpn-fast-failover-13: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ -- COMMENT: -- Thank you for the work put into this document. I have balloted ABSTAIN in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others." because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome. Stéphane in his doc shepherd's write up states that no implementation is known for a document born in 2008... Does the IETF really want to have this on the proposed standards track ? Please find below my ABSTAIN point, some non-blocking COMMENT points (but replies would be appreciated), and one nits. I hope that this helps to improve the document, Regards, -éric == ABSTAIN == -- Section 3.1.6.1 -- I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those IPv4-mapped IPv6 addresses are assumed to never leave a node and should never be transmitted over the Internet (see https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, why not using the a link-local address or the ff02::1 link-local multicast group ? == COMMENTS == -- Section 2.3 -- The use of "upstream" and "Upstream" could be confusing... The latter could have been "Upstream PE/ABSR" (often used later in the document) or "ingress node" -- Section 3.1.6 -- Could the "BFD Discreminator" attribute be used for other purpose than this document? If so, then why not specifying it in *another* document? Should this document clearly state that it does not define any TLV ? == NITS == As I am probably not the only reader have difficulties to remember RFC contents by their number, may I suggest to
Re: [bess] Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT)
Hi Eric, Speaking as BESS WG chair, you raised a very valid point on the publication of documents that have no implementation (or plan of implementation). This is also a concern that I have in general, as we cannot really prove that a technology/specification is working properly if it hasn't been implemented. I think the discussion is a bit orthogonal to this particular document. In the routing area, each WG is free to have its own policy regarding implementations. In BESS, the WG decided that there will be an implementation poll then if there is no implementation, and if WG is still fine progressing the doc without an implementation, the document will continue until publication. Good or bad that could be discussed but this is the WG consensus (it was there before I took over the chair seat). This policy differs across WGs. I don't think that the date of the doc really matters, even if the doc was more recent, nothing says that there will be an implementation in future, so situation will be the same. I personally don't like having non implemented specs but it's not just up to me and again this goes beyond just this document. Brgds, Stephane -Original Message- From: Éric Vyncke via Datatracker Sent: mercredi 16 décembre 2020 11:06 To: The IESG Cc: draft-ietf-bess-mvpn-fast-failo...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; Stephane Litkowski ; slitkows.i...@gmail.com Subject: Éric Vyncke's Abstain on draft-ietf-bess-mvpn-fast-failover-13: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-bess-mvpn-fast-failover-13: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-fast-failover/ -- COMMENT: -- Thank you for the work put into this document. I have balloted ABSTAIN in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others." because of the use outside of a node of the IPv4-mapped IPv6 addresses in section 3.1.6.1. A reply on this topic will be welcome. Stéphane in his doc shepherd's write up states that no implementation is known for a document born in 2008... Does the IETF really want to have this on the proposed standards track ? Please find below my ABSTAIN point, some non-blocking COMMENT points (but replies would be appreciated), and one nits. I hope that this helps to improve the document, Regards, -éric == ABSTAIN == -- Section 3.1.6.1 -- I appreciate that the BFD WG relies on ":::127.0.0.0/104" but those IPv4-mapped IPv6 addresses are assumed to never leave a node and should never be transmitted over the Internet (see https://tools.ietf.org/html/rfc5156#section-2.2). This is the cause of my ABSTAIN. As the inner packet is sent over a tunnel, why not using the a link-local address or the ff02::1 link-local multicast group ? == COMMENTS == -- Section 2.3 -- The use of "upstream" and "Upstream" could be confusing... The latter could have been "Upstream PE/ABSR" (often used later in the document) or "ingress node" -- Section 3.1.6 -- Could the "BFD Discreminator" attribute be used for other purpose than this document? If so, then why not specifying it in *another* document? Should this document clearly state that it does not define any TLV ? == NITS == As I am probably not the only reader have difficulties to remember RFC contents by their number, may I suggest to prefix the RFC numbers with their titles ? Esp in the introduction ;-) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
