Real-time Inter-network Defense (RID)
draft-moriarty-post-inch-rid-12

[Ballot discuss]
Section 1., paragraph 1:
>    The XML schema [4] and transport requirements contained in this
>    document are normative, all other information provided is intended
>    as informative.  More specifically, the following sections of this
>    document are intended as informative: 1, 2, 3, the subsections of 4
>    including the introduction to 4, 4.1, and 4.2.
>    The following sections of this document are normative:
>    The sub-sections of 4 including 4.3, 4.4, 4.5, section 5,
>    and section 6.

  DISCUSS: With revision -11, this is now targeted to become an
  Informational RFC, which cannot have any normative parts. This is one
  symptom of the bigger issues with this document: it tries to publish a
  specification and a set of operational procedures defined by "another
  group" as an RFC, but the entire approach and chosen technologies are
  very different from what an IETF effort would result in. I'd really
  like to see an IESG Note on this document that makes this very clear.

[Ballot discuss]
Section 1., paragraph 1:
>    The XML schema [4] and transport requirements contained in this
>    document are normative, all other information provided is intended
>    as informative.  More specifically, the following sections of this
>    document are intended as informative: 1, 2, 3, the subsections of 4
>    including the introduction to 4, 4.1, and 4.2.
>    The following sections of this document are normative:
>    The sub-sections of 4 including 4.3, 4.4, 4.5, section 5,
>    and section 6.

  DISCUSS: With revision -11, this is now targeted to become an
  Informational RFC, which cannot have any normative parts. This is one
  symptom of the bigger issues with this document: it tries to publish a
  specification and a set of operational procedures defined by "another
  group" as an RFC, but the entire approach and chosen technologies are
  very different from what an IETF effort would result in. I'd really
  like to see an IESG Note on this document that makes this very clear.

[Ballot comment]
1. Section 1

    Note: The documented procedures represent the consensus of another
    group and are included to further describe environments where this
    schema can be used.  The documented procedures are not required for
    conformance to this specification.

The document refers to ‘another group’ – which other group? as this is an individual submission

2. Section 2:

    NPs typically manage and monitor their networks through a
    centralized network management system (NMS).  The acronym NMS will
    be used to generically represent management servers on a network
    used for the management of network resources.

The term ‘management server’ does not really mean anything. Many of the management applications are clients, or a combination of clients and servers using various protocols and interconnecting with various entities. Better use ‘management stations’ or ‘management systems’.

[Ballot comment]
#1) Header: r/Intended-status: Informational/Intended status: Informational

#2) As per IDNits: Update reference to 3281 with 5755 and 3330 with 5735.

#3) Sec 4.3.3.1: r/[RFC 5070]/[RFC5070]

#4) Sec 4.3.3.1: r/One.  Boolean./One.  BOOLEAN.

#5) Sec 4.3.3.2 & .3: r/IODEF 3.16/IODEF [RFC5070] section 3.16.

#6) Sec 4.3.3.3: r/See RFC5070]/See [RFC5070]

#7) Sec 6.3: r/Certificate Authority (CA)/Certification Authority (CA)

[Ballot discuss]
#1) As per IDNits: DOWNREF - to 3379 needs to be called out in IETF LC.  That's if you want to keep it.  I'm not sure you really need to point to 3379 if you're already pointing to 5280 for path validation.

#2) Reference [3], indicates the date is 2002, but the but when you follow the link it's to the '08 version.  Is this okay?  If you're trying to point to the 2002, then this is a better reference: http://www.w3.org/TR/2002/PR-xmlenc-core-20021003/#sec-Algorithms

#3) Reference [5]:

3.1) Indicates that the date is 2002, but when you follow the link it's to the '08 version.  Is this okay?  There are two additional canonical algorithms.  If you're trying to point to the 2002, then this is a better reference: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-Algorithms

3.2) Regardless of version you point to, they require SHA-1.  It is the only algorithm defined.  We've been working hard to provide algorithm agility in our protocols.  I think it's worth noting in the security considerations that the use of [5], currently, locks you in to using SHA-1.

#4) 4.3.3.1-3 uses "Optional" and "Required" to indicate whether an attribute is included in a class.  Shouldn't these be "OPTIONAL" and "REQUIRED"?

