Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

On Oct 14, 2015, at 5:25 PM, George, Wes wrote: > Gave this a review, and stumbled across an issue that may not necessarily > be gating to this draft, but should probably be addressed in some other > drafts. … > > Substantive: I had to think through this for a bit

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

On 10/14/15, 7:20 PM, "Sriram, Kotikalapudi" wrote: >>There is a discussion in 6.4 of Sriram's design-choices doc, but I think >>it's incomplete >>since it only discusses it in terms of it being unacceptable to sign >>updates that it can't verify. > >"unacceptable

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

Gave this a review, and stumbled across an issue that may not necessarily be gating to this draft, but should probably be addressed in some other drafts. Regarding this text in 4.2: "Additionally, BGPsec requires that all BGPsec speakers will support 4-byte AS Numbers [RFC6793]. This is

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

>I think that this is a specific corner case for the more generic case of >incremental >deployment, where a given path has some routers/ASNs that support BGPSec >and some that do not, and as far as I can tell, incremental deployment isn't >really >discussed as a concept beyond the

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

The doc cites a bunch of i-d's. Under previous practice, that would have left it languishing in the RFC Editor queue waiting for the others. If that were the practice now, I would suggest we hold it and release all of the docs as a group, which would permit later changes to this doc if

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

Ah so I guess this one is informational so it could proceed without the waiting for all the refs, but I do think we can ask the RFC editor to hold it for at least the normative refs. When progressing a block of drafts, there’s always a bunch of tradeoffs to deal with: 1) Will the IESG be upset

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

On 10/8/15, 9:54 AM, "sidr on behalf of Sandra Murphy" wrote: > The system changed it to Dead from "AD is Watching" when the draft >expired. > > In any case, all "Dead" means is that the IESG is not tracking the >document, not that

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

On Oct 7, 2015, at 5:24 PM, Sean Turner wrote: > We’ll need to figure out what to do about the I-D.sidr-as-migration reference > it’s in the “IESG Dead” state. Thanks for the heads up, we’ll investigate with the AD. —Sandy, speaking as wg co-chair > > I guess s3.2 is going

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

Speaking as regular ol’ member On Oct 7, 2015, at 5:24 PM, Sean Turner wrote: > We’ll need to figure out what to do about the I-D.sidr-as-migration reference > it’s in the “IESG Dead” state. > > I guess s3.2 is going to match whatever updates are made to > bgpsec-protocol-14.

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

On Oct 8, 2015, at 5:14 AM, Sandra Murphy wrote: > > On Oct 7, 2015, at 5:24 PM, Sean Turner wrote: > >> We’ll need to figure out what to do about the I-D.sidr-as-migration >> reference it’s in the “IESG Dead” state. > > Thanks for the heads up, we’ll

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

We’ll need to figure out what to do about the I-D.sidr-as-migration reference it’s in the “IESG Dead” state. I guess s3.2 is going to match whatever updates are made to bgpsec-protocol-14. spt On Oct 07, 2015, at 11:32, Chris Morrow wrote: > > Howdy WG folks, >

[sidr] WGLC: draft-ietf-sidr-bgpsec-overview ENDING: 10/21/2015)

Howdy WG folks, Please consider this your warning/notice that the WGLC has been started for: draft-ietf-sidr-bgpsec-overview Abstract: "This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves security for