Re: [INDEP] Last Call Summary of rfc-independent

[Olaf M. Kolkman]

Jari wrote:

Thanks for summarizing. Responding to a couple of points inline:

Thanks for the response, apologies for my late reply.

3. The interaction between "independent" and modifications and/or
creation of IANA registries.

There seems consensus that the document should not try to solve these
issues and that these issues will in practice be caught by the RFC
editor or IESG review. It has been suggested to raise awareness about
possible interactions with a reference to RFC2434 but it seems (my
opinion) that that sort of instruction is to detailed for this level

of document. I therefore propose not to include text along those lines.

Are you saying RFC 3932 is the normative rule on that? I can
buy that. But remember that these documents do not exist
just to document the rules for our process. They will also be
read by people who are considering submitting an RFC to
one of the streams. To help them make the right decision
I think it is essential to point to the IANA rules. We should
not repeat the rules or start elaborating anything stated
in RFC 3932, 2434 or any of the Standards Track RFCs that
lay out the rules for IANA considerations in any specific
case. But even from a truth-in-marketing point of view the
document needs to warn people that they have to check
whether the IANA rules allow non-IETF submissions.

I was not precise enough when saying "trying to solve these issues".

"these issues" were mainly referring to the discussion who has the

the IESG during 3932 review.

Raising awareness of possible problems with IANA considerations,

immediately see where such text would fit naturally.


can an independent submission  'create' a new registry? I personally do
not see any reason why it shouldn't-- at least within bounds of what the

find normative text)

responsibility to catch problems with IANA considerations the RFC editor or as a reminder to independent authors certainly does not hurt but I do not (While writing the above I stumbled upon one case is not clear to myself: assignment criteria of the values in that namespace would be-- but I cannot

4. Independent publication of documents resulting from IETF process.

My reading of the discussion is that this issue is a hot topic that
does not necessarily needs to be covered in the document. Under the
current independent text the RFC editor has sufficient flexibility to
set its own policy on publication of this set of document.

I am carefully using the words "my reading of" since I am not sure if

dismissing this issue, to send in text.

consensus is reached. I would like to invite people that disagree with

This is indeed a hot topic, and one where we may still
be learning for quite a while. Perhaps after that
learning process we should write another RFC on
the treatment of documents resulting from unsuccessfully
terminated IETF processes.

My take would be to provide a fairly small amount of
guidance and without any hard rules about this topic
in both draft-klensin and draft-iesg. I think we already
do that, though as I recall there was a slight tone
difference between the documents.

Text needed. I feel responsible and promise to send
some.

Looking forward to that... could you give an ETA?

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
INDEPENDENT mailing list
INDEPENDENT@ietf.org
https://www1.ietf.org/mailman/listinfo/independent