Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On Jul 6, 2013, at 12:15 PM, wrote: > First deploy, then tell the IETF about it, and let the IETF put the > documentation into > the preferred 1970s ASCII format. Unless drone revoked RFC 2780, that's the wrong sequence. First develop and test, then tell the IETF in a standards- track RFC, then get that RFC approved, then get a transport number, then deploy. I don't mind general info about stuff in the area meetings, but feedback requires participation, which requires a draft. And deployment of transports requires approved standards to get assigned numbers. Joe
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
s/drone/someone/ set autocorrect=false :-) On Jul 6, 2013, at 4:03 PM, Joe Touch wrote: > > > On Jul 6, 2013, at 12:15 PM, wrote: > >> First deploy, then tell the IETF about it, and let the IETF put the >> documentation into >> the preferred 1970s ASCII format. > > Unless drone revoked RFC 2780, that's the wrong sequence. First develop and > test, then tell the IETF in a standards- track RFC, then get that RFC > approved, then get a transport number, then deploy. > > I don't mind general info about stuff in the area meetings, but feedback > requires participation, which requires a draft. And deployment of transports > requires approved standards to get assigned numbers. > > Joe
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
Well, that's the wrong sequence, too. IANA can allocate numbers at draft stage long before RFC - as it did for Saratoga http://saratoga.sf.net But even your sequence says 'tell the IETF', not 'participate in an IETF WG with all the drones'. Since QUIC is already deployed worldwide, I am reminded of King Canute. Lloyd Wood http://sat-net.com/L.Wood/ From: Joe Touch [to...@isi.edu] Sent: 06 July 2013 08:03 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded On Jul 6, 2013, at 12:15 PM, wrote: > First deploy, then tell the IETF about it, and let the IETF put the > documentation into > the preferred 1970s ASCII format. Unless drone revoked RFC 2780, that's the wrong sequence. First develop and test, then tell the IETF in a standards- track RFC, then get that RFC approved, then get a transport number, then deploy. I don't mind general info about stuff in the area meetings, but feedback requires participation, which requires a draft. And deployment of transports requires approved standards to get assigned numbers. Joe
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
And where in your sequence did a standard appear? Outside a wg? On Jul 6, 2013, at 2:20 AM, wrote: > Well, that's the wrong sequence, too. IANA can allocate numbers at draft > stage long before RFC - as it did for Saratoga http://saratoga.sf.net > > But even your sequence says 'tell the IETF', not 'participate in an IETF WG > with all the drones'. > > Since QUIC is already deployed worldwide, I am reminded of King Canute. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: Joe Touch [to...@isi.edu] > Sent: 06 July 2013 08:03 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > On Jul 6, 2013, at 12:15 PM, wrote: > >> First deploy, then tell the IETF about it, and let the IETF put the >> documentation into >> the preferred 1970s ASCII format. > > Unless drone revoked RFC 2780, that's the wrong sequence. First develop and > test, then tell the IETF in a standards- track RFC, then get that RFC > approved, then get a transport number, then deploy. > > I don't mind general info about stuff in the area meetings, but feedback > requires participation, which requires a draft. And deployment of transports > requires approved standards to get assigned numbers. > > Joe
RE: Draft agenda for the IETF-87 TSV Area meeting uploaded
Few RFCs are standards track. IETF transport focuses on maintaining its existing standards; that's my point. It's not really set up for experimental work not directly related to those standards. Lloyd Wood http://sat-net.com/L.Wood/ From: Joe Touch [to...@isi.edu] Sent: 06 July 2013 19:33 To: Wood L Dr (Electronic Eng) Cc: Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded And where in your sequence did a standard appear? Outside a wg? On Jul 6, 2013, at 2:20 AM, wrote: > Well, that's the wrong sequence, too. IANA can allocate numbers at draft > stage long before RFC - as it did for Saratoga http://saratoga.sf.net > > But even your sequence says 'tell the IETF', not 'participate in an IETF WG > with all the drones'. > > Since QUIC is already deployed worldwide, I am reminded of King Canute. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: Joe Touch [to...@isi.edu] > Sent: 06 July 2013 08:03 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > On Jul 6, 2013, at 12:15 PM, wrote: > >> First deploy, then tell the IETF about it, and let the IETF put the >> documentation into >> the preferred 1970s ASCII format. > > Unless drone revoked RFC 2780, that's the wrong sequence. First develop and > test, then tell the IETF in a standards- track RFC, then get that RFC > approved, then get a transport number, then deploy. > > I don't mind general info about stuff in the area meetings, but feedback > requires participation, which requires a draft. And deployment of transports > requires approved standards to get assigned numbers. > > Joe
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On Jul 6, 2013, at 2:52 PM, wrote: > > Few RFCs are standards track. But only those qualify for new transport numbers. > IETF transport focuses on maintaining its existing standards; that's > my point. It's not really set up for experimental work not directly > related to those standards. Early experimental work can come through the IRTF but new standards track transports can easily start in tsv wg. That wg isn't just for changes to existing standards. Joe > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: Joe Touch [to...@isi.edu] > Sent: 06 July 2013 19:33 > To: Wood L Dr (Electronic Eng) > Cc: > Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded > > And where in your sequence did a standard appear? Outside a wg? > > On Jul 6, 2013, at 2:20 AM, wrote: > >> Well, that's the wrong sequence, too. IANA can allocate numbers at draft >> stage long before RFC - as it did for Saratoga http://saratoga.sf.net >> >> But even your sequence says 'tell the IETF', not 'participate in an IETF WG >> with all the drones'. >> >> Since QUIC is already deployed worldwide, I am reminded of King Canute. >> >> Lloyd Wood >> http://sat-net.com/L.Wood/ >> >> >> >> From: Joe Touch [to...@isi.edu] >> Sent: 06 July 2013 08:03 >> To: Wood L Dr (Electronic Eng) >> Cc: ; >> Subject: Re: Draft agenda for the IETF-87 TSV Area meeting uploaded >> >> On Jul 6, 2013, at 12:15 PM, wrote: >> >>> First deploy, then tell the IETF about it, and let the IETF put the >>> documentation into >>> the preferred 1970s ASCII format. >> >> Unless drone revoked RFC 2780, that's the wrong sequence. First develop and >> test, then tell the IETF in a standards- track RFC, then get that RFC >> approved, then get a transport number, then deploy. >> >> I don't mind general info about stuff in the area meetings, but feedback >> requires participation, which requires a draft. And deployment of transports >> requires approved standards to get assigned numbers. >> >> Joe
Re: Draft agenda for the IETF-87 TSV Area meeting uploaded
On 7/6/2013 5:52 PM, l.w...@surrey.ac.uk wrote: > > IETF transport focuses on maintaining its existing standards; that's > my point. It's not really set up for experimental work not directly > related to those standards. > I'm not really sure how TSV could be setup any better to do this type of work. It could be a matter of opinion how "directly related" the experimental work is. For instance, CONEX is built on ECN, MPTCP is built on TCP, and RMCAT is building on RTP ... but all are such significant developments that they can't be classed as simply "maintenance". In Berlin, TSV has 2 BoFs planned in Berlin which are not jst maintenance of existing standards (TCMTF and AQM). Clearly, there are also important existing protocols (TCP, SCTP, etc) that a lot of TSV energy goes into maintaining, but that's certainly not all that we do. The community focuses on what it chooses to, by individuals (and companies sponsoring them) investing time and energy into the WGs and drafts that they have shared interests in. For some experimental things, that can be difficult because it requires a critical mass, and people have to be willing to work together at whatever pace the group adapts. Larger groups will have slower paces. The hope is that we wind up with better specs, less flaws, and stronger interop between multiple codebases as a result of working together, and create a better Internet. Those are not the priority for every protocol development effort, and a lot of people have good reasons for doing things on their own. This does not signal a problem with the IETF. -- Wes Eddy MTI Systems
