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