> I came to the attention of the Chairs and the ADs during the call for
> adoption that an IPR disclosure was likely pending on this draft. It
> has since transpired.
>
> The disclosure can be reviewed here.
>
> http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-
> 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
https://www.ietf.org/m
> 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
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
> 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
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
do i need to sign an nda to get the name of the draft? :)
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> http://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs/
thanks!
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> 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).
not
> 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
does this wg have a chair?
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> does this wg have a chair?
seems so. thank you, scott.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
>> Seems that in the time bikeshedding, this could have already been in
>> WGLC. Outstanding work!
> Following process and achieving consensus is not "bike shedding".
> It's entirely inappropriate to describe it that way.
i thought he was quite polite in not calling it something much stronger.
h
> 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
https://www.iet
> 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
> https://datatracker.ietf.org/doc/draft-lapukhov-dataplane-probe/
given the heavy per-hop payload, do you have estimates on how many hops
with an mtu of 512? or is this really meant for use within an
operator/datacenter, and maybe one with junbo frames?
i do not understand the relationship of t
the paragraph i deleted before sending was
[ i do have sympathy for the motivation. heck, nick duffield suckered
me in the days when at&t 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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
>>> 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,
> 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
>> fwiw, our customers do use multi-provider vpns; they use ipsec. we
>> provide ipsec capable cpe and various management/orchestration
>> systems.
> So is that enough ?
no. it does not justify 312 internet-drafts, 92 rfcs, and sellimg me a
lot of complex boxes. end of net predicted. news at e
> 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
> - The TACACS+ authentication is extended to allow the TACACS+ client
> to request the public keys from the TACACS+ server, to ease ssh-key
> management
delivered signed by the private key for proof of posession, yes?
randy
___
OPSAWG mailing list
-01 was just published. the authors believe it is ready for adoption by
the opsawg.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
we have pushed draft-ymbk-opsawg-9092-update-01, see
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/
and asked to have a few minutes for it on the agenda next month.
as the document says
Changes from [RFC9092] include the following:
* It is no longer assumed that a geofeed file
hi med,
yay! much thanks for the review.
> (1) As a complement to the discussion in the first para of the
> Introduction, I would add a note that the source address does not
> necessary point to the user. You may add a pointer to
> https://datatracker.ietf.org/doc/html/rfc6269#autoid-14 when iss
hi med,
>>> (4) Note sure we can mandate by spec how the data can be
>>> "consumed". I'm afraid the NEW sentence in the Sec Cons>> isn't
>>> useful. I would at least avoid the use of normative language
>>> there.
>>
>> you mean
>>
>> The consumer of geofeed data SHOULD fetch and
> I’ve read the original draft and the diff mentioned below.
thanks. reviews are hard to find these days.
> I think you’ve misspelled RIR as IRR in the diff.
do you mean
Absent implementation of the geofeed: attribute in a particular IRR
database
if so, it was intentional. perhaps s/
> Absent implementation of the geofeed: attribute in a particular IRR
> database
>
> if so, it was intentional. perhaps s/IRR/Whois/?
>
> JMC: Yep. I see what you’re saying now. I was reading as RIR. I
> think IRR is fine, but perhaps it should be expanded like you do RIR
> earlier.
No, I'm not aware of any IPR that applies to this draft
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> please resubmit this draft as draft-ietf-opsawg-9092-update-00
> replacing draft-ymbk-opsawg-9092-update. Do not make any other
> changes to the document text.
done. thanks.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman
ok, i am trying to make some time for this. thanks for the review!
> In section 8 'Implementation Status', a reference could be added to
> https://www.rpki-client.org/. I extended this RPKI validator
> implementation to have the ability to cryptographically verify a given
> RPKI-signed Geofeed au
> target="https://sobornost.net/~job/using_geofeed_authenticators.txt";>
>
> Example on how to use rpki-client to authenticate a signed
> Geofeed
>
>
>
>
thanks
>>> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to
>>> each oth
>>> Ah, ok. For both RSC and RTA distinct properties are listed such as
>>> "applicable in long run", "usable", "complex code"; if no comparison is
>>> intended I'd just remove the two paragraphs about RTA & RSC.
>>
>> we seem to be at cross-purposes here. the point was not comparison at
>> all.
> I will work on items 1-4 for the next version.
thanks. and thanks job for the careful eyeballs
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> Small nit: the “Error: Spurious zero bits in bitstring.” line in the
> dumpasn1 output in Appendix A can be removed, to avoid confusing the
> reader. I suspect that particular error message is a bug in dumpasn1
> rather than in the encoding example.
thanks. fixed. not worth a new push unless c
authors pushed latest revision of $ubject. would very much like some wg
members, or anyone actually. to have a look and comment before we decide
if it is time to ask for wglc.
thavanceanks
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.
> authors pushed latest revision of $ubject. would very much like some
> wg members, or anyone actually. to have a look and comment before we
> decide if it is time to ask for wglc.
well, that elicited only one poke (thanks ggm) :(
chairs, think a wglc will elicit more?
randy
_
hi med,
thanks a million for the time reviewing
> * Abstract: add "This document obsoletes RFC 9092.
sure; in my emacs buffer for -07. aside: is this sort of doc tracking
in abstracts a fashion?
> * Abstract: s/datafiles/data files
doh. thanks.
> * The changes vs 9092 lists "Geo
how about rewording to remove second must so we don't need to argue over
it? :)
OLD:
and the file geofeed_1 contains geolocation data about 192.0.2.0/29,
this MUST be discarded because 192.0.2.0/24 is within the more
specific inetnum: covering the address range and that inetnum: has a
ge
thanks, med. all in emacs buffer for -07.
this is wglc. would appreciate more constructive reviews.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
hi
> Reviewer: Sheng Jiang
> Review result: Ready with Nits
>
> Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
> Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286)
fixed. thank you!
> Downref: Normative reference to an Informational RFC: RFC 8805
been to this movie
hi
> 1. Abbreviations
> Severl abbreviations in the newly added text is better to be expanded
> on the first use, including Certification Authority (CA), EE
> (end-entity), Certificate Revocation List (CRL) and Autonomous System
> (AS).
done, i hope
> 2. Content seems repetitive
> Section 3:
> A
i just pushed -08 with what i believe to be all fixes from comments on
-07. it may be time to push the button on this one.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
>> i just pushed -08 with what i believe to be all fixes from comments on
>> -07. it may be time to push the button on this one.
> Actually, Joe did that on 2023-11-29, and it is sitting in Rob
> Wilton's AD queue…
doh.
randy
___
OPSAWG mailing list
hi rob,
thanks for review. appreciated.
> (1) p 4, sec 3. inetnum: Class
>
>Any particular inetnum: object SHOULD have, at most, one geofeed
>reference, whether a remarks: or a proper geofeed: attribute when it
>is implemented. If there is more than one, the geofeed: attribute
>
> Please push -09, and I’ll push to the IETF LC.
done
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
tim:
> (1) The following paragraph appears twice in the document (looks like just a
> copy/paste error when moving stuff around):
>
> "Identifying the private key associated with the certificate and
>getting the department that controls the private key (which might be
>stored in a Hardw
> 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
___
OPSAWG mailing list
O
thanks erik,
> * "... processing is too hard."
>
> Perhaps there's a better wording that might be found here. "imposes
> significant computational complexity" or something?
how about
processing would be quite complex and error prone
randy
_
> The nit:
>
> 192.0.2.0/12 (in Section 3) isn’t what I consider a well-formed prefix, since
> the third octet has a set bit but isn’t under the mask. I would’ve said
> 192.0.0.0/12. (Or better still 192.0/12, but that form seems to be
> disfavored.)
nit? looks like a full grown bug to me.
/
thanks for review, paul
> #1 document track
>
> The document is Standards Track, and so are the docs is
> Obsoletes/Updates ([RFC2725] and [RFC4012]), but the document also
> claims "change control effectively lies in the operator community".
> Normally, that would mean the IETF publishes this as
thanks roman,
> ** Section 3. Editorial. Consider this clarification.
> OLD
>At the time of publishing this document, change control effectively
>lies in the operator community.
>
> NEW
> At the time of publishing this document, change control of RPSL effectively
> lies in the operator c
> Suggested edits:
>
>The address range of the signing certificate MUST cover all prefixes
>in the signed geofeed file. If not, the authenticator is invalid.
>
>The signing certificate MUST NOT include the Autonomous System
>Identifier Delegation certificate extension [RFC3779].
>>> The consumer of geofeed data SHOULD fetch and process the data
>>> themselves. Importing datasets produced and/or processed by a third-
>>> party places significant trust in the third-party.
>>
>> this is in sec cons already. you want it moved up or duplicated? i
>> kinda like it wher
>>Any particular inetnum: object SHOULD have, at most, one geofeed
>>reference, whether a remarks: or a proper geofeed: attribute when it
>>is implemented. A geofeed: attribute is preferred, of course, if the
>>RIR supports it. If there is more than one type of attribute in the
>>
paul
you may, or may not, like -11. we tried to clarify some things a bit
better,
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
> https://scholar.google.com/scholar_url?url=https://dejankosticgithub.github.io/documents/publications/netconfeval-conext24.pdf&hl=en&sa=X&d=7785844682567625222&ei=DLI-Zr27FsuNy9YPtfamqA8&scisig=AFWwaebA2r_Fw4okI0irTPrMsu7W&oi=scholaralrt&hist=LiEm55wJ:3177637049449935640:AFWwaeY5VE3Htr-mPxtni
>> 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 make
> 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. fo
> 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 pla
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 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 mailing
> 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
granularitie
> 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 contr
> We also seek shepherd for this document.
a wolf may be more appropriate :)/2
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
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
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 stan
> Why anyone would need BMP wrapper to monitor IGP ?
probably similar reasons that folk seem to need bgp-ls to get the
is-is/ospf databases. is-is and ospf have decades of complexity
layered on un-simple bases. so we seek yet another layer of gunk
through which to see them more 'simply.'
i wou
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
>
> 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
o
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
interoperate.
> 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
https://
>>> 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 list
> 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 do
[ 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. this
> "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
https://www.ietf.org
>> 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 cons
[ 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 cl
>> 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
> easily
> 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 o
> 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 se
> 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 evalua
[ am i going to regret cross-posting? ]
a friend raised in private the question of whether the dns could be used
instead of rpsl.
essentially, dns does not search down-tree for you. it only answers
exact specific queries. for some reason lost in time, well at least
lost in my mind, rpsl servers
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
> 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 inte
> 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 an
1 - 100 of 155 matches
Mail list logo
