I'm doing my best not to comment, but on two points here ...
On Fri, Oct 10, 2014 at 10:59 AM, Murray S. Kucherawy <superuser@xxxxxxxxx> wrote:
On Thu, Oct 9, 2014 at 7:42 AM, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:Of course. There will periodically be a group of people who want to create a new format for data about people or calendar events, or some possibly-useful way to use HTTP or email, and so on. With this change, they will have to go to an area that is not filled with people who have done that themselves earlier. That's fine: keeping the area around just for that is not a good use of human resources.
I agree with the lauding of any organization that undertakes this sort of structural review from time to time. However, I'm a little uneasy about doing away with APP completely.
Speaking as 1/15th of the IESG, that's not on the table. I haven't heard any of the ADs saying "APP goes away completely". But beyond that ...
I do agree that a lot of APP area work is going into the web and there's a lot of overlap with RAI in that realm, but APP also looks after a lot of much older but still relevant protocols, and also things like the media type registries. Into which of the remaining areas might that work fall? People might find it confusing to have to take their new email-related idea or media type, for example, and shop it around to SEC, INT, RAI, TSV, RTG, GEN or OPS looking for a new WG or a sponsoring AD, and if I were an AD of any of those areas, I'm not sure I'd want it in mine. One could argue that stuff without an obvious home lands in GEN, but the IESG Chair is busy enough as it is. Or should we expand the definition of GEN to cover such things, and find a second AD for that?
Speaking as one of the TSV ADs ... if you think "transport" is "end to end, above IP, below the application", and I do, a bit more than half of TSV is "transport". We've got storage (both iSCSI--ish and NFS). We've got ALTO. We've got CDNI. We've got IPPM.
At the Orlando TSVAREA session, with the area was talking about TSV AD position expectations, David Black got a rousing round of applause when he said he'd never had an AD who understood the work on storage, and he wasn't sure he wanted one (*).
Historically, SIGTRAN produced more SS7 applications (like M3UA) than "transport" protocols (SCTP).
At the Orlando TSVAREA session, with the area was talking about TSV AD position expectations, David Black got a rousing round of applause when he said he'd never had an AD who understood the work on storage, and he wasn't sure he wanted one (*).
Historically, SIGTRAN produced more SS7 applications (like M3UA) than "transport" protocols (SCTP).
Several of the areas are chartering working groups that could reasonably be in any of two or three areas. We just chartered TCPINC, which could just as well have ended up in SEC, and Martin's hoping to get DTN chartered before Honolulu, which could reasonably have ended up in APP.
We can end up talking about appropriate areas at several points in the BOF/WG charter process.
So, I won't comment on anything else, but I did want to assure folks that if the IETF needs to do work on a protocol, we'll find a place to do that work, no matter what the current areas are called.
Thanks,
Thanks,
Spencer
(*) The minutes from the AD expectations discussion in Orlando at http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea are actually pretty interesting.
(*) The minutes from the AD expectations discussion in Orlando at http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea are actually pretty interesting.