#5) Sec 6.1:

    RID systems MUST implement and deploy HTTPS
    and optionally support other protocols such as BEEP

I think you need to add a normative reference to HTTPS (RFC 2818) and an informative one to BEEP (RFC 3080).

[Ballot comment]
#1) Header: r/Intended-status: Informational/Intended status: Informational

#2) As per IDNits: Update reference to 3281 with 5755 and 3330 with 5735.

#3) Sec 4.3.3.1: r/[RFC 5070]/[RFC5070]

#4) Sec 4.3.3.1: r/One.  Boolean./One.  BOOLEAN.

#5) Sec 4.3.3.2 & .3: r/IODEF 3.16/IODEF [RFC5070] section 3.16.

#6) Sec 4.3.3.3: r/See RFC5070]/See [RFC5070]

#7) Sec 6.3: r/Certificate Authority (CA)/Certification Authority (CA)

[Ballot discuss]
#1) As per IDNits: DOWNREF - to 3379 needs to be called out in IETF LC.  That's if you want to keep it.  I'm not sure you really need to point to 3379 if you're already pointing to 5280 for path validation.

#2) Reference [3], indicates the date is 2002, but the but when you follow the link it's to the '08 version.  Is this okay?  If you're trying to point to the 2002, then this is a better reference: http://www.w3.org/TR/2002/PR-xmlenc-core-20021003/#sec-Algorithms

#3) Reference [5]:

3.1) Indicates that the date is 2002, but when you follow the link it's to the '08 version.  Is this okay?  There are two additional canonical algorithms.  If you're trying to point to the 2002, then this is a better reference: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-Algorithms

3.2) Regardless of version you point to, they require SHA-1.  It is the only algorithm defined.  We've been working hard to provide algorithm agility in our protocols.  I think it's worth noting in the security considerations that the use of [5], currently, locks you in to using SHA-1.

#4) 4.3.3.1-3 uses "Optional" and "Required" to indicate whether an attribute is included in a class.  Shouldn't these be "OPTIONAL" and "REQUIRED"?

#5) Sec 6.1:

    RID systems MUST implement and deploy HTTPS
    and optionally support other protocols such as BEEP

I think you need to add a normative reference to HTTPS (RFC 2818) and an informative one to BEEP (RFC 3080).

[Ballot comment]
1. In Section 5, the XML schema has an incorrect schemaLocation:



I think that should be:



2. Section 6 states:

    The specified transport protocols must use
    encryption to provide an additional level of security, integrity,
    and authentication through bi-directional certificate usage.

Do you mean "MUST" here?

Does "bi-directional certificate usage" mean mutual authentication? If so, let's state that.

3. In Section 3.2, should the "must" be "MUST" here?

    Trust relationships may also be defined through a bridged or
    hierarchical PKI in which both peers belong.

and here?

    Systems used to send authenticated RID messages between networks
    MUST use a secured system and interface to connect to a border
    Network's RID systems.  Each connection to a RID system must meet
    the security requirements agreed upon through the consortium
    regulations, peering, or SLAs.  The RID system must only listen for
    and send RID messages on the designated port, which also must be
    over an encrypted tunnel meeting the minimum requirement of
    algorithms and key lengths established by the consortium, peering,
    or SLA.  The selected cryptographic algorithms for symmetric
    encryption, digital signatures, and hash functions must meet
    minimum security levels of the times.  The encryption strength must
    adhere to import and export regulations of the involved countries
    for data exchange.

(There are similar issues in Section 6.3 regarding "may" and "must", and really throughout the document -- please check your usage of RFC 2119 terms for accuracy and consistency.)

4. In Section 7, we find:

      It should be noted, there are cases for
      transport where the RIDPolicy class MUST be presented in clear
      text as detailed in the transport document [RFCYYYY].

Here I think you want to replace "MUST" with "needs to" or somesuch.

[Ballot discuss]
1. The following text in Section 6.3 does not provide enough detail to ensure that any two given implementers can achieve interoperability:

    An optional extension to the authentication scheme would be to
    incorporate the use of attribute certificates to provide
    authorization capabilities as described in [RFC3281].  This may
    be useful as messages are sent from network peers to determine
    authorization levels based on the attribute information in the
    certificate, which could be used to determine priority of a trace
    request.  The attribute information might be used to determine if
    a request should be processed automatically or if human
    intervention is required.

If this cannot be specified in the requisite detail, perhaps it deserves to be deleted.

[Ballot comment]
1. In Section 5, the XML schema has an incorrect schemaLocation:



I think that should be:



2. Section 6 states:

    The specified transport protocols must use
    encryption to provide an additional level of security, integrity,
    and authentication through bi-directional certificate usage.

Do you mean "MUST" here?

Does "bi-directional certificate usage" mean mutual authentication? If so, let's state that.

3. In Section 3.2, should the "must" be "MUST" here?

    Trust relationships may also be defined through a bridged or
    hierarchical PKI in which both peers belong.

and here?

    Systems used to send authenticated RID messages between networks
    MUST use a secured system and interface to connect to a border
    Network's RID systems.  Each connection to a RID system must meet
    the security requirements agreed upon through the consortium
    regulations, peering, or SLAs.  The RID system must only listen for
    and send RID messages on the designated port, which also must be
    over an encrypted tunnel meeting the minimum requirement of
    algorithms and key lengths established by the consortium, peering,
    or SLA.  The selected cryptographic algorithms for symmetric
    encryption, digital signatures, and hash functions must meet
    minimum security levels of the times.  The encryption strength must
    adhere to import and export regulations of the involved countries
    for data exchange.

(There are similar issues in Section 6.3 regarding "may" and "must".)

[Ballot discuss]
SOAP has many security mechanisms. It is no clear to me which ones need to be implemented by a device implementing this protocol. Without specifying this I don't see how we will have interoperability.  Things like "you can use" digital signatures is pretty vague. Much of section 6 say that implementation need to do something but no idea of how to implement it. I imagine that informational would resolve most of this.

[Ballot comment]
1. Section 1

    Note: The documented procedures represent the consensus of another
    group and are included to further describe environments where this
    schema can be used.  The documented procedures are not required for
    conformance to this specification.

The document refers to ‘another group’ – which other group? as this is an individual submission

2. Section 2:

    NPs typically manage and monitor their networks through a
    centralized network management system (NMS).  The acronym NMS will
    be used to generically represent management servers on a network
    used for the management of network resources.

The term ‘management server’ does not really mean anything. Many of the management applications are clients, or a combination of clients and servers using various protocols and interconnecting with various entities. Better use ‘management stations’ or ‘management systems’.

3. SNMP and NETCONF should be informative references.

[Ballot discuss]
The document has a normative reference to RFCYYYY which is http://tools.ietf.org/html/draft-moriarty-post-inch-rid-transport-00 - i.e. a 00 draft now expired. This concerns me and I cannot judge whether RFCYYYY is complete enough and stable enough rpo provide together with this document a complete interoperable and functional solution.

[Ballot comment]
Abstract doesn't talk about "this document" which is a little unusal and
means that care has to be taken to understand the purpose of the I-D.
This could be fixed pretty easily.

---

It is usual for the first section (and therefor the first text) in the
body of the I-D to tbe Introduction

---

Section 1

    Note: The documented procedures represent the consensus of another
    group and are included to further describe environments where this
    schema can be used.  The documented procedures are not required for
    conformance to this specification.

This is a little mysterious. You have to get to Section 4 to find out
what "other group" is meant.

Note that it might be helpful to clarify that the "procedures" you
refer to are not protocol procedures (which is the type of procedure
we are used to seeing in IETF documents), but "incident handling
procedures."

It would be nice if Section 4 included references to other documents,
not just to the groups.

[Ballot comment]
Abstract doesn't talk about "this document" which is a little unusal and
means that care has to be taken to understand the purpose of the I-D.
This could be fixed pretty easily.

---

It is usual for the first section (and therefor the first text) in the
body of the I-D to tbe Introduction

---

Section 1

    Note: The documented procedures represent the consensus of another
    group and are included to further describe environments where this
    schema can be used.  The documented procedures are not required for
    conformance to this specification.

This is a little mysterious. You have to get to Section 4 to find out
what "other group" is meant.

Note that it might be helpful to clarify that the "procedures" you
refer to are not protocol procedures (which is the type of procedure
we are used to seeing in IETF documents), but "incident handling
procedures."

It would be nice if Section 4 included references to other documents,
not just to the groups.

[Ballot discuss]
I may be missing some context, but this looks like a substantial set of changes since the SOAP based document that was LCed in early 2008. Should the current document be IETF LCed?

[Ballot comment]
In Section 2, last paragraph:

Informative references for SNMP and NetConf are missing.

Informative references for HTTPS and BEEP are missing elsewhere.


4.3.3.1 RequestStatus Class

  AuthorizationStatus
    4. ext-value. An escape value used to extend this attribute.  See
        IODEF Section 5.1.

This needs a proper reference to RFC 5070.

  Justification
    6. ext-value. An escape value used to extend this attribute.  See
        IODEF Section 5.1.

As above.


4.4.1 TraceRequest

      Time Stamps (DectectTime, StartTime, EndTime, ReportTime)

Here and in several other sections: typo: DetectTime


10. Normative References

    [RFC3280] "Internet X.509 Public Key Infrastructure: Certificate
    and Certificate Revocation List (CRL) Profile." R. Housley, W.
    Ford, W. Polk, and D. Solo. April 2002.

RFC3280 --> RFC5280

[Ballot discuss]
AuthorizationStatus-ext
    Optional. STRING.  A means by which to extend the
    AuthorizationStatus attribute.  See IODEF Section 5.1.

  Justification-ext
    Optional. STRING.  A means by which to extend the Justification
    attribute.  See IODEF Section 5.1.

My reading of section 5.1 of RFC 5070 is that the two attributes must be named ext-AuthorizationStatus/ext-Justification, i.e. that "ext-" must be a prefix, not a suffix. Note that the schema section (section 5) has the correct names.

  MsgType-ext
    Optional. STRING.  A means by which to extend the MsgType
    attribute.  See IODEF Section 5.1.

  MsgDestination-ext
    Optional. STRING.  A means by which to extend the MsgDestination
    attribute.  See IODEF Section 5.1.

As above.


4.5.1.1 RID TraceRequest Example


 
   
   
      192.0.2.3/iodef:Address>

Typo in the closing tag: missing "<" before "/".

[Ballot comment]
In Section 2, last paragraph:

Informative references for SNMP and NetConf are missing.


4.3.3.1 RequestStatus Class

  AuthorizationStatus
    4. ext-value. An escape value used to extend this attribute.  See
        IODEF Section 5.1.

This needs a proper reference to RFC 5070.

  Justification
    6. ext-value. An escape value used to extend this attribute.  See
        IODEF Section 5.1.

As above.


4.4.1 TraceRequest

      Time Stamps (DectectTime, StartTime, EndTime, ReportTime)

Here and in several other sections: typo: DetectTime


10. Normative References

    [RFC3280] "Internet X.509 Public Key Infrastructure: Certificate
    and Certificate Revocation List (CRL) Profile." R. Housley, W.
    Ford, W. Polk, and D. Solo. April 2002.

RFC3280 --> RFC5280

[Ballot discuss]
AuthorizationStatus-ext
    Optional. STRING.  A means by which to extend the
    AuthorizationStatus attribute.  See IODEF Section 5.1.

  Justification-ext
    Optional. STRING.  A means by which to extend the Justification
    attribute.  See IODEF Section 5.1.

My reading of section 5.1 of RFC 5070 is that the two attributes must be named ext-AuthorizationStatus/ext-Justification, i.e. that "ext-" must be a prefix, not a suffix. Note that the schema section (section 5) has the correct names.

  MsgType-ext
    Optional. STRING.  A means by which to extend the MsgType
    attribute.  See IODEF Section 5.1.

  MsgDestination-ext
    Optional. STRING.  A means by which to extend the MsgDestination
    attribute.  See IODEF Section 5.1.

As above.


4.5.1.1 RID TraceRequest Example


 
   
   
      192.0.2.3/iodef:Address>

Typo in the closing tag: missing "<" before "/".

[Ballot comment]
In Section 2, last paragraph:

Informative references for SNMP and NetConf are missing.


4.3.3.1 RequestStatus Class

  AuthorizationStatus
    4. ext-value. An escape value used to extend this attribute.  See
        IODEF Section 5.1.

This needs a proper reference to RFC 5070.

  Justification
    6. ext-value. An escape value used to extend this attribute.  See
        IODEF Section 5.1.

As above.


