Domain Name System Operations
charter-ietf-dnsop-04

[Ballot comment]
Just a question, would this WG use the output of the DNS Security and Privacy effort?  It's not mentioned, so I figured I'd ask.

[Ballot block]
Sorry to do this, but I asked for some changes to point 4 because the first sentence doesn't actually parse, and these changes never happened. They need to happen before the charter is approved.

OLD:
4. Publish documents  that extend or perform protocol maintenance
  to the address operational issues with the DNS Protocols.
NEW:
4. Publish documents  to address operational issues with the DNS
    protocols by  extending or performing protocol maintenance
    on them.

I'm not married to the wording, but the current wording doesn't make sense.

[Ballot comment]
I've cleared my block on this charter.  I would like to point out that there are some typos in the new version of the charter, though:

OLD:
4. Publish documents on extensions or perform protocol maintenance
  to the addres operational issues with the DNS Protocols, in
  particular.  Act as focal-point for operator discussion and provide
  advice to the Ops ADs and other WGs on EDNS0 options,
  new RRTYPEs, DNSSEC, record synthesis, or other mechanics of
  extending DNS to support other applications.
NEW (suggested):
4. Publish documents on extensions or perform protocol maintenance
  to address operational issues with the DNS Protocol.  Act as
  focal-point for operator discussion and provide
  advice to the Ops ADs and other WGs on EDNS0 options,
  new RRTYPEs, DNSSEC, record synthesis, or other mechanics of
  extending DNS to support other applications.

