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