Re: [art] A very late suggestion (was; Re: Back from leave)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Or, we divide the area back into Real-time and APP area.    

On Mon, Oct 24, 2022 at 2:22 PM Claudio Allocchio <Claudio.Allocchio@xxxxxxx> wrote:

+1 John...

ART is so wide that also somebody just cannot be a total knowleadgeable
expert on "everything"... I would go further that we may try to identify 3
sub-area groups and look for profiles who fit each group...


On Mon, 24 Oct 2022, John C Klensin wrote:

>
>
> --On Sunday, October 23, 2022 13:10 +0000 Francesca Palombini
> <francesca.palombini=40ericsson.com@xxxxxxxxxxxxxx> wrote:
>
>> Hi all,
>>
>> You might have noticed I have been MIA the last 3 months - As
>> some of you know, I have been taking some time off to welcome
>> the birth of my first son Leonardo, who was born on July 29th.
>> We both are well and have been enjoying this time getting to
>> know each other. I am sharing a recent picture in attachment.
>>
>> I wanted to let you know that starting next week I am back at
>> work at 50%, and that I plan to attend IETF 115 remotely. I
>> know I have some catching up to do. If I have missed any
>> important email during this period, please find me during the
>> IETF week, or write me again in the next 2 weeks.
>
>> I also was surprised to see that no one else has accepted
>> nomination for ART AD for the next term - please do think
>> carefully and bring your name forward if you can, or nominate
>> other people that you believe would do a good job: the NomCom
>> needs a good pool of candidates to work its magic, and I am
>> sure there is many of you who would do a great job for the
>> IETF. I personally have accepted nomination but expect to have
>> reduced available time and more parental leave coming next
>> year (which I will discuss with the NomCom). I look forward to
>> seeing more names - there is time until Wednesday - and please
>> do reach out if there is anything you'd like to discuss
>> about the AD role.
>
> With the understanding that this is horribly late in the cycle
> of things, I'd like to make a suggestion: in addition to
> Francesca's suggestion of the need for more candidates for her
> ART AD slot, we add a third ART AD slot and add it as close to
> Right Now as possible. By the numbers alone and just dividing
> the number of WGs in the area by two, the ART ADs are
> responsible for more WGs than ADs in any other area.   We added
> a third AD to Routing which today has "only" 24 WGs for the
> three ADs; ART has 34 for two.  In addition, ART is probably the
> most diverse of the Areas in terms of work it takes on.  That
> was even the case before we recombined Applications and
> Real-time (fwiw, it was even the case when I was Apps AD nearly
> 30 years ago). That diversity requires extra effort by the ADs
> and always has.
>
> I have been told that the IESG discussed the possibility of a
> third ART AD in June or July and concluded it wasn't necessary.
> I think there is now new data: In addition to the WGs per AD
> numbers above, I've seen very considerable traffic in the last
> few weeks in which the work and draft specifications of one WG
> in the Area intersects that of another.  Conflicting
> specifications for doing the same thing are bad news when they
> occur in different SDOs; they are far worse when they occur, not
> only within the IETF but within the same Area.  Procedurally,
> having conflicting versions of parts of specifications from
> different WGs and having one go into IETF Last Call well ahead
> of the other creates a situation for which our processes were
> not designed.  The solution to such problems is (and always has
> been) active AD involvement, either to facilitate discussions
> between the WGs involved or, if needed, to work out guidelines
> about conditions for IETF Last Call.  Murray has, in my opinion,
> been doing a superhuman job under the circumstances (including
> the added stresses and constraints of hybrid meetings), but
> there are not two (much less three) of him and the IETF has not
> yet devised Murray-cloning technology.
>
> A third AD is the solution, even if the Nomcom were to not
> return Francesca and leave Murray and the rest of the IESG
> having to break in two IESG newcomers at the same time.  Again,
> from the numbers (assuming no increase after the upcoming
> DISPATCH meeting), our choice (and the Nomcom's) is between 1
> 1/2 active ADs for parts of next year (or at least "reduced
> available time" for the one of them)l one experienced AD and one
> newcomer (and the community has been told several times that it
> takes a new AD many months to really come up to speed) -- and
> hence a different version of 1 1/2; or either two experienced
> ADs (even with one on partial availability) and a new one or two
> ones (with, I assume, Francesca, willing to help a bit from the
> sidelines).  Just numerically, that answer also seems clear.
> Let's get more nominations for the slot (as Francisca suggests)
> but then let's convince the IESG to create a third ADs position
> (ideally on Thursday but certainly not later than IETF 115) and
> then let the Nomcom fill two open slots from those nominees, not
> just one.
>
> If necessary, treat this as an experiment and plan to explicitly
> review in two years whether AET really needs three ADs.  Or, at
> the risk of making the Nomcom job a bit more difficult, make the
> new slot a one-year appointment and do the review next year.
> But let's do it rather than leaving ourselves with an Area that
> almost certain to not function as well as it could.
>
> thanks for at least considering this,
>    john
>
> _______________________________________________
> art mailing list
> art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/art
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@xxxxxxx
                        Senior Manager and Advisor
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

      PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux