ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-ietf-forces-interop-07

2013-05-16 22:19:36
Hi Ben, 

Thank you very much for the review comments. Please see inline responses from 
authors of the document on the comments.

Hi Sherpherd and AD, 

we will update a version very soon. 

thanks a lot.
Weiming
 
----- Original Message ----- 
From: "Ben Campbell" <ben(_at_)nostrum(_dot_)com>

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-forces-interop-07
Reviewer: Ben Campbell
Review Date: 2013-05-13
IETF LC End Date: 2013-05-13
IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC. I 
have a few minor questions and editorial comments that may be worth considering 
prior to publication.

*** Major issues:

None.

*** Minor issues:

-- The draft mentions a couple of instances of tests that failed because of an 
incorrect implementation or differing encapsulation formats. Does this suggest 
that the specifications should be clarified? In particular, in the case of 
encapsulation format mismatch, should the specs include stronger requirements 
to be able to receive all encapsulation formats? Or should the number of 
options be reduced?
[Re. by ΕΗ] The protocol provides a number of different approaches 
[Re. by Weiming] The key issue is still from the deep understanding of the 
protocol from implementations. I still have not seen need for any urgent change 
for the protocol. 

-- I have a mild concern that the use of origin country names for each 
implementation could confuse readers into thinking that the countries 
themselves officially participated, rather than organizations from each country.


[Re by EH]Makes sense. We should possibly change this. 
In the beginning of section 2.2.1 where it says:
"The University of Patras implementation joined remotely from Greece"
Change to:
"The University of Patras (UoP) implementation joined remotely from Greece"
And then use UoP after that for us.

[Re. by Weiming] I agree with Evangelos on this. If possible (key issue might 
be the text space for some figures) we may change the G to UoP, the J to NTT, 
the C to ZJSU ? 
Other authors, please show your views. Thanks. 

-- section 4.4, last paragraph:

The text says that since the mentioned failures were likely the result of bugs, 
it doesn't indicate an interoperability problem in the specs. I have to point 
out that, it also doesn't prove interoperability in both directions for the 
particular test. It would also be worth commenting on whether the probably bugs 
were programming errors rather than misunderstandings of the specification.
[Re. by Weiming] to change the whole paragraph to:
  <t> The two test items failed. Note that Test #7 and #8 were identical to the 
tests, only with CE and FE implementers were exchanged. Moreover, test #12 and 
#13 showed that the redirect channel worked well. Therefore, it can be 
reasonably inferred that the problem caused the failure was from the 
implementations, rather than from the ForCES protocol itself or from 
misunderstanding of implementations on the protocol specification. Although the 
failure made the OSPF interoperability test incomplete, it did not show 
interoperability problem. More test work is needed to verify the OSPF 
interoperability.</t>

*** Nits/editorial comments:

-- The draft uses inconsistent verb tense throughout. I found this a bit 
confusing, as I assume the draft talks entirely about tests that have already 
occurred.
[Re. by ΕΗ] We will stick with the past tense.

-- IDNits points out that you have several references without explicit 
citations. I see that you called the references out by name in the text, but it 
would be better to include the citations.
[Re. by Weiming]We will try to fix this as much as possible.

-- Section 1, paragraph 6:

Please expand abbreviations on first mention.
[Re. by Weiming] Yes.

-- Section 1.1:

Please expand FE on first mention.
[Re. by Weiming] Yes.

-- section 2.2.2, paragraph 1: "... from China and Japan implementations..."

Missing "the".

Is it possible to add a reference for details on the Smartbits testing machine?

-- Figure 2:

Do you really want to publish the IP addresses used in an RFC? RFCs live 
forever...

-- Section 2.2.2, paragraph after figure 2: 

First sentence does not parse.

[Re. by Weiming] In Figure 2, changed the '124.90.146.218 (ADSL)' to ' (ADSL)'. 
 In Figure 3, changed the '150.140.254.110(VPN)' to '(VPN)' to avoid personal 
IP address in public.

Section 2.2.2, paragraph after figure 2, first sentence is changed to: 
<t>CE and FE from the Greece implementation were located within the
   University of Patras, Greece, and were connected together using LAN as 
   shown in <xref target="Figure-3"/>. Connetion to the Internet was via a VPN 
channel.
</t>
[/Re]

-- Figure 3:

The figure has some formatting issues, at least in the PDF version. Also, is it 
possible to avoid splitting the figure across the page break?

[Re. by Weiming] ok, we'll try.
[/Re]

-- section 3.2, paragraph 3: "Because of system deficiency to deploy IPSec over 
TML in Greece,..."

Phrase doesn't parse.

-- section 3.2, paragraph 4: "... over IPSec channel."

Missing "the".

"...to have established..."

to establish.
[Re. by Weiming] The section 3.2 para.3 has been changed to: 
<t>... Because there came unfortunately a problem with the test system in 
Greece to deploy IPSec over TML during the test process, this test only took 
place between test systems in China and Japan.</t>
Other nits are also corrected.
thanks.
[/Re]
-- section 4 and subsections:

It seems like some of the test descriptions in 4.X may be redundant to the 
previous scenario descriptions.

[Re. by Weiming] previous section 3.x is the scenario description, and the 4.x 
related section is the test results.

-- section 4.1, notes on 28 and 29:

Sentence does not parse.

... notes on 30 and 31:

Missing articles.
[Re. by Weiming]The two notes (Note on test #28 and #29 and note on test #30 
and #31 are vaguae.  After considerations, we decide to remove thess two notes. 
Thanks.
[/Re.]

-- section 5.1, last paragraph in list item "2.": "The interoperability test 
witnessed that..."

The test _showed_...   [or the _testers_ witnessed...]

[Re. by Weiming] modified to 'The interoperability testers witnessed that...".  
Thanks.
[/Re.]

-- section 9:

It would be worth mentioning that you explicitly tested for IPSec support.

[Re. by Weiming] As a result, the section has been updated as:

 9.  Security Considerations

   Developers of ForCES FEs and CEs must take the security
   considerations of the ForCES Framework [RFC3746]  and the ForCES
   Protocol [RFC5810]  into account.  Also, as specified in the security
   considerations section of the SCTP-Based TML for the ForCES Protocol
   [RFC5811], the transport-level security has to be ensured by IPsec.Test 
   results of TML with IPsec supported have been shown in Section 4.2 of the 
document. 
[/Re.]