Last Call Review of draft-ietf-v6ops-transition-ipv4aas-11
review-ietf-v6ops-transition-ipv4aas-11-tsvart-lc-stiemerling-2018-12-18-00

Request Review of draft-ietf-v6ops-transition-ipv4aas
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-12-14
Requested 2018-11-30
Draft last updated 2018-12-18
Completed reviews Tsvart Last Call review of -11 by Martin Stiemerling (diff)
Opsdir Last Call review of -11 by Dan Romascanu (diff)
Rtgdir Last Call review of -11 by Daniele Ceccarelli (diff)
Genart Last Call review of -12 by Matthew Miller (diff)
Secdir Last Call review of -11 by Christian Huitema (diff)
Secdir Telechat review of -12 by Christian Huitema (diff)
Assignment Reviewer Martin Stiemerling
State Completed
Review review-ietf-v6ops-transition-ipv4aas-11-tsvart-lc-stiemerling-2018-12-18
Reviewed rev. 11 (document currently at 15)
Review result Ready with Issues
Review completed: 2018-12-18

Review
review-ietf-v6ops-transition-ipv4aas-11-tsvart-lc-stiemerling-2018-12-18

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

General issues:
- I have an issue with using RFC 2119 language in informative RFCs, as it is unclear
what normative language means in informative documents. However, I understand
that there is legacy from older documents in particular, but not limited to, RFC 7084.

- The document is in parts hard to read, even for someone who has a background in
IPv4/IPv6 transition. E.g. Section 1, 2nd paragraph, about what IP version is used
where. A figure could help here. 

Issues: 
- Remove the DEFAULT word and replace it with default. It is very confusing to add
capital letters normative language here. 

- Section 5: UPnP

This section is posing requirements in an IETF document that incorporates non-IETF
standards for a matter that is solely a recommendation. Can this be MUST at all? 

- Section 6: Code Considerations
This section is a collection of unfounded points without any hard proof that the
numbers are correct and tangible. Either there is a hard example on required
changes and added code size or remove it. This is an engineering document and not
a marketing document, isn't it?

Thanks,
 
  Martin Stiemerling