Subject: [Gen-art] Gen-ART review of draft-moriarty-post-inch-rid-soap-03

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Feb 2008 16:17:07 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-moriarty-post-inch-rid-soap-03
Reviewer:  Ben Campbell
Review Date:  08-02-22
IETF LC End Date: 08-02-28
IESG Telechat date: (if known)

Summary: This document is almost ready for for publication as a  
proposed standard RFC, but there are some issues and questions that  
should be addressed first.

Comments:

General:

I think this document would benefit from some reorganization, as there  
are a lot of redundant statements between sections. For example, the  
argument about why HTTP is the baseline even though BEEP might be  
better is restated in several different sections for no apparent  
reason. Similarly, the reason for using SOAP in the first place is  
presented multiple times.

IDNITS

Section 1.1:

Why is this a subsection of section 1?

1.1, first paragraph:

Please expand CSIRTS and SOAP on first use.

1.1, last paragraph, last paragraph:

Need a normative reference for "Standards exist for the HTTPS or HTTP/ 
TLS binding for SOAP"

"Standards MUST be followed..." is too vague for a normative  
statement.  The document needs to specify which standards are required  
for each binding. I think you mean to say that RFC4346 must be  
followed, but there is too much digression between the first and last  
sentence of the paragraph for that to be obvious.

I think it would help to separate the rational for the binding choices  
from the statement about what standards must be implemented.

Section 2, paragraph 2:

The first sentence is very hard to parse.

Need a normative reference for the RID schema, and possibly for the  
RIDPolicy class.

3.1, paragraph 1, final sentence:

"Security is provided through the RID specification and all REQUIRED  
RID security MUST be implemented."

_What_ must implement the security requirements? All RID elements?  
Intermediaries?

3.2, paragraph 1:

How long should a device remember that it's peer doesn't implement  
BEEP? Surely not forever, or this would prevent anything from every  
upgrading to BEEP. I'm not looking for a precise state-machine, just  
some high-level guidance.

Section 5, general:

The security considerations here are highly dependent on those of the  
IODEF and RID. I have not studied those documents to see if they  
provide sufficient security considerations. Hopefully they go into  
more detail on potential vulnerabilities, the consequence of not using  
the confidentiality and authentication features, and when said  
security features need to be used.

Section 5, second paragraph:

I'm a little concerned about referencing the WS security document in  
passing like this with no elaboration.

5.2, paragraph 1:

Is TLS expected to be used for mutual authentication, or just server  
authentication?

Section 6:

Which port range should the ports be chosen from?

Section 7:

Is this section needed? It seems redundant with the abstract.

IDNITS complains about the following:

>   == The page length should not exceed 58 lines per page, but there  
> was 1
>      longer page, the longest (page 21) being 59 lines
>
>
>   == There are 1 instance of lines with non-RFC3330-compliant IPv4  
> addresses
>      in the document.  If these are example addresses, they should  
> be changed.
>
>   == Unused Reference: 'RFC2119' is defined on line 881, but no  
> explicit
>      reference was found in the text
>

_______________________________________________
Gen-art mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/gen-art

---

From: [email-masked]
Date: Mon, 25 Feb 2008 14:31:26 -0500

Hello Ben,

Thank you for the feedback.  I have addressed your comments and submitted an
updated draft.  I will outline below how the comments were addressed, please
let me know if there are any additional issues.

Thank you,
Kathleen

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 5:17 PM
To: [email-masked]
Cc: [email-masked]; Moriarty, Kathleen; [email-masked]
Subject: Gen-ART review of draft-moriarty-post-inch-rid-soap-03

Comments:

General:

>> I went through and removed redundant text and tried to put the text
>> for each of the areas in the correct locations.

IDNITS

Section 1.1:

1.1, first paragraph:

>> I expanded CSIRTs, but SOAP is no longer an acronym, so I did not
>> expand SOAP.

>>  Re-organized and referenced the necessary documents. 

>> Agreed, reworded the section.

>> OK.

Section 2, paragraph 2:

>> Reworded the sentence to address the issue.  Good catch, thank you.

>> Added reference to the RID schema.

>> A previous security AD had asked that all security stay in RID in
>> case transport changed down the road.  I removed some of this text,
>> I hope that addresses the concern.

3.2, paragraph 1:

>> I added some guidance, but said it should be configurable for length
>> and duration, recommended on week, but based on system resources.

Section 5, general:

>> Removed and re-worded.

5.2, paragraph 1:

>> Mutual authentication, good catch, thank you

Section 6:

>> Addressed

Section 7:

>> I typically have summary sections for papers, I thought that was
>> standard with these documents as well?

>      longer page, the longest (page 21) being 59 lines

OK

>      in the document.  If these are example addresses, they should  

