Over the past year or so there's been an increase in
the number of people responding to working group last
calls with I support as a co-author. This is a
request to stop.
thank you
___
OPSAWG mailing list
OPSAWG@ietf.org
I would need a bit more clarity on what is per circuit. The
mechanism works by looking at the utilization on individual component
links within a LAG/ECMP. The port-level queues and packet/byte
counters are always visible to an implementation.
for some definitions of 'always'. a few of us
warren and any other friendly opsawg chairs:
i have been told that you are actually wasting air time discussing snmp
write for configuration of devices. i thought we had and finished that
discussion over a decade ago at ietf 51 in london. we were in a large
room with many operators, and i asked
i read it and it's ok. i need it and will use it.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
The I-D reports results from a survey. It is not a technical
specification that a working group can work on.
My recommendation would be to change the title to be more specific
that this document is a survey report and then to submit this document
as an individual submission to the RFC
> We use SHA and AES with snmp v3. Given the general pressue other parts
> of the business to carefully track and generally improve which crypto
> suites are used we would probably move there if the hardware supported
> it (I don't think getting it done in the NMS would really be that
> hard).
> I have *major* problems with the document as an IETF standard. We
> already have two AAA IETF protocols. Standardizing a third one is, in
> my opinion, entirely outside of the purview of OPSAWG.
after all, it's the one we actually use. so it has to be killed asap.
randy
> Should the ID, as presented, or as revised by the WG, be published as one
> or more RFCs?
tacacs+ as we know and use it today should be ps today
future work good and should be encouraged.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
> If the answer to the previous question is yes, should the RFC
> describing the protocol itself (as opposed to any other document that
> might describe appropriate use) be published as a standards track RFC?
it is a deployed and widely used protocol. this question is silly. of
course it should
>> One thing to keep in mind is that, if the document describing the
>> currently deployed protocol is informational, we may have a tricky time
>> making the extensions be standards track; it would (presumably) require
>> a downref.
>
> it would; it is not logically a huge problem, merely wierd.
> Occasionally I wonder if "this problem" is the hill I'm going to
> choose to die on...
sorry you have decided to die. you'll be missed
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
http://shrubbery.net/tac_plus/
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> I think in order for WG consensus to determine decisions wrt/ this
> document, it would no longer be a Cisco protocol. Cisco would have to
> give all change control authority to the IETF.
andy, you have been around for a while. where did you get the idea it
was otherwise in the case of this
does this wg have a chair?
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
the paragraph i deleted before sending was
[ i do have sympathy for the motivation. heck, nick duffield suckered
me in the days when at had a research lab, but veered left into
trajectory sampling and the psamp stuff. ]
i missed your stuff; apologies. a cite would be good.
i do see
petr,
> You are right, the primary use case is data-center network, with its
> specific devices: e.g. multiple shared-memory-buffer chips connected
> in Clos topology. The typical MTU I've seen so far there is still
> 1500, even though enabling jumbo framing is generally not a problem.
> However,
>>> Nobody is saying one is better than the other.
>>> I am saying the IETF does standards.
>> and running code
> that's what the t-shirt says, but I have never seen "running code" in
> a WG charter.
an ops wg might be a good place to start. but we've kinda been beaten
to the punch.
the idr wg,
> Nobody is saying one is better than the other.
> I am saying the IETF does standards.
and running code
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Hi Randy, today, at IETF96 in Berlin, we discussed this document in
> the OPSAWG meeting.
> We would be interested to hear your opinion (from an operator point of
> view) on this document. It is a short document. Hearing if you think
> this makes sense or not would be great.
> You can send you
> But do we want to change it all at this time?
yes. a proper sec cons does not change the protocol but advises as to
its use.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Thanks for your reply. I want to clarify that I am not
> suggesting users to use IPsec.
>
> In the draft, the tunnels between the WTP and AR need to be
> protected, so the IPsec is between the WTP and AR.
>
> The network provide is responsible for the security of the
> users, and should deploy
> I would lluike to attend this session.
will you be in s'pore or do you need help with remote participation?
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
>> Unfortunately, the fundamental concern that motivated my DISCUSS
>> remains: I do not believe that this document matches the consensus
>> of the IETF community.
> That's an interesting claim.
> If the process has not been followed, this requires facts as opposed
> to "believes".
> We should
> If the IETF as a community objected to the content of this draft,
> presumably there would ahve been significant dissent during the IETF
> last call.
my memory is that i commented once, supporting christian's eloquence
during ietf last call. i commented yesterday supporting ekr's
statement.
robin,
> It is not described clearly in the draft that reusing BMP is also a
> possible option for monitoring IGP. We will refine the draft.
if i could also use bmp for monitoring dns, smtp, and ntp, i could
stop using nagios!
i think what acee is trying to say is that "B" in BMP does not
> But I guess we all agree that this is not the best use of BGP protocol to
> be now a vehicle of NMS only because it is easy with BGP to establish a TCP
> session and to distribute "stuff" in a relatively loop free fashion.
now that dns over tcp/tls is being deployed, we can return to the other
robin,
i am not ignoring you. i did not want to write unless i had something
possibly useful to say; and that requires pretending to think, always
difficult.
> I would also like to propose following draft for your reference which
> trigger us to move forward for better network maintenance with
as one of the many folk who have been using this protocol since the
'90s, i gotta wonder how many angels we can sit on the head of this
bikeshed.
i do not think we are gonna 'fix' the security model. this is a widely
deployed antique we are just trying to document so new victims can
> I think the current proposals are pretty close, at least from my end.
> I think it's just word smithing from now on.
good. so it should be fiished by the time the drafts door re-opens on
monday?
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
>>> I think the current proposals are pretty close, at least from my end.
>>> I think it's just word smithing from now on.
>>
>> good. so it should be fiished by the time the drafts door re-opens on
>> monday?
>
> I am hoping to start a WGLC at the Tuesday meeting, and cary it over to
> the
> There are still unaddressed comments. Do we do WG last calls for
> unfinished documents?
>
> Also, we have *no idea* if the document matches current implementations or
> deployments. The proponents of TACACS+ have been surprisingly silent on this
> topic.
>
> So everyone wants the
i am confused as why this is in grow. it's protocol.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> 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
___
OPSAWG
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
> I fone has geo-information, it is unlikely to change.
i guess you have never noticed when you are at ietf praha and your phone
says you are in seoul or whatever. it takes non-trivial ops pain to get
ietf attendees geoloc to work; and sometimes we can't.
when you find yourself in a hole, first
> 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
[ first, apologies for forging a message from joe to the list ]
back in october 2016, i said
> at this level of abstraction, anything can be made to look as if it
> would work and be wonderful. it essentially says that a multi-as vpn is
> composed by linking multiple single-as vpn systems.
>> Agreed to replace the section with a simple statement that
>> obfuscation provides no integrity or replay protection. I'm assuming
>> this refers just to 10.1 and not the whole of 10.
>>
> [Joe] I think you could probably replace a large portion of 10.2, 3 and 4
> as well.
hyperbole is not
> "TACACS+ MUST be used with an addition security mechanism to
> protection of the communication such as IPSEC or a secure network such
> as described in 10.5. "
not operationaly viable
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
[ the major crypto authentication done, so another author who did it
your comments would be appreciated ]
A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-01.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.
Name: draft-ymbk-opsawg-finding
would appreciate review prior to calling for wg adoption
thanks
randy
A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.
Name: draft-ymbk-opsawg-finding-geofeeds
Revision: 02
Title
thanks for review! proposed diff attached.
> If the comments change, the signature changes?
yep. otherwise vast complexity lurks. but is there a text change you
want? i may be naïve expecting that "a digest of the main body of the
file" is sufficient.
> [a] the source of the geofeed
submitted by Randy Bush and posted to the
IETF repository.
Name: draft-ymbk-opsawg-finding-geofeeds
Revision: 03
Title: Finding and Using Geofeed Data
Document date: 2020-09-15
Group: Individual Submission
Pages: 17
URL:
https://www.ietf.org/id
>> Identifying the private key associated with the certificate, and
>> getting the department with the HSM to sign the CMS blob is left as
>> an exercise for the implementor.
>
> This cynical comment jumped out at me.
> It seems that you don't have a lot of confidence that the key will be
>
> FWIW, we tried to have some HTTP header discussion in 8805:
> https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information
An entity fetching geofeed data using these mechanisms MUST NOT
do frequent real-time look-ups to prevent load on RPSL and
geofeed
> But “UTC” is more canonical than UCT.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Original:
>As this information is not always subject to verification, it is
>recommended that this field is in policy evaluation.
>
> We are planning on replacing it with:
> Updated:
>As this information is not always subject to verification, it MUST NOT be
>used in policy
> I just reviewed rev -02. Other than noticing two ’s’ in “objects”
> in section 5, I didn’t notice any other issues.
thanks for taking a pass. objectss corrected, plus a other thinks
erik kline pointed out. we'll push -03 when there have been changes
of substance.
> One thing that did stick
> I'd like to provide some feedback on
> draft-ymbk-opsawg-finding-geofeeds-03 in relation to RDAP. The current
> draft makes reference in passing to RDAP, and the remarks: RPSL
> attribute will fit into the RFC7483 Section 5.4 IP network object
> class, however the proposed geofeed: attribute has
> I do think the “awesome” authentication bit might need to come out
> before ultimate publication, though.
just the snark, or are you saying the whole auth?
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Just the snark :-).
>>> I do think the “awesome” authentication bit might need to come out
>>> before ultimate publication, though.
>> just the snark, or are you saying the whole auth?
we can negotiate
btw, the draft is intended to document and prefer a new geofeed:
attribute, not just the
> When I read that, I assumed that such an attribute would be out of
> scope of this document and that would be a target of future work to
> happen in RIPE (perhaps?).
yep
> If this draft is intended to ALSO propose that, I would clearly
> describe the intended geofeed: attribute with examples
> I'm lost as to why you don't just do the appropriate IANA action to
> register "geofeed". Well, okay I looked it up, and maybe it's a
> challenge.
>
> RFC2622 section 10.2 says:
>New attributes can be added to any class. To ensure full
>compatibility, new attributes should not
thanks
someone should remind me to publish when
The I-D submission tool will be reopened after 2020-11-14 23:59 +07
(IETF-meeting local time).
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
i am not aware of ipr
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
hey adrian,
> Is it too late to ask for some privacy considerations to be added to
> this document?
it is never too late to ask for privacy. as usual, the problem is how
to provide it :)
> My initial thought was that the authors would point me to 8805, but a
> quick look there doesn’t show any
> 1. I believe it may be more correct to refer to RFC 4012 rather than
> 2622 (as inet6num support is declared in this draft)
thanks!
> 2. paragraph 4, first block, I think it should say "there IS a fair
> number of them."
> 3. paragraph 5 "The geofeed files SHOULD be published over and
>> 8805 was, of course, an Independent Stream production. So I carry as much
>> responsibility as anyone else for the lack of privacy discussion. But, more
>> significantly, I am entirely responsible for not having noted section 4 of
>> RFC 8805 when I wrote my email - oops.
>
> Yeah, I was
> I have requested additional directorate reviews for this work so we
> have a good amount of eyes on it.
thank you!
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Well, "whatever", but I liked the paragraph we had arrived at.
ok, ok. i could not stand the whining and put it back :)
it's just that i really prefer words to communicate something.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
hi job,
as ggm said, really appreciate your showing the tech can be done.
openssl is conservative, which has good and bad effects.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Authenticating the Geofeed data
> ===
>
> The uncommented section of the file conforms to RFC 8805:
>
> $ head -1 geofeed.csv | tee geofeed_tbs
> 2001:67c:208c::/48,NL,NL-NH,Amsterdam
>
> The commented out section of the geofeed.csv file contains a base64
>
>> Just FYI, there are 459 people on the OpsAWG list; this means we have
>> almost 500 witnesses to what I'm going to interpret as "We'll have this
>> done in a few days/weeks" :-)
i hereby witness your extremely overly optimistic intentional
misinterpretation :)
randy
---
ra...@psg.com
`gpg
> "Ideally, RPSL would be augmented to define a new RPSL geofeed:
> attribute in the inetnum: class. Until such time, this document
> defines the syntax of a Geofeed remarks: attribute which contains an
> HTTPS URL of a geofeed file."
>
> If the ideal solution is to produce a standards track
> This abstract is too short for me ...
> Potential new text (don’t hesitate to modify it):
> A network operator can publish a mapping of IP address prefixes to
> simplified geolocation information, colloquially termed a "geolocation
> feed" or “geofeed”. This document describes solutions to add
i did push -10 with that addition per discussion. it gets pretty gritty
when the political and operational uglies raise their heads. sorry.
and thanks.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
< rant >
> "While the IETF published one of the specifying documents for RPS
> [RFC], effective change control for RPSL today lies with the RIPE
> community [ref]. However, it is in scope to use the Remarks: field..."
i wish. ripe has the energy and the momentum. ripe does a lot of the
>> ever see the cat herding video?
> https://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$
>
> Does not render. Oh well, I’ve seen cat videos before, I’ll use my
> imagination.
i suspect your corporate
ok, let me try to cover what russ has not. good reviews are much
appreciated
[ in the cs academic social circle, there has been comment that,
though reviews can be a pita, they are substantial revwiews. one
gets useful feedback. in man other fields, one gets one or two
sentences
thanks john. appreciated.
> 0. I’d like to thank George Michaelson for a thorough and helpful, not
> to say exemplary, shepherd’s report.
it's odd. the acks have thanked ggm twice, once for shepherding, and
folk seem to miss it.
> 1. Section 3:
>
>Ideally, RPSL would be augmented to
my apologies. -11 had too many typos. immediately pushed -12
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> -- Section 3 --
> Having a standards track document relying on a 'remarks:' attribute looks
> really weird. Should it rather be informational ? NB: I understand that
> changing the RPSL syntax is mostly mission impossible.
note that it also specifies the "Geofeed:" attribute
> Should the case
> I may have missed something, but why does Section 5 advocate for use
> of HTTPS to fetch geofeed files in the second paragraph, and then FTP
> in the seventh?
the former is for getting one file through direct reference. the latter
is bulk transfer of the totality of the repository's data
please check -07. i think we got all directorate review comments.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
>>> If we're going with "[#RPKI Signature] address range MUST match [inetnum:
>>> followed to get here]", then there are probably a couple places that still
>>> talk about "covered by" that should catch up.
>>
>> don't find any
>>
>> what i did find is that i forgot to remove
>>
>> The
will push 16
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
mornin' folk,
thanks, rob. to be honest, i did not track process.
> When you get a chance, please can you check whether -15 is sufficient
> to clear your discuss. I think that is the last step to progressing
> this doc.
shout if you need anything from my side.
randy
> Responding to Part 1 of your DISCUSS and a few of your comments. My
> co-authors will address the other parts, including the NITS.
turning attention to this now. i was in the RIPE meetings getting this
through their sausage machine.
> OLD:
>
>1. Obtain the signer's certificate from an
>>> Publishing this document on the stanards-track does make one wonder
>>> whether RFC 8805 should be adopted at least into the IETF stream and
>>> possibly to the standards-track as well...
>>
>> and it could use a bit of work in the process. can you say "let's open
>> a can of worms?" but
i have a vague hope -14, just published, addresses all currently
expressed concerns. but i am under my quota for wrongness for the day.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> If we're going with "[#RPKI Signature] address range MUST match [inetnum:
> followed to get here]", then there are probably a couple places that still
> talk about "covered by" that should catch up.
don't find any
what i did find is that i forgot to remove
The address range of the
> Rob should probably weigh in on how much review such a change would need.
once i have the next rev out, we should look at the diff to -09 or so.
i suspect that giving the wg a week to whine would not be inappropriate.
but such decisions are above my pay grade.
randy
so
The canonicalization procedure converts the data from its internal
character representation to the UTF-8 [RFC3629] character encoding,
and the sequence MUST be used to denote the end of a line of
text. A blank line is represented solely by the sequence.
Other non-printable
> Given how systemd is prone to considerable change, I'd think it would be
> best to leave that out.
please. and for many other reasons
randy
---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
hi kyle:
thanks a million for the review. we have a suply chain problem getting
solid reviews these days.
> The nits include a need for a thorough editorial pass prior to submission to
> the RFC editor. For example:
>
> * The abstract should probably give the uninformed reader a bit more
>
kyle,
was it 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 via db-wg
> the web pki is not associated with ip address space control/ownership.
> web pki is based on control of domain name space. the two are quite
> unrelated.
note that the rpsl, the inetnum: objects, are not well secured and
authenticated. this is a bit embarrassing. and, in some regions,
the
[ excuse typos; minor hand surgery ]
> Aren't the valid ranges for an AS specified in the RPKI-protected
> routing data feed (where RPKI is available)?
not really, on a number of dimensions
first, have a look at draft-ietf-sidrops-rpki-has-no-identity
i suggest we not drag ASs into this; they
> Pivoting for a second, are you intending to support the case in which
> a provider has adopted RPKI but has no intention of signing these
> files?
unfortunately, this will be common for a while. methods for signing
with keys from the rpki are baroque at the moment, with two documents
just a quickie. i will try to get to the other stuff after $dayjobs
assumptions that the rpki and the inetnum: are congruent in ip address
space are quite unsafe, sad to say.
the granularity of the rpki is not that of the inetnum: space.
for a tragic example, among other things, in the arin
> There were some comments that will lead to document changes
commenters, please check -02
and thanks all
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
-02 was published. but, due to a merge miscommunication, it left off a
couple of acknowledgments. it also misspelled Acknowledgments :)
i'll not push -03 until after comments of substance are incorproated,
assuming no one objects.
randy
___
OPSAWG
> The signature was produced through proprietary means, but for the
> purpose of validating the signature & interopability testing that
> shouldn't matter... right?
unless you are a security person and lived through trojans such as
dual-ec. extension of kerckhoffs's principle.
randy
> So perhaps modifying your paragraph to...
>
> RFC8805 geofeed data may reveal the approximate location of an IP
> address, which might in turn reveal the approximate location of an
> individual user. As noted in section 4 of RFC8805, publishers of
> geolocation feeds are
hi rob et alia,
first, thanks a milion for a real review. really appreciated.
> 1. Specifically, I think that it would be useful for this document to
> offer more clarity as to whether the "remarks: Geofeed" tag
> specifically ties the content of the URL to a document in RFC 8805
> format, or
>> Unless is modified to formally define
> [RW]
>
> My comment was less about what gets written in the documents, and more
> about how this update would actually be done in practice. E.g.,
> updating 8805 to indicate a new section would presumably break any
> existing clients expecting to
> This I-D already defines a new content type: id-ct-geofeedCSVwithCRLF.
clearly without enough words :)
> OLD:
>
>Borrowing detached signatures from [RFC5485], after text file
>canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS)
>[RFC5652] would be used to create a
mornin rob,
new diff attached
> So, solely for my understanding, if 8805 was updated in an
> incompatible way
then it would not be 8805. it would not be a geofeed file. so the
kiddies then can have fun with a complete do-over and write their own
finding-blarffles draft.
> This makes me
1 - 100 of 143 matches
Mail list logo
