I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-bchv-rfc6890bis-04
Reviewer: Paul Kyzivat
Review Date: 2017-02-28
IETF LC End Date: 2017-03-10
IESG Telechat date:

Summary:

Ready with Issues

General Comments:

It seems that the primary intent of this document is simply to clarify 
the use of the term "Global". As such it should be just an editorial 
change.

However it takes on the job of restating all the data in RFC6890 that 
provided the initial population of the IANA registries, and also 
restating all the new entries that have been added to those registries 
since RFC6890 was published. And the editorial changes apply to every 
table entry, so there are a *lot* of changes. A diff of the new document 
against the old one fails to match up the appropriate corresponding 
tables, making the document especially hard to review.

I have *tried* to at least spot check the changes, especially those for 
registrations made since RFC6890. But I did not do an exhaustive check 
of every one.

Issues:

Major: 0
Minor: 1
Nits:  1

(1) Minor:

I am concerned that the format of this document may be difficult for 
IANA to act on, and may increase the potential for mistakes to be 
introduced. The IANA format for their special purpose IP address 
registries contains the same information as this document but in a 
different format. If I understand correctly, no changes are required to 
the per-address content of the registries - only the introductory 
content and table headings need changes. But given the document format 
IANA will be obligated to check the content of every entry.

I suggest that it might be better to eliminate duplicating the table 
content, and simply state what changes need to be made to the registries.

(2) NIT:

There is an error in the use of footnotes in Table 38. The reference to 
footnote "[2]" should be "[6]". (The footnote numbering has changed 
since RFC680, but both references were intended to be to the same footnote.)