Re: Last Call: <draft-arkko-iesg-crossarea-02.txt> (Experiences from Cross-Area Work at the IETF) to Informational RFC

[Jari Arkko <[e-mail]>]

Adrian,

Many thanks for your careful review and thoughts. A couple of follow-ups inline:

> In several places, this document is careful to state that the text
> represents the personal view of the author (Section 4 "Process vs.
> Substance", Section 5, Appendix 5).  This is fine as far as it goes, but
> leads to three issues:
>
> 1. The filename gives the impression that this is an IESG document
>     I don't believe there is any point in fixing this because once
>     published as an RFC the I-D filename is almost completely forgotten.
>
> 2. The clarity about the document being the author's personal opinion is
>     missing from the Abstract and Introduction making it hard for the
>     reader to understand this fact. This is easily fixed.
>
> 3. It is not clear what it would mean to have IETF consensus on this
>     document. Would it mean that the IETF agrees that this is the
>     author's opinion? So, please be careful to not accidentally attach
>     the "IETF consensus" boilerplate to this document if it is published
>     as an RFC. (Actually, it would be good if the IETF last call for
>     this type of document called out the "not seeking consensus" fact so
>     that the community understands what type of review they are doing
>     and how their comments will be handled.) The action here is on the
>     sponsoring AD and the IESG as the document goes for publication - it
>     would be really good to put in an RFC Editor note early so that this
>     does not get lost.

Good points. There is a more general underlying issue, how do we publish informational documents (boilerplate, last call, etc) and in particular process-related documents. I think we'll end up discussing that in the IESG more generally. Thanks for raising the issue.

FWIW, this particular document started out a couple of years ago as a documentation of the experience that we had gained at the time. It is a "Considerations on X" -type document. There is no fundamental reason why it couldn't be achieve either IESG or even IETF consensus. However, I have at least not personally been focused on that. I've been more focused on documenting observations that might be useful for readers, and publishing them as a record of thinking at the time. But there is no claim that this is all there is to say about the topic. So, if we for some reason decided that we'd want to make the document header say this has the consensus of the IETF, I'd still want to avoid making too broad claims about the document's completeness and validity in all situations.

> I would find it helpful if the Introduction gave some sort of management
> summary: Who is supposed to read / act on this document? What actions
> are they supposed to take?
>
> For example (but with no intent to constrain the author), this could be
> aimed at the wider IETF community with the intent of getting them to
> understand that it means something special for a working group to be in
> a particular area. Or it could be aimed at the IESG with a view to
> getting them to consider the implications of cross-area work on the IETF
> organisation.

The document has been mostly aimed at ADs and WG chairs, though, as pointed out in recent list discussion, other contributors may be tackling the same issues but from a different angle (which area do I submit my work?). The next version wll try to make the intended readers clearer.

> I think that the description of LWIG in Section 2 is wrong to limit the
> scope to "the TCP/IP stack and application protocols." The charter is
> far wider than that and embraces routing and operations protocols as
> well.

Will fix.

> Section 2
>
> I would suggest:
>
> OLD
>     o  The Routing Area, Transport Area, and Security Area have worked
>        together on security mechanisms and key management tools necessary
>        to secure BGP sessions carried on top of TCP.  For instance, the
>        SIDR and KARP WGs are in the Routing Area, but they are clearly
>        focused on topics that are generally found in the Security Area.
> NEW
>     o  The Routing Area, Transport Area, and Security Area have worked
>        together on security mechanisms and key management tools necessary
>        to secure routing protocols, including those carried on top of
>        TCP.  For instance, the SIDR and KARP WGs are in the Routing Area,
>        but they are clearly focused on topics that are generally found in
>        the Security Area.
> END

Good. Thanks.

> I think Section 2 should acknowledge RFC 2223 and RFC 3552 with respect
> to how security crosses into all areas.  Similarly, you should mention
> RFC 5706 with respect to how management and operations cross into all
> areas.

Good points.

> I also think the example in the last bullet of section 2 is a bit weak.
> You should probably also discuss the way that many protocol working
> groups develop data models (e.g., MIB modules), yet NETMOD is developing
> data models for protocols and entities in other areas. Similarly, you may
> want to introduce I2RS.
>
> Lastly, the same bullet is missing a discussion of OAM protocols worked
> on in protocol working groups (such as MPLS and TRILL).

OK

> The start of Section 3 seems to contradict the discussion of splitting
> work into different WGs either to share the load or to attract the right
> area participants. You say:
>
>     From an IETF participant's point of view, it is important that there
>     is a working group where the technical topic that he or she is
>     interested in can be discussed.  The area and the management
>     structure matters little for this, as long as the working group can
>     work on all of the relevant aspects.

Hmm. I'll see what I can do.

> I share some of Brian's views on "Area Shopping". The flip of what some
> may perceive as shopping is what the authors perceive as "Being pushed
> from pillar to post without anyone taking proper responsibility for
> finding the correct home for the work." The IESG has a responsibility to
> ensure that work that needs to be homed in the IETF is found a home. The
> IESG equally has a responsibility to ensure that work that does not
> belong in the IETF (for any of a number of reasons) or is not yet
> properly formed, does not "sneak in".

Right.

> The answer to this, I am afraid,
> lies in proper communication and mutual trust within the IESG.

Definitely. And some hard work to determine what the topics really are about.

> Suggestions for inclusion in Section 4 would be:
>
>     Engineers Will be Engineers
>
>     Observing that engineers will often look for an existing tool (for
>     example, a hammer) to address a new problem (for example, a screw).
>
> and
>
>     Don't Break the Internet
>
>     Some pieces of the Internet infrastructure may be considered a little
>     fragile. This understanding does not always extend beyond the working
>     group maintaining the associated technology, so there can be a real
>     tension when a working group (usually in another area) decides to use
>     the technology in a novel way without either proper discussion or
>     proper separation.

Yep. This is a very good addition.

> The piece about cross-area review is important, but is hiding in "Rigid
> Topic Ownership" in Section 4. There are three additional problems
> associated with cross-area review:
> 1. It is not clear where to send cross-area review requests
> 2. Cross-area reviews, when requested, rarely happen
> 3. The ramp-up needed to achieve a cross-area review can often be huge

Yes.

> I suspect that the recommendations concerning scheduling, while
> addressing the primary problem, do not recognise an underlying issue.
> Thus, addressing the conflicts between meeting slots in order that, for
> example, all appropriate routing experts could attend TRILL, would lead
> to a longer IETF week with fewer parallel sessions.
>
> An alternative, is to recognise that ADs are *not* the gate in
> scheduling. It is not necessary for ADs to attend even all of the
> working groups that they are responsible for. They may be interested in
> attending other working groups as well, but it is not necessary for them
> to be there.

I certainly agree.

> I also think that one of the important aspects of managing cross-area
> work goes beyond getting the language right in charters. Brian observes
> that several of the OPS working groups have charter text explicitly
> stating that "protocol development will not be done in this WG", making
> the WG responsible for problem statements, requirements, and
> applicability, and placing the responsibility for protocol development
> in other WGs often in other areas. This is great if and only if the
> charter is observed! By the time a protocol spec arrives at the IESG as
> a publication spec, it is pointless to try to control what has happened -
> the best that can be done is to send the document for wider review. What
> clearly needs to happen is for working groups to observe their charters,
> for working group chairs to be stricter, and for ADs to stay on top of
> this type of issue.
>

Yes. Another good thing to talk about.

Jari