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

"t.petch" <ietfc@btconnect.com> Thu, 03 February 2011 17:45 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20753A6A2D for <apps-discuss@core3.amsl.com>; Thu, 3 Feb 2011 09:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5u-B4OWEhRt for <apps-discuss@core3.amsl.com>; Thu, 3 Feb 2011 09:45:58 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by core3.amsl.com (Postfix) with ESMTP id 43E323A69D9 for <apps-discuss@ietf.org>; Thu, 3 Feb 2011 09:45:57 -0800 (PST)
Received: from host81-152-46-124.range81-152.btcentralplus.com (HELO pc6) ([81.152.46.124]) by c2beaomr08.btconnect.com with SMTP id BOL53320; Thu, 03 Feb 2011 17:49:10 +0000 (GMT)
Message-ID: <012101cbc3c1$bda06120$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: John C Klensin <john-ietf@jck.com>, apps-discuss@ietf.org
References: <4D4A8420.9070908@gmail.com> <F53A46A23D8CBE34742675AB@PST.JCK.COM>
Date: Thu, 03 Feb 2011 17:45:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D4AEA95.0132, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4D4AEA96.013D, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Subject: [apps-discuss] sftp Re: Request for Review - draft-yevstifeyev-rlogin-uri-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2011 17:45:59 -0000

John

A propos sftp, there was a joint ssh/sftp I-D in the secssh WG but it fell
by the wayside for lack of support in the WG.  The ssh part made it to IETF
Last Call last November and, 50 days later, the status is revised I-D needed.

Tom Petch


----- Original Message -----
From: "John C Klensin" <john-ietf@jck.com>
To: "Mykyta Yevstifeyev" <evnikita2@gmail.com>; <apps-discuss@ietf.org>
Sent: Thursday, February 03, 2011 4:54 PM
Subject: Re: [apps-discuss] Request for Review - draft-yevstifeyev-rlogin-uri-00


> Mykyta,
>
> 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
>
http://www.freebsd.org/cgi/man.cgi?query=rlogin&apropos=0&sektion=0&manpath=Free
BSD+8.1-RELEASE&format=html
> 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.
>
> regards,
>    john
>
>
> --On Thursday, February 03, 2011 12:32 +0200 Mykyta Yevstifeyev
> <evnikita2@gmail.com> wrote:
>
> > Hello all,
> >
> > In accordance with RFC 4395 I'm asking to review the
> > draft-yevstifeyev-rlogin-uri-00, that can be found here:
> > http://tools.ietf.org/html/draft-yevstifeyev-rlogin-uri-00
> >
> > 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
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss