Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of I

If I understand your note properly, your primary concern is that folks 
will think that Independent submission are IETF products.
This is a fair concern.
But the same could be said all our experimental and informational RFCs. 
 Should we insist that all experimental and informational RFC, even 
from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
Repeated multiple times to make sure folks do not miss it?
(remember, Independent Submissions are never standards track documents.)

Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.
While it is important to note when experimental or informational 
documents have had community review, and when they haven't, I do not see 
that the distinction, for these documents, warrants denigrating outside 
comment and input.
Remember also that in terms of the text being a recommendation, this is 
not a change in practice.  This is the practice we have had for more 
than the last 15 years.  If, for Independent Submissions, it is that big 
a problem, I would expect ot have heard of it.
Also, to pick up a comment from Robert, and reinforce and answer from 
John, in providing an IESG note for an Independent Submission, the IESG 
is not shining the light of IETF consensus (rough or otherwise) on the 
document.  While I strongly respect the IESG judgment, and want them to 
keep using and applying that judgment, I do not think it fair to 
conflate that with reflecting IETF consensus on something where there no 
source for such consensus.  (For clarity, I do want the IESG to have the 
opportunity to make their recommendation, and I want it taken serious by 
the ISE / RSE.  This is because they do have a view of the IETF activity 
picture, and can provide necessary perspective and judgment about the 
relationships among the moving parts.  But let us not induce confusion 
by assigning that judgment inappropriate grounding.)
Yours,
Joel

Adam Roach wrote:
> I have a serious concern about the impact of this decision and the 
> perception of RFCs by the community that uses the output of the IETF.
> The IETF process has a number of very strong safeguards in place to 
> ensure that the protocols we publish have certain levels of quality and 
> safety built in, and the Internet community at large has grown to 
> associate that level of quality with the RFC series.
> While the presence of alternate streams of publication doesn't bother 
> me, I think they need to be automatically and prominently marked as 
> being something other than an IETF document.
> In particular, when a user accesses a document at a url of the form 
> <http://www.ietf.org/rfc/rfcNNNN.txt>, there is going to be a strong 
> presumption on their part that the document was produced by the IETF. In 
> the cases that this presumption is incorrect, it seems tantamount to 
> deception to tuck the distinction between IETF and non-IETF documents 
> away in an obscure header field.
> /a
>
> Jari Arkko wrote:
> > I would like to get some further input from the community on this draft.
> >
> > But first some background. This draft was brought to a second last 
> > call in June because several IESG members felt uncomfortable with the 
> > IESG notes being used only in exceptional circumstances. I asked Russ 
> > to prepare the -07 version. This version allowed notes to be used at 
> > the IESG's discretion and suggested that the linkage (or lack thereof) 
> > to IETF work would typically be explained in the note. This version 
> > was taken to the second last call.
> > While the number of comments we received was small, after the last 
> > call was over I determined that the consensus was against this change. 
> > As a result, I asked Russ to prepare the -08 version. This version 
> > goes back to the "exceptional" wording from -06, but incorporated a 
> > number of editorial corrections that had been made in interim. I also 
> > took the draft back to the IESG telechat last week. The IESG was not 
> > extremely pleased with the new version, but my understanding is that 
> > they were willing to accept the changes. However, a new issue was 
> > brought up: one of the changes that Russ and I felt was editorial 
> > highlighted the fact that the document makes the IESG notes a 
> > recommendation to the RFC Editor, not something that would 
> > automatically always be applied to the published RFC. Some IESG 
> > members were concerned about this, and preferred the latter.
> > And now back to the input that I wanted to hear. I would like to get a 
> > sense from the list whether you prefer (a) that any exceptional IESG 
> > note is just a recommendation to the RFC Editor or (b) something that 
> > is always applied to the published RFC. Please reply before the next 
> > IESG meeting on September 10. Some e-mails on this topic have already 
> > been sent in the Last Call thread -- I have seen those and there is no 
> > need to resend.
> > (For the record my own slight preference is b. But I have to say that 
> > I think the document has been ready to be shipped from version -06, 
> > and its unfortunate that we're not there yet, particularly since this 
> > document is holding up the implementation of the new headers and 
> > boilerplates system for independent submissions, IRTF submissions and 
> > IETF submissions. I will exhaust all possible means of getting this 
> > approved in the next meeting, as soon as I know what the community 
> > opinion is.)
> > Jari Arkko
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf