auth48-questions.txt

From wwwrun@rfc-editor.org  Sat Dec 23 07:09:57 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 25C6658C4BF
	for <eckert+ietf@i4.informatik.uni-erlangen.de>; Sat, 23 Dec 2017 07:09:56 +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 73F6274DBF6
	for <tte+ietf@cs.fau.de>; Sat, 23 Dec 2017 07:09:53 +0100 (CET)
Received: by rfc-editor.org (Postfix, from userid 30)
	id 95D7AB8113A; Fri, 22 Dec 2017 22:09:47 -0800 (PST)
To: tarapore@att.com, rs1983@att.com, shep@cisco.com, tte+ietf@cs.fau.de, ramkri123@gmail.com
Subject: =?UTF-8?B?UmU6IFtBRF0gQVVUSDQ4IFtMQl06IFJGQyA4MzEzIDxkcmFmdC1pZXRmLW1ib25lZC1pbnRlcmRvbWFpbi1wZWVyaW5nLWJjcC0xNC50eHQ+IE5PVyBBVkFJTEFCTEU=?=
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, mboned-ads@ietf.org, mboned-chairs@ietf.org, tim.chown@jisc.ac.uk, warren@kumari.net
Content-type: text/plain; charset=UTF-8
Message-Id: <20171223060947.95D7AB8113A@rfc-editor.org>
Date: Fri, 22 Dec 2017 22:09:47 -0800 (PST)
X-Virus-Scanned: clamav-milter 0.99.2 at faui45
X-Virus-Status: Clean
Status: RO
Content-Length: 9130
Lines: 251

Authors and *AD,

[*AD - please review question 6 below].

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search -->


2) <!-- [rfced] There was some duplicated text in the last four paragraphs
of Section 2.  We removed the repetitive text.  Please review via the
-diff file, and let us know any objections. -->


3) <!-- [rfced]  There were some issues with figure numbers as listed in
the text.  For example, Figure 6 was cited in text before any mention
of Figure 3, so we changed "see Figure 6" to "see Section 4.2.4";
also, in Section 3.3, we changed "in Figure 2" to "in Figure 3"
because Figure 2 is related to GRE tunnels (not AMT).

Please review our updates carefully, and let us know if anything is
incorrect. -->


4) <!-- [rfced]  Figure 3:  We changed "otherwise AR=uBR (AD-1),
uBR=AG (AD-2)" to "otherwise, AR = uBR (AD-1) and uBR = AG (AD-2)";
please let us know if this is incorrect.

(We ask this because we see "otherwise AR=uBR (AD-1) or ubr=AGAR1
(AD-2)" in Figure 5 (i.e., "or" as opposed to "and").)

Original:
 uBR = unicast Border Router - not multicast enabled
       otherwise AR=uBR (AD-1), uBR=AG (AD-2)

Currently:
 uBR = unicast Border Router - not multicast enabled;
       otherwise, AR = uBR (AD-1) and uBR = AG (AD-2) -->


5) <!--[rfced] Please review use of "adaption" and let us know if "adaptation" might be agreeable instead.

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

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.

-->


6) <!-- [rfced] *AD:  Please let us know if you approve the removal of
the third bullet item (per author feedback during the AUTH state)
from the list at the beginning of Section 4.3.1.

Our original question:
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.

Author reply:
 Please delete the entire bullet. -->


7) <!-- [rfced] Section 6.1:  Please (1) review the following item and 
(2) let us know if the updated text (listed further below, under
"Currently") is incorrect.

Our original question and the author's reply:

37) Section 6.1:  To what does "their own AD" refer in this sentence?

Original:
 Each AD
 is expected to prohibit (S,G) state creation for invalid sources
 inside their own AD. 

