Alfred,
Thanks for these comments. Please find my responses and proposed actions
inline below.
Best regards,
Mark Watson
On 4/3/09 9:28 AM, "ah(_at_)tr-sys(_dot_)de" <ah(_at_)tr-sys(_dot_)de> wrote:
I have studied your Internet-Draft in IETF Last Call,
draft-ietf-rmt-bb-lct-revised-09,
and would like to submit a few comments.
(A) Prose++
I personally would have appreciated it very much if the
lengthy prose in Sections 1..4, with all of these more-or-less
repetitions of similar arguments (some of which discussed again
in Sections 6..8), would have been condensed by at least a
factor of two.
This all was o.k. in RFC 3451, where the technology was new and
the authors spent much time and paper to convince the audience
that this kind of framework specification is a useful document;
but now that things have settled, I expected a Proposed Standard
document to be more concise.
However, this observation should not stop the draft at this stage.
I have some sympathy. Unfortunately this suggestion was never made during
the update process.
(B) Technical
I found no serious technical issues with the normative parts of the
document.
Since we know that this is only a framework, it must be accepted
that the normative language is less strong, and the number of
possible options and variations is much larger than in a complete
protocol specification. However I fear this would be prohibitive
-- under the existing rules for the Standards Track -- for a future
promotion of this document to DS.
A small detail should be reconsidered, however:
Section 5.2.2 specifies an overloading of the ERT flag and ERT field:
| Expected Residual Time (ERT): ERT flag, corresponding 32 bit time
| value
|
| This timing information represents the sender expected residual
| transmission time for the current session or for the transmission
| of the current object. If the packet containing the ERT timing
| information also contains the TOI field, then ERT refers to the
| object corresponding to the TOI field, otherwise it refers to the
| session.
This overloading seems to be potentially dangerous; it prematurely
excludes the possibility to specify a session ERT value whenever
a session carries multiple objects and hence needs to make use of
TOI in every packet.
Wouldn't it be a more clean solution to spent another bit and
optional field, to achieve a clean separation of both Object ERT
and Session ERT ?
I raised this question on the RMT list and the conclusion there was to
clarify the ERT should always be the end time of the current object. The
possibility to separately specify the end time of the current session is not
believed to be useful, but could anyway be added in future in another
document if needed (with an LCT header extension).
(C) Security
I have some issues with the Security Considerations.
The text on possible mitigations there has been minimized.
Yet, some of these issues are laudably discussed in other parts of
the document; so it would be very useful to have pointers to the
precise locations of these discussions be placed into Sect. 8.*.
Ok. I will add such pointers.
(D) Editorial flaws (in textual order)
<omitting purely editorial comments - I will implement all these>
(10) Section 5.1
(10a) 1st paragraph below Figure 1
The draft says:
The function and length of each field in the default LCT header is
| the following. Fields marked as "1" mean that the corresponding bits
| MUST be set to "1" by the sender. Fields marked as "r" or "0" mean
| that the corresponding bits MUST be set to "0" by the sender.
The last two sentences are dangerous in two aspects, and almost moot.
First, it is potentially confusing to include numerical values in
double quotes; this could be interpretted as denoting a (ASCII)
string constant, not a binary value.
Thus, the quotes should be dropped from the phrases
set to "1"
and
set to "0"
Next, Figure 1 contains a field labelled "O", which in printned
form can easily be confused with what the above text refers to as
field marked ... "0" .
The 'MBZ' rule does not apply to the field labelled "O".
However, the whole document does not contain any fields marked as
either "1" or "0", and also no more field marked as "r".
(There now is a single field marked "Res", but that has an extra
paragraph of explanation.)
Therefore, I strongly suggest to simply drop these sentences
and replace the paragraph by the shortened form:
The function and length of each field in the default LCT header is
| the following.
Agreed.
(15) Section 9.2, 1st paragraph -- incomplete URN
The URN given apparently is incomplete (cf. 9.1!);
further, I strongly suggest to force the whole URN on a single line
for clarity.
| This document registers two values in the namespace "ietf:rmt:lct:
| headerExtensionTypes:variableLength" as follows:
---
| This document registers two values in the namespace
| "ietf:rmt:lct:headerExtensionTypes:variableLength:ietf" as follows:
^^^^^
Based on a discussion on the list in response to IANA comments, we will
remove the URNs and simply establish a single registry for the LCT Header
Extension Types.
(16) Section 11, 1st bullet
This bullet is bogus:
| o Update all references to the obsoleted RFC 2068 to RFC 2616
Neither did RFC 3451 contain a reference to RFC 2068, nor does this
draft contain a reference to RFC 2616.
RFC 3451 referred to RFC 2616, but the specifics of alternative
methods to SDP (for session descriptions) have been dropped entirely
from this memo.
So please delete this bullet.
Agreed.
Kind regards,
Alfred HÎnes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf