Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear SIG members,
The proposal "prop-151: Restricting non hierarchical as-set" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on Wednesday, 1 March 2023.
https://conference.apnic.net/55/program/schedule/#/day/10
We invite you to review and comment on the proposal on the mailing list before the OPM.
The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal:
- Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective?
Information about this proposal is appended below as well as available at:
http://www.apnic.net/policy/proposals/prop-151
Regards, Bertrand, Shaila, and Anupam APNIC Policy SIG Chairs
----------------------------------------------------
prop-151-v001: Restricting non hierarchical as-set
----------------------------------------------------
Proposer: Aftab Siddiqui (aftab.siddiqui@gmail.com)
1. Problem statement -------------------- An as-set (RFC 2622 Section 5.1) provides a way to document the relationship between ASes which can then be publicly verified. RFC2622 further defines 2 categories for as-set which can be Hierarchical or Non Hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
Non hierarchical as-set pose a security issue where any one can create an as-set without any authentication or authorisation e.g. any member can create AS-FACEBOOK (if available) without authorisation from Facebook. Since many peering filters are based on as-set, creating a blank as-set or as-set with wrong members can cause automated filters to apply empty prefix-filters to BGP session.
2. Objective of policy change ----------------------------- Restrict APNIC members to create non hierarchical as-set and notify all members who already have non hierarchical as-set that it is recommended to move them to hierarchical as-set.
3. Situation in other regions ----------------------------- - RIPE NCC has recently implemented restriction of non hierarchical as-set - LACNIC IRR supports only hierarchical as-set
4. Proposed policy solution --------------------------- APNIC members are only allowed to create hierarchical as-set. As defined in the RFC2622 Section 5 "A hierarchical set name is a sequence of set names and AS numbers separated by colons ":". At least one component of such a name must be an actual set name (i.e. start with one of the prefixes above). All the set name components of an hierarchical name has to be of the same type."
An as-set object with name AS65536:...... can only be created by the maintainer of the AS65536. Therefore, this must be the only allowed structure for hierarchical as-set.
Any non hierarchical as-set can not be used as a parent to create a hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not be allowed to create AS-AFTAB:AS141384 (hierarchical as-set).
5. Advantages / Disadvantages ----------------------------- Advantages: This will protect members from intentional or unintentional creation of as-set which already exist in other IRR databases creating name collision.
Disadvantages: Overhead for APNIC to notify existing non hierarchical as-set maintainers about the policy update.
6. Impact on resource holders ----------------------------- APNIC has to request members to update their non hierarchical as-set as a new recommended policy. No changes will be enforced to existing non hierarchical as-set.
7. References ------------- - Thanks to Job Snijders, Nick Hilliard and other community members on for providing in depth details on various platforms. - RIPE db-wg proposal: https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html - IRRd 4 update: https://github.com/irrdnet/irrd/issues/408 - https://www.manrs.org/2022/12/why-network-operators-should-use-hierarchical-...
Dear SIG members,
The proposal "prop-151: Restricting non hierarchical as-set" has been
sent to
the Policy SIG for review.
It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
Wednesday, 1 March 2023.
https://conference.apnic.net/55/program/schedule/#/day/10
We invite you to review and comment on the proposal on the mailing list
before the OPM.
The comment period on the mailing list before the OPM is an important
part of the Policy Development Process (PDP). We encourage you to
express your views on the proposal:
- Do you support or oppose this proposal?
- Does this proposal solve a problem you are experiencing? If so,
tell the community about your situation.
- Do you see any disadvantages in this proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more effective?
Information about this proposal is appended below as well as available at:
http://www.apnic.net/policy/proposals/prop-151
Regards,
Bertrand, Shaila, and Anupam
APNIC Policy SIG Chairs
----------------------------------------------------
prop-151-v001: Restricting non hierarchical as-set
----------------------------------------------------
Proposer: Aftab Siddiqui (aftab.siddiqui@gmail.com)
1. Problem statement
--------------------
An as-set (RFC 2622 Section 5.1) provides a way to document the
relationship between ASes which can then be publicly verified. RFC2622
further defines 2 categories for as-set which can be Hierarchical or Non
Hierarchical. A hierarchical set name is a sequence of set names and AS
numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
Non hierarchical as-set pose a security issue where any one can create
an as-set without any authentication or authorisation e.g. any member
can create AS-FACEBOOK (if available) without authorisation from
Facebook. Since many peering filters are based on as-set, creating a
blank as-set or as-set with wrong members can cause automated filters to
apply empty prefix-filters to BGP session.
2. Objective of policy change
-----------------------------
Restrict APNIC members to create non hierarchical as-set and notify all
members who already have non hierarchical as-set that it is recommended
to move them to hierarchical as-set.
3. Situation in other regions
-----------------------------
- RIPE NCC has recently implemented restriction of non hierarchical as-set
- LACNIC IRR supports only hierarchical as-set
4. Proposed policy solution
---------------------------
APNIC members are only allowed to create hierarchical as-set. As defined
in the RFC2622 Section 5 "A hierarchical set name is a sequence of set
names and AS numbers separated by colons ":". At least one component of
such a name must be an actual set name (i.e. start with one of the
prefixes above). All the set name components of an hierarchical name
has to be of the same type."
An as-set object with name AS65536:...... can only be created by the
maintainer of the AS65536. Therefore, this must be the only allowed
structure for hierarchical as-set.
Any non hierarchical as-set can not be used as a parent to create a
hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not
be allowed to create AS-AFTAB:AS141384 (hierarchical as-set).
5. Advantages / Disadvantages
-----------------------------
Advantages:
This will protect members from intentional or unintentional creation of
as-set which already exist in other IRR databases creating name collision.
Disadvantages:
Overhead for APNIC to notify existing non hierarchical as-set
maintainers about the policy update.
6. Impact on resource holders
-----------------------------
APNIC has to request members to update their non hierarchical as-set as
a new recommended policy. No changes will be enforced to existing non
hierarchical as-set.
7. References
-------------
- Thanks to Job Snijders, Nick Hilliard and other community members on
for providing in depth details on various platforms.
- RIPE db-wg proposal:
https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html
- IRRd 4 update: https://github.com/irrdnet/irrd/issues/408
-
https://www.manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/
_______________________________________________
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
--------------------------------------------------------------------
Secretariat Impact Assessment
--------------------------------------------------------------------
APNIC notes this proposal would restrict APNIC account holders from creating a non-hierarchical as-set in the APNIC Whois Database. APNIC would be required to notify all Members who already have a non-hierarchical as-set to recommend they move to a hierarchical as-set as defined in Section 5 of RFC2622.
APNIC also notes that an as-set object can only be created by the maintainer of the ASN that is used in the as-set object, and this must be the only allowed method for creating a hierarchical as-set in the APNIC Whois Database.
This proposal may require changes to APNIC systems. If this proposal reaches consensus and endorsed by the EC, implementation may be completed within three months.
Regards, Sunny
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
I would like to share key feedback in our community for prop-151, based on a meeting we organised on 15th Feb to discuss these proposals.
Many participants support the intent of this proposal, but do not believe it should be discussed in Policy SIG.
(comment details) - I agree with the purpose of the proposal, but I wonder if it is not something that should be discussed in the sig policy.
- I think the problem is how to determine which AS number to permit.
- I do not oppose this proposal, but I do not think we should have excessive expectations of IRR.
- This proposal should be discussed globally by MANRS or others, not by APNIC Policy SIG.
Regards,
Satoru Tsurumaki / JPOPF Steering Team
2023年1月20日(金) 9:25 Bertrand Cherrier b.cherrier@mynet.nc:
Dear SIG members,
The proposal "prop-151: Restricting non hierarchical as-set" has been sent to the Policy SIG for review.
It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on Wednesday, 1 March 2023.
https://conference.apnic.net/55/program/schedule/#/day/10
We invite you to review and comment on the proposal on the mailing list before the OPM.
The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal:
- Do you support or oppose this proposal?
- Does this proposal solve a problem you are experiencing? If so, tell the community about your situation.
- Do you see any disadvantages in this proposal?
- Is there anything in the proposal that is not clear?
- What changes could be made to this proposal to make it more effective?
Information about this proposal is appended below as well as available at:
http://www.apnic.net/policy/proposals/prop-151
Regards, Bertrand, Shaila, and Anupam APNIC Policy SIG Chairs
prop-151-v001: Restricting non hierarchical as-set
Proposer: Aftab Siddiqui (aftab.siddiqui@gmail.com)
- Problem statement
An as-set (RFC 2622 Section 5.1) provides a way to document the relationship between ASes which can then be publicly verified. RFC2622 further defines 2 categories for as-set which can be Hierarchical or Non Hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
Non hierarchical as-set pose a security issue where any one can create an as-set without any authentication or authorisation e.g. any member can create AS-FACEBOOK (if available) without authorisation from Facebook. Since many peering filters are based on as-set, creating a blank as-set or as-set with wrong members can cause automated filters to apply empty prefix-filters to BGP session.
- Objective of policy change
Restrict APNIC members to create non hierarchical as-set and notify all members who already have non hierarchical as-set that it is recommended to move them to hierarchical as-set.
- Situation in other regions
- RIPE NCC has recently implemented restriction of non hierarchical as-set
- LACNIC IRR supports only hierarchical as-set
- Proposed policy solution
APNIC members are only allowed to create hierarchical as-set. As defined in the RFC2622 Section 5 "A hierarchical set name is a sequence of set names and AS numbers separated by colons ":". At least one component of such a name must be an actual set name (i.e. start with one of the prefixes above). All the set name components of an hierarchical name has to be of the same type."
An as-set object with name AS65536:...... can only be created by the maintainer of the AS65536. Therefore, this must be the only allowed structure for hierarchical as-set.
Any non hierarchical as-set can not be used as a parent to create a hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not be allowed to create AS-AFTAB:AS141384 (hierarchical as-set).
- Advantages / Disadvantages
Advantages: This will protect members from intentional or unintentional creation of as-set which already exist in other IRR databases creating name collision.
Disadvantages: Overhead for APNIC to notify existing non hierarchical as-set maintainers about the policy update.
- Impact on resource holders
APNIC has to request members to update their non hierarchical as-set as a new recommended policy. No changes will be enforced to existing non hierarchical as-set.
- References
- Thanks to Job Snijders, Nick Hilliard and other community members on
for providing in depth details on various platforms.
- RIPE db-wg proposal:
https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html
- IRRd 4 update: https://github.com/irrdnet/irrd/issues/408
https://www.manrs.org/2022/12/why-network-operators-should-use-hierarchical-...
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-leave@lists.apnic.net
Satoru-san,
Thank you for your reports from JPOPF Steering Team, as always, your feedback is greatly appreciated.
Best Regards,
Bertrand, Shaila and Anupam
Policy SIG Chairs
Le 21/02/2023 à 21:00, Satoru Tsurumaki a écrit :
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
I would like to share key feedback in our community for prop-151, based on a meeting we organised on 15th Feb to discuss these proposals.
Many participants support the intent of this proposal, but do not believe it should be discussed in Policy SIG.
(comment details)
I agree with the purpose of the proposal, but I wonder if it is not something that should be discussed in the sig policy.
I think the problem is how to determine which AS number to permit.
I do not oppose this proposal, but I do not think we should have excessive expectations of IRR.
- This proposal should be discussed globally by MANRS or others, not by APNIC Policy SIG.
Regards,
Satoru Tsurumaki / JPOPF Steering Team
2023年1月20日(金) 9:25 Bertrand Cherrier b.cherrier@mynet.nc:
Aftab A. Siddiqui
Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
I would like to share key feedback in our community for prop-151,
based on a meeting we organised on 15th Feb to discuss these proposals.
Many participants support the intent of this proposal, but do not believe
it should be discussed in Policy SIG.
(comment details)
- I agree with the purpose of the proposal, but I wonder if it is not
something that should be discussed in the sig policy.
- I think the problem is how to determine which AS number to permit.
- I do not oppose this proposal, but I do not think we should have
excessive expectations of IRR.
- This proposal should be discussed globally by MANRS or others,
not by APNIC Policy SIG.
Regards,
Satoru Tsurumaki / JPOPF Steering Team
2023年1月20日(金) 9:25 Bertrand Cherrier <b.cherrier@mynet.nc>:
>
> Dear SIG members,
>
> The proposal "prop-151: Restricting non hierarchical as-set" has been
> sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> Wednesday, 1 March 2023.
>
> https://conference.apnic.net/55/program/schedule/#/day/10
>
> We invite you to review and comment on the proposal on the mailing list
> before the OPM.
>
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
>
> - Do you support or oppose this proposal?
> - Does this proposal solve a problem you are experiencing? If so,
> tell the community about your situation.
> - Do you see any disadvantages in this proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more effective?
>
> Information about this proposal is appended below as well as available at:
>
> http://www.apnic.net/policy/proposals/prop-151
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
> ----------------------------------------------------
>
> prop-151-v001: Restricting non hierarchical as-set
>
> ----------------------------------------------------
>
> Proposer: Aftab Siddiqui (aftab.siddiqui@gmail.com)
>
>
> 1. Problem statement
> --------------------
> An as-set (RFC 2622 Section 5.1) provides a way to document the
> relationship between ASes which can then be publicly verified. RFC2622
> further defines 2 categories for as-set which can be Hierarchical or Non
> Hierarchical. A hierarchical set name is a sequence of set names and AS
> numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
>
> Non hierarchical as-set pose a security issue where any one can create
> an as-set without any authentication or authorisation e.g. any member
> can create AS-FACEBOOK (if available) without authorisation from
> Facebook. Since many peering filters are based on as-set, creating a
> blank as-set or as-set with wrong members can cause automated filters to
> apply empty prefix-filters to BGP session.
>
>
> 2. Objective of policy change
> -----------------------------
> Restrict APNIC members to create non hierarchical as-set and notify all
> members who already have non hierarchical as-set that it is recommended
> to move them to hierarchical as-set.
>
>
> 3. Situation in other regions
> -----------------------------
> - RIPE NCC has recently implemented restriction of non hierarchical as-set
> - LACNIC IRR supports only hierarchical as-set
>
>
> 4. Proposed policy solution
> ---------------------------
> APNIC members are only allowed to create hierarchical as-set. As defined
> in the RFC2622 Section 5 "A hierarchical set name is a sequence of set
> names and AS numbers separated by colons ":". At least one component of
> such a name must be an actual set name (i.e. start with one of the
> prefixes above). All the set name components of an hierarchical name
> has to be of the same type."
>
> An as-set object with name AS65536:...... can only be created by the
> maintainer of the AS65536. Therefore, this must be the only allowed
> structure for hierarchical as-set.
>
> Any non hierarchical as-set can not be used as a parent to create a
> hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not
> be allowed to create AS-AFTAB:AS141384 (hierarchical as-set).
>
>
> 5. Advantages / Disadvantages
> -----------------------------
> Advantages:
> This will protect members from intentional or unintentional creation of
> as-set which already exist in other IRR databases creating name collision.
>
> Disadvantages:
> Overhead for APNIC to notify existing non hierarchical as-set
> maintainers about the policy update.
>
>
> 6. Impact on resource holders
> -----------------------------
> APNIC has to request members to update their non hierarchical as-set as
> a new recommended policy. No changes will be enforced to existing non
> hierarchical as-set.
>
>
> 7. References
> -------------
> - Thanks to Job Snijders, Nick Hilliard and other community members on
> for providing in depth details on various platforms.
> - RIPE db-wg proposal:
> https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html
> - IRRd 4 update: https://github.com/irrdnet/irrd/issues/408
> -
> https://www.manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/
>
>
>
> _______________________________________________
> sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-leave@lists.apnic.net
_______________________________________________
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
6. Impact on resource holders ----------------------------- APNIC has to request members to update their non hierarchical as-set as a new recommended policy. No changes will be enforced to existing non hierarchical as-set.The purpose of this policy is to make sure that no APNIC member intentionally or unintentionally create an unauthenticated AS-SET, while the existing non-hierarchical AS-SET pose security issue for AS-SET holder but it doesn't create any problem for any other resource holders. Thats why it should be informed to all resource holders that their AS-SETs are vulnerable to name collision attacks from other non-authenticated IRR databases but APNIC shouldn't delete them.
Aftab A. Siddiqui
Hi Satoru san,I appreciate the feedback from the JP community. I do understand some of the points you have raised, I will be doing a detailed technical presentation during the Routing Security SIG to discuss most of the issues you have raised here. I would request you and other friends from the community to attend the routing security SIG.Regards,
Aftab A. SiddiquiOn Tue, 21 Feb 2023 at 22:43, Satoru Tsurumaki <stsuruma@gmail.com> wrote:Dear Colleagues,
I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
I would like to share key feedback in our community for prop-151,
based on a meeting we organised on 15th Feb to discuss these proposals.
Many participants support the intent of this proposal, but do not believe
it should be discussed in Policy SIG.
(comment details)
- I agree with the purpose of the proposal, but I wonder if it is not
something that should be discussed in the sig policy.
- I think the problem is how to determine which AS number to permit.
- I do not oppose this proposal, but I do not think we should have
excessive expectations of IRR.
- This proposal should be discussed globally by MANRS or others,
not by APNIC Policy SIG.
Regards,
Satoru Tsurumaki / JPOPF Steering Team
2023年1月20日(金) 9:25 Bertrand Cherrier <b.cherrier@mynet.nc>:
>
> Dear SIG members,
>
> The proposal "prop-151: Restricting non hierarchical as-set" has been
> sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> Wednesday, 1 March 2023.
>
> https://conference.apnic.net/55/program/schedule/#/day/10
>
> We invite you to review and comment on the proposal on the mailing list
> before the OPM.
>
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
>
> - Do you support or oppose this proposal?
> - Does this proposal solve a problem you are experiencing? If so,
> tell the community about your situation.
> - Do you see any disadvantages in this proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more effective?
>
> Information about this proposal is appended below as well as available at:
>
> http://www.apnic.net/policy/proposals/prop-151
>
> Regards,
> Bertrand, Shaila, and Anupam
> APNIC Policy SIG Chairs
>
>
> ----------------------------------------------------
>
> prop-151-v001: Restricting non hierarchical as-set
>
> ----------------------------------------------------
>
> Proposer: Aftab Siddiqui (aftab.siddiqui@gmail.com)
>
>
> 1. Problem statement
> --------------------
> An as-set (RFC 2622 Section 5.1) provides a way to document the
> relationship between ASes which can then be publicly verified. RFC2622
> further defines 2 categories for as-set which can be Hierarchical or Non
> Hierarchical. A hierarchical set name is a sequence of set names and AS
> numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS
>
> Non hierarchical as-set pose a security issue where any one can create
> an as-set without any authentication or authorisation e.g. any member
> can create AS-FACEBOOK (if available) without authorisation from
> Facebook. Since many peering filters are based on as-set, creating a
> blank as-set or as-set with wrong members can cause automated filters to
> apply empty prefix-filters to BGP session.
>
>
> 2. Objective of policy change
> -----------------------------
> Restrict APNIC members to create non hierarchical as-set and notify all
> members who already have non hierarchical as-set that it is recommended
> to move them to hierarchical as-set.
>
>
> 3. Situation in other regions
> -----------------------------
> - RIPE NCC has recently implemented restriction of non hierarchical as-set
> - LACNIC IRR supports only hierarchical as-set
>
>
> 4. Proposed policy solution
> ---------------------------
> APNIC members are only allowed to create hierarchical as-set. As defined
> in the RFC2622 Section 5 "A hierarchical set name is a sequence of set
> names and AS numbers separated by colons ":". At least one component of
> such a name must be an actual set name (i.e. start with one of the
> prefixes above). All the set name components of an hierarchical name
> has to be of the same type."
>
> An as-set object with name AS65536:...... can only be created by the
> maintainer of the AS65536. Therefore, this must be the only allowed
> structure for hierarchical as-set.
>
> Any non hierarchical as-set can not be used as a parent to create a
> hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not
> be allowed to create AS-AFTAB:AS141384 (hierarchical as-set).
>
>
> 5. Advantages / Disadvantages
> -----------------------------
> Advantages:
> This will protect members from intentional or unintentional creation of
> as-set which already exist in other IRR databases creating name collision.
>
> Disadvantages:
> Overhead for APNIC to notify existing non hierarchical as-set
> maintainers about the policy update.
>
>
> 6. Impact on resource holders
> -----------------------------
> APNIC has to request members to update their non hierarchical as-set as
> a new recommended policy. No changes will be enforced to existing non
> hierarchical as-set.
>
>
> 7. References
> -------------
> - Thanks to Job Snijders, Nick Hilliard and other community members on
> for providing in depth details on various platforms.
> - RIPE db-wg proposal:
> https://www.ripe.net/ripe/mail/archives/db-wg/2022-November/007646.html
> - IRRd 4 update: https://github.com/irrdnet/irrd/issues/408
> -
> https://www.manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/
>
>
>
> _______________________________________________
> sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-leave@lists.apnic.net
_______________________________________________
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
Activity Summary
- 279 days inactive
- 279 days old
- sig-policy@lists.apnic.net
- 5 participants
- 6 comments