Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Melinda Shore wrote: On 9/23/05 5:38 PM, "Dave Crocker" [EMAIL PROTECTED] wrote: For the proposed area, that does not seem to explain the inclusion of ENUM, instant messaging or presence. (This area is going to take over xmpp, too?) ENUM is ancillary to telephony and not really to much else. ENUM's only reason is map E.164 numbers to URI's which in 99.9 % of the cases means VoIP. ENUM's very existance is totally linked to the rest of the SIP applicaiton suite and as such needs to remain with the rest of those groups. But anyway, you'll note that I argued that "real-time" is an unsuitable name because of what it actually means, not that your definition of real-time was vernacular and we need to focus on what's actually real-time. I tend to prefer naming it something around multimedia applications but as long as whatever it is is reasonably descriptive and won't lead to people thinking that it's a proper place to work on things like storage device controllers, I'm good. I thought the original proposal was pretty good and needed little or no editing including hair splitting on what the name of the directorate should be. Real Time Applications is a pretty good descritpion of the general problem set or maybe "Death to the PSTN Directorate?" . can we just get on with it ? Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Dave Crocker wrote: (This area is going to take over xmpp, too?) I don't think it is a useful exercise to go through all the closed working groups to determine which would have been in RAI had the area existed when they were still active. /a ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
Hi. I'm just catching up but I think signaling is not an essential discriminator of what we're talking about, and thus this name is in fact unreasonable. Some relationships are established or tailored through signaling that have nothing to do with interactiveness or delay tolerance (or SIP). I too have concerns about the wording signaling, which can mean many different things. In a previous email I mentioned LDP, commonly called signaling in the MPLS world. I could have picked any of the ITU-T Q series of recommendations (the series being entitled signalling protocols). However, admittedly there is some correlation between interactive communications and the need for signaling a ephemeral connection. Delay-sensitive interpersonal communications seems to be an excellent description of the scope. I originally thought so too (although I really don't like the interpersonal) and was quite excited about the proposed new area. However, after reading clarifications that the true intent is merely to split up the unwieldly transport area, I think that OFT (Offloaded from Transport) best describes the suggested collection of WGs. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
On Saturday, September 24, 2005 17:02 PM, Pete Resnick allegedly wrote: On 9/24/05 at 4:41 PM -0400, Scott W Brim wrote: On Sat, Sep 24, 2005 11:15:51AM -0500, Pete Resnick allegedly wrote: Signalling Applications and Infrastructure Area Actually, I screwed up: It's Signalled Applications and Infrastructure. Some relationships are established or tailored through signaling that have nothing to do with interactiveness or delay tolerance (or SIP). True, but which Signalled Applications are you thinking of that wouldn't fit into this area? Further, I can think of all sorts of interactive and delay intolerant things that do not belong in this area. *Signalled* applications (and the infrastructure to support them) seems *exactly to describe the things that I want grouped together. The problem I have is that just about every application is signaled, in the sense that there is a control plane exchange to align state and establish paths and parameters before data is exchanged. HTTP includes both, but how about FTP, where the control port and data ports are distinct, and signaling is path-decoupled? Also consider Grids, in which there can be quite a significant setup phase during which signaling takes place. I now understand that signaled is just as important as interactive to you, so I won't suggest taking it out of the name, but signaled is not enough of a differentiator all by itself. I don't mind ambiguous names but I do get concerned about names that are confusing or misleading. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On 9/22/05, Melinda Shore [EMAIL PROTECTED] wrote: On 9/22/05 1:14 AM, Dave Crocker [EMAIL PROTECTED] wrote: The term real-time tends to mean sub-second, and often much faster than that. That seems to be the vernacular use, but strictly speaking real-timeis about robust assurances of delivery within a constrained time period,whether that time period is millisecond or multi-minute.In other words, the focus is on the guarantees, not on really-really-fast. Let me play Devil's Advocate for a second: What wasn't addressed by the previous work done in RSVP and Diffserv that this new area has to be urgently addressed? Are not packet schedulers enough? Or are we going to watch a whole new infrastructure get developed that will be now better than the previous work, with less complexity, and more hope of being deployed outside of DoD programs? Because, frankly, that's the only place I've seen an explicit need for advanced QoS techniques (besides VoIP, and that gets to be really debatable too.) -scooter ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On 9/23/05 at 3:59 PM -0700, Dave Crocker wrote: So far, references have been made to time-sensitive and to signalling, yet it is not clear how this applies to the work that is being defined as seeding the area. Since SIP is really a signalling protocol, yes, that part is clear. But where is the time-sensitive technology component to the work in the area? Dave, I'm not entirely clear here: Do you have a problem with Ted's reformulation of this potential new area as the Signalling Applications and Infrastructure Area? That is, does his description concretely define the new area well enough? (If SAI is reasonable, and I think it is, let's use that reformulation and be done with it.) pr -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On Sat, Sep 24, 2005 11:15:51AM -0500, Pete Resnick allegedly wrote: On 9/23/05 at 3:59 PM -0700, Dave Crocker wrote: So far, references have been made to time-sensitive and to signalling, yet it is not clear how this applies to the work that is being defined as seeding the area. Since SIP is really a signalling protocol, yes, that part is clear. But where is the time-sensitive technology component to the work in the area? Dave, I'm not entirely clear here: Do you have a problem with Ted's reformulation of this potential new area as the Signalling Applications and Infrastructure Area? That is, does his description concretely define the new area well enough? (If SAI is reasonable, and I think it is, let's use that reformulation and be done with it.) Hi. I'm just catching up but I think signaling is not an essential discriminator of what we're talking about, and thus this name is in fact unreasonable. Some relationships are established or tailored through signaling that have nothing to do with interactiveness or delay tolerance (or SIP). Some are established through management. Delay-sensitive interpersonal communications seems to be an excellent description of the scope. Instant messaging should be included. TDM should not, and one-way multimedia should only be ancillary, even if SIP-based. I'm not sure what the name should be but please, putting signaling in the name is worse than real-time. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On 9/24/05 at 4:41 PM -0400, Scott W Brim wrote: On Sat, Sep 24, 2005 11:15:51AM -0500, Pete Resnick allegedly wrote: Signalling Applications and Infrastructure Area Actually, I screwed up: It's Signalled Applications and Infrastructure. Some relationships are established or tailored through signaling that have nothing to do with interactiveness or delay tolerance (or SIP). True, but which Signalled Applications are you thinking of that wouldn't fit into this area? Further, I can think of all sorts of interactive and delay intolerant things that do not belong in this area. *Signalled* applications (and the infrastructure to support them) seems *exactly to describe the things that I want grouped together. Some are established through management. I don't understand. Are you saying that protocols with managed relationships which aren't signalled do belong in this area (and that signalled in the name would muddy the waters somehow)? Could you give me examples? Delay-sensitive interpersonal communications seems to be an excellent description of the scope. (*Shrug*) Interpersonal doesn't seem to apply to some things I want in this area (as I think has been mentioned before. Instant messaging should be included. Right. TDM should not... And TDM is a signalled application? pr -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
Yaakov Stein wrote: (Back to the original subject line) I must admit that I am still unclear as to the true purpose of this new area. At first I understood that the IETF was finally to address real-time and/or delay-sensitive applications, and Brian's list of WGs was just a proposed seeding to start things off. Were this the case, presumably there would very soon be several BOFs proposing solutions to these fundamental questions (although with Oct 3rd as BOF scheduling requests cutoff probably not in Vancouver). Then I started feeling that the main purpose of the new area was to lighten the load of the transport ADs. In this case the seeding IS the content, and we shouldn't expect BOFs, as new WGs would only increase the WG to AD ratio. As I would like the IETF to be confronting the fundamental problems of real-time communications I would prefer the former to be the true intent (and the latter a mere transitory advantage). Could Brian or any of the IESG provide insight on this? Firstly, I refer you to Ted Hardie's New area description/name http://www1.ietf.org/mail-archive/web/ietf/current/msg37849.html which although personal seems to me to frame the scope nicely. Secondly, I don't think this area is an attempt to take the IETF where no IETF has gone before; it's to organize our current scope of work better. As you point out, tackling a new scope of work would need a lot more preparation (and I'd expect the IAB to be heavily involved). Since Ted's updated description removes the R from RAI, perhaps it also fixes this ambiguity. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
On 9/23/05 at 8:51 AM +0200, Brian E Carpenter wrote: Yaakov Stein wrote: I must admit that I am still unclear as to the true purpose of this new area. Firstly, I refer you to Ted Hardie's New area description/name http://www1.ietf.org/mail-archive/web/ietf/current/msg37849.html which although personal seems to me to frame the scope nicely. [...] Since Ted's updated description removes the R from RAI, perhaps it also fixes this ambiguity. Indeed. I think Ted's formulation of Signalled Applications and Infrastructure (I think SIG is a nicer shorthand than SAI) Area is spot on and is a formulation of the new area that I support. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ QUALCOMM Incorporated ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Melinda, et al, The term real-time tends to mean sub-second, and often much faster than that. Vernacular is not usually *more* precise. Note that I cited (human) interactive vs. real-time, with whereas the usage you describe one terms that encompasses both. The discussion at http://www.faqs.org/faqs/realtime-computing/faq/ demonstrates that the term is indeed pretty fuzzy. Still, yes, it's clear that recent use of the term real-time has tended toward the more generalized model in your description, referring to anything that is time bounded by external constraints. For the proposed area, that does not seem to explain the inclusion of ENUM, instant messaging or presence. (This area is going to take over xmpp, too?) Certainly none of those have performance constraints that are significantly different from DNS, HTTP, Telnet, SNMP or a number of other protocols. Nor do they reflect a signaling/transfer model split, as per Ted's revised language. So the technical basis for this new area remains fuzzy. Whether through the use of physically separate networks or through engineered tunnels, things like voice are starting to run on at least logically isolated networks. In which case this is not a new area, but is a new task force, since isolation means it is not part of the standard Internet architecture. Either the effort needs to be seriously coordinated with the rest of the IETF work or it doesn't. If it does, then particularly the infrastructure work needs to be done along with related infrastructure work. Since the bulk of the basis for providing time-bounded response times is almost certain to involve underlying infrastructure changes, then either the changes must be done AS PART OF the full Internet infrastructure technologies, or it must be done as a completely separate community and service. The idea that this new area will make changes to, say, IP, without being part of the Internet area just does not make sense. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On 9/23/05 5:38 PM, Dave Crocker [EMAIL PROTECTED] wrote: For the proposed area, that does not seem to explain the inclusion of ENUM, instant messaging or presence. (This area is going to take over xmpp, too?) ENUM is ancillary to telephony and not really to much else. But anyway, you'll note that I argued that real-time is an unsuitable name because of what it actually means, not that your definition of real-time was vernacular and we need to focus on what's actually real-time. I tend to prefer naming it something around multimedia applications but as long as whatever it is is reasonably descriptive and won't lead to people thinking that it's a proper place to work on things like storage device controllers, I'm good. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Melinda, thanks for pursuing this. I tend to prefer naming it something around multimedia applications but as long as whatever it is is reasonably descriptive and won't lead to people thinking that it's a proper place to work on things like storage device controllers, I'm good. well, what I was in fact trying to get at was the need for characterizing the technical work, unless this really is merely splitting off a piece of apps work according to an interest group. If there are distinguishing technical characteristics to the work being done, then its nature needs to be clear. So far, references have been made to time-sensitive and to signalling, yet it is not clear how this applies to the work that is being defined as seeding the area. Since SIP is really a signalling protocol, yes, that part is clear. But where is the time-sensitive technology component to the work in the area? And if it is multi-media then what does that really mean? Note that email and the web are multi-media... big time. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Adam Roach wrote: Dave Crocker wrote: (This area is going to take over xmpp, too?) I don't think it is a useful exercise to go through all the closed working groups to determine which would have been in RAI had the area existed when they were still active. i agree. so it's probably a good thing I didn't. by the same token it does not make sense to include work that seems to have no relationship to the various (and varying) stated technical criteria. Therefore, mentioned parallel work -- whether active or completed -- by way of demonstrating an implication, did, and does, seem useful. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
Hi Lakshminath, The end result is that we have documents in the RFC Ed queue with another document in the wings called draft-blah-clarifications I'm plotting the growth rate of draft-blah-clarifications, and my current estimate is that it will exceed the size of draft-blah-original before draft-blah-original becomes an RFC. (But we are in deep trouble if the only part of the organization that does reviews is the IESG.) I am curious about the scheduling issues. If the IESG job is a full-time job, why can't the people on IESG find time to meet with each other, f2f or in telecons; perhaps someone will help me understand that. The other issue that comes up is time zones. We've had this in the Nomcom and I found out recently that telecons at odd hours is the norm if you work in some SDOs. I think these should be non-issues really. Perhaps the IESG job description should say in part, you are expected to work some 35-40 hours a week on IESG stuff, should keep your calendar open in the months of ... for a retreat, and should be able to participate in telecons at odd hours. If you remove IESG from that sentence, it probably is already in many IETFers' job descriptions. This isn't a comment on the scaling issue (I think it needs to be considered) but I'm a bit surprised that the above isn't already a part of the job description... The Internet is important, and we should not treat the management of its technical direction as a hobby that you do on top of your day-time job. Maybe in some special cases, but not as general rule. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TAWNNY! (Re: FW: Possible new Real-Time Applications and Infrastucture (RAI) Area)
Eric Fenner wrote: On 9/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We will require all ADs that are the ADs for Bob to change their name formally to Bruce. Eric, That's the best idea I've heard yet. Eric Time was that the multicast name around here was Steve. Bob does at least meet one constraint (3 letters, which is required for the IETF agenda to be nicely aligned). But surely the ADs should then be called Alice? Seriously though - the discussion about exact scope is valuable. Obviously, if we go ahead with the area, the scope will be tuned, and the name could be modified accordingly. Anon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Hobby [Re: Possible new Real-Time Applications and Infrastucture (RAI)Area]
Jari Arkko wrote: Hi Lakshminath, ... Perhaps the IESG job description should say in part, you are expected to work some 35-40 hours a week on IESG stuff, should keep your calendar open in the months of ... for a retreat, and should be able to participate in telecons at odd hours. If you remove IESG from that sentence, it probably is already in many IETFers' job descriptions. This isn't a comment on the scaling issue (I think it needs to be considered) but I'm a bit surprised that the above isn't already a part of the job description... The Internet is important, and we should not treat the management of its technical direction as a hobby that you do on top of your day-time job. Maybe in some special cases, but not as general rule. I don't think anyone takes this on as a hobby (if they do, they didn't read the mail from the Nomcom). But I would advance a principle: Leadership positions should be defined such that the workload is compatible with other employment and personal life. Very few leadership positions should require effective full time work. IMHO, if we can't meet this, it is extremely unlikely that Nomcom will be able to find enough candidates. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On 9/22/05 1:14 AM, Dave Crocker [EMAIL PROTECTED] wrote: The term real-time tends to mean sub-second, and often much faster than that. That seems to be the vernacular use, but strictly speaking real-time is about robust assurances of delivery within a constrained time period, whether that time period is millisecond or multi-minute. In other words, the focus is on the guarantees, not on really-really-fast. By definition, the folks in the new area will not be worrying about cohabitation; they will focus on on the needs of their own set of applications. I don't agree that it will happen by definition, but in any event it's already happening anyway. That there's effectively only one AD covering the area at the moment may have something to do with that, or maybe not. Also, for some of these applications, it's increasingly the case that they're not running on a shared infrastructure. Whether through the use of physically separate networks or through engineered tunnels, things like voice are starting to run on at least logically isolated networks. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Shifting sands [Re: Possible new Real-Time Applications and Infrastucture (RAI) Area]
Bill, Bill Sommerfeld wrote: On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote: If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. Why do you think this would make any difference in practice? chances are that an AD-pair would agree to hold a DISCUSS if either felt that an issue should block publication. As I have had to remind people of before, DISCUSSes aren't intended to block publication - they are intended to start a discussion with the authors and WG about how to resolve an issue. If the IESG actually wants to block a document, it's more explicit and relatively rare. However, you're correct - an Area DISCUSS would likely be the OR of the two AD's opinions. And it's impractical, because there is generally less than a week between a document appearing on the agenda and the moment when the AD needs to enter a ballot. From my point of view, a far greater source of delay is the extraordinarily rapid change in the standards applied to documents by the IESG; it seems that, if your document editor is very busy, by the time a document is reworked to address one set of editorial standards, a new requirement (leading to a new blocking DISCUSS) is likely to appear. Well, that is why we published draft-iesg-discuss-criteria-00 which includes among the non-criteria for a DISCUSS: o Pedantic corrections to non-normative text. ... o Stylistic issues of any kind. ... o There is recent work or additional information that might be added to the document. ... o New issues with unchanged text in documents previously reviewed by the AD in question. ... seems like we could avoid this sort of logrolling by judging a document based on the rules published and in force at the time it was submitted to the IESG. They aren't rules, they're guidelines, in general. However, I largely agree with you - another reason for the above draft. But there are surely exceptions (e.g. new IPR rules, a newly discovered security threat) where currency is essential. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
[EMAIL PROTECTED] wrote: ... My read of most of the current responses on this thread is that the SIP related working groups are feeling pressure in the current Transport Area, so some re-arrangement is needed. What I haven't seen is how having more ADs involved would actually improve things. More parallelism in the steering activities of the 6 ADs replacing four previous ones. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI)Area
(Back to the original subject line) I must admit that I am still unclear as to the true purpose of this new area. At first I understood that the IETF was finally to address real-time and/or delay-sensitive applications, and Brian's list of WGs was just a proposed seeding to start things off. Were this the case, presumably there would very soon be several BOFs proposing solutions to these fundamental questions (although with Oct 3rd as BOF scheduling requests cutoff probably not in Vancouver). Then I started feeling that the main purpose of the new area was to lighten the load of the transport ADs. In this case the seeding IS the content, and we shouldn't expect BOFs, as new WGs would only increase the WG to AD ratio. As I would like the IETF to be confronting the fundamental problems of real-time communications I would prefer the former to be the true intent (and the latter a mere transitory advantage). Could Brian or any of the IESG provide insight on this? Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
H. Someone told me once that real-time means on a time scale such that no measurable time elapses between event occurrences and their recognition. There are technically 2 different types of real-time. Hard real-time means that all processing required is always performed before the next buffer arrives. Soft (or statistical) real-time means that on the average processing finishes before the next buffer arrives, but additional memory will be needed to ensure that data is not lost. So there is no absolute cap on the time-scale for RT delays, it depends on the rate of the data being processed. snip Admittedly, in a networking context, real time is being measured over shorter and shorter time intervals. But the Area being proposed is not really about networking, is it? I hope it is. As I mentioned in my first email on this subject. separation of the processing from the networking results in suboptimality of the combination. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
john == john loughney [EMAIL PROTECTED] writes: john Bill, On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote: If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. Why do you think this would make any difference in practice? chances are that an AD-pair would agree to hold a DISCUSS if either felt that an issue should block publication. john What I meant was that the IESG spends a lot of time on john document review. As I've said before this is actually not the part of the IESG job I would attack if I wanted to decrease IESG load. We get fairly efficient at doing this job. It does take time though. john I don't think anyone has complained that john there is not enough document review. If we add more ADs, john then we will be increasing the amount of document review. Honestly I don't think more document review would be harmful. I would not focus on adding more document review at the final IESG review layer, but I would not be sad if it happened. One of two things will happen. Either the discusses you get will describe real problems that need to be fixed. If that's the case then we should fix these problems. Alternatively we'll get discusses that the informed community consensus ends up concluding are inappropriate. In that case we should work on removing these discusses and training IESG members. That's true regardless of whether we add IESG members. That problem is also very important to fix even if we don't add IESG members. Now, one thing we do get with a new area is more review of documents earlier in the process and more active involvement of ADs in technical management. Many people believe that is needed; I am one of them. As such, I believe the benefits of the new area to the IETF community outweigh the costs. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
It seems that on the Internet so called real time applications are generally either delay sensitive and / or Jitter intolerant. (Which are, of course, different things.) Marshall, I think you are onto something quite fundamental. In recent times, the IETF has gotten quite good at introducing delay and making foliks jittery, so it does make some sense to be official about it... On a slightly more serious note, I'm struck by the co-occurrence of a focus on delay sensitive work with one on delay tolerant (DTN) work. Methinks there really is some commonality on the core services, although the apps are wildly divergent. Probably. However, the skillsets involved in paying attention to infrastructure performance, as needed for internet and transport work, is fundamentally different from that needed for the services that use the infrastructure (generally called applications but why be fussy?) It strikes me that the real danger of creating this specialized area will be a failure to produce results that integrate with the rest of the IETF work. Why don't we have an email area that covers relevant infrastructure services, and a web area that also does, since each of these applications have different infrastructure requirements and the lack of focus on them has had a negative impact on both of their operations. (And, yes, I'm serious that they have different service needs and that their operation is affected by this.) d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote: If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. Why do you think this would make any difference in practice? chances are that an AD-pair would agree to hold a DISCUSS if either felt that an issue should block publication. From my point of view, a far greater source of delay is the extraordinarily rapid change in the standards applied to documents by the IESG; it seems that, if your document editor is very busy, by the time a document is reworked to address one set of editorial standards, a new requirement (leading to a new blocking DISCUSS) is likely to appear. seems like we could avoid this sort of logrolling by judging a document based on the rules published and in force at the time it was submitted to the IESG. - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI)Area
Bill, On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote: If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. Why do you think this would make any difference in practice? chances are that an AD-pair would agree to hold a DISCUSS if either felt that an issue should block publication. What I meant was that the IESG spends a lot of time on document review. I don't think anyone has complained that there is not enough document review. If we add more ADs, then we will be increasing the amount of document review. Is this something we should need? I think David put it quite well that scheduling IESG calls, meetings and retreats is already problematic - adding more ADs will not improve things. Would a re-organization of the current set of areas solve the same thing? If the problem is that certain WGs are not getting enough management time, then would increased usage of Technical Advisors (which is already done) improve things? My read of most of the current responses on this thread is that the SIP related working groups are feeling pressure in the current Transport Area, so some re-arrangement is needed. What I haven't seen is how having more ADs involved would actually improve things. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI)Area
At 02:02 PM 9/21/2005, [EMAIL PROTECTED] wrote: Bill, On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote: If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. Why do you think this would make any difference in practice? chances are that an AD-pair would agree to hold a DISCUSS if either felt that an issue should block publication. What I meant was that the IESG spends a lot of time on document review. I don't think anyone has complained that there is not enough document I for one think that there is not enough document review some times. For instance, in some cases we have long running discussions on a number of issues that get resolved in the mailing list and the people involved don't take the time to thoroughly review documents (I am as guilty as the next person) because, I guess they are tired of looking at the same document again and again. The end result is that we have documents in the RFC Ed queue with another document in the wings called draft-blah-clarifications (some people might be able to guess what I am referring to -- no offense intended to the people who put the long hours to do that work -- it is the reviewers that are at fault). review. If we add more ADs, then we will be increasing the amount of document review. Is this something we should need? I think David put it quite well that scheduling IESG calls, meetings and retreats is already problematic - adding more ADs will not improve things. I am curious about the scheduling issues. If the IESG job is a full-time job, why can't the people on IESG find time to meet with each other, f2f or in telecons; perhaps someone will help me understand that. The other issue that comes up is time zones. We've had this in the Nomcom and I found out recently that telecons at odd hours is the norm if you work in some SDOs. I think these should be non-issues really. Perhaps the IESG job description should say in part, you are expected to work some 35-40 hours a week on IESG stuff, should keep your calendar open in the months of ... for a retreat, and should be able to participate in telecons at odd hours. If you remove IESG from that sentence, it probably is already in many IETFers' job descriptions. regards, Lakshminath Would a re-organization of the current set of areas solve the same thing? If the problem is that certain WGs are not getting enough management time, then would increased usage of Technical Advisors (which is already done) improve things? My read of most of the current responses on this thread is that the SIP related working groups are feeling pressure in the current Transport Area, so some re-arrangement is needed. What I haven't seen is how having more ADs involved would actually improve things. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
Lakshminath, On Wed, Sep 21, 2005 at 02:35:21PM -0700, Lakshminath Dondeti wrote: I am curious about the scheduling issues. If the IESG job is a full-time job, why can't the people on IESG find time to meet with each other, f2f or in telecons; perhaps someone will help me understand that. The other issue that comes up is time zones. We've had this in the Nomcom and I found out recently that telecons at odd hours is the norm if you work in some SDOs. I think these should be non-issues really. Perhaps the IESG job description should say in part, you are expected to work some 35-40 hours a week on IESG stuff, should keep your calendar open in the months of ... for a retreat, and should be able to participate in telecons at odd hours. If you remove IESG from that sentence, it probably is already in many IETFers' job descriptions. I think you have a reasonable understanding of the amount of time involved and issues with time zones. I think we should step away a bit from the word full time for the IESG job. We recently discussed this in the IESG and it was felt my most of us that a time commitment of at least 30 hours per week is needed, while many ADs spend more than that. Whether people than find even more time to do additional work is not really our problem as long it doesn't affect IESG performance. Many of our scheduling problems are related to timezones as you already guessed: in practice we have a 8am-11am window (Pacific Time Zone) that we can use for calls in the morning (from my perspective and assuming that I am not traveling ;-)). Other issues are our different expertises: eg. I am the OPS AD and feel that it is quite important to show up at various fora where operational people show up like NANOG, Apricot and RIPE. I bet that the Security Area Directors have their own security conferences etc. that they feel that are important to attend. In addition, despite the fact that many of us spend most of our time on the AD job, many of us occasionally have a need to show up at our company headquarters. Other issues include things like if you need to schedule something with X people also X people need to respond and progress on finding a common time is only as fast as the last person who reacts. And the larger the group, the more likely this last person is quite late due to various reasons from vacations, illness or to just being extra busy during business travel. Basically, trying to coordinate times that we can all be available is often already challenging and results in scheduling meetings further in the future than we would like to. Note that is just one of the issues, there are many issues that occur in the dynamics of a large group, whether is scheduling or simple things like finding a problem on a conference call bridge where one line causes a lot of noise which clearly takes a lot more time to debug when the group is larger. And all these issues together are decreasing our overall efficiency up to a point where things get extremely hard to get any work done (see Harald's mail for a nice explanation). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
Thanks David. Please see inline: At 05:49 PM 9/21/2005, David Kessens wrote: Lakshminath, On Wed, Sep 21, 2005 at 02:35:21PM -0700, Lakshminath Dondeti wrote: I am curious about the scheduling issues. If the IESG job is a full-time job, why can't the people on IESG find time to meet with each other, f2f or in telecons; perhaps someone will help me understand that. The other issue that comes up is time zones. We've had this in the Nomcom and I found out recently that telecons at odd hours is the norm if you work in some SDOs. I think these should be non-issues really. Perhaps the IESG job description should say in part, you are expected to work some 35-40 hours a week on IESG stuff, should keep your calendar open in the months of ... for a retreat, and should be able to participate in telecons at odd hours. If you remove IESG from that sentence, it probably is already in many IETFers' job descriptions. I think you have a reasonable understanding of the amount of time involved and issues with time zones. I think we should step away a bit from the word full time for the IESG job. We recently discussed this in the IESG and it was felt my most of us that a time commitment of at least 30 hours per week is needed, while many ADs spend more than that. Whether people than find even more time to do additional work is not really our problem as long it doesn't affect IESG performance. Many of our scheduling problems are related to timezones as you already guessed: in practice we have a 8am-11am window (Pacific Time Zone) that we can use for calls in the morning (from my perspective and assuming that I am not traveling ;-)). I have a bi-weekly 7-9 PT standards telecon and my colleagues would like me at the office before we dial-in to the conf calls. I am not a morning person, but so far I was able to make to those meetings, but time will tell. I thought about this while nomcom telecons were going on. Perhaps a rotating schedule which makes it convenient in various time zones might help (for instance if someone in PT -- or worse some TZs in Asia -- volunteers for IESG, they don't have to tell themselves that they have to wakeup early for 2, 4 or 6 years!) The rotation may result in people missing meetings when there is a change, but it is probably worth a try. A weighted fair timezone scheduling algorithm is a good research topic for someone with a lot of free time :-). Other issues are our different expertises: eg. I am the OPS AD and feel that it is quite important to show up at various fora where operational people show up like NANOG, Apricot and RIPE. I bet that the Security Area Directors have their own security conferences etc. that they feel that are important to attend. In addition, despite the fact that many of us spend most of our time on the AD job, many of us occasionally have a need to show up at our company headquarters. Ok, I managed to forget this when I wrote my previous message. (I have seen some ADs at other meetings I go to, so I shouldn't have). I guess I see it better now, but still think this is not an IETF-only problem and other people are making it work and so we should be able to as well. Do you guys share each others' calendars? That seems to help here at work. Someone has override authority to schedule meetings that need a large number of people with similar conflicts as above to attend. best, Lakshminath Other issues include things like if you need to schedule something with X people also X people need to respond and progress on finding a common time is only as fast as the last person who reacts. And the larger the group, the more likely this last person is quite late due to various reasons from vacations, illness or to just being extra busy during business travel. Basically, trying to coordinate times that we can all be available is often already challenging and results in scheduling meetings further in the future than we would like to. Note that is just one of the issues, there are many issues that occur in the dynamics of a large group, whether is scheduling or simple things like finding a problem on a conference call bridge where one line causes a lot of noise which clearly takes a lot more time to debug when the group is larger. And all these issues together are decreasing our overall efficiency up to a point where things get extremely hard to get any work done (see Harald's mail for a nice explanation). David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
I'm not sure 'real time' is being used here in the same sense it might be used outside IP communities, but that's a modest nit for now. (I liked Yaakov Stein's Interactive Services variant, though.) This highlights one of the points of confusion about the current proposal: the idea for the area seems to be getting defined in terms of some performance constraints, but the constraints are fuzzy, at best. Historically, the term interactive refers to human tolerances, with the most interesting threshholds being at 1/2-second and 2 seconds. The term real-time tends to mean sub-second, and often much faster than that. However much of the focus is on streaming, where the focus is on inter-packet jitter, rather than the amount of time it takes for the first packet to show up, or even for round-trip time. And, by the way, just what is it that makes instant message and presence need performance characteristics that are any different from http, DNS, or numerous other interactive protocols? All of this leads to the larger problem that the proposed area appears to desire to stovepipe integrated work on several layers. The one thing this is sure to achieve is an eventual failure to integrate with other uses for shared layers. By definition, the folks in the new area will not be worrying about cohabitation; they will focus on on the needs of their own set of applications. When we start having specialized applications dedicated for shared infrastructure, that clever hour-glass is going to lose its shape... d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
As we see from the comments so far, the problem with giving a name to this new area reveals uncertainty as to the intent. Signaling-centric comments Harald used the phrase SIP-type services (note the emphasis on the signaling aspects) implying that anything that can be setup using SIP and its extensions (or somehow connected with such services) is included. James word-smiths Harald's phrase into what is in and around SIP but modulates it with a not absolutely!, in order to nudge it in the direction of Rich Media Apps. From these comments the interactivity and delay sensitivity is not criticial to the definition. However, as SIP is often used to set up real-time services, they are somehow connected. Traffic-centric comments --- Melinda is worried that real-time might imply timing rigor (presumably Allan deviations, MTIE/TDEV masks and other mathematical monsters) and so presumably is interested in handling real-time (i.e. continuous time) services, but wants to leave the mathematical aspects out. Marshall wishes us to recognizes the difference between sensitivity to delay and to jitter, and emphasizes the former. Grenville sees the challenge in standardizing protocols for delay-sensitive applications, adding interactive gaming to the list. These comments emphasize the difficulty in working over IP when delay (and perhaps delay variation) is critical, which typically means interactive applications. I like to probe the difference between these approaches by asking not about WGs, but about specific apps. Should streaming one-way video, which is real-time but not interactive nor delay sensitive (although it may be jitter sensitive) be under the aegis of this new area ? How about instant messaging and presence indications (mentioned in Brian's original message) which are interactive, but not real-time in the DSP sense ? What about TDM over IP (a subject close to my heart) which is real-time and timing is critical, but is set up using LDP and not SIP ? Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FW: Possible new Real-Time Applications and Infrastucture (RAI) Area
Hi, I'm in favor of establishing this new area. During the past few years the SIP/VoIP/RAI-related work has grown enormously, so that it today forms already a significant proportion of the overall work of the IETF. When that work was integrated under transport area, there were only a couple of WGs, i.e. AVT and MMUSIC. Those have spinned off to various directions, and today we have in addition SIP, SIPPING, SIMPLE, XCON and ECRIT, not to even mention all of the somewhat related WGs that are listed in the proposal below. So, clearly, this work, which was never really only transport, has become too large for the current Transport Area. I think the forming of the new area would improve the synergies of these WGs better thant the current structure. In addition to this IETF centric perspective, another factor that should be considered is that there is also a significant industry interest in this work. This is clearly visible in the amount of dependencies that other organizations (3GPP, 3GPP2, ATIS, ETSI, OMA, ...) have on the deliverables of SIP* and other related WGs. From that point of view I think the new area would help in facilitation of those interactions, and also it would help the industry and other organizations to focus. In general I have been worried about the output of SIP* WGs lately, since there is just so much going on without much getting finished. Obviously forming a new area does not fix this, but at least it would give a clearer chance for managing the work. For instance with the new proposed structure it might make sense to even have such things as RAI interim meetings (already there was one for SIP/SIPPING/SIMPLE/XCON, why not take ECRIT, ENUM etc. along next time). I think there are many people in the IETF like myself, who mainly participate (during the meetings and in the mailing lists) in roughly those WGs which are in the RAI proposal, and usually do not attend much else. Regarding the growth of IETG from 13 to 15 members: I see a risk that it will take more time to get documents through the process if there are more people whose approval is needed. I think this needs some attention, but it should not compromise this initiatigve. On the other hand we have always heard how overloaded the ADs are. So, having some more cycles in the IESG should help in that sense, especially now in the affected areas, i.e. Apps, Transport and RAI. Regards, Markus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext IETF Chair Sent: 16 September, 2005 16:14 To: IETF Announcement list Subject: Possible new Real-Time Applications and Infrastucture (RAI) Area As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list
TAWNNY! (Re: FW: Possible new Real-Time Applications and Infrastucture (RAI) Area)
There seems to be rough consensus that the area should exist, and even what it's supposed to contain - but total confusion about the name! Suggestion: Let's have a popularity contest for the name - someone collect suggestions, and Henrik can make a voting site to gather opinions - and the first person to suggest the name that wins out in the end gets a special badge reading IETF Area Namer at the Vancouver IETF! In the meantime, let it be referred to as TAWNNY - The Area With No Name Yet! Harald, tongue firmly in cheek ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area]
All, I support starting this area, but am a bit confused on what goes in there and not. Espcially on video, if is video conferencing is is fine but if it is video on demand it will have (more or less) the same requirements as TV over Internet. So why is video there but not TV or why isn't TV there when video is? /Loa Original Message Subject: Possible new Real-Time Applications and Infrastucture (RAI) Area Date: Fri, 16 Sep 2005 09:14:15 -0400 From: IETF Chair [EMAIL PROTECTED] To: IETF Announcement list ietf-announce@ietf.org As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TAWNNY! (Re: FW: Possible new Real-Time Applications and Infrastucture (RAI) Area)
How about Converged Real-time APplications? (CRAP) Harald Tveit Alvestrand wrote: There seems to be rough consensus that the area should exist, and even what it's supposed to contain - but total confusion about the name! Suggestion: Let's have a popularity contest for the name - someone collect suggestions, and Henrik can make a voting site to gather opinions - and the first person to suggest the name that wins out in the end gets a special badge reading IETF Area Namer at the Vancouver IETF! In the meantime, let it be referred to as TAWNNY - The Area With No Name Yet! Harald, tongue firmly in cheek ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TAWNNY! (Re: FW: Possible new Real-Time Applications and Infrastucture (RAI) Area)
How about just Bob... No need for acronym, just name it Bob. We will require all ADs that are the ADs for Bob to change their name formally to Bruce. Bill How about Converged Real-time APplications? (CRAP) Harald Tveit Alvestrand wrote: There seems to be rough consensus that the area should exist, and even what it's supposed to contain - but total confusion about the name! Suggestion: Let's have a popularity contest for the name - someone collect suggestions, and Henrik can make a voting site to gather opinions - and the first person to suggest the name that wins out in the end gets a special badge reading IETF Area Namer at the Vancouver IETF! In the meantime, let it be referred to as TAWNNY - The Area With No Name Yet! Harald, tongue firmly in cheek ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TAWNNY! (Re: FW: Possible new Real-Time Applications and Infrastucture (RAI) Area)
On 9/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We will require all ADs that are the ADs for Bob to change their name formally to Bruce. Eric, That's the best idea I've heard yet. Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI)Area
I think that setting up this new area is a great idea, and shows that we are adapting the structure of the IETF to the applications people now want to use on the Internet. A few more detailed comments follow. The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Delay sensitivity impacts communications in several ways. For setup protocols you want to minimize the number of round-trips until the user has positive feedback of connectivity status. For voice and interactive video, delay sensitivity rules out retransmissions, and so raises the issue of packet loss concealment. This in general involves DSP and/or image processing treatments. For more general data, this means forward error correction and maximum likelihood estimation of missing data. These mathematically sophisticated subjects have previously been avoided in the IETF (and are awfully hard to present in ASCII ID format). Is it now proposed to treat these subjects in the IETF, and to attempt to draw in audiences interested in so doing? Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. This is a good characterization of the delay sensitivity problem, but an unusual definition of real-time. Perhaps DSI (delay-sensitive infrastructure) or ISI (Interactive Services Infrastructure) more aptly captures the intent. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. I don't really see how GEOPRIV and ECRIT fit in, based on the delay sensitivity criterion, although they may somewhat satisfy the rule of thumb. My real question is whether the rule of thumb was invented in order to aid the seeding and thus more equitably divide WGs among areas. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI)Area
--On mandag, september 19, 2005 13:51:54 +0200 Yaakov Stein [EMAIL PROTECTED] wrote: The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. I don't really see how GEOPRIV and ECRIT fit in, based on the delay sensitivity criterion, although they may somewhat satisfy the rule of thumb. Good to see more comment on this topic! (which is one I like) I think all areas in the IETF are more-or-less defined as core of the area + what is closely linked to the core + what fits less badly there than elsewhere - ECRIT would come under closely linked, since its subject area is use of the SIP-type services; GEOPRIV might be more characteristic of fits less badly here than elsewhere - it is used by many of the services like ECRIT, but is also used (or should be) by WGs in other areas. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
On 9/19/05 4:23 PM, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: I think all areas in the IETF are more-or-less defined as core of the area + what is closely linked to the core + what fits less badly there than elsewhere - ECRIT would come under closely linked, since its subject area is use of the SIP-type services; GEOPRIV might be more characteristic of fits less badly here than elsewhere - it is used by many of the services like ECRIT, but is also used (or should be) by WGs in other areas. I think there may be a problem here in that real time may suggest to a number of people a level of rigor in timing that's really not applicable to much of the work the new area is intended to cover. I'm enthusiastic about the area; not so crazy about its name. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
At 04:35 PM 9/19/2005 -0400, Melinda Shore wrote: On 9/19/05 4:23 PM, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: I think all areas in the IETF are more-or-less defined as core of the area + what is closely linked to the core + what fits less badly there than elsewhere - ECRIT would come under closely linked, since its subject area is use of the SIP-type services; GEOPRIV might be more characteristic of fits less badly here than elsewhere - it is used by many of the services like ECRIT, but is also used (or should be) by WGs in other areas. I think there may be a problem here in that real time may suggest to a number of people a level of rigor in timing that's really not applicable to much of the work the new area is intended to cover. I'm enthusiastic about the area; I am also enthusiastic about the area not so crazy about its name. I am also concerned about the name. This is basically (not absolutely!) about what is in and around SIP, and not everything in SIP is in real-time, with GEOPRIV being one of them. Yet, I believe GEOPRIV should be in this new area as there are many of the same faces in the ECRIT, GEOPRIV and SIP/SIPPING/SIMPLE WGs. This tells me there is a commonality between them such that they ought to be in the same area. Perhaps something like Rich Media Apps Area, shortened to the Media Area in discussions. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On Mon, 19 Sep 2005 16:35:58 -0400 Melinda Shore [EMAIL PROTECTED] wrote: On 9/19/05 4:23 PM, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: I think all areas in the IETF are more-or-less defined as core of the area + what is closely linked to the core + what fits less badly there than elsewhere - ECRIT would come under closely linked, since its subject area is use of the SIP-type services; GEOPRIV might be more characteristic of fits less badly here than elsewhere - it is used by many of the services like ECRIT, but is also used (or should be) by WGs in other areas. I think there may be a problem here in that real time may suggest to a number of people a level of rigor in timing that's really not applicable to much of the work the new area is It seems that on the Internet so called real time applications are generally either delay sensitive and / or Jitter intolerant. (Which are, of course, different things.) I guess I would go for Low Latency Applications and Infrastucture (LLAI) myself. Regards Marshall Eubanks intended to cover. I'm enthusiastic about the area; not so crazy about its name. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
At 23:05 19/09/2005, Marshall Eubanks wrote: I guess I would go for Low Latency Applications and Infrastucture (LLAI) myself. Do you conceptually accept in that wording that an OPES can be plugged in there, for example as part of a service to the exchange? The WG-OPES has worked on HTTP, and now on SMTP. IMHO OPES also fit pseudo-synchronous exchanges. In that case the WG-OPES should be able to dialog with the new area at a later stage. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Short form: I like this idea. Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. I'm not sure 'real time' is being used here in the same sense it might be used outside IP communities, but that's a modest nit for now. (I liked Yaakov Stein's Interactive Services variant, though.) Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. I think it would be nice to see explicit mention of delay-sensitive, online, single|multi-player games. To an extent that industry has 'rolled their own' protocols for server discovery, client registration, patch/maps/mod download and upload, lag/loss estimation and compensation, embedded voice channels, encoding of player action streams (commands) and game world state updates (snapshots), etc. I'm not sure if there's a demand (yet) for any IETF WG to develop common protocols and architectures for delay sensitive multi-party/player games, but it would at least be worth flagging the possibility in the new Area's description. (There's certainly been a small yet active community of people studying how current and previous 'home brew' multiplayer game protocols impact on networks, with papers at various workshops and conferences over the past few years.) cheers, gja -- Associate Professor Grenville Armitage Director, Centre for Advanced Internet Architectures http://caia.swin.edu.au ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
On Fri, 16 Sep 2005, IETF Chair wrote: The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. I'm generally sympathetic to this effort. It would probably help focus the transport area (and apps to a degree as well), both for real-time and other WGs. It might also help in getting more people interested in AD positions when the load is smaller and the responsibilities more focused (e.g., SIP folks might not be interested in other transport business; other transport folks might not be so enthusiastic about SIP). Maybe SIMPLE (from apps area) would also fit in this area? At least from an external point of view, it seems rather close.. I'm not personally so worried about the potential increase of DISCUSS ballots. My personal recollection is that the transport ADs have generally been rather focused on the transport business in their comments, and evaluating the documents from the perspective of the area is very useful. The more focused the areas are, the better chances we have of better and more focused review. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Possible new Real-Time Applications and Infrastucture (RAI) Area
I'm of conflicting thoughts about this. On one hand, more Ads could have more opportunity to do more hands-on work with working groups, etc. This would be a good thing, and could potentially help WGs to progress drafts through WGs faster. On the other hand, 2 more ADs means two more potential DISCUSSes and more Ads spending time on document reviews. I'm not sure if what the IETF needs is more Ads to review the documents and file DISCUSSes. If there was a way to lighten-up the IESG review process, then this would be a good idea. For example, having a single DISCUSS per Area would be one way to reduce this could be one solution. In summary, I think that expanding the IESG would only be a good idea only if we could adjust the IESG review load / process so that we are not just expanding the number of potential DISCUSSes. thanks, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext IETF Chair Sent: 16 September, 2005 16:14 To: IETF Announcement list Subject: Possible new Real-Time Applications and Infrastucture (RAI) Area As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Possible new Real-Time Applications and Infrastucture (RAI) Area
As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
