AD comments on draft-ietf-rmt-pi-norm-revised-08

Hi,

I have reviewed the NORM PI and have some comments that I like to see
addressed before IETF last call.

1. Document obsoletes RFC 3940? If yes, include in header, abstract and
introduction that fact.

2. Section 4.1:

Sequence number description is a bit cryptic. If I understand it
correctly each and every norm node has one sequence number space in its
sender role (if sender), and another in the receiver role (if receiver).

3. Section 4.1:

   The "source_id" field is a 32-bit value identifying the node that
   sent the message.  A participant's NORM node identifier (NormNodeId)
   can be set according to application needs but unique identifiers must
   be assigned within a single NormSession.  In some cases, use of the
   host IP address or a hash of it can suffice, but alternative
   methodologies for assignment and potential collision resolution of
   node identifiers within a multicast session need to be considered.
   For example, the "source identifier" mechanism defined in the Real-
   Time Protocol (RTP) specification [RFC3550] may be applicable to use
   for NORM node identifiers.  At this point in time, the protocol makes
   no assumptions about how these unique identifiers are actually
   assigned.

I think this is awfully vague for being a fully specified protocol on
the standards track. Doesn't the implementation experience have at least
one mechanism that can be default to use?

4. Page 26:
 "Example: EXT_FTI Header Extension Format for "fec_id" = 129"

Use of the wrong symbols in source seems to have produced some escaping.

5. Page 28:
"Values of "stream_control_code" that are not
   understood SHOULD be ignored."

   What can one possibly do if one doesn't understand them? Are there a
reason to build implementations that doesn't ignore them?

6. 4.2.3.4:

"If NORM is operated in a private network with
   congestion control operation disabled, the "NORM_CMD(CC)" message is
   then used for GRTT measurement only and may optionally be sent less
   frequently than with congestion control operation."

I think "private network" isn't the right naming of what the network
where one can turn off congestion control. "operated in a network where
resources are explicitly dedicated to the NORM session and therefore
congestion control operation is disabled ..."

7. 4.2.3.5:

"cc_loss" = decimal_loss_fraction * 65535.0

Does the rounding of this value matter when converting to the 16-bit
value. Most platforms that just strips the value would be equivalent to
a floor. Does it matter if ceiling or round would be used instead?

8. Section 5.1:

Congestion control operation SHALL be
   observed at all times when operating in the general Internet.

   I would like to strengthen this statement to say: at all times when
not operating using dedicated resources, like in the general Internet.

9. Section 5.5.2:

   This congestion control scheme is REQUIRED for operation
   within the general Internet unless the NORM implementation is adapted
   to use another IETF-sanctioned reliable multicast congestion control
   mechanism (e.g., PGMCC [PgmccPaper]).

The above sentence implies that PGMCC is an approved RFC document. I
would propose to remove the complete parenthesis.

10. Section 5.5.2:

 The details of PLR
   selection are not discussed in this document.

I think this and the paragraph can be misleading to that there are no
support to build the CLR + PLR list. The protocol does have a mechanism
for receiver to raise their hand and say: Hey, I may belong on this list.


11. Section 6:

The same security considerations that apply to the NORM, TFMCC, and
   FEC Building Blocks also apply to the NORM protocol.

   Please include reference indicators here.


12. Section 6.1:

The current RTP spec is RFC 3550 and not RFC 1889.

13. Section 7.1 & 11.1

RFC 2434 has been replace by RFC 5226

14. Section 11.1 and 1

   This document is a product of the IETF RMT WG and follows the
   guidelines provided in [RFC3269].

This is in my view an informative reference. So please move the
reference to the informative part.


15. ID Nits that needs to be fixed:

  == The document seems to lack the recommended RFC 2119 boilerplate,
even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph
with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is
what you
     mean).

     Found 'SHALL not' in this paragraph:

     The "NORM_CMD(SQUELCH)" command is transmitted in response to
     outdated or invalid "NORM_NACK" content received by the sender. Invalid
     "NORM_NACK" content consists of repair requests for NormObjects for
which
     the sender is unable or unwilling to provide repair.  This includes
     repair requests for outdated objects, aborted objects, or those objects
     which the sender previously transmitted marked with the
     "NORM_FLAG_UNRELIABLE" flag.  This command indicates to receivers what
     content is available for repair, thus serving as a description of the
     sender's current "repair window".  Receivers SHALL not generate repair
     requests for content identified as invalid by a "NORM_CMD(SQUELCH)".

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------