Subject: [appsdir] Fwd: Peter Saint-Andre's Discuss on draft-ietf-mile-rfc6045-bis-06: (with DISCUSS and COMMENT)

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jan 2012 17:48:26 -0700

And a third. :)

-------- Original Message --------
Subject: Peter Saint-Andre's Discuss on draft-ietf-mile-rfc6045-bis-06:
(with DISCUSS and COMMENT)
Date: Wed, 18 Jan 2012 16:42:37 -0800
From: Peter Saint-Andre <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Peter Saint-Andre has entered the following ballot position for
draft-ietf-mile-rfc6045-bis-06: 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:
----------------------------------------------------------------------

First, I'd like to thank you for addressing the comments provided by
Larry Masinter in his Apps Directorate review.

There are a few topics I'd like to chat about.

1. The document does not pass ID-nits! You might need to fix the
document in order to address the following errors and warnings:

  == Missing Reference: 'XMLschema' is mentioned on line 3519, but not
defined

  == Missing Reference: 'RFC5735' is mentioned on line 1811, but not defined

  == Unused Reference: 'CVRF' is defined on line 3720, but no explicit
     reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 3741

  ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)

  ** Downref: Normative reference to an Informational RFC: RFC 6046

2. This document inherits the definition of Node from the NodeName class
in RFC 5070. Although the IODEF specification defines a NodeName as a
fully-qualified domain name, it does not provide a definition of that
term and specifically does not say whether internationalized domain
names (IDNs) are allowed. This is a significant oversight for a modern
protocol.

3. The definition of AcrossNationalBoundaries is confusing. First it
says that this value must "MUST"?) be set if the message will cross
national boundaries (and how exactly is the sender to determine whether
the the message will in fact cross national boundaries?). Then it says
that this value is ("MUST BE"?) used when additional handling and
protection restrictions based on the data type and location, which is
not the same thing as crossing national boundaries. Then it says that
this value must be set if the security requirements of the message might
not apply to all nations. Then it says that this value must be set if
the traffic is of a type that may have different restrictions in other
nations. This is such a muddle that I don't see how an SP could choose
any value other than AcrossNationalBoundaries.

4. In Section 7, some of the examples include XML comments. Are these
allowed? Are any other aspects of XML disallowed (e.g., processing
instructions and external DTD subsets)? Can conforming applications
ignore or reject such data? I think the processing rules and security
considerations are underspecified here. At the least, it would be
helpful to cite RFC 3270 and RFC 3023 with regard to the use of XML in
IETF application protocols.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The Introduction would be easier to read if the summary of changes since
RFC 6045 were moved to an Appendix.

Please expand "FBI" on first use, preferably via "U.S. Federal Bureau of
Investigations (FBI)".

Section 4.1.1 introduces the BOOLEAN data type, which is implemented as
the xs:boolean type from W3C XML Schema. It would be helpful to note
that there are two lexical representations of boolean in XML schema. I
suggest changing the text as follows.

OLD
   The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
   the schema.

NEW
   The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
   the schema.  Note that there are two lexical representations for
   boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false'
   for FALSE.

In Section 5, why is this document defining a 'lang' attribute when any
XML data can include the 'xml:lang' attribute via inheritance from the
core XML specificiation?

The class definitions are inconsistent. I see several styles, such as:

   One.
   Zero or one.
   One or more.  REQUIRED.
   REQUIRED.  ENUM.
   One or many.  REQUIRED.
   Zero or One. URL.
   Zero to many.

It would help to make those consistent.

Section 5.1 states:

   The RIDPolicy Class includes the ability to embed an IODEF or
   other XML schema document in the ReportSchema element.

I don't think you're embedding XML schema documents, I think you're
embedding XML documents that conform to schemas other than IODEF.

Section 5.1 states:

   PolicyRegion

      One or more.  REQUIRED.  The values for the attribute "region" ....

Is that supposed to be "PolicyRegion"?

In Section 5.1.1, is "XMLDocumen" a typo?

In Section 5.3, why is the IncidentSource restricted to FQDNs (Nodes)?
It seems that the source of an incident might be an IP address, an email
address, etc.

This text in Section 5.4 is confusing:

   The RID schema declares a namespace of "iodef-rid-2.0" and registers
   it per [XMLNames].  Each IODEF-RID document MUST use the
   "iodef-rid-2.0" namespace in the top-level element RID-Document.

