Note: This ballot was opened for revision 04 and is now closed.
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
I support Lisa's discuss.
Some problems with XML schema are explained in BCP 70 section 4.7.
Here's one excerpt:
o Protocols may or may not insist that all corresponding protocol
elements be valid, according to the validity mechanism chosen; in
either case, the extensibility design should be clear. What
happens if the data is not valid?
I'm not sure that voip is the fraud type you want in section 4.5. It seems that
all of these schemes can happen on a telephone call regardless of if it is
voip, pstn, or some other type. It is often hard for the sensor to even know
what type the call was orignated as. I think you should consider changing voip
to telephone and I support the idea of an actually extensible registry for
3.3. Correctness of Fraud Activity Reports
The Fraud Activity Report MUST pass XML validation using the schema
defined in [RFC5070] and the extensions defined in
<AppendixA> of this document.
The title of this subsection should be renamed "Syntactical Correctness ..."
because it could otherwise be perdevied to deal with the validation of the
2. Section 4.4 - REQUIRED. STRING. The version shall be the value 0.04 to
be compliant with this document. [This value will be changed to "1.0" when
this document progresses.]
This should be marked as a note to RFC Editor and s/progresses/is approved/
3. There are several ENUM attributes (FraudType, Role, Confidence,
SystemStatus, OrigSensorType) that place 'other' or 'unknown' values at the end
of the enum list. The better practice is to place such special values at the
begining, so that if and when the model or report is extended in the future
such special values do not find themselves in the middle of the enumerated
4. 4.5. FraudType attribute
5. dnsspoof. This choice does not have a related FraudParameter.
This is used for a spoofed DNS (e.g., malware changes localhost
file so visits to www.example.com go to another IP address
chosen by the fraudster).
DNS spoofing is usually to involve forged DNS responses, not manipulating the
resolution path. It could be argued that in the case described here, DNS
doesn't even get used.
5. 4.9.2. DomainData element
Zero or more element values. The DomainData element describes the
registration, delegation, and control of a domain used to source the
lure. Capturing the domain data is very useful when investigating or
It is unclear what "domain used to source the lure" means. Is it the header or
envelope From address of an email?
6. 184.108.40.206.1. owner element
REQUIRED. One String Value. This element identifies the superior
node in the DNS hierarchy.
"Superior node" is either a wrong description (Is "example.com" superior to
"www.example.com"?) or an outright misunderstanding of what a "DNS owner name"
7. 220.127.116.11.3. class element
Zero or one value of a STRING. This field contains one value from
the IANA DNS Domain System Class Registry. The value will be the two
character representation of class, instead of a decimal number to
ease data entry from standard DNS tools. The default value for this
field is "IN" to note the Internet.
This seems to be in conflict with the schema defined later, which makes this
mandatory. Also I'm not sure why and how anything else but "IN" would come
8. 18.104.22.168.1. SameDomainContact
REQUIRED. One iodef:DNSNAME. The SameDomainContact element is
populated with a domain name if the contact information for this
domain is identical to that name in this or another report.
Implementors are cautioned to only use this element when the domain
contact data returned by the registrar is identical.
This tacitly assumes a "thin registry" model; s/registrar/registrar or registry/
9. 4.9.3. SystemStatus attribute
REQUIRED. ENUM. The SystemStatus attribute assesses a domain's
involvement in this event.
Domains are elements in a name space, not acting parties. How can a domain be
"involved" in anything? The IETF should resist the temptation to standardize
colloquial abuse of the meaning of "domain".
1. spoofed. This domain or system did not participate in this
event, but its address space or DNS name was forged.
It's just identifiers, but "spoofed" and "forged" appear to me as different
10. 4.9.4. DomainStatus attribute
ENUM. The DomainStatus attribute describes the registry status of a
domain at the time of the report. The below enumerated list is taken
verbose from the 'domainStatusType' of the Extensible Provisioning
Protocol[RFC4933] and "Domain Registry Version 2 for the Internet
Registry Information Service" internet-draft [CRISP].
See the other comment about the [CRISP] reference and note that the document is
no longer an Internet-Draft, but an RFC
11. 4.17.1. EmailCount
12. I support Lars's DISCUSS about the need to clarify that the Anti-Phishing
Working Group is not an IETF WG.
Section 4.4., paragraph 1:
> REQUIRED. STRING. The version shall be the value 0.04 to be
> compliant with this document. [This value will be changed to "1.0"
> when this document progresses.]
Is the text in brackets an RFC Editor Note, i.e., should the RFC
Editor change 0.04 to 1.0?
Support Dan's comment about the DNS review comments not being addressed.
Couple of nits:
- Section 22.214.171.124.2: the UML for iodef:Contact doesn't match RFC 5070
(some multiplicities, attribute types, attribute names don't match)
- Section 5.10: the UML should have (1..*) for iodef:System
(version -06 had this right).
- Section 126.96.36.199: "One Value of STRING": should be INTEGER
- Appendix B.2: the contents of phish:Message seem to be garbled.
- The " to: ..." line following Return-path seems weird (is
it intended to be part of the Return-path header?)
- The "Type" header seems strange -- should it be "Content-Type"?
But that body is not actually multipart/mixed type...
- It's not quite clear where the header ends and body text
starts. If the last header line is "X-Spam-Level", then the
first ~10 lines of the body text aren't actually the same
as in B.1.
- Appendix C.1/C.2: The URL and date in email in C.1 arent't the same
as in the report in C.2.
- The schema should *NOT* have any schemaLocation URLs pointing