Tero Kivinen <[email protected]> wrote: >> This WG has a history of adopting documents but then not having >> enough reviewers for us to feel confident that we are making a good >> standard, so we need to see a reasonable number of actively >> interested people before we adopt the document. If it is not >> adopted, the authors can ask for it to be published as an RFC >> through individual submission or by the Independent Submissions >> Editor.
> Either due through this working group or through individual submission
> would be fine. I do not like documenting extensions to the standard
> track protocol through independed submissions editor, especially if
> the idea is to make such extension standard used between multiple
> vendors. Some vendor just wanting to document their own way of doing
I believe that no matter how it proceeds, this extension will definitely need
to be marked "experimental".
I think that there can be no-interoperation of the IKEv2 side without
interoperation at the QKD side. My reading is that the QKD side requires
an unbroken light pipe connection between the two end-points (not sure if
amplification is allowed; I suspect not).
I agree that really, it's out-of-scope to IPsecME to care about that: the two
end points just have some really high quality random bits that they "share",
and really, *ANY* mechanism (including Pony Express) would do. {which raises
the question: why KINK isn't a better place for them to start}
As such, I don't see how this work can become "standard" for along time.
Maybe the bis-bis of it.
I am, however, all for accomodating the need for protocol numbers to make this
work.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
pgpmCKhyQ97YB.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
