ot;, and not EAP or RADIUS specific.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
might be late 2024
before this work starts.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
e draft, and the lack of experience with
implementations, I'd suggest that "Experimental" is more appropriate.
Alan DeKok.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
P address filtering? If the client has
correct TLS credentials, does it really matter what IP it comes from?
i.e. will the move to TLS still have servers identify clients by IP address?
Servers could also be configured to limit connections by source IP, as an
additional layer of security.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
rrently permitted to define an attribute which has a
zero-length value.
As such, "hold for document update" is the reasonable conclusion.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
o
> that mis-configured clients can be fixed?
Not really.
If the authors believe that there is significant operational benefit to
re-using the port, then the document should explain that in detail.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG
. I'd suggest reading the RADEXT TLS-PSK and ALPN documents linked
above. They go into exhaustive detail about how every little bit is supposed
to work. I've found that documenting the protocol in such detail greatly
improves the quality of the implementations, and is more likely to result in
interoperation between the implementations.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
draft-dekok-radext-deprecating-radius) rather than duplicating the reco in
> the doc.
Sure. That reference should informative, as the deprecation doc may take a
while to be published. That way it doesn't block your document.
Alan DeKok.
___
or anyone interested in the underlying reasons, there is a long discussion
of this topic in
https://datatracker.ietf.org/doc/html/draft-dekok-radext-deprecating-radius-03#section-7.3
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
a need for that, or would
> this rather be an convenience option? A specific port number limits the
> attack surface to a single port, and I don't see any need for that.
I think a dedicated port for TACACS+TLS would be good.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
TACACS+.
As a result, it is useful to have a configuration which can say "allow
network FOO, forbid network BAR". This would be in addition to any TLS layer
filtering.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
be secured by RADIUS, and used in environments where
RADIUS is (allegedly) secure. This means IPSec / TLS / management networks.
If RADIUS administrators want to send insecure UDP packets over the wider
Internet, then there's a lot more information than this which will get le
it should automatically create correctly-formed attributes.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
nly be extended by implementing the negotiation discussed
in the other specifications.
So we would like to suggest 64K packets here, but we can't mandate them,
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
; [Rob Wilton (rwilton)]
>
> Okay. If this will be obvious to everyone implementing/deploying RADIUS then
> fine, otherwise it might be worth including an informative reference to the
> RFC that increases the limit to 64K.
This is RFC 7930. Packet size limitations w
> IANA is requested to create a new sub-registry entitled "DHCPv6
> Options Permitted in the RADIUS DHCPv6-Options Attribute" in the
> "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
> [DHCP
lob/v3.2.x/raddb/mods-available/eap#L177
It's for EAP-TLS, but the requirements for TACACS+ with TLS would be similar.
There are a large number of options for configuring certificates, validation
methods, CAs, PSKs, etc. Nearly all of these would be required when TACACS+ is
used wi
Having been just added as co-author, No, I'm not aware of any IPR that
applies to this draft"
> On Oct 12, 2022, at 12:46 PM, Joe Clarke (jclarke) wrote:
>
> Authors and contributors, please respond on-list as to whether or not you are
> aware of any IPR that pertains to this work.
>
> Ple
S attribute, and
separately in a DHCPv6-Options attribute. They can all be added to the packets.
i.e. if the administrator of the system configures something weird, the
systems should just do what's asked.
Anything past basic filtering is complex to define, and complex to
iguration, the RADIUS server SHOULD expose the DHCP options and allow
administrators to configure them, instead of requiring them to be entered as
opaque data".
That gets the best of both worlds.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
are happy to accept
longer packets.
i.e. it's 2022, I think that software can easily handle 64K buffers for
network protocols.
There's also RFC 7499 which supports fragmentation of CoA packets. Perhaps a
similar method could be used here, if required?
Alan DeKok.
_
ns could suggest that
implementations SHOULD support 64K RADIUS packets.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
th. Each child attribute can then carry a full 253
octets of data. And there are no limits on the number of child attributes
which ca be carried.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
014 i.e. DHCPv4 carries RADIUS
attributes. So there's reasonable precedent.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ts only for "top level" attributes, and cannot
be used here.
Further, RADIUS packets are generally limited to 4K octets total. So even if
the limits on this attribute are removed, then there's still a practical limit
of around 4000 octets.
Alan DeKok.
_
On Oct 6, 2022, at 9:32 AM,
wrote:
> I added an appendix for this as you can see at:
> https://tinyurl.com/opsawg-add-latest.
I missed that, sorry.
> Do we need to sway more?
No, I think this looks good.
Alan DeKok.
___
OPSAW
le documents, and then "read between the
lines" to see what's implied. This is hard.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
-Lite-Tunnel-Name RADIUS attribute is a string
> with opaque encapsulation, according to Section 5 of [RFC2865].
That appears to be an error. I'll file an errata with IANA.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
is copied to DHCPv6
option BAR". There should probably either be an explicit mapping table given,
or each attribute definition should be extended with "this attribute is copied
to DHCPv6 attribute BAR"
Without such direction, an implementor has to gue
On Sep 15, 2022, at 10:04 AM, Qin Wu wrote:
>
> Thank for clarification, so Diameter protocol doesn't need to define any new
> attributes with similar functionality as Radius attributes, right?
That is what I said.
Alan DeKok.
ameter, and does not need to be mentioned in any RADIUS specification.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
k.
>
> Therefore, this kicks off a two-week CfA for
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/.
> Please comment on-list with support and/or discussion of the work.
I believe it should be adopted.
We can worry about R
for it.
>
> We believe this option will enable an effective encapsulated upgrade approach
> for implementors, and welcome feedback.
I think it's a good approach.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
doing TACACS+ 2.0 is a serious undertaking.
My related question is what *else* do people envision doing with TACACS+? If
it's 1-2 things and then done, a small change can be acceptable. If there's a
long list of new things to do, then it's time to do TACACS+ 2.0.
Alan
s this meet the expected use-case?
As an implementor, I can sympathize with the approach of "minimal changes".
But 15 years of minimal changes can result in a horrible mess. There's also a
good argument for saying "Look, we're going to do a bunch of stuff with
TACA
> on July 29, 2022.
I support adoption of this work.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
acs-security).
Yes. I've checked the tls13 draft, and it has addressed my concerns, thanks.
> The next version -f dahm-tacacs-tls13 *will* add one thing, a status code
> that is necessary to fulfill Joe's request about handling the deprecation
> of the unencrypted flag
sal
> (i.e., T+ as it is over TLS).
That's how I recall the document being described: "no changes to TACACS+,
just adding TLS transport".
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ponse at
> the beginning of May when the composite draft was submitted.
EMU spent a lot of time with TLS recently. I'm hoping that experience will
help here.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
er. The alternative is instead to define an extensible format, in which
case new extensions become trivial.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
there is some utility we are
> missing. We'd like more input and if there is interest, add it after
> adoption.
I would say that adding SNI has large value, and only small downsides.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
documenting TACACS+ proxying? Why has the scope changed from
the original discussion from a few years ago?
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
impler to understand, and is easily
extensible to add new fields. It also allows for multiple layers of proxying,
which the current draft doesn't.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
also have an existing spec, and code, to do pretty much this:
https://datatracker.ietf.org/doc/html/rfc7055 and
https://moonshot-wiki.atlassian.net/wiki/spaces/HOME/overview?mode=global
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
/datatracker.ietf.org/doc/html/rfc5505#section-2.4
i.e. tying multiple layers together is officially frowned upon by the IAB.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ous" thing, and not what the draft says. So it's worth talking about
the "obvious" thing, and explaining why it's wrong.
But overall, I think it's a good approach.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Or they can use RFCC
6677 channel bindings. https://datatracker.ietf.org/doc/html/rfc6677
This presumes that the devices are using TLS-based EAP methods in order to
authenticate to the network. As time goes on, this seems to be not only more
widely true, but also more widely reco
a
generic "key" to describe the shared secret / key field. And then another
field which describes what kind of encryption or obfuscation to use. For now,
only one value could be defined: obfuscation. Future standards could add other
methods.
nk it substantially changes my argument against using the same
"key" field for "obfuscation" and real "encryption" is perhaps not ideal.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
d lean towards to leaving this as "obfuscation". And, suggesting that
any newer security methods use entirely different fields in the YANG model.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
not be
termed as encryption in this document.
...
It would be prudent for the Yang model document to use the same terminology
as RFC 8907.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
hostname being connected to.
I suggest referencing RFC 7542 (NAI) for a discussion of "user@hostname"
issues.
Over all, I think this proposal is useful. My team has struggled with the
exact issues outlined here, when using SSH in a distributed environment. Bei
which use RFC 2119 language, including
RFC 2866 for one.
> - I am worried about the shepherd writeup:
That's a question for the IETF process. The document has been published.
It's a _little_ late to be asking many of these questions.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
^24 are forbidden, and lengths larger than 2^16 are
suspicious.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
it. So instead, they
use fixed-count and fixed-time retransmission behaviours which were first
implemented in 1993.
In order for your proposal to gain traction, the NAS vendors MUST have strong
incentive to implement it. And I'm not sure what that
Even if the various nits and and issues above were fixed, this proposal would
have serious security issues. Even if those security issues were addressed, I
believe that load balancing is simply not appropriate for the NAS. Even if it
was appropriate for the NAS, the vendors have spoken: NAS implement
ployments, and
> start to think about how to fill the standard gaps to make it happen. I think
> this is the core value of this draft.
I reiterate my objection that this draft says essentially nothing. And as
such, does not belong in the IETF.
Alan DeKok.
__
less trustworthy the document appears.
Quoting again:
It also helps to inspire innovative network
telemetry applications supporting advanced network operations.
Words like "inspire" are again marketing excitement, and not boring technical
engineering.
My
ility for the
"solution". While at the same time giving next to no information about the
solution.
IMHO the WG should ignore this document entirely.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ant
protocols, by default. It's worrying that *only* TACACS+ was included.
Omitting everything else is just a sign that this is a TACACS+ document, and
only a TACACS+ document.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
tf-system-aaa YANG
model, then perhaps we should discuss that with the AAA people. And if we want
to really push the envelope, provide for those AAA protocols in the
ietf-system-aaa YANG model.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
as at all useful to re-define "AAA" to mean "TACACS" here.
AAA has a well-defined meaning, which doesn't include TACACS.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On Aug 13, 2018, at 3:19 PM, Joe Clarke
wrote:
> As this document progresses towards ratification, the opsawg chairs are
> soliciting people that have implemented TACACS+ clients and/or servers
> to read the draft and comment as to whether or not their implementation
> is known to be compliant _o
haps "insecure", with an explanation as to why.
> TACACS+ server implementations SHOULD deprecate the redirection mechanism.
"implementations" is fine here. Perhaps also "SHOULD deprecate the
redirection mechanism, and disable it by default."
> T
oes not.
There are probably dozens of implementations of TACACS+ around. From my
recollection, there may have been two implementors who said "yes the draft
matches the implementation".
And one of those was from my team. Which wa
document matches current implementations or
deployments. The proponents of TACACS+ have been surprisingly silent on this
topic.
So everyone wants the document published, but they're unwilling to state if
it actually documents TACACS+.
That's a pretty large red flag *against* publica
from my end. I
think it's just word smithing from now on.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
eed to adopt the recommendations".
The spec needs to say "you MUST implement and deploy it in a secure manner".
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ULD where there's multiple things (e.g. PAP vs. CHAP is closely
> related to password management on the server side).
>
> Would this be the right way or not really?
Yes.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
rnative is to leave the reader to fend for himself. "Hmm... the
authors didn't say this was bad, so let's do it!"
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
anagement network, or (b) it's
"protected" by the obfuscation mechanism.
The spec should just describe the requirements. How the implementors and
administrators deploy it is up to them.
e.g. "PAP MUST NOT be used outside of management networks, unless the packets
are protected
insecure
[1]
or
b) we describe the protocol, along with recommendations for how best to secure
it
I choose (b). There is non-trivial support for (a).
It's not clear to me why this position is in any way controversial, or
misunderstood.
Alan DeKok.
[1] Without
ocol, *and* recommended
best practices.
If you don't think that the protocol is salvageable at all, then please
withdraw the draft.
If you think we *can* document best practices, then we should do so.
If you think documenting best practices isn't productive
The desire is to
*recommend* best practices for new deployments. This shouldn't be the least
bit controversial.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
nd you'll be back
in the same place you are today.
Again, it looks VERY much to me like the goal is to publish an "IETF stamped"
version of TACACS+. And that the content of the document is almost irrelevant.
That's just not how this works.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
elling
people that *new* implementations, or new *releases*, have to be as secure as
possible.
If the WG punts on security then we might as well add a note to the document
saying "using this protocol will ensure that hackers will pwn your equipment".
Because it will be absolutely true.
And then *no one* will want to implement it.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
hing that is insecure by design?"
Which is a Good Thing.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
#x27;ve done do a quick check recently, and there are still major issues with
the document. So there isn't much point in doing more detailed reviews. Having
done that lots, I'm disinclined to do it again.
Alan DeKok.
___
OPSAWG mailing l
quot;? Earlier text
had such prescriptive text.
> If the option must be used for legacy application reasons, then it is
> recommended to avoid the option to send secret keys in the server list.
Again, "it is recommended"
The new text is a step backwards from earlier drafts. I
st and -08, the first version which included an attribution, last
> February.
That's not true. It acknowledged I had *reviewed* the document. There was
*no* acknowledgement that "Sections X through Y were written by Alan DeKok.
> Almost a full year after -06. I can only imag
ional criticism, past and future,
> in what we believe is the most constructive way: improving in the areas where
> we were found wanting.
The goal *is* to have a specification after all.
I am, however, deeply concerned at the miscommunication. The messages could
not have been more c
ummarize:
* we have no idea if this revision of the document addresses multiple WG reviews
* we have no idea if the document even describes TACACS+ as currently
implemented
As such, it should not be put into working group last call, or much less
published until such time as those issues are addressed.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
these steps (as they have not so
far), that the chairs and ADs should replace them with other WG
member(s) who will follow the IETF process.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ledgement that this is the case.
It would be good for the authors to engage with the WG to demonstrate that
the document is ready. The document has been shown repeatedly to be not ready
for publication, with minimal engagement, feedback, or updates.
Alan DeKok.
___
that this is the case.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
he previous ad-hoc definitions.
> Boolean
>
> All boolean attributes are encoded with values "true" or "false".
Nit: encoded as US-ASCII strings with values...
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
mplementation defined, the range of T+ devices we
>>> see is so diverse and use cases are such that I would not like to
>>> constrain.]
>>
>> It would be good to have recommendations. e.g. "updates more than once
>> per second are NOT RECOMMEND, updates more t
o d). How much of UTF8 is allowed and where; it encompasses
> over 65k characters these day:-(
IMHO, the draft should just mention 18n, and run away screaming. :(
As in, "we know about it, we don't know how to fix it, we don't know what
to speak for everyone, I think the current approach in the draft will be fine.
They may ask for some sections to be removed (i.e. servers pushing keys to
clients). But everything else is pretty much fine.
The idea is that having a documented protocol, with warnings and caveats, i
task_id? Since values can be omitted, is it OK to have a
> zero-length task_id? or 1 octet?
>
> * are there recommendations for the content of task_id? e.g. incrementing
> numbers, strings, etc.
>
> * is task_id mandatory to occur in accounting packets?
> [task_id is best
IETF works. I fail to see what else could be commented
> here.
I'm saying until I complained, that *was* largely the process being used in
this WG.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On May 14, 2017, at 8:11 AM, Douglas Gash (dcmgash) wrote:
> We will work through this list, and reply with an item-by item response,
> (In place of previous mode of updating the doc to make v6) and then
> hopefully move towards a consensus for the content for version 7.
Thanks.
A
adopt this, and what status should it be.
Part of the problem is that it's hard to have an ongoing conversation around
my reviews. The comments are so numerous that discussing each one publicly
would require hundreds of messages.
Which for me is a sign that the draft is just nowhere n
o make here. The only
subjects you addressed were ones I hadn't raised.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
the existing
implementors haven't reviewed the document. So we have no idea whether or not
it describes the protocol they've implemented, or the choices they've made.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ensus, I suggest the chairs
replace you with authors who will.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
On May 12, 2017, at 2:40 PM, Douglas Gash (dcmgash) wrote:
> 1) Regarding the use of uncredited text from Alan DeKok:
>
> It is certainly the case that Alan has spent time actively engaged in the
> process of critiquing this document to improve it, and provided numerous
> p
do more.
>> It's up to the authors to demonstrate that the comments have been addressed.
>
> Authors have the next step to do at this time. Let's wait for the new
> revision first.
It's also possible to respond publicly to my review.
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ll be followed.
I would suggest that it's too early to have a WGLC, as the authors simply
haven't responded to reviews of the draft.
i.e. I have no idea what state the draft is in. After doing multiple
detailed reviews that largely get ignored,
While I appreciate that the document is improving, blatant copying of my text
without attribution is entirely inappropriate.
What are the chairs recommendations?
Alan DeKok.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailma
1 - 100 of 153 matches
Mail list logo
