[newtrk] question about repurposing-isd-00.txt

[Michael Richardson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----


I have a question about how the ISD would work in an RFP process.

I have read the repurposing document, and I think that it will be very
useful in a procurement process.

{At least from the Government of Canada, we see very strange things in
 RFPs. The silliest one that I saw this year was that RFC1180 was
 specified in an RFP as meaning "TCP/IP". (that's one word, btw. UDP
 runs on top of "TCP/IP"). When challenged on this, asking if they mean
 791/792/793, aka STD0005), they replied and gave a document that was
 unrelated and was in Historical status. (they replied by fax, so I
 don't have the number here}

I think that Paul Hoffman is also on this list, so I'm going to ask my
question as IPsec document specific example.

Let's that the ISD for IPsec was:
      ISD-2401

I do not think that publication of RFC2401bis will actually take IPsec
to Draft Standard, rather, since we are in fact introducing some new
concepts, it will cycle at PS. This is unfortunate, because 2401 really
does deserve to be Full Standard at this point. 

So, I think that "ISD-2401" can actually make the above point, and
could even say that the contents of RFC2401 which are unchanged
technically by RFC2401bis, can be considered very reliably described.

I think that we would not issue a new ISD for IPsec.

Now, how does an RFP specify things? 
(Section 10 talks about what a vendor can/might do.)

Should it ask for "ISD-2401" as the stable identifier, when they really
mean that they want the functionality of RFC2401 (and friends, including
probably IKE, without 1DES, but with 3DES and AES). But, they do not
care if they get 64-bit replay counters, or and of the useful, but new
ideas in RFC2401bis. They also didn't require IKEv2.

i.e. they *REQUIRE* the stable, full-standard-ish subset of IPsec.
Next year, when IKEv2 implementations become available, they may be
happy to have that, but they still need IKEv1. 

Maybe some feel it isn't the IETF's job to make the life of procurement
people easier. No point in having stable identifiers that aren't useful
to people. If we want to make this work, it has to work well enough that
it can be used in an RFP. Marketing people will then see it, and the
result is that they new nomenclature will get used.

So, it seems that the RFP will have to say "ISD-2401 January 1, 2005",
as suggested by section 10.

a) Does this document intend obsolete the "STD" series process?

b) I think that the first ISD issued should be for the RFC2026/BCP0009.
   series :-)

c) do ISDs get issued as internet drafts for comment before the archive
   is updated?

d) will the ISDs have a DTD and associated .xml version?


] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [e-mail] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

   


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQY539YqHRg3pndX9AQG3qAP+PrA8ioiMIhMRHnp+Pja0zNH3dYyKJwAo
ravLBS1AjhHEj1E6Or1AgTd9jiZrLjNB11BSdlQ7Tr31Dudgfr1JuxkzOzipaKY5
ZSRQQBBevugbB/mmdXOFobW0tuWOflneuBm9bEGRNVAvHzVbNR76Kd2zIH7Bosub
WVnI6EKZ6pk=
=QoKB
-----END PGP SIGNATURE-----
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html