14-rfc-editor-feedback.txt

From wwwrun@rfc-editor.org  Wed Dec 13 03:36:27 2017
Return-Path: <wwwrun@rfc-editor.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	faui40.informatik.uni-erlangen.de
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED=-2.3,
	SPF_HELO_PASS=-0.001,T_RP_MATCHES_RCVD=-0.01 autolearn=disabled version=3.4.0
X-Original-To: eckert+ietf@i4.informatik.uni-erlangen.de
Delivered-To: eckert+ietf@i4.informatik.uni-erlangen.de
Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 6555558C4EC
	for <eckert+ietf@i4.informatik.uni-erlangen.de>; Wed, 13 Dec 2017 03:36:27 +0100 (CET)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id ADA1274D903
	for <tte+ietf@cs.fau.de>; Wed, 13 Dec 2017 03:36:22 +0100 (CET)
Received: by rfc-editor.org (Postfix, from userid 30)
	id 0D232B81521; Tue, 12 Dec 2017 18:35:55 -0800 (PST)
To: tarapore@att.com, rs1983@att.com, shep@cisco.com, tte+ietf@cs.fau.de, ramkri123@gmail.com
Subject: =?UTF-8?B?W0xCXSAgUXVlc3Rpb25zIGFib3V0IGRyYWZ0LWlldGYtbWJvbmVkLWludGVyZG9tYWluLXBlZXJpbmctYmNwLTE0LnR4dA==?=
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org 
Cc: rfc-editor@rfc-editor.org, gjshep@gmail.com, lenny@juniper.net, bclaise@cisco.com, warren@kumari.net, tim.chown@jisc.ac.uk
Content-type: text/plain; charset=UTF-8
Message-Id: <20171213023555.0D232B81521@rfc-editor.org>
Date: Tue, 12 Dec 2017 18:35:55 -0800 (PST)
X-Virus-Scanned: clamav-milter 0.99.2 at faui45
X-Virus-Status: Clean
Status: RO
Content-Length: 15056
Lines: 419

Dear authors,

While editing draft-ietf-mboned-interdomain-peering-bcp-14, we have the following questions.

Please reply so that your document will move forward in the publication process.

Thank you.

RFC Editor/lb

1) Section 1:  We had trouble following this sentence,
because we do not see AD-1 referred to as the multicast source in
any other text in this document.  Please clarify "AD-1 that this
document refers to as the multicast source."

Original:
 To support that additional service, it is
 recommended to use some method (outside the scope of this
 document) by which the content from EUs is transmitted to the
 application in AD-1 that this document refers to as the
 multicast source and let it send out the traffic as IP
 multicast.


2) Section 1:  Because Section 4.2.2 does not mention IXPs,
we changed the citation to point to Section 4.2.4.  Please let us
know if this is incorrect.

Original (the previous sentence is included for context):
 The other case is that of a broadcast peering
 point which is a common option in public Internet Exchange Points
 (IXP).  See Section 4.2.2 for more details about that option.

Currently:
 The other case is that of a broadcast peering
 point, which is a common option in public Internet Exchange Points
 (IXPs).  See Section 4.2.4 for more details.


3) Section 1:  We could not find text in Section 2 that
relates to this sentence.  Please confirm that "Section 2" is correct
here.

Original:
 o  As described in Section 2, the source IP address of the multicast
    stream in the originating AD (AD-1) is known.


4) Section 3.1:  BCP 145 (RFC 8085) does not mention
"rate adaption," and it appears that the RFCs cited in RFC 8085
don't mention it either.  Please confirm that this citation is
correct and will be clear to readers who refer to it.

Original:
 If this is not the case, then the multicast
 traffic must support rate-adaption (see [BCP145]).


5) Section 3.2:  Should "can or should not be enabled" be
"cannot be or should not be enabled," "can be enabled or should not
be enabled," or something else?  Please clarify.

Original ("choosen" and "physcially" have been corrected):
 Normally, this approach is choosen if the uBR physcially connected to
 the peering link can or should not be enabled for IP multicast.


6) Section 3.2:  For ease of the reader, we expanded "SAFI"
as "Subsequent Address Family Identifier."  Please let us know if this
is incorrect.

Original:
 The routing configuration is basically unchanged: Instead of BGP
 (SAFI2) across the native IP multicast link between AD-1 and AD-2,
 BGP (SAFI2) is now run across the GRE tunnel.

Currently:
 The routing configuration is basically unchanged: instead of running
 BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family
 Identifier") across the native IP multicast link between AD-1 and
 AD-2, BGP (SAFI-2) is now run across the GRE tunnel.


7) Section 3.2:  Does "the fully native multicast Use Case"
refer to a specific use case/section in this document, or is it used
generally?

Original:
 o  Highly efficient use of bandwidth in both domains, although not as
    efficient as the fully native multicast Use Case.


8) Figure 5:  "AMT Relay and Relays" looks odd.  Should it
be "AMT Relays," or perhaps "AMT Gateways and Relays"?

Original:
 Figure 5: AMT Tunnel Connecting AMT Relay and Relays


9) Section 4.1:  "MBGP" is not used anywhere in RFC 4760.
"MBGP" can stand for "Multicast BGP" (per RFC 5760) or "Multiprotocol
BGP" (per RFC 6831).  Please let us know how we should cite "MBGP"
here (and expand it in the legend for Figure 1) for ease of the
reader.

Original:
 o  Peering Point Protocol Support - Multicast protocols that will be
    used for multicast delivery will need to be supported at these
    points.  Examples of protocols include eBGP [RFC4760] and MBGP
    [RFC4760].


10) Section 4.1.1:  We had trouble parsing this sentence.
Please clarify "and of not ..."

Original:
 In many instances, multicast content delivery evolves from intra-
 domain deployments where it is handled as a controlled network
 service and of not complyng to congestion control principles.

Possibly:
 In many instances, multicast content delivery evolves from
 intra-domain deployments where it is handled as a controlled network
 service and does not comply with congestion control principles.


11) Section 4.1.1:  This sentence did not parse.  We updated
it as follows.  Please let us know if this is incorrect.

Original:
 Because rate adaption in IP unicast video is
 commonplace today because of ABR (Adaptive Bitrate Video), it is very
 unlikely for this to happen though in reality with IP unicast.

Currently:
 Note that because
 rate adaption in IP unicast video is commonplace today due to the
 availability of ABR (Adaptive Bitrate Video), it is very unlikely
 that this will happen in reality with IP unicast.


12) Section 4.2.2:  As there is no "Use Case 3.2.2," we
changed "3.2.2" to "3.2"; please let us know if this is incorrect.

Original:
 If the interconnecting peering point is not multicast enabled and
 both AD's are multicast enabled, then a simple solution is to
 provision a GRE tunnel between the two AD's - see Use Case 3.2.2.

Currently:
 If the interconnecting peering point is not multicast enabled and
 both ADs are multicast enabled, then a simple solution is to
 provision a GRE tunnel between the two ADs; see Use Case 3.2.


13) Section 4.2.3:  This sentence does not parse.  Please
clarify "and Anycast IP addresses process for Use Cases ..."

Original:
 An illustrative example of a relay selection based on DNS queries and
 Anycast IP addresses process for Use Cases 3.4 and 3.5 is described
 here.


14) Section 4.2.4:  We changed "do contract this content" to
"contact this content" per "The customer contacts content source" in
Section 4.3.2.  Please let us know if this is incorrect.

Original:
 Assume one or more IP multicast (S,G) traffic streams can be served
 by both AD-1a and AD-1b, for example because both AD-1a and AD-1b do
 contract this content from the same content source.

Currently:
 Assume that one or more IP multicast (S,G) traffic streams can be
 served by both AD-1a and AD-1b - for example, because both AD-1a and
 AD-1b contact this content from the same content source.


15) Section 4.2.4:  Does "upstreams" refer to upstream BRs,
upstream domains, upstream ADs, or something else?  Please clarify.

Original:
 3.  The LAN has multiple upstreams, but they are federated and agree
     on a consistent policy for IP multicast traffic across the LAN.


16) Section 4.2.4:  To what does "above example" refer in
this sentence?  Please clarify.

Original:
 Another policy is that sources are redundantly
 announced (problematic case mentioned in above example), but the
 upstream domains also provide mutual operational insight to help
 troubleshooting (outside the scope of this document).


17) Section 4.3.1:  To what does "these" refer in this
sentence?

Original:
 o  Routing protocols as needed, e.g. configuring routers to support
    these.


18) Section 4.3.1:  Should "ISP backbones, peering and
access networks" be "ISP backbones, peering points, and access
networks," "ISP backbones, peering links, and access networks," or
something else?

Original:
 Native multicast functionality is assumed to be available across many
 ISP backbones, peering and access networks.


19) Section 4.3.2:  To what does "propagate the issue" refer
in this sentence?  Does it mean "communicate the problem," "convey the
customer's request," or something else?  Please clarify.

Original:
 The reason to specifically mention the need for AD-1 to initiate
 interactions with AD-2 (and use some account for that), as opposed to
 the opposite direction is based on the recommended workflow initiated
 by customers (see Section 4.4): The customer contacts content source
 (part of AD-1), when AD-1 sees the need to propagate the issue, it
 will interact with AD-2 using the aforementioned guidelines.


20) Section 4.3.3:  It appears that some words are missing
from this sentence (e.g., possibly a citation for another section
instead of "in before" and "the content source and on its behalf AD-1").
Please clarify.

Original:
 The basic model as explained in before is that the content source and
 on its behalf AD-1 take over primary responsibility for customer
 experience and the AD-2's support this.


21) Section 4.4:  Which use cases are referred to here?
Please clarify.

Original (the previous sentence is included for context):
 o  AD-2 may experience some problems in its network.  For example,
    for the AMT Use Cases, one or more AMT Relays may be experiencing
    difficulties.

Possibly:
 For example,
 in Use Case 3.3 or Use Case 3.4, one or more AMT relays may be
 experiencing difficulties.


22) Section 4.4:  What does "CP" stand for in this phrase?

Original:
 o  Analysis of the problem information provided by the customer
    (CP).


23) Section 6.1:  This sentence does not parse.  If the
suggested text is not correct, please clarify "solutions that
consider bandwidth consumed exist as vendor specific feature in
routers."

Original:
 Simple solutions such as limiting
 the maximum number of joined (S,G) per EU are readily available,
 solutions that consider bandwidth consumed exist as vendor specific
 feature in routers.

Suggested:
 Simple solutions such as limiting
 the maximum number of joined (S,G)s per EU are readily available;
 solutions that take consumed bandwidth into account are available as
 vendor-specific features in routers.


24) Section 6.1:  We could not see in Use Case 3.4 how the
AMT relay in AD-1 is "that last replication point."  Please confirm
that the reference to Use Case 3.4 is correct here.

Original:
 Note that this is primarily a non-peering issue
 in AD-2, it only becomes a peering issue if the peering-link itself
 is not big enough to carry all possible content from AD-1 or in case
 3.4 where the AMT relay in AD-1 is that last replication point.


25) Section 6.2:  For ease of the reader, we expanded "OTT"
as "Over the Top."  Please let us know if this is incorrect.

Original:
 It is also
 the model used in Internet OTT video delivery.

Currently:
 It is also the model used in
 Internet "Over the Top" (OTT) video delivery.


26) Section 6.2:  This sentence does not parse.  Please
clarify "only copy deliver thast is used in unicast."

