I'm good with either of Scott's wordings on this.

I guess I'm making an assumption that the TLD operators know what they can
and can't do
(but that may be a horrible assumption).


Tim
(no hats)


On Sun, Jul 14, 2019 at 6:13 AM Alessandro Vesely <ves...@tana.it> wrote:

> On Fri 12/Jul/2019 20:27:05 +0200 Scott Kitterman wrote:
> > On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote:
> >> On Fri, Jul 12, 2019, at 1:41 PM, Scott Kitterman wrote:
> >>> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> >>>> As Secretary, there are three items that have not yet reached
> consensus
> >>>> that must be resolved during WGLC:
> >>>>
> >>>> 2. If explicit call outs to ICANN/limited operator capacity to
> implement
> >>>> are needed
> >>>
> >>> There has been feedback in favor of adding this and none against so
> far.
> >>>
> >>> The specific proposal is:
> >>>
> >>> "Please note that today's operational and policy reality prevents this
> >>> experiment from being deployed globally. If the experiment shows that
> PSD
> >>> solves a real problem at a large scale, the results could prove to be
> >>> useful in the development of policies outside of the IETF that would
> >>> permit its ubiquitous deployment."
> >>>
> >>> Because RFCs are (approximately) forever, I'm concerned about words
> like
> >>> "today's" in protocol documents, even experimental ones.
> >>>
> >>> How about this instead:
> >>>
> >>> "As of the writing of this document operational and policy constraints
> >>> prevent this experiment from being deployed globally. If the experiment
> >>> shows that PSD solves a real problem and can be used at a large scale,
> >>> the results could prove to be useful in the development of policies
> >>> outside of the IETF that would permit broader deployment".
> >>
> >> "[D]evelopment of policies outside of the IETF" strikes me as a little
> odd
> >> since IETF isn't setting policy *per se*, although substitute language
> that
> >> is just as succinct is escaping me at the moment.
> >
> > .... removal of constraints ... ???
> >
> > "As of the writing of this document operational and policy constraints
> prevent
> > this experiment from being deployed globally. If the experiment shows
> that PSD
> > solves a real problem and can be used at a large scale, the results
> could
> > prove to be useful in the removal of constraints outside of the IETF
> that
> > would permit broader deployment".
> >
> > Better?
>
>
> I reply here to the other thread,[*] where you said "Some can, some
> can't."  For the sake of comprehensibility, could that be spelled out a
> little bit more clearly?  For example like so:
>
>     As of the writing of this document, there are operational
>     and policy constraints which prevent this experiment from
>     being deployed globally.  While it is beyond the scope of
>     this document to delve into the details,  be it enough to
>     mention that not all PSOs are actually able to publish
>     DMARC records as needed.  Those who are able to do so and
>     wish to participate in the experiment should contact
>     DMARC-PSD.org in order to have their PSD enlisted.  If the
>     experiment shows that DMARC-PSD solves a real problem and
>     can be used at a large scale, the results could prove to
>     be useful in removing those constraints, so as to permit
>     broader deployment.
>
>
> Best
> Ale
> --
>
> [*] Archived-At: <
> https://mailarchive.ietf.org/arch/msg/dmarc/_WjDZj17qySDLcIWlcCIan54s0A>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to