Hi Alexey,
At 22:59 08-06-10, Alexey Melnikov wrote:
And how is this different from the procedure used recently? IESG can
still block (reject) pre-evaluation documents. The major difference
is that there is no public record of which AD raised a particular
blocking issue. With proper IESG review of pre-evaluation documents,
datatracker can be used for permanently storing such comments.
That's a reason to file a DISCUSS instead of taking the "Management
Item" path. Dave commented on the archival which provides a public
record of the changes/non-changes considered by the WG even after the
I-D expires. As there wasn't any blocking issues for the latest
pre-evaluation draft that was processed, I cannot tell what the
record from the IESG end will be like. I agree that the IESG can
still block or reject a pre-evaluation document.
Publication of the pre-evaluation documents as RFCs doesn't change
this agreement in any way.
Ned mentioned that these documents "are essentially a collection of
notes, nothing more". In Appendix B of
draft-ietf-yam-5321bis-smtp-pre-evaluation-05, Barry provided a
detailed list of issues. There was an issue raised during the
Gen-ART review was about the requirements for advancement to Internet
Standard. There are two questions here; the level of detail needed
from outside the YAM WG to understand the issues that were identified
and requirements for advancement. I am not implying that the
pre-evaluation documents are not up to the quality required for
publication. My point is that it would require more effort to polish
each pre-evaluation document.
Referring to Tony's message, we would be changing the
mechanism. Whether this changes the agreement could be subject to
discussion. And the discussion can be a distraction from current work.
One purpose of the IETF LC is to alert wider IETF community about
certain agreements reached in the WG.
The only agreement the YAM WG has with the wider IETF community is
the YAM charter. Anything more than that can turn into a process discussion.
You seem to be implying that there are 3 parties here (YAM WG, IESG
and the rest of IETF community) and that the third party doesn't
need to be involved.
I am saying that any agreement between the YAM WG and the IESG can be
overturned through the IETF Standards Process. The IETF community
would only be a third party which is not involved if they were kept
out of the picture. That is not going to happen as there must be a Last Call.
Besides, there would be IETF LC for the bis document itself. During
such IETF LC any issues could be raised. Making sure there are no
surprises there would be in the best interests of the WG.
There can always be an element of surprise which affects
decision-making based on consensus. It may be in the best interest
of the WG to make sure that there are no surprises. But that best
interest cannot take precedence over the wishes of the IETF community.
In the Charter, there is:
"If the WG cannot quickly reach consensus about further work
on a document, it will drop the documents from its agenda
without further comment or effort."
If the intent was to avoid surprises from the IETF community, it
would have been mentioned in there. I doubt that would fly.
In theory you should be right. But in practice it doesn't work like
this. Some people don't follow the yam mailing list on daily basis
and I don't blame them.
Yes.
I don't understand why you say that. IESG can send additional
statements in addition to approving documents.
I don't see any conflict in this, or any proof that IESG wants to
screw the WG.
I do not believe that the IESG wants to screw the WG. If we want to
have a RFC for archival purposes, we might as well do it with a
proper record of the decision-making, i.e. those are the issues
agreed upon and this is what the IESG has to say.
I am not sure what you are suggesting. Please explain.
See above. This would like the IESG Note from BCP 92.
Regards,
-sm
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
