Re: [Softwires] draft-ietf-softwire-dslite-deployment - review

[Maoke <[e-mail]>]

dear authors and chairs,

i volunteered to be one of the reviewers of the draft on dslite deployment
(v01), and now i send my comments as follows. i also attach a diff
(generated by "diff -u") containing modifications that i suggest for the
grammatical/wording. but i am not a native speaker and please forgive if i
make anything wrong. :P

Sec 1.

some grammatical concerns only.

Sec 2.
2.1: stating the AFTR "is the function deployed ..." and soon after
mentioning dual-stack interface for "both functions" might confuse. i
suggest to remove "the function" in the first phrase.

2.2: it is unfair to say any tunneling has a risk on MTU. it is not true
that FTP or HTTP would fail once there is a tunnelrfc2473 and rfc4213,
which rfc6333 cites normatively, have discussed this issue. it is needed to
explain here why those are not enough for ds-lite. on the other hand, how
do we increase the MTU of an access network in practice? and how do we
 prevent host to generate full-MTU-sized datagrams even we have the MTU in
access network increased?

2.3: it is mentioned that both host and the remote peer "may continue to
use the MTU size for communication"... here, "the MTU" is what sort of MTU?
of link or of path? if it is path MTU, it is necessary to explain why
DS-Lite tunneling doesn't support correct path MTU discovery to work.

regarding the editor question on whether we need to drop the IPv4 DF=1
packets, if we don't what we expect the result? if the ICMP error is
bounced, the packet could and should be dropped.

here a citation to RFC792 is needed.

2.4: interception "must be performed on the AFTR" => "has to be performed
on the AFTR if it is needed"? (why it is not fine to do that on B4?)

2.5: how does the AFTR create one log per port range? if it is the
timestamped log, each log entry has a unique timestamp, right? how do we do
the aggregation for the source-specific log?

2.7: "Policies" => "Filtering Policies" or "Filters"? what does the "port
creation" mean?

2.8: where we have the "levels" of B4, BNAS, AFTR defined? i removed the
"level" for each one in the diff.

the 3rd paragraph of this subsection is hard to read. i tried to re-arrange
the text but i'm not sure if my modification is what the authors mean.

there are 10 "operator" and 9 "service provider" throughout the document, i
suggest to use "operator" uniformly and i do this with the diff.

2.9: does the last phrase of the 3rd paragraph, "since the AFTR would
support B4 elements ...", refer to Model One or Model Two? what does the
"deeper in the network" mean?

2.11: this subsection is related to geo-location issue of sharing the same
IPv4 address in a wide area. geo-location is not only used for the service
optimization but directly used for by applications. what are the "existing
assumptions of the client source address"?

the "another possibility" is not qualified. for mobile devices, typically
we use either GPS or geo-location service provided in the Internet. if the
device doesn't have GPS module, the "application could rely on GPS" might
be a myth.

somehow, this part is of an limitation of the ds-lite. no matter what we
do, it exists. my suggestion is to admit the limitation and state carefully
locating AFTRs may mitigate the inaccuracy of geo-location services.

2.13: "accepting incoming UDP or TCP traffic" is confusing. any service may
require accepting incoming traffic. i suggest to modify as "incoming UDP or
TCP requests".

Sec 5 seems to me less informational but i don't insist to suggest removing
it. :)

regards,
maoke