Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add text from RFC4052 Section 4 #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add text from RFC4052 Section 4 #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions draft-kuehlewind-iab-rfc4053bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -537,6 +537,51 @@ This document describes the procedure for generating and handling
The process of generating and approving transmission of liaison
statements is a matter of IETF process and is specified in [RFC4052].

# Approval and Transmission of Liaison Statements

It is important that appropriate leadership review be made of
proposed IETF liaison statements and that those writing 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
using procedures defined in [6] or its successors.

Comment on lines +547 to +549
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
All outgoing liaison statements will be copied to IETF Secretariat
using procedures defined in [6] or its successors.

For a liaison statement generated on behalf of an IETF WG, the WG
chair(s) must create a statement based on appropriate discussions
within the WG to ensure working group consensus for the position(s)
presented. The chair(s) must have generated or must agree with the
sending of the liaison statement, and must advise the AD(s) that the
liaison statement has been sent by copying the appropriate ADs on the
message.

For a liaison statement generated on behalf of an IETF Area, the
AD(s) must have generated or must agree with the sending of the
liaison statement. If the liaison statement is not sent by the ADs,
then their agreement must be obtained in advance and confirmed by
copying the ADs 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
IETF Chair, then his or her agreement must be obtained in advance and
confirmed by copying the IETF Chair on the message.

For a liaison statement generated by the IAB, the IAB Chair must have
generated or must agree with the sending of the liaison statement.
If the liaison statement is not sent by the IAB Chair, then his or
her agreement must be obtained in advance and confirmed by copying
the IAB Chair on the message.

In cases where prior agreement was not obtained as outlined above,
and the designated authority (AD, IETF Chair, or IAB Chair) in fact
does not agree with the message, the designated authority will work
with the liaison manager to follow up as appropriate, including
emitting a revised liaison statement if necessary. Clearly, this is
a situation best avoided by assuring appropriate agreement in advance
of sending the liaison message.


# Security Considerations

One of the key considerations in developing this process has been the
Expand Down
Loading