Original (the previous sentence is included for context):
 To mitigate this issue, the last replication point that is creating
 (S,G) copies to EUs would need to permit those copies only after
 authentication of EUs.  This would establish the same authenticated
 EU only copy deliver thast is used in unicast.


27) Section 6.2:  Does "a separate network forwarding
authentication/authorization scheme" mean "a separate
traffic-forwarding authentication/authorization scheme,"
"a separate authentication/authorization scheme for forwarding
network traffic," or something else?  Please clarify.

Original:
 Such schemes
 are technically not difficult to build and would avoid creating and
 maintaining a separate network forwarding authentication/
 authorization scheme decoupled from the end-to-end authentication/
 authorization system of the application.


28) Section 6.3:  Does "defined high bars" mean "defined
strict constraints," or something else?  Please clarify.

Original:
 In the case of a private peering link, IP multicast does not have
 attack vectors on a peering link different from those of IP unicast,
 but the content owner may have defined high bars against
 unauthenticated copying of even the end-to-end encrypted content, and
 in this case AD-1/AD-2 can agree on additional transport encryption
 across that peering link.


29) Section 6.3:  This sentence does not parse.  Please
clarify "the information what content is being consumed."

Original ("the the" has been corrected):
 It not only prohibits possible
 "leakage" of content, but also to protects the the information what
 content is being consumed in AD-2 (aggregated privacy protection).


30) Section 6.4:  In this section,"(S,G)" is only mentioned
in the last sentence of the first paragraph of this section.  Please
confirm that "this section" is correct here.

Original ("exhange" has been corrected):
 Section 4.3.3 discusses exchange of log information, this section
 discussed exchange of (S,G) information and Section 7 discusses
 exhange of program information.


31) Section 6.4:  It appears that either (1) a citation for
another section might be missing from this sentence or (2) "in before"
should be "before" (assuming that readers will know where to look for the
information).  Please clarify "as discussed in before to protect it."

Original:
 If any protocols used for the operational information exchange are
 not easily secured at transport layer or higher (because of the use
 of legacy products or protocols in the network), then AD-1 and AD-2
 can also consider to ensure that all operational data exchange goes
 across the same peering point as the traffic and use network layer
 encryption of the peering point as discussed in before to protect it.


32) Section 7:  We had trouble parsing this sentence.  We
updated it as follows.  Please let us know if this is incorrect.

Original:
 AD-2 is not required to gain
 additional insight into the user behavior through this process that
 it would not already have without the service collaboration with AD-1
 - unless AD-1 and AD-2 agree on it and get approval from the EU.

Currently:
 AD-2 is not required to gain
 additional insight into the user's behavior through this process
 other than what it would already have without service collaboration
 with AD-1, unless AD-1 and AD-2 agree on it and get approval from
 the EU.


33) Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 "S,G" / (S,G)
 AMT Relay / AMT relay (in text) (per RFC 7450)
 AMT Gateway / AMT gateway (in text) (per RFC 7450)
 GRE Tunnel / GRE tunnel (in text)
   (per RFC 2784 and per more common usage in post-6000 published RFCs)
 Native Multicast / native multicast (in text) (per RFC 7450)
 Application Source (in text; 4 instances in Section 4.3.1) /
   application source
 group (or stream) id / group (or stream) ID

b) We changed the following variations to
"AS = multicast (e.g., content) Application Source."  Please let us
know any objections.

 AS = Application (e.g., Content) Multicast Source /
   AS = Application Multicast Source /
   AS = Application Source


Title                  : Use of Multicast Across Inter-Domain Peering Points
Author(s)              : P. Tarapore,  Ed., 
                         R. Sayko,  G. Shepherd, 
                         T. Eckert,  Ed., 
                         R. Krishnan
Working Group Chair(s) : Greg Shepherd, Leonard Giuliano
Area Director(s)       : Benoit Claise, Warren Kumari