[rpd] PDWG discussion

Sun May 29 16:43:03 UTC 2022

Thank you Alain, you bring forward a viable process. It's the RIR community
responsibility

On Sat, May 28, 2022, 3:01 PM <rpd-request at afrinic.net> wrote:

> Send RPD mailing list submissions to
>         rpd at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.afrinic.net/mailman/listinfo/rpd
> or, via email, send a message with subject or body 'help' to
>         rpd-request at afrinic.net
>
> You can reach the person managing the list at
>         rpd-owner at afrinic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RPD digest..."
>
>
> Today's Topics:
>
>    1. Re: A question for the PDWG (ALAIN AINA)
>    2. Re: A question for the PDWG (Mike Silber)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 May 2022 13:15:19 +0000
> From: ALAIN AINA <aalain at trstech.net>
> To: rpd at afrinic.net
> Subject: Re: [rpd] A question for the PDWG
> Message-ID: <D575B648-7691-4B57-B710-C88CC504C96B at trstech.net>
> Content-Type: text/plain;       charset=utf-8
>
> Hello,
>
> Are we not mixing things now?
>
> With the development in the Internet Number registry system, RFC2050 was
> de-facto obsolete and due to move to ?historical?  as there was no need to
> keep documenting any best practices on this at IETF.
>
> The debate on how this informational document replaced a BCP did happen
> https://datatracker.ietf.org/doc/rfc7020/
>
> As for the original concern from Fernando and any other issues we may want
> to fix or improve on the RIR system, shouldn't we have discussions within
> the numbers community and use the Global policy process as  prescribed by
> the ICANN bylaws (ASO) and the ICANN/NRO MoU on the ASO function?  ICP-2
> was adopted through the global Policy approach.
>
> Willing to enforce RFC1881 [ Another informational RFC.] on revocability,
> mediation and appeals? https://www.rfc-editor.org/rfc/rfc1881.html
>
> Are we not looking for the better RIR accountability ? The latest RIR
> accountability review seems to have occurred in 2015.
> https://www.nro.net/accountability/rir-accountability/regional-internet-registry-accountability-assessment-reports/
>
> HTH
>
> ?Alain
>
>
>
>
>
> > On 26 May 2022, at 10:34, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net>
> wrote:
> >
> > I will be happy to contribute.
> >
> > RFC7020 passed "silently" in IETF, not good. Not good that a BCP is
> replaced by an informational document.
> >
> > Not good something which is not right:
> >
> >   One particular change of note is that RFC 2050 defined an appeal
> >   process and included:
> >
> >      If necessary, after exhausting all other avenues, the appeal may
> >      be forwarded to IANA for a final decision.  Each registry must, as
> >      part of their policy, document and specify how to appeal a
> >      registry assignment decision.
> >
> >   The RIRs have developed consensus-based policies for appeals, and
> >   over time, they have become accepted by the respective RIR
> >   communities.  As a result, the ability to further appeal to IANA is
> >   no longer appropriate.
> >
> > IETF is at the end the "owner" of the protocols and Internet Resources.
> IETF must have the right to oversight if something is not going right and
> be able to correct it.
> >
> > Regards,
> > Jordi
> > @jordipalet
> >
> >
> >
> > ?El 26/5/22, 11:51, "Andrew Alston via RPD" <rpd at afrinic.net> escribi?:
> >
> >    Just as a note on RFC7020 -
> >
> >    I looked at this document and noted that it is information and
> replaced a BCP - which was interesting in and of itself (that normally
> doesn't happen), but yes - it is purely an informational document.
> >
> >    The question of if a new BCP around the functioning of RIR's is
> needed - is an interesting question, and if there is sufficient interest in
> doing an updated 7020 either as a BCP or as an informational document - I'd
> be happy to work on something with those interested.  It has also been
> raised with me about writing a corporate governance for RIR's document
> under the auspices of the IETF, either as an IETF document or an ISE
> document.  On the former, I think there is merit in additional work here -
> on the latter - I am far from convinced that writing RIR governance
> documents through the IETF - either via informational track, bcp track or
> ISE track would be a good idea - in fact I can see distinct problems with
> it.
> >
> >    If there is interest in doing an updated 7020 though - I'd happily
> contribute - to the point where I'd consider AD sponsoring such if the need
> arose and the contents of the document were sane (provided I wasn't an
> author on it as that would create a distinct conflict that I could not be
> party to)
> >
> >    The question on this though is - what are the areas of 7020 that
> would need to be fixed/changed - and do we have sufficient people who are
> wiling to take the pen to do this work.  The other question of course would
> be if we wish to take this to a BCP or another informational document.
> Curious to hear thoughts.
> >
> >    Thanks
> >
> >    Andrew
> >
> >
> >    -----Original Message-----
> >    From: David Conrad <drc at virtualized.org>
> >    Sent: Wednesday, May 25, 2022 7:45 PM
> >    To: Fernando Frediani <fhfrediani at gmail.com>
> >    Cc: rpd at afrinic.net
> >    Subject: Re: [rpd] A question for the PDWG
> >
> >    Fernando,
> >
> >    On May 25, 2022, at 8:44 AM, Fernando Frediani <fhfrediani at gmail.com>
> wrote:
> >> I think you missed my main point about this topic.
> >
> >    I don?t believe so. My understanding (please correct me if I am
> mistaken) is that you would like there to be (or rather, that you believe
> it illogical for there not to exist) a governance hierarchy that sits atop
> the RIRs such that misbehavior by an RIR can be directly addressed. I am
> merely pointing out that while this may (or may not: what happens when the
> parent is captured by ?the bad guys"?) be a good idea, it does not reflect
> current reality as defined by existing arrangements between network
> operators, the RIRs, and ICANN. Despite your view about the logic, ICANN
> has no mechanism to ?de-recognize? an RIR and even if it did, it?s wildly
> unlikely the RIRs or network operators would care.
> >
> >> That must be a counter balance measures for the rest o Internet
> community to stop bad actors, including entire RIRs to do things that may
> affect the stability of the Internet.
> >
> >    There is: that power is vested in the respective RIR communities.
> >
> >> Regarding RFC 7020 I personally hope it gets fixed at some point. I
> don't think that is all bad, but it lacks a fundamental point to any system
> like this: double degree of jurisdiction which must exist in any
> administrative and legal system. It simply makes any RIR administrative
> final.
> >
> >    Again, RFC 7020 merely documented the system existing at the time of
> publication (it might have evolved since then). It is descriptive, not
> proscriptive. The Internet, including the administration of numbering
> resources, is _decentralized_. This has both positive and negative
> implications. For example, you can?t "appeal to authority" since there
> isn?t one.
> >
> >    Regards,
> >    -drc
> >
> >    _______________________________________________
> >    RPD mailing list
> >    RPD at afrinic.net
> >    https://lists.afrinic.net/mailman/listinfo/rpd
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> >
> >
> >
> > _______________________________________________
> > RPD mailing list
> > RPD at afrinic.net
> > https://lists.afrinic.net/mailman/listinfo/rpd
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 27 May 2022 15:45:57 +0200
> From: Mike Silber <silber.mike at gmail.com>
> To: ALAIN AINA <aalain at trstech.net>
> Cc: rpd at afrinic.net
> Subject: Re: [rpd] A question for the PDWG
> Message-ID: <E28A5187-D48B-4D9E-A72D-7549E2D14AD9 at gmail.com>
> Content-Type: text/plain;       charset=utf-8
>
> You make a good point Alain. One comment in-line below.
>
> Mike
>
> > On 27 May 2022, at 15:15, ALAIN AINA via RPD <rpd at afrinic.net> wrote:
> >
>
> > As for the original concern from Fernando and any other issues we may
> want to fix or improve on the RIR system, shouldn't we have discussions
> within the numbers community and use the Global policy process as
> prescribed by the ICANN bylaws (ASO) and the ICANN/NRO MoU on the ASO
> function?  ICP-2 was adopted through the global Policy approach.
> >
>
> The ICANN/NRO MoU specifically states that "global policies are defined ?
> as Internet number resource policies that have the agreement of all RIRs ?
> and ICANN, *and require specific actions or outcomes on the part of IANA or
> any other external ICANN-related body* in order to be implemented.?
>
> I don?t think governance improvements meet the criteria in the MOU and as
> such would not qualify as a possible global policy.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> ------------------------------
>
> End of RPD Digest, Vol 187, Issue 65
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20220529/e25b0cdb/attachment-0001.html>