Re: [yam] Status: draft-ietf-yam-rfc1652bis-pre-evaluation-00

[Alexey Melnikov <alexey.melnikov at isode.com>]

Ned Freed wrote:
> > I received some feedback from the Alexey.  I edited the information for
> > this status update.
> With all due respect, I think we're WAY past the point where this 
> degree of
> indirection is anything but a hindrance to forward progress. The IESG 
> needs to
> state, clearly and directly to this WG, what their concerns are.
Ned, this is arguably my fault. I sent a private note to SM and chairs, 
SM reworded my version and I found it to be slightly better, so I told 
SM that he can send out his version.
> > The IESG is fine with all the changes except for the
> > downreferences.  The format is generally Ok, several ADs commented
> > that the pre-evaluation document was useful.
> Well, if that's the case in general, then this effort is effectively 
> over, and
> we might as well disband this group right now and save ourselves a lot of
> pother. Because if downrefs aren't going to be allowed, we're screwed 
> because
> references to things like TLS are never going to make it to standard 
> in the
> necessary time frame.
>
> If this is a more selective thing (and I see no evidence that it is or 
> isn't - the IESG evaluation record is singularly unhelpful on figuring 
> out exactly what
> this downref problem is), then the IESG needs to explain the actual 
> policy
> behindd their selective allowance of downrefs.
Oh, I am sorry. I think I should have been clearer on this. IESG 
specifically talked about downreferences to other documents in YAM's scope.
I believe having a downreference to TLS is not going to be a problem.
> > The following paragraphs are about the process.  The general view was
> > that the IESG cannot really judge the process by doing a simple
> > document.
> And I think the appropriate response to that is, "So what?" We appear 
> to be so
> wrapped up in nailing down every last detail of the process for every
> conceivable document we might consider that we're losing sight of the 
> actual
> goal here, which is to address the minimal set of *technical* issues 
> needed to
> get the various core email specifications to Standard.
I agree.
> > It doesn't make sense to approve extensions first, then
> > run into the possibility of not approving changes to the document
> > being  extended.  The WG should move the main documents first instead
> > of the dependent documents.
> And again, if that's supposed to be generally applicable rule, this 
> effort is
> effectively over.
I wouldn't say it is over, but we will certainly discuss much quicker if 
YAM's process experiment is successful or not.


I am largely agreeing with the rest of your note.