Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. Sam, most of the changes are results of the allocation experiment that was conducted. The working group was fully aware of them and the changes made to the document see: http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html While it may well the be case that MOST of the changes resulted from the experiment and were called out to the WG, the change I cited (re: creating IANA registries using templates) was neither a result of the experiment (having been made before the experiment), nor called out. As for the WG being fully aware of the changes resulting from the experiment, I note that between the end of WGLC in November 2006 and the start of IETF last call a year later (which included the time of the experiment), the namedroppers list appears to have seen fourteen posts about 2929bis. The post-experiment discussion of these changes was minimal at best. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? This is an excellent IETF wide question it is outside the DNSEXT WG expertize to judge this issue. At this point there is no specific guidance to the expert(s) on what to do in this case. I'm glad you agree that it is an excellent question. I suspect it's one of the things IANA plans to weigh in on. -- Sam ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
At 11:50 04/12/2007, Sam Weiler wrote: This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. Sam, most of the changes are results of the allocation experiment that was conducted. The working group was fully aware of them and the changes made to the document see: http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. Yes this is an oversight on the editors part and mine as well, sorry. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? This is an excellent IETF wide question it is outside the DNSEXT WG expertize to judge this issue. At this point there is no specific guidance to the expert(s) on what to do in this case. I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. I hope there are not any more skeletons in the closet :-) On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. good. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam Olafur ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
Hi Sam, It appears that, somehow, I overlooked message [2] below when I was editing the document. Thanks for catching that. I'd be happy to make the two changes agreed to: changing who to whose in one case (an error a couple of other people have noticed) and changing IETF Consensus to IETF Review. I believe that other changes you suggested were found by the WG Chair not to have WG consensus. Thanks, Donald -Original Message- From: Sam Weiler [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 04, 2007 11:51 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP
Hi, Thanks for your comment on 2929bis. See response below at @@@ -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 5:08 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG [EMAIL PROTECTED] wrote a message of 24 lines which said: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from IETF consensus to the new DNS RRTYPE Allocation Policy in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: a Meta-Type who processing is optional, I believe it should be whose processing). @@@ Thanks for finding this typo. But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), @@@ I do not see any reason to provide for extension of consideration or mid-stream modification to applications. The Expert is required by 2929bis to monitor namedroppers discussion of applications for an RR Type and applicants are encouraged by 2929bis to informally post applications to get feedback. So the applicant should normally have early feedback from the Expert. In cases where the formal application is rejected and the Expert provides suggested changes, it seems simpler and cleaner for the applicant to resubmit, rather than modify. This also fits with the DNSEXT WG consensus that the namedroppers community have three weeks to examine any application, to reduce the chance of someone missing something because they are on vacation or the like, rather than the more common IETF posting requirement of two weeks (which is used in 4646bis). @@@ I personally don't see why someone would think there is a time extension or mid-stream change facility for 2929bis when none is provided in the document; but I don't object to adding a few words to make this clear. * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, @@@ This is probably a good point. The addition of a specific requirement for the assigned Expert to post an acceptance or rejection (presumably to IANA, namedroppers, and the applicant) within a reasonable period of time, such as six weeks from the formal posting of the completed template to namedroppers, seems reasonable to me. * appeals to the IESG @@@ I see no need to include this. 2929bis normatively references RFC 2434 which says: @@@Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF- PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG. May be such wording should appear in draft-ietf-dnsext-2929bis? @@@ How about adding the following to Section 3.1.1? @@@ After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. @@@ Thanks again, @@@ Donald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS)IANA Considerations) to BCP
On Thu, Nov 29, 2007 at 04:16:19PM -0500, Eastlake III Donald-LDE008 [EMAIL PROTECTED] wrote a message of 103 lines which said: How about adding the following to Section 3.1.1? After a completed template has been formally posted to namedroppers by IANA the Expert shall post a message, explicitly accepting or rejecting the application, to IANA, namedroppers, and the email address provided by the applicant not less than three weeks and not more than six weeks after the formal posting. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. It seems fine to me. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
On Mon, Nov 19, 2007 at 10:48:11AM -0500, The IESG [EMAIL PROTECTED] wrote a message of 24 lines which said: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP I approve the goal (the main change is to simplify the registration of new DNS Resource Record codes, from IETF consensus to the new DNS RRTYPE Allocation Policy in section 3.1.1 of the I-D). I've read the document and I've found only one typo (3.1.1: a Meta-Type who processing is optional, I believe it should be whose processing). But I find that the Expert Review process in section 3.1.1 may be described too lightly. I base my opinion on experience with the ietf-languages process (RFC 4646) which uses a similar expert review. There have been some problems such as deadlocking (the expert thought his previous comments were to be addressed, while the requester thought he had to wait the expert) or uncertainty about delays (does a new form, sent to address some comments, reset the period?). draft-ietf-ltru-4646bis-09 (section 3.5) specifically addresses these points, which seem to be ignored in draft-ietf-dnsext-2929bis-06.txt: * modifications made to the request during the course of the registration process (they extend the period, but do not reset it), * clear indication of the outcome of the process (acceptance, rejection, extension). Some requests on ietf-languages saw the period pass and no decision taken, * appeals to the IESG May be such wording should appear in draft-ietf-dnsext-2929bis? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Domain Name System (DNS) IANA Considerations ' draft-ietf-dnsext-2929bis-06.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-12-03. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13373rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
