>
>>> 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
> responsibility to catch problems with IANA considerations the RFC
> editor or
> the IESG during 3932 review.
>
> Raising awareness of possible problems with IANA considerations,
> as a reminder to independent authors certainly does not hurt but I do not
> immediately see where such text would fit naturally.
>
> (While writing the above I stumbled upon one case is not clear to myself:
> 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
> assignment criteria of the values in that namespace would be-- but I
> cannot
> find normative text)
Here is a suggestion. Add text after the 2nd last paragraph of Section 2.
OLD:
... If the
IESG identifies issues, it may recommend explanatory or qualifying
text for the RFC Editor to include in the document if it is
published.
NEW:
... If the
IESG identifies issues, it may recommend explanatory or qualifying
text for the RFC Editor to include in the document if it is
published.
Note that independent submissions are nevertheless under the
usual protocol extension rules as other documents. For instance,
an independent submission can not request an IANA allocation
from a number space marked as requiring Standards Action [RFC3932,
RFC2434].
>>> 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
>>> consensus is reached. I would like to invite people that disagree with
>>> dismissing this issue, to send in text.
>>
>> 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?
Here:
OLD:
o Documents considered by IETF Working Groups but not standardized.
While many documents of this type are published via the IESG
approval path (see RFC 3932, Section 1 [RFC3932]), the independent
submission path has traditionally been open to them. Because of
their intimate connection to the IETF Standards Process and WG
activites and the consequent sensitivity to exact statements of
relationships and to timing, there is reason to believe that all
such documents should be published only at IESG request. In any
event, these documents are published for the historical record.
NEW:
o Documents considered by IETF Working Groups but not standardized.
While many documents of this type are still published in the IETF
document stream [RFC2026,draft-iesg-sponsoring-guidelines] as
Informational or Experimental RFCs, the independent submission
path has traditionally been open to them as well. However, because
of their intimate connection to the IETF Standards Process
and WG activites and the consequent sensitivity to exact
statements of
relationships and to timing, there is reason to believe that such
documents should normally be published via the IETF stream. In
any event, these documents are published for the historical record.
There was also some text in Section 3, but that seems fine.
Jari
_______________________________________________
INDEPENDENT mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/independent
