Re: [mile] WG Last call

[<[e-mail]>]

Hi Paul,

Thank you again for the detailed review!

We went back and forth to come to a working group consensus in INCH as to how this should be approached and eventually wound up with the current solution using peer documents.  It would be easy to include an optional element as suggested, but this would break compatibility.  Are there opinions from the MILE WG?

The reasons for the separate schemas listed as peers was to help prevent schema validation issues and reduce potential problems.  

Thank you,
Kathleen  (as document editor)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Cichonski, Paul
Sent: Sunday, December 04, 2011 5:49 PM
To: [e-mail]
Subject: Re: [mile] WG Last call

Sorry to follow-up on my own post, but I was thinking a bit more about the "enveloping" relationship, and was just wondering why a RID instance document does not actually include an iodef:IODEF-Document element as one of the optional elements of the rid:RID element?

[Note that I was inferring (possibly incorrectly) a lot about the RID usage patterns when writing the below comments, so please take them with a grain of salt.]

It would seem that this type of true enveloping relationship would be beneficial to RID consumers since in most of the cases (e.g., those that require an IODEF document along with the RID message) it will be necessary for the consumer to determine which IODEF-Document relates to the RID message that was received. Without an explicit specification of how to resolve this correlation the consumer is not guaranteed to resolve the correct IODEF-Document. Going a step further, it would also be possible to include a dsig:Signature element within the Rid element so that all information is fully contained within the RID envelope (see section 3.10 of the SCAP 1.2 specification to see how this is done within the context of SCAP 1.2 documents: http://csrc.nist.gov/publications/nistpubs/800-126-rev2/SP800-126r2.pdf). 

Another way to ensure that the IODEF-Document is resolved correctly is to formally specify that the iodef:IncidentId in the RID document points to the associated iodef:IncidentID in the IODEF document. I think this logic is implicit in the current draft, but it would be helpful to call it out formally. Also, i am not positive this will always work since the iodef:IncidentId is not a required element in the  RIDPolicy element.

To provided a somewhat related example from the SCAP space, the SCAP specification started out with all of the disparate components (e.g., XCCDF, OVAL, CPE, etc…) being disparate XML documents and the only rule was that they all had to be in the same ZIP bundle to allow a consumer to compile the the cross-document relationships in memory. However, the lack of formalization caused problems for consumers; the new strategy (in SCAP 1.2, referenced above) is to include all the disparate components in a higher-level element named 'data-stream' that wraps everything in one document to provide more context and make the cross-component relationships more explicit.

As a side note, the examples in section 6 of the RID draft include xml comments (i.e., "<!-- -->") between the iodef-rid:RID and iodef:IODEF-Document root elements, which leads the reader to believe that there is some higher-level root element that wraps these elements (and the XML dsig Envelope), but I am guessing that was not intentional.

This has probably all been discussed in detail at some point in RID's history so I apologize if I am repeating old issues.

-Paul
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Cichonski, Paul [[e-mail]]
Sent: Sunday, December 04, 2011 3:38 PM
To: [e-mail]; [e-mail]
Subject: Re: [mile] WG Last call

Hi Kathleen,

I just have a few minor comments below relating to the "Real-time Inter-network Defense (RID) draft-moriarty-mile-rfc6045-bis-02.txt" document. Other than these comments, both documents look good to me.

Section: Introduction, fifth paragraph:

For the sentence "The RID schema acts as an XML envelope to support the communication of IODEF documents for exchanging or tracing information regarding incidents". It may help clarify things if a different word than 'envelope' was used here, since [to me] it suggests that RID documents will actually envelope IODEF documents. However, based on the examples and schema, the intended usage is for a RID document to be a peer to IODEF in the transport scenarios, so no enveloping is occurring. Would suggest a phrase like "The RID schema defines communication-specific metadata to support the communication of ...."

Section: Introduction, fifth paragraph:

In the second to last sentence, the citation [RFC6046-bis] is duplicated.

Section 3.1, first paragraph:

I think there may be a typo in the start of the sentence: "RID provides a standard protocol and format is required to ensure", probably should be "RID provides a standard protocol and format that is required to ensure". (added 'that').

Section 4, first paragraph:

In the first sentence, it may be helpful to add clarification relating to the phrase "RID extension". Specifically, the thing that RID is extending. If you mean that RID is extending IODEF, I am not sure I like the term 'extend', since RID is really just importing the IODEF data model and using some of the elements that IODEF defines, but not extending any of the IODEF types, thus the word 'extend' may confuse developers that are reading the spec.

Section 4, second paragraph:

Relating to the first sentence, just repeating my previous comment from the intro section: "It may help clarify things if a different word than 'envelope' was used here, since [to me] it suggests that RID documents will actually envelope IODEF documents. However, based on the examples and schema, the intended usage is for a RID document to be a peer to IODEF in the transport scenarios, so no enveloping is occurring. "

Section 6:

One overall comment for the diagrams in this section: it may help to include the IP address of "things" (e.g., Attack Dest, SP-1, SP-2, etc..) if possible to help readers understand the example XML, specifically the places where IP addresses are listed.

Section 6.2, diagram:

A result message is shown in the diagram, but no result xml is provided in the following sub-sections. A RequestAuthorization is listed instead. If the sub-sections are intended to describe the diagram this should be changed.

Section 6.4.1, first paragraph,

This paragraph lists the different types of formats the IncidentQuery may be sent as, but does not say what the example xml illustrates (e.g., what type). Suggest adding some text to second sentence saying that the type described in that sentence is illustrated in the example XML (at least I think it is).

Section 7, schema.

For the first import (urn:ietf:params:xml:ns:iodef-1.0), guessing this is supposed to point to IODEF schema and not IODEF-RID:�http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd.

Thanks,
Paul




________________________________________
From: [e-mail] [[e-mail]] On Behalf Of [e-mail] [[e-mail]]
Sent: Friday, December 02, 2011 3:11 PM
To: [e-mail]
Subject: [mile] WG Last call

FYI - two documents wrap up Working Group Last Call (WGLC) at end of day on Monday.  Please share your comments on the list or that you have read the documents and have no comments/issues.

Thank you and have a nice weekend!
Kathleen



_______________________________________________
mile mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
mile mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mile
_______________________________________________
mile mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mile