Thanks, Andrew, for your reviews. (To the WG: He did let me know ahead of time that he'd be sending a late one.)
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Scott > Kitterman > Sent: Tuesday, February 28, 2012 9:11 AM > To: [email protected] > Subject: Re: [marf] FW: REMINDER: WGLC for draft-ietf-marf-{spf, > dkim}-reporting ends in one week > > > First, a process issue. The header says that this is aimed for the > > standards track, and that it updates RFC 4408. The chairs are more > > experienced than I in the arcana of IETF process rules, but I think > > this is going to be tricky, isn't it? > > There's a process for dealing with downrefs. I think it's appropriate > in this case. AIUI whoever does the post last call writeup on the > draft has to document for the IESG why the downreft is appropriate. > There's roughly no chance SPFbis will cause an impact on this > specification, so it'd be wasteful to publish this as experimental and > then come back once 4408bis is updated and republish the same document > with a different label. Actually the reason I recommended including "Updates" is that this is supposed to mean "If you implement the older spec, you really need to also read the newer one." It creates that forward pointer in the RFC index and on some HTML renderings of the older documents. The specific reason for doing it in this case is the creation of the IANA registry of modifiers, which RFC4408 didn't do. Someone that wants to make a new one but only reads RFC4408 won't know the registry exists, so it seemed the forward pointer created by an "Updates" was appropriate. This is really a minor procedural point, however. If the IESG doesn't like it, we can simply remove it. > > Second, in section 3, discussing rp=, the document says that a report > > SHOULD NOT be generated for percentages higher than that. Under what > > circumstances is it ok to generate outside of this guidance? Is this > > a resource issue? I don't understand when it would be ok. > > It wouldn't be OK, but it wouldn't fundamentally cause an > interoperability problem, so we didn't use MUST. The worst that's > likely to happen is some of all of your reports get routed to > /dev/null. This is text copied from the other reporting document, as I recall. I used SHOULD in that instance because there might be cases where one party contacts another and says, basically, "Although I advertise that I want x% reported, from you I want everything." Thus, a private arrangement overriding what the protocol says would be a valid reason to disregard the "rp=" value. We might want to say that, since there are people on the IESG that have specifically said they like to see examples of when one might contradict a SHOULD. We'll save that minor thing for after the IETF-wide LC. Thanks again, -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
