This review may be of general interest.
-------- Original Message --------
Subject: Gen-ART LC review of draft-arkko-iesg-crossarea-03.txt
Date: Sat, 09 Feb 2013 14:53:50 +0000
From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Organization: University of Auckland
To: draft-arkko-iesg-crossarea.all@xxxxxxxxxxxxxx, General Area Review Team <gen-art@xxxxxxxx>
Please see attached review.
Brian
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-arkko-iesg-crossarea-03.txt
Reviewer: Brian Carpenter
Review Date: 2013-02-09
IETF LC End Date: 2013-03-06
IESG Telechat date: 2013-
Summary: On the right lines
--------
Major Issues:
-------------
> Area Shopping
I'm not entirely happy with this discussion. From the point of view of the
person trying to introducing a new topic that does indeed cross areas, it is
*inevitable* to commit the sin of area shopping. <shout>This is not a fault of
the shopper; it's the fault of the IETF for having areas in the first place.</shout>
I agree that it's the IESG's, and also the IAB's, job to resolve this when
it arises. But the current text makes it sound as if the protagonist is to
blame for bringing a cross-area problem to the IETF.
There also seems to be a missing topic, here and in the recommendations:
the importance of the BOF (and bar BOF) process, and topic review by the
IAB, in identifying cross-area topics and chartering them carefully. The
worst thing that can happen is to BOF and charter a topic within one area,
but discover later that it is in fact a cross-area topic. There are
relevant RFCs: 5434, 6771.
Minor Issues:
-------------
> 2. Examples of Cross-Area Work
>
> Many IETF efforts cross area boundaries. Some recent examples of
> such work include:
>
> o The development of a routing-protocol based bridging model. This
> work has been going on in the TRILL WG on the Internet Area and in
> parallel in the ISIS WG on the Routing Area.
A very important aspect of this example is that it *also* overlaps with IEEE work.
That scenario should surely be mentioned, at least by a cross-reference to the
various RFCs on liaisons: 4052, 4053, 4691.
> o The RENUM WG on the Operations and Management Area is addressing
> renumbering issues, but will have to work with other areas if
> changes or extensions to specific protocols are required.
The WG name is 6RENUM. In fact its charter is explicit that protocol work
will *not* be done in the WG. (The same is true of V6OPS.)
> 3. Rationale for Cross-Area Work
...
> The
> actual solution work is then taken up by the relevant technical
> community that works on the protocol that needs to be extended.
It would be useful to refer to the RFCs about extensions: 4775, 6709.
Nits
----
There are numerous errors in the choice of prepositions, e.g. "The LWIG WG on the
Internet Area", that need to be fixed during editing.