Re: [Iasa20] 6635bis

["Joel M. Halpern" <[e-mail]>]

Given that Ted actually asserted that the discussion on this list was 
expected to be the primary discussion, Brian's point about this being a 
focused venue, and his further point that the relevant vanue would need 
to include a much larger audience, would seem to be very relevant.

Yours,
Joel

On 4/30/19 4:51 PM, Richard Barnes wrote:
> It seems like you're trying to use a process point to shut down 
> discussion here, Brian, and one that's incorrect at that..  As Alissa 
> has already said and Ted confirmed, "the plan for this doc and the other 
> IAB stream bis documents was to discuss them here prior to the IAB 
> running its usual call for community comment".
> 
> Nobody thinks this working group is taking any action here.  This whole 
> discussion is feedback to the IAB, and the IAB has asked for it in 
> advance of their usual comment period.
> 
> --Richard
> 
> On Tue, Apr 30, 2019 at 4:38 PM Brian E Carpenter 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     I agree with Joel, but once again I am strongly against a draft from
>     this WG making any of these changes, which are clearly outside the WG's
>     charter.  When we pass the draft on to the IAB, it would be perfectly
>     appropriate to raise these points during the IAB's period of public
>     comment, which of course concerns the entire community interested in
>     RFCs, not just the IETF.
> 
>     Regards
>         Brian
> 
>     On 01-May-19 06:17, Joel M. Halpern wrote:
>      > On the SOW phrasing, I can live with removing it, although I do
>     not see
>      > the value.
>      >
>      > On the complex reporting, that was the deliberate community
>     compromise..
>      > The goals was to avoid having the RSE be the line manager.  People
>      > management is a VEyr different skill set that what we were (and I
>      > believe still are) looking for in an RSE.  If you suspect there is a
>      > problem with the structure, one could ask the RSE and / or the
>     RPC if
>      > they have a problem with it.
>      >
>      > On making the LLC more able to make the RPC employees, that is a
>     major
>      > shift in structure.  I would want to see an explicit reason for
>     enabling
>      > such a change, not just "to give us more flexibility". 
>       Flexibility in
>      > structuring is good if it solves / avoids a problem.  In this
>     case, what
>      > does that solve / avoid?  If we develop a problem, that would
>     seem the
>      > time to ask the community for permission to make such a change.
>      >
>      > Yours,
>      > Joel
>      >
>      > On 4/30/19 12:40 PM, Sean Turner wrote:
>      >>
>      >>> On Apr 29, 2019, at 15:03, Joel M. Halpern <[e-mail]
>     <mailto:[e-mail]>> wrote:
>      >>>
>      >>> Maybe the correct answer is for us all to stop arguing for any
>     position until there is a proposed change that can be discussed?
>      >>
>      >> Hi! Again sorry for going into radio silence right after
>     starting this thread.
>      >>
>      >> Since Joel asked, I have included review comments below. These
>     deal directly with the question about more flexibility for the RSE
>     and RPC to be either contractors or employees, and the text
>     suggestions assume that the desired result is flexibility for the
>     LLC to choose the type of employment relationship. I have some other
>     comments/questions based on reviewing the doc but I will hold those
>     for now so we can focus on this particular issue..
>      >>
>      >> I realize people wanted to just s/IAOC/LLC/ here as in the other
>     documents (and that the editors dutifully followed this direction),
>     but this draft is prescriptive about what the LLC can do in a way
>     that the other documents are not. As a result, changing the label
>     seems to have other implications that it is worth the community
>     considering. If IAOC == LLC then we would not have gone to the
>     trouble to create the LLC.
>      >>
>      >> Also, in case it was not clear, none of this relates to
>     performance of current contractors in current roles, but rather
>     establishing the LLC's ability to operate successfully in the future.
>      >>
>      >>
>      >> = Section 2 =
>      >>
>      >> The use of the term "SOW" could be read to imply contractor
>     status. Suggestion:
>      >>
>      >> OLD
>      >>    These responsibilities are defined below, although the
>     specific work
>      >>    items under them are a matter for the actual employment
>     contract and
>      >>    its Statement of Work (SOW).
>      >>
>      >> NEW
>      >>    These responsibilities are defined below.
>      >>
>      >> = Section 2.1.1 =
>      >>
>      >> "The RSE is responsible for the performance of the RFC
>     Production Center and Publisher."
>      >>
>      >> It is not clear what this is meant to imply from a management
>     perspective. Also relevant here is Figure 2 and this text from 2.2:
>     "All these activities will be done under the general direction, but
>     not day-to-day management, of the RSE." Under RFC 6635, does this
>     mean that if the performance of the RPC does not meet the standards
>     in the RPC contract, that the RSOC/IAB are to hold the RSE
>     accountable for that? Section 2.1.1 also says the RSE performs
>     annual reviews for the RPC and the Publisher function. But this
>     performance responsibility/accountability relationship is not
>     specified in the RPC contract as far as I can tell. That is,
>     accountability to the RSE for performance of the contract does not
>     appear. Accountability to ISOC (now assigned to the LLC) does appear.
>      >>
>      >> If both employees and contractors are allowed for these
>     functions, it seems like there are multiple different management
>     structures that could all be workable here (e.g., RPC employees
>     reporting to an RSE employee who is their manager, or all of them as
>     employees reporting to another manager within the LLC, or two
>     contractors whose contracts are both managed by the same LLC
>     employee). So if there is flexibility allowed in the employment
>     types, it would probably make more sense for this section to just
>     specify who is expected to be accountable to whom for their
>     performance, and leave out the bits about SOWs and vendor selection.
>     But it's hard to suggest a specific edit since the intent of RFC
>     6635 is not clear, or not clearly reflected in the contracts.
>      >>
>      >> = Section 2.2 =
>      >>
>      >> Same comment as Section 2, regarding "paid contractor.”
>      >>
>      >> OLD
>      >>    The RFC Production Center function is performed by a paid
>     contractor,
>      >>    and the contractor's responsibilities include the following:
>      >>
>      >> NEW
>      >>    The RFC Production Center's responsibilities include the
>     following:
>      >>
>      >> The last sentence of the section would also need to be deleted
>     or edited based on edits to 4.1.
>      >>
>      >> = Section 2.3 =
>      >>
>      >> The last sentence of the section would need to be deleted or
>     edited based on edits to 4.1.
>      >>
>      >> = Section 4.1 =
>      >>
>      >> If employees and contractors are both allowed, it seems like
>     mandating the specific process detailed here would not work, since
>     depending on the circumstances this might be a vendor selection
>     process or an employee hiring process or a mix of both. It seems
>     like specifying who must be involved in whatever process is used is
>     important, since that allows the community to know that the people
>     who are the appointed experts (on RSOC or selected by RSOC) will be
>     involved. But eliding the rest of the details and the language about
>     vendors and SOWs and RFPs would be needed to provide the flexibility.
>      >>
>      >> What to suggest here specifically is dependent on the intent of
>     2.1.1, per my comments above.
>      >>
>      >> spt
>      >> _______________________________________________
>      >> iasa20 mailing list
>      >> [e-mail] <mailto:[e-mail]>
>      >> https://www.ietf.org/mailman/listinfo/iasa20
>      >>
>      >
>      > _______________________________________________
>      > iasa20 mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/iasa20
>      >
> 
>     _______________________________________________
>     iasa20 mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/iasa20
> 
> 
> _______________________________________________
> iasa20 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iasa20
>