Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for August 28, 2008 Telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 24 Aug 2008 08:53:11 +0200

Please see below the preliminary agenda of the 8/28 IESG telechat.
Please send me comments and concerns related to the documents and WG
charters brought up for approval until 8/27 COB the latest. 

Thanks and Regards,

Dan

2. Protocol Actions
	Reviews should focus on these questions: "Is this document a
	reasonable basis on which to build the salient part of the
Internet
	infrastructure? If not, what changes would make it so?"

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-mpls-number-0-bw-te-lsps-11.txt
    A Link-Type sub-TLV to convey the number of Traffic Engineering
Label

    Switched Paths signalled with zero reserved bandwidth across a link 
    (Proposed Standard) - 1 of 1 
    Token: Ross Callon

2.1.2 Returning Item
NONE
2.1.3 For Action
  o draft-ietf-opsawg-snmp-engineid-discovery-03.txt
    Simple Network Management Protocol (SNMP) Context EngineID Discovery

    (Proposed Standard) - 1 of 1 
    Token: Dan Romascanu

2.2 Individual Submissions
2.2.1 New Item
  o draft-cain-post-inch-phishingextns-05.txt
    Extensions to the IODEF-Document Class for Reporting Phishing,
Fraud,
and 
    Other Crimeware (Proposed Standard) - 1 of 1 
    Token: Tim Polk

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.1.1 New Item
  o draft-ietf-mip6-whyauthdataoption-06.txt
    Why Authentication Data suboption is needed for MIP6 (Informational)
-
1 of 
    1 
    Note: No document shepherd -- old MIP6 document 
    Token: Jari Arkko

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.2.1 New Item
  o draft-cam-winget-eap-fast-provisioning-09.txt
    Dynamic Provisioning using Flexible Authentication via Secure
Tunneling 
    Extensible Authentication Protocol (EAP-FAST) (Informational) - 1 of
2
 
    Token: Tim Polk
  o draft-sun-dime-itu-t-rw-01.txt
    Diameter ITU-T Rw Policy Enforcement Interface Application
(Informational) 
    - 2 of 2 
    Token: Dan Romascanu

3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor
	The IESG will use RFC 3932 responses: 1) The IESG has not
	found any conflict between this document and IETF work; 2) The
	IESG thinks that this work is related to IETF work done in WG
	<X>, but this does not prevent publishing; 3) The IESG thinks
	that publication is harmful to work in WG <X> and recommends
	not publishing at this time; 4) The IESG thinks that this
	document violates the IETF procedures for <X> and should
	therefore not be published without IETF review and IESG
	approval; 5) The IESG thinks that this document extends an
	IETF protocol in a way that requires IETF review and should
	therefore not be published without IETF review and IESG
approval.

	The document shepherd must propose one of these responses in
	the Data Tracker note and supply complete text in the IESG
	Note portion of the write-up. The Area Director ballot positions
	indicate consensus with the response proposed by the
	document shepherd.

	Other matters may be recorded in comments, and the comments will
	be passed on to the RFC Editor as community review of the
document.

3.3.1 New Item
  o draft-irtf-nmrg-snmp-measure-05.txt
    SNMP Traffic Measurements and Trace Exchange Formats (Informational)
-
1 of 
    1 
    Note: Proposed IESG Note: . . The IESG thinks that this work is
related to 
    IETF work done in the Operations and Management Area related to
SNMP,
but 
    this does not prevent publishing.. . This RFC is not a candidate for
any 
    level of Internet Standard.. The IETF disclaims any knowledge of the

    fitness of this RFC for. any purpose and notes that the decision to
publish 
    is not based on. IETF review apart from the IETF Last Call on the 
    allocation of an URI by IANA and the IESG review for conflict with
IETF 
    work.. The RFC Editor has chosen to publish this document at its. 
    discretion. See RFC 3932 for more information.. . 
    Token: Dan Romascanu

3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
    NONE
4.1.2 Proposed for Approval
    NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
  o Operational Security Capabilities for IP Network Infrastructure
(opsec) - 1 of 1
    Token: Ron Bonica
