Asynchronous Layered Coding (ALC) Protocol Instantiation
draft-ietf-rmt-pi-alc-revised-10

[Ballot comment]
The "Baseline Secure ALC Operation" (Section 5.1) seems very specific
to some particular application (not clear what exactly), and probably
wouldn't be very useful for most applications using ALC. For example,
using IP addresses in certificates (Section 5.1.2.5) is unlikely
to be a good idea for most applications...

[Ballot discuss]
Can someone explain the IPR situation on this to me. My understanding is that there was IPR on 3450. Has this gone away somehow?

It seems like this should be experimental. What changed?

[Ballot comment]
The OPS-DIR review performed by Victor Fajardo raised a number of issues which are not blocking, but should be clarified and answered in order to improve the quality of the document:

1. There is a strong recommendation regarding the placement of the RP (Rendezvous Points) as close to the source as possible. However the placement of RPs are typically not constrained by control protocols either in sparse or dense mode multicast deployments. Is not this a too strong of a deployment constraint when using ALC, and what can be the consequences of such a troplogy requirement not be met in depoyment?
 
2. In sec 2.2, is RFC3738 the default congestion control ? It is not clear how multiple congestion control schemes would inter-operate when they are present. i.e. how does it map a scheme to each possible length ?

3. In paragraph 5 of sec 2.3, there seems to be several available mechanisms for communicating FEC OTI. Is the ALC responsible for mapping/sorting out which scheme is in use ?

4. In 1st paragraph of sec 4.2, ALC MUST ‘recognize’ EXT_AUTH. In this context, what does ‘recognize’ mean ? Does it mean passing the responsibility to some auth module ? Its not clear in the document how this is supported.

5. The last paragraph of sec 4.4 maybe more useful to be part of the security considerations section.

[Ballot discuss]
I think that the following two issues need to be discussed by the IESG before apprpving this document. I would be glad to clear the DISCUSS if there are appropriate answers to these questions.

1. This document updates RFC 3450 and moves it from Experimental to Proposed Standard. What is the rationale behind this move - is the protocol implemented and succesfully deployed,  what is the operational experience that was gained in the 6-7 years since 3450 was published?

2. How is this protocol deployed and managed? Are there any configuration operations that are required? How are sessions monitored? Are there performance metrics and parameters that need to be monitored? I understand that the answers may not be included in this document but some place else, but I could not find anything in the WG documents.

[Ballot comment]
The OPS-DIR review performed by Victor Fajardo raised a number of issues which are not blocking, but should be clarified and answered in order to improve the quality of the document:

1. There is a strong recommendation regarding the placement of the RP (Rendezvous Points) as close to the source as possible. However the placement of RPs are typically not constrained by control protocols either in sparse or dense mode multicast deployments. Is not this a too strong of a deployment constraint when using ALC, and what can be the consequences of such a troplogy requirement not be met in depoyment?
 
2. In sec 2.2, is RFC3738 the default congestion control ? It is not clear how multiple congestion control schemes would inter-operate when they are present. i.e. how does it map a scheme to each possible length ?

3. In paragraph 5 of sec 2.3, there seems to be several available mechanisms for communicating FEC OTI. Is the ALC responsible for mapping/sorting out which scheme is in use ?

4. In 1st paragraph of sec 4.2, ALC MUST ‘recognize’ EXT_AUTH. In this context, what does ‘recognize’ mean ? Does it mean passing the responsibility to some auth module ? Its not clear in the document how this is supported.

5. The last paragraph of sec 4.4 maybe more useful to be part of the security considerations section.

[Ballot discuss]
I think that the the following two issues need to be discussed by the iESG before apprpving this document. I would be glad to clear the DISCUSS if there are appropriate answers to these questions.

1. This document updates RFC 3450 and moves it from Experimental to Proposed Standard. What is the rationale behind this move - is the protocol implemented and succesfully deployed,  what is the operational experience that was gained in the 6-7 years since 3450 was published?

2. How is this protocol deployed and managed? Are there any configuration operations that are required? How are sessions monitored? Are there performance metrics and parameters that need to be monitored? I understand that the answers may not be included in this document but some place else, but I could not find anything in the WG documents.

[Ballot discuss]
The Gen-ART for review by Miguel Garcia on 2009-09-21 can be found at:
  http://www.softarmor.com/rai/temp-gen-art/draft-ietf-rmt-pi-alc-revised-08-garcia.txt

  The author agreed with these comments, but they have not been addressed yet.

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "LCT Header Extension Types" registry at
http://www.iana.org/assignments/lct-header-extensions/lct-header-extensions.xhtml

Number Name Reference
------ ------- ----------
TBD(64) EXT_FTI [RFC-rmt-pi-alc-revised-08]


We understand the above to be the only IANA Action for this document.

Document Shepherd Write-Up for "draft-ietf-rmt-pi-alc-revised-06" intended for
publication in the "Proposed Standard" category.

This writeup complies with RFC 4858


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Brian Adamson, who has personally reviewed this
version of the document and believes it is ready for forwarding to the
IESG for publication. 

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had adequate review by key WG members.  The document has been
reviewed by multiple WG members and has been updated to reflect their
comments.  There are non unresolved issues.  The Experimental RFC3450 upon
which this revision is based was thoroughly reviewed.  The differences
between this revision and the original document are relatively minor.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No additional reviews needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

There are no such concerns with this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represent a solid consensus of the RMT WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No discontent of significant concern have been raised about this
document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The Document Shepherd has personally verified that the document satisfies all ID nits.

"draft-ietf-rmt-pi-alc-revised-06" is intended for publication in the
"Proposed Standard" category.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and
informative. The normative references are in RFC published status.
There are no downward references.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA consideration section exists.  A single Layered Coding Transport (LCT)
header extension is defined.  IANA requirements are clearly described and are
consistent with the other documents requiring assignments from the "ietf:rmt"
name-space.  All assignment requests are in compliance with RFC2434 and the
appropriate IETF actions are specified.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The documents contains no section written in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Document Announcement Write-Up for draft-ietf-rmt-pi-alc-revised-06 follows.

Technical Summary

  This document is an Reliable Multicast Transport (RMT) Protocol Specification
  that builds upon the RMT Layered Coding Transport (LCT) building block
  document. This specification describes a massively scalable reliable content
  delivery protocol, Asynchronous Layered Coding (ALC), for multiple rate
  congestion controlled reliable content delivery.  The protocol is specifically
  designed to provide massive scalability using IP multicast as the underlying
  network service.  Massive scalability in this context means the number of
  concurrent receivers for an object is potentially in the millions, the
  aggregate size of objects to be delivered in a session ranges from hundreds of
  kilobytes to hundreds of gigabytes, each receiver can initiate reception of an
  object asynchronously, the reception rate of each receiver in the session is
  the maximum fair bandwidth available between that receiver and the sender, and
  all of this can be supported using a single sender.

Working Group Summary

    There is consensus in the WG to publish this documents.

Document Quality

    The document is of high quality and has been subject to extensive
    review in its Internet Draft and Experimental RFC forms.  The
    revised draft represents a small number of changes from the original
    Experimental RFC 3450.
   
    Open source implementations of the ALC protocol are available and
    considerable experience in using this protocol has been accumulated.
    The protocol has been adopted by the Digital Video Broadcasting (DVB)
    industry consortium for content delivery.

    The content of this document was already reviewed and approved for
    publication as experimental RFC 3450. This document contains minor
    technical modifications.

Personnel

    Brian Adamson is the Document Shepherd.
    Magnus Westerlund is the Responsible Area Director.