Wellllll.
The mail archive does not seem to show attachments. For me. I see do see
attachments on other messages.
It would be nice to know if anyone has seen attachments on my messages in the
last few weeks.
At any rate, for the mail archive, the comments are copied below the signature.
—Sandy
Points that might get lost in the long detailed list that follows:
1. RFC4271 (and RFC6286) and RFC8209 use the term “BGP Identifier”. The main
text says RouterID and the Appendix B says “serial number”. I believe both are
talking about what RFC8209 calls the “BGP Identifier”. Most of the tech sites
say router ID or router-id or routerid or RID or some such. But I think
consistency with the referenced text would be good.
2. I was initially confused by the text in various places that talks about the
operator adding the AS and RouterID (sic) and sends to the CA. I thought that
meant the operator adds those to the CSR, which would be hard since the CSR is
signed. This occurs a couple of places. I suggest a sentence early on that
says the router certificate includes the AS and router identifier but the CSR
does not include such fields, so the operator must include the AS and routerID
when it sends the CSR to the CA.
3. “corresponds” - there are several places that say the certificate must be
validated to prove that the public key corresponds with the private key. The
main body does not say how that correspondence is validated. The appendix
suggests that the operator could validate the signature on the CSR with the
returned router cert in order to validate the key. (a) When the operator
generated the public/private key pair, why not just do a comparison to the
generated public key, presuming it was retained? (b) When the operator passed
the CSR generated by the router to the CA, why not validate the public key
before sending it to the CA? The public key in the returned router certificate
could subsequently be validated by a comparison, presuming the public key was
retained. (c) When the router is supposed to validate the public key of the
router cert it receives, and the operator generated the public/private key
pair, it does not have a copy of the CSR to validate the correspondence. Took
me a bit to realize the router could sign just any old bit of bytes and then
validate the signature with the received router cert. Right?
4. “corresponds” again - there’s no mention of a router verifying that the
router cert it receives has an AS that is configured on the router. There are
lots of other checks and double checks - why not this one? And if the router
has multiple ASs and multiple CSRs have been generated (either by the router or
by the operator), then the router uses the received router certificate to
associate the AS with the public/private key pair, so it knows which private
key to use over which session. Right?
5. Section 8 on “Advanced Deployment Scenarios” talks about routers that
already have pre-installed keys (with mentions of types of crypto that are not
known to me, and I did not dig up the refs, so I might be missing something
here). The first paragraph talks about “pre-installed key material”. I could
understand why these pre-installed keys might be useful in authenticating the
router directly to the CA. The “burdens” 1 and 2 also talk abut “key
material”. It did not look to me like the “key material” in 1 and 2 are
talking about these “pre-installed” keys. But I admit to being very confused
by the way the term is used.
6. Section 5.2.1 is titled ”Using PKCS#8 to Transfer Public Key”. The text
talks about using PKCS #8 in RFC5958, which allows for including both the
public and private key. But the text of that section is talking about using
PKCS #8 to transmit the private key to the router. I presume the title should
be Using PKCS#8 to Transfer Private Key
7. There is an early assumption that all the communication between the
operator and the router is over a protected channel. Section 5.2.1 suggests
using a CMS SignedData to transmit the PKCS#8. RFC5958 suggests several
different “CMS protecting content types” for the PKCS#8 - EncryptedData,
EnvelopedData, etc. I presume that the encrypted versions are not used here
because the protected channel ensures confidentiality. So (a) Appendix A talks
about the key strength to be used for the different crypto algorithms
(encryption, key exchange, …). That’s a big hint that the channel should
provide the related security protections. I think it would be good to
explicitly state the protections the protected channel must provide: “The
protected channel must provide confidentiality, authentication, integrity and
replay protection”. (b) if the protected channel provides authentication and
integrity, why is the protection of the CMS SignedData needed? One possible
reason follows -> (c) The AS EE certificate has an AS extension, not an IP
extension, I presume. So the AS EE certificate would be a second way for the
router to associate a private key with an AS and an appropriate BGP session
(see my comment 3c above). But this applies only when the operator generated
the public/private key pair.
8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines several
types of content, e.g., signed-data, enveloped-data, signed-and-enveloped-data,
etc. Is there any reason to specify which type? Is it operator choice?
9. The term “operator” is used to talk about carbon-based units (who are
forgetful), ISP organizations (who peer with other operators), ASs (who have an
AS EE certificates) and management system stations (that receive CSRs from the
router). It was a bit unsettling, but after multiple reads through I’m getting
used to it. I’m not sure I could suggest a term that would fit all those uses.
Perhaps network operators (the ones with DNA) identify personally with all
those uses and think of their person in all cases. “I am the AS”, “I am the
peering entity”, “I am the management of the network”, etc.
10. I do not understand the last two paragraphs of section 7 at the bottom of
page 6. It sounds to me like they are out of place, like they belong elsewhere
in the text.
11. There are some occurrences of “must” and only a few of “MUST” - the draft
is standards track, so how much of the described behaviors are mandatory?
12. Some consistency nits - PKCS sometimes followed by a space, sometimes not.
protected channel, secure channel, communications channel, protected session,
SSH session, . . .
========================================
OK, so on to the detailed comments, sequentially through the document
p3, section 1:
two methods to provision new and existing routers. The methods
described involve the operator configuring the two end points and
acting as the intermediary.
What are the two endpoints? The router and the management station? The router
and the CA? I can imagine the operator configuring the management station, but
not the CA. I can imagine the operator acting as the intermediary between the
router and the CA, but not between the router and the management station.
p3, section 1: (nit)
[RFC8208]
specifies the algorithms used to generate the signature.
If I read correctly, “the” signature in this text would be the signature on the
PKCS#10.
suggest:
[RFC8208]
specifies the algorithms used to generate the PKCS#10 signature.
p4, section 2
See Appendix A for security considerations
for this channel.
I think it is important to say what security protection are required for this
protected channel.
Appendix A talks about the strength of the key used in the various crypto
algorithms. I think a
sentence something like the following would be useful here or in Appendix A.
“The protected channel must provide confidentiality, authentication, integrity”
and replay protection.”
p4, section 4 (nit)
appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router.
suggest:
appropriate RPKI Trust Anchor Certificate (TA Cert) in the router.
or
appropriate RPKI Trust Anchor’s Certificate (TA Cert) in the router.
p4, section 4
The operator also configures the Autonomous System (AS) number to be
used in the generated router certificate. This may be the sole AS
configured on the router, or an operator choice if the router is
configured with multiple ASs.
There’s a hint here that the operator configures the router to generate just
one router certificate.
RFC8209 allows the router certificate to have one or more ASs, but recommends
that there be multiple router certificates with one AS each. Does this
paragraph intend to limit a router to one router certificate or just to limit
the router to one AS per router certificate? I have questions later about what
happens if the router wants a router certificate for each of multiple ASs.
Perhaps “A router with multiple ASs can be configured with multiple router
certificates”, maybe also “by following the process of this document for reach
desired certificate”.
The operator configures or extracts from the router the BGP RouterID
RFC4271 and RFC8209 say “BGP Identifier”. OSPF uses RouterID, and lots of C/J
commands use RouterID, or router-id, or router id, or RID, or . . . But
consistency with the referenced specs would a good thing.
p4, section 5
I think it would be great to add a sentence here explaining that the PKCS#10
(CSR) format does not include the AS and RouterID (sic). Therefore, the
operator must transmit the AS and RouterID (sic) as well when it sends the CSR
to the CA.
That sentence applies to both the router generated keys and the operator
generated keys, so maybe it could go here.
The PKCS#10 format does not include the AS and RouterID for the router
certificate. Therefore, the operator must include the AS it has chosen for the
router and the RouterID when it sends the CSR to the RPKI CA.
That should be a MUST, shouldn’t it?
p5, section 5.1
The operator adds the chosen AS number and the RouterID to send to
the RPKI CA for the CA to certify.
My first reading was that the text meant the AS and RouterID were added to the
CSR. First, that’s not possible because of the signature, unless there’s some
key sharing going on. Second, that’s not possible because the CSR format does
not include the AS and RouterID. Hence my comment above.
suggest:
The operator includes the chosen AS number and the RouterID when it sends
the CSR to
p4, section 5.1 (nit)
NOTE: If a router was to communicate directly with a CA to have the
suggest:
NOTE: If a router were to communicate directly with a CA to have the
p5, section 5.2
and adds the chosen AS number and RouterID to be sent to the RPKI CA
for the CA to certify.
suggest:
and includes the chosen AS number and the RouterID when it sends the CSR to
the RPKI CA
for the CA to certify.
p5, section 5.2.1
section title “Using PKCS#8 to Transfer Public Key”
PKCS#8 in RFC5958 can transfer public keys. But the following text is talking
about transferring the private key to the router.
I think this title should be “Using PKCS#8 to Transfer Private Key”
A private key encapsulated in a PKCS #8 [RFC5958] should be further
encapsulated in Cryptographic Message Syntax (CMS) SignedData
[RFC5652] and signed with the AS's End Entity (EE) private key.
Would “A private key encapsulated in a PKCS #8” be followed by "OTOH, a private
key that is not encapsulated in a PKCS#8”? :-)
Suggest:
A private key can be encapsulated in a PKCS #8 [RFC5958] and should be
further
(or “is” encapsulated or “should be” encapsulated)
Section 3 suggests various ways to “exchange PKI-related information with
routers”. Is this PKCS#8 just one more way, or is it the recommended way? The
intro to section 5 suggests that copy and paste could also be used, but doesn’t
say if that would be copy and paste of the PKCS#8. If Section 5 is also
talking about straight copy and paste of the hex or the PEM block, then that’s
another alternative.
RFC5958 discusses several “CMS protecting content types” to protect the
AsymmetricKeyPackage. I presume that the encryption/enveloping content types
are not needed because confidentiality is being provided by the protected
channel. But then why use the CMS SignedData - would not the protected channel
provide the authentication and integrity needed? (But see potential reason
below)
[RFC5652] and signed with the AS's End Entity (EE) private key.
Does it matter which AS’s EE cert the operator uses to sign the PKCS#8? I
presume that the AS must match an AS with which the router is configured.
Should the router check that? Does a router that is configured with multiple
ASs use this communication to tie the private key to the appropriate AS &
BGPsec session?
If the answer is yes to both questions, should those actions be mentioned here?
(I admit to being a bit dizzy here, but maybe the mapping of private key to AS
happens in the receipt of the router certificate.)
include in the SignedData the RPKI CA certificate and relevant AS's
EE certificate(s).
Maybe this is the reason for using the SignedData - to be able to include the
AS’s EE cert and give the router the means to tie the private key to the right
AS.
The router SHOULD verify the signature of the encapsulated PKCS#8 to
ensure the returned private key did in fact come from the operator,
Then shouldn’t it be signed with the operator’s personal cert? :-)
include in the SignedData the RPKI CA certificate and relevant AS's
EE certificate(s).
Elsewhere (sections 6 & 7) it mentions including the entire cert chain. Should
that be mentioned here as well?
p5, section 6 (nit)
The operator uses RPKI management tools to communicate with the
global RPKI system to have the appropriate CA validate the PKCS#10
request, sign the key in the PKCS#10 (i.e., certify it) and generated
PKCS#7 response, as well as publishing the certificate in the Global
RPKI.
for symmetry, suggest:
The operator uses RPKI management tools to communicate with the
global RPKI system to have the appropriate CA validate the PKCS#10
request, sign the key in the PKCS#10 (i.e., certify it) and generate a
PKCS#7 response, as well as publish the certificate in the Global
RPKI.
p5, section 6
External network connectivity may be needed if the certificate
is to be published in the Global RPKI.
The previous sentence and the following paragraph do not hint that there is any
“if” about the publication of the certificate. Is there a case where the
certificate is NOT “to be published in the Global RPKI”?
p6, section 6 (nit)
2. Returns the certificate to the operator's management station,
packaged in a PKCS#7
Needs a reference. RFC2315?
In the operator-generated method, the operator SHOULD extract the
certificate from the PKCS#7, and verify that the private key it holds
corresponds to the returned public key.
“it” means the operator, right?
You get to Appendix B before the verification of the correspondence is
explained. I think it should be explained here.
The Appendix B says the operator should verify the signature on the PKCS#10 CSR
to verify the correspondence. But the operator generated the key - can’t the
correspondence be verified by checking the certificate’s public key against the
operator generated public key (presuming the key was retained)? That seems too
easy - I fear I am missing some important part here.
p6, section 7
The router SHOULD extract the certificate from the PKCS#7 and verify
that the public key corresponds to the stored private key.
I think more needs to be said about how the correspondence would be verified.
Appendix B says the operator should verify the signature on the PKCS#10 with
the certificate to verify the correspondence to the private key. That would
work for the router as well if the router generated the PKCS#10, but not if the
operator generated the key pair and the PKCS#10. But the router could sign any
random bunch of bits and verify the signature with the certificate to verify
the correspondence. Should those things be said?
Also, in the router-driven method, the router can verify the correspondence
simply by matching the certificate’s public key with one of the router’s stored
public keys. (Right? What am I missing here?)
Should the router also verify that the AS mentioned in the returned router
certificate is an AS with which it is configured?
For a router that is configured with multiple ASs, is this where the router
ties the private key to the AS & BGPsec session with which the private key
should be used?
The last two paragraphs of section 7 confuse me.
Even if the operator cannot extract the private key from the router,
this signature still provides a linkage between a private key and a
router. That is the operator can verify the proof of possession
(POP), as required by [RFC6484].
What is “this signature”? And there’s been no mention in this section of
extracting the private key from the router.
This sounds to me like it belongs in section 5.1, maybe after:
“to sign
the PKCS#10 with the private key. Once generated, the PKCS#10 is
returned to the operator over the protected channel.
And then:
NOTE: The signature on the PKCS#8 and Certificate need not be made by
the same entity. Signing the PKCS#8, permits more advanced
configurations where the entity that generates the keys is not the
direct CA.
Maybe this belongs in section 5.2.1 where it is talking about the PKCS#8?
Even so, I’m not sure what Certificate this text references. The AS EE cert?
Both the router-driven method and the operator-driven method are not the direct
CA. Nowhere in this draft does it mention the CA generating the keys. So the
entire draft is one of these “advanced configurations”. What am I missing here?
p7, section 8 (nit)
Transport" [RFC7030] or the original CMC transport protocol's
Is the possessive really needed here? I didn’t peruse the RFC5273 thoroughly,
but I can see that it defines a number of transport methods, so maybe there is
a “CMC transport protocol’s X” missing here.
p7, section 8
This section uses “key material” several places. But I’m not certain each use
is talking about the same key material.
When the operator first establishes a secure
communication channel between the management system and the router,
this pre-installed key material is used to authenticate the router.
So the router gets keys as part of the manufacturing, where the “pre-installed
key material” can be used in communication with the operator.
I can see that this might make it easier for the router to communicate directly
with the CA and authenticate itself using these keys. But section 5.1 notes
that the CA has no way to authenticate the router. I don’t know that the
pre-installed key material could provide that way to authenticate the router,
without the participation of the operator at some point.
The operator burden shifts here to include:
I’m not sure how to read this. Maybe “The operator burdens that shift here
can/will include”.
I’m also not sure if both 1 and 2 are presumed to be shifted/lifted, or if it
is either.
1. Securely communicating the router's authentication material to
the CA prior to operator initiating the router's CSR. CAs use
authentication material to determine whether the router is
eligible to receive a certificate. Authentication material at a
minimum includes the router's AS number and RouterID as well as
the router's key material, but can also include additional
information. Authentication material can be communicated to the
CA (i.e., CSRs signed by this key material are issued
certificates with this AS and RouterID) or to the router (i.e.,
the operator uses the vendor-supplied management interface to
include the AS number and routerID in the router-generated CSR).
Who is doing the communicating in “securely communicating to the CA” and “can
be communicated to the CA”? In the following paragraph, the text says “the
router is communicating directly with the CA” - is the communication in this
part 1 text going from the router to the CA?
What is the “router’s key material”? I could read it both ways:
The paragraph above says that the pre-installed key material is used to
authenticate the router, so maybe the “router’s key material” is the
pre-installed key material. The text says that the CA “uses” the
authentication material, which includes the router’s key material, to determine
whether to issue the certificate. I don’t know how the pre-installed key
material could assure the CA that the router could be issued a cert, without
some coordination with the operator about that particular key material.
Then the text says “CSRs signed by this key material” which implies that the
“router’s key material” is the public/private key pair.
So I’m not certain what is going on here, or how the pre-installed key material
is helping.
Once configured, the operator can begin the process of enrolling the
router.
What does “once configured” mean? configuring the router-operator protected
channel? Doing the communication of authentication material in 1 and 2 above?
Configuring the router with AS and RouterID?
Because the router is communicating directly with the CA,
there is no need for the operator to retrieve the PKCS#10 from the
router or return the PKCS#7 to the router as in Section 6. Note that
the checks performed by the router,
Section 5 says the router returns the PKCS#10 to the operator.
Section 7 says the operator sends the PKCS#7 to the router and the router
performs checks.
suggest:
Because the router is communicating directly with the CA,
there is no need for the operator to retrieve the PKCS#10 from the
router as in Section 5 or return the PKCS#7 to the router as in Section 7.
Note that
the checks performed by the router in Section 7,
When a router is so configured the communication with the CA SHOULD
be automatically re-established
what does “so configured” mean here? configured with pre-installed key
material? configured by the operator with AS and RouterID?
p8, section 9.1 (nit)
just for symmetry:
4. Use some other kind of automated process to search for and track
suggest:
4. The operator uses some other kind of automated process to search for and
track
p8, section 9.1
Regardless of the technique used to track router certificate expiry
times, it is advisable to notify additional operators in the same
organization
“notify additional operators” — In addition to what? or after what?
I think you mean “multiple” operators, or I misunderstand.
p9, section 9.3 (nits)
certificate to the router), and distributing the status takes time
Not sure what you mean by “status” that needs to be distributed. Are you
talking about distributing the revocation “status” in the CRL?
Keeping the router operational and BGPsec-speaking is the ideal goal,
but if operational practices do not allow this then reconfiguring the
router to disabling BGPsec is likely preferred to bringing the router
offline.
suggest:
router to disable BGPsec is likely preferred to bringing the router
p10, section 9.4
To allow operators to quickly replace routers without requiring
update and distribution of the corresponding public keys in the RPKI,
routers SHOULD allow the private BGPsec key to inserted via a
protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This
lets the operator escrow the old private key via the mechanism used
for operator-generated keys, see Section 5.2, such that it can be re-
inserted into a replacement router.
The topic here is routers that won’t allow off-loading of their keys.
“routers SHOULD allow the private BGPsec key to inserted”
is the router that is doing the allowing the old, soon to be replaced routers,
or the newly installed routers?
“to <be> inserted” - where? - in the newly installed router or in the
management station?
“This lets the operator escrow the old private key” - sounds like the old
router is allowing the private key to be “inserted in” (exported to?) the
management station. Right?
Is there a suggestion of how to get the routers to allow export of the key,
which is currently not allowed?
I don’t see that section 5.2 says anything about a mechanism for escrowing
keys. It talks about installing a private key into a router over the protected
channel. If the citation to 5.2 is about the “such that it can be re-inserted”
part of the sentence, then I get it. But the citation should move to the end
of the sentence.
p10, section 10 (nit)
After
familiarizing one's self with the capabilities of the router,
operators are encouraged
suggest:
After
familiarizing themselves with the capabilities of the router,
operators are encouraged
or
After
familiarizing one's self with the capabilities of the router,
an operator is encouraged
p11, section 10 (nit)
employees that no longer need access to
routers SHOULD be removed the router
suggest
employees that no longer need access to
a router SHOULD be removed from the router
or
employees that no longer need access to
a router SHOULD be removed from the router access [list]
p11, section 10 (nit)
The
operator MUST ensure that installed CA certificate is valid.
suggest:
The
operator MUST ensure that the installed CA certificate is valid.
p14, section Appendix A
x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
authentication.
is that an example, or a recommendation?
p15, section Appendix B (nit)
that will generate the key pair for the algorithms noted in the main
body of this document;
the algorithms are not noted in the main body, but the end of section 1 does
cite RFC8208.
the private key just generated to sign the certification request with
the algorithms specified in the main body of this document;
the algorithms are not specified in the main body, but the end of section 1
does cite RFC8208.
p16, Appendix B
Uses of “serial number”:
the subject name and serial number for the router. The CA needs this
and
CSR you sent; the certificate will include the subject name, serial
number, public key, and other fields
and
Create CSR and sign CSR with private key, and; o Step 3: Send CSR
file with the subject name and serial number to CA.
The first of these seem to mean the BGP Identifier aka RouterID. As said
before, RFC4271 and RFC8209 use the term BGP Identifier.
The second and third use of “serial number” probably also mean BGP Identifier
aka RouterID (not the issued cert’s serial number).
p17, section Appendix B (typo nit)
way through GPsec-enabling the router.
suggest:
way through BGPsec-enabling the router.
p17, section Appendix B
To avoid having routers with expired certificates
follow the recommendations in the Certification Policy (CP) [RFC6484]
you could also mention section 9.1.
> On Nov 14, 2017, at 10:36 AM, Sandra Murphy <[email protected]> wrote:
>
>
>
> Sorry, the reply did not pick up the original attachment.
>
> Attached here.
>
> Let me know if there are problems reading the comments.
>
> —Sandy
>
> <draft-ietf-sidr-rtr-keying-14.mycomments.rtf>
>
>> On Nov 14, 2017, at 10:33 AM, Sandra Murphy <[email protected]> wrote:
>>
>> Speaking as wg co-chair
>>
>> Please, wg, do take a look at the comments attached. This draft was
>> requested by the operators and is important.
>>
>> Some of the comments are about substance. Those at the very least must be
>> considered by the wg.
>>
>> Please take advantage of focused attention and close proximity at the IETF
>> meeting to discuss.
>>
>> I unfortunately can not be there to button hole people and shove printouts
>> into their hands.
>>
>> —Sandy, speaking as wg co-chair
>>
>>> On Nov 5, 2017, at 9:25 PM, Sandra Murphy <[email protected]> wrote:
>>>
>>> I’m attaching some comments and questions I found in the -14 version.
>>>
>>> —Sandy
>>>
>>> <draft-ietf-sidr-rtr-keying-14.mycomments.rtf>
>>>
>>>> On Oct 20, 2017, at 1:04 PM, Sean Turner <[email protected]> wrote:
>>>>
>>>> Chris,
>>>>
>>>> This version includes changes to address Oliver’s and Sriram’s comments.
>>>>
>>>> spt
>>>>
>>>>> On Oct 20, 2017, at 13:02, [email protected] wrote:
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> This draft is a work item of the Secure Inter-Domain Routing WG of the
>>>>> IETF.
>>>>>
>>>>> Title : Router Keying for BGPsec
>>>>> Authors : Randy Bush
>>>>> Sean Turner
>>>>> Keyur Patel
>>>>> Filename : draft-ietf-sidr-rtr-keying-14.txt
>>>>> Pages : 17
>>>>> Date : 2017-10-20
>>>>>
>>>>> Abstract:
>>>>> BGPsec-speaking routers are provisioned with private keys in order to
>>>>> sign BGPsec announcements. The corresponding public keys are
>>>>> published in the global Resource Public Key Infrastructure, enabling
>>>>> verification of BGPsec messages. This document describes two methods
>>>>> of generating the public-private key-pairs: router-driven and
>>>>> operator-driven.
>>>>>
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
>>>>>
>>>>> There are also htmlized versions available at:
>>>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-14
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>> _______________________________________________
>>>> sidr mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/sidr
>>>
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