4.2.2 Proposed for Approval
  o Sieve Mail Filtering Language (sieve) - 1 of 1
    Token: Lisa Dusseault

_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Peter Koch <[email-masked]>
Date: Mon, 25 Aug 2008 09:44:59 +0200

Dan,

>     Other Crimeware (Proposed Standard) - 1 of 1 

this draft, deferred from 2008-08-14, was the only one triggering on my DNS
keywords.  Two weeks ago I sent in a review, but haven't heard back from the
authors, yet. The proto summary now gave some helpful background information
about the drafts history and current use of the scheme, but I'd re-submit
my review here.

-Peter

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 25 Aug 2008 09:58:52 +0200

I am working to sort out the DISCUSS (show stoppers) from COMMENT
(nice-to-have, nits) issues. It would be useful if you can indicate what
you believe are the show stoppers in your review (attached) to make sure
I do not miss anything critical. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: Peter Koch [mailto:[email-masked]] On Behalf Of Peter Koch
> Sent: Monday, August 25, 2008 10:45 AM
> To: Romascanu, Dan (Dan)
> Cc: IETF DNS Directorate
> Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for 
> August 28, 2008 Telechat
> 
> Dan,
> 
> > 2.2.1 New Item
> > Fraud, and
> this draft, deferred from 2008-08-14, was the only one 
> triggering on my DNS keywords.  Two weeks ago I sent in a 
> review, but haven't heard back from the authors, yet. The 
> proto summary now gave some helpful background information 
> about the drafts history and current use of the scheme, but 
> I'd re-submit my review here.
> 
> -Peter
>

---

From: Peter Koch <[email-masked]>
Date: Mon, 25 Aug 2008 16:07:32 +0200

Hello Dan,

> I do not miss anything critical. 

further below I have marked what I consider substantial.  Some terminology issues
might also be important but could probably be fixed with just another editing
round.  I'd not say the individual questions raised are "show stoppers",
but in total, several clarifications could improve the document.

> >  Extensions to the IODEF-Document Class for Reporting Phishing, Fraud,
> >                           and Other Crimeware
> >                  draft-cain-post-inch-phishingextns-05
> 
> 
> > 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.
> 
> This headline should be renamed "Syntactical Correctness ..." because it could otherwise be perdevied to deal with the validation of the report content.
> 
> > 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.
> 
> > 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 to me what "domain used to source the lure" means.  Is it the header or envelope From address of an email?
> 
> >    The structure of a DomainData element is as follows:
> > 
> >    +--------------------+
> >    | DomainData         |
> >    +--------------------+
> >    |                    |<>----------[ Name ]
> >    |                    |<>--(0..1)--[ DateDomainWasChecked ]
> >    | ENUM SystemStatus  |<>--(0..1)--[ RegistrationDate ]
> >    | ENUM DomainStatus  |<>--(0..1)--[ ExpirationDate ]
> >    |                    |<>--(0..*)--[ Nameservers ]
> >    |                    |<>--(0..*)--[ DNSRecord ]
> >    |                    |<>--(0..*)--[ DomainContacts ]
> >    +--------------------+
> > 
> >                 Figure 4.3 The DomainData element
> [...]
> > 4.9.2.1.  Name
> > 
> >    REQUIRED.  One value of iodef:MLStringType [RFC5070], Section 2.4].
> >    The Name element is the domain name used in this event.
> 
> How is usage defined here?  Also, judging from the following, if the authors believe that the domain name should be modified to just cover the "registry level", they should make that explicit:
> If "www.example.com" was "used", would "www.example.com" or just "example.com" appear in the report?

Substantive clarification needed.

