Thanks for the review, Christer, and thanks Remi for volunteering to address these.
jari On 06 Oct 2014, at 13:40, Christer Holmberg <christer.holmb...@ericsson.com> wrote: > > 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> > > Document: draft-ietf-softwire-4rd-08.txt > > Reviewer: Christer Holmberg > > Review Date: 6 October 2014 > > IETF LC End Date: 10 October 2014 > > IETF Telechat Date: 16 October 2014 > > Summary: The document is well written, and almost > ready for publication, but there are some editorial nits that I ask the > authors to address before publishing. > > Major Issues: None > > Minor Issues: None > > Editorial nits: None > > > QGEN_1: > > In a number of places in the document you talk about "mesh topology" and > "Hub&Spoke topology". Are those considered commonly known, or would it be > useful to have a reference? > > > QABS_1: > > The Abstract needs to be re-formulated. It seems to describe a problem, but > does not really say anything about the scope of the document. Normally, after > the problem statement, there would be a sentence starting with "This document > defines blah blah blah...". > > > Q_1_1: > > The first sentence says "For deployments of residual IPv4 service via IPv6 > networks,". Is there a document defining "residual IPv4 service via IPv6 > networks" which you could reference? > > Q_1_2: > > I would suggest to split the first paragraph into smaller paragraphs. > Something like (note some minor editorial changes): > > "For deployments of residual IPv4 service via IPv6 networks, the need > for a stateless solution, i.e. one where no per-customer state is > needed in IPv4-IPv6 gateway nodes of the provider, is expressed in > [I-D.ietf-softwire-stateless-4v6-motivation]. This document specifies > such a > solution, named "4rd" for IPv4 Residual Deployment. > > Using the solution, IPv4 packets are transparently tunneled across IPv6 > networks > (reverse of 6rd [RFC5969] in which IPv6 packets are statelessly > tunneled across IPv4 networks). > > While IPv6 headers are too long to be mapped into IPv4 headers (why 6rd > requires > encapsulation of full IPv6 packets in IPv4 packets), IPv4 headers can > be reversibly > translated into IPv6 headers in such a way that, during IPv6 domain > traversal, UDP packets having checksums and TCP packets are valid > IPv6 packets. IPv6-only middle boxes that perform deep-packet- > inspection can operate on them, in particular for port inspection and > web caches." > > > Q4_1: > > In section 4, the text lists a number of functions that a 4rd CE and a 4rd BR > SHOULD follow. > > However, e.g. in R-2 the text says: > > "CEs and BRs MUST be configured with the following Domain parameters:" > > So, is R-2 a "MUST", or a "SHOULD"? > > Perhaps you in section 4 should only list the functions, and for each > function you then say whether it is SHOULD, MUST, or something else. > > > Regards, > > Christer > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
