Subject: Internet Research Labs Draft

From: <[email-masked]>
Date: Wed, 15 Feb 2017 16:29:38 +0000 (UTC)

All,
 
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. 

https://tools.ietf.org/html/draft-chowbat-irl-00 

The abstract is here: 

Many people learn technical concepts best in a hands-on environment, 
and Internet protocols and standards are no exception. Internet 
Research Labs (IRL) will facilitate a platform and encourage the 
technical community (seasoned professionals and newcomers alike) to 
discuss, collaborate, design and develop utilities, ideas, sample 
code and solutions that show practical implementations (Proof of 
Concept) of existing IETF standards. These labs may also be used by 
the IETF Mentoring Program and/or EDU teams for hands-on training to 
mentees or newcomers. This base draft intends to provide a high-level 
overview of the concept of Internet Research Labs in terms of 
objectives, requirements, challenges and deliverables without going 
into details of a specific lab, technology or an IETF Working Group 
(WG). After this draft matures and gains traction within the IETF 
community, we foresee more and more Internet drafts for the specific 
labs. 

Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Feb 2017 07:08:31 +0000

How is this different from codestand?

-- 
Sent from a mobile device; please excuse typos.
+49 151 120 55791

> On Feb 15, 2017, at 17:30, "[email-masked]" <[email-masked]> wrote:
> 
> 
> 
> 
> 
> All,
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Feb 2017 10:37:07 +0100

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

There are a lot of resources already available. (Really a lot: may be
the poeple who want to learn/work could use some guidance.) Did you
identify actual gaps (ideas: real-time BGP feed, repository of packet
captures, since pcapr.net seems de facto dead, etc)?

Editorial: for cloud services, please mention also non-US services
(like OVH or Gandi in France, examples from China, Russia, India, are
welcome).

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 16 Feb 2017 13:21:17 +0000

> How is this different from codestand?

As in https://codestand.ietf.org/codestand/

---

From: <[email-masked]>
Date: Thu, 16 Feb 2017 13:43:17 +0000 (UTC)

>As in https://codestand.ietf.org/codestand/

Lars,  I believe this is what started as the CodeMatch project.   We definitely want to work with them to showcase the work they have done.   But, my understanding of CodeStand was that it was a "dating service" to match people who wanted code done with people who wanted to do code.

Our concept is a bit different.  The idea is that if you want to see, for example, how TLS1.3 looks like without having to do all the implementation yourself, you can use one of the Internet Labs and be guided through.  Everything you need will be installed, including Wireshark, or another network analysis tool.

Does that make sense?

Nalini

---

From: <[email-masked]>
Date: Thu, 16 Feb 2017 14:22:18 +0000 (UTC)

Stephane,

>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.

>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! 

>welcome).

Great!  Please let us know more.

Thanks for your comments.

Nalini