Re: Internet Research Labs Draft

[<[e-mail]>]

Stephane,


On Wed, Feb 15, 2017 at 04:29:38PM +0000,
[e-mail] <[e-mail]> 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