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

From: SM <[email-masked]>
Date: Sat, 09 Feb 2013 11:36:37 -0800

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
>[email-masked] 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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Feb 2013 03:57:38 -0700

SM,

Many thanks for your feedback.

I will incorporate your suggestions and few other people's comments in a new version of the document.

Some further discussion on a couple of points that deserve it:

> I read draft-arkko-iesg-crossarea-03 as I am trying to learn about the IETF.  In Section 2:
>
> 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. 
> 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.

Admittedly, the document was written from the perspective of the IETF managers (ADs, WG chairs) but comments from you and Brian have led me to understand better that we need to include more about the participant aspect as well.

> Shouldn't that map to a working group?

Normally, yes, but I could imagine topics that are wider than one working group but still within an area.

> 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 best place to find out what topics belong under a working group is within the charter page, e.g., http://tools.ietf.org/wg/<somewg>/charters (although for some working groups, particularly long-lived generic groups such as v6ops, 6man, dhc, etc. the charter usually does not outline the specific current work items). The working groups chairs are helpful and also usually quite knowledgeable about what is going on in the IETF even outside their own groups, and can help you find the right venue.

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

Right.

Jari

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 10 Feb 2013 17:17:30 +0100

Reply to your request dated 07/02/2013
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 10/02/2013

Reviewer Comment #AB1: I-D Overall Idea and Aim
++++++++++++++++++++++++++++++++++++
I support strongly the idea-work but not publication, the draft needs
to be completed (i.e. the aim was not targeted well). The work should
involve the IESG, or analysis of process procedures in IETF including
IESG. A survey of the IESG members' opinion will help the work value.

I don't think a description of the examples/problem/challenges and
giving recommendation is enough for this work. I recommend the draft
adds analysis of process of the IETF best practices. From the draft we
may understand that our best practices are not recommended, the author
does not mention related RFCs and other BCPs than RFC2026 (is it the
only related document?).

AB> the abstract should include that the draft is the authors opinion,
it was only mentioned in acknowledgement.
AB> Questions> What is missing in IESG? how they have no strategy?
very strange to me to read the section related to IESG without any
reference or history? Is the document based on the author's point of
view, not mentioned in Abstract how he evaluated the
processes/problem?

AB> The author should mention that he is a member of IESG and for how
long with dates at least. I recommend more referencing or reasons why
author beleives that. The reviewer does n't consider all the author
beleives only if reads the proof/reference reason.

This will not be the last message, will continue,

Regards
AB
---------------------------------------------------------------------------------------
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---------------------------------------------------------------------------------------

On 2/7/13, The IESG <[email-masked]> wrote:
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This memo discusses the reasons for IETF work on topics that cross
>    area boundaries.  Such cross-area work presents challenges for the
>    organization of the IETF as well as on how interested parties can
>    participate the work.  The memo also provides some suggestions on
>    managing these challenges.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-arkko-iesg-crossarea/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-arkko-iesg-crossarea/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 10 Feb 2013 19:59:37 +0100

Reply to your request dated 07/02/2013
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 10/02/2013
Reviewed I-D -03 (latest)
Reviewer Comment #AB2: Rationale for Cross-Area Work
++++++++++++++++++++++++++++++++++++
The section 3 explains cross areas but involves the security which the
reviewer disagrees. Security is already discussed and examined in all
areas separately but in the Security Area it is discussed crossly or
specifically, we may think that security experts are already experts
of different areas in IETF. The reviewer beleive in IETF separate
areas as separated TCP/IP model layers, or Internet-Networks. However
comments for I-D's section 3 below;

>Section 3: Rationale for Cross-Area Work

>The area and the management structure matters little for this, as long as the working group can work on all of the relevant aspects.

AB> not sure why cross-area WG, why not Cross-area Area (e.g. for
Security we already have), it is more related to crossing areas, the
I-D is discussing cross areas not cross WGs. The cross-area Area can
have a general cross-area WG, and specific cross-WGs

>different groups of people at the IETF.

AB> different Working Groups, people in IETF are equal not different

>In other cases different types of individuals may have specific
expertise that is helpful to solve a problem.

AB> IETF has equal individuals, but they have different type of
experiences and different responsibilities.

>Another common example of a situation where two different areas of
expertise are needed is developing security features for a protocol.
The protocol specialists are needed to understand the application and
its requirements and the security specialists are needed to help with
understanding the possible security issues and potential solutions.
Such work is commonly not organized as cross-area work, however.

AB> outside the IETF structure, security concerns/issues are already
considering to crossing TCP/IP layers, however, I disagree that we
involve it as a cross-area WG, because IMHO in IETF the Security Area
SHOULD already be considering cross-ietf-areas.

AB> Why all Works/Documents in IETF MUST consider a Security Section?
It is already an IETF practice. The answer may be because this field
of experts is involved within all IETF Areas and future technologies.

Regards
AB

---

From: SM <[email-masked]>
Date: Sun, 10 Feb 2013 13:11:05 -0800

Hi Jari,
At 02:57 10-02-2013, Jari Arkko wrote:
>Admittedly, the document was written from the perspective of the 
>IETF managers (ADs, WG chairs) but comments from you and Brian have 
>led me to understand better that we need to include more about the 
>participant aspect as well.

