<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 17.01.2019 15:37, JORDI PALET
      MARTINEZ via address-policy-wg wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:A7B9FA65-0F59-4342-B53B-0DB0C077F92F@consulintel.es">
      <pre wrap="">We need to consider as well, as I depicted already before, that if you have a physical sever, you probably need also multiple addresses for that server, that's why, I think the policy should allow that (this is clearly now allowed now).</pre>
    </blockquote>
    <br>
    Let's consult ripe-707:<br>
    <br>
    <blockquote type="cite">
      <h3>2.6. Assign</h3>
      <p>To “assign” means to delegate address space to an ISP or End
        User for specific use within the Internet infrastructure they
        operate. Assignments must only be made for specific purposes
        documented by specific organisations and are not to be
        sub-assigned to other parties.</p>
      <p>Providing another entity with separate addresses (not prefixes)
        from a subnet used on a link operated by the assignment holder
        is not considered a sub-assignment. This includes for example
        letting visitors connect to the assignment holder's network,
        connecting a server or appliance to an assignment holder's
        network and setting up point-to-point links with 3rd parties.</p>
    </blockquote>
    <blockquote type="cite">
      <h3>2.9. End Site</h3>
      <p>An End Site is defined as an End User (subscriber) who has a
        business or legal relationship (same or associated entities)
        with a service provider that involves:</p>
      <ul>
        <li>that service provider assigning address space to the End
          User</li>
        <li>that service provider providing transit service for the End
          User to other sites</li>
        <li>that service provider carrying the End User's traffic</li>
        <li>that service provider advertising an aggregate prefix route
          that contains the End User's assignment<br>
        </li>
      </ul>
    </blockquote>
    <br>
    By these definitions, only an IR ("2.1. Internet Registry (IR)") 
    can "assign" allocated address space to non-IRs, i. e. ISPs or End
    Users, in the context of ripe-707.<br>
    The term "ISP" is not wll defined within ripe-707 except for "LIRs
    are generally ISPs whose customers are primarily End Users and
    possibly other ISPs" in "2.4. Local Internet Registry (LIR)". The
    graph in "2. Definitions" suggests that ISPs are the entities that
    are actually creating the Internet, whereas (L)IRs are involved in
    distributing IP space only. Since, following 2.6., only an (I)SP
    _that also is an (L)IR_ could, acting in it's (L)IR role, "assign"
    address space, 2.9. should therefore receive a friendly "s/service
    provider/ISP/g" and have the first bullet point removed.<br>
    <br>
    On the other hand, 2.6. in it's current form – except for the
    "separate addresses (not prefixes)" issue, as any singke address IS
    technically also a /128 prefix – seems rather clear to me: if it's
    for the documented "specific use within the Internet infrastructure
    they operate", it's fine. Otherwise, a separate assignment is needed
    for either a new specific use _or a different End User_, so the ISP
    or End User (or the ISP for it's End User) will have to request that
    from an (L)IR (which it may be itself, if the ISP or End User is an
    LIR as well).<br>
    <br>
    Thus, if you need "multiple addresses" for your "physical server"
    and you received an assignment for your infrastructure including
    your server(s), I cannot see a conflict with ripe-707. If you want
    to add a dedicated server for a customer of yours, I'd expect you to
    get a new (non-PI) prefix (i. e. no less than a /64 as per 5.4.1.)
    for this different End User from your LIR of choice (or have that
    End User apply for a /48 PIv6 via your cooperative LIR).<br>
    <br>
    Regards,<br>
    -kai<br>
  </body>
</html>