remove language that requires sending a response

fixes #2

draft-kuehlewind-iab-rfc4053bis.md

@@ -26,34 +26,31 @@ informative:
 
 --- abstract
 
-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 describes the procedure for generating and handling
+liaison statements between the IETF and other SDOs, so that IETF can
+effectively collaborate with other organizations in the international
+standards community. 
 
 
 --- middle
 
 # Introduction
 
 This document describes the procedure for generating and handling
-   liaison statements between the IETF and other SDOs, so that IETF can
-   effectively collaborate with other organizations in the international
-   standards community.  These liaison statements are primarily
-   exchanged between IETF and organizations with whom the IAB has
-   created a liaison relationship (see {{?RFC4052}}), although other
-   organizations are not precluded.  The procedures described in this
-   document encompass all liaisons statements received from SDOs,
-   whether or not a formal liaison arrangement is in place between the
-   SDO and the IETF.  The IETF is not obligated to respond to the
-   liaison statement where there is no formal liaison arrangement.
+liaison statements between the IETF and other SDOs, so that IETF can
+effectively collaborate with other organizations in the international
+standards community.
+
+Exchange of liaison statements does not require a formal liaison
+relationship (see {{?RFC4052}}).  The procedures described in this
+document encompass all liaisons statements received from SDOs,
+whether or not a formal liaison arrangement is in place between the
+SDO and the IETF. Receive of a liaison statement does not automatically
+impose an obligation of sending a response by the other party. The decision
+to send a response depends on the content and kind of request. However,
+if a formal liaions relationship exists it is the responsibility
+of the liaison manager to ensure appropriate communication
+between the orginiation(see {{Section 3 of RFC4052}}) even if no response in sent.
 
    The implementation of the procedure and supporting tools is occurring
    in a minimum of three phases.  The initial phase has been the
@@ -451,11 +448,10 @@ This document describes the procedure for generating and handling
 ###  Responding to Incoming Liaison Statements
 
    Any incoming liaison statement that indicates that it is for
-   "Comment" or for "Action" requires a response by the deadline; other
-   liaison statements may also be replied to, although a reply is
-   generally optional.  It is the responsibility of the (co)chair(s) of
+   "Comment" or for "Action" requires a response by the deadline.
+   It is the responsibility of the (co)chair(s) of
    the addressed organization to ensure that a response is generated by
-   the deadline.
+   the deadline if a respone is intended.
 
 ####  Responding to Requests for Information
 
@@ -476,8 +472,8 @@ This document describes the procedure for generating and handling
 
    If no clear consensus is evident from the pattern of comments on the
    mailing list, or if there is no further discussion, a response is
-   still due to the originator.  A summary of the email comments, or
-   lack of interest in the issue, should be created and sent to the
+   still anticipated to the originator.  A summary of the email comments, or
+   lack of interest in the issue, can be created and sent to the
    originator, and represented as "collected comments" rather than a
    consensus of the IETF group to which the liaison statement was
    addressed.  It is possible to send this kind of a reply even if some
@@ -505,7 +501,7 @@ This document describes the procedure for generating and handling
 
    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
+   generally a response is anticipated.  The originating organization should always be
    informed of what, if anything, the IETF has decided to do in response
    to the request.  If the IETF decides not to honor the request, or to
    honor it with modifications, the response should include the reasons
@@ -514,7 +510,7 @@ This document describes the procedure for generating and handling
    For tasks that require a great deal of time, it may be necessary that
    several liaison statements be sent back to the originating
    organization to report the status of the work and the anticipated
-   completion time.  The first of these liaison statements must be
+   completion time.  The first of these liaison statements should be
    generated by the deadline indicated in the incoming liaison
    statement.