(I also don't think you need to say "in particular" since obviously DNSOP is about DNS in particular, but that's a pretty minor nit, and I'm not attached to that edit.)

Former BLOCK position:

Point 1 could  be interpreted to mean that DNSOP is going to define new protocols for operating the DNS.  It also implies some degree of authority—it could be interpreted as carte blanche for defining standards-track specifications that describe how DNS servers must be configured, for instance.  I don't think this is what is currently intended, so perhaps it would be better to say "Describe practices" rather than "Define processes."  Since I don't know precisely what is intended here, what I'm suggesting may not be quite right, but I'd like to have a discussion about that.

Points 4 and 5 seem to be creating another catch-all DNS working group.  We've been burned by catch-all DNS working groups in the past.  The wording here isn't tight enough to prevent this—it can easily be interpreted to mean that DNSOP is going to start writing new standards-track DNS documents, as long as the responsible AD for DNSOP at that time agrees.  I do not mean to suggest that the current AD has any bogus intentions here, but this isn't tight enough to prevent trouble in the future, in particular with the working group taking advantage of a new AD who hasn't learned how to say no yet.

It's worth noting that we have a new intarea directorate that's supposed to be qualified to do what's described in the first sentence of point 5 and the last sentence in point 4.  That doesn't mean DNSOP is a bad place to raise such discussions, but I don't think we need to call this out in the charter; doing so seems to say "this is where such discussions should happen" which seems wrong to me. 

And then the text in section 5 seems to suggest that with AD approval, the work might take on arbitrary DNS work.  I think it would be better to say something like "The group will then consider whether the work is covered by the DNSOP charter and if not, decide whether to propose updating the charter, recommend creation of a new working group to do the work, or suggest a working group that is already chartered to do the work."

I'm also not convinced that points 4 and 5 are different points.  They're not exactly the same, obviously, but it might make sense to combine them.

[Ballot comment]
If point 1 is describing practices (and maybe this is old and the work has been done already, so excuse me if that is the case), why is there no mention of security or operational security considerations?

[Ballot block]
Point 1 could  be interpreted to mean that DNSOP is going to define new protocols for operating the DNS.  It also implies some degree of authority—it could be interpreted as carte blanche for defining standards-track specifications that describe how DNS servers must be configured, for instance.  I don't think this is what is currently intended, so perhaps it would be better to say "Describe practices" rather than "Define processes."  Since I don't know precisely what is intended here, what I'm suggesting may not be quite right, but I'd like to have a discussion about that.

Points 4 and 5 seem to be creating another catch-all DNS working group.  We've been burned by catch-all DNS working groups in the past.  The wording here isn't tight enough to prevent this—it can easily be interpreted to mean that DNSOP is going to start writing new standards-track DNS documents, as long as the responsible AD for DNSOP at that time agrees.  I do not mean to suggest that the current AD has any bogus intentions here, but this isn't tight enough to prevent trouble in the future, in particular with the working group taking advantage of a new AD who hasn't learned how to say no yet.

It's worth noting that we have a new intarea directorate that's supposed to be qualified to do what's described in the first sentence of point 5 and the last sentence in point 4.  That doesn't mean DNSOP is a bad place to raise such discussions, but I don't think we need to call this out in the charter; doing so seems to say "this is where such discussions should happen" which seems wrong to me. 

And then the text in section 5 seems to suggest that with AD approval, the work might take on arbitrary DNS work.  I think it would be better to say something like "The group will then consider whether the work is covered by the DNSOP charter and if not, decide whether to propose updating the charter, recommend creation of a new working group to do the work, or suggest a working group that is already chartered to do the work."

I'm also not convinced that points 4 and 5 are different points.  They're not exactly the same, obviously, but it might make sense to combine them.

[Ballot block]
Point 1 could  be interpreted to mean that DNSOP is going to define new protocols for operating the DNS.  It also implies some degree of authority—it could be interpreted as carte blanch for defining standards-track specifications that describe how DNS servers must be configured, for instance.  I don't think this is what is currently intended, so perhaps it would be better to say "Describe practices" rather than "Define processes."  Since I don't know precisely what is intended here, what I'm suggesting may not be quite right, but I'd like to have a discussion about that.

Points 4 and 5 seem to be creating another catch-all DNS working group.  We've been burned by catch-all DNS working groups in the past.  The wording here isn't tight enough to prevent this—it can easily be interpreted to mean that DNSOP is going to start writing new standards-track DNS documents, as long as the responsible AD for DNSOP at that time agrees.  I do not mean to suggest that the current AD has any bogus intentions here, but this isn't tight enough to prevent trouble in the future, in particular with the working group taking advantage of a new AD who hasn't learned how to say no yet.

It's worth noting that we have a new intarea directorate that's supposed to be qualified to do what's described in the first sentence of point 5 and the last sentence in point 4.  That doesn't mean DNSOP is a bad place to raise such discussions, but I don't think we need to call this out in the charter; doing so seems to say "this is where such discussions should happen" which seems wrong to me. 

And then the text in section 5 seems to suggest that with AD approval, the work might take on arbitrary DNS work.  I think it would be better to say something like "The group will then consider whether the work is covered by the DNSOP charter and if not, decide whether to propose updating the charter, recommend creation of a new working group to do the work, or suggest a working group that is already chartered to do the work."

I'm also not convinced that points 4 and 5 are different points.  They're not exactly the same, obviously, but it might make sense to combine them.

[Ballot comment]
-
Just to make sure that it's not the group that decides alone, and to leave the door open if there is a need for a new WG.

OLD:
  The group will then decide whether these issues belong in DNSOP
  and, if not, will work with the authors and appropriate ADs to
  determine the appropriate group for the work.

NEW:
  The group, with the advice and consent of the responsible AD,
  will then decide whether these issues belong in DNSOP
  and, if not, will work with the authors and appropriate ADs to
  determine the appropriate group for the work.

Maybe such a formulation could be used for 4. as well?

Anyway, it's only editorial, as I entirely trust the chairs and Joel to do the right thing.

- I would expand EDNS0

[Ballot comment]
So long as this is going for external review, I'm willing to withhold judgement, but the "clearinghouse" items still give me pause. It sounds like this WG could become a honeypot for all sorts of lunacy. And in general this sort of long-term open-ended charter can do that as well. But let's see what the IAB and the community think.

[Ballot block]
I just want to get clarification on one point, so I hope this is a short-lived Block...

The charter has the following point:

4. Publish documents on extensions or protocol maintenance to the
  DNS Protocol, with a focus on the operational impacts of such
  changes.  Act as clearinghouse for discussion or provide advice
  to ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC,
  record synthesis, or other mechanics of extending DNS to support
  other applications.


I know we had a brief e-mail discussion, but I would like to see some clarity in this item.  Does the above mean that DNSOP will only write operational documents on protocol specs developed in a different WG?  Or is the intent to allow DNSOP to develop protocol extensions as well?

Added milestone "Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational.", due August 2004, from current group milestones