Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt

From: Frank Ellermann <[email-masked]>
Date: Thu, 25 Jan 2018 14:55:27 +0100

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.

---

From: John C Klensin <[email-masked]>
Date: Thu, 25 Jan 2018 10:13:32 -0500

--On Thursday, January 25, 2018 14:55 +0100 Frank Ellermann
<[email-masked]> wrote:

> 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"
(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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Jan 2018 10:20:37 -0500

> the path to try to replace Whois for registry database use.

My understanding is that DCHK did get deployed by two domain
registries. I do not know if they still use it though.

> title but, having skimmed through it, would not require

In my opinion, "we have given up on IRIS" is the proper thing to say.

-andy

---

From: John C Klensin <[email-masked]>
Date: Thu, 25 Jan 2018 10:42:15 -0500

--On Thursday, January 25, 2018 10:20 -0500 Andrew Newton
<[email-masked]> 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.
> 

Even if they do, a move to Historic and/or Obsolete doesn't
change their situation, it is just an implicit recommendation
that others should not rush out to deploy this or even actively
consider it as a option.  If something more nuanced is needed,
it is probably time to write an A/S and have this particular
registry/ subdomain removal be part of that.

>> (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.
> 

Sad although probably right.   It was and remains, at least in
my opinion, a nice piece of work.   That actually leads to
another commend, which is that I'd much rather see a document
like this say something equivalent to "overtaken by events" or
"use no longer recommended" rather than "deprecated".

best,
   john

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Jan 2018 10:11:04 -0800

Sorry for the delay in replying; I was returning from the QUIC meeting in
Melbourne.

> 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

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Jan 2018 14:27:32 -0500

--On Monday, January 29, 2018 10:11 -0800 Ted Hardie
<[email-masked]> wrote:

> Sorry for the delay in replying; I was returning from the QUIC
> meeting in Melbourne.
> 

>> > Maybe "obsoletes 4698" instead of only "updates 4698" would
>> > be clearer for readers of RFC 4698.
>> 
>> Ted,
>> 
> 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.
> 

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.   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,  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.

But, here, the document seems to single out one particular
subtree and a single application of a protocol that has gotten
little or no traction in it more general form.  It that is the
topic, I think the IAB is under some obligation to explore that
protocol and its present-day utility and active implementations
a bit further (especially in the light of Andy's note) or, if
that is too burdensome, to include a (very brief) explanation
about why IRIS itself is not being retired and/or why the IAB
doesn't consider it useful to examine that question.

Disclaimer: My position on this issue is conditioned by part of
my view of the role of the IAB in current times.  That view is
that the IAB should be functioning as a sort of architectural
think tank and, (at least at the conceptual level), an oversight
body.  That, in turn, implies that the IAB should be looking at
whole-system issues, specifically including how particular
protocols and sets of protocols interact with what has recently
started being called the "Internet ecosystem".  While it isn't
my personal highest priority, I think the IAB's taking on a
review of RFC 3172 and clean-out of registries that are no
longer relevant would be a find idea.  Conversely, if the IAB
decides at another look --at a system-wide level-- at registry
databases of many or all flavors is in order, I'd consider that
a worthy task, even if it focused on cleaning up the options
that have never taken off, whether you went back to Whois++
(which has been declared obsolete) or Rwhois (which hasn't).
But to clean out a single application (and registry) or a single
protocol just seems to me like a poor use of time and a likely
source of confusion for those who might decide to read and think
about the IRIS protocol documents.

My vocabulary is somewhat different from that used by Brian and
the IAB in 2008, but I believe it is consistent with RFC 2850.

If the community no longer believes in that vision of the IAB,
my view may be irrelevant, but a revision or replacement for RFC
2850 is probably in order.

best,
   john

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Jan 2018 11:55:18 -0800

On Mon, Jan 29, 2018 at 11:27 AM, John C Klensin <[email-masked]> wrote:

> 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
> 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
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

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Jan 2018 15:35:31 -0500

Ok, Ted, I can buy this, albeit somewhat reluctantly and noting
that the IAB has passed IAB documents that require community
consensus off to the IESG for determination of that consensus in
the past.  I believe a paragraph of explanation, in your
personal capacity and very much along the lines of what you say
below, would be desirable, but don't see its absence as a
showstopper.

thanks for the explanation.
    john

--On Monday, January 29, 2018 11:55 -0800 Ted Hardie
<[email-masked]> wrote:

>> >> deployed for anything else either and has become part of
>> >> the wreckage along the path to try to replace Whois for
>> >> registry database use.
>> >> 
>> > 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
>> > IRIS, as I know that there was some deployment at one time.
>> > I would be fine seeing a deprecation if one is warranted, in
>> 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
>> 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,
> 
> 
> 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.
> 
> 
> 
>> 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