Hi Nico,
even if we later fold the problem statement (PS) into the
standards-track document, the motivation behind such a PS is to achieve
common understanding of the problem *before* all of our attention is
diverted towards the technical solution. What worked for us in the past
is to have a separate PS/requirements document, and to kick off the
solution document as soon as the PS leaves the working group. I.e.,
without waiting for the PS to actually get published.
Thanks,
Yaron
On 11/21/2011 11:44 PM, Nico Williams wrote:
On Mon, Nov 21, 2011 at 2:09 PM, Stephen Hanna<sha...@juniper.net> wrote:
* Should we create a problem statement and requirements
draft?
The problem statement seems simple enough that if there is to be just
one Standards-Track RFC with one (or more) solution(s), then the
problem statement could be folded into the one S-T RFC.
* Should we create a Standards Track document with
the solution or just document existing proprietary
vendor solutions in Informational RFCs?
What are the existing proprietary solutions? I'd prefer to see a
Standards-Track solution, but that's not incompatible with documenting
an existing proprietary solution, if there are any such that can
reasonably be made an Internet standard.
Nico
--
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
