> -----Original Message----- > From: Robert Sparks [mailto:[email protected]] > Sent: Tuesday, April 24, 2012 8:52 AM > To: The IESG > Cc: [email protected]; [email protected] > Subject: Robert Sparks' Discuss on draft-ietf-marf-as-14: (with DISCUSS and > COMMENT) > > Robert Sparks has entered the following ballot position for > draft-ietf-marf-as-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The MUST in section 4.5 item 1 may need clarification. Do you mean to > say that the system MUST accept a report with a feedback type with any > value that makes it into the (specification-required) registry? Or are > you wanting to scope that to values that were registered with an RFC > that Updates/Obsoletes 5965? Or something else?
The intent is the first case, or basically any "official" type. At present, that means the registry. Obviously there's no signaling mechanism from IANA to implementers when new types are added, but that's still the intent. Since this is an applicability statement and not a technical specification, I don't think we need to establish a protocol to ensure compliance, but rather perhaps say that implementers need to check periodically for new types of feedback to appear in the registry as a result of the publication of other registering documents. > Is this effectively > requiring implementations of automated report processing systems to be > configurable with what feedback types it will accept? If so, would it > make sense to say that explicitly? That is one option, except that in addition to merely accepting the types by name, adding parsing support for types which (for example) add new feedback header fields might be necessary. So it might not be as simple as configuring a list. Perhaps "add support for" would be better. > Also, consider more detail on what > accept means here. Does it mean the system can't return a rejection > response (what bad happens if it does?) or is the intent that it must > _process_ the report. The intent is "not reject", as in no SMTP 5yz replies and no DSNs generated. Rather than requiring automated processing, a system that sees a report type it doesn't explicitly know how to handle might simply set it aside for manual handling. The rejection can't necessarily be distinguished by the sender as "unsupported report type" if the other side is only looking at SMTP reply codes, for example; we'd have to provide a more detailed signaling mechanism on top of SMTP. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In section 5.1 item 1, is there a typical unstandardized out-of-band > mechanism for telling unsolicited reporters to please stop that you can > call out as an example (an existence proof)? I'll see if I can find one. I don't know of one personally, but someone in the working group probably does. > In Section 6, item 1, the sentence "Automatic feedback generators MUST > select recipients based on data provided by the report recipient." is > really hard to understand (it's almomst circular). Is it trying to say > something like "Automatic feedback generators MUST only send to > addresses explicitly provided by willing recipients."? Yes, that's better. We can patch that in. Thanks, -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
