IETF Operational Notes
draft-alvestrand-ipod-03

[Ballot comment]
The IESG wiki page is noticably absent in section 5 (I don't consider the discussion on "Web Pages" to accurately reflect the wiki pages). For fairness sake, it should probably be mentioned.

[Ballot discuss]
I originally expressed concern about this:

  Old versions MAY be published in the draft store, but all drafts will
  be deleted from it when the document is approved.

This was updated to:

  Old versions MAY be published in the draft store, but there's no
  requirement that they remain available indefinitely.  Experience will
  show what the best policy for draft retention is.

This answers part of the concern, but not all.  I believe that tracking the evolution
of the drafts will be key to evaluating the experiment.  During the course of the
experiment, in other words, I am asking that they all be retained, and that we determine
afterwards whether this is the best long term policy. 

In Section 3, the following text was added to the list of documents which might be
split:

  If someone wishes to do such a split while the experiment is running,
  the BCPs cannot refer to the "procedures" documents as IONs, since
  the concept of an ION may go away.

That would constrain the results of the ION experiment such that, should it fail,
all of those procedure documents would become other kinds of documents which
are suitable for reference by a BCP.    Given that one normal result of such an
experiment might be to drop the whole thing, doing this midstream just doesn't
seem workable.  Put another way, I do not believe you can do this to BCPs without
a permanent document series, and IONs are not permanent until the experiment
has been judged a success.

IANA Last Call Comments:

This document has no IANA considerations,

BUT: This document defines a new document publication trac, for operational
information about protocols. The document as is does not explicitly say if these documents canb have IANA consderations or not. (I think the intent is that the document can not specify any new items but may encourage or discourage use of certain protocol features).

The question is: Does IANA want an explicit statement about this document
publication trac that NO IANA actions can be included in these documents.

[Ballot comment]
Just an observation on the IESG comments on this .... they seem very much like the type of comments that are typical come up in a WGLC. You could take this mean I think we should all go join the WG if we care, but I don't mean that. You take this mean how did this document get here like this, but I don't mean that. You could take this to mean we are applying to wrong level of standard to evaluation of this document, but I don't mean that either. Really I have no idea  what this means - it's just an observation on the comments.

[Ballot discuss]
It wasn't clear to me why this:

  Old versions MAY be published in the draft store, but all drafts will
  be deleted from it when the document is approved.

is a useful thing to do during the experimental phase.  One of the key questions for me is whether this series will generate work and for whom.  Tracking the evolution of the drafts would be a valuable way for us to discover how much effort (or churn) goes into the process over the 12 months.  Deleting them longer term may make sense, but I'm concerned about doing it during the experimental phase.

The document says:

The existence of the ION series may cause the following documents to
  be split into a "policy and principles" BCP and a "procedures and
  boilerplate" document published as ION:

  o  IETF Rights in Documents (currently BCP 78)RFC3978 [RFC3978]

  o  IETF Rights in Technology (currently BCP 79)RFC3979 [RFC3979]

  o  IETF mailing list management (currently RFC3005 [RFC3005], BCP 45,
      RFC3683 [RFC3683], BCP 83, and RFC3934 [RFC3934], BCP 94)

Certainly this cannot happen during the course of the experiment, since IONs might subsequently disappear.  It also cannot be done by ION for the subordination reasons already given.  So this seems be a question that  must be handled in the context of Section 4 (success criteria) and the BCP it suggests be written if this is deemed a success.  I suggest moving this section there as a potential action of the success, and deleting it from this list.

In Section 4, is it reasonable to expect that the IESG of the time could determine that this just makes too much work in its current form, and that having the IESG be the approver/appeals chain for this doesn't work?  If so, should this document reflect that potential outcome, or is it appropriate to leave that for those formulating the question to the community?

[Ballot comment]
In the Introduction, the document says:

The document series defined here is strictly subordinate to the IETF
  process rules that are defined in currently valid BCP documents.

Later, the document uses this language:

  Procedurally, an ION has the formal authority of a statement from its
  approving body.  This means that an ION cannot change those
  procedures of the IETF that are documented via the BCP series, since
  the BCP series represents a determination of IETF consensus.

I think the second statement is much clearer, and I recommend either removing the first statement or re-using the terms of the second statement.

The document says this:

    An updated ION will normally be approved by the same body that
  approved the previous version, or by another body with the approval
  of the previously-approving body.  In case of conflict, or when the
  previous body no longer exists, the IESG gets to decide who gets to
  approve an updated ION.

If an ION changes approvers, I personally think it would be cleaner for the old one to be retired using the draft's mechanisms and a new one issued. This gets around the question of what it takes to indicate approval of a change in approving body (there are lots of sensible possibilities, but this seems likely to be rare, so I'd suggest just using a re-issue).

