Hi Chris,
With regards to "draft-rir-rpki-allres-ta-app-statement², the question for
the WG acceptance should go back to the authors on their willingness to
take WG feedback.
If the aim is to work with the WG, I think the document describes a
current problem with inter-RIR address transfers and
Hi Andrew,
Taking into consideration your call for transparency, do you think the RIRs
could add a section on the document where it is clearly stated what are the
roadblocks to have a single root? I believe the document describes the problem
and one technical feasible solution but not the full
Carlos,
I guess what the RIRs are going to do is to create a CA hierarchy:
RIR_CA_0/0_(probably a hidden HSM) ‹> RIR_CA_RIR_RESOURCES (online HSM) ‹>
member_CA
This means that not much changed from the current situation multiple
self-signed certs, other than instead of getting the list of
+1 with Standard Track.
The question could have been relevant six years ago and we may not have
debated it that much then. Today, we are clearly beyond experimental draft
definition and we do not want to stop people working on the topic.
Roque
On 14/04/16 22:20, "sidr on behalf of Geoff
Hi Geoff,
In many cases we publish an Appendix on update documents detailing the
changes from previous version and given the rational that Arturo mentioned.
Roque
‹
Roque Gagliano
Tail-f Solutions Architect Southern Europe
+41 76 449 8867
On 13/10/15 20:06, "sidr on behalf of Geoff
Iljitsu,
It is not an implementation choice, it is by design. If a signed object does
not validate (based on whatever reason not just expiration), it is like if did
not existed.
I guess your point is covered.
Roque
Sent from my HTC
- Reply message -
From: Iljitsch van Beijnum
On 20/03/15 21:20, Rob Austein s...@hactrn.net wrote:
At Fri, 20 Mar 2015 12:35:42 -0500, Randy Bush wrote:
I?ll caveat this by saying I am definitely not hard over on this, but
I thought I?d bring it up: Should we switch to a SHA-256-based key
identifier?
all the kool kids are doing
Chis,
The document is now RFC 6912 published as BCP.
Regards,
Roque
On 14/11/14 21:00, Christopher Morrow christopher.mor...@gmail.com
wrote:
Also there was a question (from hannes?) about algorithm change
processes and timelines.. that's covered in:
Hi Leo,
I was thinking that letting the resource owner know that its certificate or
ROA failed validation and why could be helpful to the resource owner and
help minimize routing failures based on validation failures.
If I want to be contacted, I can issue a Ghostbuster RR:
Terry,
I have two other comments on this draft.
4.1. Algorithm based on jurisdiction
(Roque) My (basic) understanding of the GHOST problem when tackled by the
DNSSEC people is that it end up been a no-problem. A lot of discussions, lot of
waisted time, support for GHOST was added to
Hi Terry,
Thanks for this effort.
Overall I think there are good points that you raise.
However, I am struggling with the relevance from a CA perspective of Section 7
(Communication from validators to objects signers regarding validation status).
Validation is a local process done from RPs.
I read the document and support its publication.
Roque
From: Carlos M. Martinez
Date: Fri Sep 26 2014 17:07:07
To: Sandra Murphy
Subject: Re: [sidr] WGLC on draft-ietf-sidr-rfc6490-bis-01.txt
I support publication of this document.
On 26/09/2014 11:17, Sandra Murphy wrote:
The authors of
Hi Wes,
Thanks for your message, I think it is always great to have a fresh view when
we are looking at new problems.
I have some comments inline.
Cheers!
Roque
On Aug 5, 2014, at 5:51 PM, George, Wes
wesley.geo...@twcable.commailto:wesley.geo...@twcable.com wrote:
On 8/4/14, 5:47 PM,
Randy,
because the goal of this draft can already be reached simply through use
of existing means, i do not support publication. i am not strongly
opposed. it's just one more bit of ietf work that is not obviously
needed.
Here are the three reasons that may refresh our mind on why after 4
Randy,
while checking the docco, i found
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms SHOULD conform with
On May 5, 2014, at 9:41 AM, Randy Bush ra...@psg.com wrote:
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing decisions. Such
mechanisms SHOULD
Sandy,
I support the addition of multiple publication points as working group item and
hope to go quickly through the process.
Roque
Initial Comments:
Section 2.1
(Roque) We received the request from the WG to add a blank line break between
the URI section and the public
Geoff,
On Feb 10, 2014, at 5:43 PM, Geoff Huston gih...@gmail.com wrote:
On 11 Feb 2014, at 3:23 am, Roque Gagliano (rogaglia) rogag...@cisco.com
wrote:
Hi Goeff,
On Feb 9, 2014, at 11:05 PM, Geoff Huston gih...@gmail.com wrote:
Hi,
I took the text n draft-ietf-sidr-multiple
I support adoption. I think it is important work.
Roque
On Jan 10, 2014, at 9:33 PM, Murphy, Sandra sandra.mur...@parsons.com wrote:
There were four responses to this adoption call, all positive. But four is
not a strong indication of wg wishes here.
Can others please look at this and
document.
- A new BCP/Informational document on best practices when RPKI
certificates include multiple repository operators for the same materials.
We look forward to hearing from you,
Regards,
Roque + Carlos + Terry
On Oct 2, 2013, at 9:58 AM, Roque Gagliano (rogaglia) rogag...@cisco.com
Hi Sandra,
Thanks for all your comments. To be honest, we did not updated the document for
quite some time waiting for the advancement of the BGPSEC
thread/requirements/protocol documents. I agree that we should now update it to
be consistent with the changes in the main documents but I
Thanks Sharon for your email and analysis. These points are some of the points
raised during our last meeting.
I personally believe that the non-TAL work requires more research activity and
I guess from your email that you have an interest in this area :-).
Regards,
Roque
Hi Roque,
As you
Sandy,
I agree with Randy that (we) the authors are in fault here.
I will work with my co-authors to bring a proposal to the group on how to move
forward with the document.
Roque
On Sep 27, 2013, at 10:02 PM, Randy Bush ra...@psg.com wrote:
imiho, mailing list discussion has raised issues
implements-include or contain or...
RP- relying party (or you'll have to define the acronym somewhere)
Not sure what as in IDR means.
From: Andy Newton [a...@arin.net]
Sent: Tuesday, July 16, 2013 9:49 AM
To: Roque Gagliano (rogaglia)
Cc: Murphy, Sandra
that implements the changes in Section 2. At the time of this
writing, all known RP software suites (you can mention them as in IDR) were
tested and supported the updates on this document
Roque
On Jul 15, 2013, at 7:07 PM, Andy Newton a...@arin.net wrote:
On 7/15/13 10:22 AM, Roque Gagliano (rogaglia
I support adoption.
Roque
On Jul 4, 2013, at 11:36 PM, Murphy, Sandra sandra.mur...@sparta.com wrote:
On behalf of the sidr co-chairs, this opens a two week wg adoption call for
the draft draft-ymbk-rpki-rtr-keys-01.txt. The wg adoption call will end 18
July 2013.
Please respond to the
Randy,
On May 30, 2013, at 7:46 PM, Randy Bush ra...@psg.com wrote:
The document is intended as Informational but do have requirement
language.
normative language in an info doc is perfectly normal and acceptable.
this doc does not create protcol, protocol data elements, ... it says
Hi George,
Thanks for writing this document, I think it is very good work!
One comment before sending my support email. The document is intended as
Informational but do have requirement language. Is this what you intended?
Personally, I would rather all requirements to be moved to the
Danny,
Thanks for the link. I read the doc.
I do not believe the work has been peer-reviewed and I detected a couple of
bizarre statements (such as deleting an object = revocation or the idea of
overwriting a ROA to replace an existing one).
What I believe it adds to our work are a number of
I support this document and I volunteer review.
I suffered this problem in a previous job.
Also CPS URIs in certificates are common practice. See the Certificate
Policies extension from my personal certificate issued by Verisign where a CPS
pointer qualifier (id-qt-cps) is present:
Thank YOU David for been such a great reviewer.
I will solve the Idnits in my working version waiting for other comments during
IESG review.
Regards,
Roque
On Jan 17, 2013, at 6:38 AM, Black, David david.bl...@emc.com wrote:
The -11 version of this draft resolves all of the concerns raised
the private key
corresponding to CA-X-Certificate-Algorithm- Suite-A and published at CA X's
corresponding publication point.
You will get a new version notification in your inbox.
Roque
On Jan 8, 2013, at 12:02 PM, Roque Gagliano (rogaglia) rogag...@cisco.com
wrote:
Hi David,
I got your
Wrong Reference.
Mikael, have you looked at:
http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19
That could be a starting point to look for missing pieces from an OPS
perspective.
Roque
On Jan 11, 2013, at 11:27 AM, SM s...@resistor.net wrote:
Hi Mikael,
At 23:48 10-01-2013, Mikael
of
Cert-YA. It looks like that's part of the relationship represented by
'|-' and (if so) I would like to see a statement to that effect in
addition to your proposed text about different publication points.
Thanks,
--David
-Original Message-
From: Roque Gagliano (rogaglia
David,
I just published version 10 of the document with all the agreed changes. Thanks
again for your review.
Roque
On Dec 31, 2012, at 8:57 PM, Black, David david.bl...@emc.com wrote:
Steve,
This all looks good; thanks for the quick response.
[*] Section 4.7 changes the meaning of
Dear WG,
This version basically addresses the comments from the Gen-Area Directorate.
Roque
On Jan 7, 2013, at 6:00 PM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Secure Inter-Domain
in a certificate chain.
Subsequent uses of |- seemed clear to me.
Thanks,
--David
-Original Message-
From: Roque Gagliano (rogaglia) [mailto:rogag...@cisco.com]
Sent: Monday, January 07, 2013 12:02 PM
To: Black, David
Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; gen
I want to echo Randy's comment on this paragraph.
i am confident that the folk providing third-party mitigation services
are clever enough to figure out their own hacks around this problem, and
we do not need to second guess what might best work for them.
Lets keep in mind that for origin
Hi Shane,
I always found this presentation very instructive to educate on the practice
you are describing:
http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTIwMCZuYW5vZzQ1nm=nanog45
I agree that this is common practice, particularly between content operators.
Roque
On Oct 24, 2012, at
,
Roque
--Sandy, speaking as regular ol' wg member
From: sidr-boun...@ietf.orgmailto:sidr-boun...@ietf.org
[sidr-boun...@ietf.org] on behalf of Roque Gagliano (rogaglia)
[rogag...@cisco.com]
Sent: Monday, October 22, 2012 9:29 AM
To: sidr@ietf.orgmailto:sidr
Sriram,
Let me re-comment on some of the points.
(skip)
Particularly, I was surprised that in your assessment for the PKR method you
did not considered the points highlighted in section 4.2 of our draft
(Advantages/Disadvantages).
In your Section 4.2, you have proposed what looks
Hi Sriram,
Thanks for the email.
On Oct 21, 2012, at 9:40 PM, Sriram, Kotikalapudi wrote:
Roque,
I took another look at Section 4.2.
Can you please clarify if the method you describe in Sec. 4.2 is purely the
PKR method,
or if it has elements of both PKR and EKR in it?
(Roque) The
Dear WG,
We created a new version of the BGPSEC key roll-over draft that basically
incorporate all corrections/comments from Steve (on:
http://www.ietf.org/mail-archive/web/sidr/current/msg04770.html) and comments
from Sriram here:
Sriram,
One thing that did not went out well in my previous email is that I really
appreciate the time you guys took to look into this issue.
Regards,
Roque
On Oct 18, 2012, at 3:04 PM, Roque Gagliano (rogaglia) wrote:
Sriram,
I read your document and I have a some comments.
1
Hi Group,
Correcting some nits detected by the WG chairs before sending it to the IESG.
Cheers!
Roque
On Oct 19, 2012, at 10:17 AM, internet-dra...@ietf.org
internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a
Hi WG,
This update took care of some nits detected by the WG chairs before heading to
IETF LC.
Roque
From 06 to 07:
1. Added definition for Correspond
2. Added reference of correspondence between suites in phase 2 and 3
3. Small nit on the revocation definition.
Begin
of Murphy,
Sandra [sandra.mur...@sparta.com]
Sent: Thursday, June 28, 2012 4:45 PM
To: Roque Gagliano (rogaglia); sidr@ietf.org
Cc: sidr-cha...@ietf.org
Subject: Re: [sidr] WG Adoption callfor
draft-rogaglia-sidr-bgpsec-rollover-01.txt
There were only two responses to this call
Hi Steve,
Please see inline.
Roque
On Jul 18, 2012, at 5:47 PM, Stephen Kent wrote:
Roque,
Hi Steve,
Thanks for your comments.
I tried to extract the most relevant for discussion on text format.
1) Section 2: RFC 6487 limitation to multiple Repository Publication Points.
Comment: 6487
Hi Steve,
Thanks for your comments.
I tried to extract the most relevant for discussion on text format.
1) Section 2: RFC 6487 limitation to multiple Repository Publication Points.
Comment: 6487 says that, for AIA: In this profile, a single reference to the
publication point of the immediate
...@ietf.org [sidr-boun...@ietf.org] On Behalf Of Sriram,
Kotikalapudi [kotikalapudi.sri...@nist.gov]
Sent: Friday, July 06, 2012 12:23 PM
To: Roque Gagliano (rogaglia); sidr@ietf.org
Cc: sidr-cha...@ietf.org
Subject: Re: [sidr] WG Adoption callfor
draft-rogaglia-sidr-bgpsec-rollover
Dear WG,
This update covers quite some comments received from the WG Chairs review after
the WGLC. The main change is an organization one as we created a specific
section on how to deprecate a suite (Section 10).
We do not have pending issue and we believe it should now move to next step in
Terry,
On Jun 8, 2012, at 2:30 AM, Terry Manderson wrote:
Hey Roque,
On 7/06/12 5:53 PM, Roque Gagliano (rogaglia)
rogag...@cisco.commailto:rogag...@cisco.com wrote:
On Jun 7, 2012, at 7:54 AM, Terry Manderson wrote:
I had the same reaction as you. I looked at the CP document and the Cert
Hi Steve,
The following errata report has been submitted for RFC6487,
A Profile for X.509 PKIX Resource Certificates.
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487eid=3238
i agree. but every time i say AS_PATH someone whacks me with AS4_PATH.
maybe this is why i like the NO_EXPLICIT_PATH :)
well, you are normally consistent at asking people to read the documents :-).
r.
randy
smime.p7s
Description: S/MIME cryptographic signature
Sandra,
I attend the meeting remotely on both Monday and Wednesday. I did not feel the
need for Webex as the audio streaming + jabber worked just fine.
My only comment is to re-emphasize what was mentioned by Wes on the jabber
room, please request including page numbers on presentation decks
Hi Douglas,
On Mar 9, 2012, at 4:10 PM, Montgomery, Douglas wrote:
At least part of my quantum state was there.
If draft-rogaglia-sidr-bgpsec-rollover-00 becomes the way to control stale
updates, the two issues will be intertwined.
I was just pointing out that you need the ability to
Hi Sriram
Thanks for your email.
(snif)
Considering all of the above, I think the following taxonomy would be
preferable:
Origin Signature Expire Time (OSET) method (for what is in the current -01
spec draft), and
Router Re-keying (RR) method (proposed new method).
I am ok with your
Hi WG Chairs,
Could you please help us stating the current status of this document? We
believe the latest version (-05) incorporated all the changes that were agreed
on the list.
Regards,
Roque
Begin forwarded message:
From: Murphy, Sandra sandra.mur...@sparta.com
Date: December 8,
Dear SIDR WG,
We published this -00 draft to document a possible process to perform key
rollovers on a BGPSEC router certificate and discuss the use of rollovers as an
alternative to beaconing.
We are planning to present the proposal in Paris and we welcome comments.
Regards,
Roque
Begin
I support adoption and I am willing to be a reviewer.
Roque.
On Jan 21, 2012, at 1:19 AM, Murphy, Sandra wrote:
The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt
as a working group draft.
The draft is available at
Hi WG,
In this version I incorporated the comments from Danny and some other editorial
nits.
The authors believe all comments form WGLC were answered in the mailing list
and addressed in the document when required.
Regards,
Roque
Diff file can be generated using this URL:
From: Danny McPherson da...@tcb.net
Date: December 23, 2011 6:15:54 AM GMT+01:00
To: sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt
I've reviewed the -04 version of the draft and have the following
comments (most of which persist from the
62 matches
Mail list logo
