[MBONED] Alissa Cooper's Discuss on draft-ietf-mboned-interdomain-peering-bcp-11: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Tue, 10 October 2017 15:27 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: mboned@ietf.org
Delivered-To: mboned@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA542135146; Tue, 10 Oct 2017 08:27:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mboned-interdomain-peering-bcp@ietf.org, mboned-chairs@ietf.org, tim.chown@jisc.ac.uk, mboned@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150764927891.13436.4480686201231484122.idtracker@ietfa.amsl.com>
Date: Tue, 10 Oct 2017 08:27:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/-7a3f-CHcyk40S7XyY4OcUZkXRQ>
Subject: [MBONED] Alissa Cooper's Discuss on draft-ietf-mboned-interdomain-peering-bcp-11: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 15:29:39 -0000

Alissa Cooper has entered the following ballot position for
draft-ietf-mboned-interdomain-peering-bcp-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mboned-interdomain-peering-bcp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.3.3 recommends that ADs generate and exchange extensive logging
information, but the document says nothing about securing these logs or
limiting the exchange of private or confidential information between the peers.
This seems like it needs to be addressed in the BCP.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Why does this document contain the copyright disclaimer for pre-RFC5378
work?

(2) Section 4.4 says:

"In the event of performance degradation (SLA violation), AD-1
        may have to compensate the multicast application source per SLA
        agreement. As appropriate, AD-1 may seek compensation from AD-2
        if the cause of the degradation is in AD-2's network."

and

"Faults in service could lead to SLA violation for which the
        multicast application source provider may have to be
        compensated by AD-1. Subsequently, AD-1 may have to be
        compensated by AD-2 based on the contract."

These bullets seem out of scope for this BCP. I would recommend deleting them.

(3) Section 6 says:

"DRM and Application Accounting, Authorization and Authentication
   should be the responsibility of the multicast application source
   provider and/or AD-1. AD-1 needs to work out the appropriate
   agreements with the source provider.

   Network has no DRM responsibilities, but might have authentication
   and authorization obligations. These though are consistent with
   normal operations of a CDN to insure end user reliability, security
   and network security."

I find these two paragraphs somewhat contradictory and vague. The first
paragraph makes it sound like DRM could be the responsibility of AD-1. The
second paragraph makes it sound like AD-1 (assuming it counts as "network")
would never be responsible for DRM. Then later on the text says:

"Authentication and authorization of EU to receive multicast content
   is done at the application layer between the client application and
   the source. This may involve some kind of token authentication and
   is done at the application layer independently of the two AD's."

Is this differentiating authentication and authorization of the application
source from that of the end user? It's not clear. I would suggest revising this
whole section to be clear about which security functions are the responsibility
of which parties.