[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IAB comments on draft-baker-liaisons-00.txt
Howdy,
The IAB did review and discuss draft-baker-liaisons-00.txt.
The upshot is that there were some comments and significant
concerns that individual IAB folks (myself, Geoff) found, that
many other IAB members seemed to feel resonated with their own.
I've included those comments below, and cc'ed the IESG as Geoff's
comments points out some of this is theirs to define.
Leslie.
[Leslie Daigle's comments:]
A meta-comment: I understand that we have a problem in the shape
of keeping track of liaisons that we do receive from other organizations,
clearly identifying the appropriate receiving party and expectations
of responses. However, this seems to provide little guidance on how
we might go about determining the appropriate party (so that
liaising bodies can have some sense of our "API" as it were).
Rather, in some way seems to be an elaboration of a new (and
separate) communication channel, without solving those basic problems.
2.1.6 Purpose:
While others are possible, a liaison generally has one of three
purposes, and will clearly state its purpose using one of these
labels:
There are 4 labels listed (including "In Reply").
2.2 Addressee Responsibilities
[snip]
Liaisons are always important to the body that sent them. Having
arrived at the appropriate body, the liaison may be more or less
important to the addressee depending on the contents of the liaison
and the expertise of the sender. If the liaison seeks to influence
the direction of a working group's development, it should get the
same consideration that any temporary document receives. The working
group chair may request the sender's contacts to make their case to
the IETF working group in the same manner and on the same basis that
an internet draft author makes his case.
This seems to open the door to suggesting to other SDOs that they
don't need to interact with the IETF the same way as all individual
participants of the IETF -- through I-Ds. Also, working group chairs
can determine whether or not a WG wants to accept an I-D as
a working group item -- it's not entirely clear that this right
extends here.
I.e., I'm not entirely sure how we made the leap from "business
letter" analogy to something that the IETF WG will consider as
seriously as an I-D (for which we have crafted management processes
over the last N years).
3. Liaison Statements from other SDOs, Consortia, and Fora to IETF
The process of handling a liaison statement is a little heavier than
the handling of a business letter, however, because the organizations
and issues are heavier. To manage liaison statements, the IETF will
offer three web-accessible facilities: a form for submission of
liaison statements, a web page organizing their contents and making
them accessible, and a tracking system.
This section is un-motivated (in this document) -- the document
doesn't make it clear why this much administration is necessary, why
take this particular approach to administration? The process mechanics
are even greater than I-D's, which are our core tool for handling
our internal work.
It is my understanding that we have always encouraged other SDOs to
interact with the IETF through our existing processes (mailing
lists, Internet-Drafts, etc), and we have understood that we
have to learn the formalisms of other organizations in order to
interface successfully with them. As it stands, this seems like
a large step back from that -- why try to figure out the Internet-Draft
process, when it's possible to stick to the more familiar (for
some SDO's) liaison format and liaison relationship style?
A meta-comment about Section 4, with some other particular
comments in-line...
The meta-comment is: this is useful advice (or guidelines) for IETF
participants; however, I'm concerned that, as phrased, it seems to
be *prescriptive* -- IETF participants (and other SDOs expecting
to receive liaisons from the IETF) will perceive it as providing
*the* set of processes whereby communications may be expected.
What we really need are: clear guidelines to direct incoming liaisons
to the relevant parties, clear mechanisms for identifying that
IETF liaison originators are indeed capable of speaking on behalf
of the body they are representing (WG, Area, IETF), and some
expectation setting about what that means (e.g., a WG may have
consensus that the IETF as a whole disagrees with; WG's are not
exclusively authoritative on their topics, which is something that
other SDOs might find confusing).
4. Communicating IETF information to other SDOs, consortia, and fora
This includes liaisons sent in reply to liaisons sent by other
bodies, and liaisons being sent by the IETF.
4.1 Spontaneously generating Liaisons to other organizations
Liaisons can be generated at a WG, Area, or IETF level to another
organization. The respective (co)chair(s) are responsible for judging
the degree of consensus for sending the particular liaison and what
the content should be. The amount of consensus required to send a
liaison statement varies greatly depending on its content. This
section gives some rough guidance about how much consensus should be
sought before sending a liaison statement to another organization.
4.1.1 Transmitting IETF documents to other organizations
The simplest case of approving sending of a liaison from IETF is
where the information that is being transmitted consists of an IETF
document that has some level of agreement within the IETF. The
process that the document has already gone through to achieve its
current status assures the necessary level of consensus. Any
Standards Track RFC (Draft Standard, Proposed Standard, Internet
Standard, BCP), and any working group document expected to be placed
on the standards track, may be transmitted without concern.
Informational documents may also be exchanged readily when they
represent a working group position or consensus, such as a
requirements or architecture document.
In all cases, the document status must be appropriately noted. In the
case of a Working Group Internet Draft, it must be clear that the
existence of the draft only indicates that the Working Group has
accepted the work item and, as the standard disclaimer says, the
actual content can be treated as nothing more than Work in Progress.
Individual Internet Drafts, Experimental or Historical RFCs, and
non-working group informational documents should not be transmitted
without developing further consensus within the relevant group, as
these documents cannot be truthfully represented as any kind of IETF
position.
4.1.2 Requests for Information
Another type of liaison that can be generated without the need for
extensive consensus building on the email list is a request for
information. The (co)chairs(s) can generate such a liaison when they
recognize from the activities of the group that some additional
Trowbridge, et al. Expires December 18, 2003 [Page 9]
Internet-Draft Handling of Liaison Statements June 2003
information would be helpful, for example, to resolve an impasse
(i.e., don't waste time arguing over what the real meaning or intent
of another SDOs document is, just ask the other SDO and base further
work on the "official" answer).
Other requests for information may be to request access to certain
documents of other organizations that are not publicly available.
4.1.3 Requesting comments on Work in Progress
There may be cases where people feel that a document under
development in the IETF would benefit from the input of experts in
another relevant SDO, consortium, or forum. Generally, this is done
before the text is "fully cooked" so that input from experts in
another organization can be included in the final result. Comments
would generally be solicited for a standards track working group
Internet Draft and some level of consensus should be reached on the
working group or other open mailing list that it is appropriate to
ask another organization for comments on an IETF draft.
BTW, what are the expected results? Participation of members of the
other SDO in the IETF WG in question? Or a response from the other
SDO saying we (SDO organization) think this, that, and the other thing
are wrong? (I.e., in the form of a liaison from the SDO "for action"
on our part, which (per the above) has to be handled as formally
as an Internet-Draft). The latter would be inconsistent with (what I
understand to be) our standing policy that we don't favour group input,
but rather individual technical debate. This proposal should be clear
about that, so as not to set up different expectations on the part
of another SDO.
4.1.4 Requests for Other Actions (besides comments on IETF drafts)
There are a number of other kinds of actions that might reasonably be
requested of another organization:
o In the case of overlapping or related work in another
organization, a request could be made that the other organization
change something to align with the IETF work.
o A request could be made for another organization to start a new
work item (on behalf of IETF).
o A request could be made for another organization to stop a work
item (presumably because it overlaps or conflicts with other work
in the IETF).
These sorts of requests are quite serious. They can certainly be made
where appropriate, but these kinds of requests should only be made
where there is the clearest possible consensus within the particular
Working Group, Area, or within the IETF at large.
For this not to be advice, but rather to be successful as a prescriptive
document, some notion of *who* is responsible for posing the question
and determining the consensus would be necessary.
4.2 Responding to Incoming Liaisons
Any incoming liaison that indicates that it is for "Comment" or for
"Action" requires a response by the deadline; other liaisons may also
be replied to, although a reply is generally optional. It is the
responsibility of the (co)chair(s) of the addressed organization to
make sure that a response is generated by the deadline.
Trowbridge, et al. Expires December 18, 2003 [Page 10]
Internet-Draft Handling of Liaison Statements June 2003
4.2.1 Responding to Requests for Information
If another organization requests information that can be found in an
IETF document of the types indicated in Section 4.1.1, this can be
transmitted by the (co)chair(s) of the addressed group, indicating
the level of agreement for the relevant document.
Level of agreement? Do you mean "status"?
4.2.2 Responding to Requests for Comments
If an incoming liaison requests comments on a document from another
organization, a discussion will occur on the mailing list where
participants can provide their comments.
If a clear consensus is evident from the pattern of comments made to
the mailing list, the (co)chair(s) can summarize the conclusions in a
reply liaison back to the originating organization.
If no clear consensus is evident from the pattern of comments on the
mailing list, a response is still due to the originator. A summary of
the email comments can be created and sent to the originator, and
represented as "collected comments" rather than as a consensus of the
IETF group to which the liaison was addressed. It is possible to send
this kind of a reply even if some of the comments are contradictory.
4.2.3 Responding to Request for Action
A request for Action is a fairly serious thing. Examples of the kinds
of actions that may be expected are:
o In the case of overlapping or related work in another
organization, another organization may request that the IETF align
its work with that of the other organization.
o A request could be made for IETF to undertake a new work item.
o A request could be made for IETF to stop a work item (presumably
because it overlaps or conflicts with other work in the
originating organization).
Consensus of the receiving group within IETF is clearly necessary to
be able to fulfill the request. Fulfilling the request may require a
great deal of time and multiple steps, for example, if initiating or
stopping a work item requires a charter change.
There is, of course, no requirement that IETF perform the action that
was requested. But the request should always be taken seriously, and
a response is required. The originating organization must always be
informed of what, if anything, the IETF has decided to do in response
Trowbridge, et al. Expires December 18, 2003 [Page 11]
Internet-Draft Handling of Liaison Statements June 2003
to the request. If the IETF decides not to honor the request, or to
honor it with modifications, the response should include the reasons
and, if applicable, the alternate course of action.
For tasks that require a great deal of time, it may be necessary that
several liaisons be sent back to the originating organization to
report the status of the work and the anticipated completion time.
The first of these liaisons must be generated by the deadline
indicated in the incoming liaison.
4.2.4 Tool for generating liaisons
The liaison page described in Section 3 may be used to generate a
reply. If an authenticated person (usually a working group char or
AD) selects "reply", a new liaison page is generated from the
existing one, to send the reply using. The "reply-to" email address
is used as a target rather than the selection of working groups and
areas, and the selection of working groups and areas is displayed as
a "from" field. In the case that the IETF is originating the liaison,
the appropriate target must be.
4.3 Approval and Transmission of Liaison Statements
It is important that appropriate leadership review be made of
proposed IETF liaison statements and that those who write such
statements who claim to be speaking on behalf of IETF are truly
representing IETF views.
All outgoing liaison statements will be copied to IETF Secretariat by
the liaison page.Copying liaison statements to the Secretariat is to
ensure posting of the outgoing liaison statements as described in
section 5.
For a liaison statement generated on behalf of an IETF working group,
the working group chair(s) must have generated, or must agree with
the sending of the liaison statement, and must advise the Area
Director(s) that the liaison statement has been sent by copying the
appropriate Area Directors on the message.
For a liaison statement generated on behalf of an IETF Area, the Area
Director(s) must have generated or must agree with the sending of the
liaison statement. If the liaison statement is not sent by the Area
Directors then their agreement is indicated by copying the Area
Directors on the message.
For a liaison statement generated on behalf of the IETF as a whole,
the IETF Chair must have generated or must agree with the sending of
the liaison statement. If the liaison statement is not sent by the
Trowbridge, et al. Expires December 18, 2003 [Page 12]
Internet-Draft Handling of Liaison Statements June 2003
IETF Chair then his or her agreement is indicated by copying the IETF
Chair on the message.
4.4 Indication on Outgoing Liaison Statements about how to Respond
All outgoing liaison statements should indicate how to respond. This
is standard text which can be appended by the secretariat when the
liaison statement is sent. This text should read:
Please send any responses to this liaison statement via email to
statements@ietf.org, indicating
Attention: (xxx Working Group)|(xxx Area)|IETF
Trowbridge, et al. Expires December 18, 2003 [Page 13]
Internet-Draft Handling of Liaison Statements June 2003
And, finally:
5. Security Considerations
One of the key considerations in developing this process has been the
possibility of a denial of service attack on the IETF and its
processes. Historically, the IETF has not handled liaisons
effectively, resulting in people working in other organizations
becoming frustrated with it. Various organizations have also used the
liaison process to attempt to impose deadlines on IETF activities,
which has been frustrating for all concerned - the IETF because it
does not accept such, and the other organizations because they feel
ignored.
This is the reason that the submission process is automated, and
restricted to authenticated submitters. While the IETF cannot
rate-limit the submitters it authenticates, it can control who it
authenticates, and it can manage its internal pipelines.
But, creating the mechanism that encourages other groups to
fill those piplelines seems to be an opportunity to raise
expectations about our responsiveness in ways we may not intend.
Which suggests that we will seem to be *more* failure-prone
in servicing our extra-IETF communications, which ulitmately
is damaging to our relationships with those organizations.
[Geoff Huston's comments:]
Overall comment:
EVERYWHERE the word "liaison" appears on its own, replace it with
"liaison communication", and everywhere "liaison statement" appears
in the document, replace it with "liaison communication"
i.e. cut the scope of the document to explicitly refer to communications
between the IETF and bodies where there exists a current liaison agreement.
Second comment:
The document needs to explicitly tag the observation that a liaison communication is distinguished from an individual contribution on the basis that it comes from a
body where the IETF has a formal liaison arrangement in place (as approved
by the IAB) and the communication is encompassed within the scope of
matters described by the liaison agreement.
Third comment:
All liaison communications must pass through the IETF Secretariat
(ingoing and outgoing) and their contents recorded on a public web page
at this point. i.e. this is not a cc: function. The communication must
pass through the Secretariat. Its organizational correspondence,
not casual email.
Outgoing communications will be passed to the nominated POC of the
liaising body (normally its Secretariat), as noted in the relevant
liaison agreements. Any explicit drop copies address to individuals or
functional areas of the liaising organization , etc shall be the responsibility
of the receiving organization. The manner of IETF generation of outgoing
communications shall be undertaken according to processes defined by the
IESG.
Incoming communications will be managed by the Secretariat according to
processes defined by the IESG.
Last Comment
Parts of this draft appear to be useful input to the IESG in terms of their
role in defining how to handle the management of these communications
(both IN and OUT). Other parts appear to be getting into the area
of extraneous definition (e.g. 2.1, 4.1.3)
--
-------------------------------------------------------------------
"Reality:
Yours to discover."
-- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------