4.4.1 TraceRequest

      Time Stamps (DectectTime, StartTime, EndTime, ReportTime)

Here and in several other sections: typo: DetectTime


10. Normative References

    [RFC3280] "Internet X.509 Public Key Infrastructure: Certificate
    and Certificate Revocation List (CRL) Profile." R. Housley, W.
    Ford, W. Polk, and D. Solo. April 2002.

RFC3280 --> RFC5280

[Ballot discuss]
This is discuss discuss that I will clear or clarify after the call. I am very worried about setting precedent of publishing documents from WG that did not achieve consensus.

I don't see support for publishing these as PS.

[Ballot discuss]
The use of SOAP in IETF protocols is an interoperability risk that isn't appropriate for an individual submission on Standards Track.  The framing that SOAP provides isn't necessary if something is to be a standard and therefore well-understood.

The draft doesn't motivate the use of SOAP despite declarations to the contrary.  Both HTTP and BEEP would allow messages in an INCH schema to be sent without the SOAP envelope.

The use of SOAP isn't sufficiently specified.  There's all kinds of options and flexibility.  Are headers required?  What about message paths?  When is fault signalling desired or required or not allowed, and which faults?  Are multiple header blocks allowed or forbidden?

Why are responses in plain HTTP and not SOAP?  That doesn't seem to be SOAP-compliant.

Support for chunked transfer-encoding is a MUST in HTTP, not a SHOULD.

I am unaware of any review by the XML Directorate or the Apps review team.  It's not that we require that for any doc with XML Schemas, but this proposal goes where IETF proposals don't usually go, and the XML Directorate has more experience with SOAP than the average IETFer.

[Ballot discuss]
The use of SOAP in IETF protocols is an interoperability risk that isn't appropriate for an individual submission on Standards Track.  The framing that SOAP provides isn't necessary if something is to be a standard and therefore well-understood.

The draft doesn't motivate the use of SOAP despite declarations to the contrary.  Both HTTP and BEEP would allow messages in an INCH schema to be sent without the SOAP envelope.

The use of SOAP isn't sufficiently specified.  There's all kinds of options and flexibility.  Are headers required?  What about message paths?

Why are responses in plain HTTP and not SOAP?  That doesn't seem to be SOAP-compliant.

Support for chunked transfer-encoding is a MUST in HTTP, not a SHOULD.

[Ballot discuss]
This discuss applies soley to draft-moriarty-post-inch-rid-soap.

The author has proposed resolution for issues Gen-ART and
Security Directorate reviews, which will require a new draft.  This
discuss is a placeholder for resolution of those issues.  I will move
back to YES once those issues have been resolved.

The reviews are appended below for completeness.  (BTW, I do not
believe the reference issues noted in the Gen-ART Review constitue
a downref.)

Gen-ART Review

Document: draft-moriarty-post-inch-rid-soap-05
Reviewer: Ben Campbell
Review Date:  2008-03-03
IESG Telechat date: 06 March 2008

Summary:

This document is almost ready for publication as a standards RFC, but
there are some nits that should be considered first.

Comments:

Disclaimers:

I am not an expert in SOAP wrapper specifications, and cannot offer
an informed opinion about whether this document is sufficiently
specified for that purpose. (I also note that there is controversy about
whether SOAP is appropriate for this sort of thing at all, but again,
hold no informed opinion.)

Additionally, the security considerations in this draft refer heavily
to the other RID documents. I am making the assumption that the
referenced documents sufficiently describe the security requirements
and potential attacks for RID in general. If that turns out not to be the
case, then the security consideration section of this document might
need some more meat.

Details:

I performed a Gen-ART review of version 3 of this draft. Most of my
specific comments have been resolved, but a few remain:

1) Since this document specifies SOAP over HTTP, I would like to see
at least one of the examples show the SOAP exchange in the context
of actual HTTP messages.

2) I am still not sure the reference for HTTP/TLS in section 1 is correct.
The original draft referenced RFC 4346 for HTTP/TLS, and I commented
that 4346 defines TLS, but not HTTP/TLS. The author changed the
wording to "HTTP over TLS V1.1 [RFC4346]", which technically solves
the problem, but we are then left with no normative reference for
HTTP/TLS at all. It may be that this is the best we can do, as the only
reference I could dig up for this is 2818, which is informational--but
it seems unsatisfying to not be able to come up with _some_ normative
reference for HTTP/TLS.

