From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 2 13:00:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09761 for ; Thu, 2 Jan 2003 13:00:56 -0500 (EST) Received: (qmail 23350 invoked by uid 605); 2 Jan 2003 18:03:54 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20030102180354.23349.qmail@mail.netbsd.org> Received: (qmail 23341 invoked from network); 2 Jan 2003 18:03:52 -0000 Received: from r200-71-8-128.multitel.com.uy (HELO hotmail.com) (200.71.8.128) by mail.netbsd.org with SMTP; 2 Jan 2003 18:03:52 -0000 From: "La Sociedad Digital / A Sociedade Digital" To: (La Sociedad Digital) Subject: Comunicacion cientifica a la comunidad de Internet y de la Sociedad de la Informacion Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 3 Jan 2003 02:35:54 -0300 Reply-To: "La Sociedad Digital / A Sociedade Digital" Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Versión español al frente, versión portuguesa a continuación, versión inglesa al final. ---------------------------------------------------------------------- ------------ Comunicación científica a la comunidad de Internet y a la comunidad de la Sociedad de la Información. La Sociedad Digital – www.sociedaddigital.org / www.asociedadedigital.org La presente comunicación tiene como objetivo informar a la comunidad de Internet y a la comunidad de la Sociedad de la Información las novedades de los últimos meses del Proyecto La Sociedad Digital. La Sociedad Digital es un proyecto abierto a la comunidad de Internet y de la Sociedad de la Información en el ámbito iberoamericano principalmente, pero no restringido exclusivamente a él. Se trata de la creación del primer espacio de convergencia para los especialistas de habla castellana y portuguesa, bajo la forma de un Portal de la Sociedad de la Información (www.sociedaddigital.org / www.asociedadedigital.org). La estructuración de este espacio comprende, en primer lugar, una subdivisión por áreas temáticas consideradas trascendentes para el desarrollo de la Sociedad de la Información, tales como lengua, brecha digital, gobierno digital, estudios especiales, legislación, situación por países, etc. Una segunda subdivisión apunta a elementos de interactividad como noticias, proyectos, observatorios de información, etc. que apuntan a generar un espacio de intercambio y sinergia entre los especialistas de la región, en la búsqueda de modelos de aplicación y resultados de investigaciones, para que todos sus participantes puedan beneficiarse, construyendo, entre todos, el espacio de la Sociedad de la Información en su tránsito hacia la Sociedad del Conocimiento. Invitamos, en consecuencia, a todos, a visitar el Portal, integrarse, enviar sus aportes intelectuales y usar todos los recursos en él disponibles, los que son, por supuesto, de uso libre y gratuito. (www.sociedaddigital.org / www.asociedadedigital.org). Pueden comunicarse a info@sociedaddigital.org. Todos los comentarios, aportes y observaciones serán bienvenidos. Muy cordialmente, El Presidente del Consejo de Directores de La Sociedad Digital, Prof. Dr. Ricardo Petrissans de Aguilar ricardo@sociedaddigital.org La presente comunicación se realiza por única vez. Se trata de una comunicación científica destinada a los miembros de la Comunidad Científica Iberoamericana. En caso que este mensaje sea considerado por su receptor como carente de interés, rogamos se sirva deletear el mismo. Muchas gracias. __________________________________________________ Comunicação Científica à comunidade da Internet e à Comunidade da Sociedade da Informação. La Sociedad Digital comunica aos usuários da Internet e à comunidade da Sociedade da Informação La Sociedad Digital - www.sociedaddigital.org / www.asociedadedigital.org A presente comunicação tem como objetivo informar à comunidade da Internet e à Comunidade da Sociedade da Informação as novidades dos últimos meses do Projeto da Sociedade Digital. La Sociedad Digital é um projeto aberto à comunidade da Internet e à Sociedade da Informação no âmbito ibero-americano, principalmente, porém não restrito exclusivamente a ele. Trata-se da criação do primeiro espaço de convergência para os especialistas de idioma castelhano e português, sob a forma de um Portal da Sociedade da Informação (www.sociedaddigital.org / www.asociedadedigital.org). A estruturação deste espaço compreende, em primeiro lugar, uma subdivisão por áreas temáticas, consideradas transcendentes para o desenvolvimento da Sociedade da Informação, tais como idioma, brecha digital, governo digital, estudos especiais, legislação, situação por país, etc. Uma segunda subdivisão aponta para elementos de interatividade como notícias, projetos, observatórios de informação, etc., no sentido de gerar um espaço de intercâmbio e sinergia entre os especialistas da região, na busca de modelos de aplicação e resultados de investigações, para que todos seus participantes possam se beneficiar, construindo entre todos o espaço da Sociedade da Informação em seu trânsito até a Sociedade do Conhecimento. Convidamos, então, a todos para uma visita ao Portal, para se integrarem, enviar suas contribuições intelectuais e usar todos os recursos nele disponíveis, que são de uso livre e gratuito. (www.sociedaddigital.org / www.asociedadedigital.org). Para se comunicarem, utilizem info@sociedaddigital.org Todos os comentários, contribuições e observações serão bem-vindos. Cordialmente Prof. Dr. Ricardo Petrissans de Aguilar Presidente do Conselho de Diretores de La Sociedad Digital ricardo@sociedaddigital.org A presente comunicação se realiza uma única vez. Trata-se de comunicação científica destinada aos membros da Comunidade Científica Ibero-americana. Caso esta mensagem seja considerada pelo receptor como carente de interesse, pedimos que seja deletada. Muito obrigado. ________________________________________________________________ Scientific message to the Internet Community and to the Information Society Community. The Digital Society – www.sociedaddigital.org / www.asociedadedigital.org This message has the objective of informing the Internet Community and the Information Society Community the latest news about The Digital Society Project. The Digital Society is a project open mainly to the Internet Community and the Information Society Community in Latin American, however without restrictions to any other countries or regions in the world. It is about the creation of the first forum to portuguese and spanish speaking specialists, under the structure of an internet gate (www.sociedaddigital.org / www.asociedadedigital.org). The structure of this space is divided, in its first level, into areas considered of extreme importance to the development of the Information Society, such as language, (brechas digitais), e-Government, special studies, legislation and country information. On a second level, there are interactive elements such as news, special projects and information centres designed to promote interchanges and synergy between regional specialists, always searching for new models, applications and research results, benefiting all users and paving the road between the Information Society and the Knowledge Society. Therefore, we invite everyone to visit the Internet site, integrate yourself in the community, contribute with your knowledge and use all free available resources. Our address : (www.sociedaddigital.org / www.asociedadedigital.org). Please send any queries and comments to info@sociedaddigital.org. All comments, queries and contributions are welcome. Cordially, President of the Digital Society Board of Directors Ricardo Petrissans de Aguilar, MSc, PhD. ricardo@sociedaddigital.org This message will only be sent once, since it is intended to be directed to the members of the Latin America Scientific Community. If it is not of your interest, please delete it. Thank you for your time and attention. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 10 18:44:09 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20093 for ; Fri, 10 Jan 2003 18:44:09 -0500 (EST) Received: (qmail 26978 invoked by uid 605); 10 Jan 2003 23:47:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26971 invoked from network); 10 Jan 2003 23:47:21 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 10 Jan 2003 23:47:21 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24634 for ; Fri, 10 Jan 2003 16:47:21 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ANlK5f008182 for ; Fri, 10 Jan 2003 18:47:20 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0ANlJjt010765 for ; Fri, 10 Jan 2003 18:47:20 -0500 (EST) Message-Id: <200301102347.h0ANlJjt010765@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: still need review of normative vs. non-normative reference split. In-Reply-To: Your message of "Thu, 21 Nov 2002 20:56:40 EST." Reply-to: sommerfeld@sun.com Date: Fri, 10 Jan 2003 18:47:19 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Nobody got back to me from this request: > Latest nit from the AD's on core documents: need to separate normative > and non-normative references, per http://www.rfc-editor.org/policy.html > > I'd appreciate it if a couple people could play "spot the > non-normative references" in the current drafts and share their > results with me and/or the WG. (I've done a quick look myself; the > vast majority are normative). > > There will be a document re-spin after this exercise. > > Thank you for your assistance. here's my take. Anyone disagree with the categorization? http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-01.txt: All references are normative. (FIPS-46-3 in this context is a "historic normative") http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt Non-normative: RFC854 (telnet) RFC894 (IP over Ethernet) RFC1134 (PPP) RFC1232 (rlogin) (the above are refereced as part of an analsis of relative protocol overhead.) All others are normative; note that I think RFC1766 has been superceded. nits: references from text are [RFC-NNN]; references section has [RFCNNN]. http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-16.txt All normative http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt Non-normative: [Orm96] (nit: typo in the reference) references rfc1766 (superceded) apparently unused: rfc2459 rfc1034 there are references to Applied Cryptography for several algorithms. http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-16.txt All normative. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 10 20:03:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21444 for ; Fri, 10 Jan 2003 20:03:12 -0500 (EST) Received: (qmail 28924 invoked by uid 605); 11 Jan 2003 01:06:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28917 invoked from network); 11 Jan 2003 01:06:26 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 11 Jan 2003 01:06:26 -0000 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09406 for ; Fri, 10 Jan 2003 18:06:25 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8I007X0Z2PSC@edgemail1.Central.Sun.COM> for ietf-ssh@netbsd.org; Fri, 10 Jan 2003 18:06:25 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8I00HXVZ2JUN@mail.sun.net> for ietf-ssh@netbsd.org; Fri, 10 Jan 2003 18:06:25 -0700 (MST) Date: Fri, 10 Jan 2003 17:00:44 -0800 From: Chris Newman Subject: Re: still need review of normative vs. non-normative reference split. In-reply-to: <200301102347.h0ANlJjt010765@thunk.east.sun.com> To: sommerfeld@Sun.COM, ietf-ssh@netbsd.org Message-id: <2147483647.1042218044@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.0 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <200301102347.h0ANlJjt010765@thunk.east.sun.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7BIT begin quotation by Bill Sommerfeld on 2003/1/10 18:47 -0500: > http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt > ... > All others are normative; note that I think RFC1766 has been > superceded. Yes, use RFC 3066 instead of RFC 1766. - Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 10 20:06:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21548 for ; Fri, 10 Jan 2003 20:06:12 -0500 (EST) Received: (qmail 446 invoked by uid 605); 11 Jan 2003 01:09:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 439 invoked from network); 11 Jan 2003 01:09:27 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 11 Jan 2003 01:09:27 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00419 for ; Fri, 10 Jan 2003 17:09:26 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0B19Omt007233; Fri, 10 Jan 2003 20:09:24 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0B19Ojt012057; Fri, 10 Jan 2003 20:09:24 -0500 (EST) Message-Id: <200301110109.h0B19Ojt012057@thunk.east.sun.com> From: Bill Sommerfeld To: Chris Newman Cc: ietf-ssh@netbsd.org Subject: Re: still need review of normative vs. non-normative reference split. In-Reply-To: Your message of "Fri, 10 Jan 2003 17:00:44 PST." <2147483647.1042218044@nifty-jr.west.sun.com> Reply-to: sommerfeld@Sun.COM Date: Fri, 10 Jan 2003 20:09:24 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Yes, use RFC 3066 instead of RFC 1766. Do you know if there are any significant over-the-wire differences between 3066 and 1766 ? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 10 20:17:05 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21881 for ; Fri, 10 Jan 2003 20:17:05 -0500 (EST) Received: (qmail 7245 invoked by uid 605); 11 Jan 2003 01:20:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7238 invoked from network); 11 Jan 2003 01:20:19 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 11 Jan 2003 01:20:19 -0000 Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07111 for ; Fri, 10 Jan 2003 18:20:19 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8I0076SZPUSC@edgemail1.Central.Sun.COM> for ietf-ssh@netbsd.org; Fri, 10 Jan 2003 18:20:19 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8I00HQEZPSUQ@mail.sun.net> for ietf-ssh@netbsd.org; Fri, 10 Jan 2003 18:20:18 -0700 (MST) Date: Fri, 10 Jan 2003 17:14:41 -0800 From: Chris Newman Subject: Re: still need review of normative vs. non-normative reference split. In-reply-to: <200301110109.h0B19Ojt012057@thunk.east.sun.com> To: sommerfeld@Sun.COM Cc: ietf-ssh@netbsd.org Message-id: <2147483647.1042218881@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.0 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <200301110109.h0B19Ojt012057@thunk.east.sun.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7BIT begin quotation by Bill Sommerfeld on 2003/1/10 20:09 -0500: >> Yes, use RFC 3066 instead of RFC 1766. > > Do you know if there are any significant over-the-wire differences > between 3066 and 1766 ? RFC 3066 permits digits in subtags, while 1766 doesn't. Otherwise the ABNF is unchanged. So I'd say the answer to your question is "no". - Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 10:14:34 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26781 for ; Tue, 14 Jan 2003 10:14:33 -0500 (EST) Received: (qmail 16654 invoked by uid 605); 14 Jan 2003 15:17:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16646 invoked from network); 14 Jan 2003 15:17:46 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 14 Jan 2003 15:17:46 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26727; Tue, 14 Jan 2003 10:14:13 -0500 (EST) Message-Id: <200301141514.KAA26727@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-dns-02.txt Date: Tue, 14 Jan 2003 10:14:13 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Using DNS to securely publish SSH key fingerprints Author(s) : J. Schlyter, W. Griffin Filename : draft-ietf-secsh-dns-02.txt Pages : 10 Date : 2003-1-13 This document describes a method to verify SSH host keys using DNSSEC. The document defines a new DNS resource record that contains a standard SSH key fingerprint. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-dns-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-dns-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-13142159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dns-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dns-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13142159.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 11:11:45 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00259 for ; Tue, 14 Jan 2003 11:11:45 -0500 (EST) Received: (qmail 17594 invoked by uid 605); 14 Jan 2003 16:15:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17587 invoked from network); 14 Jan 2003 16:15:01 -0000 Received: from web40301.mail.yahoo.com (66.218.78.80) by mail.netbsd.org with SMTP; 14 Jan 2003 16:15:01 -0000 Message-ID: <20030114161501.77207.qmail@web40301.mail.yahoo.com> Received: from [212.91.166.210] by web40301.mail.yahoo.com via HTTP; Tue, 14 Jan 2003 08:15:01 PST Date: Tue, 14 Jan 2003 08:15:01 -0800 (PST) From: Sombody Somewhere Subject: ssh channel window and adjustment To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi all, I have a simple question about ssh channel window and its adjustment. Maybe this is my mistake and I haven't found the right info about it and sorry if it is a lame question for you. I am interested in the following issues: 1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message consumes window size? 2. Is there a specific rule when to send SSH_MSG_CHANNEL_WINDOW_ADJUST and when not to send it ? 3. What must a peer do, when it has to send data but has no channel window ? Thank you very much in advance for you replies. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 11:48:26 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02901 for ; Tue, 14 Jan 2003 11:48:23 -0500 (EST) Received: (qmail 3685 invoked by uid 605); 14 Jan 2003 16:48:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2648 invoked from network); 14 Jan 2003 16:47:17 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 14 Jan 2003 16:47:17 -0000 Received: from tickit.tick-it.de (p50852A7B.dip0.t-ipconnect.de [80.133.42.123]) by narn.netbsd.org (Postfix) with ESMTP id 149C511165 for ; Tue, 14 Jan 2003 08:28:45 -0800 (PST) Received: from [192.168.1.102] ([192.168.1.102]) by tickit.tick-it.de (8.11.6/8.11.6) with ESMTP id h0EGmPG01231; Tue, 14 Jan 2003 17:48:25 +0100 Subject: Re: ssh channel window and adjustment From: Jon Bright To: Sombody Somewhere Cc: ietf-ssh@netbsd.org In-Reply-To: <20030114161501.77207.qmail@web40301.mail.yahoo.com> References: <20030114161501.77207.qmail@web40301.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 14 Jan 2003 17:40:01 +0100 Message-Id: <1042562403.24850.105.camel@prak> Mime-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2003-01-14 at 17:15, Sombody Somewhere wrote: > > 1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message > consumes window size? No. Unless I'm mistaken, the window size is the window for data sent in the 'data' field of the SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA messages *only* - i.e. no other fields and no other messages. > 2. Is there a specific rule when to send > SSH_MSG_CHANNEL_WINDOW_ADJUST and when > not > to send it ? No, this is implementation dependent. > 3. What must a peer do, when it has to send data but > has no channel window ? Buffer the data until the window is expanded. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 11:53:38 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03115 for ; Tue, 14 Jan 2003 11:53:38 -0500 (EST) Received: (qmail 10622 invoked by uid 605); 14 Jan 2003 16:56:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10615 invoked from network); 14 Jan 2003 16:56:54 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 14 Jan 2003 16:56:54 -0000 Received: from folly.informatik.uni-erlangen.de (root@localhost [127.0.0.1]) by faui02.informatik.uni-erlangen.de (8.12.6/8.12.6) with ESMTP id h0EGupgY023896; Tue, 14 Jan 2003 16:56:52 GMT Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id B728634081; Tue, 14 Jan 2003 17:56:30 +0100 (CET) Date: Tue, 14 Jan 2003 17:56:30 +0100 From: Markus Friedl To: Sombody Somewhere Cc: ietf-ssh@netbsd.org Subject: Re: ssh channel window and adjustment Message-ID: <20030114165630.GA6081@folly> References: <20030114161501.77207.qmail@web40301.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030114161501.77207.qmail@web40301.mail.yahoo.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 14, 2003 at 08:15:01AM -0800, Sombody Somewhere wrote: > Hi all, > > I have a simple question about ssh channel window and > its adjustment. Maybe this is my mistake and I haven't > found the right info about it and sorry if it is a > lame > question for you. I am interested in the following > issues: > > 1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message > consumes window size? no. only SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA consume window size. > 2. Is there a specific rule when to send > SSH_MSG_CHANNEL_WINDOW_ADJUST and when > not > to send it ? no. depends on how you want to do flow control. > 3. What must a peer do, when it has to send data but > has no channel window ? send data on other channels, if possible. buffer data received from other sources, if possible. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 12:00:30 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03261 for ; Tue, 14 Jan 2003 12:00:30 -0500 (EST) Received: (qmail 14822 invoked by uid 605); 14 Jan 2003 17:03:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14790 invoked from network); 14 Jan 2003 17:03:40 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 14 Jan 2003 17:03:40 -0000 Received: from tparelay.telradnetworks.co.il (unknown [62.90.58.229]) by narn.netbsd.org (Postfix) with ESMTP id F331D11173 for ; Tue, 14 Jan 2003 08:30:39 -0800 (PST) Received: from tparelay.telradnetworks.co.il (localhost [127.0.0.1]) by tparelay.telradnetworks.co.il (8.12.5/8.12.5) with ESMTP id h0EGSrwb020642 for ; Tue, 14 Jan 2003 18:28:53 +0200 (IST) Received: from tpa-mail1.Telrad.co.il ([141.226.76.57]) by tparelay.telradnetworks.co.il (8.12.5/8.12.5) with ESMTP id h0EGSrR7020639; Tue, 14 Jan 2003 18:28:53 +0200 (IST) Received: by tpa-mail1.Telrad.co.il with Internet Mail Service (5.5.2654.89) id ; Tue, 14 Jan 2003 18:29:23 +0200 Message-ID: From: Avraham Fraenkel - Commatch To: "'Sombody Somewhere'" , ietf-ssh@netbsd.org Subject: RE: ssh channel window and adjustment Date: Tue, 14 Jan 2003 18:29:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-8" Sender: ietf-ssh-owner@netbsd.org Precedence: list Hello Sombody, (1) From the implemntations I looked in , it looks like that the adjest is not consuming window , but I must agree that it is not wriiten in the draft. (2) No - I looked into two impelmentations and I found the following regarding server sending SSH_MSG_CHANNEL_WINDOW_ADJUST to the client: option (A): The openSSH implementation send it when the client had already sent more then half of the max_window the server can handle. The window is increased in the amount of data which already was sent to the shell. option (B) : The PuTTY implementation sent it when the amount of buffered data (buffer which is not sent yet to shell) is less then some constant. -- Avraham (mailto:avhf@alum.cs.huji.ac.il) -----Original Message----- From: Sombody Somewhere [mailto:koda_e@yahoo.com] Sent: Tuesday, January 14, 2003 6:15 PM To: ietf-ssh@netbsd.org Subject: ssh channel window and adjustment Hi all, I have a simple question about ssh channel window and its adjustment. Maybe this is my mistake and I haven't found the right info about it and sorry if it is a lame question for you. I am interested in the following issues: 1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message consumes window size? 2. Is there a specific rule when to send SSH_MSG_CHANNEL_WINDOW_ADJUST and when not to send it ? 3. What must a peer do, when it has to send data but has no channel window ? Thank you very much in advance for you replies. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 12:23:01 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03969 for ; Tue, 14 Jan 2003 12:23:01 -0500 (EST) Received: (qmail 28384 invoked by uid 605); 14 Jan 2003 17:26:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28377 invoked from network); 14 Jan 2003 17:26:17 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 14 Jan 2003 17:26:17 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18YUp7-0006R6-00; Tue, 14 Jan 2003 17:26:01 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20030114161501.77207.qmail@web40301.mail.yahoo.com> Subject: Re: ssh channel window and adjustment Message-Id: Date: Tue, 14 Jan 2003 17:26:01 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Sombody Somewhere wrote: > 3. What must a peer do, when it has to send data but > has no channel window ? There have been other good answers to your other questions, so I won't spend time repeating them, but I haven't yet seen anyone say what I want to say in response to this one. If you have data to send on a channel but there's no window left on that channel, then (as other people have said) your only option at the SSH end is to sit on your buffered data and hope you get a window adjust at some point in the future. Meanwhile you can still send on _other_ SSH channels, and open new channels, and keep doing everything else. But the really important thing you probably want to do if you don't have any window on a particular channel is to _stop accepting data_ from wherever your source is. For example, if the channel is a forwarded port, this would be a good moment to stop reading data from the relevant local network connection. That way, delays propagate all the way down the pipeline: if the app at the server end stops reading data, then the SSH server stops increasing the window size, and when your client runs out of window it stops reading data from the local connection, so eventually the app at the client end sits there blocking and trying to send data - which is exactly what it _would_ be doing if there wasn't an SSH connection and a port forwarding in the way. To put it another way, you're arranging that the total amount of data which can be buffered between the ultimate endpoints of the connection is _limited_ - so if the receiver stops receiving, the buffers will all fill up and eventually the sender will notice. If you don't do this, your SSH implementation will continue reading data and buffering it, and will gradually inflate to a ridiculous size and run out of memory. Cheers, Simon -- Simon Tatham "infinite loop _see_ loop, infinite" - Index, Borland Pascal Language Guide From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 14 12:56:44 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04907 for ; Tue, 14 Jan 2003 12:56:43 -0500 (EST) Received: (qmail 16878 invoked by uid 605); 14 Jan 2003 18:00:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16871 invoked from network); 14 Jan 2003 18:00:00 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 14 Jan 2003 18:00:00 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28201; Tue, 14 Jan 2003 09:59:55 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0EHxtmt029656; Tue, 14 Jan 2003 12:59:55 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0EHxsjt004908; Tue, 14 Jan 2003 12:59:54 -0500 (EST) Message-Id: <200301141759.h0EHxsjt004908@thunk.east.sun.com> From: Bill Sommerfeld To: Jon Bright cc: Sombody Somewhere , ietf-ssh@netbsd.org Subject: Re: ssh channel window and adjustment In-Reply-To: Your message of "14 Jan 2003 17:40:01 +0100." <1042562403.24850.105.camel@prak> Reply-to: sommerfeld@east.sun.com Date: Tue, 14 Jan 2003 12:59:54 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [Note: WG chair hat off for the following] > > 3. What must a peer do, when it has to send data but > > has no channel window ? > > Buffer the data until the window is expanded. Alternatively, provide some sort of flow-control back-pressure to slow down the source of the channel.. For instance, if the data for the outbound direction of a channel comes in on a reliable byte stream IPC channel of some sort [1], and you run out of window on that channel, stop reading from the data source. The OS will provide buffering and/or back pressure to the other end of that channel; when the channel's window reopens, you can start reading that channel again.. - Bill [1] on unix: pipes, SOCK_STREAM sockets, etc., From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 16 17:11:33 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25225 for ; Thu, 16 Jan 2003 17:11:32 -0500 (EST) Received: (qmail 22729 invoked by uid 605); 16 Jan 2003 22:14:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22722 invoked from network); 16 Jan 2003 22:14:51 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 16 Jan 2003 22:14:51 -0000 Received: from BLUETAIL (inago.swcp.com [198.59.115.17]) by taka.swcp.com (8.12.3/8.12.3) with SMTP id h0GMEmAh056030 for ; Thu, 16 Jan 2003 15:14:49 -0700 (MST) Message-ID: <00a401c2bdab$f2d0c260$4900a8c0@BLUETAIL> From: "Brent McClure" To: References: <200301102347.h0ANlJjt010765@thunk.east.sun.com> Subject: Re: still need review of normative vs. non-normative reference split. Date: Thu, 16 Jan 2003 15:09:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-0.1 required=10.0 tests=REFERENCES Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Bill, I'm working through the drafts a couple at a time. My comments on the first couple drafts are below. --Brent > here's my take. Anyone disagree with the categorization? > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-01.txt: > > All references are normative. (FIPS-46-3 in this context is a > "historic normative") I Agree. > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt > > Non-normative: > RFC854 (telnet) > RFC894 (IP over Ethernet) > RFC1134 (PPP) > RFC1232 (rlogin) > (the above are refereced as part of an analsis of > relative protocol overhead.) > > All others are normative; note that I think RFC1766 has been > superceded. > > nits: references from text are [RFC-NNN]; references section > has [RFCNNN]. Agree. With some possible exceptions: I wonder if RFC-1750 (Randomness recommendations for security) might be listed as informative. Obviously randomness is something that is important for implementors to pay attention to, but it still seems like it might be considered "background" (or "very important background"). I guess what I'm basing this one could implement the protocol using a very poor stream of random data and it would still "work". Also, it seems like RFC2434 (IANA considerations in RFCS) seems like it could be listed as informative rather than normative. It is referred to as policy for allowing DNS domain owners to introduce names like name@mydomain.org to secsh. Since it is referred to as policy rather than "technology that must be understood...", then it might be considered informative. --- nit: SSH-ARCH refers to [RFC-2343] in the body, but I believe is ^^^^^^^^^ supposed to be RFC2434. I'll look over the remaining drafts soon. thanks, Brent bdm@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 16 19:06:37 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27075 for ; Thu, 16 Jan 2003 19:06:37 -0500 (EST) Received: (qmail 27988 invoked by uid 605); 17 Jan 2003 00:09:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27981 invoked from network); 17 Jan 2003 00:09:55 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 17 Jan 2003 00:09:55 -0000 Received: from BLUETAIL (inago.swcp.com [198.59.115.17]) by taka.swcp.com (8.12.3/8.12.3) with SMTP id h0H09qAh046648 for ; Thu, 16 Jan 2003 17:09:53 -0700 (MST) Message-ID: <002001c2bdbc$05dd3680$4900a8c0@BLUETAIL> From: "Brent McClure" To: References: <200301102347.h0ANlJjt010765@thunk.east.sun.com> Subject: Re: still need review of normative vs. non-normative reference split. Date: Thu, 16 Jan 2003 17:04:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-0.1 required=10.0 tests=REFERENCES Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-16.txt > > All normative I wonder if [POSIX] could really be categorized as informative. While POSIX was the source of the secsh list of signals, the fact that they came from there doesn't seem to require one to go read POSIX to implement. Here is the relevant text in SSH-CONN: ... The signal name is one of the following (these are from [POSIX]) ABRT ALRM FPE HUP ... I read SSH-TRANS and SSH-USERAUTH and the only non-normative ref I found was [Orm96] that you already identified. thanks, Brent bdm@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 16 19:25:37 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27460 for ; Thu, 16 Jan 2003 19:25:37 -0500 (EST) Received: (qmail 9198 invoked by uid 605); 17 Jan 2003 00:28:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9191 invoked from network); 17 Jan 2003 00:28:55 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Jan 2003 00:28:55 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00729; Thu, 16 Jan 2003 16:28:46 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0H0Sj4t003505; Thu, 16 Jan 2003 19:28:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0H0Sjjt028116; Thu, 16 Jan 2003 19:28:45 -0500 (EST) Message-Id: <200301170028.h0H0Sjjt028116@thunk.east.sun.com> From: Bill Sommerfeld To: "Brent McClure" cc: ietf-ssh@netbsd.org Subject: Re: still need review of normative vs. non-normative reference split. In-Reply-To: Your message of "Thu, 16 Jan 2003 15:09:32 MST." <00a401c2bdab$f2d0c260$4900a8c0@BLUETAIL> Reply-to: sommerfeld@east.sun.com Date: Thu, 16 Jan 2003 19:28:45 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [wg chair hat on..] the normative/non-normative reference split is a new requirement which started being imposed after the core documents were first submitted to the IESG. this is an evolving requirement and exactly how it's being handled is still a bit fuzzy at the moment.. My understanding right now is that the current cited reason to not mark a reference "normative" is to avoid publication delays when you have non-normative references to unpublished internet-drafts. Since all the references in the core drafts are either within-the-hairball or to published documents, this is largely a non-issue for us. [wg chair hat off for the following.] > I wonder if RFC-1750 (Randomness recommendations for security) might > be listed as informative. Obviously randomness is something that is > important for implementors to pay attention to, but it still seems > like it might be considered "background" (or "very important > background"). so, if we go by the "must read this in order to implement" interpretation of normative, I think we're safer off declaring this as normative. > I guess what I'm basing this one could implement the protocol using > a very poor stream of random data and it would still "work". while such an implementation would interoperate, it would emphatically not provide meaningful security. > Also, it seems like RFC2434 (IANA considerations in RFCS) seems > like it could be listed as informative rather than normative. > It is referred to as policy for allowing DNS domain owners > to introduce names like name@mydomain.org to secsh. Since it is > referred to as policy rather than "technology that must be > understood...", then it might be considered informative. On the other hand, it's normative for the process to follow when implementing private extensions.. > I wonder if [POSIX] could really be categorized as informative. > While POSIX was the source of the secsh list of signals, the fact > that they came from there doesn't seem to require one to go > read POSIX to implement. Here is the relevant text in SSH-CONN: ... The signal name is one of the following (these are from [POSIX]) so, my take is that you need to read [POSIX] to understand what a "signal" is and how to map your local OS's equivalent into the over-the-wire protocol message. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 16 19:36:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27796 for ; Thu, 16 Jan 2003 19:36:10 -0500 (EST) Received: (qmail 13773 invoked by uid 605); 17 Jan 2003 00:39:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13766 invoked from network); 17 Jan 2003 00:39:29 -0000 Received: from halt-in.cisco.com (171.70.144.185) by mail.netbsd.org with SMTP; 17 Jan 2003 00:39:29 -0000 Received: from cisco.com (171.70.157.157) by halt-in.cisco.com with ESMTP; 16 Jan 2003 16:39:29 +0000 Received: from cisco.com (dhcp-171-71-137-108.cisco.com [171.71.137.108]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA11808 for ; Thu, 16 Jan 2003 16:39:28 -0800 (PST) Message-ID: <3E275081.5030406@cisco.com> Date: Thu, 16 Jan 2003 16:38:25 -0800 From: Yong Ni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: scp/sftp using IPv6 address, any ambiguity? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hi, For scp and sftp (used in the command line mode), we provide the src/dst path in the form of [[user@]host[#port]:]file_or_dir In case of IPv6 address, the host itself could contain multiple ":". How do we solve the ambiguity here? The problem is worsen when the filename containing ":" is allowed in some file system. For example: guest@FFF1::FFFF2:FFF3:FFF4 Can you tell which part is what? I was under the impression people uses "[]" to group ipv6 address. However, is there a document somewhere about this? thanks, Yong From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 16 19:39:50 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27830 for ; Thu, 16 Jan 2003 19:39:49 -0500 (EST) Received: (qmail 15975 invoked by uid 605); 17 Jan 2003 00:43:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15968 invoked from network); 17 Jan 2003 00:43:09 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 17 Jan 2003 00:43:09 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12125; Thu, 16 Jan 2003 16:43:08 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.7+Sun/8.12.7) with ESMTP id h0H0h8L6243704; Thu, 16 Jan 2003 16:43:08 -0800 (PST) Date: Thu, 16 Jan 2003 16:43:07 -0800 (PST) From: Darren J Moffat To: Yong Ni cc: ietf-ssh@netbsd.org Subject: Re: scp/sftp using IPv6 address, any ambiguity? In-Reply-To: <3E275081.5030406@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 16 Jan 2003, Yong Ni wrote: > For scp and sftp (used in the command line mode), we provide the src/dst > path in the form of > [[user@]host[#port]:]file_or_dir > > In case of IPv6 address, the host itself could contain multiple ":". > How do we solve the ambiguity here? The problem is worsen when the > filename containing ":" is allowed in some file system. For example: > guest@FFF1::FFFF2:FFF3:FFF4 > Can you tell which part is what? I was under the impression people uses > "[]" to group ipv6 address. However, is there a document somewhere > about this? What you are describing is a user interface issue for a particular implementation of the protocol. The protocol is written in such a way that it is obvious when "data" is a file, a file separator and a host address. I believe you should take this issue up with the group that designed the user interface for the program you are using. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 16 19:45:29 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27894 for ; Thu, 16 Jan 2003 19:45:29 -0500 (EST) Received: (qmail 20232 invoked by uid 605); 17 Jan 2003 00:48:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20225 invoked from network); 17 Jan 2003 00:48:47 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Jan 2003 00:48:47 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15474; Thu, 16 Jan 2003 17:48:45 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0H0mj5f004913; Thu, 16 Jan 2003 19:48:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0H0mijt028309; Thu, 16 Jan 2003 19:48:44 -0500 (EST) Message-Id: <200301170048.h0H0mijt028309@thunk.east.sun.com> From: Bill Sommerfeld To: Yong Ni cc: ietf-ssh@netbsd.org Subject: Re: scp/sftp using IPv6 address, any ambiguity? In-Reply-To: Your message of "Thu, 16 Jan 2003 16:38:25 PST." <3E275081.5030406@cisco.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 16 Jan 2003 19:48:44 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list As Darren said this is a local issue for ssh; It's an on-the-wire issue for other protocols (http/html), and has been "fixed" as described in RFC2732. It would certainly be appropriate for an ssh implementation to follow suit. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 17 10:09:54 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25157 for ; Fri, 17 Jan 2003 10:09:53 -0500 (EST) Received: (qmail 27926 invoked by uid 605); 17 Jan 2003 15:13:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27919 invoked from network); 17 Jan 2003 15:13:11 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 17 Jan 2003 15:13:11 -0000 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 183FC67111; Fri, 17 Jan 2003 10:19:19 -0500 (EST) Date: Fri, 17 Jan 2003 10:12:46 -0500 Subject: Re: still need review of normative vs. non-normative reference split. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Brent McClure" From: RJ Atkinson In-Reply-To: <00a401c2bdab$f2d0c260$4900a8c0@BLUETAIL> Message-Id: <22406F3C-2A2E-11D7-A6D5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, Jan 16, 2003, at 17:09 America/Montreal, Brent McClure wrote: > Agree. With some possible exceptions: > > I wonder if RFC-1750 (Randomness recommendations for security) > might be listed as informative. It is normative. An implementation that doesn't follow those recommendations can't be secure. > Also, it seems like RFC2434 (IANA considerations in RFCS) seems > like it could be listed as informative rather than normative. No. It is normative because we are obliged to follow that RFC in our IANA considerations. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 17 11:59:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28643 for ; Fri, 17 Jan 2003 11:59:02 -0500 (EST) Received: (qmail 12247 invoked by uid 605); 17 Jan 2003 17:01:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11845 invoked from network); 17 Jan 2003 17:01:47 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 17 Jan 2003 17:01:47 -0000 Received: from BLUETAIL (inago.swcp.com [198.59.115.17]) by taka.swcp.com (8.12.3/8.12.3) with SMTP id h0HH1jxB025859 for ; Fri, 17 Jan 2003 10:01:45 -0700 (MST) Message-ID: <006b01c2be49$601871e0$4900a8c0@BLUETAIL> From: "Brent McClure" To: References: <200301170028.h0H0Sjjt028116@thunk.east.sun.com> Subject: Re: still need review of normative vs. non-normative reference split. Date: Fri, 17 Jan 2003 09:56:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-0.1 required=10.0 tests=REFERENCES Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bill Sommerfeld" To: "Brent McClure" Cc: Sent: Thursday, January 16, 2003 5:28 PM Subject: Re: still need review of normative vs. non-normative reference split. > [wg chair hat on..] > > the normative/non-normative reference split is a new requirement which > started being imposed after the core documents were first submitted to > the IESG. this is an evolving requirement and exactly how it's being > handled is still a bit fuzzy at the moment.. > > My understanding right now is that the current cited reason to not > mark a reference "normative" is to avoid publication delays when you > have non-normative references to unpublished internet-drafts. > > Since all the references in the core drafts are either > within-the-hairball or to published documents, this is largely a > non-issue for us. > > [wg chair hat off for the following.] > > > I wonder if RFC-1750 (Randomness recommendations for security) might > > be listed as informative. Obviously randomness is something that is > > important for implementors to pay attention to, but it still seems > > like it might be considered "background" (or "very important > > background"). > > so, if we go by the "must read this in order to implement" > interpretation of normative, I think we're safer off declaring this as > normative. > > > I guess what I'm basing this one could implement the protocol using > > a very poor stream of random data and it would still "work". > > while such an implementation would interoperate, it would emphatically > not provide meaningful security. I guess "interoperable" was the perspective was taking. One could never have read 1750 and still write an interoperable implementation, so technically one might categorize it as informative. I didn't feel that doing this necessarily gives a green light to poor implementations. Especially since the text of SSH-ARCH makes it clear how important randomness is. If making it normative helps emphasize it's importance, I'm happy to see it stay that say. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 20 17:28:49 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02970 for ; Mon, 20 Jan 2003 17:28:49 -0500 (EST) Received: (qmail 10524 invoked by uid 605); 20 Jan 2003 22:31:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10230 invoked from network); 20 Jan 2003 22:30:46 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 20 Jan 2003 22:30:46 -0000 Received: from hqmail01.ellacoya.com (unknown [64.223.136.41]) by narn.netbsd.org (Postfix) with ESMTP id 6348C11153 for ; Mon, 20 Jan 2003 14:07:03 -0800 (PST) Received: by hqmail01.ellacoya.com with Internet Mail Service (5.5.2656.59) id ; Mon, 20 Jan 2003 17:06:54 -0500 Message-ID: From: "Amedeo, David" To: "'ietf-ssh@netbsd.org'" Subject: Question Date: Mon, 20 Jan 2003 17:06:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list How do I disable the ability for the root user to login to a Solaris server using your ssh product? Thanks ******************** David Amedeo Network Engineer Ellacoya Networks, Inc. 7 Henry Clay Drive Merrimack, NH 03054 Phone (603) 879-7341 Mobile (603) 315-1095 Fax (603) 577-5533 ******************** From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 21 18:16:36 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14884 for ; Tue, 21 Jan 2003 18:16:35 -0500 (EST) Received: (qmail 19386 invoked by uid 605); 21 Jan 2003 23:19:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19379 invoked from network); 21 Jan 2003 23:19:56 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 21 Jan 2003 23:19:56 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27847; Tue, 21 Jan 2003 16:19:46 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0LNJj4t026348; Tue, 21 Jan 2003 18:19:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0LNJjjt029968; Tue, 21 Jan 2003 18:19:45 -0500 (EST) Message-Id: <200301212319.h0LNJjjt029968@thunk.east.sun.com> From: Bill Sommerfeld To: "Amedeo, David" cc: "'ietf-ssh@netbsd.org'" Subject: Re: Question In-Reply-To: Your message of "Mon, 20 Jan 2003 17:06:53 EST." Reply-to: sommerfeld@east.sun.com Date: Tue, 21 Jan 2003 18:19:45 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > How do I disable the ability for the root user to login to a Solaris server > using your ssh product? You've reached the IETF secure shell working group. This isn't the group you're looking for. Our "product" is the protocol specification, not any particular implementation of the protocol. That said, I'll give a stab at the answer: Several ssh server implementations have a PermitRootLogin configuration parameter in the server's config file. This parameter is usually documented in the man page for that config file. - Bill IETF Secure Shell WG chair. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 22 07:16:48 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22571 for ; Wed, 22 Jan 2003 07:16:47 -0500 (EST) Received: (qmail 16017 invoked by uid 605); 22 Jan 2003 12:20:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16010 invoked from network); 22 Jan 2003 12:20:08 -0000 Received: from web40310.mail.yahoo.com (66.218.78.89) by mail.netbsd.org with SMTP; 22 Jan 2003 12:20:08 -0000 Message-ID: <20030122122008.30280.qmail@web40310.mail.yahoo.com> Received: from [212.91.166.210] by web40310.mail.yahoo.com via HTTP; Wed, 22 Jan 2003 04:20:08 PST Date: Wed, 22 Jan 2003 04:20:08 -0800 (PST) From: Sombody Somewhere Subject: Re: ssh channel window and adjustment To: ietf-ssh@netbsd.org In-Reply-To: <200301141759.h0EHxsjt004908@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi all! Thank you for your replies. Basicly your opinions confirmed my theory about the implementations and standards ;). Recently I investigated the OpenSSH client behaviour. It seems to me that OpenSSH client sends SSH_MSG_CHANNEL_WINDOW_ADJUST, when it writes more than the half of its own channel window size(the initial channel window size it is sending to its peer,when opening new channel). I think that this behaviuor may be quite incorrect. Here is an example of such situation: let's say the user using OpenSSH client sends commands to th SSH server and if we suppose these commands have big console output, then OpenSSH client's channel window may be filled much faster than the server's channel window space,but the server is obliged no to write its output untill the client sends it adjust message. This way the server is obliged to allocate great amount of data and keep it allocated untill the the amount of data written by the client exceeds the half of its own channel. Just then the server will recieve adjust. In my opinion the adjust message sneding has to be dependent on amount of data read not written. I would appreciate any comments on my opinion and thank you again for your attention :) P.S. I am afraid that this posting maybe treated as out of topic but I think that people developing the OpenSSH are reading this mail list and also I think that if my opinion is generally wrong(having in mind the drafts) this is the place to be corrected ;) __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 22 08:08:36 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23788 for ; Wed, 22 Jan 2003 08:08:35 -0500 (EST) Received: (qmail 12561 invoked by uid 605); 22 Jan 2003 13:11:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12553 invoked from network); 22 Jan 2003 13:11:57 -0000 Received: from p5085280a.dip0.t-ipconnect.de (HELO tickit.tick-it.de) (80.133.40.10) by mail.netbsd.org with SMTP; 22 Jan 2003 13:11:57 -0000 Received: from [192.168.1.102] ([192.168.1.102]) by tickit.tick-it.de (8.11.6/8.11.6) with ESMTP id h0MDYUG14283; Wed, 22 Jan 2003 14:34:31 +0100 Subject: Re: ssh channel window and adjustment From: Jon Bright To: Sombody Somewhere Cc: ietf-ssh@netbsd.org In-Reply-To: <20030122122008.30280.qmail@web40310.mail.yahoo.com> References: <20030122122008.30280.qmail@web40310.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 22 Jan 2003 14:25:58 +0100 Message-Id: <1043241959.13221.6.camel@prak> Mime-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2003-01-22 at 13:20, Sombody Somewhere wrote: > > It seems to me that OpenSSH client sends > SSH_MSG_CHANNEL_WINDOW_ADJUST, when it writes more > than the half of its own channel window size(the No, this isn't correct. It sends it (afair, I don't have time to check the code) when the remaining space in the incoming channel window is less than half the maximum space in the incoming channel window. > server is obliged no to write its output untill the > client sends it adjust message. This way the server is > obliged to allocate great amount of data and keep it At no point is the server obliged to allocate lots of memory - it can just stop accepting more data from whatever's generating the data. So if 'ls -lR' is generating the console output, the sshd stops accepting the output from 'ls -lR', which in turn sleeps. When the client sends an adjust message, the server sends more data until the window's again full. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 22 08:31:25 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24485 for ; Wed, 22 Jan 2003 08:31:24 -0500 (EST) Received: (qmail 22935 invoked by uid 605); 22 Jan 2003 13:34:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22913 invoked from network); 22 Jan 2003 13:34:47 -0000 Received: from web40304.mail.yahoo.com (66.218.78.83) by mail.netbsd.org with SMTP; 22 Jan 2003 13:34:47 -0000 Message-ID: <20030122133447.22642.qmail@web40304.mail.yahoo.com> Received: from [212.91.166.210] by web40304.mail.yahoo.com via HTTP; Wed, 22 Jan 2003 05:34:47 PST Date: Wed, 22 Jan 2003 05:34:47 -0800 (PST) From: Sombody Somewhere Subject: Re: ssh channel window and adjustment To: Jon Bright Cc: ietf-ssh@netbsd.org, openssh-unix-dev@mindrot.org In-Reply-To: <1043241959.13221.6.camel@prak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Jon! I checked the code and I saw that I made a mistake - sorry for the wrong post :( Thank you very much for the reply! __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 24 22:27:19 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08779 for ; Fri, 24 Jan 2003 22:27:19 -0500 (EST) Received: (qmail 2011 invoked by uid 605); 25 Jan 2003 03:30:44 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 25 Jan 2003 03:30:44 -0000 Message-ID: <20030125033044.2010.qmail@mail.netbsd.org> Received: (qmail 1996 invoked from network); 25 Jan 2003 03:30:42 -0000 Received: from 200-158-174-115.dsl.telesp.net.br (HELO parperfeito.com.br) (200.158.174.115) by mail.netbsd.org with SMTP; 25 Jan 2003 03:30:42 -0000 From: "Virtualserv" To: hospedagem@profissional.net Subject: Hospedagem profissional de domínios e sites Content-Transfer-Encoding: Quoted-Printable MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: Quoted-Printable HOSPEDAGEM PROFISSIONAL DE DOMÍNIOS E SITES A VirtualServ oferece o mais completo plano de hospedagem profissional do mercado. Todas as possibilidades disponíveis hoje na WEB num só plano. O melhor servidor, a melhor conexão, o melhor suporte e recursos ilimitados. Nosso serviço é top de linha entre os melhores servidores e temos como objetivo a sua satisfação e confiança. Visite-nos: http://virtualserv.com _________________________________________ PAINEL DE CONTROLE - CPANEL O painel de controle oferecido pela VirtualServ simplifica todos os comandos Unix em uma interface gráfica intuitiva e fácil de usar, agilizando a manutenção de sua conta. Disponibilizamos essa ferramenta para todos os clientes. _________________________________________ LOJA VIRTUAL GRÁTIS Adquirindo o plano de hospedagem profissional da VirtualServ, você ganha uma Loja virtual Grátis totalmente automatizada e com e-commerce*. Você pode oferecer qualquer produto ou serviço que quiser com divulgação permanente na internet. Você também pode modificá-la de acordo com suas necessidades. Na loja, você pode receber pelos seus produtos ou serviços através de depósito bancário, boleto ou cartão de crédito. _________________________________________ Plano profissional de hospedagem com recursos ilimitados VirtualServ Valor Mensal - R$ 21,00 Taxa única de Setup - R$: 15,00 Espaço em Disco 100 MB (ampliável) Transferência Mensal 2 GB Contas de E-mail POP3 personalizadas com anti-vírus - ilimitadas Subdomínios - ilimitados Redirecionamento de domínios - ilimitados Contas de FTP individuais - ilimitadas Bancos de Dados MY SQL 3.45 - ilimitados Painel de Controle CPANEL - Sim Diretório CGI-BIN - Sim Estatísticas Completas - Sim Loja Virtual GRÁTIS - Sim ASP e tarefas CRON - Sim Suporte Técnico - Sim Software para e-commerce - Sim Divulgação permanente na internet - Sim ________________________________ Não perca tempo, entre hoje mesmo para a VirtualServ e obtenha o serviço mais completo do mercado ! Visite nosso site: http://www.virtualserv.com Suporte online: suporte@virtualserv.com - Fones: (11)6567-3684 ou (11)9443-4276 - h/c - ICQ-141826334 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 28 22:11:41 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15015 for ; Tue, 28 Jan 2003 22:11:40 -0500 (EST) Received: (qmail 21031 invoked by uid 605); 29 Jan 2003 03:15:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21024 invoked from network); 29 Jan 2003 03:15:06 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 29 Jan 2003 03:15:06 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07989 for ; Tue, 28 Jan 2003 19:15:06 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0T3F54t020139 for ; Tue, 28 Jan 2003 22:15:05 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id h0T3F4jt001508 for ; Tue, 28 Jan 2003 22:15:05 -0500 (EST) Message-Id: <200301290315.h0T3F4jt001508@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: secure shell core draft status update Reply-to: sommerfeld@east.sun.com Date: Tue, 28 Jan 2003 22:15:04 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, I just got an update .. Current holdup is that an IESG member believes that the security considerations section is inadequate. I haven't seen specifics yet. I've been promised that the IESG will deliver us an acceptable-to-them security considerations section (but, alas, no ETA on when it will appear). Send whines to me, I'll pass them upstream. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 29 09:43:56 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20503 for ; Wed, 29 Jan 2003 09:43:55 -0500 (EST) Received: (qmail 374 invoked by uid 605); 29 Jan 2003 14:47:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 366 invoked from network); 29 Jan 2003 14:47:20 -0000 Received: from pd180.radomsko.sdi.tpnet.pl (HELO express.toh.info) (217.96.202.180) by mail.netbsd.org with SMTP; 29 Jan 2003 14:47:20 -0000 Received: from Cyberia1 (unknown [192.168.0.2]) by express.toh.info (Postfix) with ESMTP id EC012246FB for ; Wed, 29 Jan 2003 15:50:35 +0100 (CET) From: "Express" Subject: Wspolpraca To: ietf-ssh@netbsd.org Date: Tue, 11 Jan 2028 15:46:54 +0100 X-Priority: 3 X-Library: Indy 9.00.10 Message-Id: <20030129145035.EC012246FB@express.toh.info> Sender: ietf-ssh-owner@netbsd.org Precedence: list Najtansza i skuteczna reklama Twojej firmy. BAZA ADRESOW E-MAIL polskich firm i przedsiebiorstw, zawierajaca 60000 lub 100000 adresow e-mail. Masowa wysylka ofert jest jedna z najtanszych, najskuteczniejszych i najszybciej dzialajacych form reklamy. Dzieki bazie adresow e-mail Panstwa oferta handlowa dotrze do kilkudziesieciu tysiecy polskich firm w ciagu kilku godzin. Wysylke ofert ulatwi Panstwu program ExpressMail - naszego autorstwa, dolaczany gratis do kazdej zakupionej przez Panstwa bazy adresow. Baze adresow e-mail mozecie Panstwo nabyc w cenie promocyjnej : -Baza 60000 adresow - 299 pln/NETTO -Baza 100000 adresow - 399 pln/NETTO * Ceny promocyjne obowiazuja do dn. 10.02.2003r. wiecej informacji na stronie http://www.acid.pl Zamowienia i info - biuro@acid.pl lub telefonicznie tel/fax. 0(prefix)44 683 44 03 w godz. od 15-18. --------------------------------------------- Informujemy , ze Panstwa adres , na ktory zostala wyslana ta wiadomosc nie znajduje sie w naszej bazie adresowej i sluzyl jednorazowemu wyslaniu oferty.