IETF Guidelines for Conduct
draft-moonesamy-ietf-conduct-3184bis-07

[Ballot discuss]
This is in a sense a really minor nit, but one that I think really needs to be fixed before the document is published, so I'm putting it in as a DISCUSS.  If the authors disagree that this is an issue, I will drop it, but I just want to make sure it actually gets discussed.  The following text was added to the security considerations, partially at my urging on the previous telechat:

  However it is to be noted that there is an
  expectation that no one shall ever knowingly contribute advice or
  text that may affect the security of the Internet without describing
  all known or foreseeable risks and threats to potential implementers
  and users.

The only problem with this is that we can only document those foreseeable risks that are successfully foreseen, not the entire set of all foreseeable risks.  The point of this text is not to insist that contributors wrack their brains indefinitely until every foreseeable risk has been foreseen, but rather that they document all risks that they have actually foreseen, and make some effort to foresee risks.  I think the best way to address this is just to change "foreseeable" to "foreseen."

[Ballot comment]
Purely a style thing, but the text is written more in the style of saying we conform to an ideal behaviour rather than the imperative that we should aim to attain a particular style of behaviour. Specifically it may be more effective to put the SHOULDs in the four points in section 2 to reinforce the requirement than in the preamble to the list.

"We follow the intellectual property guidelines outlined in BCP 79 [RFC3979]."

Recent events suggest to me that we should set a strong expectation that IETF contributors will emphasis the need of their sponsors/employers to follow these guidelines.

"However it is to be noted that there is an
expectation that no one shall ever knowingly contribute advice or
text that may affect the security of the Internet..."

Firstly, surely that should perhaps be "adversely affect...", but more importantly surely it is not just security, we expect that no one shall knowingly contribute advice or text that may harm the internet in any way.

[Ballot comment]
Thanks for taking this on.

Still balloting "Yes" on the latest revision.

Just a few Comments...

---

As Sean says, I guess 3184 can be moved to Historic at the same time.
If this is to be done, it has to be called out somewhere.
(I am now feeling that I don't care!)

---

Nits...

---

Section 1

OLD
  The work of the IETF relies on cooperation among a diverse range of
  people, ideas, and communication styles.
NEW
  The work of the IETF relies on cooperation among a diverse range of
  people with different ideas and communication styles.
END

OLD
  The IETF strives, through
  the guidelines for conduct
NEW
  The IETF strives, through
  these guidelines for conduct
END

---

Section 2 point 3

OLD
      We understand that "scaling is
      the ultimate problem"  and that many ideas quite workable in the
      small fail this crucial test.
NEW
      We understand that "scaling is
      the ultimate problem" and that many ideas that are quite workable
      on a small scale fail this crucial test.
END

---

...and an aside...
Section 3 has

  Guidelines about IETF conduct do not directly affect the security of
  the Internet.

...which (given recent claims and revelations) seems to conflict with
Section 2 point 3...

      no                                                   
      one shall ever knowingly contribute advice or text that would make
      a standard technically inferior.

I don't want to make a big thing of this, but perhaps change Section 3
to read...

  Guidelines about IETF conduct do not directly affect the security of
  the Internet, however it must be noted that there is an expectation
  that no one shall ever knowingly contribute advice or text that would
  make a standard less secure.

[Ballot comment]
I have moved back to No Record as this document has been updated quite a lot and needs a further review.

The Comment below accompanied my previous Yes and is included until I have had a chance to check out the changes.

=========


Thanks for taking this on.

Just a few Comments...

---

I would like the Abstract to note that this document obsoletes 3184 and
to provide a few words on what changes it makes. For example,

  This document brings the guidelines up-to-date and obsoletes RFC 3184.

---

As Sean says, I guess 3184 can be moved to Historic at the same time.

---

In Section 1, I wondered why you didn't also mention RFC 3683 as many
conduct issues will arise on mailing lists. Maybe...

  If conflicts arise they are resolved according to the
  procedures outlined in RFC 2026 [RFC2026] and RFC 3683 [RFC3683].

...and, yes, I do see Appendix B.

---

Section 2, point 3

      The goal of the IETF is to maintain and enhance a working, viable,
      scalable, global Internet

I don't disagree, but since 3184 was written we have BCP 95 (currently
RFC 3935), and it might be helpful to align the text by quoting and
referencing. For example...

  The mission of the IETF is to produce high quality, relevant
  technical and engineering documents that influence the way people
  design, use, and manage the Internet in such a way as to make the
  Internet work better [RFC3184].

