-
Notifications
You must be signed in to change notification settings - Fork 0
/
auth48-questions-reply.txt
333 lines (298 loc) · 12.3 KB
/
auth48-questions-reply.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
Dear RFC editor
I have attached a fixed up XML file with the changes as described below.
(added keywords, removed rfcED comments, changed text where rfc editor had questions).
Text diff:
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/toerless/peering-bcp/master/auth48-rfc8313.txt&url2=https://raw.githubusercontent.com/toerless/peering-bcp/master/auth48-rfc8313-reply.txt
Explanations / answers following:
>
> 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 -->
Thanks. See list below. Not sure if keywords that are multiple words
(eg: multicast security) are permitted. Likewise for variations that
users likely may look for even if "incorrect" (MBGP, M-BGP).
Just remove what you do not like.
<keyword>multicast security</keyword>
<keyword>multicast troubleshooting</keyword>
<keyword>multicast routing</keyword>
<keyword>multicast tunneling</keyword>
<keyword>PIM</keyword>
<keyword>PIM-SSM</keyword>
<keyword>SSM</keyword>
<keyword>Source Specific Multicast</keyword>
<keyword>AMT</keyword>
<keyword>GRE</keyword>
<keyword>Automatic Multicast Tunneling</keyword>
<keyword>BGP</keyword>
<keyword>MBGP</keyword>
<keyword>M-BGP</keyword>
<keyword>MP-BGP</keyword>
<keyword>exchange</keyword>
<keyword>exchange point</keyword>
<keyword>NNI</keyword>
<keyword>content distribution</keyword>
<keyword>video streaming</keyword>
<keyword>anycast</keyword>
> 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. -->
Good change. thank you.
> 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. -->
Good changes. thank you.
> 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.
The best wording would IMHO be:
also, either AR = uBR (AD-1) or uBR = AG (AD-2)";
> (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").)
Which should be
also, either AR=uBR (AD-1) or ubr=AGAR1 (AD-2)
The idea is that only one of the uBR could include the multicast
function (AR/AG/AGAR1). If both uBR can do the multicast functions,
then the cases deteriorate to use case 3.1.
(Geeks would of course write xor instead of either/or ;-)
> 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.
>
> -->
Please use the word adaptation, that seems to be the preferred form:
http://grammarist.com/usage/adaption-adaptation/
(I guess i was always preferring adaption because its the same word in German.)
> 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. -->
No action on author side i think (otherwise approved).
> 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). -->
Sending is an activity performed by a source, so "are permitted _to_be_ sent"
sounds wrong to me. "are permitted to send" would IMHO be correct. Also
remove the parenthesis around the last part, that is the key piece of
the sentence, the rest is just the necessary context.
>
> Thank you.
Thank you so much. Lots of great editorial improvements of the doc through
your work, just read through it again.
Of course somewhat frustrating to see how bad the english of
the document was, but i fancy myself in two excuses: a) i am not a native
english speaker, b) there are hopefully a lot better writers that only
manage to produce readable books beause of good editors ;-)
Only outstanding change from my side is my previously raised ask for
a second email address for me in the doc.
Cheers
Toerless
> 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
>