Real-time Inter-network Defense (RID)
RFC 6045

Note: This ballot was opened for revision 12 and is now closed.

(Lisa Dusseault) Discuss

Discuss (2008-03-05 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Cullen Jennings) (was No Record, Discuss) Discuss

Discuss (2010-01-21 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Tim Polk) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

Comment (2008-03-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
XXXX = 5070

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ross Callon) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2010-01-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley) (was No Record, No Objection) No Objection

Comment (2008-03-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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.

Alexey Melnikov (was Discuss) No Objection

Comment (2010-05-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
In Section 2, last paragraph:

Informative references for SNMP and NetConf are missing.

Informative references for HTTPS and BEEP are missing elsewhere.

(Dan Romascanu) (was Discuss) No Objection

Comment (2010-06-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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’.

(Peter Saint-Andre) (was Discuss, No Objection) No Objection

Comment (2010-06-02)
No email
send info
1. In Section 5, the XML schema has an incorrect schemaLocation:

<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="urn:ietf:params:xml:ns:iodef-1.0"/>

I think that should be:

<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
 schemaLocation="http://iana.org/iodef/ietf-inch-rid-1.0.xsd"/>

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.

(Robert Sparks) (was No Record, Discuss) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2010-06-02)
No email
send info
#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)

Magnus Westerlund No Objection