In fact the namespace is not "iodef-rid-2.0" but
"urn:ietf:params:xml:ns:iodef-rid-2.0". In addition, the "Namespaces in
XML 1.0" specification says nothing about registration of XML
namespaces; perhaps you meant to cite RFC 3688?

In Section 5.5.1, do you really intend to include schemas, or documents
defined by other schemes?

The text in Section 6 is a bit misleading when it says that "The IODEF
model MUST be fully implemented to ensure proper parsing of all RID
messages." That's true only for RID messages that contain IODEF
payloads, not RID messages that contain payloads defined by other schemas.

In Section 8, the XML comment is quite distracting. Why not include this
information in the xs:annotation element?

Section 9.1 states:

   o  The originator of a Request MUST use a detached signature to sign
      at least one of the original elements contained in the RecordItem
      class to provide authentication to all upstream participants in
      the trace or those involved in the investigation.

Is this required even in cases where channel encryption (e.g., TLS) is
used between the parties to a PeerToPeer exchange that doesn't involve
upstream participants? (By the way, it seems that some of the examples
in the spec violate the rule from SEction 9.1.)

In Section 9.1, do you mean "MAY" in the text "The IODEF/RID document
may be encrypted"? The same question applies to "The action taken in the
Result message may be encrypted". The difference between conformance and
normal usage is especially confusing in a sentence like this:

   A Request, or any other message type that may be relayed through
   RID systems other than the intended destination as a result of
   trust relationships, may be encrypted for the intended recipient.

I encourage you to check all the text in Section 9.1 (and elsewhere)  to
make it clear whether you intend your guidelines to have conformance force.

It's a bit confusing to say in Section 9.1 "See Section 9 for a
discussion on public key infrastructure (PKI) and other security
requirements." I think you mean Section 9.3. :)

Section 9.2 states:

   The transport specifications are fully defined in a separate document
   [RFC6046-bis].

I think you mean "A transport specification" because it seems that you
are leaving the door open to defining other transport bindings in the
future.

Section 9.2 states:

   The RID protocol must be able to guarantee delivery and meet the
   necessary security requirements of a state-of-the-art protocol.  In
   order to guarantee delivery, TCP should be considered as the
   underlying protocol within the current network standard practices.

There's a lot more to truly guaranteed delivery at the application layer
than simply using TCP as the underlying transport. Do you mean at least
once delivery, at most once, or something else? Do messages need to be
persisted in case the messaging system crashes? And so on. You might
consider dropping this paragraph, or clarifying what you really mean by
guaranteed delivery.

I find this a bit confusing:

   Consortiums may vary their selected transport mechanisms and thus
   decide upon a mutual protocol to use for transport when communicating
   with peers in a neighboring consortium using RID.  RID systems MUST
   implement and deploy HTTPS as defined in the transport document
   [RFC6046-bis] and optionally support other protocols such as the
   Blocks Extensible Exchange Protocol (BEEP) [RFC3080].

If consortia are allowed to decide upon their own preferred transport
bindings, why is HTTP/TLS a MUST-deploy technology?

As to "optionally support other protocols", clearly someone would need
to define bindings for those protocols (BEEP or XMPP or SIP or whatever)
before they could be used -- it appears that one can't simply start
sending RID documents over those protocols without some definition of
the binding (as is already done for things like SOAP). So the current
text is a bit misleading.

Section 11 states:

      Registrant Contact: See the "Author's Address" section of this
      document.

However, RFC 3688 states:

   In the case of IETF developed standards, the Registrant will be the IESG.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 18 Jan 2012 17:00:37 -0800

My concern about the document was that they were using controlled vocabularies without a process for converging on meanings in those vocabularies, and I gave a couple of examples. They fixed the examples but didn't actually address the core of the problem that I was trying to raise.

The " AcrossNationalBoundaries" is just an example. But I don't know how to teach the design issue around controlled vocabularies and standards.

Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Wednesday, January 18, 2012 4:48 PM
To: [email-masked]
Subject: [appsdir] Fwd: Peter Saint-Andre's Discuss on draft-ietf-mile-rfc6045-bis-06: (with DISCUSS and COMMENT)

And a third. :)

-------- Original Message --------

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

First, I'd like to thank you for addressing the comments provided by Larry Masinter in his Apps Directorate review.

1. The document does not pass ID-nits! You might need to fix the document in order to address the following errors and warnings:

  == Missing Reference: 'XMLschema' is mentioned on line 3519, but not defined

2. This document inherits the definition of Node from the NodeName class in RFC 5070. Although the IODEF specification defines a NodeName as a fully-qualified domain name, it does not provide a definition of that term and specifically does not say whether internationalized domain names (IDNs) are allowed. This is a significant oversight for a modern protocol.

3. The definition of AcrossNationalBoundaries is confusing. First it says that this value must "MUST"?) be set if the message will cross national boundaries (and how exactly is the sender to determine whether the the message will in fact cross national boundaries?). Then it says that this value is ("MUST BE"?) used when additional handling and protection restrictions based on the data type and location, which is not the same thing as crossing national boundaries. Then it says that this value must be set if the security requirements of the message might not apply to all nations. Then it says that this value must be set if the traffic is of a type that may have different restrictions in other nations. This is such a muddle that I don't see how an SP could choose any value other than AcrossNationalBoundaries.

4. In Section 7, some of the examples include XML comments. Are these allowed? Are any other aspects of XML disallowed (e.g., processing instructions and external DTD subsets)? Can conforming applications ignore or reject such data? I think the processing rules and security considerations are underspecified here. At the least, it would be helpful to cite RFC 3270 and RFC 3023 with regard to the use of XML in IETF application protocols.

The Introduction would be easier to read if the summary of changes since RFC 6045 were moved to an Appendix.

Please expand "FBI" on first use, preferably via "U.S. Federal Bureau of Investigations (FBI)".

Section 4.1.1 introduces the BOOLEAN data type, which is implemented as the xs:boolean type from W3C XML Schema. It would be helpful to note that there are two lexical representations of boolean in XML schema. I suggest changing the text as follows.

OLD

NEW

In Section 5, why is this document defining a 'lang' attribute when any XML data can include the 'xml:lang' attribute via inheritance from the core XML specificiation?

   One.
   Zero or one.
   One or more.  REQUIRED.
   REQUIRED.  ENUM.
   One or many.  REQUIRED.
   Zero or One. URL.
   Zero to many.

Section 5.1 states:

I don't think you're embedding XML schema documents, I think you're embedding XML documents that conform to schemas other than IODEF.

Section 5.1 states:

   PolicyRegion

In Section 5.3, why is the IncidentSource restricted to FQDNs (Nodes)?
It seems that the source of an incident might be an IP address, an email address, etc.

In fact the namespace is not "iodef-rid-2.0" but "urn:ietf:params:xml:ns:iodef-rid-2.0". In addition, the "Namespaces in XML 1.0" specification says nothing about registration of XML namespaces; perhaps you meant to cite RFC 3688?

In Section 5.5.1, do you really intend to include schemas, or documents defined by other schemes?

The text in Section 6 is a bit misleading when it says that "The IODEF model MUST be fully implemented to ensure proper parsing of all RID messages." That's true only for RID messages that contain IODEF payloads, not RID messages that contain payloads defined by other schemas.

In Section 8, the XML comment is quite distracting. Why not include this information in the xs:annotation element?

Section 9.1 states:

Is this required even in cases where channel encryption (e.g., TLS) is used between the parties to a PeerToPeer exchange that doesn't involve upstream participants? (By the way, it seems that some of the examples in the spec violate the rule from SEction 9.1.)

In Section 9.1, do you mean "MAY" in the text "The IODEF/RID document may be encrypted"? The same question applies to "The action taken in the Result message may be encrypted". The difference between conformance and normal usage is especially confusing in a sentence like this:

I encourage you to check all the text in Section 9.1 (and elsewhere)  to make it clear whether you intend your guidelines to have conformance force.

It's a bit confusing to say in Section 9.1 "See Section 9 for a discussion on public key infrastructure (PKI) and other security requirements." I think you mean Section 9.3. :)

Section 9.2 states:

I think you mean "A transport specification" because it seems that you are leaving the door open to defining other transport bindings in the future.

Section 9.2 states:

There's a lot more to truly guaranteed delivery at the application layer than simply using TCP as the underlying transport. Do you mean at least once delivery, at most once, or something else? Do messages need to be persisted in case the messaging system crashes? And so on. You might consider dropping this paragraph, or clarifying what you really mean by guaranteed delivery.

If consortia are allowed to decide upon their own preferred transport bindings, why is HTTP/TLS a MUST-deploy technology?

As to "optionally support other protocols", clearly someone would need to define bindings for those protocols (BEEP or XMPP or SIP or whatever) before they could be used -- it appears that one can't simply start sending RID documents over those protocols without some definition of the binding (as is already done for things like SOAP). So the current text is a bit misleading.

Section 11 states:

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