3) There are still IDNIT warnings, quoted below. There is something
in the reference formating that seems to confuse IDNits. I removed
warnings that were clearly [to me]  false.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
    current year


  == Outdated reference: A later version (-05) exists of
    draft-moriarty-post-inch-rid-02

  -- Possible downref: Non-RFC (?) normative reference: ref. '2'

  -- Possible downref: Non-RFC (?) normative reference: ref. '3'

  -- Possible downref: Non-RFC (?) normative reference: ref. '4'

  -- Possible downref: Non-RFC (?) normative reference: ref. '5'

--- Security Directorate Review (Glen Zorn) --------

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Security-related comments:

* I find it difficult to reconcile the statement in the Introduction
that "The Transport Layer Security (TLS) Protocol    [RFC4346] MUST be
followed for the implementation and deployment of this protocol." with
the one in section 5.1 that says "For transport confidentiality, TLS
(whether HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD
be used."; they seem at least somewhat contradictory.

* In the Security Considerations section, to say that "All security
considerations of related documents MUST be    considered, including
those in the following documents: the Incident Object Description
Exchange (IODEF), [RFCXXXX] and Real-time Inter-network Defense (RID)
[RFCYYYY]." seems simultaneously redundant (If considerations aren't
considered then what is done with them?) and non-specific (Are the
security considerations in the referenced documents especially
important?  If so, why?).

* The fact that "HTTP/TLS is not ideally suited for IODEF/RID transport"
is acknowledged in section 3.1 suggests that special attention should
have been paid to security threats against this transport, since the
re-use of protocols for purposes which they were not designed can often
expose previously undiscovered weaknesses.  However, it's not clear to
be that this analysis has been conducted.


A few general comments:

* Since the inch WG has concluded, it would be better to replace
"Extended Incident Handling Working Group" with "Network Working Group"
in the first page header.

* Section 3, last sentence says "Other protocol bindings may be defined
in separate documents."  However, the authors define another binding one
section later (not in a separate document.  Suggest changing to "This
does not preclude the definition of other protocol bindings (for
example, see Section 3.2)." or some such, or possibly just removing the
sentence.

* Some of the references are out of date: draft-ietf-inch-iodef-14.txt
was published as a Proposed Standard, RFC 5070
(http://www.ietf.org/rfc/rfc5070.txt), on 2007-12-17 &
draft-moriarty-post-inch-rid is now a -05.

* idnits generates a raft of other complaint, the most serious of which
are about lines that are too long.

[Ballot discuss]
This discuss applies soley to draft-moriarty-post-inch-rid-soap.

The author has proposed resolution for issues Gen-ART and
Security Directorate reviews, which will require a new draft.  This
discuss is a placeholder for resolution of those issues.  I will move
back to YES once those issues have been resolved.

The reviews are appended below for completeness.  (BTW, I do not
believe the reference issues noted in the Gen-ART Review constitue
a downref.)

Gen-ART Review

Document: draft-moriarty-post-inch-rid-soap-05
Reviewer: Ben Campbell
Review Date:  2008-03-03
IESG Telechat date: 06 March 2008

Summary:

This document is almost ready for publication as a standards RFC, but there are some nits that should be considered first.

Comments:

Disclaimers:

I am not an expert in SOAP wrapper specifications, and cannot offer an informed opinion about whether this document is sufficiently specified for that purpose. (I also note that there is controversy about whether SOAP is appropriate for this sort of thing at all, but again, hold no informed opinion.)

Additionally, the security considerations in this draft refer heavily to the other RID documents. I am making the assumption that the referenced documents sufficiently describe the security requirements and potential attacks for RID in general. If that turns out not to be the case, then the security consideration section of this document might need some more meat.

Details:

I performed a Gen-ART review of version 3 of this draft. Most of my specific comments have been resolved, but a few remain:

1) Since this document specifies SOAP over HTTP, I would like to see at least one of the examples show the SOAP exchange in the context of actual HTTP messages.

2) I am still not sure the reference for HTTP/TLS in section 1 is correct. The original draft referenced RFC 4346 for HTTP/TLS, and I commented that 4346 defines TLS, but not HTTP/TLS. The author changed the wording to "HTTP over TLS V1.1 [RFC4346]", which technically solves the problem, but we are then left with no normative reference for HTTP/TLS at all. It may be that this is the best we can do, as the only reference I could dig up for this is 2818, which is informational--but it seems unsatisfying to not be able to come up with _some_ normative reference for HTTP/TLS.

