RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC
So perhaps if we replace REQ-022 and REQ-023 with the requirement that Muthu has proposed and one further requirement, e.g.: "REQ-022 The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata either at storage or at playback. REQ-023 The mechanism MUST provide means for relating recordings to wall clock time." John (as individual) > -Original Message- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperu...@cisco.com] > Sent: 14 April 2011 21:42 > To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org > Cc: sip...@ietf.org > Subject: RE: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based MediaRecording (SIPREC)) toInformational RFC > > I agree with John that these seem more like part of a solution rather > than actual requirements. In addition, sending the wallclock time at > media start/end alone may not suffice for achieving inter-media > synchronization and playback, instead we may need to send the > wallclock > time periodically, like RTCP. For e.g, if there is a codec > renegotiation > in CS the RTP timestamp can restart from a random value. If silence > suppression is enabled there would be gaps in the RTP timestamp. > > These are things that need to be discussed as part of the solution -- > the requirement itself should be generic enough, like what I > described. > REQ-022 and REQ-023 we have doesn't seem to clearly indicate the > purpose. > > Muthu > > |-Original Message- > |From: Ram Mohan R (rmohanr) > |Sent: Thursday, April 14, 2011 10:13 PM > |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |Cc: sip...@ietf.org > |Subject: RE: [siprec] Last Call: (Use > Cases andRequirements for SIP- > |based MediaRecording (SIPREC)) toInformational RFC > | > |We already have attributes Start-Time / End-time in Media Stream > block. This is for the same purpose > |to indicate the wall clock time for start/end of media. > | > |Ram > | > |> -Original Message- > |> From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On > |> Behalf Of Leon Portman > |> Sent: Thursday, April 14, 2011 9:57 PM > |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: sip...@ietf.org > |> Subject: Re: [siprec] Last Call: (Use > |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) > |> toInformational RFC > |> > |> I am not sure that having wall clock only for CS start is enough, > |> especially for partial metadata update. I will prefer to have on > media > |> level > |> > |> Leon > |> > |> -Original Message- > |> From: Elwell, John [mailto:john.elw...@siemens-enterprise.com] > |> Sent: Thursday, April 14, 2011 3:58 PM > |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> Cc: sip...@ietf.org > |> Subject: RE: [siprec] Last Call: > (Use > |> Cases andRequirements for SIP-based Media Recording (SIPREC)) > |> toInformational RFC > |> > |> Understood, but if we have wall clock time for the start of a CS, > |> wouldn't that be sufficient? The new requirement would cover > |> synchronization of all media start/stops relative to that time. > |> > |> John (as individual) > |> > |> > |> > -Original Message- > |> > From: Leon Portman [mailto:leon.port...@nice.com] > |> > Sent: 14 April 2011 13:19 > |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); > ietf@ietf.org > |> > Cc: sip...@ietf.org > |> > Subject: RE: [siprec] Last Call: > |> > (Use Cases andRequirements for > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > Actually REQ-022 and REQ-023 describing not only requirement to > |> > synchronize between different media streams but more importantly > |> > ability to relate them to real world (wall) clock. It is not only > |> > important to playback them correctly but also to know when it was > |> > said. > |> > One example is continue trading after closing hour (even for one > |> > second is not allowed) > |> > > |> > And if these media are synchronized to wall clock then they are > also > |> > synchronized between them thus I am not sure if we need this > |> > additional requirement. > |> > > |> > Thanks > |> > > |> > Leon > |> > > |> > -Original Message- > |> > From: siprec-boun...@ietf.org > |> > [mailto:siprec-boun...@ietf.org] On Behalf Of Elwell, John > |> > Sent: Thursday, April 14, 2011 1:54 PM > |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > |> > Cc: sip...@ietf.org > |> > Subject: Re: [siprec] Last Call: > |> > (Use Cases andRequirements for > |> > SIP-based Media Recording (SIPREC)) toInformational RFC > |> > > |> > > |> > > |> > > |> > > -Original Message- > |> > > From: siprec-boun...@ietf.org > |> > > [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu > |> > ArulMozhi Perumal > |> > > (mperumal) > |> > > Sent: 14 April 2011 07:34 > |> > > To: ietf@ietf.org > |> > > Cc: sip...@ietf.org > |> > > Subject: Re: [siprec]
Weekly posting summary for ietf@ietf.org
Total of 57 messages in the last 7 days. script run at: Fri Apr 15 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 8.77% |5 | 7.70% |35805 | bob.hin...@gmail.com 5.26% |3 | 4.54% |21094 | hous...@vigilsec.com 1.75% |1 | 7.14% |33185 | chalik...@gmail.com 3.51% |2 | 5.22% |24276 | o...@nlnetlabs.nl 3.51% |2 | 4.94% |22939 | ron.even@gmail.com 3.51% |2 | 4.46% |20736 | mperu...@cisco.com 3.51% |2 | 3.99% |18525 | leon.port...@nice.com 3.51% |2 | 3.89% |18058 | john.elw...@siemens-enterprise.com 3.51% |2 | 3.46% |16080 | brian.e.carpen...@gmail.com 3.51% |2 | 3.02% |14042 | cy...@daboo.name 3.51% |2 | 2.49% |11556 | l...@cisco.com 3.51% |2 | 2.24% |10392 | o...@cisco.com 1.75% |1 | 3.32% |15451 | hal...@gmail.com 1.75% |1 | 3.20% |14849 | les...@thinkingcat.com 1.75% |1 | 3.00% |13947 | t...@americafree.tv 1.75% |1 | 2.84% |13175 | even.r...@huawei.com 1.75% |1 | 2.79% |12957 | stpe...@stpeter.im 1.75% |1 | 2.02% | 9366 | dou...@rpi.edu 1.75% |1 | 2.00% | 9274 | mo...@network-heretics.com 1.75% |1 | 1.90% | 8808 | dave.thew...@calconnect.org 1.75% |1 | 1.85% | 8620 | john-i...@jck.com 1.75% |1 | 1.70% | 7911 | barryle...@computer.org 1.75% |1 | 1.65% | 7671 | tglas...@earthlink.net 1.75% |1 | 1.42% | 6599 | evniki...@gmail.com 1.75% |1 | 1.35% | 6283 | nar...@us.ibm.com 1.75% |1 | 1.33% | 6182 | t...@smartcomsoftware.com 1.75% |1 | 1.22% | 5655 | f...@cisco.com 1.75% |1 | 1.18% | 5471 | iljit...@muada.com 1.75% |1 | 1.15% | 5337 | dwor...@avaya.com 1.75% |1 | 1.13% | 5238 | s...@resistor.net 1.75% |1 | 1.12% | 5225 | d...@dotat.at 1.75% |1 | 1.10% | 5103 | i.g...@comcast.net 1.75% |1 | 1.06% | 4905 | m...@cloudmark.com 1.75% |1 | 1.03% | 4790 | joe...@bogus.com 1.75% |1 | 1.01% | 4693 | do...@dougbarton.us 1.75% |1 | 1.00% | 4627 | amor...@amsl.com 1.75% |1 | 0.99% | 4588 | ch...@ietf.org 1.75% |1 | 0.98% | 4575 | b...@estacado.net 1.75% |1 | 0.98% | 4538 | m...@sabahattin-gucukoglu.com 1.75% |1 | 0.94% | 4349 | mo...@necom830.hpcl.titech.ac.jp 1.75% |1 | 0.86% | 3995 | m...@sap.com 1.75% |1 | 0.82% | 3831 | g...@amsl.com +--++--+ 100.00% | 57 |100.00% | 464701 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: audio streaming archive...
On Wed, Apr 13, 2011 at 09:58:24PM -0700, Joel Jaeggli wrote: > there was a naming convention issue on the channel5 recorder which I > thought that we caught all of those by I could be wrong... > > The contractor has the channel8 recorder and should be able toretrive > the file. Is there an ETA for the fix to that? I listened to both the .mp3 and .mp3.1 file for wed-am ch8, and neither sounds like the DANE session to me. -- Scott Schmit > On 4/13/11 7:54 PM, Martin Rex wrote: > > Peter Saint-Andre wrote: > >> > >> On 3/29/11 2:16 AM, Joel Jaeggli wrote: > >> > >>> the long term home as with all other recordings is: > >>> > >>> http://www.ietf.org/audio/ > >> > >> I receive a 403 Forbidden error there. > > > > There seems to be an(other?) archive here: > > http://ietf80streaming.dnsalias.net/ietf80/ > > > > I tried to listen to the DANE session from Wednesday morning > > (should have been channel 8 according to the agenda), > > but the ch8 wed-am file seems to be a copy of ch5 wed-am instead. :-( > > > > -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Apr 14, 2011, at 5:01 AM, Olaf Kolkman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Apr 14, 2011, at 9:17 AM, Brian E Carpenter wrote: > >> On 2011-04-14 06:19, Bob Hinden wrote: >>> Olaf, >>> >>> On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote: >>> [as editor:] It seems that the high order bit of this discussion circles around the question on whether it a requirement for the IETF Chair to have a voting position in order to effectively perform oversight. Once we figured out where we want to go with that we can think about delegation by the chair vs appointment by the bodies and the implementation details with respect to the trust. >>> >>> For the record, I don't agree with this summary. That is, I >>> still question the basic assumption in the proposal. We have >>> "running code" in the IASA model and it appears to work >>> reasonable well. Not perfect, of course. In particular I >>> think that having the IETF chair, IAB chair, and ISOC >>> president as voting members of the IAOC (and IETF Trust) has >>> worked very well. It makes them an active part of decisions >>> the IAOC and IETF Trust are making and helps keep the IAOC >>> from getting disconnected from the community. It also makes >>> them share the responsibility for decisions by having their >>> vote be publicly recorded. >> >> I agree. I think this responsibility should not be delegated. >> It's fundamental to the success of the IETF (and the ISOC for >> that matter - the IETF is a major source of ISOC's legitimacy). >> The IAOC delegates execution to the IAD etc. - maybe the real >> bug is that the IAOC itself needs to delegate more? >> > > > > I agree the IASA model is working well and I also agree that the chairs have > played an important role. > > But I am not convinced that it is the only way to keep the IAOC from getting > disconnected from the community. To turn that argument around: If it is the > case that we need the IAB chair, IETF chair and ISOC president [iChiefs] to > keep the IAOC on track then why do we have NOMCOM appointments? One could > easily argue that the NOMCOM appointments are made to keep the IAOC connected > to the community. > > I also do not see why it 'it's fundamental to the success of the IETF'. I do > agree that the iChiefs need to understand what is going on, there is no > dispute about, but I question whether IAOC membership is best and most > efficient instrument. > > > >>> I also don't understand what the effect of the proposal is on >>> the IETF Trust. Currently all IAOC members are members of >>> the IETF Trust. They have to sign a letter accepting this >>> role. I don't think it can then be delegated. >> >> It can't be delegated. However, a duly approved update to BCP101 >> can change the definition of the formal membership of the >> IAOC, and that would automatically change the membership of >> the Trust. An alternative would be a formal change to the Trust >> Agreement, but since IANAL, I don't know whether a change to >> allow delegation or proxies would be possible under the law of >> the Commonwealth of Virginia, where the Trust was established. >> > > I do not want to brush over this important detail. But, let us first figure > out what we want with the IAOC. If there is no consensus on having the > iChiefs play a less involved role then fine tuning the details doesn't make > sense. If we gain consensus then fixing the Trust is doable. > Please note that, as I am sure you are aware, the consensus that would have to be gained to modify the Trust agreement is among the Trustees. >>> >>> Your draft focuses on one area (that is, reducing the burden >>> of these positions), but does not discuss any other aspects >>> of making this change. What might the negative aspects of >>> delegating this responsibility be? How will this be dealt >>> with? > > Help me out. > > The main _potential_ negative aspect is a drop of iChiefs' awareness of what > is going on; and the ability to directly influence decisions. > I think that you are neglecting the potential impact on the IAOC/Trust. When the IETF Chair or the IAB Chair speaks in the IAOC or the Trust on a matter in their area of responsibility, their words carry a lot of weight. Their representative will inevitably lose some of that weight, and their use will thus change the balance in the IAOC and the Trust. Suppose, for example, that the iChief in question has been negotiating some issue with the US DoC or the ITU or ICANN or a potential host country's IT Ministry. Such negotiations frequently impact either the IAOC or the Trust (or both) - in terms of the budget, sponsors, meeting locations, etc. Will their IAOC/Trust representative be part of any such negotiations as a matter of course ? If not, then they will not speak authoritatively about them. No matter how carefully they are briefed, there may be matters arising
Flashback
So, here we are celebrating 25 years of the IETF and it seems like only yesterday that I put together this slide deck of the 20 year celebration: http://www.yikes.com/~ole/store/IETF-20years.pdf Enjoy! Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Bob: >> The proposed update to BCP 101 permits further delegation of the IAOC voting >> position. While I do not see myself taking advantage of this new feature, I >> do think we should give future IETF Chairs this option. It is a cohesive >> part of the work that can be delegated. Some coordination between the IETF >> Chair and the delegate would be necessary, but the time commitment would be >> significantly less than participating in the IAOC and a subset of its >> committees. > > > This prompts me to ask a question. Who would the IETF Chair delegate this > responsibility to? The draft doesn't specify. > > An Area Director is the obvious answer, except from what I understand ADs are > also extremely busy. This trades one problem for another. If it is someone > not on the IESG, then this is effectively turning into giving the IESG > another IAOC slot to select. > > As a general comment on the draft, I think it needs to be clear as to who the > delegation can be made to and how much authority is delegated. I think that the delegate would have t be an IESG member, otherwise it the expected insight would not be provided. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Speaking as an individual, but an individual who helped set up this structure and who sat in the non-delegated ex officio IAB Chair position on the IAOC (and IETF Trust) for a couple of years, let me offer some comments. As Bob noted, elsewhere in the thread, your draft does not describe how to delegate responsibilities, it describes how to allow alternatively fill the positions. And I believe that is a fatal flaw. The discussion on this thread certainly indicates that there isn't a clear grasp of what the responsibilities are for the positions in question. The responsibilities are not: show up for meetings/telecons, offer opinions about how to administer the IETF, and put in a vote when called upon, although those certainly are the functions expected. You described the IAB Chair as "hub" as if that was a bad thing. In fact, the one thing the Chair (of the IAB -- but it applies in analog to the IETF) needs to do is to support the IAB's functioning (through leadership, organization, note-taking, cajoling, listening, etc). That doesn't mean the IAB Chair has to do the work of the whole IAB, but it does mean that an overall perspective is critical, and each Chair has to best organize her/himself to achieve the one task. In setting up the IAOC as it is, the intent was to inject the IAB Chair's overall perspective into the IAOC's discussions, including the support for IAB activities. It was not a question of simply finding more credible people to put on the IAOC. If change is needed, the one path away from the fatal flaw seems to be to articulate the actual responsibilities of the IAB Chair (and IETF Chair and ISOC CEO, as appropriate) in the intended ex officio positions, such that it is possible to get agreement and external confirmation that the role is being properly fulfilled by whomever is selected to perform them. Anything else, IMO, is mindless deconstruction. Leslie. On 4/14/11 5:01 AM, Olaf Kolkman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 14, 2011, at 9:17 AM, Brian E Carpenter wrote: On 2011-04-14 06:19, Bob Hinden wrote: Olaf, On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote: [as editor:] It seems that the high order bit of this discussion circles around the question on whether it a requirement for the IETF Chair to have a voting position in order to effectively perform oversight. Once we figured out where we want to go with that we can think about delegation by the chair vs appointment by the bodies and the implementation details with respect to the trust. For the record, I don't agree with this summary. That is, I still question the basic assumption in the proposal. We have "running code" in the IASA model and it appears to work reasonable well. Not perfect, of course. In particular I think that having the IETF chair, IAB chair, and ISOC president as voting members of the IAOC (and IETF Trust) has worked very well. It makes them an active part of decisions the IAOC and IETF Trust are making and helps keep the IAOC from getting disconnected from the community. It also makes them share the responsibility for decisions by having their vote be publicly recorded. I agree. I think this responsibility should not be delegated. It's fundamental to the success of the IETF (and the ISOC for that matter - the IETF is a major source of ISOC's legitimacy). The IAOC delegates execution to the IAD etc. - maybe the real bug is that the IAOC itself needs to delegate more? I agree the IASA model is working well and I also agree that the chairs have played an important role. But I am not convinced that it is the only way to keep the IAOC from getting disconnected from the community. To turn that argument around: If it is the case that we need the IAB chair, IETF chair and ISOC president [iChiefs] to keep the IAOC on track then why do we have NOMCOM appointments? One could easily argue that the NOMCOM appointments are made to keep the IAOC connected to the community. I also do not see why it 'it's fundamental to the success of the IETF'. I do agree that the iChiefs need to understand what is going on, there is no dispute about, but I question whether IAOC membership is best and most efficient instrument. I also don't understand what the effect of the proposal is on the IETF Trust. Currently all IAOC members are members of the IETF Trust. They have to sign a letter accepting this role. I don't think it can then be delegated. It can't be delegated. However, a duly approved update to BCP101 can change the definition of the formal membership of the IAOC, and that would automatically change the membership of the Trust. An alternative would be a formal change to the Trust Agreement, but since IANAL, I don't know whether a change to allow delegation or proxies would be possible under the law of the Commonwealth of Virginia, where the Trust was established. I do not want to brush over this important detail. But, let us first
Re: IAOC: delegating ex-officio responsibility
On Thu, 14 Apr 2011, Bob Hinden wrote: > Russ, > > > This prompts me to ask a question. Who would the IETF Chair > delegate this responsibility to? The draft doesn't specify. I am thinking it would be someone like the IESG Secretary (if there is such a person), and I mean a member of the IESG, not some contractor. Suppose, for a moment, we were talking about the ISOC BoT here instead of the IESG, the *obvious* choice would be Scott Bradner who has been Board Secretary for longer than any one can remember and clearly has a very good idea about the "sense of the board" at any given time. So, is there an "equivalent" person in the IESG, that isn't also the IESG (IETF) Chair? Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: (IANA Procedures for Maintaining the Timezone Database) to BCP
On behalf of CalConnect and its members I would like to voice our support for the timezone database proposal: http://datatracker.ietf.org/doc/draft-lear-iana-timezone-database/ and encourage its adoption. In particular this proposal is supported by our Timezone Technical Committee (TC TIMEZONE). Valid, accurate and timely timezone information is increasingly essential to computing and the internet, and with Mr. Olson's retirement soon, it becomes critical to determine a permanent home for the process and the the database, while continuing and encouraging the volunteers who provide and manage the data itself. CalConnect has worked from its earliest days on improving ways of accessing timezone data, which is critical to calendaring and scheduling, and has been an early and ongoing supporter of the IETF and IANA offering to provide a home for the Olson database and processes. Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | dave.thew...@calconnect.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Russ, > The proposed update to BCP 101 permits further delegation of the IAOC voting > position. While I do not see myself taking advantage of this new feature, I > do think we should give future IETF Chairs this option. It is a cohesive > part of the work that can be delegated. Some coordination between the IETF > Chair and the delegate would be necessary, but the time commitment would be > significantly less than participating in the IAOC and a subset of its > committees. This prompts me to ask a question. Who would the IETF Chair delegate this responsibility to? The draft doesn't specify. An Area Director is the obvious answer, except from what I understand ADs are also extremely busy. This trades one problem for another. If it is someone not on the IESG, then this is effectively turning into giving the IESG another IAOC slot to select. As a general comment on the draft, I think it needs to be clear as to who the delegation can be made to and how much authority is delegated. Thanks, Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Brian: > I'd really like to hear from > Olaf, Bernard and Russ what has changed in the workload in the > last few years. I am fortunate that my sponsorship situation lets me spend almost full time on the IETF Chair position. Even so, there are aspects of the job that exceed full time. I am not talking about IETF meeting week -- the job far exceeds full time for many others too during that week. That said, the answer to your question is not simple. The IETF Chair is a member of the IAOC, the IETF Trust, the IAB, and the IESG. The IAOC has many committees, and I am unable to participate in all of them. Even though I am interested in all of the topics, it is just not possible to participate in all of them. So, I rely on the people that do participate and review their recommendations when they come to the whole IAOC for a vote. The IETF Trust is the least time commitment. It is important, but it is not usually time consuming. The IAB has recently adopted a structure of "projects" and "initiatives." These are much like IAOC committees, and it will not be possible for any IAB member to participate in all of them. This is necessary and healthy. It also lets the IAB draw on expertise from outside the IAB more easily. The IESG does much less work by committee, but some ADs have directorates or review teams to help with the vast amount of document review. The IETF Chair has relied on Gen-ART since it was established by Harald about eight years ago. I know that I depend on these reviews heavily. The IETF Chair also depends upon the IETF Executive Director and other members of the Secretariat for many day-to-day tasks. I believe that I have made greater use of the Secretariat than many previous IETF Chairs. So, you can readilly see that there is a significant amount of delegation going on. Still, some tasks get starved, simply because other things are more important at the time. Recently, for example, activities around the relationship with ITU SG15 have consumed all available cycles. The proposed update to BCP 101 permits further delegation of the IAOC voting position. While I do not see myself taking advantage of this new feature, I do think we should give future IETF Chairs this option. It is a cohesive part of the work that can be delegated. Some coordination between the IETF Chair and the delegate would be necessary, but the time commitment would be significantly less than participating in the IAOC and a subset of its committees. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC
I agree with John that these seem more like part of a solution rather than actual requirements. In addition, sending the wallclock time at media start/end alone may not suffice for achieving inter-media synchronization and playback, instead we may need to send the wallclock time periodically, like RTCP. For e.g, if there is a codec renegotiation in CS the RTP timestamp can restart from a random value. If silence suppression is enabled there would be gaps in the RTP timestamp. These are things that need to be discussed as part of the solution -- the requirement itself should be generic enough, like what I described. REQ-022 and REQ-023 we have doesn't seem to clearly indicate the purpose. Muthu |-Original Message- |From: Ram Mohan R (rmohanr) |Sent: Thursday, April 14, 2011 10:13 PM |To: Leon Portman; Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |Cc: sip...@ietf.org |Subject: RE: [siprec] Last Call: (Use Cases andRequirements for SIP- |based MediaRecording (SIPREC)) toInformational RFC | |We already have attributes Start-Time / End-time in Media Stream block. This is for the same purpose |to indicate the wall clock time for start/end of media. | |Ram | |> -Original Message- |> From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On |> Behalf Of Leon Portman |> Sent: Thursday, April 14, 2011 9:57 PM |> To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> Cc: sip...@ietf.org |> Subject: Re: [siprec] Last Call: (Use |> Cases andRequirements for SIP-based MediaRecording (SIPREC)) |> toInformational RFC |> |> I am not sure that having wall clock only for CS start is enough, |> especially for partial metadata update. I will prefer to have on media |> level |> |> Leon |> |> -Original Message- |> From: Elwell, John [mailto:john.elw...@siemens-enterprise.com] |> Sent: Thursday, April 14, 2011 3:58 PM |> To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> Cc: sip...@ietf.org |> Subject: RE: [siprec] Last Call: (Use |> Cases andRequirements for SIP-based Media Recording (SIPREC)) |> toInformational RFC |> |> Understood, but if we have wall clock time for the start of a CS, |> wouldn't that be sufficient? The new requirement would cover |> synchronization of all media start/stops relative to that time. |> |> John (as individual) |> |> |> > -Original Message- |> > From: Leon Portman [mailto:leon.port...@nice.com] |> > Sent: 14 April 2011 13:19 |> > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> > Cc: sip...@ietf.org |> > Subject: RE: [siprec] Last Call: |> > (Use Cases andRequirements for |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> > |> > Actually REQ-022 and REQ-023 describing not only requirement to |> > synchronize between different media streams but more importantly |> > ability to relate them to real world (wall) clock. It is not only |> > important to playback them correctly but also to know when it was |> > said. |> > One example is continue trading after closing hour (even for one |> > second is not allowed) |> > |> > And if these media are synchronized to wall clock then they are also |> > synchronized between them thus I am not sure if we need this |> > additional requirement. |> > |> > Thanks |> > |> > Leon |> > |> > -Original Message- |> > From: siprec-boun...@ietf.org |> > [mailto:siprec-boun...@ietf.org] On Behalf Of Elwell, John |> > Sent: Thursday, April 14, 2011 1:54 PM |> > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org |> > Cc: sip...@ietf.org |> > Subject: Re: [siprec] Last Call: |> > (Use Cases andRequirements for |> > SIP-based Media Recording (SIPREC)) toInformational RFC |> > |> > |> > |> > |> > > -Original Message- |> > > From: siprec-boun...@ietf.org |> > > [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu |> > ArulMozhi Perumal |> > > (mperumal) |> > > Sent: 14 April 2011 07:34 |> > > To: ietf@ietf.org |> > > Cc: sip...@ietf.org |> > > Subject: Re: [siprec] Last Call: |> > > (Use Cases andRequirements for |> > > SIP-based Media Recording (SIPREC)) toInformational RFC |> > > |> > > I've one major comment. It draft discusses synchronization |> > between the |> > > recorded media streams and synchronized playback, which |> > seem important |> > > for certain applications: |> > > |> > > |> > > Some applications require the recording of more than one |> > media stream, |> > > possibly of different types. Media are synchronized, either |> > at storage |> > > or at playback. |> > > |> > > |> > > However, in the requirements section it doesn't seem REQ-022 and |> > > REQ-023 are all that are need and sufficient to achieve this with |> > > needed precision. So, I would suggest adding another requirement as |> > > follows: |> > > The mechanism MUST provide means for facilitating |> > synchronization of |> > > the recorded media streams and metadata either at storage or at |> > > playback. |> > > This includes, but not limited t
Re: Last Call: (xCal: The XML format for iCalendar) to Proposed Standard
On 04/14/2011 03:18 PM, Keith Moore wrote: I appreciate that great pains have been taken to ensure that this format is a dual of the standard iCalendar format, that translation can be performed in both directions without loss, and that at least some attempt has been made to specify the conversion algorithms in such a way that (if carefully implemented) they should continue to work with extensions to iCalendar. I think it's confusing that many elements are referred to using an ICAL: prefix, when (a) the xml examples don't actually associate that prefix with a namespace, and (b) when iCal is probably a trademark of Apple. However (and I think it's been at least 10 years since this was first proposed) I still find myself wondering, why is this format needed or even useful?Practically speaking, I think the adoption of this format will only increase the burden on implementations and decrease the likelihood of interoperability between implementations. It will increase the burden on implementations because now implementations will need to be able to accept, and possibly generate, two different calendar data formats instead of one. It will decrease interoperability because there will certainly be some attempts to send xCalendar data created by new implementations, to old implementations that only accept iCalendar data. It will also decrease interoperability because, inevitably, some implementations of the conversion routines will fail to be sufficiently general in order to handle currently-undefined properties and components. This is an almost inherent consequence of the likely use of XML schema description languages that explicitly enumerate element names, and processing languages that associate explicit element names with processing actions. Finally it will decrease interoperability because it will no longer be the case that only producers and consumers of iCalendar data have to interoperate - it will then be necessary for producers, consumers, and converters to all interoperate - thus introducing more opportunities for both implementation bugs and version skew to create problems. In many situations XML is the only acceptable data format. The work going on for the SmartGrid has made that clear to us. Far from decreasing interoperability this work will help keep the work done in XML based environments in line with that in the rest of the calendaring world. It is already the case that other data formats are in use - we're not going to prevent that. The best we can do is to try to provide standardised approaches to conversion and data formats. I also get the impression that the mapping of "values" or data types (section 3.6) between iCalendar and XML is not sufficiently general to permit continued interoperability across extensions. I think that adoption of this format will in practice require that (a) any extensions to iCalendar to also explicitly specify how they are mapped into xCalendar, and (b) every, or nearly every, iCalendar<>xCalendar conversion product to be updated every time there is an extension to the iCalendar format. In the JAXB and SOAP worlds at least this is not an issue. By default those environments ignore elements they are not aware of. That's fine as schemas can be updated when it is important to handle these extensions. An iCalendar XML schema is being developed for use in those environments and already does a reasonable job of handling extensions. We're aware of the problems posed by extensibility (as is most of the enterprise XML world) and are developing ways of mitigating them. I also suspect that converting the format to XML will encourage ad hoc extensions to xCalendar which might not map well to iCalendar - since the constraints and extension model of iCalendar will not be obvious to the typical XML code developer. Use of the "XML" property in iCalendar implies that the conversion routine needs to know which properties are "already" defined in iCalendar, which either implies that iCalendar cannot be extended, or that different converters (knowledgable about different versions of iCalendar) will produce different results (some mapping unknown properties to the iCalendar XML property, and some mapping them to native iCalendar properties). Correct conversion from iCalendar to XML appears to require the converter to know about the types of each of the properties even though these are not explicitly specified in the source iCalendar document. This is problematic if new properties are defined for iCalendar, as old converters won't know about the types of those properties. So, in summary, I still don't think this is worth the trouble. Regardless of the application, providing multiple ways to represent the same information generally seems to degrade interoperability. Keith It's worth remembering that the initial motivation for this specification was not to promote the use of XML but in re
Re: Last Call: (xCal: The XML format for iCalendar) to Proposed Standard
Hi Keith, --On April 14, 2011 11:52:37 AM -0400 Keith Moore wrote: I appreciate that great pains have been taken to ensure that this format is a dual of the standard iCalendar format, that translation can be performed in both directions without loss, and that at least some attempt has been made to specify the conversion algorithms in such a way that (if carefully implemented) they should continue to work with extensions to iCalendar. Yes, that has always been a requirement for this mapping. I think it's confusing that many elements are referred to using an ICAL: prefix, when (a) the xml examples don't actually associate that prefix with a namespace, and (b) when iCal is probably a trademark of Apple. Section 2 explains that the ICAL: prefix is used when elements are referred to outside the context of an XML fragment - i.e. in the actual text. As regards the possible trademark issue, to remove any possibility of that I will change to using IC: instead (hopefully there are not "legal" objections to that). However (and I think it's been at least 10 years since this was first proposed) I still find myself wondering, why is this format needed or even useful?Practically speaking, I think the adoption of this format will only increase the burden on implementations and decrease the likelihood of interoperability between implementations. It will increase the burden on implementations because now implementations will need to be able to accept, and possibly generate, two different calendar data formats instead of one. First of all the real burden in handling iCalendar is not the syntax, it is the semantics (dealing with recurrences, timezones etc). In most cases, apps that use iCalendar parse the data into their own internal object model and deal with it there. Those implementers that have already developed iCalendar-in-XML parsers/generators have found it trivial to do and map to their internal object models (I have done that, and I am sure others can chime in and confirm this too). Secondly, there is a great push on now to include iCalendar data in various web tools and automated systems, where XML is the primary format that is used. In particular, OASIS is planning on adopting this specification as a key component of smart grid work they are undertaking. The Calendaring and Scheduling Consortium has been advising them and helping develop APIs (REST, SOAP) etc to enable the kinds of calendar data access and manipulation that they need. I think that adoption of this format will in practice require that (a) any extensions to iCalendar to also explicitly specify how they are mapped into xCalendar, and (b) every, or nearly every, iCalendar<>xCalendar conversion product to be updated every time there is an extension to the iCalendar format. I disagree that extensions will need to describe anything related to iCalendar-in-XML. We have tried very hard to have an automatic mapping. In fact I have several iCalendar extension drafts in the works and none of them will make reference to iCalendar-in-XML. I also suspect that converting the format to XML will encourage ad hoc extensions to xCalendar which might not map well to iCalendar - since the constraints and extension model of iCalendar will not be obvious to the typical XML code developer. That is a concern. But any changes to the semantics of iCalendar that go on the standards track are covered by the IANA registration procedures outlined in 5545. As such designated experts get to review those and those experts can keep this problem in check (yes I happen to be one of those designated experts). Use of the "XML" property in iCalendar implies that the conversion routine needs to know which properties are "already" defined in iCalendar, which either implies that iCalendar cannot be extended, or that different converters (knowledgable about different versions of iCalendar) will produce different results (some mapping unknown properties to the iCalendar XML property, and some mapping them to native iCalendar properties). One of the primary uses for iCalendar-in-XML is to allow it to be easily embedded in other XML documents (e.g. business-to-business automated transactions that require detailed specification of timing), and to also allow "annotation" of the iCalendar data with other XML elements (in a different namespace) that may provide references back to the enclosing data. The "XML" property is designed to allow round-tripping of XML data in other namespaces embedded in the iCalendar-in-XML data. Correct conversion from iCalendar to XML appears to require the converter to know about the types of each of the properties even though these are not explicitly specified in the source iCalendar document. This is problematic if new properties are defined for iCalendar, as old converters won't know about the types of those properties. Hrmm, good point. I will need to think about how the default value type
Re: IAOC: delegating ex-officio responsibility
John, >> Bob, > > I think you and Olaf (and myself and others) are addressing two > rather different questions. Your note seems to assume the > question is "how to make the IAOC work better". Your answer, if > I understand it correctly, is "it works fairly well today isn't > broken, let's not fix it". If that were the question, I'd agree. No that is not correct, you have it reversed. My concern is that this proposed change would likely make the IAOC work worse. That is, I think it would have a negative impact on the operations of the IETF and that is why I am concerned. I am sympathetic to the leadership's overload problem, but think we should take a broader view. For example, another approach might be to split the IAB's responsibilities into two groups, one focused on architecture (the IAB's traditional role) and another new group to deal with the parts of the job that seems to be growing (liaisons, RFC Editor, etc.). Something like this might make the NOMCOM job easier in the sense that it wouldn't have find people who were strong in architecture and policy administration (I don't think that is the best description of the rest, but can't think of anything better at the moment). Bob > > But, remembering that the IASA has only the purpose of making > the extended IETF (including the IAB) work more efficiently, I > see a somewhat different question. The roles and resource > requirements of the IAB and IETF Chairs have expanded > dramatically over the last several years.. expanded to the point > that the appointing bodies may soon have to choose, not among > the best people for the job, but from those who have spare time > and resources on their hands or, worse, who work for > organizations who see particular value in having one of their > employees in those positions. We have been lucky so far in > finding very good people despite those pressures, but we can't > count on its lasting. > > That situation suggests to me that we should be asking the > question of how we can reduce the absolute requirements > associated with the IAB and IETF Chair positions. If whomever > is in those positions has the time, resources, and interest to > also serve on the IAOC, I'm very much in favor of that. But, > if an individual --or the Nomcom-- have to choose between > exclusion of the best candidate because there aren't enough > resources for him or her to do the [rest of the] Chair job _and_ > the IAOC versus spreading the workload out, then I think it is > in the community's interest to have an alternative.My > personal preference continues to be to make the decision of who > from the IAB (and potentially the IESG) serves on the IAOC be > the decision of the IAB or IESG respectively rather than using > the "delegation" model Olaf suggests but, in practice, I think > it really makes no difference because any reasonable Chair is > going to discuss those options with the relevant body. > > Even if we were not worried about overall workload, we've > discovered at several recent IETF meetings that the schedule for > IAOC-related meetings keeps the IAB and IETF Chairs out of other > meetings that might, objectively, have been important for them > to attend. So it is not clear to me that having those two > people on the IAOC in person is optimal for the community, > independent of whether or not it is desirable for IASA. > >> From that point of view, the right question from the IASA/IAOC > perspective should not be "is it working well enough that there > is no internal reason to make a change" but "can this type of > change be made without serious damage". > > As far as the Trust is concerned, while we couldn't change the > relationship until recently, we can now: if the linkage between > Trust and IAOC membership is interfering with the simultaneous > successful operation of the Trust and the efficient operation of > the IAB and/or IESG, let's just change it. > >john > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Brian, On Apr 14, 2011, at 8:34 AM, Brian E Carpenter wrote: > John, > > On 2011-04-15 01:10, John C Klensin wrote: > ... >> But, remembering that the IASA has only the purpose of making >> the extended IETF (including the IAB) work more efficiently, I >> see a somewhat different question. The roles and resource >> requirements of the IAB and IETF Chairs have expanded >> dramatically over the last several years.. > > We really need to understand that better, and the underlying > reasons for it, in some detail. I don't think that cherry-picking > parts of the jobs to be delegated should be the starting point. > We really need to start by reviewing all the tasks together and > then decide what should be changed. I'd really like to hear from > Olaf, Bernard and Russ what has changed in the workload in the > last few years. You are of course correct that if the workload > is constantly increasing, it will make NomCom's task very hard. > > Certainly the IASA/IAD/IAOC reorganisation produced a noticeable > reduction in the IETF Chair workload, but what has changed since > http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00 ? > It would be good to have a similar analysis for the IAB chair role. +1 If there is a systemic problem, let's talk about that before proposing point solutions. The overload problem also affects other leadership positions such as the IESG AD members. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC
I am not sure that having wall clock only for CS start is enough, especially for partial metadata update. I will prefer to have on media level Leon -Original Message- From: Elwell, John [mailto:john.elw...@siemens-enterprise.com] Sent: Thursday, April 14, 2011 3:58 PM To: Leon Portman; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org Cc: sip...@ietf.org Subject: RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Understood, but if we have wall clock time for the start of a CS, wouldn't that be sufficient? The new requirement would cover synchronization of all media start/stops relative to that time. John (as individual) > -Original Message- > From: Leon Portman [mailto:leon.port...@nice.com] > Sent: 14 April 2011 13:19 > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: sip...@ietf.org > Subject: RE: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based Media Recording (SIPREC)) toInformational RFC > > Actually REQ-022 and REQ-023 describing not only requirement to > synchronize between different media streams but more importantly > ability to relate them to real world (wall) clock. It is not only > important to playback them correctly but also to know when it was > said. > One example is continue trading after closing hour (even for one > second is not allowed) > > And if these media are synchronized to wall clock then they are also > synchronized between them thus I am not sure if we need this > additional requirement. > > Thanks > > Leon > > -Original Message- > From: siprec-boun...@ietf.org > [mailto:siprec-boun...@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, April 14, 2011 1:54 PM > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: sip...@ietf.org > Subject: Re: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > > > -Original Message- > > From: siprec-boun...@ietf.org > > [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu > ArulMozhi Perumal > > (mperumal) > > Sent: 14 April 2011 07:34 > > To: ietf@ietf.org > > Cc: sip...@ietf.org > > Subject: Re: [siprec] Last Call: > > (Use Cases andRequirements for > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > I've one major comment. It draft discusses synchronization > between the > > recorded media streams and synchronized playback, which > seem important > > for certain applications: > > > > > > Some applications require the recording of more than one > media stream, > > possibly of different types. Media are synchronized, either > at storage > > or at playback. > > > > > > However, in the requirements section it doesn't seem REQ-022 and > > REQ-023 are all that are need and sufficient to achieve this with > > needed precision. So, I would suggest adding another requirement as > > follows: > > The mechanism MUST provide means for facilitating > synchronization of > > the recorded media streams and metadata either at storage or at > > playback. > > This includes, but not limited to, the information needed as per > > REQ-022 and REQ-023. > [JRE] This seems a reasonable addition. I wonder if the new > requirement (first sentence only) is sufficient as a > **replacement** for REQ-022 and REQ-023. On reading REQ-022 and > REQ-023 again, it is not so clear what their purpose was, and they > seem to be more like a solution than a requirement. > One purpose would certainly be that covered by Muthu's new > requirement. Was there any other purpose? > > John > > > > > A nitpick: > > Use Case 8 > > In cases where calls inside or between branches must be recorded, a > > centralized recording system in data centers together with > telephony > > infrastructure (e.g. PBX) me deployed. > > > > s/me/may be > > > > Muthu > > > > |-Original Message- > > |From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On > > Behalf Of The IESG > > |Sent: Wednesday, April 06, 2011 6:20 PM > > |To: IETF-Announce > > |Cc: sip...@ietf.org > > |Subject: [siprec] Last Call: > > (Use Cases > > andRequirements for SIP-based > > |Media Recording (SIPREC)) toInformational RFC > > | > > | > > |The IESG has received a request from the SIP Recording WG > (siprec) to > > |consider the following document: > > |- 'Use Cases and Requirements for SIP-based Media > Recording (SIPREC)' > > | as an Informational RFC > > | > > |The IESG plans to make a decision in the next few weeks, > and solicits > > |final comments on this action. Please send substantive > > comments to the > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > comments may > > be > > |sent to i...@ietf.org instead. In either case, please retain the > > |beginning of the Subject line to allow automated sorting. > > | > > |The file can be obtained via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > |IE
Re: IAOC: delegating ex-officio responsibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Certainly the IASA/IAD/IAOC reorganisation produced a noticeable > reduction in the IETF Chair workload, but what has changed since > http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00 ? > It would be good to have a similar analysis for the IAB chair role. > Below is a copy from a note I mailed to the IAB dd Feb 17, 2011. It wis a variation on a note that I mailed to the Nomcom in 2009. It may not map exactly to what you are asking, but I believe it is close enough. Also, my wish to remove the _must_ in the 'iChiefs must be a member of the IAOC' best current practice is not a cherry picking act. The IAB has hired secretarial assistance for the agenda keeping, todo-list maintenance, minutes, etc. It is pushing forward the 'programs and initiatives' model that allows for subgroups to do a lot of actual work without the chair driving that (i.e. much more formal delegation of activities to sub-groups with possibly external members). > Starting off with a personal note. > As you know the IAB chair is selected by and from the IAB membership on a > yearly basis. I first volunteered for the role of chair in March 2007. When I > volunteered the first time I committed myself for 3 to 5 years (obviously > subject to Nomcom and IAB decision). A minimum of 3 years because anything > shorter is almost not worth the investment in the learning curve and the > personal network that is needed to do the job effectively. Not longer than 5 > years because of the fact that(much) longer terms tend to result in strong > identification of a person with the role, sharpness and creativity decline, > and possibly forms of mannerism in dealing with issues. > From my perspective the most ideal scenario was (remember I wrote this in > 2009) that I'd be allowed by the Nomcom and the IAB to serve as a chair for > one more year and then be around for another to allow for continuity. In any > case I think that it would be good for the Nomcom to look out for 'chair > material'. > The main reason why I want to step down now is that there have been some > developments in the NLnet Labs situation that need my attention as director > of that organization that can not be combined with a 0.7 FTE that I seem to > be putting in at the moment. > > As for the responsibilities of the chair. > ∙ A number of 'mechanical/managerial' tasks: > ∙ Managing and organizing the IAB work-flow both on > architectural and organizational items > ∙ Setting priorities, planning activities to be aligned, > identify actionable items and make sure next steps are taken > ∙ Set up various meetings, manage agendas > ∙ Track minutes creation and publication > ∙ A chair's job can be relieved by having an executive director > that complements a chairs talents in organizing these activities. > ∙ Drive discussions > ∙ defining goals > ∙ moderate discussions > ∙ call consensus > ∙ Identify work items > ∙ Incoming appeals > ∙ Specific questions to the IAB from external bodies > ∙ Track (or make sure they are tracked) various developments > that may have impact on the IETF. > ∙ IASA/IAOC and Trust > ∙ As ex-officio membership, to represent IAB (and IRTF) matters > Because the chair is involved in all these activities (s)he becomes a > de-facto information hub, besides because the chair often act as spokes > person there isa tendency for all major organizational work items to > gravitate towards the chair, specifically if the interests of the other > members are mostly architectural. There are arguments that the load on the > IAB chair is to high and it causes the job to be more than a half-time > position (depending on personal effectively, delegation skill, organizational > skills and the quality of an executive director[*], it may even be closer to > 3 quarters). And I believe that there are some structural questions one can > ask, such as in the ex-officio membership of the IASA/IOAC. > If we manage to get the Programs ran as more or less autonomous motors that > produce recommendations to the IAB it may be that the chairs job becomes > relatively bearable. > While I think that with the Programs we have put a good structure in place it > will need serious efforts of the next chair and the NEW IAB to make working > with programs part of the common mindset. > I think, and I realize that I am biased, that an IAB chair has some of the > following skills, properties: > ∙ Organizational: tracking actions, poking people, planning the work > load. A good Executive Director can be of tremendous help > ∙ Moderating and motivating: The ability to herd cats where > occasionally a cat will have its claws out. > ∙ Diplomatic: In inter-organizational contacts taking the diplomatic
Re: Last Call: (xCal: The XML format for iCalendar) to Proposed Standard
I appreciate that great pains have been taken to ensure that this format is a dual of the standard iCalendar format, that translation can be performed in both directions without loss, and that at least some attempt has been made to specify the conversion algorithms in such a way that (if carefully implemented) they should continue to work with extensions to iCalendar. I think it's confusing that many elements are referred to using an ICAL: prefix, when (a) the xml examples don't actually associate that prefix with a namespace, and (b) when iCal is probably a trademark of Apple. However (and I think it's been at least 10 years since this was first proposed) I still find myself wondering, why is this format needed or even useful? Practically speaking, I think the adoption of this format will only increase the burden on implementations and decrease the likelihood of interoperability between implementations. It will increase the burden on implementations because now implementations will need to be able to accept, and possibly generate, two different calendar data formats instead of one. It will decrease interoperability because there will certainly be some attempts to send xCalendar data created by new implementations, to old implementations that only accept iCalendar data. It will also decrease interoperability because, inevitably, some implementations of the conversion routines will fail to be sufficiently general in order to handle currently-undefined properties and components. This is an almost inherent consequence of the likely use of XML schema description languages that explicitly enumerate element names, and processing languages that associate explicit element names with processing actions. Finally it will decrease interoperability because it will no longer be the case that only producers and consumers of iCalendar data have to interoperate - it will then be necessary for producers, consumers, and converters to all interoperate - thus introducing more opportunities for both implementation bugs and version skew to create problems. I also get the impression that the mapping of "values" or data types (section 3.6) between iCalendar and XML is not sufficiently general to permit continued interoperability across extensions. I think that adoption of this format will in practice require that (a) any extensions to iCalendar to also explicitly specify how they are mapped into xCalendar, and (b) every, or nearly every, iCalendar<>xCalendar conversion product to be updated every time there is an extension to the iCalendar format. I also suspect that converting the format to XML will encourage ad hoc extensions to xCalendar which might not map well to iCalendar - since the constraints and extension model of iCalendar will not be obvious to the typical XML code developer. Use of the "XML" property in iCalendar implies that the conversion routine needs to know which properties are "already" defined in iCalendar, which either implies that iCalendar cannot be extended, or that different converters (knowledgable about different versions of iCalendar) will produce different results (some mapping unknown properties to the iCalendar XML property, and some mapping them to native iCalendar properties). Correct conversion from iCalendar to XML appears to require the converter to know about the types of each of the properties even though these are not explicitly specified in the source iCalendar document. This is problematic if new properties are defined for iCalendar, as old converters won't know about the types of those properties. So, in summary, I still don't think this is worth the trouble. Regardless of the application, providing multiple ways to represent the same information generally seems to degrade interoperability. Keith On Apr 14, 2011, at 11:20 AM, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'xCal: The XML format for iCalendar' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-05-12. Exceptionally, comments may be > sent to i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/ > > > > No IPR declarations have been submitted directly on this I-D. > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
John, On 2011-04-15 01:10, John C Klensin wrote: ... > But, remembering that the IASA has only the purpose of making > the extended IETF (including the IAB) work more efficiently, I > see a somewhat different question. The roles and resource > requirements of the IAB and IETF Chairs have expanded > dramatically over the last several years.. We really need to understand that better, and the underlying reasons for it, in some detail. I don't think that cherry-picking parts of the jobs to be delegated should be the starting point. We really need to start by reviewing all the tasks together and then decide what should be changed. I'd really like to hear from Olaf, Bernard and Russ what has changed in the workload in the last few years. You are of course correct that if the workload is constantly increasing, it will make NomCom's task very hard. Certainly the IASA/IAD/IAOC reorganisation produced a noticeable reduction in the IETF Chair workload, but what has changed since http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00 ? It would be good to have a similar analysis for the IAB chair role. Regards Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
--On Wednesday, April 13, 2011 11:19 -0700 Bob Hinden wrote: > Olaf, > > On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote: > >> >> [as editor:] >> >> It seems that the high order bit of this discussion circles >> around the question on whether it a requirement for the IETF >> Chair to have a voting position in order to effectively >> perform oversight. Once we figured out where we want to go >> with that we can think about delegation by the chair vs >> appointment by the bodies and the implementation details with >> respect to the trust. > > For the record, I don't agree with this summary. That is, I > still question the basic assumption in the proposal. We have > "running code" in the IASA model and it appears to work > reasonable well. Not perfect, of course. In particular I > think that having the IETF chair, IAB chair, and ISOC > president as voting members of the IAOC (and IETF Trust) has > worked very well. It makes them an active part of decisions > the IAOC and IETF Trust are making and helps keep the IAOC > from getting disconnected from the community. It also makes > them share the responsibility for decisions by having their > vote be publicly recorded. >... Bob, I think you and Olaf (and myself and others) are addressing two rather different questions. Your note seems to assume the question is "how to make the IAOC work better". Your answer, if I understand it correctly, is "it works fairly well today isn't broken, let's not fix it". If that were the question, I'd agree. But, remembering that the IASA has only the purpose of making the extended IETF (including the IAB) work more efficiently, I see a somewhat different question. The roles and resource requirements of the IAB and IETF Chairs have expanded dramatically over the last several years.. expanded to the point that the appointing bodies may soon have to choose, not among the best people for the job, but from those who have spare time and resources on their hands or, worse, who work for organizations who see particular value in having one of their employees in those positions. We have been lucky so far in finding very good people despite those pressures, but we can't count on its lasting. That situation suggests to me that we should be asking the question of how we can reduce the absolute requirements associated with the IAB and IETF Chair positions. If whomever is in those positions has the time, resources, and interest to also serve on the IAOC, I'm very much in favor of that. But, if an individual --or the Nomcom-- have to choose between exclusion of the best candidate because there aren't enough resources for him or her to do the [rest of the] Chair job _and_ the IAOC versus spreading the workload out, then I think it is in the community's interest to have an alternative.My personal preference continues to be to make the decision of who from the IAB (and potentially the IESG) serves on the IAOC be the decision of the IAB or IESG respectively rather than using the "delegation" model Olaf suggests but, in practice, I think it really makes no difference because any reasonable Chair is going to discuss those options with the relevant body. Even if we were not worried about overall workload, we've discovered at several recent IETF meetings that the schedule for IAOC-related meetings keeps the IAB and IETF Chairs out of other meetings that might, objectively, have been important for them to attend. So it is not clear to me that having those two people on the IAOC in person is optimal for the community, independent of whether or not it is desirable for IASA. >From that point of view, the right question from the IASA/IAOC perspective should not be "is it working well enough that there is no internal reason to make a change" but "can this type of change be made without serious damage". As far as the Trust is concerned, while we couldn't change the relationship until recently, we can now: if the linkage between Trust and IAOC membership is interfering with the simultaneous successful operation of the Trust and the efficient operation of the IAB and/or IESG, let's just change it. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC
Understood, but if we have wall clock time for the start of a CS, wouldn't that be sufficient? The new requirement would cover synchronization of all media start/stops relative to that time. John (as individual) > -Original Message- > From: Leon Portman [mailto:leon.port...@nice.com] > Sent: 14 April 2011 13:19 > To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: sip...@ietf.org > Subject: RE: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based Media Recording (SIPREC)) toInformational RFC > > Actually REQ-022 and REQ-023 describing not only requirement > to synchronize between different media streams but more > importantly ability to relate them to real world (wall) > clock. It is not only important to playback them correctly > but also to know when it was said. > One example is continue trading after closing hour (even for > one second is not allowed) > > And if these media are synchronized to wall clock then they > are also synchronized between them thus I am not sure if we > need this additional requirement. > > Thanks > > Leon > > -Original Message- > From: siprec-boun...@ietf.org > [mailto:siprec-boun...@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, April 14, 2011 1:54 PM > To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org > Cc: sip...@ietf.org > Subject: Re: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > > > -Original Message- > > From: siprec-boun...@ietf.org > > [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu > ArulMozhi Perumal > > (mperumal) > > Sent: 14 April 2011 07:34 > > To: ietf@ietf.org > > Cc: sip...@ietf.org > > Subject: Re: [siprec] Last Call: > > (Use Cases andRequirements for > > SIP-based Media Recording (SIPREC)) toInformational RFC > > > > I've one major comment. It draft discusses synchronization > between the > > recorded media streams and synchronized playback, which > seem important > > for certain applications: > > > > > > Some applications require the recording of more than one > media stream, > > possibly of different types. Media are synchronized, either > at storage > > or at playback. > > > > > > However, in the requirements section it doesn't seem REQ-022 and > > REQ-023 are all that are need and sufficient to achieve this with > > needed precision. So, I would suggest adding another requirement as > > follows: > > The mechanism MUST provide means for facilitating > synchronization of > > the recorded media streams and metadata either at storage or at > > playback. > > This includes, but not limited to, the information needed as per > > REQ-022 and REQ-023. > [JRE] This seems a reasonable addition. I wonder if the new > requirement (first sentence only) is sufficient as a > **replacement** for REQ-022 and REQ-023. On reading REQ-022 > and REQ-023 again, it is not so clear what their purpose was, > and they seem to be more like a solution than a requirement. > One purpose would certainly be that covered by Muthu's new > requirement. Was there any other purpose? > > John > > > > > A nitpick: > > Use Case 8 > > In cases where calls inside or between branches must be recorded, a > > centralized recording system in data centers together with > telephony > > infrastructure (e.g. PBX) me deployed. > > > > s/me/may be > > > > Muthu > > > > |-Original Message- > > |From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On > > Behalf Of The IESG > > |Sent: Wednesday, April 06, 2011 6:20 PM > > |To: IETF-Announce > > |Cc: sip...@ietf.org > > |Subject: [siprec] Last Call: > > (Use Cases > > andRequirements for SIP-based > > |Media Recording (SIPREC)) toInformational RFC > > | > > | > > |The IESG has received a request from the SIP Recording WG > (siprec) to > > |consider the following document: > > |- 'Use Cases and Requirements for SIP-based Media > Recording (SIPREC)' > > | as an Informational RFC > > | > > |The IESG plans to make a decision in the next few weeks, > and solicits > > |final comments on this action. Please send substantive > > comments to the > > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > > comments may > > be > > |sent to i...@ietf.org instead. In either case, please retain the > > |beginning of the Subject line to allow automated sorting. > > | > > |The file can be obtained via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > |IESG discussion can be tracked via > > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > > | > > | > > | > > |No IPR declarations have been submitted directly on this I-D. > > |___ > > |siprec mailing list > > |sip...@ietf.org > > |https://www.ietf.org/mailman/listinfo/siprec > > ___ > > siprec mailing list > > sip...@ietf.org > > https://www.ietf.org/mailman/listinfo/s
RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC
Actually REQ-022 and REQ-023 describing not only requirement to synchronize between different media streams but more importantly ability to relate them to real world (wall) clock. It is not only important to playback them correctly but also to know when it was said. One example is continue trading after closing hour (even for one second is not allowed) And if these media are synchronized to wall clock then they are also synchronized between them thus I am not sure if we need this additional requirement. Thanks Leon -Original Message- From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On Behalf Of Elwell, John Sent: Thursday, April 14, 2011 1:54 PM To: Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org Cc: sip...@ietf.org Subject: Re: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC > -Original Message- > From: siprec-boun...@ietf.org > [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu ArulMozhi Perumal > (mperumal) > Sent: 14 April 2011 07:34 > To: ietf@ietf.org > Cc: sip...@ietf.org > Subject: Re: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based Media Recording (SIPREC)) toInformational RFC > > I've one major comment. It draft discusses synchronization between the > recorded media streams and synchronized playback, which seem important > for certain applications: > > > Some applications require the recording of more than one media stream, > possibly of different types. Media are synchronized, either at storage > or at playback. > > > However, in the requirements section it doesn't seem REQ-022 and > REQ-023 are all that are need and sufficient to achieve this with > needed precision. So, I would suggest adding another requirement as > follows: > The mechanism MUST provide means for facilitating synchronization of > the recorded media streams and metadata either at storage or at > playback. > This includes, but not limited to, the information needed as per > REQ-022 and REQ-023. [JRE] This seems a reasonable addition. I wonder if the new requirement (first sentence only) is sufficient as a **replacement** for REQ-022 and REQ-023. On reading REQ-022 and REQ-023 again, it is not so clear what their purpose was, and they seem to be more like a solution than a requirement. One purpose would certainly be that covered by Muthu's new requirement. Was there any other purpose? John > > A nitpick: > Use Case 8 > In cases where calls inside or between branches must be recorded, a > centralized recording system in data centers together with telephony > infrastructure (e.g. PBX) me deployed. > > s/me/may be > > Muthu > > |-Original Message- > |From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On > Behalf Of The IESG > |Sent: Wednesday, April 06, 2011 6:20 PM > |To: IETF-Announce > |Cc: sip...@ietf.org > |Subject: [siprec] Last Call: > (Use Cases > andRequirements for SIP-based > |Media Recording (SIPREC)) toInformational RFC > | > | > |The IESG has received a request from the SIP Recording WG (siprec) to > |consider the following document: > |- 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' > | as an Informational RFC > | > |The IESG plans to make a decision in the next few weeks, and solicits > |final comments on this action. Please send substantive > comments to the > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > comments may > be > |sent to i...@ietf.org instead. In either case, please retain the > |beginning of the Subject line to allow automated sorting. > | > |The file can be obtained via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > |IESG discussion can be tracked via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > | > | > |No IPR declarations have been submitted directly on this I-D. > |___ > |siprec mailing list > |sip...@ietf.org > |https://www.ietf.org/mailman/listinfo/siprec > ___ > siprec mailing list > sip...@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > ___ siprec mailing list sip...@ietf.org https://www.ietf.org/mailman/listinfo/siprec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Applied Networking Research Prize
I wanted to make sure you were all aware of this opportunity to recognize contributions to networking. Russ -- CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) *** Apply until May 8, 2011 for the ANR Prize for IETF-81, *** July 24-29, 2011 in Quebec City, Canada! The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize (ANRP) is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) * invited talk at the IRTF Open Meeting * travel grant to attend the week-long IETF meeting (airfare, hotel, registration, stipend) * recognition at the IETF plenary * invitation to related social activities * potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize (ANRP) will be awarded three times per year, in conjunction with the three annual IETF meetings. HOW TO APPLY Applicants must nominate a peer-reviewed, recently-published, original journal, conference or workshop paper. Both self nominations (nominating one's own paper) and third-party nominations (nominating someone else's paper) are encouraged. The nominee must be one of the main authors of the nominated paper. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how presentation of these research results will foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party applications) are available to attend the respective IETF meeting in person and in its entirety. Applications must include: * the name and email address of the nominee * a reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement that the nominee is available to attend the respective IETF meeting in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee's web site, etc.) *** Applications are submitted by email to a...@isoc.org. *** SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. The goal is to select 1-2 submissions for the Applied Networking Research Prize (ANRP) during each application period. All applicants will be notified by email. IMPORTANT DATES Applications open: April 11, 2011 Applications close: May 8, 2011 Notifications: May 31, 2011 IETF-81 Meeting:July 24-29, 2011 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [siprec] Last Call: (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC
> -Original Message- > From: siprec-boun...@ietf.org > [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu ArulMozhi > Perumal (mperumal) > Sent: 14 April 2011 07:34 > To: ietf@ietf.org > Cc: sip...@ietf.org > Subject: Re: [siprec] Last Call: > (Use Cases andRequirements for > SIP-based Media Recording (SIPREC)) toInformational RFC > > I've one major comment. It draft discusses synchronization between the > recorded media streams and synchronized playback, which seem important > for certain applications: > > > Some applications require the recording of more than one media stream, > possibly of different types. Media are synchronized, either at storage > or at playback. > > > However, in the requirements section it doesn't seem REQ-022 > and REQ-023 > are all that are need and sufficient to achieve this with needed > precision. So, I would suggest adding another requirement as follows: > The mechanism MUST provide means for facilitating > synchronization of the > recorded media streams and metadata either at storage or at playback. > This includes, but not limited to, the information needed as > per REQ-022 > and REQ-023. [JRE] This seems a reasonable addition. I wonder if the new requirement (first sentence only) is sufficient as a **replacement** for REQ-022 and REQ-023. On reading REQ-022 and REQ-023 again, it is not so clear what their purpose was, and they seem to be more like a solution than a requirement. One purpose would certainly be that covered by Muthu's new requirement. Was there any other purpose? John > > A nitpick: > Use Case 8 > In cases where calls inside or between branches must be recorded, a > centralized recording system in data centers together with telephony > infrastructure (e.g. PBX) me deployed. > > s/me/may be > > Muthu > > |-Original Message- > |From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On > Behalf Of The IESG > |Sent: Wednesday, April 06, 2011 6:20 PM > |To: IETF-Announce > |Cc: sip...@ietf.org > |Subject: [siprec] Last Call: > (Use Cases > andRequirements for SIP-based > |Media Recording (SIPREC)) toInformational RFC > | > | > |The IESG has received a request from the SIP Recording WG (siprec) to > |consider the following document: > |- 'Use Cases and Requirements for SIP-based Media Recording (SIPREC)' > | as an Informational RFC > | > |The IESG plans to make a decision in the next few weeks, and solicits > |final comments on this action. Please send substantive > comments to the > |ietf@ietf.org mailing lists by 2011-04-20. Exceptionally, > comments may > be > |sent to i...@ietf.org instead. In either case, please retain the > |beginning of the Subject line to allow automated sorting. > | > |The file can be obtained via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > |IESG discussion can be tracked via > |http://datatracker.ietf.org/doc/draft-ietf-siprec-req/ > | > | > | > |No IPR declarations have been submitted directly on this I-D. > |___ > |siprec mailing list > |sip...@ietf.org > |https://www.ietf.org/mailman/listinfo/siprec > ___ > siprec mailing list > sip...@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 14, 2011, at 9:17 AM, Brian E Carpenter wrote: > On 2011-04-14 06:19, Bob Hinden wrote: >> Olaf, >> >> On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote: >> >>> [as editor:] >>> >>> It seems that the high order bit of this discussion circles >>> around the question on whether it a requirement for the >>> IETF Chair to have a voting position in order to >>> effectively perform oversight. Once we figured out where we >>> want to go with that we can think about delegation by the >>> chair vs appointment by the bodies and the implementation >>> details with respect to the trust. >> >> For the record, I don't agree with this summary. That is, I >> still question the basic assumption in the proposal. We have >> "running code" in the IASA model and it appears to work >> reasonable well. Not perfect, of course. In particular I >> think that having the IETF chair, IAB chair, and ISOC >> president as voting members of the IAOC (and IETF Trust) has >> worked very well. It makes them an active part of decisions >> the IAOC and IETF Trust are making and helps keep the IAOC >> from getting disconnected from the community. It also makes >> them share the responsibility for decisions by having their >> vote be publicly recorded. > > I agree. I think this responsibility should not be delegated. > It's fundamental to the success of the IETF (and the ISOC for > that matter - the IETF is a major source of ISOC's legitimacy). > The IAOC delegates execution to the IAD etc. - maybe the real > bug is that the IAOC itself needs to delegate more? > I agree the IASA model is working well and I also agree that the chairs have played an important role. But I am not convinced that it is the only way to keep the IAOC from getting disconnected from the community. To turn that argument around: If it is the case that we need the IAB chair, IETF chair and ISOC president [iChiefs] to keep the IAOC on track then why do we have NOMCOM appointments? One could easily argue that the NOMCOM appointments are made to keep the IAOC connected to the community. I also do not see why it 'it's fundamental to the success of the IETF'. I do agree that the iChiefs need to understand what is going on, there is no dispute about, but I question whether IAOC membership is best and most efficient instrument. >> I also don't understand what the effect of the proposal is on >> the IETF Trust. Currently all IAOC members are members of >> the IETF Trust. They have to sign a letter accepting this >> role. I don't think it can then be delegated. > > It can't be delegated. However, a duly approved update to BCP101 > can change the definition of the formal membership of the > IAOC, and that would automatically change the membership of > the Trust. An alternative would be a formal change to the Trust > Agreement, but since IANAL, I don't know whether a change to > allow delegation or proxies would be possible under the law of > the Commonwealth of Virginia, where the Trust was established. > I do not want to brush over this important detail. But, let us first figure out what we want with the IAOC. If there is no consensus on having the iChiefs play a less involved role then fine tuning the details doesn't make sense. If we gain consensus then fixing the Trust is doable. >> >> Your draft focuses on one area (that is, reducing the burden >> of these positions), but does not discuss any other aspects >> of making this change. What might the negative aspects of >> delegating this responsibility be? How will this be dealt >> with? Help me out. The main _potential_ negative aspect is a drop of iChiefs' awareness of what is going on; and the ability to directly influence decisions. >> >> Each of the positions (IETF Chair, IAB chair, ISOC President) >> are different in the way they are selected and this effects >> their ability to delegate their responsibility and who they >> might delegate it to. For example, the IETF chair is >> selected by the NOMCOM and one of his/her responsibilities is >> to sit on the IAB, IAOC, and IETF Trust. The IAB chair is >> selected by the IAB. The ISOC president is hired by the ISOC >> Board of Trustees. Consequently, I think the authority to >> delegate differs and they should be considered separately. I agree, this needs discussion. But lets first see if there is any consensus on going down the path of getting the iChiefs out day-to-day IAOC business. >> >>> [as olaf:] >>> >>> I agree that the IETF chair needs to have a good oversight >>> about what goes on in the IETF, to a lesser extend it is >>> good that the IAB has that oversight too (specifically with >>> respect to its chartered responsibilities) but I wonder if >>> a voting membership is the appropriate instrument. >> >> Why not? It does appear to work. Yes it works. But it consumes a lot of time too. IAOC retreat, meetings at the IETF, regular tele-chats, participation i
Re: IAOC: delegating ex-officio responsibility
On 2011-04-14 06:19, Bob Hinden wrote: > Olaf, > > On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote: > >> [as editor:] >> >> It seems that the high order bit of this discussion circles >> around the question on whether it a requirement for the >> IETF Chair to have a voting position in order to >> effectively perform oversight. Once we figured out where we >> want to go with that we can think about delegation by the >> chair vs appointment by the bodies and the implementation >> details with respect to the trust. > > For the record, I don't agree with this summary. That is, I > still question the basic assumption in the proposal. We have > "running code" in the IASA model and it appears to work > reasonable well. Not perfect, of course. In particular I > think that having the IETF chair, IAB chair, and ISOC > president as voting members of the IAOC (and IETF Trust) has > worked very well. It makes them an active part of decisions > the IAOC and IETF Trust are making and helps keep the IAOC > from getting disconnected from the community. It also makes > them share the responsibility for decisions by having their > vote be publicly recorded. I agree. I think this responsibility should not be delegated. It's fundamental to the success of the IETF (and the ISOC for that matter - the IETF is a major source of ISOC's legitimacy). The IAOC delegates execution to the IAD etc. - maybe the real bug is that the IAOC itself needs to delegate more? > I also don't understand what the effect of the proposal is on > the IETF Trust. Currently all IAOC members are members of > the IETF Trust. They have to sign a letter accepting this > role. I don't think it can then be delegated. It can't be delegated. However, a duly approved update to BCP101 can change the definition of the formal membership of the IAOC, and that would automatically change the membership of the Trust. An alternative would be a formal change to the Trust Agreement, but since IANAL, I don't know whether a change to allow delegation or proxies would be possible under the law of the Commonwealth of Virginia, where the Trust was established. Brian > > Your draft focuses on one area (that is, reducing the burden > of these positions), but does not discuss any other aspects > of making this change. What might the negative aspects of > delegating this responsibility be? How will this be dealt > with? > > Each of the positions (IETF Chair, IAB chair, ISOC President) > are different in the way they are selected and this effects > their ability to delegate their responsibility and who they > might delegate it to. For example, the IETF chair is > selected by the NOMCOM and one of his/her responsibilities is > to sit on the IAB, IAOC, and IETF Trust. The IAB chair is > selected by the IAB. The ISOC president is hired by the ISOC > Board of Trustees. Consequently, I think the authority to > delegate differs and they should be considered separately. > >> [as olaf:] >> >> I agree that the IETF chair needs to have a good oversight >> about what goes on in the IETF, to a lesser extend it is >> good that the IAB has that oversight too (specifically with >> respect to its chartered responsibilities) but I wonder if >> a voting membership is the appropriate instrument. > > Why not? It does appear to work. > >> I believe effective oversight depends on having the >> appropriate high level information and having the >> opportunity to timely inject information that is needed to >> steer an outcome. An alternative method for sharing and >> injecting is having regular meetings between the I* chairs >> and the ISOC President/CEO. I believe that such meetings >> are much more effective for the parties involved than being >> exposed to all details. > > Do we really need to have another regular meeting? Would > this give the I* chairs more authority than they have now? > Sort of an executive committee. Would these meetings be > public, have votes, have public minutes? > >> This only an illustration of an instrument, there may be >> other instruments for oversight as well. But I do not think >> the ex-officio membership is the only method. > > It's not perfect but it is the one we have now and it is > working. We should only change it if we are sure that it > will improve the overall IASA operation. I am seriously > concerned about the current proposal. > > Bob > > > ___ Ietf mailing > list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf > > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
