Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-01

[Donald Eastlake <[e-mail]>]

Hi Alfred,

There have been no objections to your suggested changes so I will go
ahead, make them, and post  revised version.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Fri, May 4, 2012 at 11:59 AM, Alfred HÎnes <[e-mail]> wrote:
> Donald,
>
> I really do appreciate all the efforts you have undertaken on the
> rfc6195bis draft, in particular the pain to improve the clarity and
> readability of the tables, which now all look pretty nice and clear.
>
> I have once more taken a full proofreading pass over the draft and
> think we're almost done with it now, so the Chairs might as well
> announce WGLC now.
> In that case, the few remarks below should be regarded as early WGLC
> comments.
>
>
> (1)  Small gap in assignment rules
>
> Now recently also dealing with the newest rfc3597bis draft,
> I found a single new topic that preferably should be clarified
> in the rfc6195bis document before publication:
>
> RFC 3597 (and again, rfc3597bis) define the 'synthetic' names
> to be used in the presentation format as the mnemonics for
> unknown CLASSes and RRTYPEs.
> For completeness and to protect against accidents, I suggest that
> very tiny clauses be added to the draft to indicate that these
> names must not be assigned by IANA:
>
> (1.1)
>
> The 4th paragraph of Section 3.1 says:
>
> |  RRTYPEs have mnemonics that must be completely disjoint from the
> |  mnemonics used for CLASSes and that must match the following regular
> |  expression:
> |
> |        [A-Z][A-Z0-9\-]*[A-Z0-9]
>
> I propose to insert after this snippet the new clause:
>
> |  Additionally, the 'synthetic' CLASS and RRTYPE names specified in
> |  Section 5 of [RFC3597] cannot be assigned as new RRTYPE mnemonics.
>
> Note that the 'synthetic' names also conform to the RE shown, so the
> present text does not preclude abuse.
>
> Using this (arguably unpleasant) indirect specification, room is
> left for potential future directions of rfc3597bis/ter/...  :-)
>
> RFC 3597 already is listed as a Normative Reference, so no change
> in References is needed.
>
> (1.2)
>
> Similarly, the 4th paragraph of Section 3.2 says:
>
> |  CLASSes have mnemonics that must be completely disjoint from the
> |  mnemonics used for RRTYPEs and that must match the following regular
> |  expression:
> |
> |        [A-Z][A-Z0-9\-]*[A-Z0-9]
>
> ... and I propose to insert after this snippet the new clause:
>
> |  Additionally, the 'synthetic' CLASS and RRTYPE names specified in
> |  Section 5 of [RFC3597] cannot be assigned as new CLASS mnemonics.
>
>
> (2)  Section 3.1.1 -- visual grouping of rules
>
> As mentioned recently on the list, it turned out to be a little hard
> to locate the processing rules for new RRTYPEs that cannot be treated
> by the customized Expert Review process described in the draft.
>
> I think this could be made better without changing the text, by
> simply re-grouping the first 2 paragraphs of Section 3.1.1; the first
> sentence of the current 2nd para logically belongs to the context
> of the 1st para, as it deals with the Expert Review only, and the
> 2nd sentence in the 2nd para describes the procedure to be followed
> when the subsequently listed preconditions for the Expert Review
> process are not met.  So I suggest to pack the 1st sentence to the
> 1st para and leave the conditional rules alone in the 2nd para.
>
> OLD:
>
> |  Parameter values specified in Section 3.1 above, as assigned based on
>   DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
>   meet the two requirements listed below. There will be a pool of a
>   small number of Experts appointed by the IESG. Each application will
>   be judged by an Expert selected by IANA. In any case where the
>   selected Expert is unavailable or states they have a conflict of
> |  interest, IANA may select another Expert from the pool.
> |
> |  Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs
>   that do not meet the requirements below may nonetheless be allocated
>   by a Standards Action as modified by [RFC4020].
>
> NEW:
>
> |  Parameter values specified in Section 3.1 above as assigned based on
>   DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
>   meet the two requirements listed below. There will be a pool of a
>   small number of Experts appointed by the IESG. Each application will
>   be judged by an Expert selected by IANA. In any case where the
>   selected Expert is unavailable or states they have a conflict of
> |  interest, IANA may select another Expert from the pool.  Some
> |  guidelines for the Experts are given in Section 3.1.2.
> |
> |  RRTYPEs that do not meet the requirements below may nonetheless be
> |  allocated by a Standards Action as modified by [RFC4020].
>
> Note that the present comma in the first line seems to be spurious,
> unnaturally separating   "... specified ... above as assigned ..."
>
>
> (3)  Remaining nits
>
> (3.1)  Section 3.1, table heading
>
> The heading for the 2nd table column is slightly misaligned;
>   s/Assignment Policy/  Assignment Policy/
>
> (3.2)  Section 3.1.4, leading paragraph
>
> Please fix the typo:  s/as show below/as shown below/
>
> (3.3)  Section 3.2, precision in text for 2 table entries
>
> In the table in Section 3.2, some descriptions have been clarified/
> improved by replacing "assigned" by "available for assignment",
> but two entries have been missed.  I suggest that this be aligned
> using the improved wording already introduced in other entries.
> Below, I have shortened the present text at the end to avoid
> overflow into an additional line.)
>
> OLD:
>
>   32,768 - 57,343
> |  0x8000 - 0xDFFF   Assigned for data CLASSes only; Specification
> |                    Required for new assignments
>
>   57,344 - 65,279
> |  0xE000 - 0xFEFF   Assigned for QCLASSes and meta-CLASSes only;
> |                    Specification Required for new assignments
>
> NEW:
>
>   32,768 - 57,343
> |  0x8000 - 0xDFFF   Available for assignment to data CLASSes only;
> |                    Specification Required
>
>   57,344 - 65,279
> |  0xE000 - 0xFEFF   Available for assignment to QCLASSes and meta-
> |                    CLASSes only; Specification Required
>
>
> Kind regards,
>  Alfred.
>
> --
>
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> +------------------------+--------------------------------------------+
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext