On 16 Mar 2009, at 03:53, Pekka Savola wrote:
Actually, this is being proposed as an IETF RFC (as opposed to say,
RFC-editor RFC) (you can see this by e.g. looking at the Evaluation
record in the datatracker.). It seems to be an individual submission
through an area director (Tim Polk).
Well, if that's true, and it is not obviously true to me,
then that wasn't our idea, but instead the IESG's idea.
For the record, the draft authors are quite happy for this to be
a non-IETF Informational RFC, since that's what we already thought
was happening.
Originally, the Security AD wanted to persue Proposed Standard,
which is how it got into I-D Tracker, and had an IETF-wide Last Call,
but then more recently the IESG consensus was that this was not
standards-track material, so now the document is intended to be
Informational.
The MLS community are simply, however, trying to be flexible. :-)
The main difference is that (unless the rules have changed recently),
rfc-editor RFC's get an "IESG Note" in the first page which says the
document is not a product of the IETF, etc. which essentially
disclaims any IETF endorsement of the protocol. This draft would not
have such a note.
What words would you like to see added ? and where in the draft ?
(I find it more productive to discuss specific edits to the draft,
than hypothetical issues. :-)
Kindly note, at present, there are several *pages* of scoping text
(effectively these are a disclaimer that this option is not intended
for general use on the public Internet).
Now, the document keeps getting longer and longer, mainly due to people
wanting to add more and more text saying this option has limited utility
and that utility does not include the public Internet. Most recently,
some other (non-MLS community) folks have started to complain to me
that the document is too repetitive on these points, which repetition
exists solely to respond to the earlier comments.
(Personally I would have a much smaller problem with the publication
of this document if it included an appropriate IESG note.)
While I don't necessarily object to some IESG note:
- the IESG have not proposed one,
- the IESG have not suggested that one was appropriate,
AND
- it isn't obvious to me what such a note might say, given
the existing numerous pages of scoping text which are
already a multi-page disclaimer.
(This seems pretty deep into the hypothetical to me right now.)
The second difference in this case is that the allocation guidelines
for IPv6 options of this type are basically undefined at the moment.
(No comment from me; I can't speak for the IPv6/6MAN WG or the IESG.)
I think this is interpreted so that some IETF approval for new
codepoints is required.
(No comment; I can't speak for any of the Powers That Be.)
It is not obvious why one couldn't just ask
community the question "do we grant this codepoint for this purpose?"
In fact, I believe this IS roughly the question the IESG was hoping
to see answered, but perhaps with the sense inverted.
"Does this WG object to granting this IPv6 option a codepoint ?"
instead of "do we grant this codepoint for this purpose by approving
this IETF RFC?"
This second question you wrote (above) is not MY understanding
of this discussion/proposal on this mailing list.
To be really honest, I do not perceive a huge difference between
the two phrases you used. I gather that to you there is a huge
difference there, and so I am partly confused.
BOTTOM LINE:
The MLS user community is seeking only 2 things, which frankly
I thought would be procedurally much simpler than it has been
so far (speaking as someone who has been active with the IETF
for 20+ years):
1) an open specification; to achieve this,
nearly any form of RFC would suffice.
The MLS community does NOT seek an IETF endorsement.
2) an official code point for the IPv6 Option,
purely for interoperability reasons.
I've followed the various IESG instructions about how to proceed,
as best I understood them, and as those have evolved over time.
The most recent input seemed to say that this document ought to be
an individual submission Informational RFC (which we are quite
happy and comfortable with :-).
(Simply getting to version -11 of this I-D recently reflects the
large number of document edits that we've been making recently
based on various feedback.)
We are flexible about how to get to the two objectives that
I've outlined just above. It would be helpful to understand
whether there are specific edits that would resolve your concern,
and if so what edits you are proposing for which part of the
draft.
Yours,
Ran Atkinson
r...@extremenetworks.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
