IPv6 Maintenance
charter-ietf-6man-04

[Ballot comment]
In theory, I have no problem with the idea that 6man can block another document. In effect, the chair of 6man can say, "6man has looked at this document and does not have consensus that the following issues have been properly addressed...". Assuming those issues are real, it would be an appealable action for any other chair (or for that matter, an AD or the IESG) to progress a document with outstanding unanswered objections from any group or individual, not just 6man. If the intention of the original text was that 6man could effectively put an "IOU" DISCUSS on a document ("6man think there might be issues here, so we want more time to review"), or that 6man could not in the end be declared "in the rough", that would be bogus. But I didn't read the original text that way. All that said, I have no particular objection to the current text. I'd rather it said "6man working group consensus does not exist on those documents" instead of "6man working group consensus is needed before the any of those documents can progress for publication", but the latter pretty much has the same effect as the former.

A bit of copyediting, because we don't have an RFC Editor to do so on charters:

  The working group may, at its discretion, review any document
  produced in another working group that extends or modifies the IPv6
  protocol and, in consultation with the responsible AD, may recommend
  to the IESG that 6man working group consensus is needed before any of
  those documents can progress for publication.

[Ballot comment]
The second paragraph gives the working group authority to block documents from other working groups.  I have no objection to the intent here, but as a process matter it strikes me that only consensus of the IESG can do that (there are other odd variations on that, but, basically...).

Perhaps the paragraph should add something to make it clear that it takes that action through the responsible AD?

UPDATE: -05 takes care of this nicely; thanks.

[Ballot comment]
I agree with the other comments related to the empowering of 6man in cross WG matters.

"and may determine that" should really be "and may recommend to the IESG that"

[Ballot comment]
I agree with Barry's comment.

I don't have any concerns if the interaction with other working groups as described happens via ADs, but the current text seems just a bit too empowering.

[Ballot comment]
The second paragraph gives the working group authority to block documents from other working groups.  I have no objection to the intent here, but as a process matter it strikes me that only consensus of the IESG can do that (there are other odd variations on that, but, basically...).

Perhaps the paragraph should add something to make it clear that it takes that action through the responsible AD?

[Ballot comment]
Thank you for addressing my concern. I am happy to ballot Yes on this charter revision, but hope it will go for IETF review to make sure that the whole IETF sees and understands the statement of protocol ownership.

[Ballot block]
Oh, I should have added...
Depending on the resolution of my concern, this charter will need IETF-wide review because it has the potential to impact strongly on other WGs.

I support this new charter but I want to pick on the same paragraph as Barry for a different reason.

  The 6MAN WG will review all proposed extensions to IPv6 developed in other
  working groups to ensure that they are consistent with the IPv6 architecture and
  specifications.

We need to be very clear whether this is an advisory review or a gating review. Does another WG making some extension to IPv6 need to get WG consensus in 6man, or does it need to bring its work to 6man for review input?

Making this statement very clear at this time will really help set expectations and make the future progress much more smooth.

I hope we can polish this and then I will ballot Yes

[Ballot block]
I support this new charter but I want to pick on the same paragraph as Barry for a different reason.

  The 6MAN WG will review all proposed extensions to IPv6 developed in other
  working groups to ensure that they are consistent with the IPv6 architecture and
  specifications.

We need to be very clear whether this is an advisory review or a gating review. Does another WG making some extension to IPv6 need to get WG consensus in 6man, or does it need to bring its work to 6man for review input?

Making this statement very clear at this time will really help set expectations and make the future progress much more smooth.

I hope we can polish this and then I will ballot Yes

[Ballot comment]
Same concern/comment as Barry

  The 6MAN WG will review all proposed extensions to IPv6 developed in other
  working groups to ensure that they are consistent with the IPv6 architecture and
  specifications.

So basically, for this entry, you want 6MAN to work as directorate?
We have directorates (pm-dir, yang-doctors, aaa-doctors, etc...) that receive a generated weekly email with all the current drafts that reference a list of RFC and/or contain specific keyword(s) (ex: performance metric). This is the input for the review process.
Maybe a directorate is more appropriate for this task?

No strong opinion at this point in time

[Ballot block]
I'd like to raise one of Sean's points to the level of a discussion (why did we not call it DISCUSS on charters again?):

I'd like to know why the last paragraph is not:

  All new work items not listed above require a recharter before they will
  be adopted by the working group.

[Ballot comment]
I have no objection to the new charter, including no objection to the intent of the new second paragraph:

  The 6MAN WG will review all proposed extensions to IPv6 developed in other
  working groups to ensure that they are consistent with the IPv6 architecture and
  specifications.

That said, that paragraph makes me uncomfortable on behalf of the chairs: How does the WG *find* "all proposed extensions to IPv6"?  Who is responsible for looking at what all the other working groups are doing, and identifying everything that 6MAN needs to review?  Isn't this an open-ended requirement that the chairs can't hope to meet?  (I realize that it's likely that 6MAN participants will find most of them "organically", by virtue of their normal participation in other WGs; what I worry about is its being put in terms of a mandate, a formal task for the WG.)

As I say, I think the intent is a fine one, and I wouldn't want to pull that paragraph back out, or anything like that.  I chatted with Brian for a bit, and neither of us can think of a different way to phrase this so that it's not akin to cleaning the Augean stables.

I'll continue thinking on it for now; if anyone else has any ideas, please speak up.

[Ballot comment]
0) I like the last work item a lot!  Let me know if I can help in anyway.

1) How does this:

  It is not chartered to develop major changes or additions
  to the IPv6 specifications.

jive with the list of things to do especially this one:

  Extensions/changes to core IPv6 protocols such as IPv6
  Neighbor Discovery

Maybe the sentence in the first paragraph should say:

  It is not chartered to make gratuitous changes or additions
  to the core IPv6 specifications.

2) I'm just curious about the correlation of the drafts to some of the work items.  Some seem pretty concrete, like these:

- "U/G" bits in Interface Identifiers is draft-ietf-6man-ug-03?

- Fragmentation - there's a whole bunch of individual drafts.  Will there be a tradeoff draft and then a solution draft (not that I care whether there are two or one I'm just curious).

- Approaches for IPv6 Extension Headers are draft-ietf-6man-ext-transmit-03 + draft-ietf-6man-oversized-header-chain?

but the next two seem a little open ended, but maybe I've gotten this wrong - are there drafts that directly correlate to these work items or will there be many drafts:

- Extensions/changes to core IPv6 protocols such as IPv6 Neighbor Discovery
- New IPv6 over  approaches if appropriate for 6MAN

Would adding a limit on the number of these kind of specs make sense?  "The WG will only adopt 2 New IPv6 over  approaches at a time to ensure they are completed before starting a new one."  The idea is too keep 'em focused and not just have things sprout up to sprout up.

And should there be a list of the RFCs that form the core IPv6 protocols or is that too much of a red herring?

3) On the last paragraph should it be:

  All new work items not listed above require a recharter before they will
  be adopted by the working group.

4) Don't know how people feel about this but I like what IPSECME does - they timeout if they're not getting stuff done:

  This charter will expire in (24 months from approval).
  If the charter is not updated before that time, the WG will be
  closed and any remaining documents revert back to individual
  Internet-Drafts.

5) Also, should update the dates in the milestones before it goes to external review I got flamed on a recent re-charter.