As the document shepherd this same phrase struck me a different way so
I let it go forward.
This document is not a panacea, nor is it a deep and
thorough approach to flap reduction.
My understanding is that some authors (researchers and engineers) were
from Japan.
well, gaijin living
that it had escaped unscathed. Of course, from your response as well
as the follow up from Randy Bush, it appears that adequate deliberations
went into the thinking that allowed the sentence to appear.
Given all this, I am fine with moving ahead with the draft.
hey, thanks for the review. so few do
Vijay: Thanks for the review and for raising an issue - I am glad we
discussed it, and with the explanation I too agree that the document
can go ahead. I have balloted a No-Obj for this draft…
more serious than usual bit-drop here due to overload. i cannot find
this review. should i be
more serious than usual bit-drop here due to overload. i cannot find
this review. should i be concerned? any bugs found?
Randy: Please see thread starting at
http://www.ietf.org/mail-archive/web/gen-art/current/msg08982.html
as i seem to have participated in that thread, it is even more
i think i got all LC comments. note that adrian farrel's asking me to
2119 'recommended' conflicted with a private exchange with randall
gellens asking me to 9112 a lot of stuff that was not really mandatory
for interop or op. i eventually sided with randall.
randy
Thanks for your review, Suresh. Randy et al - any comments?
the comments of shuresh and bzzt, no brain changing planes after 13
hour flight about the poor correspondence between -impl and 6810 are
quite correct and embarrassing. fix will require going back to all
implementors. we will do so.
thanks for the review, francis. i will hack as soon as the ads|chairs
say it is time to do so.
randy
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
- 3 3.7 (twice), 3.11 page 4 and 4 4.3 page 6: need - needs
i believe that x need not do y is correct, so will leave it to the
rfced if you will indulge
- 3 3.14 page 4: wording (I had to read the 3.14 multiple times
to understand it)
how about
While the formal validity of a routing
thanks roni. i wonder how i missed your message. my bad.
>> I think the document need an editorial review, a lot of text in
>> passive language, for example
i confess it is my normal mode, despite being a strunk and white fan.
sometimes rfced agrees, sometimes not and fixes. unless it is a
> I think the document need an editorial review, a lot of text in
> passive language, for example third paragraph in section 1
> "BGPsec needs to be spoken only by an AS's eBGP speaking, AKA border,
> routers, and is designed so that it can be used to protect
> announcements which are originated
> I was wondering if there was more scope to make mischief at a distance
> in a less less obvious way than before.
there isn't
but where were you when the blackhole community was passed?
> So you rely on the nodes that receive these community strings to
> interpret them in a common way.
no.
>> 5. Security Considerations
>>
>>Operators should note the recommendations in Section 11 of BGP
>>Operations and Security [RFC7454].
>>
>> SB> You do not address the question of whether there are new
>> SB> considerations, or considerations that are of increased importance?
>
> It is
>> you're supposed to guess
>>
>> the normal hack here is
>>
>>this document introduces no new security issues beyond those discussed
>>in 1997
>
> Guessing is horrible, but if that is what you do, that is what you do,
> and if the risks are the accepted norm in the BGP community I am
thanks for review!
> Title would be more searchworthy if it read "BGP-4 Origin Validation
> Clarifications"
ok. how about "BGP-4 RPKI-Based Origin Validation Clarifications?"
> Abstract: s/\"/./
whoopsie.
will keep new xml in in emacs buffer until all reviews are in
randy
> why the implementation description has to be an RFC? clog up the RFCs
because this is engineering, not academic research; no requirement for
original contribution. having the workings of a protocol implementation
well documented helps others interoperate, gives them ideas for their
own
> I do not see any indication of wide-spread consistency.
the point is that there is widespread use. the page heas pointed out is
what is documented by large ops, the tip of the iceberg. how about stop
speaking for operators?
randy
___
Gen-art
hi joel,
> The secondary problem is that this additional work is justified for
> the router by the claim that the unusual usage of applying community
> tags for geographical location of customers is a common practice. It
> is a legal practice. And I presume it is done somewhere or the
> authors
> Thus, again, you are not making a case for why the existing techniques
> which are easier to implement and deploy are not sufficie3nt for the
> problem.
correct. i, and a couple of other ops, are making the case that
communities are fairly widely used for tagging geo loc at varying
> As far as I can see, this document proposed a new aggregation
> parameter for IPFIX. So that the operators can get the traffic
> statistic from a new dimension.
>
> Because "Flow information based on IP address or IP prefix may provide
> much too fine granularity for a large network. On the
> Let me try to explain it clearly in simple words again. BGP community
> attributes, such as standard community, extended community, large
> community, have already been defined by IDR working group. Operaters
> use those already defined BGP communities in their field networks with
> their own
> In both the Abstract and the 2nd paragraph of the Introduction,
> it might be helpful to add something like:
> This document recommends specific action items to limit future
> inconsistency.
thanks. done but not (yet) published.
randy
___
> In my opinion, this document adds new requirements or at least new
> considerations for implementations of RFC1997, I think that means it
> updates RFC1997. I liked to see it have "Updates: 1997" metadata added and
> appropriate statements in the Abstract and Intro. I think this requires and
>
paul,
thanks for the review. appreciated.
> The Abstract and Introduction are written in the abstract, implying
> (to me) that the requirements here are intended to be broadly
> applicable for the stated purposes, over an extended period of
> time. On the other hand, I get the impression that
>>> 2) NIT:
>>>
>>> Reading the last two security considerations in section 8 leaves me
>>> concerned. I was expecting to see some further discussion of how these
>>> issues can be mitigated, or why it is OK that they are not.
>>
>> i am not sure if there are mitigations.
>>
>> i believe that
ut to the ebgp peer) as opposed to
> "my autonomous system number" in the open message.
>
> Regards, Keyur
>
> On 3/17/20, 8:27 PM, "Randy Bush" wrote:
>
>> I wanted to avoid "be able to be" and have an explicit actor. I see
>> the difficulty yo
thanks for review robert,
> This sentence slowed me down when reading:
>
>As the origin AS may be modified by outbound policy, policy semantics
>based on RPKI Origin Validation state MUST be able to be applied
>separately on distribution into BGP and on egress.
>
> I suggest
> I wanted to avoid "be able to be" and have an explicit actor. I see
> the difficulty you point to below.
i am happy to change to the following
>> As the origin AS may be modified by outbound policy, a BGP speaker
>> MUST apply ROV policy semantics using the My Autonomous System number
>> in
> I like that and hope it's acceptable to the community.
>
> But it was a very small nit - if it turns out to be problematic, I'm
> ok leaving things as they were.
our illustrious AD is fond of specific references to RFCs and other
formal wording. :)
randy
>As the origin AS of a BGP UPDATE is decided by configuration and
>outbound policy of the BGP speaker, a validating BGP speaker MUST
>apply Route Origin Validation policy semantics (see [RFC6811] Sec 2)
>against the origin Autonomous System number which will actually be
>put in
> Although a little more verbose, perhaps the following is more explicit?
>
> As the origin AS of a BGP UPDATE is decided by configuration and
> outbound policy of the BGP speaker, a validating BGP speaker MUST
> apply Route Origin Validation policy semantics Against the Route
>
> Having spend the better part of last week stepping a vendor through
> exactly these semantics
while there is no proof of termination of clue insertion, that a BGP/ROV
*implementor* did not get it, justifies the hack.
As the origin AS of a BGP UPDATE is decided by configuration and
hi paul:
thanks for the review.
> 1) Minor: Definition of "remarks: Geofeed"
>
> Section 3 says:
>
>... The format of the inetnum: geofeed
>attribute MUST be as in this example, "remarks: Geofeed" followed by
>a URL ...
>
> From the examples and common sense there should be a
mornin' paul,
>>> Also, is the word "Geofeed" case sensitive?
>>
>> "MUST be as in this example." do we need ABNF the ex compiler hacker
>> asks? i can add enough syntactic sugar to give you a diabetic coma :)
>
> I don't think you need abnf. But some text specifying it is/isn't case
>
paul,
i believe it was you who was wondering about the ops community process
and progress getting this draft implemented. as part of the RIPE
process, the RIPE/NCC, who has to actually implement this stuff, issues
an impact report. i thought it might be informative.
randy
From: Edward Shryane
> I think the editorial suggestions below make sense and hope the
> authors will consider them.
they were, mostly in -06 and one still in an emacs buffer due to a
mistake on my part.
randy
___
Gen-art mailing list
Gen-art@ietf.org
> ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)
> ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
> ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608)
>
> The first is covered by an explanation in the text of the draft, but the other
>
>> Nits fulls up three errors:
>>
>> ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)
>> ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
>> ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608)
the first remains, with explanation
the last two
> Q1: There are a few places where the document says "Currently". I'd
> prefer to instead say something like "At the time of publishing this
> document". I do realize this issue already exists in RFC 9092.
sure. thanks.
randy
___
Gen-art mailing list
38 matches
Mail list logo