3) There are still IDNIT warnings, quoted below. There is something in the reference formating that seems to confuse IDNits. I removed warnings that were clearly [to me]  false.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
    current year


  == Outdated reference: A later version (-05) exists of
    draft-moriarty-post-inch-rid-02

  -- Possible downref: Non-RFC (?) normative reference: ref. '2'

  -- Possible downref: Non-RFC (?) normative reference: ref. '3'

  -- Possible downref: Non-RFC (?) normative reference: ref. '4'

  -- Possible downref: Non-RFC (?) normative reference: ref. '5'

--- Security Directorate Review (Glen Zorn) --------

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Security-related comments:

* I find it difficult to reconcile the statement in the Introduction
that "The Transport Layer Security (TLS) Protocol    [RFC4346] MUST be
followed for the implementation and deployment of this protocol." with
the one in section 5.1 that says "For transport confidentiality, TLS
(whether HTTP/TLS or the BEEP TLS profile) MUST be supported and SHOULD
be used."; they seem at least somewhat contradictory.

* In the Security Considerations section, to say that "All security
considerations of related documents MUST be    considered, including
those in the following documents: the Incident Object Description
Exchange (IODEF), [RFCXXXX] and Real-time Inter-network Defense (RID)
[RFCYYYY]." seems simultaneously redundant (If considerations aren't
considered then what is done with them?) and non-specific (Are the
security considerations in the referenced documents especially
important?  If so, why?).

* The fact that "HTTP/TLS is not ideally suited for IODEF/RID transport"
is acknowledged in section 3.1 suggests that special attention should
have been paid to security threats against this transport, since the
re-use of protocols for purposes which they were not designed can often
expose previously undiscovered weaknesses.  However, it's not clear to
be that this analysis has been conducted.


A few general comments:

* Since the inch WG has concluded, it would be better to replace
"Extended Incident Handling Working Group" with "Network Working Group"
in the first page header.

* Section 3, last sentence says "Other protocol bindings may be defined
in separate documents."  However, the authors define another binding one
section later (not in a separate document.  Suggest changing to "This
does not preclude the definition of other protocol bindings (for
example, see Section 3.2)." or some such, or possibly just removing the
sentence.

* Some of the references are out of date: draft-ietf-inch-iodef-14.txt
was published as a Proposed Standard, RFC 5070
(http://www.ietf.org/rfc/rfc5070.txt), on 2007-12-17 &
draft-moriarty-post-inch-rid is now a -05.

* idnits generates a raft of other complaint, the most serious of which
are about lines that are too long.

[Ballot comment]
From Ben Campbell's Gen-ART Review of
  draft-moriarty-post-inch-rid-soap-05.txt:

  Since this document specifies SOAP over HTTP, I would like to see 
  at least one of the examples show the SOAP exchange in the context of 
  actual HTTP messages.

  I am still not sure the reference for HTTP/TLS in section 1 is 
  correct. The original draft referenced RFC 4346 for HTTP/TLS, and I 
  commented that 4346 defines TLS, but not HTTP/TLS. The author changed 
  the wording to "HTTP over TLS V1.1 [RFC4346]", which technically 
  solves the problem, but we are then left with no normative reference 
  for HTTP/TLS at all. It may be that this is the best we can do, as the 
  only reference I could dig up for this is 2818, which is 
  informational--but it seems unsatisfying to not be able to come up 
  with _some_ normative reference for HTTP/TLS.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

Registration
ID URI template Reference
------ ------------------------- ------------ --------
iodef-rid-1.0 urn:ietf:params:xml:ns:iodef-rid-1.0 iodef-rid-1.0
[RFC-moriarty-post-inch-rid-02]


Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
------ ------------------------- ------------ --------
iodef-rid-1.0 urn:ietf:params:xml:schema:iodef-rid-1.0 iodef-rid-1.0
[RFC-moriarty-post-inch-rid-02]


We understand the above to be the only IANA Actions for this
document.