Author reply:
 This is a generic statement. The meaning is something like "countries
 (ADs) have blacklists for their own criminals (illegal (S,G)),
 but there is no scheme to exchange those blacklists, so they can not
 be caught in foreign countries". 

 Aka: illegal "S" in AD-1 can and will be filtered in AD-1, illegal "S" in AD-2
 can be filtered in AD-2, but illegal "S" from AD-1 can not be filtered
 in AD-2.

 [rfced]  We are still a bit confused regarding "Each AD [does something]
 inside their own AD."  Would the following be correct (assuming that "realm"
 wouldn't have any confusing technical connotations in the context of this
 document)?

 Each AD is expected to prohibit (S,G)   
 state creation for invalid sources only inside its own realm.

 Thanks for not giving up ;-).

 Reading through my original sentence "Each AD is expected to prohibit (S,G)
 state creation for invalid sources inside their own AD" it dawns on me that it
 may not be obvious from the sentence that this is meant to be about "S" from
 the same domain.

 Your sentence would be ok. if it was changed to:

 Each AD is expected to be able to prohibit invalid (S,G) state creation for
 sources located inside the AD. 

 I think adding another word "realm" would just confuse things. 

 But its not clear to me if this makes it explicit enough.  So here is one
 suggested replacement with is a bit more elaborate: 

 Each ADi is expected to know what sources located in ADi are permitted to send
 and what their valid (S,G) are. ADi can therefore also filter invalid (S,G)
 for any S located inside ADi. But not four sources located in another AD:

 That last sentence is a bit duplication of the first sentence of the following
 paragraph, but maybe useful for emphsis. You decide. Otherwise just drop the
 last sentence of above suggestion.

 surprisingly difficult if one wants to be precise and easy to
 understand... ;-(

Currently:
 Each
 AD (say, "ADi") is expected to know what sources located in ADi are
 permitted to be sent and what their valid (S,G)s are.  ADi can
 therefore also filter invalid (S,G)s for any "S" located inside ADi
 (but not sources located in another AD). -->


Thank you.

RFC Editor/lb/mf

*****IMPORTANT*****

Updated 2017/12/22

—-FYI - the RFC Production Center will be closed from 
December 25 - January 2.  Please expect some delay in reply. —

RFC Author(s):
--------------

Instructions for Completing AUTH48 in XML

This is your last chance to make changes to your RFC-to-be: 
draft-ietf-mboned-interdomain-peering-bcp-14.txt.
Once the document is published as an RFC, we will not make changes.  
Please follow the instructions below to complete the AUTH48 process.
(For frequently asked questions, please see 
https://www.rfc-editor.org/faq/#auth48.)

1) Review the edited document completely.  The files are available here:

   https://www.rfc-editor.org/authors/rfc8313.txt
   https://www.rfc-editor.org/authors/rfc8313-diff.html

   We recommend reviewing the entire document, not just the diff file.
   FYI, http://tools.ietf.org/rfcdiff provides tools to make various
   kinds of diff files.

   The placement of page breaks will be handled during the final stages of
   publication (typically post-xml2rfc processing).

2) Review and resolve (as necessary) any questions raised by the RFC
   Editor.  The questions (if any) have been included in the XML file as
   comments marked <!-- [rfced] ... --> and will be sent in a subsequent email.

   Retrieve the edited XML file here:

      https://www.rfc-editor.org/authors/rfc8313.xml

   (Note that you may need to view the page source to save the file.)

3) Send us your changes or respond with your approval for publication.  
   Please use 'REPLY ALL' so that rfc-editor@rfc-editor.org and the parties
   CC'ed on this message receive your response. Note that your document will
   not move forward until we have received approvals from each of the
   authors listed on the front page.

   Note that, because you are listed in the document header, you are 
   responsible for reviewing and approving the RFC-to-be for publication.
   As part of that, you are also responsible for engaging other parties 
   (e.g., Contributors or Working Group) as necessary before providing 
   your approval.

   If sending changes, please do one of the following:

   a. Update the provided XML file, then email us the revised XML file.  
      You may use any filename for the revised file; we will rename it 
      before posting it.

   --OR--

   b. Provide us with an explicit list of changes in this format.

      Section # (or indicate Global)
   
      OLD:
      old text
   
      NEW:
      new text

   Be sure to pay particular attention to these areas of the document:
   - IANA Considerations updates (if applicable)
   - Contact information
   - Copyright notice and legends (see item 5 for more details)

4) Review changes submitted by your coauthors (if any).  We assume that
   you will speak up if you do not agree with the proposed changes.
   That is, your silence is your assent to changes submitted by your
   coauthors. Note that any changes that are beyond editorial will be
   sent to the relevant body for approval.

5) Review the copyright notice and legends as defined in RFC 5378 and the
   Trust Legal Provisions (TLP -- https://trustee.ietf.org/license-info/).

   If your document was approved for publication with a pre-RFC-5378
   copyright notice, we have applied the text from section 6.c.iii of the
   TLP.  Please consider whether this text is required (note that the
   6.c.iii text is not applicable to Alternate Stream RFCs).  See item
   4.5 of the "Copyright FAQ" at https://trustee.ietf.org/faq.html for
   guidance on whether this text applies to your document.

6) Please reply, as the document will not be published until we receive
   approvals from each author.  The details of the AUTH48 status of your
   document are here:

   https://www.rfc-editor.org/auth48/rfc8313

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC8313 (draft-ietf-mboned-interdomain-peering-bcp-14)
--------------------------------------
Title            : Use of Multicast Across Inter-Domain Peering Points
Author(s)        : P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan
WG Chair(s)      : Greg Shepherd, Leonard Giuliano
Area Director(s) : Benoit Claise, Warren Kumari