Hi,
Here are some comments resulting from my reading of draft-arkko-iesg-crossarea.
I chose to review the -03 version.
Hope they are useful.
Adrian
===
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.
---
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.
---
Nit:
Several s/on the foo area/in the foo area/
---
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. (For some reason the security area escapes attention in the
charter although there is an I-D for TLS).
---
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
---
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.
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).
---
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.
---
Nit
Section 3
Cross-area work is needed,
of course, in any situation where a particular technical problem does
not cleanly map to one organization.
s/organization/area/
---
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". The answer to this, I am afraid,
lies in proper communication and mutual trust within the IESG.
---
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.
---
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
---
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.
Similarly, while there are some high-level conflicts to avoid (TRILL
against ISIS), other conflicts are a nuisance for a few people rather
than a major problem for the IETF.
---
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.
> -----Original Message-----
> From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce-
> bounces@xxxxxxxx] On Behalf Of The IESG
> Sent: 06 February 2013 23:50
> To: IETF-Announce
> Subject: Last Call: <draft-arkko-iesg-crossarea-02.txt> (Experiences from
Cross-
> Area Work at the IETF) to Informational RFC
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Experiences from Cross-Area Work at the IETF'
> <draft-arkko-iesg-crossarea-02.txt> as 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@xxxxxxxx mailing lists by 2013-03-06. Exceptionally, comments may be
> sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.