---

Section 2, point 4

      IETF participants read the relevant Internet-Drafts, RFCs, and
      email archives beforehand, in order to familiarize themselves with
      the technology under discussion.

"Beforehand" reads oddly to me. Before what? I suppose you mean before
joining in with the discussion. It would help to clarify.

---

In Appendix C

  o  The text about "think globally" was not removed as the meaning was
      not clear.

I think s/was not/was/

[Ballot comment]
Consider the following a thought experiment... Is the Security Considerations correct given that failure to follow bullet #3 could lead to serious security issues?

[Ballot comment]
From Appendix C:
      The text about "think globally" was not removed as the meaning was
      not clear.

This doesn't make sense—I think you have one too many or one too few nots here.

The security considerations section doesn't mention the possibility that a participant failing to follow the advice in section 2, part 3 that "no one shall ever knowingly contribute advice or text that would make a standard technically inferior" can in fact result in an inadequately secure protocol specification.  I don't know if this is worth fixing, but it's something that we've been accused of in the past, so perhaps it is worth specifically calling out.

All in all, this is a significant improvement over RFC 3184, which is itself a good document.  Thanks for doing the work!

[Ballot comment]
Thanks for taking this on.

Just a few Comments...

---

I would like the Abstract to note that this document obsoletes 3184 and
to provide a few words on what changes it makes. For example,

  This document brings the guidelines up-to-date and obsoletes RFC 3184.

---

As Sean says, I guess 3184 can be moved to Historic at the same time.

---

In Section 1, I wondered why you didn't also mention RFC 3683 as many
conduct issues will arise on mailing lists. Maybe...

  If conflicts arise they are resolved according to the
  procedures outlined in RFC 2026 [RFC2026] and RFC 3683 [RFC3683].

...and, yes, I do see Appendix B.

---

Section 2, point 3

      The goal of the IETF is to maintain and enhance a working, viable,
      scalable, global Internet

I don't disagree, but since 3184 was written we have BCP 95 (currently
RFC 3935), and it might be helpful to align the text by quoting and
referencing. For example...

  The mission of the IETF is to produce high quality, relevant
  technical and engineering documents that influence the way people
  design, use, and manage the Internet in such a way as to make the
  Internet work better [RFC3184].

---

Section 2, point 4

      IETF participants read the relevant Internet-Drafts, RFCs, and
      email archives beforehand, in order to familiarize themselves with
      the technology under discussion.

"Beforehand" reads oddly to me. Before what? I suppose you mean before
joining in with the discussion. It would help to clarify.

---

In Appendix C

  o  The text about "think globally" was not removed as the meaning was
      not clear.

I think s/was not/was/

[Ballot comment]
I compared, with the rfcdiff tool, RFC 3184 and this draft, and I have to admit that I failed to see why we needed to update RFC 3184. Don't get me wrong, there are some nice text improvements and one paragraph was corrected (IPR), as mentioned in Appendix C.
The only significant changes in the diff is the addition of the the appendix A and B. The content is useful, but these are only in the appendix, so not normative, right?

Anyway, no objection.

I was surprised to see that http://www.ietf.org/tao.html doesn't refer to RFC 3184.
When this RFC will be published, the TAO should have a reference to it.

IESG/Authors/WG Chairs:

IANA has reviewed draft-moonesamy-ietf-conduct-3184bis-03, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IETF Guidelines for Conduct) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'IETF Guidelines for Conduct'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides a set of guidelines for personal interaction
  in the Internet Engineering Task Force.  The Guidelines recognize the
  diversity of IETF participants, emphasize the value of mutual
  respect, and stress the broad applicability of our work.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-moonesamy-ietf-conduct-3184bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-moonesamy-ietf-conduct-3184bis/ballot/


No IPR declarations have been submitted directly on this I-D.