> On Sep 11, 2018, at 16:19 , JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> 
> wrote:
> 
> Hi Owen,
>  
> For me (and a couple of other folks that I checked around this morning), your 
> wording is more difficult to read.
> 

> This may be because we aren’t native English speakers.

Interesting… Probably be. As a native English speaker, frankly, your version 
simply doesn’t parse. The grammar doesn’t really work.

Examples:

        “Providing addressing space” is an invalid construct. You could correct 
this with “Providing address space” to fix the grammar, but it doesn’t
        really fix the remaining awkwardness of the rest of the sentence. I 
chose the words “Providing IP number resources” to match the common
        technical phrase used in a lot of RIR policy to cover IPv4, IPv6, and 
possibly ASNs.

        If you want to limit it to just IP addresses, including both v4 and v6 
(and possible future protocols), we could use “Providing IP address(es)”
        instead.

        The construct non-permanently is awkward and does not read well. 
Perhaps it works in other languages, but in English a native speaker
        would either use some conjugation of “impermanent” or more often, 
“temporary” (e.g. temporarily). Since I know you previously had some
        negative emotional reaction to the idea of replacing non-permanent with 
“temporary”, I decided to try “impermanent”

        I also removed a number of improper commas that really really made it 
hard to parse properly.
 
> Also, your wording has an “or” and I was using “and/or” to make sure to allow 
> the cases when the holder needs “both” (has an external contractor using 
> on-site devices and has employees visiting the network).
>  
> Nevertheless, I think I’m fine either way if we replace the “or” with the 
> “and/or”.

Yep… That’s an easy solution to your concern. However, FWIW, to a native 
speaker, in that context, the or is clearly intended to be inclusive rather 
than exclusive as an exclusive or would be nonsensical.

So I guess the question is do we want to write policies in english that are 
best suited for foreign readers while ill suited to parsing by native speakers, 
or, do we want
to write policies in grammatically proper english.

Don’t get me wrong, I’m the first to admit I make my share of spelling and 
grammar errors. The person I’d defer to for judgment on any such issue would be 
Lee Howard.

I’m actually OK either way, but, it seems to me that if we want the former, we 
have a slippery slope of problems, including, but not limited to:

        +       Which language(s) native speakers are we optimizing for?
        +       How do we resolve conflicts in optimizing for multiple 
different non-english languages in our english 
        +       If we have some other target language we prefer to optimize 
for, why aren’t we just using that language in the first place?

At the end of the day, my only dog in the fight is wanting to have clear policy 
that is understood by all who must live with and/or implement it.

Owen


> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De: Owen DeLong <o...@delong.com <mailto:o...@delong.com>>
> Fecha: miércoles, 12 de septiembre de 2018, 4:17
> Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es 
> <mailto:jordi.pa...@consulintel.es>>
> CC: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp 
> <mailto:satoru.tsurum...@g.softbank.co.jp>>, SIG policy <sig-pol...@apnic.net 
> <mailto:sig-pol...@apnic.net>>
> Asunto: Re: [sig-policy] Prop124 version 4
>  
> Rather than explain each part of your text, I think it would be more useful 
> if you explained where my text doesn’t convey the same intent.
>  
> Owen
>  
> 
> 
>> On Sep 10, 2018, at 22:16 , JORDI PALET MARTINEZ <jordi.pa...@consulintel.es 
>> <mailto:jordi.pa...@consulintel.es>> wrote:
>>  
>> Hi Owen, all,
>>  
>> In previous versions I tried to make a shorter text and didn’t worked.
>>  
>> Let me try to explain each part:
>>  
>> 1.       “Providing addressing space to third party devices including 
>> addresses for 
>> point-to-point links”
>>  
>> This covers the case of a subcontractor with devices siting on the holders 
>> network may be for several years, and in this case they are “permanently” 
>> connected (during the duration of the contract), explained in my problem 
>> statement as:
>>  
>> One more case is when an end-user contracts a third-party to do some 
>> services in their own network and they need to deploy their own devices, 
>> even servers, network equipment, etc. For example, security surveillance 
>> services may require that the contractor provides their own cameras, 
>> recording system, even their own firewall and/or router for a dedicated VPN, 
>> etc. Of course, in many cases, this surveillance system may need to use the 
>> addressing space of the end-user.
>>  
>> Of course, the 2nd part of the sentence is for the point-to-point links, I 
>> think that’s very obvious.
>>  
>> 2.       “and/or non-permanently providing addressing space to third Parties”
>>  
>> This covers the other cases, BYOD (employee or guest of a corporation, 
>> student of a university, visitor in a hot-spot, etc.), which are more 
>> commonly for some hours or minutes, even days.
>>  
>> 3.       “The provision of addressing space for permanent or semi-permanent 
>> connectivity, 
>> such as broadband services, is still considered a sub-assignment.”
>>  
>> We want to make sure that ISPs, typically offering broadband services, 
>> aren’t end-users, as they should be LIRs.
>> 
>> Regards,
>> Jordi
>> 
>>  
>> 
>>  
>>  
>> De: Owen DeLong <o...@delong.com <mailto:o...@delong.com>>
>> Fecha: martes, 11 de septiembre de 2018, 15:29
>> Para: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es 
>> <mailto:jordi.pa...@consulintel.es>>
>> CC: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp 
>> <mailto:satoru.tsurum...@g.softbank.co.jp>>, SIG policy 
>> <sig-pol...@apnic.net <mailto:sig-pol...@apnic.net>>
>> Asunto: Re: [sig-policy] Prop124 version 4
>>  
>> Aside from the question of examples or not examples, I offer the following 
>> suggestion… The wording is quite awkward and difficult to parse. So much so, 
>> I am not 100% certain of the intent.
>>  
>> I offer the following suggestion for a rewrite hoping that I have captured 
>> the intent accurately:
>>  
>> =======
>>  
>> Providing IP number resources to third party devices, including addresses 
>> for point-to-point links or addresses provided on an impermanent basis, for 
>> use on a network managed and operated by the assignment holder shall not be 
>> considered a sub-assignment.
>>  
>> Providing IP number resources for permanent or semi-permanent connectivity, 
>> such as broadband services is still considered a sub-assignment.
>>  
>> =======
>>  
>> Owen
>>  
>> 
>> 
>> 
>>> On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ 
>>> <jordi.pa...@consulintel.es <mailto:jordi.pa...@consulintel.es>> wrote:
>>>  
>>> Hi Satoru,
>>>  
>>> Thanks for commenting on this.
>>>  
>>> The current proposal text has not examples, I think it is quite neutral in 
>>> this aspect:
>>>  
>>> Providing addressing space to third party devices including addresses for 
>>> point-to-point links and/or non-permanently providing addressing space to 
>>> third 
>>> parties, for use on a network managed and operated by the assignment 
>>> holder, 
>>> shall not be considered a sub-assignment.
>>>  
>>> The provision of addressing space for permanent or semi-permanent 
>>> connectivity, 
>>> such as broadband services, is still considered a sub-assignment.
>>>  
>>> I think having the examples in the “objective” of the policy proposal is 
>>> needed to clarify the reason for it. You don’t think so?
>>> 
>>> Regards,
>>> Jordi
>>> 
>>>  
>>> 
>>>  
>>>  
>>> De: <sig-policy-boun...@lists.apnic.net 
>>> <mailto:sig-policy-boun...@lists.apnic.net>> en nombre de Satoru Tsurumaki 
>>> <satoru.tsurum...@g.softbank.co.jp 
>>> <mailto:satoru.tsurum...@g.softbank.co.jp>>
>>> Fecha: martes, 11 de septiembre de 2018, 14:02
>>> Para: SIG policy <sig-pol...@apnic.net <mailto:sig-pol...@apnic.net>>
>>> Asunto: Re: [sig-policy] Prop124 version 4
>>>  
>>> Dear Colleagues,
>>>  
>>> I am Satoru Tsurumaki from Japan Open Policy Forum.
>>>  
>>> I would like to share key feedback in our community for prop-124,
>>> based on a meeting we organised on 22nd Aug to discuss these proposals.
>>>  
>>> Many supporting opinions were expressed on this proposal.
>>> However, also many concerning comment was expressed to explain the specific 
>>> examples.
>>> For this matter, the same opinion was given also at JPOPM34.
>>>  
>>>   - It is better to stop specific examples because they tend to fall into 
>>> discussion of adding / not applying / not applicable.
>>>   - I think that specific examples should be stated in the guidelines 
>>> rather than policies.
>>> 
>>> Regards,
>>> Satoru Tsurumaki
>>>  
>>>  
>>> 2018-09-09 18:37 GMT+11:00 Bertrand Cherrier <b.cherr...@micrologic.nc 
>>> <mailto:b.cherr...@micrologic.nc>>:
>>>> Dear SIG members
>>>> A new version of the proposal "prop-124: Clarification on IPv6 
>>>> Sub-Assignments"
>>>> has been sent to the Policy SIG for review.
>>>> Information about earlier versions is available from:
>>>> https://www.apnic.net/community/policy/proposals/prop-124 
>>>> <https://www.apnic.net/community/policy/proposals/prop-124>
>>>> You are encouraged to express your views on the proposal:
>>>> · Do you support or oppose the proposal?
>>>> · Is there anything in the proposal that is not clear?
>>>> · What changes could be made to this proposal to make it more effective?
>>>> Please find the text of the proposal below.
>>>> Kind Regards,
>>>> Sumon, Bertrand, Ching-Heng
>>>> APNIC Policy SIG Chairs
>>>> prop-124-v004: Clarification on IPv6 Sub-Assignments
>>>> Proposer: Jordi Palet Martínez
>>>> jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>
>>>> 1. Problem Statement
>>>> 
>>>> 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.
>>>> In the case of IPv6, instead of unique addresses, the use of unique
>>>> prefixes (/64) is increasingly common.
>>>> 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.
>>>> One more case is when an end-user contracts a third-party to do some 
>>>> services
>>>> in their own network and they need to deploy their own devices, even 
>>>> servers,
>>>> network equipment, etc. For example, security surveillance services may 
>>>> require
>>>> that the contractor provides their own cameras, recording system, even 
>>>> their
>>>> own firewall and/or router for a dedicated VPN, etc. Of course, in many 
>>>> cases,
>>>> this surveillance system may need to use the addressing space of the 
>>>> end-user.
>>>> 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).
>>>> 2. Objective of policy change
>>>> 
>>>> Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits
>>>> such assignments, stating that “Assigned ... may not be sub-assigned”.
>>>> https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space
>>>>  
>>>> <https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space>
>>>> This proposal clarifies this situation in this regard and better define the
>>>> concept, particularly considering new uses of IPv6 (RFC 8273), by means of
>>>> a new paragraph.
>>>> 3. 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 APNIC. Same text has also been submitted
>>>> to AfriNIC, LACNIC and ARIN.
>>>> 4. Proposed policy solution
>>>> 
>>>> Add a new paragraph after the existing one in 2.2.3
>>>> https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space
>>>>  
>>>> <https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space>
>>>> Actual text:
>>>> 2.2.3. Assigned address space
>>>> Assigned address space is address space that is delegated to an LIR, or 
>>>> end-user,
>>>> for specific use within the Internet infrastructure they operate. 
>>>> Assignments must
>>>> only be made for specific, documented purposes and may not be sub-assigned.
>>>> New text:
>>>> 2.2.3. Assigned address space
>>>> Assigned address space is address space that is delegated to an LIR, or 
>>>> end-user,
>>>> for specific use within the Internet infrastructure they operate. 
>>>> Assignments must
>>>> only be made for specific, documented purposes and may not be sub-assigned.
>>>> Providing addressing space to third party devices including addresses for
>>>> point-to-point links and/or non-permanently providing addressing space to 
>>>> third
>>>> parties, for use on a network managed and operated by the assignment 
>>>> holder,
>>>> shall not be considered a sub-assignment.
>>>> The provision of addressing space for permanent or semi-permanent 
>>>> connectivity,
>>>> such as broadband services, is still considered a sub-assignment.
>>>> 5. Advantages / Disadvantages
>>>> 
>>>> Advantages:
>>>> Fulfilling the objective above indicated and making sure to match the real 
>>>> situation
>>>> in the market.
>>>> Disadvantages:
>>>> None foreseen.
>>>> 6. Impact on resource holders
>>>> 
>>>> None
>>>> 7. References
>>>> 
>>>> Links to RIPE policy amended and new policy proposal submitted.
>>>> Cordialement,
>>>> Bertrand Cherrier
>>>> Administration Systèmes - R&D
>>>> Micro Logic Systems
>>>> b.cherr...@micrologic.nc <mailto:b.cherr...@micrologic.nc>
>>>> https://www.mls.nc <https://www.mls.nc/>
>>>> Tél : +687 24 99 24
>>>> VoIP : 65 24 99 24
>>>> SAV : +687 36 67 76 (58F/min)
>>>> 
>>>> *              sig-policy:  APNIC SIG on resource management policy        
>>>>    *
>>>> _______________________________________________
>>>> sig-policy mailing list
>>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>>>> https://mailman.apnic.net/mailman/listinfo/sig-policy 
>>>> <https://mailman.apnic.net/mailman/listinfo/sig-policy>
>>>  
>>> * sig-policy: APNIC SIG on resource management policy * 
>>> _______________________________________________ sig-policy mailing list 
>>> sig-policy@lists.apnic.net 
>>> <mailto:sig-policy@lists.apnic.net>https://mailman.apnic.net/mailman/listinfo/sig-policy
>>>  <https://mailman.apnic.net/mailman/listinfo/sig-policy>
>>> 
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.consulintel.es <http://www.consulintel.es/>
>>> 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.
>>> 
>>> *              sig-policy:  APNIC SIG on resource management policy         
>>>   *
>>> _______________________________________________
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>>> https://mailman.apnic.net/mailman/listinfo/sig-policy 
>>> <https://mailman.apnic.net/mailman/listinfo/sig-policy>
>>  
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.consulintel.es <http://www.consulintel.es/>
>> 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.
>> 
> 
>  
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es <http://www.consulintel.es/>
> 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.
> 

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to