[Apwg-ipv6-papi] [pdo] last changes?

[Daniel Stolpe]

On Mon, 9 Sep 2013, Elvis Velea wrote:

> Hi,
>
> On 9/9/13 6:29 PM, Daniel Stolpe wrote:
>>
>>  Hi,
>>
>>  I see we will have enless layers of IR:s now. :-)
>>
>>  But yes. All the layers will in some sense be IR:s themseleves.
>> 
>
> because we have removed the assignment (which was the last layer) now anyone 
> can be an IR if they receive a sub-allocation.
>
> so, yes.. there's an infinite number of IRs within an allocation made by the 
> RIPE NCC :)
>
> Do you agree with the last comments/edits?

Yes, I think it's a nice way to show exactly that.

Cheers,

Daniel

>>  On Mon, 9 Sep 2013, Elvis Velea wrote:
>> 
>> >  Hi everyone,
>> > 
>> >  Taking into account Olaf's comments, and after a few minutes and an
>> >  other coffee I decided to implement a new change.
>> > 
>> >  Introducing the PIR - Portable Internet Registry \o/
>> > 
>> >  (@Olaf and Daniel - please respond asap and let me know if you agree,
>> >  only then Marco can request Comms and the webmaster to implement the
>> >  change)
>> > 
>> >  please see below:
>> > 
>> >  On 9/9/13 3:24 PM, Marco Schmidt wrote:
>> > >  Hello Olaf,
>> > > 
>> > >  the final decision is of course with the proposers but please allow me
>> > >  mention the following:
>> > > 
>> > >  With the proposed changes we the publishing will get delayed by at 
>> > >  least
>> > >  a week as the complete text must be reviewed for references and
>> > >  cross-references as often the terms are related.
>> > > 
>> > >  Please see below:
>> > > 
>> > >  On 9/9/13 2:01 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote:
>> > > >  Dear Elvis
>> > > > 
>> > > >  It took time, but I got it. From my point of view, WG, especially
>> > > >  Elvis, and Comms did a great job.
>> > > > 
>> > > > 
>> > > >  If it is still possible (I think not based on our timeline), I have
>> > > >  following suggestions for a better understanding of the policy:
>> > > > 
>> > > >  1: "End User" vs. "End Site":
>> > > >  In the beginning, policy defines "End Site" is the same as "End 
>> > > >  User".
>> > > >  But, "end site" hasn't really been used within policy (once within
>> > > >  chapter 2.9, twice within chapter 5.4). So, we could directly define
>> > > >  term "End User" instead "End Site". In this case, acronym "EU" has
>> > > >  been defined, which has been used inside illustration under chapter
>> > > >  2.0.
>> > >  Even if end site is described as an end user there is a different to 
>> > >  the
>> > >  term end user used in the policy. An End User/LIR's customer can have
>> > >  serveral end sites (e.g. company with several branches) - like shown 
>> > >  in
>> > >  the graph in 2.0.
>> > >  If this would be unified then as per 5.4.4. then every assignment 
>> > >  bigger
>> > >  than a /48 per end user must be evaluated by the RIPE NCC.
>> > >  (Imagine McDonalds is an LIR customer and want to connect 1000
>> > >  restaurants)
>> > 
>> >  Actually, according to the current proposal, End User will become an IR.
>> >  It will be an organisation or private person that will receive a
>> >  sub-allocation and will be able to make further sub-allocations if
>> >  allowed by the holder of the larger (sub-)allocation.
>> > 
>> >  I would not unify the End User and End-Site terms, as these are
>> >  completely different in most cases.
>> >  The End-Site is the last level of sub-allocation, the actual site (be it
>> >  a computer, a mobile device or a small network).
>> >  The End User is an organisation that may have one or more End-Sites.
>> > 
>> > > > 
>> > > >  2. "End user(s)" instead "LIR's customer" / "customer of (the) LIR" 
>> > > >  /
>> > > >  "End Site" / "customer" in conjunction with "LIR":
>> > > >  Based on first suggestion, policy could only use term "end user"
>> > > >  instead "LIR's customer", "customer of (the) LIR" and so on. A 
>> > > >  service
>> > > >  provider, who has a business with another service provider (LIR), is
>> > > >  also an "end user" at this particular time. A end user, who has a
>> > > >  business with another end user (service provider), is also an "end
>> > > >  user" at this particular time. From my point of view, term "end 
>> > > >  user"
>> > > >  describes a role.
>> > > > 
>> > > >  Changes could be done at following chapters: 2.7, 2.9, 5.1.1, 5.1.2,
>> > > >  5.1.4, 5.2.3, 5.3, 5.4.1, 5.4.2, 5.4.3, 5.4.4, 5.6
>> > >  As above.
>> > 
>> >  I initially agreed with your suggestion, however, we could only change
>> >  the references to 'LIR's Customer' or 'Customer of (the) LIR', see
>> >  below, most have been changed to PIR.
>> > 
>> >  But we can not change the End-Site to End User, that would cause a whole
>> >  other problem.
>> > 
>> > > 
>> > > > 
>> > > >  3. "LIR" instead "IR":
>> > > >  Sometimes policy is talking about "IR" for rules, which apply only 
>> > > >  to
>> > > >  "LIR". Policy defines, that two types of "IR" are available inside 
>> > > >  our
>> > > >  service region: RIR and LIR. "Sponsoring LIR" is a kind of type 
>> > > >  "LIR".
>> > > >  - Example 1: Chapter 5.1.1 refer to "IR", following chapter 5.1.2
>> > > >  refer firstly to "LIR" and one paragraph later to "IR". But, any
>> > > >  definition within 5.1 is only valid for "LIR", because IANA policies
>> > > >  are valid for RIR.
>> > > >  - Example 2: Chapter 5.5 refer firstly to "IR", and it refer one
>> > > >  paragraph later to "LIR".
>> > > > 
>> > > >  Changes could be done at following chapters: 5.1.1, 5.1.2, 5.2.1,
>> > > >  5.4.3, 5.4.5, 5.5, 5.6
>> > >  IR is the general term and later in the policy rules are described 
>> > >  that
>> > >  sometimes apply only for RIRs, sometimes only for LIRs and sometimes 
>> > >  for
>> > >  both.
>> > >  And for these general rules it is probably good to keep IR (instead of
>> > >  writing "RIRs and LIRs") - for example in 4.2 RIR and LIRs must apply
>> > >  procedures that reduce the possibility of fragmented address space...
>> > > 
>> > >  Related to this I noticed that in 5.1.1 probably it really should be 
>> > >  LIR
>> > >  instead of IR - I adjusted this already - let me know if I'm wrong.
>> > > 
>> > 
>> >  Indeed, IR is a general term and I actually thought that I made mistakes
>> >  in editing the proposed text. However, some of the definitions apply to
>> >  all IRs while some others apply only to the RIR, others only to the LIR.
>> > 
>> >  5.1.1 does mention IRs because initial allocations can be made either to
>> >  the LIR or to the EU (via Sponsoring LIR). In this case the EU is also
>> >  an IR, as they will be making sub-allocations to their own
>> >  infrastructure or to their customers. Please see the changes below.
>> > 
>> > 
>> > 
>> >  @Marco, please ask Comms to update the following:
>> > 
>> >  - add
>> > 
>> >  2.5 Portable Internet Registry (PIR)
>> > 
>> >  A Portable Internet Registry is an IR which can request (via a
>> >  Sponsoring LIR) a portable allocation from the RIR. The PIR
>> >  sub-allocates address space to the users of the network services that it
>> >  provides.
>> > 
>> >  - change
>> > 
>> >  from
>> >  2.4 Sponsoring LIR
>> > 
>> >  Members of the RIPE NCC (LIRs) can request portable allocations on
>> >  behalf of a third party, and the RIPE NCC will allocate resources
>> >  directly to this third party. In these cases, the role of the LIR is to
>> >  facilitate the administrative processes and to maintain a link between
>> >  the RIPE NCC and the third party that holds the resources. An LIR
>> >  fulfilling this role is called the Sponsoring LIR for the third party.
>> >  Third parties can choose another LIR to be their Sponsoring LIR at any
>> >  time.
>> > 
>> >  to
>> >  2.5 Sponsoring LIR
>> > 
>> >  Members of the RIPE NCC (LIRs) can request portable allocations on
>> >  behalf of PIRs, and the RIPE NCC will allocate resources directly to the
>> >  PIR. In these cases, the role of the LIR is to facilitate the
>> >  administrative processes and to maintain a link between the RIPE NCC and
>> >  the PIR that holds the resources. An LIR fulfilling this role is called
>> >  the Sponsoring LIR for the PIR. PIRs can choose another LIR to be their
>> >  Sponsoring LIR at any time.
>> > 
>> >  -change current 2.5 to 2.6, etc..
>> > 
>> >  -change
>> >  5.1.1
>> > 
>> >  from
>> >  To qualify for an initial allocation of IPv6 address space, an IR must
>> >  have a plan for making sub-allocations to other customers and/or End
>> >  Sites within two years.
>> > 
>> >  to
>> >  To qualify for an initial allocation of IPv6 address space, an LIR or an
>> >  PIR must have a plan for making sub-allocations to other customers
>> >  and/or End Sites within two years.
>> > 
>> >  -change
>> >  5.1.2
>> > 
>> >  from
>> >  IRs may qualify for a larger initial allocation by submitting
>> >  documentation that reasonably justifies the request.
>> > 
>> >  to
>> >  LIRs or PIRs may qualify for a larger initial allocation by submitting
>> >  documentation that reasonably justifies the request.
>> > 
>> >  -change
>> >  (also in 5.1.2)
>> > 
>> >  from
>> >  /48 allocations can be made by the RIPE NCC to customers of the LIR that
>> >  do not expect to ever need more or for special purposes.
>> > 
>> >  to
>> >  /48 allocations can be made by the RIPE NCC to PIRs that do not expect
>> >  to ever need more or for special purposes.
>> > 
>> >  -change
>> >  5.1.4
>> > 
>> >  from
>> >  To qualify for portable address space, an LIR?s customer must meet the
>> >  requirements of the policies described in the RIPE Document ripe-452 or
>> >  it?s updates.
>> >  The RIPE NCC will allocate the prefix directly to the customer of the
>> >  Sponsoring LIR upon a request properly submitted to the RIPE NCC by the
>> >  Sponsoring LIR.
>> > 
>> >  to
>> >  To qualify for portable address space, an PIR must meet the requirements
>> >  of the policies described in the RIPE Document ripe-452 or it?s updates.
>> >  The RIPE NCC will allocate the prefix directly to the PIR upon a request
>> >  properly submitted to the RIPE NCC by the Sponsoring LIR.
>> > 
>> > 
>> >  -change
>> >  5.2.1
>> > 
>> >  from
>> >  An additional allocation will also be provided when an IR satisfies the
>> >  evaluation threshold of past address utilisation in terms of the number
>> >  of sites in units of /56s.
>> > 
>> >  to
>> >  An additional allocation will also be provided when an LIR or PIR
>> >  satisfies the evaluation threshold of past address utilisation in terms
>> >  of the number of sites in units of /56s.
>> > 
>> >  -change
>> >  5.2.3
>> > 
>> >  from
>> >  When an LIR or its customer has achieved an acceptable utilisation level
>> >  for its allocated address space, it is immediately eligible to receive
>> >  an additional allocation that results in a doubling of the address space
>> >  allocated to it.
>> > 
>> >  to
>> >  When an LIR or PIR has achieved an acceptable utilisation level for its
>> >  allocated address space, it is immediately eligible to receive an
>> >  additional allocation that results in a doubling of the address space
>> >  allocated to it.
>> > 
>> >  -change
>> >  5.3
>> > 
>> >  from
>> >  The RIPE NCC will make allocations to LIRs or their customers according
>> >  to the points 5.1 and 5.2 of this policy. These allocations can be made
>> >  to the LIR (not portable) or (via a Sponsoring LIR) to a customer of the
>> >  LIR (portable).
>> > 
>> >  to
>> >  The RIPE NCC will make allocations to LIRs or PIRs according to the
>> >  points 5.1 and 5.2 of this policy. These allocations can be made to the
>> >  LIR or to a PIR.
>> > 
>> > 
>> >  -change
>> > 
>> >  from
>> >  5.4.2 Sub-allocations Made by the Customer of the (Sponsoring) LIR
>> > 
>> >  A customer of an LIR which has received an allocation (portable or not)
>> >  can further sub-allocate parts of this allocation to a downstream
>> >  customer.
>> > 
>> >  to
>> >  5.4.2 Sub-allocations Made by the PIR
>> > 
>> >  An PIR which has received an allocation can further sub-allocate parts
>> >  of this allocation to a downstream customer.
>> > 
>> >  -add
>> > 
>> >  5.4.3 Sub-allocations Made by the Customers
>> > 
>> >  A customer which has received a sub-allocation can further sub-allocate
>> >  parts of it to a downstream customer. These sub-allocations must be
>> >  registered in the RIPE Database.
>> > 
>> >  -change current 5.4.3 to 5.4.4, etc...
>> > 
>> >  -change
>> >  current 5.4.3
>> > 
>> >  from:
>> >  End Sites or customers are sub-allocated an IPv6 block. The size of the
>> >  sub-allocation is a local decision for the IR to make, using the minimum
>> >  value of a /64 (if only one subnet is anticipated for the End Site).
>> > 
>> >  to:
>> >  End Sites or customers are sub-allocated an IPv6 block. The size of the
>> >  sub-allocation is a local decision for the LIR or the PIR to make, using
>> >  the minimum value of a /64 (if only one subnet is anticipated for the
>> >  End Site).
>> > 
>> >  -change
>> >  current 5.4.5
>> > 
>> >  from
>> >  An IR may sub-allocate a network prefix per point of presence (PoP) as
>> >  the service infrastructure of an IPv6 service operator. Each
>> >  sub-allocation to a PoP is regarded as one regardless of the number of
>> >  users using the PoP. A separate sub-allocation can be obtained for the
>> >  operator?s in-house operations.
>> > 
>> >  to
>> >  An LIR or PIR may sub-allocate a network prefix per point of presence
>> >  (PoP) as the service infrastructure of an IPv6 service operator. Each
>> >  sub-allocation to a PoP is regarded as one regardless of the number of
>> >  users using the PoP. A separate sub-allocation can be obtained for the
>> >  operator?s in-house operations.
>> > 
>> >  -change
>> >  5.5
>> > 
>> >  from
>> >  When an IR holding an IPv6 address allocation makes allocations,
>> >  sub-allocations or aggregations, these must be registered in the RIPE
>> >  Database.
>> > 
>> >  to
>> >  When an organisation holding an IPv6 address allocation makes
>> >  allocations, sub-allocations or aggregations, these must be registered
>> >  in the RIPE Database.
>> > 
>> >  -change
>> >  5.6
>> > 
>> >  from
>> >  When an RIR allocates IPv6 address space to an IR, it also delegates the
>> >  responsibility to manage the reverse lookup zone that corresponds to the
>> >  allocated IPv6 address space. Each LIR or customer should properly
>> >  manage its reverse lookup zone. When making sub-allocations, the IR can
>> >  delegate to its customer, upon request, the responsibility to manage the
>> >  reverse lookup zone that corresponds to the sub-allocated block.
>> > 
>> >  to
>> >  When an RIR allocates IPv6 address space to an LIR or PIR, it also
>> >  delegates the responsibility to manage the reverse lookup zone that
>> >  corresponds to the allocated IPv6 address space. Each LIR or PIR should
>> >  properly manage its reverse lookup zone. When making sub-allocations,
>> >  the LIR or PIR can delegate to its customer, upon request, the
>> >  responsibility to manage the reverse lookup zone that corresponds to the
>> >  sub-allocated block.
>> > 
>> >  -change
>> >  5.7.2
>> > 
>> >  from
>> >  Organisations holding an allocation lower than a /32 (except those made
>> >  for special purposes) can request an extension of this allocation to a
>> >  /32. Where this extension is not possible, the organisation has the
>> >  option to return the allocation and automatically receive a /32 (or
>> >  larger if justified).
>> > 
>> >  to
>> >  LIRs or PIRs holding an allocation lower than a /32 (except those made
>> >  for special purposes) can request an extension of this allocation to a
>> >  /32. Where this extension is not possible, the LIR or PIR has the option
>> >  to return the allocation and automatically receive a /32 (or larger if
>> >  justified).
>> > 
>> >  -end of changes
>> > 
>> > 
>> >  And with this changes, I hope we get to publish the proposal as soon as
>> >  possible :)
>> > 
>> >  We will all still get a chance to have a look at the proposal before it
>> >  is announced to the mailing list. Hope there won't be anything else to
>> >  change.
>> > 
>> >  --
>> >  Kind regards,
>> >  Elvis Velea
>> > 
>> >  _______________________________________________
>> >  Apwg-ipv6-papi mailing list
>> >  Apwg-ipv6-papi at ripe.net
>> >  https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>> > 
>> > 
>>
>>  mvh
>>
>>  Daniel Stolpe
>>
>>  _________________________________________________________________________________
>>
>>  Daniel Stolpe           Tel:  08 - 688 11 81
>>  stolpe at resilans.se
>>  Resilans AB             Fax:  08 - 55 00 21 63
>>  http://www.resilans.se/
>>  Box 13 054                                  556741-1193
>>  103 02 Stockholm
>> 
>
>
>

mvh

Daniel Stolpe

_________________________________________________________________________________
Daniel Stolpe           Tel:  08 - 688 11 81                   stolpe at resilans.se
Resilans AB             Fax:  08 - 55 00 21 63            http://www.resilans.se/
Box 13 054							      556741-1193
103 02 Stockholm