Stephane,
On Wed, Feb 15, 2017 at 04:29:38PM +0000,
nalini(_dot_)elkins(_at_)insidethestack(_dot_)com
<nalini(_dot_)elkins(_at_)insidethestack(_dot_)com> wrote
a message of 34 lines which said:
If anyone is interested, we have just done an I-D for a proposed
concept for "Internet Labs". We hope this will be of interest.
That's interesting, there is certainly a need for more resources for
the people who want to work on the practical side of the Internet
protocols.
https://tools.ietf.org/html/draft-chowbat-irl-00
I find the proposal both too detailed ("access to IRL labs" with
discussion of CLI vs Blackberry...) and too vague. What will be the
actual services provided by these labs?
What we envision are drafts which describe each lab specifically, for example,
DPRIVE, TLS, etc.
This draft is the "Base Framework". That is, each lab should describe what
hardware, software, training tools it has specifically.
I will talk with you offline about specifics of how to improve the draft.
There are a lot of resources already available. (Really a lot: may be
the poeple who want to learn/work could use some guidance.)
As far as we can see, there are, too many resources for some things and not
enough for others. We cite this in our draft. It is also the viewpoint or
perspective towards the particular IETF draft / RFC that is missing.
Our goal is to enable more people to participate well in the IETF as well as to
resolve possible discussions at a WG with actual running code or packet traces.
Let me give an example. Let's say that one wants to start working in DPRIVE
(maybe a group you know something about!), then the lab would specifically say
that if you want to see implementation of "RFC7858: Specification for DNS over
Transport Layer Security (TLS)", then here it is, and then have some sample
scenarios or even traces that are captured. Then, you may also have the
implementation of DNS over DTLS & you can see the differences.
I know that for myself, if I can stare at a packet trace at the same time that
I am reading a draft or RFC, then all of a sudden, I actually start
understanding and can comment somewhat intelligently. A few years ago, one of
my friends & I used to have a standing meeting on Thursday nights where we
would do various tests on IPv6 servers, trace them, look at them & talk
together about what we were seeing. It really allowed us to understand IPv6
concepts in a way that would have been much more difficult otherwise. Then,
you can go back to the RFC or draft & then it all starts making some kind of
sense. And, I think that I am not alone. Many people cannot just read a draft
and understand.
I know I have tried to find, for example, a DTLS trace when I wanted to learn
about that & it was not so easy. (Which is your point below about a packet
trace repository.)
And, yes, I know I could do all the implementation of everything myself, but
there are only 24 hours in a day!
As far as your point on guidance, I think that is very much on target. I think
that people need a bit of a bridge to help them make the leap to becoming
productive contributors.
Did you identify actual gaps (ideas: real-time BGP feed, repository of packet
captures, since pcapr.net seems de facto dead, etc)?
This is a very good idea. I have used PCAPR.net myself in the past & it was a
very useful service. I think the indexing of packet traces by protocol
function is quite necessary. I know Wireshark tries to have a repository also.
But it is quite incomplete. I will chat with the Wireshark core developers on
this as a good repository is useful for them also & we need more resources to
help!
Editorial: for cloud services, please mention also non-US services
(like OVH or Gandi in France, examples from China, Russia, India, are
welcome).
Great! Please let us know more.
Thanks for your comments.
Nalini