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

[SM <[e-mail]>]

At 15:49 06-02-2013, The IESG wrote:
>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
>[e-mail] mailing lists by 2013-03-06. Exceptionally, comments may be

I read draft-arkko-iesg-crossarea-03 as I am trying to learn about 
the IETF.  In Section 2:

    "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."

There is an assumption that I know what "WG" means.

Editorial: I suggest within the area instead of on the area.

In Section 3:

   "Cross-area work is needed, of course, in any situation where a
    particular technical problem does not cleanly map to one
    organization."

Shouldn't that map to a working group?

In Section 4:

   "But it is also possible that concerns raised in one forum are
    not understood in another, and this can lead to an effort going
    forward after finding the "lowest bar" forum to take it up."

Brian Carpenter commented about Area Shopping in his Gen-ART 
review.  Scrolling back to Section 3, "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 problem is how to identify that working group.  I 
went to http://datatracker.ietf.org/list/wg/  to find the working 
group where I can discuss about my solution to an IPv6 problem.  I 
found "IPv6 Maintenance".  I am not sure what that group does.  As 
the problem affects IPv6 operations I picked the "IPv6 Operations" 
working group.  I post a message to the mailing list.  There isn't 
any reply.  My solution does some DNS stuff.  I try the "Domain Name 
System Operations" working group.  I keep trying various mailing 
lists until I find the "right" venue.

The actual problem is finding out what's the main topic of the draft 
within an IETF context and identifying the proper working 
group.  There should also be someone to identify related topics which 
will be useful as input for the draft to progress.  The IESG part of 
the "process" is more about identifying which working groups should 
be chartered and in which area they should fall.  The Area Shopping 
heading looks at the problem from an IESG perspective.  The "lowest 
bar" is the IETF participant's perspective.

   "A more common issue is that the different organizations typically
    have different motivations."

The Abstract mentions "challenges for the organization of the 
IETF".  Although I think I understand what "Problem Ownership" is 
about, I suspect that the reader might be confused about what the two 
paragraphs discuss about.

   "For the regular participant it is difficult to find out where there
    are important documents that would deserve more review."

It's not a matter of important documents.  I would say that it is 
about the regular participant being able to find that document which 
he/she believes is important or the subject of discussion where 
his/her input would be helpful.

Recommendation 8 is about interaction between working groups.  It 
would be good if WG Chairs could reach out to other working groups 
when a topic relates to what's in their charter.  Recommendation 9 
looks at conflicts from an area point of view.  The current 
scheduling model is based on groups the participants would like to 
attend instead of conflicts which may prevent the topics being 
discussed from the cross-area participants.  Recommendation 10 comes 
out as having 10 in the list. :-)

It took me some time to understand that the draft was about how work 
is organized in the IETF.  I didn't really understand what area means 
except that Routing Area must have something to do with router and 
Security Area must have something to do with security.  I decided to 
read the Informational reference and I learned that it is a 
management division within the IETF.

I suggest having some text in Section 1 to introduce the areas.  The 
Abstract should be aligned with the Introduction Section.   Section 2 
provides examples of cross-area work.    There aren't any examples to 
illustrate the challenges except for the AD scheduling conflict.

Regards,
-sm