Re: [Int-area] Suggestion to move draft-olteanu-intarea-socks as Independent Submissions
'Toerless Eckert' <tte@cs.fau.de> Mon, 01 March 2021 16:14 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6193A1EEC for <int-area@ietfa.amsl.com>; Mon, 1 Mar 2021 08:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4fVHnirmqKz for <int-area@ietfa.amsl.com>; Mon, 1 Mar 2021 08:14:51 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237E43A1EEA for <int-area@ietf.org>; Mon, 1 Mar 2021 08:14:51 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 36C9C54804B; Mon, 1 Mar 2021 17:14:46 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2E430440166; Mon, 1 Mar 2021 17:14:46 +0100 (CET)
Date: Mon, 01 Mar 2021 17:14:46 +0100
From: 'Toerless Eckert' <tte@cs.fau.de>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "'Eric Vyncke (evyncke)'" <evyncke=40cisco.com@dmarc.ietf.org>, sarikaya@ieee.org, int-area@ietf.org, dragos.niculescu@cs.pub.ro, rfc-ise@rfc-editor.org
Message-ID: <20210301161446.GC11539@faui48f.informatik.uni-erlangen.de>
References: <A83C9114-FC48-4BB9-8B3A-55A877C9232B@cisco.com> <CAC8QAce45tXvz7sMQjaL85-=KQk1BNV+LOXmGf3ohdmOA8vxaw@mail.gmail.com> <70242F40-BB96-4562-A758-85CF6C0CBD96@cisco.com> <004501d6eb6d$9334c500$b99e4f00$@olddog.co.uk> <20210301151814.GA11539@faui48f.informatik.uni-erlangen.de> <053801d70eb2$35eb0040$a1c100c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <053801d70eb2$35eb0040$a1c100c0$@olddog.co.uk>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/uH2wAnAej2pCmbgQg4QaoXrtcwY>
Subject: Re: [Int-area] Suggestion to move draft-olteanu-intarea-socks as Independent Submissions
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 16:14:53 -0000
Thanks, Adrian Looking back at a lot of (multicast) RFCs that started as experimental i guess i had tied the meaning of the word too much to "blessed by IETF for further adoption", but it makes a lot of sense to apply it also to other (non IETF blessed/validated) experiments. Just never thought of it that way. Although: In that case though, i would love to see even more documentation of environmental aspects such as implementation information. Sure, removing implementation and any other process-how-we-got-here sections from RFC is fine. The only gotcha i observed when just moving a draft into the RFC editor queue was that my AD (also here on the thread ;-) felt that it was not even appropriate to leave in the RFC a breadcrumb sentence pointing to the existance of (outdated or not) additional information in the last draft. I think such a breadcrub sentence would be a perfect way to justify the effort to invest cycles into good tracking of process data during the development. And reduce the amount of pain having to go back and sift such info oout of mailing list archives (if it's there at all). Cheers Toerless On Mon, Mar 01, 2021 at 03:47:38PM -0000, Adrian Farrel wrote: > Hi Toerless, > > >> Just to re-assert that the Independent Submissions Stream can publish > Informational > >> and Experimental RFCs. > > > > Just if its approriate to ask on a list where i could probably wade > through rfcs to find > > the answer: Whats the relevance/differentiation of "experimental" for > independent > > stream ? > > That's a question for the ISE, I think. > The answer is that the definition of the RFC categories is immutable across > the various RFC streams. > The difference is that "Informational" provides information, while > "Experimental" describes an on-going experiment (not usually an experiment > that has already completed). > The Independent Stream can only publish Informational, Experimental, and > Historic RFCs. > > > Other than that: > > I leave the other questions to the discussion among the authors, but you > might find RFC 7942 useful and note that it recommends removing reports of > implementation status from RFCs before publication because the information > rarely retains currency (wiki pages, OTOH, can be helpful). > > Cheers, > Adrian > > > - Is there anywhere information about the available SOCK implementations > sufficiently > > detailed to understand their ability and use-case benefits to > interoperate (between > > client SDK/shim-library and server ? > > > >- For those existing or planned future implementations, is it possible to > collect insight > > into how eager the implementers would be to adopt the draft proposed > functionality ? > > > >- For any implementer/implementations showing interest in adoption, where > their > > names collected ? > > > > If this did all happen in some discussions on int-area, i would still > prefer to see this > > salient information collected in a document. Even if it might not be this > draft, but an -ops > > draft, but especially when this goes ISE, it should be much less a problem > to have > > actual dadoption relevant information in a doc as opposed to jus the bare > protocol details. > > > > Even if his is built on the push model of "standardize it and they > (implementers) will come", > > it would (at last for me) still be highly useful to see a list of > implementations, and whether > > or not the authors of this document reached out to the implemenations to > query about the > > interest in this 'extension/version'. -- --- tte@cs.fau.de
- [Int-area] Suggestion to move draft-olteanu-intar… Eric Vyncke (evyncke)
- Re: [Int-area] Suggestion to move draft-olteanu-i… Behcet Sarikaya
- Re: [Int-area] Suggestion to move draft-olteanu-i… Eric Vyncke (evyncke)
- Re: [Int-area] Suggestion to move draft-olteanu-i… Vladimir Olteanu
- Re: [Int-area] Suggestion to move draft-olteanu-i… Joseph Touch
- Re: [Int-area] Suggestion to move draft-olteanu-i… Adrian Farrel
- Re: [Int-area] Suggestion to move draft-olteanu-i… Eric Vyncke (evyncke)
- Re: [Int-area] Suggestion to move draft-olteanu-i… Behcet Sarikaya
- Re: [Int-area] Suggestion to move draft-olteanu-i… Toerless Eckert
- Re: [Int-area] Suggestion to move draft-olteanu-i… Adrian Farrel
- Re: [Int-area] Suggestion to move draft-olteanu-i… 'Toerless Eckert'
- Re: [Int-area] Suggestion to move draft-olteanu-i… Eric Vyncke (evyncke)
- Re: [Int-area] Suggestion to move draft-olteanu-i… Vladimir Olteanu