Subject: [Gen-art] Gen-ART review of draft-ietf-rmt-pi-alc-revised-08.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 21 Sep 2009 10:04:38 +0200

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-ietf-rmt-pi-alc-revised-08.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2009-09-21
IETF LC End Date: 2009-09-22

Summary: The document is almost ready for publication as a standards 
track RFC. There are a few minor issues and nits that should be polished 
before publication.

Major issues: none

Minor issues:

- According to idnits, the document makes a downref normative reference 
to RFC 3738, which is an experimental RFC. According to RFC 3967, I 
believe this downref is needed and appropriate. According to the process 
described in RFC 4897 Section 4, a caution annotation should be added to 
this I-D:

    o  A note is included in the reference text that indicates that the
       reference is to a target document of a lower maturity level, that
       some caution should be used since it may be less stable than the
       document from which it is being referenced, and, optionally,
       explaining why the downward reference is appropriate.

So, the action goes to the authors to add a note indicating that RFC 3738 
is an experimental RFC and some caution should be used since it may be 
less stable than this document. This note should go right after the first 
paragraph in Section 2.2, when RFC 3738 is mentioned first.

- The text, towards the end of Section 1.3, reads:

                                                To ameliorate
    these concerns, it is RECOMMENDED that the RP be as close to the
    sender as possible.

I think this text does not make sense with RFC 2119 wording. This is a 
deployment recommendation, for which the protocol designer has no action 
to improve or control. There is nothing that can be tested in an 
interoperability test. So, I think there is no point in having RFC 2119 
strength in this sentence (I am assuming that the target reader is the 
protocol implementor, not the deployment manager). I think the text 
should change to illustrate that this is a recommendation for a different 
audience, and should not use RFC 2119 wording.

- Section 2.4 says:

    The Session Description that a receiver is REQUIRED to obtain before
    joining an ALC session MUST contain the following information:

First, I have a problem with the "REQUIRED". This normative text is 
written in a dependent clause, so, it is kind of hiding behind the main 
sentence.

Second, I am not sure if there is a justification for the REQUIRED and 
MUST in this sentence. I understand these terms, according to RFC 2119, 
as an imperative for the protocol to work. However, in your I-D, the text 
is describing a need more than a requirement for the protocol 
implementor. I would understand that an implementation MUST send some 
data, or MUST parse some data upon reception, but the "MUST aquire" sound 
a bit strange, because it does not put a requirement on the protocol 
implementation. Also, notice that the document leaves the session 
description aspects outside the scope of the I-d (to reinforce my sentiment).

So, my recommendation is that this first sentence merely says:

    Before a receiver can join an ALC session, the receiver needs to
    obtain a session description that contains the following information:

- Section 4.3, second paragraph. The text reads:

    A sender using ALC MUST make available the required Session
    Description as described in Section 2.4.

   I think this text is unimplementable and un-testable (at least the 
"MUST), especially considering that Section 2.4 says that session 
description aspects are outside the scope of the document. I think the 
MUST should be replaced by a "should" (yes, in lowercase).

- Similarly, in Section 4.4, second paragraph, the text reads:

    To be able to participate in a session, a receiver MUST obtain the
    REQUIRED Session Description as listed in Section 2.4.  How receivers
    obtain a Session Description is outside the scope of this document.

As discussed later, the "MUST" should be replaced by a "needs", and the 
"REQUIRED" should be replaced by a "required".

- Similary, in Section 4.4, third paragraph, the text reads:

    As described in Section 2.3, a receiver MUST obtain the required FEC
    Object Transmission Information for each object for which the
    receiver receives and processes packets.

I think the "MUST" should be replaced by a "needs".

Nits/editorial comments:

- Expand acronyms at first occurrence. This includes: "SSM", "MSDP".

- The Introduction section should be descriptive and not normative in 
nature. So, I would not expect to find any normative strength words (RFC 
2119) anywhere in Section 1. However, at the end of Section 1.3, there is 
a "RECOMMENDED". If the text persists (see my previous comment in which I 
recommend to use a non-RFC 2119 wording), perhaps should be moved outside 
Section 1.

- Section 1.3, second paragraph, 8th line:
s/may also uses/may also use

- An informative reference to MSDP protocol would be nice (Section 1.3).

- Section 2, 4th paragraph. A figure that illustrates the wording would 
be nice.

- Section 4.1, 1st paragraph. The text reads:

                                The Congestion Control Information
    field in the LCT header contains the REQUIRED Congestion Control
    Information that is described in the multiple rate congestion control
    building block used.

   I think the term "REQUIRED" is merely and adjective and, consequently, 
not subject to RFC 2119 wording. I think it should be written in lower case.

- Section 5.1.2.2,
s/protocol implementation ./protocol implementation.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 21 Sep 2009 08:58:19 -0700

Miguel,

Thanks for your comments. I agree with them all and will make the suggested changes in the next draft.

Regards,

Mark Watson

On 9/21/09 1:04 AM, "Miguel A. Garcia" <[email-masked]> wrote:

Major issues: none

Minor issues:

                                                To ameliorate

- Section 2.4 says:

Nits/editorial comments:

- Section 5.1.2.2,

/Miguel

--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain