On 3/31/15, 2:29 PM, "George, Wes"
mailto:wesley.geo...@twcable.com>> wrote:
Wes:
Some replies below.
Thanks!
Alvaro.
Added SIDR, responses below inline, which of course messed up your original
numbering.
I haven't pushed the rev yet, as I'm waiting to make sure that I don't need to
make a
Hi!
I have a couple of Major comments related to the existence/co-existence of two
versions of the protocol. I would like to see the comments discussed/addressed
before starting the IETF Last Call.
Thanks!!
Alvaro.
Major:
1. RFC6810.
* Section 1.2. (Changes from RFC 6810): "The
On 4/26/16, 6:58 PM, "Rob Austein" wrote:
Rob:
Hi!
>At Sat, 23 Apr 2016 00:09:07 +, Alvaro Retana (aretana) wrote:
>>
>> * Section 1.2. (Changes from RFC 6810): "The protocol
>> described in this document is largely compatible wit
On 5/26/16, 11:15 AM, "sidr on behalf of Stephen Kent"
wrote:
[Sorry for the delay...]
>
>> ...
>>> It means that most of the code one needs to deal with version one is
>>> the same as the code one needs to deal with version zero. Feel free
>>> to suggest better text.
>> When I think about prot
Rob:
Hi!
Did you have comments on this? I'm assuming that we're expecting an
updated document at some point, but if we need to discuss more...
Thanks!
Alvaro.
On 5/25/16, 12:09 AM, "Alvaro Retana (aretana)" wrote:
>On 4/26/16, 6:58 PM, "Rob Austein" wro
Dear authors:
Hi! First of all, thank you for taking on the duties of editing this document.
I have several comments (see below). For the most part, I think they should be
easy to solve as many are related to clarifications. Most of the comments I
classified as Major are due to the use of No
Randy:
Hi! Thanks for working on this document!
I have two issues I want to highlight upfront, and then some comments (below).
I would like to see these two issues addressed, along with the Major comments
below, before moving the document forward.
These two upfront issues are probably more q
Dear authors:
Hi!
I have a couple of comments about this document (below). I am going to start
the IETF Last Call, and schedule it in the next IESG Telechat, with the
expectation that my comments will be addressed before then.
Thanks!
Alvaro.
C1. The reference to rfc7607 should be Informat
Either way is fine. The document is scheduled for the Telechat on Dec/15. I
expect maybe a couple of directorate reviews before that – if they come in by
Dec/9 and you have time to pdate, then please do. Otherwise, let’s wait for
the IESG to comment.
Thanks!
Alvaro.
On 11/13/16, 4:25 PM, "R
Hi!
Yes, the text below works for me. And I would assume it works for Tero as well.
Thanks!!
Alvaro.
On 11/30/16, 11:20 AM, "John G. Scudder"
mailto:j...@juniper.net>> wrote:
On Nov 30, 2016, at 9:18 AM, Randy Bush mailto:ra...@psg.com>>
wrote:
section 4.5 of 4593 is relevant, or all of sec
On 11/27/16, 12:21 PM, "Sriram, Kotikalapudi (Fed)"
wrote:
Sriram:
Hi! Thanks for addressing my comments. I have some remaining comments below.
I flagged a couple of items that I think the Chairs should consult the WG on,
but I’ll leave it up to them to decide that – note that I don’t
Just noticed one more thing: the reference to I-D.ietf-sidr-rtr-keying is no
longer needed.
Thanks!
Alvaro.
On 12/1/16, 9:10 PM, "Alvaro Retana (aretana)"
mailto:aret...@cisco.com>> wrote:
On 11/27/16, 12:21 PM, "Sriram, Kotikalapudi (Fed)"
wrote:
Sriram:
Randy:
Hi!
Do you think we can get an update out for this document soon? I just put the
BGPsec spec up for the Jan/5 IESG Telechat, and it would be great if we could
get this document in as well.
Thanks!
Alvaro.
On 11/8/16, 12:28 AM, "Randy Bush" mailto:ra...@psg.com>> wrote:
thanks for th
On 12/2/16, 10:56 AM, "Randy Bush" wrote:
Randy:
Hi!
I’m fine with your comments, proposed text. Just a couple of more replies
below.
Thanks!
Alvaro.
…
> > M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out
> > over…a long time. Hence a normal operator's polic
Dear authors:
Hi! I just finished reading this document.
I have some comments (please see below) I would like you to address, but I
wouldn’t characterize any of them as major, so I’m starting the IETF Last Call
and placing this document in the next available IESG Telechat.
Thanks!
Alvaro.
That workd for me.
Thanks!
Alvaro.
On 12/6/16, 4:08 PM, "Sean Turner" mailto:s...@sn3rd.com>>
wrote:
I concur and I’ve got an editor’s copy with all the changes incorporated.
Unless I hear otherwise I’ll hold off on posting until we’ve collected and
addressed all of the other IETF LC commen
Randy:
Hi!
In thinking about this point some more…what about draft-ietf-sidr-slurm? Isn’t
that supposed to address the private space?
Thanks!
Alvaro.
On 12/2/16, 12:56 PM, "Randy Bush" mailto:ra...@psg.com>> wrote:
M4. Still in Section 7: “To prevent exposure of the internals of BGP
Confed
Hi!
Yes, there should be something about private ASNs in the protocol spec.
It would be nice to also see some operational guidance in this document.
Alvaro.
On 12/7/16, 7:07 PM, "Randy Bush" mailto:ra...@psg.com>> wrote:
otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
[Changed the Subject to specifically discuss Confederation support, and
hopefully get some attention from the WG.]
Sriram:
Hi! I think the only item left is the Confederations one…and we might be
speaking past each other.
Yes, I agree that the collusion problem is one that (as you mentioned
Yes, I agree. I just sent a message to the authors of the protocol spec (cc’d
the WG) along the same lines.
On 12/9/16, 7:57 PM, "Randy Bush" mailto:ra...@psg.com>> wrote:
first the protocol spec needs to make clear if the real AS can proxy
sign for a connected private AS. then i can hack the
On 12/12/16, 8:34 AM, "Mirja Kuehlewind" wrote:
Mirja:
Hi!
> --
> COMMENT:
> --
>
> Just a thought: Would it be useful to add an IESG note saying something
> l
On 12/13/16, 7:26 AM, "Sriram, Kotikalapudi (Fed)"
wrote:
> [Sriram-3] I understand now your main comment about confederation. I think
> there are
> two ways to address it (of course I hope other people chime in as well):
>
> Choice A: The pCount = 0 solution that you have suggested.
>
>
Dear authors:
Hi! I just finished reading this document.
I have several comments (please see below); I marked many of them as “Major”,
some because of the use of Normative language, but my main concern is that I
think error conditions in the protocol are underspecified (see M7, M8, M10,
below
Rob:
Hi! How are you?
I just finished reading this document. Thanks for the work!
I have some comments (below) that should be easy to address. I think the major
one is about the ordering of the XML attributes (C2); I’ll start the IETF Last
Call once (at least) that point is resolved.
Thank
On 12/20/16, 12:33 PM, "Rob Austein" wrote:
| At Tue, 20 Dec 2016 14:24:27 +0000, Alvaro Retana (aretana) wrote:
| | C1. Why isn?t an IETF namespace [RFC3688] used in the XML schema? I
| | would strongly suggest that you use one and request it in the IANA
| | Consideratio
Hi!
I am (obviously) fine with it.
Thanks!
Alvaro.
Thumb-typed and autocorrected..
> On Dec 20, 2016, at 5:56 PM, Sriram, Kotikalapudi (Fed)
> wrote:
>
> If we agree and others on the WG list express no objection or find no fault
> in this solution, I will be happy to go ahead and add this
Rob:
Hi!
You added some text about offer and referral:
A parent is unlikely to need to send both and
elements, but strictly speaking they are not mutually exclusive, so a
parent which really needs to express that it both offers repository
service to its child and is also willing to ref
Yes, I’m good.
Thanks!!
Alvaro.
On 12/21/16, 1:13 PM, "Rob Austein" mailto:s...@hactrn.net>>
wrote:
I hope this addresses the issue.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On 12/21/16, 12:47 PM, "Sriram, Kotikalapudi (Fed)"
wrote:
Sriram:
Hi!
| I said in my previous post:
| "(2) It also keeps confed ASes from failing to validate properly the
signature injected at the boundary."
|
| I retract my observation…
…
|
| So let us focus back on only your or
Hi!
I don’t think there’s anything to be done, besides the guidance already in the
draft about path preference: prefer Valid paths. If the validity state changes
later, then it becomes a local policy to use or not.
Alvaro.
On 1/2/17, 8:37 PM, "Randy Bush" mailto:ra...@psg.com>> wrote:
it is
On 1/3/17, 9:00 PM, "Randy Bush" wrote:
| | -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
| | needed to understand this document. That suggests it should be a
| | normative reference.
|
| ennie meenie. i think some other reviewer had me push refs around. i
| don't
Randy:
Just one nit: RFC6490 was obsoleted by rfc7730.
Sorry I didn’t catch this earlier. I think this is the last change needed, so
I’ll take care of it with a note to the RFC Editor.
Thanks!
Alvaro.
On 1/4/17, 11:06 PM, "iesg on behalf of Randy Bush"
mailto:iesg-boun...@ietf.org> on beha
of them to
| disagree or suggest changes to the things below.
Thanks for that. I have some comments below – I want us to discuss the Update
issue (M16) so we can start the IETF Last Call.
Thanks!
Alvaro.
| On 20 Dec 2016, at 14:15, Alvaro Retana (aretana) wrote:
…
| | M2. S
On 1/6/17, 12:40 AM, "Sriram, Kotikalapudi (Fed)"
wrote:
[Cut the distribution list a little.]
Sriram:
Hi! Happy New Year!
I have some comments on this, please see below.
Thanks!
Alvaro.
…
| | 1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are
mutua
Tim:
Congratulations! ☺
I think we’re in sync with everything else, just this last piece is outstanding.
Thanks!
Alvaro.
On 1/9/17, 6:55 AM, "Tim Bruijnzeels" mailto:t...@ripe.net>>
wrote:
Let me try to make the point again – I didn’t do a good job above. In fact,
reading this over I w
Rob:
Thanks for the update! I’m starting the IETF Last Call.
I have two comments that result from not Obsoleting RFC6810:
1. If this document is not Obsoleting RFC6810, then clarifying the title
would avoid confusion from having 2 RFCs with the same name. My suggestion is
to change th
Mirja:
Hi!
If an AS in the path doesn’t support BGPsec, then BGP goes back to “normal”
mode (as in before BGPsec), and the assurance that the “update propagated via
the sequence of ASes listed” is lost. In other words, from the origin AS to
the AS before the one not supporting BGPsec, we can
Sriram:
Hi!
Yes, I think I may have read more into Keyur’s comment than what he was asking
for, so I think we’re ready to go. ☺
I’ll approve publication.
Thanks!!
Alvaro.
On 1/16/17, 10:10 PM, "Sriram, Kotikalapudi (Fed)"
mailto:kotikalapudi.sri...@nist.gov>> wrote:
Hi Alvaro,
... snip ..
ACK
On 1/17/17, 10:52 AM, "Mirja Kuehlewind (IETF)"
mailto:i...@kuehlewind.net>> wrote:
thanks for the very clear clarification. Not sure if it’s just me or if that’s
not clearly stated in the draft, but maybe it would be worth it double-checking.
___
[Oleg: Thanks for the update!]
Dear WG:
One of the significant changes in this version is an Update to RFC6480,
RFC6481, and RFC7730, in order to remove the normative dependency on rsync as
needed in every deployment. Please take a close look at the new text in
Section 4.
Thanks!
Alvaro.
Hi!
I was going to wait for the author, but he has been out sick this week… ☹
Picking up from Benoit’s comment – the use of “protocol” is misleading. What
is described is a process that can be followed and the necessary information
exchanged “to simplify configuration…by setting up relationshi
Thanks Rob!
Yes, initially this document was marked to obsolete rfc6810, but at the same
time it mandated the use of the previous version as part of the Protocol
Version Negotiation. Given that it may take a while before caches and routers
both implement this new version, we decided to settle
Hi!
I just want to provide a little bit more background on the topic below – and
ask the Chairs to take an action to confirm with the WG.
During the discussion resulting from my AD review of this document [1], the
topic of whether the intent of the document was to replace rsync or not came up
Tim:
Hi!
Given the feedback so far on the list, I think we should roll back the updates
in preparation for next week’s IESG Telechat.
Thanks!
Alvaro.
On 2/17/17, 9:56 AM, "sidr on behalf of Alvaro Retana (aretana)"
mailto:sidr-boun...@ietf.org> on behalf of
aret...@cisco.co
[Took the IESG, ietf-announce and rfc-editor lists off.]
Jakob:
Hi!
This document is already in AUTH48. I don’t think we need to make any changes
to the document, but if we do, we need to decide very soon.
The document doesn’t say anything about what should be done with this extended
communi
Hi!
I just approved!
Thanks!
Alvaro.
On 3/6/17, 11:54 AM, "sidr on behalf of Sean Turner" wrote:
This version addresses the IESG comments we got from Alexey (drive home the
point that these algs are different than the rest of the RPKI) and Stephen (add
examples). As you may have seen, Ol
Dear authors:
I just finished reading this document. My review is predicated on the
assumption that the intent of the WG is to define an additional validation
process, and not amend/change/update/deprecate the existing one…yet, which is
why there are not only process changes specified, but als
Hi!
[Speaking as AD]
The requirement for Extended Messages has been in the BGPSec draft since the
beginning (at least the WG -00 version). Changing it now would mean a
significant deviation in the process – but not impossible.
Before committing to supporting any change to the document, I woul
On 4/4/17, 12:44 PM, "Matthew Lepinski" wrote:
Matt:
Hi!
> The proposed changes seem reasonable, but I want to make sure that I
> understand the path forward clearly.
>
> My understanding is that if we were to reach a future where
> draft-ietf-idr-bgp-extended-messages is widely deployed, then
Dear authors:
Hi!
It’s been 3 months since this e-mail, which was the last of the thread started
from my review.
I am expecting a revised ID – what are the plans to move forward?
Thanks!
Alvaro.
On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels"
mailto:sidr-boun...@ietf.org> on beh
On 6/22/17, 10:36 AM, "Tim Bruijnzeels" wrote:
Tim:
Hi!
> All that said I will work on an update of this document following
> Alvaro’s review. This document will define an additional validation
> algorithm, but not update the existing one. We can finish this work
> first and then have a stru
Dear sidr WG:
I want to call attention to this Last Call.
The document has undergone significant editorial changes since the WGLC – none
of which change the operation or other technical aspects. The changes are
meant mainly to not obsolete the current procedures at this time.
I have asked for
On 8/24/17, 9:55 AM, "Mirja Kühlewind" wrote:
Mirja:
Hi!
> --
> COMMENT:
> --
>
> Given this new mechanism seems to be the recommended way of doing things, I
>
[Explicitly adding Terry…]
Tim:
Hi!
As I think you understand from the response below, there are two parts to
consider when deploying: what can be done, and what will be done. Interpreting
what Ben and Terry wrote…what I think they are asking is for you to clarify in
this document the consid
54 matches
Mail list logo
