Subject: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Aug 2017 14:48:24 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have no technical comments, but a number of editorial comments:

- General: I think this could use another proofreading and/or editing pass for
the following issues: -- Inconsistent tense--especially use of future or
present continuous. -- Wordy and convoluted sentences -- Use of "/" as a
conjunction.

- Abstract:
The abstract is longer and more detailed than is useful. The last paragraph
could have stood alone as the abstract. It's not clear to me if "hosts
(subscribers)" means something different than "hosts" in context.

-1:
Please expand "IA_NA" on first use.
s/"This document will focus..."/"This document focuses..."

"As such the use
   of IPv6 SLAAC based subscriber and address management for provider
   managed shared network services is the recommended technology of
   choice, as it does not exclude any known IPv6 implementation."
Does this document make that recommendation, or is that some pre-existing
recommendation?

-3: "The Best Current Practice documented in this note is to provide a
   unique IPv6 prefix to hosts/subscribers devices connected to the
   provider managed shared network."

The sentence hard to follow. Consider "This document recommends...".  I'm not
sure how to interpret "hosts/subscribers devices"

"Each unique IPv6 prefix can
   function as control-plane anchor point to make sure that each
   subscriber is receiving"
s/"... subscriber is receiving ..."/"... subscriber receives..."

-4: Is "First Hop Provider Router" different than "First Hop Router"?

In the last bullet (L-flag=0), are NEVER and ALWAYS in all-caps expected to
have different meaning than if they had normal capitalization?

The sentence starting with "The architected result of designing the RA as
documented above..." is convoluted and hard to follow.

"... however it SHOULD NOT use stateful DHCPv6 to receive
   a service provider managed IPv6 address": Is that really a normative
   requirement, or is it a statement of fact about existing requirements?

"it SHOULD send this traffic
   to the First Hop Provider Router." : statement of fact?

- 5: "To reduce
   undesired resource consumption on the First Hop Router the desire is
   to remove UE/subscriber context in the case of non-permanent UE, such
   as in the case of WiFi hotspots as quickly as possible. "
Convoluted sentence.

"A possible solution is to use a subscriber inactivity timer which, after
   tracking a pre-defined (currently unspecified) number of minutes,
   deletes the subscriber context on the First Hop Router."

s/which/that   (Consider " ... timer that deletes...after a predetermined
number of minutes"

-7: "The
   combination of both IPv6 privacy extensions and operator based
   assignment of a Unique IPv6 Prefix per Host provides each
   implementing operator a tool to manage and provide subscriber
   services and hence reduces the experienced privacy within each
   operator controlled domain."

I have trouble following that sentence. Is the point to say that providing
tools to manage and provide services reduces privacy in general? As worded, it
almost sounds like this is meant as a feature, which I assume is not the case.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 21 Aug 2017 14:28:49 +0000

Hi Ben,

Thanks for the review. Look for GV>

On 16/08/2017, 23:48, "Ben Campbell" <[email-masked]> wrote:

    

GV> I decided to swap ”UE/subscriber” with ”subscriber” through the document
    
    - Abstract:
    
GV> ack. I removed first two paragraphs. The abstract now simply reads:

This document outlines an approach utilising existing IPv6 protocols
to allow hosts to be assigned a unique IPv6 prefix (instead of a unique
IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix 
over a unique IPv6 address from the service provider include improved 
host isolation and enhanced subscriber management.</t>

    -1:
    Please expand "IA_NA" on first use.
GV> DHCP IA_NA (Identity Association - Non-temporary Address)

GV. Ack
    
    "As such the use
    
GV> rephrased:
To not exclude any known IPv6 implementations, IPv6 SLAAC based subscriber and address 
management is the recommended technology to reach highest percentage 
of connected IPv6 devices on a provider managed shared network service.

    
GV> rephrased to:
“This document recommends providing a unique IPv6 prefix to devices connected to the managed shared
      network.”

GV> ack, modified

    -4: Is "First Hop Provider Router" different than "First Hop Router"?
GV> Indeed. I modified the text accordingly.

GV> I modified accordingly to lower caps

GV> re-edited to be more readable:
      The architected result of designing the RA as documented above is
      that each subscriber gets its own unique IPv6 prefix. Each host can consequently 
      use SLAAC or any other method of choice to select its /128 unique address

GV> This text has been modified based upon another comment

    "it SHOULD send this traffic
       to the First Hop Provider Router." : statement of fact?
GV> it Is what should happen if IPv6 stack behave as pre-scribed

    - 5: "To reduce

    
GV> Text re-edited:
      The stateless nature of the subscriber IPv6 SLAAC connectivity
      model introduces non-optimal resource consumption (i.e. memory, 
      neighbor state) on the First Hop Router. To reduce undesired resource 
      consumption, such as in the case of WiFi hotspots, is to remove subscriber 
      context as quickly as possible when a device or subscriber becomes non-active. 
      A possible solution is to use a subscriber or device inactivity timer,
      that after tracking a pre-defined (currently unspecified) number of minutes,
      deletes the subscriber context on the First Hop Router.

    -7: "The

GV> re-edited the text:
	  The mechanics of IPv6 privacy extensions <xref target="RFC4941">RFC4941</xref> 
	  is compatible with assignment of a unique IPv6 Prefix per Host.
	  However, when combining both IPv6 privacy extensions and a unique IPv6 Prefix per Host 
	  a reduced privacy experience for the subscriber is introduced, because a 
	  prefix may be associated with a subscriber, even when the subscriber 
	  implemented IPv6 privacy extensions <xref target="RFC4941">RFC4941</xref>.