Procedures for Handling Liaison Statements to and from the IETF
RFC 4053

Received changes through RFC Editor sync (changed abstract to 'This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.

The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.')

[Ballot discuss]
>    Liaison Statements are only exchanged within the context of
>    established liaison relationships, which are managed by the IAB.

So, does this mean we don't accept liaion statements nor send them to
organization with which we have no formal liaison agreement? I hope
this isn't true. It would be fine for this document to just cover
liaison processes for which  we've set up formal liaisons, leaving the
others out-of-scope. But this document shouldn't preclude us from
doing things on the other cases as appropriate

This document has quite a lot of tool-specific detail that I don't
think should be normative in a "BCP" sense. A BCP should reflect what
the process should be (at an appropriately high-level), with the
implementation details subject to evolvement/implementation without
having to go to a BCP (or change it to make an obvious feature change).

For example:

>    The status/management mechanism contains a simple frame, showing the
>    title of the liaison statement, the URL for its mechanism, and the
>    organizations it is from and to.

And this really goes to far:

>    As a convenience, the liaison statement page described in Section 4.2
>    may be used to generate a reply.  If an authenticated person (usually
>    a working group char or AD) selects "reply", a new liaison statement
>    page is generated from the existing one, reversing the addressing
>    information.  IETF documents should be referenced by URL, such as
>    http://www.ietf.org/internet-drafts/>file< or
>    ftp://ftp.rfc-editor.org/in-notes/>file<.

To summarize, the implementation specifics (e.g., web-based stuff)
should not be considered part of the formal BCP.

>    The process of generating and approving transmission of liaison
>    statements is a matter of IETF process, and is specified in
>    [I-D.iab-liaison-mgt].

This seems at odds with the discussion throughout this document as to
how to respond to liaison statements. Or is this sentence just
focusing on the narrow question of the mechanics of sending a
completed statement? Also, this is a bit confusing given the
"authenticated" discussion in 5.2.4, which seems to imply that the
official response is what gets posted on the web page.

>    processes.  Historically, the IETF has not handled liaison statements

s/has not/has not always/

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

this text again seems to make it clear that the automated tools are a
big part of this document.

AD Review comments:

- Title: "Procedure for Handling Liaison Statements Between Standards Bodies" seems a bit grandiose (3GPP to ITU?). "Procedures for handling liaison statements to and from the IETF" might be better.

- Abstract: Liaison Statements only within established liaison relationships - this increases the pressure to establish such relationships. Clarify later?

- Section 2: "generally the purpose is to solicit information, comment, or action". Unclear how the verb binds - do you intend "solicit information, solicit comment or solicit action", or do you intend "solicit information, make a comment or request an action"?
2.1.1.6 seems to indicate "give information, solicit comment or request action", which is not consistent with the sentence as written.

- 2.1.1: I don't understand "meta-statements regarding". What about "properties of"?

- Section 3: It is not clear to me when a response is a returning liaison statement and when it is not - in some cases, like a "thank you" note, it seems clearly informal.

- Section 4.2 mentions "recently closed" liaison statements. I think they should be permanently archived - but the very old archives don't need to be "in your face"....

- Section 5.2 regarding replies: the case of nobody bothering to comment within a reasonable period may warrant mention. In that case, the chair should be able to say "no interest in WG on the isuse".

- I am somewhat worried about Appendix A and B being seen as "normative" when this goes forward as a BCP. I would like to either put in a note saying that these are "for information, may be modified later without notification", or a note saying that these are present to inform the debate at Last Call, and will be removed from the published RFC.

No showstoppers for a Last Call that I can see.