Re: [v6ops] comments on draft-xiao-v6ops-nd-deployment-guidelines

[Xipengxiao <[e-mail]>]

Hi Richard,

Thank you very much for your review and feedback.  I appreciate it.

Yes we used a Word macro to prepare the draft.  We will explore the new tool that you mentioned in the future.

Regarding your comment, please see my response in line.

> -----Original Message-----
> From: Michael Richardson [mailto:[e-mail]]
> Sent: Friday, October 22, 2021 7:08 PM
> To: Xipengxiao <[e-mail]>
> Cc: [e-mail]
> Subject: comments on draft-xiao-v6ops-nd-deployment-guidelines
> 
> 
> XiPeng, Some editorial comments/questions first.
> Are you using kramdown and/or xml format?  Or doing something with a Word
> macro?
> I strongly recommend using kramdown format,
>    https://www.ietf.org/live/previous/live104/ietf104-create-i-d-tutorial/
> because then you upload XMLv3, and you get much more beautiful and
> readable HTML.
> 
> What made me notice this is that "OPSECv27" reference is not linked, and that
> document is now RFC9099.
> 
> I don't want to go through the document word for work.
> I think that this is premature.  I think that the goals of the document are clear,
> but I think that some restructuring is in order to meet the needs of what I think
> are the intended readers.  I think that intended readers are a variety of
> different operators.
> A secondary list of readers are product managers at L2/L3 switch vendors.
 
[XX] Yes the intended readers are operators and enterprises who need to deploy ND.  Some product managers at L2/L3 switch vendors may be interested in this draft too, as we discussed the implementation for "Unique Prefix Per Host".

> The operator would say, "I'm deploying IPv6 in my XXX network using RFFyyyy,
> method 4".  The vendor would say, "oh yes. wonderful. We support that, and
> you want to read section zzz of our manual"
> 
> Section 2 has a lot of information, and is close, but not quite, a tutorial on each
> mechanism. Perhaps that belongs in a series of appendixes.

[XX] I feel that a review of known issues and solutions are needed, before we discuss how to select these solutions based on usage scenarios.

> I think that the better approach is to have a section two ask questions (i.e. a
> self-assessment) as to what kind of scenario they want to do.
> Some of the results might be aspirational vs actual.
> As in, "I really want to get to UPPH support, but not all my hosts are capable
> yet, so until then, I want MLSN"

[XX] I read your message 3 times, but I still don't fully understand the logic flow here.  The current logic of the draft is (1) review the known issues and solutions, in Section 2.1-2.4 (2) analyze the essence of each solution to see what mechanisms make it effective, to get some insight, in Section 2.5 (3) apply the insight to future deployment scenarios, and discuss the applicability, in Section 3.1 (4) summarize the whole practice into 4 guidelines for future ND deployers to consider, in Section 3.2.  Maybe this logic in my mind gets in the way of understanding your logic.  So if you can further elaborate your logic I will appreciate it.

> I suggest that section 3 then more about characteristics of each solution, and
> how each solution accomplishes the different goals.  The text there is good,
> but I think it should come in a different order.

[XX] What order would you suggest?  Again, I think I need to understand your logic first.

> The Security Considerations will need to do a lot more.

[XX] This draft only summarizes existing solutions, and provide guidelines on how to select them based on the usage scenarios. It introduces no new solution.  So I think it's fair for us to say it does not introduces new security issues.  What else do you think are needed?

Thank you again Michael!  I appreciate your time to review and feedback.  XiPeng