It's difficult to reconcile the two aspects.  The draft can end up 
being less effective.  I think that it is your individual perspective 
which brings value to the document.

>working group but still within an area.

My opinion is that topics can be wider than one working group and 
they can spill over other areas (cross-area).

Regards,
-sm

---

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Feb 2013 17:04:14 +0100

Hi Jari,
Hi Jari,

Thanks for your draft.
A couple of points.

1.

    Cross-area work does present some challenges, however.  Apart from
    the advisor model there are no established practices and the
    processes and division of responsibility differs from case to case
    [RFC2026  <http://tools.ietf.org/html/rfc2026>].

Regarding "there are no established practices", I would stress the 
directorate process. Not really processes in the sense of RFC 2026, but 
pretty useful for cross area work.

For example, for MIB doctors, see 
http://www.ietf.org/iesg/directorate/mib-doctors.html

    All MIB documents will be passed by a MIB doctor reviewer before
    they will be approved by the IESG. The MIB doctor review must be
    done after the Working Group Last Call and before the IETF Last
    Call. ADs and WG chairs responsible on I-Ds that include MIB
    documents should ask the OPS ADs for a MIB review as soon as the
    document completed WGLC.

For example, for the YANG doctors, see 
http://www.ietf.org/iesg/directorate/yang-doctors.html

    All YANG documents will be passed by a YANG doctor reviewer before
    they will be approved by the IESG. The YANG doctor review must be
    done after the Working Group Last Call and before the IETF Last
    Call. ADs and WG chairs responsible on I-Ds that include YANG
    documents should ask the OPS ADs for a review as soon as the
    document completed WGLC.

For example, the performance metrics directorate, see 
http://www.ietf.org/iesg/directorate/performance-metrics.html
Note that this directorate is a relatively new directorate, so the 
"process" is still debated

Etc... I can tell you that that "IPFIX doctors" is about to be put in place.

As an OPS AD, I'm trying to make sure that the OPS-related directorates 
have a clear documentation containing: the directorate goal, the 
"process", the benefits, the guidelines, etc...
2.

       part of the problem here is
       that IESG does not normally develop a master plan, but rather
       individual documents and charter proposals are brought to the IESG
       in a piecemeal fashion, one by one.  This makes it hard to see
       bigger trends and possibilities for colliding work.

I'm not sure if the master plan is the primary problem. At the time of 
the charter creation, discussions regarding the work division between 
different WGs take place. However, along the time, different WGs take 
different directions. And there, the master plan might fall apart. So I 
would say the problem is the lack of revisiting the existing charters/WG 
new directions on regular basis.
Somehow, my comment relates to a sentence I see later in the draft:

       Periodic review and re-assessment is healthy and encouraged.

3.
Jari, you mentioned in one of the emails: "The document has been mostly 
aimed at ADs and WG chairs"
Out of the 10 recommendations, some don't give me a clear advice. I can 
only say: "sure, that is common sense!"

    7.   The best examples of successful cross-area work involve
         combining two pieces of expertise, with both parties having an
         incentive to complete the work.

4.
Potentially, out of the 10 recommendations, you could flag the ones that 
might require some sort of process improvements.
For example:

    10.  In general, the ability to associate work with all the areas
         that it relates to will be helpful not just for scheduling, but
         also for participants following an area of work, review teams,
         and so on.

Regards, Benoit

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Feb 2013 20:22:21 -0700

Hi Jari, although I was asked to complete an AppsDir review of this
document, on reading it several times I realized that my feedback is
more personal and less from the Apps Area perspective, so I am sending
a more general message.

On 2/6/13 4:49 PM, 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

Section 3 begins:

   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.

I'm not convinced that IETF participants really care whether the
institutional machinery of WG formation has been put in place. In my
experience, a fair amount of interesting work has happened outside of
any WG (e.g., Jeff Hodges and I worked on RFC 6125 on a
special-purpose IETF mailing list, not in a WG). As long as there's
some kind of venue, discussion can occur.

A related note on the following sentence in Section 1:

   If the work is
   interesting, the necessary people come to the meetings and work on
   the specifications.

Well, meetings (in the sense of WG sessions, or even IETF meetings)
aren't truly necessary if there is some other appropriate venue available.

IMHO, Section 2 could benefit from examples of cross-area work
involving RAI and Apps. Current and recent WGs include PRECIS (with
involvement from Apps, RAI, Security, and Ops/Mgt), ALTO (straddling
Apps and Transport), OAUTH (straddling Apps and Security), CORE (in
Apps but with close connections to 6lowpan in Int), PAWS (it was an
open question whether it would end up in Apps or Ops/Mgt), and current
efforts to define multi-stream support in MMUSIC, CLUE, and RTCWEB.
The Apps and RAI AD can probably provide further insight here.

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.

Is an IETF area truly an "organization"? Isn't the organization here
the IETF?

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.

By "forum" you seem to mean "IETF area".

OLD
      Similarly, requests for cross-area review are relatively
      infrequent or sent only to a particular subset of people in an
      area (such as a directorate).
NEW
      Similarly, requests for cross-area review are relatively
      infrequent or sent only to a particular subset of people in an
      area (such as a directorate or related working group).

I tend to agree with Benoit that the scope of, and audience for, the
suggestions in Section 4 are not particularly clear. Unfortunately, I
do not yet have actionable suggestions for improvement.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/