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
At the meeting, someone made a suggestion about just documenting use cases. If
this is the same thing as a requirements document, then I'm in favor of it.
If a requirements draft is much more involved -- I would be against it.
Also, I do believe a standards track document would be useful, but d
Classification:UNCLASSIFIED
I think the problem as stated represents the issue quite well although I'd be
tempted to add discovery to the list of issues.
What I've taken awa from the various debates is that there are differing views
as to whether the problem can be sorted by combining existing
As per RFC 4301 implementing AH is a MAY and ESP a MUST. Given that
most of what is achieved by AH can be easily achieved by ESP-NULL, is
there a possibility that AH may get deprecated in the future. Should
new protocols or mechanisms be defined in IETF that depend solely upon
AH to be supported?
Hi Jack
On Nov 23, 2011, at 1:24 AM, Jack Kohn wrote:
> As per RFC 4301 implementing AH is a MAY and ESP a MUST. Given that
> most of what is achieved by AH can be easily achieved by ESP-NULL, is
> there a possibility that AH may get deprecated in the future. Should
> new protocols or mechanisms
