[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.
- [MBONED] Alissa Cooper's Discuss on draft-ietf-mb… Alissa Cooper
- Re: [MBONED] Alissa Cooper's Discuss on draft-iet… Toerless Eckert