Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

From: Kurt Andersen <[email-masked]>
Date: Sat, 20 Jan 2018 04:19:07 +0000

On Jan 19, 2018 19:53, Hector Santos <[email-masked]> wrote:

If this is done, then shouldn't the ARC proposal be standard track
rather than experimental?

Making 7601 more extensible does not affect the state of ARC.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Sat, 20 Jan 2018 17:00:30 +0000

> Making 7601 more extensible does not affect the state of ARC.

Agreed. Extending 7601 lets us meaningfully simplify the ARC draft, but
does not otherwise affect the state of the tech or the underlying
experiment.

Seth

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Jan 2018 12:11:54 -0500

> Making 7601 more extensible does not affect the state of ARC.

It was my understanding that the IETF frowns upon making proposed 
standards RFC connections to experimental, non-standard stuff.

If ARC fails as an experiment, 7601 will be left with legacy 
dependencies and wasted development *overhead* on an abandoned 
experimentation that has yet to proven its value.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 20 Jan 2018 12:17:58 -0500

IMEV, 7601 should be extendable without continuing modifying 7601 by 
augmented technology, i.e. ARC itself should do the 7601 "add-on" 
considerations and that shouldn't effect 7061 or any 7601 
implementations.

-- 
HLS

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 20 Jan 2018 09:52:39 -0800

That is our plan. The change to 7601 is to segment the ABNF for clearer
extension by ARC. Wait and see what Murray puts in and then we can discuss.

On Jan 20, 2018 09:18, "Hector Santos" <[email-masked]> wrote:

> considerations and that shouldn't effect 7061 or any 7601 implementations.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 20 Jan 2018 18:15:09 -0800

>> considerations and that shouldn't effect 7061 or any 7601 implementations.
Kurt's correct.  ARC (experimental) depends on A-R (standards track), not
the other way around.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Sun, 21 Jan 2018 17:39:13 -0500

On 1/20/2018 9:15 PM, Murray S. Kucherawy wrote:
> On Sat, Jan 20, 2018 at 9:52 AM, Kurt Andersen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     That is our plan. The change to 7601 is to segment the ABNF for
>     clearer extension by ARC. Wait and see what Murray puts in and
>     then we can discuss.
>
>     On Jan 20, 2018 09:18, "Hector Santos" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         IMEV, 7601 should be extendable without continuing modifying
>         7601 by augmented technology, i.e. ARC itself should do the
>         7601 "add-on" considerations and that shouldn't effect 7061 or
>         any 7601 implementations.
>
>
> Kurt's correct.  ARC (experimental) depends on A-R (standards track),
> not the other way around.

That is what I would think, but the key concern I would think, we 
don't want to add something ARC related to A-R if its not generic and 
only specific to ARC.

Personally, it may be premature. Wait until ARC is more than settle in 
its direction before modifying any standard track item.  But if its a 
generic change, that fits more than just ARC, that sounds ok.

Keep in mind, there are might be others, besides my own package, who 
can't/won't (for various reasons) use OpenARC or OpenDMarc and/or 
OpenA-R.   Hopefully, we will be able to write (implement) this from 
the RFC "functional specifications" from scratch.

Thanks

-- 
HLS