Subject: Re: [sidr] WGLC - draft-ietf-sidr-as-migration

From: Christopher Morrow <[email-masked]>
Date: Fri, 12 Sep 2014 10:29:14 -0400

Boo! people ought to read and write.. it's friday! take some time to
review and make sure there's not like mistakes and stuff in this, eh?
:)

(please? :) )

-chris

On Thu, Aug 28, 2014 at 10:46 AM, Chris Morrow <[email-masked]> wrote:
> Howdy SIDR folken,
> It's time again to dust off your spectacles and dive into a wonderous
> world of 'potential RFC' reading material!!
>
> It'd be great if we could start this WGLC today:
>   8/28/2014 or
>   August 28 2014 or
>   the 240th day of this year 2014
>
> and end it in 2 weeks time on:
>   9/11/2014
>   September 11, 2014
>   the 254th day of this year 2014
>
>
> for the draft in the subject line: draft-ietf-sidr-as-migration
> the abstract of which is copied herein for your convenience:
>
>   "This draft discusses considerations and methods for supporting and
>    securing a common method for AS-Migration within the BGPSec
>    protocol."
>
>
> This document's pair is in IDR WGLC at this time as well, that document is:
>   <http://tools.ietf.org/html/draft-ietf-idr-as-migration>
>
> happy reading and please send comments/concerns/adulation to the list.
>
> -chris
> wg-co-chair
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 18 Sep 2014 12:48:50 -0400

Helo from sidr-co-chair:
Are there no more comments and concerns and improvements and "Hey,
awesome draft!" things to be said about this draft?

With no input it's a tad hard to judge the quality of the draft and
it's applicability to SIDR in general...

-chris
(note, I've read the draft and think it's helpful to migrating
operational networks together... in a land where SIDR is in play)

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Sep 2014 11:23:22 +0900

i think i already said this.  but i have reviewed.  the scheme is
solid.  the document is in scale to the scope of the problem
(unfortunately not simple).  ship it.

randy

---

From: Terry Manderson <[email-masked]>
Date: Fri, 19 Sep 2014 03:17:06 +0000

The document is stable, and well written.

I re-read it (even with jetlagged eyes) and saw nothing that caused
concern. The corollary, and as mentioned in the draft, is that without
_really_ understanding the companion document in IDR any attempts to pick
this text up to read as a standalone is pointless.

I think this document can move forward.

T.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 29 Sep 2014 14:22:59 +0000

I support the publication of this document as an RFC.
I have read the revised -02 version carefully.
The description of the methodology is clear, and no inconsistencies found 
with reference to the BGPsec protocol draft [draft-ietf-sidr-bgpsec-protocol]. 

I thank the authors for incorporating most of my earlier comments/suggestions.
Some minor nits/editorial comments follow:

1. Figures 3 and 4 from the companion I-D draft-ietf-idr-as-migration are referenced 
several times in this document. It would be easier for the readers if those two  figures 
are reproduced in this document when they are first referenced. 
Readers can then avoid having to go back and forth between the two documents.

2. The meaning of this sentence on p.4 is lost on me. 

"Since they
   are using methods to migrate that do not require coordination with
   customers, they do not have a great deal of control over the length
   of the transition period as they might with something completely
   under their administrative control (e.g. a key roll)."

For me, "do not require coordination with customers" and 
"completely under their administrative control" are on the same 
side of the equation.

May be this paraphrasing will help:
"Since they
   are using interim methods to migrate that seek to postpone
 requiring coordination with
   customers, they do not have a great deal of control over the length
   of the transition period as they might with something completely
   under their administrative control (e.g. a key roll)."

3. Sentence on p.5 reads:

"Assuming that this mismatch will be allowed by vendor implementations
   and using it as a means to solve this migration case is likely to be
   problematic."

Please consider changing it to (for grammatical accuracy):

"Assuming that this mismatch will be allowed by vendor implementations,
   using it as a means to solve this migration case is likely to be
   problematic."

Thanks.

Sriram

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Sep 2014 10:18:42 +0900

> 1. Figures 3 and 4 from the companion I-D draft-ietf-idr-as-migration
>    are referenced several times in this document. It would be easier
>    for the readers if those two figures are reproduced in this
>    document when they are first referenced.

uh, having data in two places is a recipe for trouble.  this is why we
do references.  i really don't like copy and paste between docs.  but
perhaps i am alone in this.

rest of your comments fool me into belief :)

randy

---

From: "George, Wes" <[email-masked]>
Date: Tue, 30 Sep 2014 13:28:33 -0400

>perhaps i am alone in this.

WG] I agree, my preference is to leave the diagrams in the referenced
document, and assume that those reviewing can manage to have two parallel
windows open (one of the few places where IETF's self-imposed text-width
restrictions come in handy) or briefly commit the "high-quality" ASCII
diagrams to memory.

Sriram, I'll incorporate the rest of your feedback into my next version,
which will likely be posted either at IETF LC or due to directorate review.

Thanks for giving it another look

Wes

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.