[regext] Fwd: New Version Notification for draft-hardie-iris-arpa-00.txt
Howdy, A reviewer of this draft suggested that it would be useful to have it reviewed by this list as well. If you have thoughts on suggestions on it, please let me know. best regards, Ted Hardie -- Forwarded message -- From: Date: Thu, Jan 11, 2018 at 9:08 AM Subject: New Version Notification for draft-hardie-iris-arpa-00.txt To: Ted Hardie A new version of I-D, draft-hardie-iris-arpa-00.txt has been successfully submitted by Ted Hardie and posted to the IETF repository. Name: draft-hardie-iris-arpa Revision: 00 Title: Iris.arpa is Deprecated Document date: 2018-01-10 Group: Individual Submission Pages: 3 URL:https://www.ietf.org/internet-drafts/draft-hardie-iris-arpa- 00.txt Status: https://datatracker.ietf.org/doc/draft-hardie-iris-arpa/ Htmlized: https://tools.ietf.org/html/draft-hardie-iris-arpa-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hardie-iris- arpa-00 Abstract: This document requests that iris.arpa and areg.iris.arpa be removed from the arpa zone. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [art] New Version Notification for draft-hardie-iris-arpa-00.txt
Sorry for the delay in replying; I was returning from the QUIC meeting in Melbourne. On Thu, Jan 25, 2018 at 7:13 AM, John C Klensin wrote: > > > --On Thursday, January 25, 2018 14:55 +0100 Frank Ellermann > wrote: > > > On 22 January 2018, Ted Hardie wrote: > >> If you have thoughts > > > > Maybe "obsoletes 4698" instead of only "updates 4698" would be > > clearer for readers of RFC 4698. > > Ted, > > Unless there are considerations that I don't understand, I agree > with Frank and would go a step further. While the document > indicates that IRIS was not actually deployed for address > registry usage, as far as I know it has not been deployed for > anything else either and has become part of the wreckage along > the path to try to replace Whois for registry database use. > > If the intent here is to say "we have given up on IRIS" > This came up in the context of the IAB trying to work out how useful some of the existing delegations in .arpa are, and the current draft reflects that. Updating RFC 4698 was, in other words, the simplest thing we could do. Given the feedback, I'm fine with updating that to "obsoletes RFC 4698", since the data support the notion that this is not currently in use. I don't have the data to support a broader statement about IRIS, as I know that there was some deployment at one time. I would be fine seeing a deprecation if one is warranted, in other words, but I'm not sure I can put one forward to the community. Do you object to obsoleting just RFC 4698 by this document? regards, Ted > (probably just recognizing what has happened historically), then > we should be formally obsoleting all of the IRIS documents at > the same time (and/or moving them to Historic) so they are no > longer listed as Proposed Standards and implicitly recommended. > That means at least RFC 4698 but also 4414 and the original > protocol specifications (3982-3983). That would require > broadening the scope of this document somewhat and adjusting its > title but, having skimmed through it, would not require > significant work. > > By contrast, if you believe that the ISOS protocols and the > other registries and identifiers are still relevant for > implementation and use, I think it would be helpful if this > document said that explicitly. For example, you might > explicitly indicate that IRIS had additional applications (with > a reference or two) and that, unlike the address registries, > those are still in use and Recommended. > > best, >john > > > ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [art] New Version Notification for draft-hardie-iris-arpa-00.txt
On Mon, Jan 29, 2018 at 11:27 AM, John C Klensin wrote: > > >> Unless there are considerations that I don't understand, I > >> agree with Frank and would go a step further. While the > >> document indicates that IRIS was not actually deployed for > >> address registry usage, as far as I know it has not been > >> deployed for anything else either and has become part of the > >> wreckage along the path to try to replace Whois for registry > >> database use. > >> > >> If the intent here is to say "we have given up on IRIS" > >> > > > > This came up in the context of the IAB trying to work out how > > useful some of the existing delegations in .arpa are, and the > > current draft reflects that. Updating RFC 4698 was, in other > > words, the simplest thing we could do. Given the feedback, > > I'm fine with updating that to "obsoletes RFC 4698", since the > > data support the notion that this is not currently in use. > > > > I don't have the data to support a broader statement about > > IRIS, as I know that there was some deployment at one time. I > > would be fine seeing a deprecation if one is warranted, in > > other words, but I'm not sure I can put one forward to the > > community. > > > > Do you object to obsoleting just RFC 4698 by this document? > > Object, not really. I do see it as creating something of a > silly state in which we leave the protocol apparently active and > recommended while eliminating a key facility for utilizing it in > a particular way should one decide to do so. This actually reflects how the IRIS documents specified the extension to include address registrations; that facility was separately specified and could have been separately deployed. As far as we can tell, no one has deployed AREG. I've agreed that obsoleting the document, rather than simply updating it, appears to have community support. To put this another way, I personally see the AREG and DREG uses of IRIS as distinct, and I believe that reflects both the document structure and my ability to get data on their use. The data provided by examining the logs shows that there is no current use of RFC 4698 facilities, but there is no parallel data set for DREG available to me. > The only thing > that makes the address registries different in this regard is > that the number of possible uses is small and easily identified. > > One of your comments above helps identify what concerns me about > this document, so let me take a step back and address that. So > the IAB decides that it should do a review of "how useful some > of the existing delegations in .arpa are". Seems worthwhile to > me although I might wonder whether the Internet and the various > protocol relationships were in such good shape that the IAB > should prioritize that work, It originally came up in the context of https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ but the discussion after that was pretty clear that the IAB couldn't deprecate anything requested in Proposed Standard without an IETF consensus document. That's why this is a personal document going for proposed standard, not an IAB document. > But then I'd expect an I-D that > said that the IAB had conducted that review and was, e.g., > elimination all of the subdomains/ registries that were unused > or that supported obsolete protocols (or particular applications > of protocols) and obsoleted the standards-track documents > creating those registries. Perfectly orderly. > > Each of the others where we might consider deprecation also requires an IETF consensus document, and they represent different communities of use (or did when specified). Putting them all into one document would make this more "the IAB has decided" than "X, who happens to be a member of the IAB, suggests that the IETF should consider deprecation of FOO". The latter seems more in keeping with our practice, at least as far as I see it. Had the community already obsoleted the relevant protocols, then I agree, the IAB could clean up the delegations without further ado. regards, Ted ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Errata Verified] RFC7482 (5621)
Howdy, I note John suggests a reference to either RFC 8499 or RFC 5980. The latter is almost certainly meant to be RFC 5890, since that is the definitions and document framework for the IDNA 2008 series. I would disagree, however, that this is a useful reference, since neither RFC 5980 or RFC 5984 (which supplies the rational) actually has a definition of the form this document presumes. RFC 3490 does: An "internationalized domain name" (IDN) is a domain name in which every label is an internationalized label. This implies that every ASCII domain name is an IDN (which implies that it is possible for a name to be an IDN without it containing any non-ASCII characters). This document does not attempt to define an "internationalized host name". Just as has been the case with ASCII names, some DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Such restrictions have no impact on the syntax or semantics of DNS protocol messages; a query for a name that matches no records will yield the same response regardless of the reason why it is not in the zone. Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions. but given it was obsoleted by RFC 5980, I think you are left with RFC 8499 as the best choice. regards, Ted On Tue, Mar 5, 2019 at 12:18 PM RFC Errata System wrote: > The following errata report has been verified for RFC7482, > "Registration Data Access Protocol (RDAP) Query Format". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5621 > > -- > Status: Verified > Type: Editorial > > Reported by: John Klensin > Date Reported: 2019-02-01 > Verified by: Adam Roach (IESG) > > Section: 2.1 > > Original Text > - > IDN: Internationalized Domain Name > > IDNA: Internationalized Domain Names in Applications, a protocol > for the handling of IDNs. > > Corrected Text > -- > IDN: Internationalized Domain Name, a [fully-qualified] domain name > containing one or more labels that are intended to include one or more > Unicode code points outside the ASCII range (cf. "domain name", > "fully-qualified domain name" and "internationalized domain name" in > RFC 8499). > > IDNA: Internationalized Domain Names in Applications, a protocol for > the handling of IDNs. In this document, "IDNA" refers specifically to > the version of those specifications known as "IDNA2008" [RFC5980]. > > > Notes > - > While the proposed new text above borders on the painfully pedantic, > failure to be specific about these things undermines the technical validity > and consistency of the text (making this a technical issue rather than > exclusively an editorial one like a missing reference). IDNA2008 [RFC5890 > Section 2.3.2.3] is very precise about what an "IDN" is (a definition > incorporated by reference in RFC 6365 and consistent with the definition in > RFC 8499) , but there are other things around that, e.g., assume either > that "IDN" refers to a label, not an FQDN; that an ASCII label, even one in > ACE form, does not make the FQDN in which it is imbedded an IDN; that all > of the label components of an IDN must be U-labels or A-labels, etc. > Without the definition being clear, some of the statements in the document > make no sense. > > A reference to 8499 is suggested above because it is the most recent > authoritative definition (and because I didn't write it), but 5980 would be > equally legitimate if the authors prefer. > > Pinning down the IDNA definition is even more important. While there are > IDNA2008 references further on in the document, if the question of what the > generic term "IDNA" means is left to the imagination of the reader, then > the specification is missing language about what to do if, e.g., a query is > inconsistent with the U-label form of what is stored in the registry > database without mapping. The opportunity for that sort of problem is > clearly created by the "performs any local case mapping deemed necessary" > statement in Section 6.1 of the document, at least unless that case mapping > is constrained to not be applied to domain name labels (which the text > definitely does not say). > > -- > RFC7482 (draft-ietf-weirds-rdap-query-18) > -- > Title : Registration Data Access Protocol (RDAP) Query Format > Publication Date: March 2015 > Author(s) : A. Newton, S. Hollenbeck > Category: PROPOSED STANDARD > Source : Web Extensible Internet Registration Data Service > Area: Applications > Stream : IETF > Verifying Party : IESG > >