I think having the format question (use of web pages, etc.) mixed up with this is going to muddy the waters.

[Ballot comment]
I am concerned about the impact of this experiment on the IESG load. In order for the experiment to be conclusive we need at least a healthy bunch of IONs to make it through the process, we need to write and approve IONs for IONs, we need to share at least the load of one document with each of the other organizations that may own IONs, we need to formalize the way conclusions and draw recommendations. This looks like a lot of work.

I am also concerned that rather simple procedural sets of rules that were previously solved or could have been solved through a wiki page will go now through a full process hopefully simpler than a BCP RFC process, but certainly more complicated than editing in wiki.

Frankly, I cannot suggest edits to meet these concerns, and I do not want to stop the show.

[Ballot discuss]
A discuss-discuss:

I wonder if the IESG wiki page meets some of the goals that IONs were originally intended to solve? Its existance is noticably absent in section 5 (I don't consider the discussion on "Web Pages" to accurately reflect the wiki pages).

[Ballot discuss]
The document states:

  An ION is always approved by some body.  This document suggests that
  the IESG be given supreme authority over the ION mechanism, subject
  to appeal, but encourages the IESG to share the right to approve IONs
  with other bodies.

  The IESG is responsible for approving the document that gives the
  list of current ION approvers.  An initial set of ION approvers may
  be the IESG, the IAB, the IAOC and the IAD.

I am troubled by the "supreme authority" part above. The IESG has certain
tasks and powers; I think everyone agrees that this experiment is not
changing those powers. Yet some of the other bodies mentioned above
also have some powers and even a potential need to post operational
notes about matters belonging to them. For instance, the IAB is responsible
for RFC Editor relationship and liaisons. It seems wrong to claim that
the IESG has supreme authority over such IONs.

Suggested edit below:

  An ION is always approved by some body.  The IESG is granted authority
  over the practical management of the series and the definition of
  detailed processes and rules associated with it. The right to
  approve IONs resides, however, on each body for the part they
  are responsible for according to the current process BCPs.
  This document specifies that the IESG, IAB, IAOC, and the IAD
  have an ION approval right. These bodies may in addition delegate
  parts of their own approval right to others.

Comment part: Nits -- spelling issues: previoiusly, fulfil, veichle

[Ballot discuss]
The document states:

  An ION is always approved by some body.  This document suggests that
  the IESG be given supreme authority over the ION mechanism, subject
  to appeal, but encourages the IESG to share the right to approve IONs
  with other bodies.

  The IESG is responsible for approving the document that gives the
  list of current ION approvers.  An initial set of ION approvers may
  be the IESG, the IAB, the IAOC and the IAD.

I am troubled by the "supreme authority" part above. The IESG has certain
tasks and powers; I think everyone agrees that this experiment is not
changing those powers. Yet some of the other bodies mentioned above
also have some powers and even a potential need to post operational
notes about matters belonging to them. For instance, the IAB is responsible
for RFC Editor relationship and liaisons. It seems wrong to claim that
the IESG has supreme authority over such IONs.

Suggested edit below:

  An ION is always approved by some body.  The IESG is granted authority
  over the practical management of the series and the definition of
  detailed processes and rules associated with it. The right to
  approve IONs resides, however, on each body for the part they
  are responsible for according to the current process BCPs.
  This document specifies that the IESG, IAB, IAOC, and the IAD
  have an ION approval right. These bodies may in addition delegate
  parts of their own approval right to others.

[Ballot comment]
Section 2.2, last paragraph:
"In the case that the IESG ceases to exist, its successors or assigns
  will take over the tasks given to the IESG in this document."

Something is strange with with the second part of the sentence. Please correct it to what is desired.

Section 2.4:

The store should be reachable by common methods like World Wide Web
  and FTP, and should offer both easy access to the "current" version
  of all IONs and bulk download of all IONs, all versions.

I find it strange that the document call World Wide Web a method for accessing the IONs. I would propose replacing World Wide Web with HTTP.

[Ballot comment]
Needs to be spell-checked.


Section 7., paragraph 1:

>    IONs shouldn't have much need to talk about security.

  Meaning what? This is a bit too flippant. Given how broadly IONs are
  being scoped, they can surely have security implications?