Suresh, et al,
I am not sure it is appropriate to treat the issue of this
being possibly published as a BCP as a "process nit".
There are a lot of required behaviors and no discussion to
lead one to conclude that these are already existing behaviors
in any part of the "problem space." In fact, what discussion
there is includes statements like:
"This document outlines the proposed solution for IPv4."
That doesn't sound like an endorsement of an existing
approach one should expect from a BCP.
The entire Abstract says only this:
"This document outlines a solution for the Mobile IPv4 and IPsec
coexistence problem for enterprise users. The solution consists
of an applicability statement for using Mobile IPv4 and IPsec
for session mobility in corporate remote access scenarios, and a
required mechanism for detecting the trusted internal network
securely."
The introduction includes a bullet requirement of the
"solution specified in this document" that says "must minimize
changes to existing firewall/VPN/DMZ deployments" - clearly
implying that some significant part of the deployed equipment
may require changes (further begging a question about where
and when the "current practices" should be discovered).
In fact, the introduction explicitly states -
"Unfortunately the current Mobile IPv4 and IPsec standards alone
do not provide such a service"
- where the service referred to is (presumably) the target solution
proposed by this document.
As I understand it, the use of "Best Current Practices"
is intended to document the best of (possibly several) existing
solutions for use in the network. Using a BCP to propose a new
set of "practices" - particularly where those practices involve
required behaviors in existing devices that may or may not be
present, and without any obvious mention of at least considering
that as an issue - (at worst) looks effectively like an "end-run"
effort to avoid standards track processes, or (at best) severely
optimistic interpretation of the phrase "current practice".
Have BCPs become the new standard's track?
--
Eric Gray
Principal Engineer
Ericsson
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Suresh Krishnan
> Sent: Monday, March 03, 2008 3:05 PM
> To: General Area Review Team; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; Henrik Levkowetz; Jari Arkko
> Subject: [Gen-art] Gen-ART review
> ofdraft-ietf-mip4-vpn-problem-solution-04.txt
>
> I am the assigned Gen-ART reviewer for
> draft-ietf-mip4-vpn-problem-solution-04.txt
>
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Summary: Ready for publication. All my technical comments on
> the earlier
> version of this draft have been addressed.
>
> Process nit
> ===========
> I am still concerned about the draft being a BCP rather than
> a Standards
> track document since it requires changes to node implementations and
> requires behavioral changes on some nodes.
>
> Cheers
> Suresh
>
>
>
>
>
>
>
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
