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
