Domain Connect
charter-ietf-dconn-01

[Ballot comment]
My apologies for missing to review/ballot when this came up for internal review and this is why I am sharing my feedback as comments instead of a block.

I am concerned with IESG recommending individual starting point documents to the WG. The WG should follow its process to pick their starting point and go with the consensus.

Is there an issue if "The WG will use draft-kowalik-domainconnect as the starting point for its work." were to be removed from the charter?

Alternately, if that draft specifies the current state of the protocol specification outside of the IETF, then please consider the following suggestion:

CURRENT:
The Domain Connect Working Group (WG) is chartered to develop and standardize the Domain Connect Protocol.

SUGGEST:
The Domain Connect Working Group (WG) is chartered to develop and standardize the Domain Connect Protocol that is documented in draft-kowalik-domainconnect.

And then remove "The WG will use draft-kowalik-domainconnect as the starting point for its work."

[Ballot comment]
"WG", paragraph 0
> The Working Group acknowledges that Domain Connect is "a deployed technology
> for which protecting the installed base is essential, including retention of
> core interoperability," as described in Section 4 of RFC 7221. Accordingly, the
> WG will prioritize stability and backward compatibility, and will avoid changes
> that could break existing implementations or deployments. The working group may
> make breaking changes to address critical security issues.

Have to agree with Med and Eric that the Copyright statement is concerning. It should be resolved before the WG is formed.

"WG", paragraph 1
> The scope of the WG’s activities includes:
>
> * Ensuring that the specification is precise and provides clear guidance for
> implementers. * Addressing any ambiguities, inconsistencies, or issues
> identified within the current draft. * Producing a comprehensive document
> suitable for publication as a Standards Track RFC.

Nothing about this set of activities sounds new or different from what a standards process entails. Why are they even in the charter?

[Ballot comment]
I understand there is only one deliverable, but I am surprised the charter states this: "WG will use draft-kowalik-domainconnect as the starting point for its work."

[Ballot comment]
I can only repeat my NoObjection ballot comments on -00-00 as they are unchanged (to be accurate, the copyright issue is based on the first link in the charter)

So, it is about a 'tiny' WG with a single document (and I appreciate that the intended RFC status is clearly marked).

I share Med's concern with the GoDaddy copyright as the I-D cannot be subject to this kind of external copyright. Are we sure that the current set of authors will agree to relinquish the change control to the IETF community? Else, ISE seems more suitable.

Strongly suggest to change the term "Service Providers" into "SaaS" (or something similar) as with my INT eyes, I read this as "Internet Service Providers".

[Ballot comment]
Hi all,

Thanks for the message sent recently to DNSOP WG to inform the WG about this effort and sharing the background since 2016. That's useful.

I do support providing a home for this work. I do see it in the frontier between OPS/ART, but that's not an issue per se.

Please find below some comments:

# Expected outcome

The various guards in the charter suggests that the technical changes are likely to be marginal (?) and will be more about the clarity of the spec. This smells more about documenting the protocol as currently deployed. That seems more Informational to me. That would be at least consistent with how widely deployed protocols were first RFCed in the IETF (e.g., syslog (3164/info), netflow (3954/Info), IAX (5456/info), tacacs (8907/Info)) or even active proposals (e.g., PCAP (draft-ietf-opsawg-pcap/Info)).

# Control Change

[2], which documents the protocol, states the following:

"
Copyright (c) 2016 GoDaddy Operating Company, LLC.
..
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
"

What are the implications on publishing that text as an RFC?

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/uneEOoBRTnQvg2L3StNR1Zl7Smk/

[2] https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc

[Ballot block]
In addition to the IPR issues, I am also considered about two things:

1) if just documenting an existing protocol without change control, the ISE is the better path
2) I'm very nervous about the OAUTH authentication system, where an unskilled Registrant has to
  click some things to give out access to their domain name to a SAAS party, and the security
  implications involved. The scoping town with templates is hard for me to follow, I am not
  sure an unskilled Registrant can make proper choices here. As such, I feel the security
  model might need some changes but that is not what the proponents seem to want.

[Ballot block]
Hi all,

I'm updating my ballot per the discussion in [3].

Thanks for the message sent recently to DNSOP WG to inform the WG about this effort and sharing the background since 2016. That's useful.

I do support providing a home for this work. I do see it in the frontier between OPS/ART, but that's not an issue per se.

Please find below some comments:

# Expected outcome

The various guards in the charter suggests that the technical changes are likely to be marginal (?) and will be more about the clarity of the spec. This smells more about documenting the protocol as currently deployed. That seems more Informational to me. That would be at least consistent with how widely deployed protocols were first RFCed in the IETF (e.g., syslog (3164/info), netflow (3954/Info), IAX (5456/info), tacacs (8907/Info)) or even active proposals (e.g., PCAP (draft-ietf-opsawg-pcap/Info)).

# Control Change

[2], which documents the protocol, states the following:

"
Copyright (c) 2016 GoDaddy Operating Company, LLC.
..
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
"

What are the implications on publishing that text as an RFC?

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/uneEOoBRTnQvg2L3StNR1Zl7Smk/

[2] https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc

[3] https://mailarchive.ietf.org/arch/msg/dconn/LzrrptC6kGqqwGD0iqG8rRcFC6M/

[Ballot comment]
So, it is about a 'tiny' WG with a single document (and I appreciate that the intended RFC status is clearly marked).

I share Med's concern with the GoDaddy copyright as the I-D cannot be subject to this kind of external copyright. Are we sure that the current set of authors will agree to relinquish the change control to the IETF community? Else, ISE seems more suitable.

Strongly suggest to change the term "Service Providers" into "SaaS" (or something similar) as with my INT eyes, I read this as "Internet Service Providers".

[Ballot comment]
I agree with Med's suggestion that PS and restricting the WG from making breaking changes seems incompatible. However, the current language could be read as discouraging unnecessary breaking changes rather than outright prohibiting them. I would suggest clarifying that the WG is able to make breaking changes if necessary, but should consider the installed population carefully before doing so.

[Ballot comment]
Hi all,

Thanks for the message sent recently to DNSOP WG to inform the WG about this effort and sharing the background since 2016. That's useful.

I do support providing a home for this work. I do see it in the frontier between OPS/ART, but that's not an issue per se.

Please find below some comments:

# Expected outcome

The various guards in the charter suggests that the technical changes are likely to be marginal (?) and will be more about the clarity of the spec. This smells more about documenting the protocol as currently deployed. That seems more Informational to me. That would be at least consistent with how widely deployed protocols were first RFCed in the IETF (e.g., syslog (3164/info), netflow (3954/Info), IAX (5456/info), tacacs (8907/Info)) or even active proposals (e.g., PCAP (draft-ietf-opsawg-pcap/Info)).

# Control Change

[2], which documents the protocol, states the following:

"
Copyright (c) 2016 GoDaddy Operating Company, LLC.
..
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
"

What are the implications on publishing that text as an RFC?

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dnsop/uneEOoBRTnQvg2L3StNR1Zl7Smk/

[2] https://github.com/Domain-Connect/spec/blob/master/Domain%20Connect%20Spec%20Draft.adoc