Re: [apps-discuss] Request for Review - draft-yevstifeyev-rlogin-uri-00

John C Klensin <> Thu, 03 February 2011 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B1E43A6932 for <>; Thu, 3 Feb 2011 07:51:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.928
X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z2ciZ27HEI-Z for <>; Thu, 3 Feb 2011 07:51:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AF0B83A697E for <>; Thu, 3 Feb 2011 07:51:05 -0800 (PST)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1Pl1Vr-0008ef-KE; Thu, 03 Feb 2011 10:54:27 -0500
Date: Thu, 03 Feb 2011 10:54:26 -0500
From: John C Klensin <>
To: Mykyta Yevstifeyev <>,
Message-ID: <F53A46A23D8CBE34742675AB@PST.JCK.COM>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] Request for Review - draft-yevstifeyev-rlogin-uri-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Feb 2011 15:51:07 -0000


Please consider this a micro-review as well as a request.

Speaking for myself and not in any "official" capacity I might
have, I really appreciate the amount of energy and effort you
are putting into updating and classifying documents and tying up
assorted loose ends.  Unfortunately, many of us have other
commitments both inside and outside the IETF, to the point that
your having many individual submission (non-WG) documents
outstanding at once almost guarantees that few of them will get
adequate review.  Reflecting on some of the other comments you
have received, I suggest that the dividing line between "useful
update or supplement to existing protocol or document" and
"waste of time" is very narrow indeed.   While a specification
or three that lay close to that boundary might be accepted by
the community (especially if well-motivated as to why the work
is needed), a large collection of such proposals, without good
motivation, are likely to result in increases in the number of
people who assume everything you are submitting falls into the
"wasting your time and that of everyone else" category.

May I suggest that you try to prioritize review requests
somewhat so as to avoid having the decisions as to what gets
reviewed made at random or of having people conclude that you
simply have too much time on your hands and assume others do too.

In the case of this particular spec, my decision to look at it
was more driven by curiosity about what you had covered and the
particular time at which I saw you note than by any rational
decision on my part.  I consider that a symptom of the problem.
However, now that I have glanced at it:

(1) Despite the assertions in the draft, rlogin was never
defined by the IETF.  Both RFCs 1258 and 1282 are informational
documents that described the state of the protocol (as of twenty
years ago) for the information of the IETF community.  Neither
reflects the state of the protocol or user-level commands as
they are implemented and defined today.  You might examine
as an example of documentation that is closer to the
contemporary practice (but it only describes one implementation
for one operating system).

(2) It is probably a bad idea to create URIs that make it easy
to use badly-designed, security-problematic, protocols... and to
use them in those problematic ways.    If there were a
compelling need to do so, that might be different but, IMO, it
would also carry with it the need to either 

	-- have an up-to-date IETF spec with a decent security
	analysis or
	-- reference documentation for at least most the popular
	implementations in the URI spec and include a security
	analysis there.

(3) If we really want to do a URI for rlogin (you can deduce
from the rest of this message that I have my doubts), we should
do something complete and comprehensive, addressing both the
many options in contemporary versions of the protocol and the
other transports over which similar facilities are used.

(4) There is a very general design question about the
desirability of defining URIs to open terminal sessions or the
equivalent.  I seem to be in the IETF minority in being
concerned about that (e.g., we have a Telnet URI registered and
the ftp one can be used to open an interactive session), but I
think it would be lots more useful to get a URI defined for rsh
(or to combine the two) or sftp than to have one for rlogin.
Whether even though would fall above the threshold for not being
a waste of time is a separate question; again, I have my doubts.


--On Thursday, February 03, 2011 12:32 +0200 Mykyta Yevstifeyev
<> wrote:

> Hello all,
> In accordance with RFC 4395 I'm asking to review the
> draft-yevstifeyev-rlogin-uri-00, that can be found here:
> This document specifies the 'rlogin' URI scheme.  The Rlogin
> protocol is defined in RFC 1282.
> Thank you for your time,
> Mykyta Yevstifeyev
> P.S. I've also posted such message on uri-review list.  Mykyta