> > 4.9.2.6.  DNSRecord element
> > 
> >    Zero or more values.  This element allows the reporter to duplicate
> >    the DNS record data as defined by [RFC1034], and returned by the DNS.
> >    Including this information allows for tracking, trending, and
> >    identification of the very transient DNS mapping and structure of
> >    crimeware domains.
> > 
> >    +----------------+
> >    | DNSRecord      |
> >    +----------------+
> >    |                |<>--(1..1)--[ owner ]
> >    |                |<>--(1..1)--[ type ]
> >    |                |<>--(0..1)--[ class ]
> >    |                |<>--(0..1)--[ ttl ]
> >    |                |<>--(1..1)--[ rdata ]
> >    +----------------+
> > 
> >              Figure 4.4 The DomainContacts element
> 
> I wonder why we do not already have an XML schema describing DNS RRs.
> 
> > 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.
> 
> > 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.
> 
> Not being an XML expert this still 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.
> 
> > 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/;
> 
> > 4.9.2.7.2.1.  Role attribute
> > 
> >    REQUIRED.  ENUM.  The role attribute is extended from the iodef:role-
> >    ext attribute with values identified in [CRISP].  The role-ext 
> > value
> 
> The reference is broken. Also, the protocol's name is IRIS, not CRISP.
> 
> >    of the role attribute should be used, with the role-ext attribute
> >    value chosen from one of the following values:
> > 
> >    1.   registrant.  This identified Contact is the domain registrant.
> > 
> >    2.   registrar.  This contact identifies the registrar of this
> >         domain.
> > 
> >    3.   billing.  This entry is the billing or financial contact.
> > 
> >    4.   technical.  This contact deals with technical issues.
> > 
> >    5.   administrative.  This contact handles administrative matters for
> >         this domain.
> > 
> >    6.   legal.  This entry deals with legal issues for this domain.
> > 
> >    7.   zone.  This entry controls the DNS zone information.
> > 
> >    8.   abuse.  This entry accepts abuse issues.
> > 
> >    9.   security.  This entry accepts security issues.
> 
> Why have the attribute values been chosen to differ from those defined in IRIS-DREG?
> 
> >    10.  domainOwner.  This lists the owner of the domain.
> 
> This doesn't appear in RFC 3982.  How is the "owner" different from the "registrant"?

Even though the scheme seems to already be used, the duplication is confusing
from a DNS perspective and should be either explained or eliminated. (substantive)

> 
> >    11.  ipAddressOwner.  This entry identifies the assignee of the IP
> >         address space.
> 
> Which IP address space?
> 
> >    12.  hostingProvider.  This contact is the hosting provider of this
> >         domain.
> 
> At best, this should be _a_ provider, not _the_.
> 
> > 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.
> 
> > 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].
> 
> NIT: no longer an "internet-draft".
> 
> > 4.9.7.1.1.  Name element
> > 
> >    One STRING, representing the WINDOWS Operating System Registry Key
> >    Name.
> 
> Ouch;  shouldn't the document then at least have a reference to such Key Names' syntax?
> Better yet, no OS would be preferred over others and this be redefined as "vendor specific key" or similar.

Substantive IMHO.

> > 4.17.  EmailRecord element
> > 
> >    Extensions are also made to the iodef:Incident.EventData element to
> >    include the actual email message received in phishing lure or
> >    widespread spam emails.  The ability to report spam is included
> >    within a PhraudReport to support exchanging information about large-
> >    scale spam activities related to phishing, not necessarily a single
> >    spam message to a user.  As such the spam reporting mechanism was not
> >    designed to minimize overhead and processing, but to support other
> >    widely-used spam reporting formats such as the MAAWG's Abuse
> >    Reporting Format [ARF].
> > 
> >    Reporting of the actual mail message is supported by choosing one of
> >    three methods.  First, an ARF message may be included.  Second, the
> >    message may be included as one large string.  Third, the header and
> >    body components may be dissected and included as a series of strings.
> 
> [...]
> 
> > 4.17.2.2.  ARFText
> > 
> >    Zero or one value of STRING.  The Messaging Anti-Abuse Working Group
> >    (MAAWG) defined a format for sending abuse and list control traffic
> >    to other parties.  Since many of these reports will get integrated
> >    into incident processes, the raw Abuse Reporting Format [ARF] may be
> >    inserted into this element.
> 
> This seems to suggest a normative reference to the "Abuse Reporting Format", but the [ARF] reference is informative only and, more importantly, is MAAWG eligible for normative references at all?

Substantive.

> 
> > Appendix B.  Example Virus Report
> 
> The examples in this appendix contains lots of non-RFC2606 domain names and non-reserved IP addresses.

Regards,
  Peter