Subject: Re: [dnsext] rfc6195bis registration template clarification

From: Donald Eastlake <[email-masked]>
Date: Wed, 2 May 2012 15:49:25 -0400

I'm OK with the below suggested change to the appellation template.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Mon, Apr 23, 2012 at 2:37 PM, Alfred HÎnes <[email-masked]> wrote:
> I tried to figure out whether the rfc1995bis-ixfr draft needs
> to undergo the RRtype Expert Review per RFC 6195[bis].
>
> It looks like that review only pertains to Data and Meta-RRtypes,
> (and the draft -- targeting Standards Track -- needs IETF review),
> but the registration policy table for RRtypes (entry for range
> 128-255) could be misunderstood to indicate otherwise.
>
> When looking at the registration template in RFC 6195[bis],
> I missed a structured opportunity for the applicant to indicate
> whether the application is for a Data RR or Meta-RR, which would
> be significant for IANA to select a proper numerical range in the
> assignment process.
>
> So I suggest to amend clause B. of the template in Appendix A of
> the rfc6195bis I-D as follows:
>
> OLD:
>
> |  B. Submission Type:
> |     [ ] New RRTYPE
> |     [ ] Modification to existing RRTYPE
>
> NEW:
>
> |  B. Submission Type:
> |     [ ] New RRTYPE
> |     [ ] Modification to existing RRTYPE
> |
> |     Kind of RRTYPE:
> |     [ ] Data RR
> |     [ ] Meta-RR
>
> As an alternative, a new numbered item might be inserted; that
> would cause the need to renumber the exicsting items, which perhaps
> is less desirable for backwards compatibility with RFC 6195.
> A third alternative would be using item numbers "B.1." and "B.2.".
>
> Best regards,
>  Alfred.
>
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 03 May 2012 14:36:55 -0400

I'm not, meta types are for DNS software consumption so adding meta 
types involves processing.

	Olafur

On 02/05/2012 15:49, Donald Eastlake wrote:
> On Mon, Apr 23, 2012 at 2:37 PM, Alfred HÎnes<[email-masked]>  wrote:

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 3 May 2012 14:42:26 -0400

Hi,

On Thu, May 3, 2012 at 2:36 PM, Olafur Gudmundsson <[email-masked]> wrote:
> I'm not, meta types are for DNS software consumption so adding meta types
> involves processing.

RFC 6195 and its previous versions have always allowed ignorable meta
RR types to be allocated with expert approval. The only change is to
add some check boxes to the template.

Thanks,
Donald

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 4 May 2012 17:59:45 +0200 (MESZ)

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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 28 May 2012 14:03:13 -0400

Hi Alfred,

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

Thanks,
Donald