[Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the ALC PI and have some comments.

1. If one compare this one with the experimental one they are very
similar. At least my expectation would be that a bit more details are
actually nailed down on how one should do them to achieve interoperable
implementations. For example the choice of congestion control algorithm.
I think we only have one that we can really use to satisfy the intended
usage of large scale sessions. Why isn't this a required to implement
feature?

The same thing can be said about normative to implement security
features. Yes, here there are choices, but still specify one required to
implement should be possible. If you have observant the NORM PI got this
comment from the SECdir reviewer. And I think he was right, we should be
clear on these.

A question is if we need to specify one mandatory to implement FEC
encoding?

In general I am not against the flexibility the protocol allows for.
However, it should be clear what you do need to implement for a
base-line implementation.

2. Section 2, third paragraph:
"This
   specification defines ALC as payload of the UDP transport protocol
   [RFC0768] that supports IP multicast delivery of packets.  Future
   versions of this specification, or companion documents may extend ALC
   to use the IP network layer service directly.  ALC could be used as
   the basis for designing a protocol that uses a different underlying
   network service such as unicast UDP, but the design of such a
   protocol is outside the scope of this document."

This type of text seems out of place. You are not any longer describing
a experimental protocol. State what is, not what could have been. Also
the ALC PI would not work from a congestion control side over unicast IP.

3. I am also disappointed that the ID nits hasn't been taking care of:

  Miscellaneous warnings:

----------------------------------------------------------------------------

  == The copyright year in the IETF Trust Copyright Line does not match the
     current year

  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
     defined in RFC 2119.  If it is intended as a requirements
expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements
text,
     is not defined in RFC 2119, and should not be used.  Consider using
'MUST
     NOT' instead (if that is what you mean).

     Found 'MAY NOT' in this paragraph:

     All senders and receivers implementing ALC MUST support the EXT_NOP
     Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
     parse its content.  The EXT_NOP and EXT_AUTH LCT Header Extensions are
     defined in [I-D.ietf-rmt-bb-lct-revised]

  == The expression 'MAY NOT', while looking like RFC 2119 requirements
text,
     is not defined in RFC 2119, and should not be used.  Consider using
'MUST
     NOT' instead (if that is what you mean).

     Found 'MAY NOT' in this paragraph:

     If more than one object is to be carried within a session then the
     Transmission Object Identifier (TOI) MUST be used in the LCT header to
     identify which packets are to be associated with which objects. In this
     case the receiver MUST use the TOI to associate received packets with
     objects.  The TOI is scoped by the IP address of the sender and the
TSI,
     i.e., the TOI is scoped by the session.  The TOI for each object is
     REQUIRED to be unique within a session, but MAY NOT be unique across
     sessions.  Furthermore, the same object MAY have a different TOI in
     different sessions.  The mapping between TOIs and objects carried in a
     session is outside the scope of this document.

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.).


  Checking references for intended status: Proposed Standard

----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-09) exists of
     draft-ietf-rmt-bb-lct-revised-07

  ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566)

  ** Downref: Normative reference to an Informational RFC: RFC 2357

  ** Downref: Normative reference to an Experimental RFC: RFC 2974

  -- Obsolete informational reference (is this intentional?): RFC 1889
     (Obsoleted by RFC 3550)

Yes, there is a difference between the draft submission check and the
full checks that the tools page provide. At publication request time I
do expect the draft be without real nits.

4. There are more references that are not updated. Cases where mechanism
are available in IETF draft, like the TESLA solution. Which would impact
the reference for example in Section 5, third paragraph.

5. Section 4.4:

"If immediate checking is possible and if the packet
   fails the check then the receiver MUST discard the packet and reduce
   its reception rate to a minimum before continuing to regulate its
   reception rate using the multiple rate congestion control."

Isn't the above instruction about reducing the rate based on packets
that fails authentication checks resulting in another DoS vector on the
receiver. If the only thing I need to do to keep the receiver at minimum
reception rate is to send the occasional packet that fails the checks
that seems extremely cheap. Can you please elaborate what the thoughts
where on this?

So in conclusion I think this document needs a work over and some
nailing down on what is mandatory to implement. I am expecting a revised ID.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------