Hi Jeff,
On 19/03/2008, at 12:47 AM, Jeffrey Haas wrote:
Terry,
On Sat, Mar 15, 2008 at 06:13:32AM +1000, Terry Manderson wrote:
I'm not going to go back through the process of discussing the merits
and downfalls of RSYNC or any other competing protocol or service
that
might be used
Hi Danny,
There are several motivations for an additional / alternative
mechanism for retrieval as I see it. We know that RSYNC is a MUST in
the SIA of the issued RPKI certificate, and it then allows further
multiple additional fetch URIs where order of those URIs is the
preferred
On 12/08/2008, at 11:58 PM, Sandra Murphy wrote:
A social aspect that I'm cognisant of is that there appeared to be
reluctance by some parties to accept the rescerts draft because it
had a non-ietf reference implementation which potentially could
raise issues about interoperability
Hi Roque,
On 26/08/2008, at 12:37 AM, Roque Gagliano wrote:
I wanted to ask you about this line:
- --
4.1.1
e. Confirm that all of the objects listed in the downloaded manifest
have been retrieved.
- --
What if I have a partial download of the URIs from
All,
I have created a new version of the draft presented and discussed in
Dublin.
http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt
This version, while still noted as 00 (*), has:
- https mandated for full end to end integrity of fetching objects
- updated for RFC5280
-
Hi Randy,
On 06/10/2008, at 10:54 PM, Randy Bush wrote:
While sometimes I enjoy reading pointed rhetoric dismissing everyone
else's view of the world, I'll skip it for today thanks.
and surely we can find better ways to amuse ourselves by complicating
things. like how about we propose a
Hi Rob,
On 19/10/2008, at 5:22 AM, Rob Austein wrote:
I'd also question the purpose of TLS (ie, HTTPS vs HTTP) in this
context. All the data are signed, there's no confidentiality or
access control reuirement as far as I know, and the manifest design
was specifically intended to remove the
On 21/10/2008, at 8:09 AM, Rob Austein wrote:
You appear to be describing a selective DoS attack by an on-path
attacker. Unless I'm missing something, adding TLS to the mix here
changes details but doesn't change the overall situation much, as:
a) The attack was already detectable without
On 20/10/2008, at 8:22 PM, Andy Newton wrote:
Hmmm... This couldn't be too hard to test, now could it. Using curl
or
Apache libraries should be easy. If somebody could throw out what
they
consider to be a good size for the number of files in the repository
and
file size ranges, I'll
Hi Randy,
On 12/11/2008, at 10:40 AM, Randy Bush wrote:
the security model of the boa is seriously flawed. it mixes a
negative
model with the existing positive one. this will vastly complicate
things and to little utility.
As I see it the BOA draft introduces and allows for the
On 26/11/2008, at 4:22 PM, Randy Bush wrote:
Knowing that ROA's can only be issued based on the AS and IP
resources
allocated by the parent.
whoops! no. the asn in the roa is not signed or otherwise
authorized.
..sigh.. I'm _sure_ I read in one of the many documents that an ASN
On 26/11/2008, at 3:28 PM, Terry Manderson wrote:
The issue I see with either a AS0 or private AS use is that it
isn't allocated in the resource allocation hierarchy, unless all
RIRs are issued with AS0 and AS64512 through to AS65535 by IANA, and
then the RIRs subsequently simultaneously
After a read through of the draft, I have some points to raise.
Section 1, Last paragraph
locally manage trust anchors in a fashion that preserves the
resource subset constraints imposed by the use the RFC 3779 extensions.
I think you mean
locally manage trust anchors in a
On 12/03/2009, at 11:27 AM, Robert Loomans wrote:
... where resources are listed in the 3779 attributes following the
paradigm that no two TA organisations can be authoritative for the
same information? (in that model)
I'm not sure that's a valid assumption. I believe that this would
On 12/03/2009, at 2:27 PM, Rob Austein wrote:
At Thu, 12 Mar 2009 11:49:53 +1000, Terry Manderson wrote:
I don't remember seeing the a make-before-break issue raised in any
draft, can you point me to a reference?
May not have gotten into any draft, but keeping routing live has
certainly
Sriram,
On 13/03/2009, at 2:45 AM, K. Sriram wrote:
I am curious as to what happens if MomAndPopISP's address space has
a ROA in region B
created by a higher-tier ISP, say BigISP, in region B.
That means, most likely, that the resources listed in the ROA are
allocated to BigISP and I
I support draft-ietf-sidr-ta-00 becoming a work group item.
Terry
On 26/03/2009, at 12:32 PM, Sandra Murphy wrote:
There were objections yesterday in the sidr meeting to the way that
draft-ietf-sidr-ta-00.txt became a wg draft.
draft-ietf-sidr-ta-00.txt was an extract of an important topic
All,
In the WG meeting, if I heard correctly, it was stated that there
needs to be a consistent reference for how to interpret ROAs with
examples so that we are consistent in discussion and help newcomers
grok this rpki space.
I have started cutting some words in this space, however
On 28/03/2009, at 6:52 AM, Sandra Murphy wrote:
Terry, did you see my message to the list about Russ White's
volunteering to try to assemble use cases? He said that anyone
wanting to help should email him.
No I didn't.. But it is clearly in the archives.. But my maillogs
imply i
Hi Heather,
On 14/04/2009, at 1:14 AM, Heather Schiller wrote:
We already identify our customers to others publicly today with
SWIP... most RIR's require SWIP/RWHOIS when you assigned/allocate a
netblock over a particular size. Not sure I understand why an ISP
that is already required
Hi All,
In IETF 74 a call was made to the SIDR-WG to define the organisational use
cases that would precipitate use of the RPKI certificates and objects in a
routing sense.
Shortly after, a small group of interested individuals began proposing text
and discussing approaches. This culminated in
On 31/07/09 7:55 PM, Geoff Huston g...@apnic.net wrote:
thanks Rob.
I believe that we agree - My phrase more specific than the set of
prefixes specified in the ROA is intended to mean a prefix whose
length is greater than maxlen (i.e. more specific than what is
specified by the
I support and able to review.
Terry
On 31/07/09 11:30 PM, Sandra Murphy sa...@sparta.com wrote:
I am opening a two week call for comments on this request for working
group adoption of draft-huston-sidr-rpki-algs-00.txt.
The draft is available at
On 1/08/09 8:36 AM, Geoff Huston g...@apnic.net wrote:
ends?
perhaps an example may help here
A ROA is issued for 203.0.113.0/24, maxlength 25, oroginating AS 65534
using only this ROA, and nothing else, the revised draft would
generate the following outcomes:
203.0.113.0/24,
Hi Pradosh,
On 4/08/09 7:14 AM, Pradosh Mohapatra (pmohapat) pmoha...@cisco.com
wrote:
The customers do not have to participate in the RPKI. The LIR can issue the
Not LIR can, LIR MUST.
That is where I have the issue, the interpretation then drives that the LIR
or LIR customer have no
On 4/08/09 7:25 AM, Rob Austein s...@isc.org wrote:
At Sun, 2 Aug 2009 19:56:08 -0700, Terry Manderson wrote:
Kindly tone down the rhetoric.
Apologies if you were offended.
A ROA that has an implicit deny creates a major break scenario since
the RPKI system will be in partial
On 4/08/09 7:14 AM, Pradosh Mohapatra (pmohapat) pmoha...@cisco.com
wrote:
issued. Else they become INVALID in the validation logic. I do not see how
BOAs solve the make-before-break problem though. The moment they become
separate instances (RPKI objects vs. prefix announcements in BGP), they
On 05/08/2009, at 11:31 AM, Geoff Huston wrote:
WG Chair hat OFF
On 05/08/2009, at 11:04 AM, Stephen Kent wrote:
I still believe that the ability to make negative assertions seems
like an important feature for incremental deployment of the RPKI.
My proposal makes use of ROAs with an AS#
Hi Steve,
On 6/08/09 11:33 AM, Stephen Kent k...@bbn.com wrote:
Terry,
- As the creator of ROas I don't share the view that using an
AS # of 0 is overloading the semantics :-).
agree to disagree? :-)
- I agree that this proposal does not allow one to express a
On 8/08/09 1:47 PM, Randy Bush ra...@psg.com wrote:
No, the LIR just has to issue ROAs for any of its customers that are
Not just has to, MUST issue.
big deal. and we must connect wires to them. the list of musts to
provision a customer is rather large. this one will go with the ones
I second that motion!
Terry
On 11/09/09 10:45 AM, George Michaelson g...@apnic.net wrote:
Dear Working group chairs.
Please can we move to using the ietf tools issue tracker on the
working group drafts.
I think this would help by clearly identifying issues.
-George
Hi John,
While I appreciate the work by Steve here to allow a relying party to
put on the rose coloured validation glasses, it is an inside view
looking out. That means is allows an organisation to locally say what
it believes is the RPKI view of the world irrespective of what is said
Hi Steve,
On 15/09/2009, at 11:03 AM, Stephen Kent wrote:
Terry,
I think you misunderstand the nature of trust anchors in PKIs. No
entity can force all relying parties adopt the entity as a TA,
period. The acceptance of a TA is always a local matter, if the
software is properly
Hi Steve,
On 17/09/2009, at 1:53 AM, Stephen Kent wrote:
In the local TA management scheme I described, an RP gets to specify
the set of resources it believes is associated with a given key
(cert). The software enables an RP to assert what it knows to be
true, overriding what the
knows
Sandy and David,
On 18/09/2009, at 5:25 AM, Sandra Murphy wrote:
On Thu, 17 Sep 2009, David Conrad wrote:
Sandy,
On Sep 17, 2009, at 5:59 AM, Sandra Murphy wrote:
I recognize that there is an fear that this system somehow puts
ISPs under someone's control. I would answer that there is
Chairs,
apologies for nagging, but this really is a good idea.
Can this be implemented?
Cheers
Terry
On 11/09/09 10:50 AM, Terry Manderson terry.mander...@icann.org wrote:
I second that motion!
Terry
On 11/09/09 10:45 AM, George Michaelson g...@apnic.net wrote:
Dear Working group
Hi Robert,
On 8/10/09 2:47 AM, Robert Kisteleki rob...@ripe.net wrote:
[..]
so two organisations, at some point in time, will have the ability to
issue valid and conflicting statements.
They have that ability today, it is being used and it's useful. Would you
want to take that ability
On 8/10/09 3:13 AM, Danny McPherson da...@tcb.net wrote:
On Oct 7, 2009, at 10:47 AM, Robert Kisteleki wrote:
Suppose you're ISP1, and want to sell some part of your clients to
ISP2 (this happens: mergers, splits, you name it). In other words,
you want to transfer a live, routed and
On 8/10/09 11:14 AM, Danny McPherson da...@tcb.net wrote:
But what decision should the relying party make? in other words how
does the
relying party know that collision was intentional?
I'd think it wouldn't matter with the RP, if the ROAs
are there then accept those prefixes from
Hi Sam,
On 24/10/09 4:58 AM, Samuel Weiler wei...@watson.org wrote:
On Mon, 15 Jun 2009, Terry Manderson wrote:
For the RPKI, sections 3 and 5 are useful. I have basically ignored
section 4.
On to the specifics:
Observation: Most of the Section 3 cases speak about which routes
Oppose.
Although opposition is based on a small number of nits:
* Section 1.7, page 11. RPKI signed Object ... declared to be such by a
standards track RFC issued by the SIDR WG
Over time, the SIDR WG may not exist, or the name could change, or valid
RPKI objects come from other WG's. Perhaps
I support this document going forward.
the only comment I have is that I'd prefer to see a preference order in
validation (section 3) to help relying party S/W writers to make efficient
choices in the validation path - but that isn't a stopping block for me.
Cheers
Terry
On 28/10/09 12:48 PM,
Oppose.
the following, I think, needs attention.
* Section 4.3 Access Protocols
Current efforts to implement a repository system use RSYNC [14] as
the single access protocol. RSYNC, as used in this implementation,
provides all of the above functionality. A document specifying the
I support this document going forward..
Ideally I would like the draft to handle corruption avoidance instead of
just corruption detection (section 6: security section), But I think that
might be better dealt elsewhere than in the structure of the repo.
Terry
On 28/10/09 3:05 PM, Sandra Murphy
Chairs,
The authors of draft-manderson-sidr-usecases-01.txt would like to request
that this ID be adopted as a WG item.
We acknowledge that there is a lot of work yet to be done on this document
however we believe that the areas to be completed should come at the
direction of the work group
I feel unable to say either way at present.
The IPR disclosure at https://datatracker.ietf.org/ipr/1028/
highlights the US Patent Application Serial No. 12/243,767.
In searching for this, at the USPTO I cannot find any relevant documents
with that serial.
I did try searching for Cisco as the
Matt,
I think this is sensible.
Terry
On 6/11/09 6:08 AM, Matt Lepinski mlepin...@bbn.com wrote:
Note that since relying parties will perform these operations
regularly, it is more efficient for the relying party to request from
the repository system only those objects that have
Byron,
On 30/11/09 9:45 AM, Byron Ellacott b...@apnic.net wrote:
[..]
lastly, the draft suggests the server MUST NOT accept a client's request
unless it has generated and sent a response to the client's previous
request - it appeard the _assumption_ made is that the client deals with
the
On 27/04/10 12:24 PM, Rob Austein s...@isc.org wrote:
I'm writing to propose that we remove all use and mention of TLS from
the RPKI up-down protocol described in the (expired) draft
draft-ietf-sidr-rescerts-provisioning.
I second this given my observations from October last year
On 12/05/10 8:45 PM, internet-dra...@ietf.org internet-dra...@ietf.org
wrote:
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-ta-04.txt
I have a question not specifically targeted at the content of the ID, but
related to it.
Are there any software
Support adoption and willing to review.
No substantive concerns just yet..
Cheers
Terry
On 13/05/10 7:23 AM, Sandra Murphy sandra.mur...@sparta.com wrote:
Randy Bush has requested that the working group adopt the draft
draft-ymbk-rpki-rtr-protocol-05.txt as a work item.
It is available
I support adoption, and am happy to review.
Cheers
Terry
On 19/05/10 8:38 AM, Sandra Murphy sandra.mur...@sparta.com wrote:
Steve Kent's presentation at IETF 77 requested that the working group
adopt the draft Local Trust Anchor Management for the Resource Public Key
Infrastructure as a
Folks,
Sorry, had weekend away from the keyboard.
On 22/05/10 12:46 AM, Pradosh Mohapatra pmoha...@cisco.com wrote:
Hi Terry, Robert,
I agree with Terry on this one. I'd personally be much happier with
verified/unverified instead of valid/invalid. These terms are much closer to
what we
On 24/05/10 11:40 AM, Robert Loomans robe...@apnic.net wrote:
Refuted definitely has the right connotations.
I'm not fond of unverified... if unknown is not acceptable,
perhaps undetermined is a good term.
I can live with unknown.
I still have reservations about using different terms
I support the use of this alternative format.
Cheers
Terry
On 25/08/10 6:25 PM, Sandra Murphy sandra.mur...@sparta.com wrote:
Forgot to add the obligatory coda:
On Wed, 25 Aug 2010, Sandra Murphy wrote:
Draft draft-weiler-sidr-trust-anchor-format-00.txt suggests an alternate
trust
Hi Steve
On 8/09/10 8:25 AM, Stephen Kent k...@bbn.com wrote:
Folks,
At the IETF meeting in Maastricht I mentioned that we might need to
augment the repository structure doc (that I briefed on Geoff's
behalf) with some sort of lock capability. My concern is that if RP
softwre visits a
Hi Sandy,
On 29/10/10 1:53 AM, Sandra Murphy sandra.mur...@sparta.com wrote:
I came across a couple of special address space cases recently.
There are some special addresses that are reserved by/to IANA. We've
discussed a few of the more well known, e.g. the private address space
(10/8,
I support the last call of the following WG documents. (Insomnia well and
truly cured.)
draft-ietf-sidr-roa-format-09
draft-ietf-sidr-rpki-rtr-02
draft-ietf-sidr-keyroll-04
draft-ietf-sidr-res-certs-20
draft-ietf-sidr-repos-struct-06
draft-ietf-sidr-rescerts-provisioning-09
... so Chris is moving faster than I am :)
I'll have the public -00 uploaded in a few minutes.
Cheers
Terry
On 4/02/11 12:32 PM, Christopher Morrow christopher.mor...@gmail.com
wrote:
Oh, actually I'm confused, the timeline on the doc is the same, only
this is advice to IANA about what kind
-00 indv. draft available at
http://www.ietf.org/id/draft-manderson-iana-objects-00.txt
..T
On 4/02/11 12:37 PM, Terry Manderson terry.mander...@icann.org wrote:
... so Chris is moving faster than I am :)
I'll have the public -00 uploaded in a few minutes.
Cheers
Terry
On 4/02/11
open item, would you be ok if I made the changes prior
to IESG submission instead of cutting another revision.
Cheers
Terry
spt
On 2/10/11 6:30 PM, Terry Manderson wrote:
with author hat stylishly tilted to one side.
The doc can be found at:
http://tools.ietf.org/html/draft-ietf-sidr
Rev'd at the WG Co-Chair's request. Contains agreed fixes during last call
so that the chairs can progress shepherding using IETF tools.
Cheers
Terry
On 16/02/11 1:45 PM, internet-dra...@ietf.org internet-dra...@ietf.org
wrote:
A New Internet-Draft is available from the on-line
I think this item should be WG document and I am willing to review and
contribute.
Cheers,
Terry
On 19/04/2011, at 9:29 PM, Sandra Murphy sandra.mur...@sparta.com wrote:
The working group has been requested to adopt
draft-lepinski-bgpsec-overview-00 as a working group draft, to satisfy the
I think this item should be WG document and I am willing to review and
contribute.
Cheers,
Terry
On 19/04/2011, at 9:30 PM, Sandra Murphy sandra.mur...@sparta.com wrote:
The working group has been requested to adopt
draft-lepinski-bgpsec-protocol-00 as a working group draft, to satisfy the
I think this item should be WG document and I am willing to review and
contribute.
Cheers,
Terry
On 19/04/2011, at 9:31 PM, Sandra Murphy sandra.mur...@sparta.com wrote:
The working group has been requested to adopt draft-ymbk-bgpsec-ops-01 as
a working group draft, to satisfy the following
On 26/04/11 12:55 PM, Randy Bush ra...@psg.com wrote:
how about the following in draft-ymbk-bgpsec-ops?
As a router must evaluate certificates and ROAs which are time
dependent, routers' clocks MUST be correct to a tolerance of
approximately an hour.
So what you are allowing
Hi Sandy,
Wearing just the iana-objects author hat.
It would require a small amount of editing, which in turn will ultimately
result in the prefixes (as termed 'deprecated') being considered unallocated
- and therefore an AS0-ROA SHOULD (eventually) be issued for 2002::/16 and
192.88.99.0/24.
) : Terry Manderson
Richard L. Barnes
Matt Lepinski
Filename: draft-manderson-sidr-geo-01.txt
Pages : 16
Date: 2011-06-09
This document describes the construction and use
.
Title : Use Cases and Interpretation of RPKI Objects for
Issuers and Relying Parties
Author(s) : Terry Manderson
Kotikalapudi Sriram
Russ White
Filename: draft-ietf-sidr-usecases-02.txt
Have read -06 and I think (generally) it is fine to progress with a tiny
personal nit.
I did wonder as I was reading the document if the object is optional or
mandatory in the repository structure? For example if I create a ROA, MUST I
create a Ghostbusters record. I can certainly see that for
On 18/07/11 11:29 AM, Geoff Huston g...@apnic.net wrote:
On 18/07/2011, at 9:42 AM, Terry Manderson wrote:
This actually makes me wonder why the manifest (
draft-ietf-sidr-rpki-manifests) in:
FileAndHash ::= SEQUENCE {
fileIA5String,
hashBIT
On 18/07/11 12:32 PM, Stephen Kent k...@bbn.com wrote:
But wouldn't the CMS (and ASN.1 for that matter) effectively tell
the RP what the object was intended to be? It strikes me that the
file name extension is a bit of syntactic sugar rather than an
essential and necessary component, so I'm
On 18/07/11 12:42 PM, Stephen Kent k...@bbn.com wrote:
At 4:42 PM -0700 7/17/11, Terry Manderson wrote:
the filename extension, which is part of the file data type above,
conveys the needed info. yes, one could add an OID here, but
ultimately an RP will check the syntax and know which file
On 18/07/11 9:39 PM, Tim Bruijnzeels t...@ripe.net wrote:
Hi,
I agree that not having this mapping is tedious and error prone for RPs.
I can agree that a mapping system is useful. It may just be that living unix
world for far too long has seen me move away from the mandatory dos-like
On 19/07/11 2:23 PM, Randy Bush ra...@psg.com wrote:
And I'm happy to see it written as a hint. A validated mapping should
come, in my opinion from something more robust which also transcends
the technology used in the repository.
easy. throw away the entire structure and code to date and
On 19/07/11 9:15 PM, Randy Bush ra...@psg.com wrote:
I think there is an easier way, as already suggested. Add the object
type to the manifest in FileandHash.
1) the rescert points to the publication point and manifest
2) the manifest is mandatory
3) the manifest is signed
4) the
On 19/07/11 11:59 PM, Rob Austein s...@isc.org wrote:
What threat? Please describe it.
The only threat I saw discussed is, in my opinion, a non-issue: an
attacker can mangle filenames in the unprotected data stream, thus
causing objects to fail validation. An attacker who can do that
A process reminder here. Several other documents point to the
repos-struct draft, some of them specifically regarding the file
extensions. Separating out the tagging into a separate document could
mean some serious review of multiple documents.
I think the question might be if the
On 20/07/11 1:02 AM, Sandra Murphy sandra.mur...@sparta.com wrote:
There was a brief discussion of the use of file names extensions when the
repos-struct document came up for last call. See the following messages:
http://www.ietf.org/mail-archive/web/sidr/current/msg02281.html
Hi John,
Thanks for taking the time to review the draft and post your thoughts.
On 20/07/11 7:00 AM, John Kristoff j...@cymru.com wrote:
1) Use cases? who wants this.
I'll assume that you're looking for more use cases beyond those you had
envisioned when deciding to write it up.
All,
So it seems that the RPKI repository as it stands has the notion of a
mandatory entry in the resource certificate pointing to a manifest.
The existence of the manifest is intended, but doesn't seem to be mandated,
that is the absence of a manifest is left to the relying party make a
Steve,
On 21/07/11 3:22 AM, Stephen Kent k...@bbn.com wrote:
Terry,
The repository document mandates that each CA
issue a manifest and maintain it in an up-to-date
fashion; that's pretty clear. For example, 4.2.1
says If the authority alters any of the items
that it has published in
On 21/07/11 12:42 PM, Randy Bush ra...@psg.com wrote:
I would prefer, given the identified case, that where a situation
exists that a manifest is is non-existent or discarded that the entire
publication point MUST be considered suspicious and not used for
validation of operational objects.
On 21/07/11 2:15 AM, Rob Austein s...@isc.org wrote:
At Tue, 19 Jul 2011 14:03:18 -0700, Terry Manderson wrote:
Rob's observation that the extension exists in the manifest file name is a
close approximation provided words exist as highlighted which gives clear
instruction to implementers
Provided of course that you have a valid GB object since without a
manifest a simple `cp 1.gbr 1.cer` will fail to validate under
oops that should have been `mv 1.gbr 1.cer`.
the assumption you make the validation selection regime based on
filename extension
this is so
Hi Andrew,
On 22/07/11 5:00 AM, Andrew Chi a...@bbn.com wrote:
On 7/20/2011 11:24 PM, Terry Manderson wrote:
The problem is Randy, that this PKI requires full and complete distribution
through a sane repository system. Failure to have a full and complete
repository WILL lead to unintended
Hi Andrew,
Therefore, the BBN validator does the only thing sensible, which is
validate based on filename and certificate chain. After that, we check
against the manifest and emit a warning if it doesn't look right. And
we provide the user with configuration flags to control the output
'good enough to progress' and ask for WGLC??
-Chris
On Wed, Jun 22, 2011 at 5:14 AM, Terry Manderson
terry.mander...@icann.org wrote:
The second ROA (ROA 2) below would of course be address 10.1.0.0/20
maxlength 20.
Apologies for the cut/paste error.
Cheers
Terry
On 22/06/2011, at 11:37
Some comments.
Section 4.3. Phase 0
I'm still struggling to see the necessity to put in the operational dates
for a Alg shift in [I-D.ietf-sidr-rpki-algs]. I concur that the future Alg
suite and to be EOL's suite should be identified once suitable candidates
have been selected in rpki-algs. But
On 31/10/11 8:57 PM, Stephen Kent k...@bbn.com wrote:
At 7:18 PM -0700 10/30/11, Terry Manderson wrote:
We have included dates for alg start an EOL because they affect all
RPs, and we want to make life predictable for RPs. Also, because the
WG agreed that alg transition will be top-down
On 22/11/2011, at 3:13 PM, Christopher Morrow wrote:
'if it is intended' ... means:
a) is intended to be seen at the vantage point it was observed at
(3 as-hops away)
b) with the as-path it shows up with (isp1 - as1 - isp2 - me)
c) something else?
it's not clear what you meant, I'll
and on 8 Sep, Terry
(http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html) replied:
From time to time authors choose to use non rfc5737 address blocks as the
examples can't often be adequately described or remain uniform with the
documentation prefixes.
I was suggesting
Monday is my preference. Friday clashes with other work.
Cheers
Terry
On 20/03/12 7:58 AM, Murphy, Sandra sandra.mur...@sparta.com wrote:
One important point.
The routing AD needs to know the decision by COB UTC time on Tuesday
(tomorrow).
So replies are needed quickly.
--Sandy
On 23/03/12 4:43 AM, Eric Osterweil eosterw...@verisign.com wrote:
Comments?
This is a large amount of travel and I think it unduly reduces the ability of
many of the wg's members to participate at the same level as they do today. I
think this is a bad idea.
I predict travel related
Hi Chris,
On 23/03/12 11:05 AM, Christopher Morrow morrowc.li...@gmail.com wrote:
significant progress has been made on the topics here because of
frequent (monthly about) face-to-face meetings, focused meetings even.
Wow.. that is news to me. Are those meetings under the guise of something
Jeff,
On 28/03/12 6:19 PM, Jeffrey Haas jh...@pfrc.org wrote:
Per my mic comment at IETF 83:
During the San Diego interim session we had discussed potentially signaling
in BGP the idea that a given AS may have fresher data available in its
repository.
My original thought had been
These are my comments on the draft draft-ietf-sidr-rpsl-sig-05
In the Introduction (Para 3) it says:
A maintainer of such signed database objects MUST possess a relevant
resource certificate which shows him/her as the legitimate holder of an
Internet number resource
I'm afraid I'm confused on
Hi Randy,
I'm presuming that there are cases that prompt you to write this draft as
BCP. Are you able to elaborate on why (using the nomenclature from your
example) A wouldn't re-issue the rpki certificate to C to be
10.42.0.0/23,10.42.4.0/22,10.42.8.0/21,10.42.16.0/20,10.42.32.0/19,10.42.64
Hey Roque,
On 7/06/12 5:53 PM, Roque Gagliano (rogaglia) 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.
Profile. The best reference to this use-case is the second paragraph
Hi Roque,
On 8/06/12 11:10 PM, Roque Gagliano (rogaglia) rogag...@cisco.com wrote:
This is more a question for Randy.
IMHO, his text says both:
A may certify G's resources, or issue one or more EE certificates and ROAs
for G's resources. Which is done is a local matter between A and G.
1 - 100 of 131 matches
Mail list logo
