IETF Operational Notes
draft-alvestrand-ipod-03

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.

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.

  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?

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.

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.

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.