<div dir="ltr">"Nominative, verb indirect" isn't English ;) Clean english structure would be:<br><br>"<span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">A unique address or a unique /64 prefix that is non-permanently provided to third parties shall not be considered an assignment.<span> "</span></span><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br>Or if you really want a descriptive phrase that modifies the nominative you can get commas like so:</span></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">"A unique address or a unique /64 prefix, which is non-permanently provided to third parties, shall not be considered an assignment."<br></span><br>I would also argue that this phrase is very vague unless "permanently" is defined elsewhere in the document. Wasn't there some phrasing around short-term assignment? (sorry, too busy/too lazy to grab the entire doc right now)</span></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 4, 2018 at 6:40 PM Andrew Dul <<a href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_-5771187374056834000moz-cite-prefix">I'd like to suggest that the proposed
      policy text be shorted and clarified.  I don't believe all the
      examples are necessary in the definition section.<br>
      <br>
      Add to the end of NRPM Section 2.5 -
      <a class="m_-5771187374056834000moz-txt-link-freetext" href="https://www.arin.net/policy/nrpm.html#two5" target="_blank">https://www.arin.net/policy/nrpm.html#two5</a><br>
      <br>
      Current draft text: <br>
      <br>
      The fact that a unique address or even a unique /64 prefix is
      non-permanently provided to third parties, on a link operated by
      the original receiver of the assignment, shall not be considered a
      sub-assignment. This includes, for example, guests or employees
      (devices or servers), hotspots, and point-to-point links or VPNs.
      The provision of addressing for permanent connectivity or
      broadband services is still considered a sub-assignment. Only the
      addressing of the point-to-point link itself can be permanent and
      that addressing can't be used (neither directly or indirectly) for
      the actual communication.
      <br>
      <br>
      My suggested rewrite:<br>
      <br>
      A unique address or a unique /64 prefix that is non-permanently
      provided to third parties, shall not be considered an assignment.
      <br>
      <br>
       <br>
      <br>
      On 4/24/2018 11:57 AM, David Farmer wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>I note that the text in question is the subject of an
          editorial change that the AC has recently forwarded to Board
          for review, at a minimum the policy text need to be updated to
          account for this editorial change. Further, I do not support
          the text as written.<br>
          <br>
          I support a change to section 2 that is not quite so IPv6
          specific and focused more on the idea that providing hotspot,
          guest access, or other such temporary access does not
          necessitate the making of re-assignments from a policy
          perspective.  Furthermore, such uses are not in conflict with
          the conditions of an assignment (made by ARIN) or
          re-assignment (made by an ISP or LIR). Also, If the details of
          RFC8273 need to be mentioned at all, they should be someplace
          in section 6, not in section 2, the definitions of assign,
          allocate, re-assign and re-allocate should remain agnostic
          about IP version.<br>
          <br>
          Thanks.    
          <div>
            <div>
              <div class="gmail_extra"><br>
                <div class="gmail_quote">On Mon, Apr 23, 2018 at 2:22
                  PM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span>
                  wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
                    18 April 2018 the ARIN Advisory Council (AC)
                    accepted "ARIN-prop-254: Clarification on IPv6
                    Sub-Assignments" as a Draft Policy.<br>
                    <br>
                    Draft Policy ARIN-2018-4 is below and can be found
                    at:<br>
                    <a href="https://www.arin.net/policy/proposals/2018_4.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/proposals/2018_4.html</a><br>
                    <br>
                    You are encouraged to discuss all Draft Policies on
                    PPML. The AC will evaluate the discussion in order
                    to assess the conformance of this draft policy with
                    ARIN's Principles of Internet number resource policy
                    as stated in the Policy Development Process (PDP).
                    Specifically, these principles are:<br>
                    <br>
                     * Enabling Fair and Impartial Number Resource
                    Administration<br>
                     * Technically Sound<br>
                     * Supported by the Community<br>
                    <br>
                    The PDP can be found at:<br>
                    <a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
                    <br>
                    Draft Policies and Proposals under discussion can be
                    found at:<br>
                    <a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/proposals/index.html</a><br>
                    <br>
                    Regards,<br>
                    <br>
                    Sean Hopkins<br>
                    Policy Analyst<br>
                    American Registry for Internet Numbers (ARIN)<br>
                    <br>
                    <br>
                    <br>
                    Draft Policy ARIN-2018-4: Clarification on IPv6
                    Sub-Assignments<br>
                    <br>
                    Problem Statement:<br>
                    <br>
                    When the policy was drafted, the concept of
                    assignments/sub-assignments did not consider a
                    practice very common in IPv4 which is replicated and
                    even amplified in IPv6: the use of IP addresses for
                    point-to-point links or VPNs.<br>
                    <br>
                    In the case of IPv6, instead of unique addresses,
                    the use of unique prefixes (/64) is increasingly
                    common.<br>
                    <br>
                    Likewise, the policy failed to consider the use of
                    IP addresses in hotspots, or the use of IP addresses
                    by guests or employees in Bring Your Own Device
                    (BYOD) and many other similar cases.<br>
                    <br>
                    Finally, the IETF has recently approved the use of a
                    unique /64 prefix per interface/host (RFC8273)
                    instead of a unique address. This, for example,
                    allows users to connect to a hotspot, receive a /64
                    such that they are “isolated” from other users (for
                    reasons of security, regulatory requirements, etc.)
                    and they can also use multiple virtual machines on
                    their devices with a unique address for each one
                    (within the same /64).<br>
                    <br>
                    Section 2.5 (Definitions/Allocate and Assign),
                    explicitly prohibits such assignments, stating that
                    “Assignments... are not to be sub-assigned to other
                    parties”.<br>
                    <br>
                    This proposal clarifies this situation in this
                    regard and better define the concept, particularly
                    considering new uses of IPv6 (RFC8273), by means of
                    a new paragraph.<br>
                    <br>
                    5.    Policy Statement<br>
                    <br>
                    Actual Text<br>
                    <br>
                    •    Assign - 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 organizations and are not to
                    be sub-assigned to other parties.<br>
                    <br>
                    New Text<br>
                    <br>
                    •    Assign - 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 organizations and are not to
                    be sub-assigned to other parties.<br>
                    <br>
                    The fact that a unique address or even a unique /64
                    prefix is non-permanently provided to third parties,
                    on a link operated by the original receiver of the
                    assignment, shall not be considered a
                    sub-assignment. This includes, for example, guests
                    or employees (devices or servers), hotspots, and
                    point-to-point links or VPNs. The provision of
                    addressing for permanent connectivity or broadband
                    services is still considered a sub-assignment. Only
                    the addressing of the point-to-point link itself can
                    be permanent and that addressing can't be used
                    (neither directly or indirectly) for the actual
                    communication.<br>
                    <br>
                    <br>
                    <br>
                    6.    Comments<br>
                    <br>
                    a.    Timetable for implementation:<br>
                    <br>
                    Immediate<br>
                    <br>
                    b.    Anything else:<br>
                    <br>
                    Situation in other regions: This situation, has
                    already been corrected in RIPE, and the policy was
                    updated in a similar way, even if right now there is
                    a small discrepancy between the policy text that
                    reached consensus and the RIPE NCC Impact Analysis.
                    A new policy proposal has been submitted to amend
                    that, and the text is the same as presented by this
                    proposal at ARIN. Same text has also been submitted
                    to AfriNIC, LACNIC and APNIC.<br>
                    _______________________________________________<br>
                    PPML<br>
                    You are receiving this message because you are
                    subscribed to<br>
                    the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
                    Unsubscribe or manage your mailing list subscription
                    at:<br>
                    <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
                    Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you
                    experience any issues.<br>
                  </blockquote>
                </div>
                <br>
                <br clear="all">
                <div><br>
                </div>
                -- <br>
                <div class="m_-5771187374056834000m_-3435164732170650606m_3246561661068296257m_3699022285824535440m_-5579145693037642280gmail_signature" data-smartmail="gmail_signature">===============================================<br>
                  David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>
                  Networking & Telecommunication Services<br>
                  Office of Information Technology<br>
                  University of Minnesota   <br>
                  2218 University Ave SE        Phone: 612-626-0815<br>
                  Minneapolis, MN 55414-3029   Cell: 612-812-9952<br>
                  ===============================================</div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_-5771187374056834000mimeAttachmentHeader"></fieldset>
      <br>
      <pre>_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="m_-5771187374056834000moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="m_-5771187374056834000moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="m_-5771187374056834000moz-txt-link-abbreviated" href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
</pre>
    </blockquote>
    <p><br>
    </p>
  </div>

_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>