Subject: [RPSEC] Scope was Re: Please vote

From: "Tom Petch" <[email-masked]>
Date: Sat, 1 Oct 2005 11:46:04 +0200

I was fishing for something more than a change from RFC1771 to RFC4271.  Have
the editors actually read the later BGP specification and used it in this draft
or is the draft based on BGP as specified in RFC1771?

The reference to RFC1771 suggested the latter to me, in which case just changing
the reference I do not see as enough.

Tom Petch

----- Original Message -----
From: "Tony Li" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: "Russ White" <[email-masked]>; <[email-masked]>; "Tony Tauber"
<[email-masked]>; "Tom Petch" <[email-masked]>
Sent: Friday, September 30, 2005 10:20 PM
Subject: Re: [RPSEC] Re: Please vote

>
> On Sep 30, 2005, at 12:29 PM, Alex Zinin wrote:
>
> >
> > Russ wrote:
> >
> >> The new draft is a valid point, but I believe this would be
> >> updated in
> >> the iesg process, so we could give the current bgp draft a chance to
> >> become rfc'd before referencing it. Maybe Alex or Bill would have
> >> more
> >> to say on the process.
> >>
> >
> > The BGP spec update is on its way out of the RFC-Ed queue--we got a
> > msg
> > from them yesterday asking about RFC number preferences. You can
> > either
> > wait, or put "RFC ????" in the refs and it'll be fixed during the RFC
> > editor process.
>
>
> The update will be RFC 4271.
>
> Tony
>

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Sat, 01 Oct 2005 13:10:45 -0400

The current draft is based on the current BGP specification, not on the 
older one. It's generally easier to reference an RFC than a draft, and 
since the new version was already making it's way through, it just 
seemed easier to reference the older draft, and switch to the new one, 
than to reference the draft, and then switch to the RFC number when it 
was given a number.

I hope that makes sense.

:-)

Russ

>>The update will be RFC 4271.

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Tony Tauber <[email-masked]>
Date: Sun, 2 Oct 2005 20:55:23 -0700 (PDT)

On Sat, 1 Oct 2005, Tom Petch wrote:

> I was fishing for something more than a change from RFC1771 to
> RFC4271.  Have the editors actually read the later BGP specification
> and used it in this draft or is the draft based on BGP as specified
> in RFC1771?
>
> The reference to RFC1771 suggested the latter to me, in which case
> just changing the reference I do not see as enough.
>
> Tom Petch

Hi Tom,

I plead guilty for only having sounded off on one of your
questions/suggestions and somewhat glibly at that.

I can take only some of credit/blame for the draft having come in to
do the more recent and minor revisions, mostly with input from others.

However, my take, and I went back to review some of the relevant bits
of the two docs at hand, is that the parts which inform the BGP
Security Requirements doc don't differ substantially in the two BGP
specs.

If others have different assessments, I'm hope they'll share their
thoughts.

As for your comments on TLS, it seems to have been seconded and can be
dropped.  The words on key management are also well taken, I can
integrate that as well.

Regarding the "other attributes" question:
In the case of communities, since they can be added, modified, or
removed by any AS, they should considered suspect, IMHO.  As for other
features or attributes, I don't think we've heard clearly from the WG.

Thanks,

Tony

---

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Oct 2005 10:37:35 -0400

>If others have different assessments, I'm hope they'll share their

The latest spec, now in the RFC editor's queue, explicitly 
acknowledges the legitimacy of an AS adding multiple instances of its 
own AS to the path, something we discuss, so I think this is the spec 
to reference.

>features or attributes, I don't think we've heard clearly from the WG.

The fact that communities are subject to a wide range of legitimate 
modification does not mean that they are unable to be protected. 
No-export is a prime example of a community that has significant 
semantics and should be covered.

Steve

---

From: Tony Tauber <[email-masked]>
Date: Mon, 3 Oct 2005 11:42:39 -0700 (PDT)

On Mon, 3 Oct 2005, Stephen Kent wrote:

> acknowledges the legitimacy of an AS adding multiple instances of
> its own AS to the path, something we discuss, so I think this is the
> spec to reference.

Right, I noticed that, too.

>> Regarding the "other attributes" question: In the case of
>> communities, since they can be added, modified, or removed by any
>> AS, they should considered suspect, IMHO.  As for other features or
>> attributes, I don't think we've heard clearly from the WG.
>

It does have significant semantics, but can validly be modified by any
AS or node, though a "rogue node" w/in an AS shouldn't be able to do so.
I'm guessing you might be suggesting we stipulate that one be able to
detect when it's been removed or when an UPDATE that had it set by
some upstream AS is still getting propagated.

Can any BGP implementors give some indication of whether or not they
implicitly don't propagate UPDATEs which are received with NO_EXPORT
set?

Tony

---

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Oct 2005 15:01:30 -0400

>some upstream AS is still getting propagated.

yes, that's one obvious example. also the ability to determine which 
AS in a path added a community seems like a desirable feature.

Steve

---

From: Tony Tauber <[email-masked]>
Date: Wed, 5 Oct 2005 08:11:50 -0700 (PDT)

A week has passed and I believe the voting thus far has been:

Russ White, Blaine Christian, and Stefan Mink have voted that the
document should progress.

Tom Petch, Sue Hares, and Steve Kent have voted that the
document is not ready but have suggested places they'd like to see
modifications, though the particulars need to be worked out.

Tony Li believes that this document goes in entirely the wrong
direction.

Any other voices who'd like to sound off?  There are a few others
who've been vocal but for whom I couldn't seem to find clear votes
expressed.

I'll give it until COB this Friday.

Tony

On Tue, 27 Sep 2005, Tony Tauber wrote:

> Folks,
>
> Since it seems we're going around and around on the latest vibrant
> set of comments, let's work on a clear vote on the document as it
> stands.
>
> Please convey your opinion on whether this document should progress.
> If an unqualified "yes" or "no" doesn't represent your view, please
> try and _succinctly_ relate what would need to be changed for the
> document to meet with your approval.
>
> Tony