Extensions to the IODEF-Document Class for Reporting Phishing
draft-cain-post-inch-phishingextns-07

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 these.

1. 

 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 report content.

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 lists. 

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
    correlating events.
 
It is unclear what "domain used to source the lure" means.  Is it the header or envelope From address of an email?

6.  4.9.2.6.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" means.

7.  4.9.2.6.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 into play.

8.  4.9.2.7.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 scenarios.

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 

s/enumerates/contains/

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 5.9.2.6.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 5.11.2.1: "One Value of STRING": should be INTEGER

- Appendix B.2: the contents of phish:Message seem to be garbled. 
For example:
  - 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
to www.iana.org.

I support the DISCUSS from DNSOPS/Dan