As mentioned in the first part of my IETF LC review of
draft-ietf-dnsext-rfc2671bis-edns0-08  also sent to the IETF
main list, I also found a couple of editorials that should be
addressed before publication -- maybe at the RFC Editor.

Editorials
==========

A) Recurring details, grouped by topic:

1)  usage of article with "DNS"

If used as a noun, "DNS" should better be accompanied by an article.
In particular:

- in Section 1, 2nd para:

|  [RFC2671] added an extension mechanism to DNS.  [...]
---                                         vvvvv
|  [RFC2671] added an extension mechanism to the DNS.  [...]

- in Section 3, 1st para:

|  EDNS provides a mechanism to improve the scalability of DNS as its
   uses get more diverse on the Internet.  [...]
---                                                       vvvvv
|  EDNS provides a mechanism to improve the scalability of the DNS as
   its uses get more diverse on the Internet.  [...]

- in Section 3, 2nd para:

|  With time, some applications of DNS have made EDNS a requirement for
   their deployment.  [...]
---                               vvvvv
|  With time, some applications of the DNS have made EDNS a requirement
   for their deployment.  [...]


2)  precise usage of "that" vs. "which"

According to the RFC Editor explanations, in the following instances
I found the "which" used in the draft needs to be replaced by "that":

- Section 2, 1st para:   "other DNS component that responds ..."

- Section 6.2.3, 3rd para (2 instances):
                                                                vvvv
|    [...].  For example, if a requestor sits behind a firewall that
   will block fragmented IP packets, a requestor SHOULD NOT choose a
|  value that will cause fragmentation.  [...]
         ^^^^
- Section 6.2.4:  "... an UPDATE that takes advantage of ..."

- Section 6.2.5, 2nd para:  "... a fallback mechanism that begins ..."

- Section 6.2.6, 3rd para:  "Middleboxes that simply forward ..."

- Section 6.2.6, 4th para:  "Middleboxes that have additional ..."

- Section 8, 3rd para:  "Responders that choose not to ..."

- Section 8, 4th para:  "... servers that do not implement ..."


3)  "rational quotation" style

Please adjust

- in Section 1, last para:

   [RFC2671] specified extended label types.  The only one proposed was
|  in [RFC2673] for a label type called "Bitstring Labels."  [...]
---                                                      ^^
   [RFC2671] specified extended label types.  The only one proposed was
|  in [RFC2673] for a label type called "Bitstring Labels".  [...]
                                                         ^^
- in Section 6.1.3, explanation of VERSION:

         Indicates the implementation level of the setter.  Full
         conformance with this specification is indicated by version
|        ``0.''  Requestors are encouraged to [...]
---         ^^^
         Indicates the implementation level of the setter.  Full
         conformance with this specification is indicated by version
|        ``0''.  Requestors are encouraged to [...]
            ^^^

  But there seems no need to quote the VERSION value 0 -- in the
  same paragraph and in other parts of the memo, field values are
  regularly shown literally or symbolically without any quotes.
  So it would be even more preferable to simplify this to:

         Indicates the implementation level of the setter.  Full
         conformance with this specification is indicated by version 0.
         Requestors are encouraged to [...]


4) Hyphenation

Please use hyphens in word combinations used as attributes:

- in Section 8, 4th para:

  s/out of range values/out-of-range values/

- in Section 9, 1st para:

  s/a DNS denial of service attack/a DNS denial-of-service attack/


B) singular details:

5)  Section 4.1

There seems to be a spurious comma, and two instances of "of" are
missing:

   The DNS Message Header's second full 16-bit word is divided into a
|  4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see ,
                v                                               ^^
|  section 4.1.1 [RFC1035]).  Some of these were marked for future use,
|  and most these have since been allocated.  [...]
---        ^
   The DNS Message Header's second full 16-bit word is divided into a
|  4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see section
|  4.1.1 of [RFC1035]).  Some of these were marked for future use, and
|  most of these have since been allocated.  [...]


6)  Section 5, 3rd para -- punctuation

For clarity, two commas should be added as follows to delineate
the first sub-clause starting with "which":

   Extended Label Types are difficult to use due to support in clients
|  and intermediate gateways as described in [RFC3364], which moves them
|  to experimental status, and [RFC3363], which describes the pros and
   cons.

Alternatively, the "which" sub-clauses might be placed parentheses:

   Extended Label Types are difficult to use due to support in clients
|  and intermediate gateways as described in [RFC3364] (which moves them
|  to experimental status) and [RFC3363] (which describes the pros and
   cons).

7)  Section 6.1.3, explanation of VERSION

  s/run time configuration option/runtime configuration option/
       ^

8)  Section 6.2.6

- In the first para, a comma should be placed for clarity in the
  1st line:

|  In a network that carries DNS traffic, there could ...
                                        ^
- At the very end of the last para, the trailing period is missing.


9)  Section 8, 4th para -- punctuation

I suggest to place a comma for clarity:

|       [...]  If this occurs, the responder MUST ...
                             ^

10)  Section 10 -- grammar / typos

- At about one third of the section:
                           vv
|  IANA is advised to udpates references to [RFC2671] in these entries
   and sub-registries to this document.
---                        v
|  IANA is advised to udpate references to [RFC2671] in these entries
   and sub-registries to this document.

- In the second-to-last para:

|     [...].  For many uses, a EDNS Option Code may be preferred.
---                          vv
|     [...].  For many uses, an EDNS Option Code may be preferred.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+