From 6cba37d81e83131d6e34b450293964ec96d6d0bb Mon Sep 17 00:00:00 2001 From: mirjak Date: Thu, 10 Oct 2024 15:28:29 +0200 Subject: [PATCH] remove language that requires sending a response fixes #2 --- draft-kuehlewind-iab-rfc4053bis.md | 54 ++++++++++++++---------------- 1 file changed, 25 insertions(+), 29 deletions(-) diff --git a/draft-kuehlewind-iab-rfc4053bis.md b/draft-kuehlewind-iab-rfc4053bis.md index 01a6b53..00cece8 100644 --- a/draft-kuehlewind-iab-rfc4053bis.md +++ b/draft-kuehlewind-iab-rfc4053bis.md @@ -26,17 +26,10 @@ 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 @@ -44,16 +37,20 @@ relationship, however. # 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.