Security consideration section in SP requirements I-D
Martin Sustrik
The mandatory "security considerations" section in SP requirements draft
is rather vague; it's more of a placeholder for now.
I propose to change it to the following text:
"This memo proposes a system for communication between multiple
endpoints. Thus, it does not map naturally to connection-based security
mechanisms. Care should be taken to explain how security mechanisms
offered by underlying layers can be leveraged in such a system and/or
provide a guidelines for building security solutions on top of it."
Thoughts?
Martin
Pieter Hintjens
It might be useful to host the documents on a wiki, as Greg Wilkins
and I did for BWTP a while back
http://bwtp.wikidot.com/main:proposal1
Makes it easier for people to catch up, and you can still copy to the
list if you want.
-Pieter
> --
> Note Well: This discussion group is meant to become an IETF working group in
> the future. Thus, the posts to this discussion should comply with IETF
> contribution policy as explained here:
> http://www.ietf.org/about/note-well.html
>
Martin Sustrik
> It might be useful to host the documents on a wiki, as Greg Wilkins
> and I did for BWTP a while back
>
> http://bwtp.wikidot.com/main:proposal1
>
> Makes it easier for people to catch up, and you can still copy to the
> list if you want.
I am storing the docs at the github. The document can be found here:
https://github.com/sustrik/sp-docs/raw/master/draft-sustrik-spreqs-01.txt
Martin
Pieter Hintjens
> I am storing the docs at the github. The document can be found here:
> https://github.com/sustrik/sp-docs/raw/master/draft-sustrik-spreqs-01.txt
This is better than nothing but it doesn't create a space where people
can contribute. Typical example would be a page with UDP use cases.
All we have now are some emails.
The patterns that work are key pages with strict editorial access
(i.e. core specs), a wider range of supporting pages anyone can create
and edit, and email for transient discussions of that.
I challenge you or anyone to go back through the zeromq-dev list and
collect knowledge on the hundreds of topics that have been discussed
there. Whereas what got captured on the 0MQ wiki actually survives and
is reused. Perhaps we can avoid making this mistake again.
Is there any IETF policy on keeping semi-persistent knowledge?
-Pieter
Martin Sustrik
> Is there any IETF policy on keeping semi-persistent knowledge?
I-Ds. They are updatable and expire in 6 months.
Martin