Section number, not an IP

>      reference was found in the text

There was a space between RFC and 2119, fixed.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 25 Feb 2008 15:01:25 -0600

Hi, thanks for the quick response.

A few additional comments occurred to me since my original review--I  
apologize for not getting these in the first round:

1) I am not an expert on the conventions for defining SOAP wrappers-- 
but should this document include WSDL? (This is more of a question  
than a request for a change.)

2) It might be helpful to show at least one of the examples in the  
context of an actual HTTP exchange, i.e. an HTTP POST request and  
response.

3) You reference RFC 4346 for HTTP/TLS. RFC 4346 is for TLS 1.1  
itself, not really HTTP/TLS. That was actually defined in RFC 2818,  
which is unfortunately only an informational RFC. I'm not sure how  
this reference should be handled--it's probably worth getting some AD  
advice.

4) The URLs in your references [3] and [4] do not reference the  
described documents.

More inline (Note the original quoting is reversed for some reason):

On Feb 25, 2008, at 1:31 PM, [email-masked] wrote:

[...]

>>> for each of the areas in the correct locations.

That helps, thanks!

[...]

> Why is this a subsection of section 1?

This was not fixed in the new version. To be clear, the "introduction"  
section is a sub-section of the "terminology" section, which I don't  
think was the intent.

>>> I expanded CSIRTs, but SOAP is no longer an acronym, so I did not

Okay.

>>> Re-organized and referenced the necessary documents.

The reorganization helps, but see my comment about the RFC 4346  
reference above.

>>> Agreed, reworded the section.

Thanks

> from the statement about what standards must be implemented.

Thanks

>>> Reworded the sentence to address the issue.  Good catch, thank you.

It's better, thanks.

>>> Added reference to the RID schema.

Thanks.

>>> I hope that addresses the concern.

It addresses my concern, assuming that the removal of text does not  
cause issue for someone else.

>>> and duration, recommended on week, but based on system resources.

That addresses my concern, and then some :-) Thanks.

> passing like this with no elaboration.

I don't see the change--the paragraph seems to be the same as before.

>>> Mutual authentication, good catch, thank you

Thanks.

> Which port range should the ports be chosen from?

Thanks

>>> standard with these documents as well?

I don't know of any rule against such a section, although drafts and  
RFCs do have the initial abstract, which seems to me to serve the same  
purpose.

>>     longer page, the longest (page 21) being 59 lines

IDNits no longer complains about this

> Section number, not an IP

Okay.

That warning went away in IDNits, but there are new warnings:

>   Miscellaneous warnings:
>    
> ----------------------------------------------------------------------------
>
>   == The copyright year in the IETF Trust Copyright Line does not  
> match the
>      current year
>
>
>   Checking references for intended status: Proposed Standard
>    
> ----------------------------------------------------------------------------
>
>      (See RFCs 3967 and 4897 for information about using normative  
> references
>      to lower-maturity documents in RFCs)
>
>   ** Downref: Normative reference to an Unknown state RFC: RFC 3080
>
>   ** Downref: Normative reference to an Unknown state RFC: RFC 3205
>
>   ** Downref: Normative reference to an Unknown state RFC: RFC 3275
>
>   ** Downref: Normative reference to an Unknown state RFC: RFC 4227
>
>   ** Downref: Normative reference to an Unknown state RFC: RFC 4346
>
>   -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX'
>
>   == Outdated reference: A later version (-04) exists of
>      draft-moriarty-post-inch-rid-02
>
>   -- Possible downref: Non-RFC (?) normative reference: ref. '3'
>
>   -- Possible downref: Non-RFC (?) normative reference: ref. '4'
>
>   -- Possible downref: Non-RFC (?) normative reference: ref. '5'
>

---

From: [email-masked]
Date: Mon, 25 Feb 2008 16:40:37 -0500

Hi Ben,

I will try to get the update out before the 5 PM cut off.  As for #1, Brian
could answer that question better than I could.  There was a reason that we
just referenced WSDL as an ancillary tool.  I'll leave that alone for now
unless Brian or someone else points out the need to revisit the topic.

#2 I don't think I can get an example done by 5 unless Brian can get that to
me before then and I'll add in a section for that.

#3, you are correct and I made the adjustment to the text so that it says
HTTP with TLS v1.1 [RFC4346]

#4 Updated the URLs, new versions were published, Thank you!

I will have a version posted in a few minutes with the next number.  If I
hear from Brian, I may add an example as requested.

Thank you,
Kathleen

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 4:01 PM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Gen-art] Gen-ART review of
draft-moriarty-post-inch-rid-soap-03

[...]

That helps, thanks!

[...]

Okay.

Thanks

Thanks

It's better, thanks.

Thanks.

Thanks.

Thanks

Okay.