Subject: [Gen-art] Gen-ART review of draft-ietf-softwire-4rd-08.txt

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Oct 2014 10:40:32 +0000

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Oct 2014 15:49:52 +0200

Thanks for the review, Christer, and thanks Remi for volunteering to address these.

jari

On 06 Oct 2014, at 13:40, Christer Holmberg <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art