All,
I have completed my AD evaluation for the above draft and have
some feedback for the group. I will focus on the substantive comments
for the time being since some of them may result in re-written text in
places. I will follow up with the document authors on editorial nits
and such at a later time.
1. It is obvious from the way certain sections of text are written that
the original intent was to make a recommendation on which of the
described approaches should be used to disambiguate between multiple
hosts behind a NAT/CGN. Given that the document is now simply a
characterization of those mechanisms, I would suggest spending some time
cleaning up the Abstract, Section 1.1, and Section 2 so that they focus
on the task of describing the mechanisms, rather than mentioning
abstract requirements for those mechanisms. There are concrete
suggestions a little later in this note.
2. The mechanisms described in this draft fall into two broad
categories, deployed and proposed. Those in the former category can be
characterized based on actual usage scenarios, which would benefit the
table shown in Figure 3. The latter should be described in terms of what
they are proposed to do, but cannot be assessed against the same metrics
as the other groups.
3. The "Requirements Language" section should be removed. As an
Informational document describing mechanisms, there is no need to
leverage 2119 keywords.
4. It would be useful if the third paragraph of Section 1.1 was expanded
to discuss the risks in more detail. In fact, it may be clearer to
understand this draft if the problem statement came before the context
(Section 2).
5. Section 2
* The Observation text should provide some brief examples of how and why
special treatment is needed/provided. Is it sufficient to identify the
sending host? application? user? It should also note that there may be
issues with the fact that some IP addresses will be shared and others
may not. How does that impact the performance of these mechanisms?
* I would like some text in the Objective text to explain why such
sorting is needed. This relates back to the Context description in
Section 1.1.
* I don't think there needs to be a description of a Requirement in this
document any more, so that text can be removed.
6. Section 3.1 should be removed. This is simply an analysis of the
mechanisms, so there is no new work which needs requirements defined at
this point.
7. In Section 4.1.2, it would be good to describe any issues that the
approach has with the original use of the Identification field for
fragmentation reassembly. If a middlebox changes the ID field, weird
things can/will happen if those packets are fragmented somewhere.
8. I don't see a need for a forward reference in Section 4.2.2. I would
suggest simply stating that the IP Option approach will support any/all
transport protocols.
9. In Section 4.3.2...
* I would like to see some description of what risk(s) may arise with a
TCP option, even though they are apparently low probability.
* Additionally, the text contains "0,103%", which I assume should be
"0.103%" (i.e., 1/10th of 1%).
*The third bullet mentions that having several NATs in the path may
cause issues for a TCP option. Isn't this true for other approaches
discussed in the document? These should be identified as well.
10. In Section 4.5.1, I would suggest adding some text that describes
how to interpret Figure 2.
11. Is Section 4.6 theoretical or is there a specific reference that can
be added for this technique?
12. Section 4.7.2 should clearly state that HIP is an ideal solution for
this identification problem, even though the document states there is a
high cost for deployment. I would also like to see some description of
why HIP does not work if "the address sharing function is required to
act as a UDP/TCP-HIP relay".
13. Section 4.8.2
* The text says that the ICMP approach is viable for TCP and UDP. Any
reason why it may be an issue for other transport protocols (e.g., SCTP
or RTP)?
* I would also like to see some text describing why the approach is not
compatible with cascading NATs.
* The last bullet mentions FMC and Open WiFi with no context or
references. These should either have references or their mention should
be removed since they don't add much to the description. The same goes
for their mention in Section 4.9.2 (8th bullet).
14. In Section 4.9.2 (3rd bullet), is the solution to publish this info
in DNS or is that just an example approach? This should be clarified.
15. Section 5
* Shouldn't there be an additional metric that covers the impact/cost of
needing client or middlebox code changes?
* Where did the 100% success ratio for IP-ID come from? There have been
documented cases of OSes setting the Identification field to zero. If
that is true, the success ratio can't be 100% can it?
* Given the goal of this document to describe these identification
mechanisms, I don't see the need for the last bulleted list.
Regards,
Brian
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
