[bcop] IPv6 prefix delegation BCOP document available for comments and suggestions

Hi Jordi,


> 
>    Hi Jan,
> 
>    Great doc, and very readable. Thanks to all the authors for their input. 
>    I went over the doc with the eyes of a newbie to this stuff and found some areas for clarification.
> 
>    In section 3, we mention "end-user" for the first time, without explaining what an end-user is in this context.. In our courses we have to make that explanation sooner than later, because different audiences read different things in the word “end-user”.
> 
> ⇒ Can’t find “end-user” in the current version. I think we used end-customer and the goal was always “residential/household end-users”
> 
>    The abbreviation of CPE is nowhere explained or fully written.
> 
> ⇒ Right, some other documents use CE. Is the same (Customer Edge or Customer Premises Equipment). We can point here to the definition at RFC7084, because this document is being updated, so if we need to clarify that (don't think so is the case, right now, but just in case), we could take the opportunity to do so …

I talked to Jan, don’t think this is needed, if we explain the intended audience better. “operators” was a bit too vague. By explaining that this document is for an entity/organisation that provides internet connectivity to residential and business customers, the problem is solved. 

> 
>    Can we provide a link to an explanation of the Neighbor Discovery exhaustion attack?
> 
> ⇒ RFC6583 maybe
> 
>    3.1.3
>    where we mention “This method may be seen as easier to implement, but it also brings some drawbacks such as difficulties with troubleshooting”, can we make it a bit more explicit by stating that link-local addresses don’t appear in a trace route, for example?
> 
> ⇒ Can write some text, of course …    

Yes, Jan took care of that, I believe.

> 
>    3.2.1
>    “It should be remembered that some mechanisms use a default /48 prefix size “ 
>    Do we have examples?
> ⇒ Yeah, users of tunnel brokers (some delegate /48), 6to4, ULA, all them use by default /48.    

ULA is not recommended you wrote, 6to4 is on the way to be deprecated and tunnel brokers are not the intended audience of the doc, right? I would just leave this out….

> 
>    3.2.3.
>    I would make 
> 
> 
>    “There is a clear exception to this rule when assigning addresses in a cellular network. I n this case a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers it will still be necessary to choose a /48 or /56, in accordance with the aforementioned considerations.“
>    the paragraph after “assigning a /64 or smaller prefix is highly discouraged”
> 
> ⇒ Ok.    
> 
>    4.
>    “Static assignment means that a prefix is assigned to a customer (typically an AAA) “
>    What is an AAA? Try to explain abbreviations.
> ⇒ I’m starting to think that the target of the document is not clear. AAA is something obvious for any network operator. The document doesn’t target end-users … or I got something wrong? AAA -> Authentication, Authorization and Accounting    

The target audience was indeed not explained well at the beginning ;)


> 
>    4.1
>    “The easiest way method” remove way or method.
> ⇒ Ok.   
> 
>    4.2 
>    “If the CPE knows that the delegated prefix has changed it should send out RA packets”
>    Write Router Advertisements. 
> ⇒ Same as above, but we can write the complete text each time we use each abbreviation.

That is good practice in writing documentation, the first time write the word out full, later use the abbreviation. 

> 
>    Did the authors consider images to explain certain concepts? For example bit boundary? RIPE NCC can help with that, if you wish.
> 
> ⇒ I’m fine and happy with that support, but again, who is the target for the document? Need that target all this?

Like I said, don’t know. Wonder how the rest feels…

Cheers,
Nathalie