Benoit/Martin, I apologize. I seem to have missed reading that email. I review and replay.
regards, Victor K On Tue, Jan 14, 2014 at 12:10 PM, Benoit Claise <[email protected]> wrote: > Dear authors, doc. shepherd, > > Can you please answer Martin. > > Regards, Benoit > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-opsawg-lsn-deployment-04 >> Reviewer: Martin Thomson >> Review Date: 2014-01-06 >> IETF LC End Date: 2014-01-06 >> IESG Telechat date: (if known) >> >> Summary: This document describes a generic way that MPLS LSPs can be >> deployed to support the deployment of CGNs in a way that addresses a >> range of common requirements. As a draft, it's still a little rough, >> but it is mostly ready for publication as an Informational RFC. >> >> Major issues: none >> >> Minor issues: >> >> The abstract says this: >> >> This document does not intend to defend the >> merits of CGN. >> >> Which seems wise given their somewhat contentious nature. But then >> the entirely of Section 2 does exactly the opposite. I don't know >> what the right answer is here, but maybe the right thing to do is >> delete Section 2. >> >> Figures 1 and 2 should probably use different labels for the two CPE >> boxes. The top one is being translated, the bottom one isn't. >> >> Section 6 is a little too speculative to be valuable. How about using >> the boilerplate: >> >> This document has no IANA actions. >> >> I'm not sure what "security measures" might be employed here: >> >> If a provider plans to operate the pre-translation realm (CPE towards >> translator IPv4 zone) as a non-public like network, then additional >> security measures may be needed to secure this environment. >> >> What might be secured in these scenarios? Confidentiality? Access to >> network resources? Perhaps this should talk about what a network >> operator wants to secure: access to the network. Then maybe talk >> about access control and isolation. >> >> In Section 4, this seems a little vague: >> >> Various redundancy models >> can be used within this architecture to support failover from one >> physical CGN hardware instance to another. >> >> I don't expect an enumeration of the options, but this seems important >> enough to at least point to where the redundancy options might exist? >> Redundant "VPNs"/LSPs? Redundant paths from the VRF termination? >> >> Nits: >> >> Missing period in Section 9 >> >> I found the structure of the first part of Section 3.1 difficult: >> >> Centralized deployments of CGN (longer proximity to end user and/or >> higher densities of subscribers/connections to CGN instances) differ >> from distributed deployments of CGN (closer proximity to end user and >> /or lower densities of subscribers/connections to CGN instances). >> >> Maybe this could be expanded a little to improve comprehension. >> >> This statement seems redundant: >> >> Other requirements may be assessed on a operator-by-operator basis, >> but those listed above may be considered for any given deployment >> architecture. >> >> As far as it goes, some of the requirements listed might not apply to >> a particular deployment, or part thereof. >> . >> >> >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
