Subject: [yam] Rough notes for IETF76 YAM WG Session

From: S Moonesamy <[email-masked]>
Date: Wed, 02 Dec 2009 01:18:32 -0800

The YAM Working Group held a meeting at IETF 76 on November 10, 2009.

Agenda:

Nov 11, 2009					75 minutes	0900 - 1015

     Note well				 	 1 minute	0900 - 0901
     Agenda bashing				 4 minutes 	0901 - 0905
     Discuss how our process is working		40 minutes	0905 - 0945
	Alexey Melnikov
	Dave Crocker
     Next Steps					20 minutes	0945 - 1005
	Wither the working group?
	Template changes?
     Any Other Business				10 minutes 	1005 - 1015

The slides can be retrieved at 
https://datatracker.ietf.org/meeting/76/materials.html#wg-yam

Working Group Chair: Tony Hansen
Scribe: S. Moonesamy

Here are some rough notes for the session.  Please send any corrections to me.

9:00 MIC test

The Chair (Tony Hansen) opens the session

Tony: Everybody should have seen the Note Well.  There are two blue 
sheets going around.  Meeting materials can be found on the datatracker.

Agenda for bashing

Scribe walks in the room.

Tony: First question, how is our process working?  Alexey is up first.

Alexey Melnikov: What useful came out of discussions within the IESG 
and the Working Group.  Confusion and other 
things,  process,  emphasize what are a big deal.  YAM WG was 
chartered in April or May.  Nobody from the new ADs understood how 
the process is supposed to work.  Some of the old ADs didn't realize 
either.  There were various discussions about whether current IESG 
members can bind future members.  General feeling was that each AD 
should express their preferences.   Difficult to predict what will 
happen during the various stages as AD collect input from multiple 
sources.  ADs were happy to express their preferences about the document.

Next slide.

Various IESG members commented on the format of the document.  They 
found the format to be suitable.  There were comments on what to 
change.  The major one is to list changes not to be done that was 
dicussed in the WG.  Instead of not mentioning this, it should be 
much better to mention explicitly to bring them to the IESG attention 
so that the IESG can think about them in advance.

During the discussion, the IESG kept shifting from evaluating the 
pre-evaluation document which was simple to more general issues.  In 
particular there was a sentiment expressed that the 8BITMIME document 
was to easy to test the WG.  The IESG is asking the Working Group to 
a pre-evaluation on a more complex document.  The other question 
asked why the WG was trying to do extensions first.  I (Alexey) 
explained that he wanted to try the process first on a simple 
document.  However, pre-evaluation for 8 BITMIME said that we have a 
downref to SMTP.  That is why the question was asked.

Pete Resnick: Clarifying question,  could you go one slide 
maybe?  One more.  The IESG was confused about the pre-evaluation 
process, didn't think they could do this reasonably.  Then they said 
that this was too simple even if they said that pre-evaluation wasn't 
a good thing.

Alexey:  I didn't say that pre-evaluation was a good 
thing.  Everybody on the IESG was trying to figure out how to use it 
best and whether it was suitable.

Alexey:  Dave suggested posting all clarifying questions until after 
the presentation.

Next slide.

We spent some time in the WG discussing about security 
considerations.  The IESG got distracted by discussions about 
security considerations.  The discussions turned into everything that 
could possibly go wrong.  That wasn't really productive.

Next slide.

The agreement so far within the IESG was to process the 
pre-evaluation document as a management item which is basically for 
everything that doesn't fit the standard document review within the IESG.

This is kind of an internal process tool thing

After discussion with the IESG, I had some long conversations with 
various people and it occurred to me that we might end up spending 
more time talking about process.  Originally, we thought that the two 
step process is  going to save time but maybe just using the standard 
single step process may be quicker to achieve the results the WG 
wants which is to move documents to Full Standards.

The other thing is to evaluation whether the two step work is to 
compare it with a normal one step process.  My proposal is to take 
two moderately complex documents and do one using the two step 
process and do the other using the normal process and see whether we 
get variation in speed and try to analyze why.  At least we would 
know whether the process experiment works of not.

That's it for me.

Dave Crocker: First of all I believe any description of the facts, 
the details of the facts afre the same as Alexey.  Some of our 
interpretation are the same.  We are likely to have significant 
differences in the implications in recommendations.  Brief review of 
why I am the one standing here righyt now.  It's partly my laziness 
and partly an accident that led to my being responsible for this 
document.  I don't care about this document, I care about what the 
group is doing.  The tone of the responses we saw from the IESG felt 
more like complaints than efforts to improve things.  It didn't feel 
like they felt that they were participating in a document.  It felt 
like it was a hassle, maybe they were.  It did not feel collaborative.

Very clear statement from IESG members  that they will not be 
constrained by anything in the pre-evaluation phase.  I tried to have 
a debate.  They viewed this as more like an IESG discuss, I view it 
as more like a charter.  These two different perspectives are 
different views on how to proceed.  They are both  based on 
principles and people have different principles they embrace.

The difference in recommendations from what I have from Alexey is 
because Alexey is nicer and more patient.  We have quite a lot of 
data to know that there is nothing more to learn from an 
experiment.  We choose to work on whether to modify the documents or 
we don't.  I'm listing two choices that we can pursue.  There is 
probably a third.  I'll mention it. The third is to push back on the 
IESG in a variety of possible ways, challenge the process, 
whatever.  I think that this is a technically available path.  I 
cannot see in my own mind anything that could be constructive about 
it and off course I think that it would be destructive.  I think that 
if we took the third choice, this would be a social statement saying 
that we would be entering a sttae of war with the IESG.

There is a principle that would cuase us to do that.  The principle I 
think is a perfectly fine principle.  I think that the IESG needs 
it.  I don't think it would be useful for us, the IESG or the IETF to 
do it.  And given that our goal is to move documents, the first 
bullet is my own recommendation which is we have been told what to 
do, let's go and do it.

Tony: Now is the time for the action, mics are open.

Alexey: I would agree that the IESG as a whole disagreed to be 
constrained.  This is in the tracker.  I think there were at least 
six people saying that they are happy with the pre-evaluation 
document modular issues  brought up on the IETF Last-Call.

Dave:  Thank you for saying that.  I did not notice any pattern of 
agreement.  I'm glad to hear that it was there.  I sorry to say I 
must have missed it.  I must stress however that when I am saying the 
IESG, there must be an aggregate reality even if the personal 
realities might be different.  and the fact that some Area Directors 
are willing to be constrained is different than saying that the IESG 
is.  What I think is a fundamental distinction, having them saying 
that  they like us to do it doesn't mean that it achieved the points 
we needed or that it is any way useful for getting documents 
progressed.  The bottom line is that we spent months doing what we 
did and it was rejected.  That's a fairly important status I think.

John Klensin: John Klensin here, there are still things on a 
procedural basis on which Dave and I disagree.  First of all, I have 
a question to ask Dave.  Have the Area Directors that decided that 
they do not want to be constrained been identified by the NomCom?

Dave: for those who cannot see my badge, I have one of those dots.  I 
believe that I am being asked as a NomCom member.  My response is 
that I cannot talk about what we have or haven't done or seen or 
heard or think.

John: Okay, that's a good answer.  I think that we cannot go ahead on 
the basis in which we intended to go ahead, we need to ask ourselves 
a very very fundamental question; it is whether advancing these 
documents is important enough than other work that can get done.  We 
need to ask this question against the backdrop of individual IESG 
members holding documents for long periods of time because of some 
hobby horse that hey mounted very late in the process and without any 
justification from IETF Last-Call.  I think that we need to 
understand that if we are changing the process that it needs a major 
charter revision if we actually going to follow what the existing 
charter is.  and it makes a very strong argument for our, assuming 
that this working group is currently chartered, under the assumption 
that the charter needs to be abandoned, we need to make a decision 
about whether or not the work this working group was supposed to 
accomplish is appropriately chartered to be carried out under the 
current rules under which we do standards work and then throw 
ourselves at the IESG's mercy.

Dave:  Dave Crocker jumping in only because.  I just realized that I 
left an important half.  As member of the NomCom, I need to say that 
if you think that there is feedback that NomCom needs to have, please 
provide it to the NomCom.

Barry Leiba:  Jabber chat has been off for a while.

Several comments, I did not really get the feeling from talking to 
Alexey and some of the other ADs that they ADs were worried that this 
would bind them to a future position, so much that they were worried 
about this would bind future IESGs if, say Lisa agrees to something 
and in March someone comes in.   my comment for that point are that 
the [position seems correct  for most documents that should go 
through the IESG into the standards process.  I think that this is a 
different case of advance a mature document to Full Standard.  I 
think that in that case saying that we see the maturity of the 
document and we are committing to something.  I see the chartering 
process where the IESG by approving the charter binds future IESGs to 
this charter.  Another AD cannot come in and say that I did not 
approve this charter.  That may be worth Alexey take that back to the 
IESG as a comparison.  The combination of the issue of how we do 
charters and that these are mature documents that we take to the last 
step is the key to me.   John said that we need to look into whether 
it is worth our time doing this if we have to do it in a more busy 
way or whether we should be spending our time on something else.  My 
view on that is whether it is worth doing this or whether it is worth 
revising the Standards Process so that we stop doing this.  I think 
that we should do one or the other.  I don't think that we should say 
that it is not worth doing this and go away.  Now, I do know that 
people have brought up the idea of revising the Standards Process 
before and it gets into a blackhole.  But I think that it really 
needs to be pushed if it is not working. I expect comments on that 
point.  On the comments that we spent months doing this and it was 
rejected, I'll only say that if this is an experiment, we are part of 
the experiment as well.  If we have to expect that the IESG is going 
to do somersaults and stand on their heads, then we need to do that 
also.  And that may involve getting some of our ideas rejected.  I 
don't think that's necessarily a bad thing if we can work it out in 
the end.  Can you put up Dave's last slide please?  On the point of 
feeling hassled, that the IESG felt hassled, that it was not a 
collaborative response, in a sense I think that it is a little bit 
fair.  There was confusion about the initial document that made 
people think that they were wasting their time reviewing a final 
document when it wasn't.  And the IESG is very busy and this is an 
extra step in the process.  I can see why they might feel hassled. 
and the fact that this is an experiment doesn't make me worry too 
much about that response.  On Dave's last slide, the two choices, I 
think that there is a third choice which is to do as the IESG 
suggested and try this again with the SMTP document, continue the 
experiment with the main document rather than continuing with the 
main document abandoning the experiment.

Pete:  I will preface this by saying that this will be somewhat less 
than productive because I don't have an answer to Dave's last point 
of what the working group should do.  I am exceedingly annoyed.  What 
I am annoyed about is that what Alexey identified from the IESG 
seemed uniquely tied to the procedures and the rules and the tools 
that the IESG uses.  We went into this experiment saying that we are 
going to do something differently and the IESG's complaint seems to 
be that you are doing something differently.  That's hard.  You know 
what, it is hard.  Part of the problem here we haven't moved anything 
to full standard in this organization in a long time.  It's not a 
regular process.  And the IESG is sitting on the process that gets 
documents to proposed standards and sticks them there.

(comments about EPPs from the room)

John: and even that is not the question as EPP serves a small 
community that is uncontroversial in that community and nobody else 
(cares).  I work in that community, I know where the controversies 
lie.  The point is that it is an entire different situation.  For 
example, for the emaill protocol on which everybody in the IEFT who 
works with email has opinions, and some of the participants in the 
IETF including some ADs believe that there are experts because they 
are using email.

Pete: What bothers me about this is that the IESG interpreted this as 
constraining future IESGs.  You know what, moving something to draft 
standard constrains future IESGs.  Making the charter constrains 
future IESGs.  Doing all sorts of things constrains future 
IESGs.  They have to get power it.

John: Historically, no they don't

Pete: Point taken.  They don't have to get over it.  On the other 
hand, part of the reason we went down this path is that we knew that 
if they did not try to get over it, we were just going to be hassled 
from now till the end of time.

Barry: I rephrase that they have to get over it as it is in the best 
interest of the IETF for them to get over it.

John: It is the best interest of the IETF to get over it and since 
the IESG has also refused to consider any proposal to change the 
standards process, so that we do not in principle need to do this, 
they are basically saying no don't do this and do do this.

Dave:  You guys seem very upset by this.  I do not have much tendency 
to be upset by the IESG's behavior and I do not understand this.  The 
IESG has a long pattern of behaving in a certain way.  And I am sure 
that a lot of it needs to be changed.  But we are a working group and 
we have work to get done.  I think that it is just fine to pursue the 
larger goals.  But that is not the working group's job.  The working 
group might provide input to it.  I think that we need to discuss the 
larger issues carefully.  I think that it does not need to become 
what the Working Group is.  What it should become something somebody 
does, fine.  I could even participate.  But the IESG is what it 
is.  My reaction to seeing the IESG's responses is that it was 
entirely predictable.  It matches the kinds of things they have said 
many times over the years about not being constrained ahead of time 
by things they might do during a Last-Call.   And yes, we wanted to 
see whether we can change that and I think that we have full data on 
that and I don' think it is going to change with anything this 
working group will do within this working group.  Should it be 
changed?  Of course it should.  I tried to raise the issue with the 
distinction between the chartering process; that's a constraint on 
future action by the IESG, I tried to take the view of what we were 
doing is a version of contracting which is what a charter is and the 
response back was that this is more like a Last-Call.  I tried to set 
up a little table and present it but it didn't work.  Okay, that was 
a fun academic exercise but the result did not surprise me.  And if 
people in this group want to form a coalition to pursue the offenses 
that have been committed, I'll probably participate.  But I do not 
think that this working group should be distracted from the goal of 
this working group.  One of the comments that was raised, and I will 
note that one of the comments from the IESG is that they got 
distracted by focusing a lot on process is that I'd rather not get a 
lot distracted by process.  And yes, our charter says that we will be 
doing the pre-evaluations.  Within the history of the IETF, it is 
pretty common for these variations to occur.  We just go and do the 
actual work.  I don't think it is worth the effort to recharter to 
get rid of the pre-evaluation.

Alexey: Specifically regarding rechartering, if the working group 
wants to use a one-step process, the normal one, I don't think you 
need to recharter.  The IESG is not going to nit-pick on this point.

John: some of us would probably appeal that decision.

Tony: appeal what decision?

John: decision to proceed with this charter but with a single step 
process without the pre-evaluation.

Alexey: if that is the case, I'll force the working group to recharter

Barry: if I understand what you are saying, if the chairs decided to 
proceed without rechartering, you would go to the IESG.

John: let me back away for a moment from the hard line of taking the 
hard line position about this and suspend disbelief and try to put 
myself in the framework that Dave is arguing for.  Unless the test 
document which is small and non-controversial, some of these 
documents are large and complex.  When we attempt to open them, and 
SMTP is certainly the test case, the activity of opening them draws 
flies.  And I have no reason to believe that it would not happen if 
we open 5321 under the conventional process.  I have every reason to 
believe that everybody who was told, no you cannot do that at this 
stage of the Standards Process the last time around, a process that 
was advertised as quick into a painful extended process.  I have no 
reason to believe that people who try to do it again.  I have no 
reason to believe that if we go to the standard model that we will 
not have to figure out a way to process and consider each and every 
one of these inputs.  Less the people reappear on last call and claim 
that we have blown their inputs and find an IESG member who thinks 
that he or she is an email expert to argue that we should go back 
post Last-Call and review those things and do another 
Last-Call.  Given that situation, the question here is about whether 
all the various things that most of us could be working on within the 
IETF and their importance whether it is worth reopening these 
documents to bring them as Full Standards which as far as I am 
concerned, the IESG is telling us that they are not very interested 
in.  I don't know and speaking very personally in the context of 
5321bis, I would argue that the answer is no.  The email 
internationalization work is more important.  Some of the other 
things I am trying to do are more important.  I have got a limited 
number of IETF cycles.  I can turn over that document to somebody 
else but the same issues would apply.  People who can do this work 
are relatively scarce in the community.  If the IESG wants to do this 
stuff on the kind of constrained expedited fast track model that we 
had proposed, I think that's fine.  If the IESG is not interested in 
doing that I have a really hard time arguing that bringing these 
documents to Full Standards against an IESG that is not really 
interested in Full Standards except insofar that they get to second 
guess everything every time a document comes to them, I don't think 
that it is worth doing.

Alexey: Okay, I'll do it anyway.  Three quick comments, first during 
the IESG retreat this year, we actually discussed why moving 
documents to Full Standards is so difficult.  The reason is a quite 
strong feeling within the IESG that helping to move documents to Full 
Standard is important.  It doesn't answer the question of how to do 
this.  But there is general feeling that the IESG would still needs 
to help with this

Second, I understand the feeling that if we are going to try to move 
SMTP using Standard Process that it might encounter the same problems 
as moving to draft.  However, I think that certain things were 
changed since the document moved to draft.  Two of them come to 
mind.  First, probably two third of the original IESG reviewed this 
document and probably voted on it for draft.  So if we do it quickly, 
within six  months, I think that it would be much easier.  The second 
part is actually doing this in a working group is much easier to 
judge consensus.  That helps as well.

John: Quick response as Alexey's comment was pretty much addressed to 
me.  Do keep in mind that in that approval process with the existing 
IESG that several of the members agreed to change their votes and 
discuss no objection condition to changes being made if this went to 
Full Standard.   If we ever propose this to Full Standard and getting 
another whack at it.  in which they refused to constrain themselves 
to whacking.  So you may be right.  But it may also be the same 
people who tried things the last time will turn around and drag 
things out again because they have explicitly claimed that they would 
drag things out again and reserve themselves the right to do 
that.  So I do not know how to make that prediction.

Tony: Just a quick time check, we have 23 minutes left.

Pete:  We'll try anyway.  The problem with being third in line is 
that things get said beforehand.  The thing that I am running into is 
this word constrained, again and again, and I don't know how to 
unwedge this.  The response I had to Dave's comments were that if not 
know, if not when, I do not remember what the story is.  But I feel 
like the whole reason we went through this chartering process, the 
reason we spent any time going through this chartering process is 
because we wanted to get some buy-in from the IESG that claims that 
it is a problem that things do not get to standard.  for them to join 
with us to figure out a way to get to standard.  If the IESG says 
that we need to change the way we get things to standard and we make 
a suggestion, then they say we are not going to try that.  And they 
are not going to give us another way to do it, they have yet to say, 
here's a different procedure to do it.  I have less of an issue with 
this than John does because there are less controversial changes in 
5322.  Some changes need to be made but they are less of them.  But I 
am uninclined going down this path to spin my wheels in the endgame 
because the IESG won't do some work up-front.  The IESG as fall as I 
can tell on this issue have not done any work to figure out what 
procedure they want to do.  They want to stick with old 
procedures.  That's what they have claimed.  and unless the IESG is 
willing to do some work here, In this specific instance, I do not see 
the point of us going forward.  We can do this as individuals without 
the working group.  I do think that it is worth getting things to 
standard.  I really do.  But I do not think that we spin as a working 
group if we are going to end up spending more time as editors in the 
end game process which is where we spend up most of out process time 
when we use the standard process.

Dave: I do not know why I am acting this way but I really find it 
delicious to feel that I am the subdued one here.

Barry: because you are not raving doesn't mean that you are subdued.

Dave: But inside I am feeling subdued. honest to goodness.  I want to 
repeat just one thing that I said at the beginning.  I think that 
there are some facts in front of us.  And I do not disagree with any 
of the facts including the facts about the process and the facts 
about the IESG.  I think that the disagreement is about how to 
proceed.  And I would like to suggest that people start making 
comments about how to proceed in a concrete way.  I want to make two 
comments, the second is not about how to proceed, it is a 
clarification about a point I mentioned.  The first is to respond to 
a hardline point.  This is a working group that is a small group of 
people trying to do a particular piece of work.  This is not a group 
that was formed or in my view sufficient for effecting revolutionary 
change with the IESG.  Do I think that this change is needed?  Yes, 
but this is not the point.  The point is this working group is trying 
to do some real work.  I recommend, here's the hard line part, that 
if anyone attempts to turn this working group effort into a political 
issues, that we vote to disband immediately.  I think that pursuing 
the political issue outside of this working group can make a lot of 
sense.  But within the working group and part of the working group, 
no.  That's the hard line.  Now I will move on to the other 
clarification.  We said the pieces of this but I want to focus on 
it.  The IESG's history is of doing proposed standard.  That is their 
hammer, everything is therefore a nail for that hammer.  They have 
done a little bit of other things, going to draft, going to 
full.  But that is not really in their model and I viewed the 
comments from them as fitting into the issue of going to 
proposed.  And do I believe that this is for Full, sure.  Do I 
believe that they have a model going to full that is different from 
going to proposed, no, I don't.  Would it be nice to change that, 
yes.  That's essentially the template which we tried.  I do not 
believe that we can educate or change the IESG.  I believe that they 
can be changed.  But I do not believe that this working group is 
going to do that.  And I think that this working group, as a working 
group to get some documents to full needs to not complain about the 
IESG, not try to change the IESG but either decide to fit within the 
reality of the IESG or disband.

Barry: So I'll start with that one.  I disagree with you Dave on one 
point when you say that this Working Group has some work to do which 
is to advance this to standard and not do do other stuff.  No, we 
specifically chartered to experiment with a new process for doing 
that and I think that is part of the work of the working group. I do 
not think that we are done with that experiment.  Pete said that the 
IESG has not responded to the process issues.  I think they 
have.  And they have asked us to try it with something else.  My 
concrete proposal of where we should go is that we should do 
that.  We should take SMTP.

Pete:  Dave said we want to try the two-step again with a different document.

Barry: And I think that is what we should do.  My suggestion is that 
we take them at their word and continue the experiment and do this 
with SMTP and see where that goes.  With 5322.  I would do it with 
5321.  If John has for whatever reason the need to pass the document 
off, I would be happy to volunteer and take it.

John: First observation is that I think that the experiment is worth 
trying.  I'm very pessimistic about it but I think that it is worth 
trying.  Tony has in hand a draft template which we can probably put 
in the current form and current template relatively quickly.  and it 
probably worthwhile given that that work has been done to hand them 
SMTP and see what happens.  But beyond that I strongly agree with 
part of what Barry said  that we went into this process with a 
certainty that there was a certain amount of work involved with a 
feeling that we would not do that work unless we could reach a prior 
agreement with the IESG about what the balance of that work was or 
what they were going to demand.  and if that agreement is not 
possible, then again, I think that we need to review the question 
whether this is worthwhile.  Now, as far as turning things political 
or not, we specifically proposed in this charter a specific way of 
advancing these things in part because some of us did not think that 
this would be worth advancing if it was done in the traditional 
fashion.  The reason I made the comment about appealing is that if we 
decided to go through with the other process in the existing charter 
is to take the question of whether the IESG gets to behave in a 
fashion in which the effective message of moving complex documents 
about which the community cares to Full Standard is no, you cannot 
try your deviant process and we won't let you do the other process 
and we won't make any suggestions about what you should do 
instead.  The nature  of turning it into an appeal is to open that 
question up to the community and get it out of the working group.

Tony: Last comments and I am going to call for a hum.

Barry: Barry with a comment and then I am going to channel Chris.  I 
am ambivalent about the value of the three-step standards track.  The 
reason I think that it is important to take 5321 and 5322 to Full 
Standard is that 821 and 822 are full standard.  and I want to get 
the current versions at that same level.  I think that this is an 
important thing.

Chris Newman (via jabber): Speaking as an individual: if we 
re-charter, I would like the pre-review replaced with text providing 
equivalent functionality.  Here's a first draft: When the WG attempts 
to move a document from draft to full standard it will only make 
minor technical corrections deemed necessary to better align with the 
installed base.  In the event changes the WG believes have a 
substantive risk of breaking backwards compatibility are deemed to be 
blocking by the IESG, the WG will remove the document from processing 
and its charter.  In the event all documents are removed from the WG 
charter, the WG will write a narrowly drawn update to RFC 2026 that 
eliminates the third level of standard; this update document is 
forbidden from making other changes in the standards process.

Chris: Presently, I support continuing with the pre-review experiment.

Alexey:  That is excellent.  You know, I actually am tempted to 
recharter with this text.

Tony: This is a multivoting step.  Find the sense of the room, a four 
way hum, do you want to disband, do you want to recharter to a 
one-step process before continuing, do you want to continue working 
but do as Alexey suggested in his original slides and do one step 
versus two step comparison of two different documents or do we 
continue with the current course on the next set of documents in the 
two step process?  Now comments on the four way hum before we hum.

Dave: You left a bullet off.

Tony: I did, okay.

Dave: and it is a bullet which some of us said would be 
reasonable.  And Alexey said that he would be reasonable which is to 
continue a one-step process without rechartering.

Dave: Work on comparison is about working on comparison   I am 
talking bout just doing the work.  Not doing an experiment.  I was 
not suggesting that you change any of the other bullets.  I said that 
you left one off.  So undo undo undo.

John:  I'd like to suggest a slightly different refinement.  I 
suggest that we go ahead and put the template for 5321 into the 
harper as it is the most complex and probably the most controversial 
document we've got which responds directly to the IESG's request to 
do that.  If the IESG takes a look at that and responds that as the 
original charter and the assumptions behind it, we simply move 
forward as we expected to move forward.  Consider the current 
situation as a bump on the road that is easily forgotten.  If the 
IESG responds to that template by saying yes this looks find but we 
reserve the right to make any changes we want or any demands we want 
during and after last call, then we disband.

Pete:  That's exactly what I was jumping up to say.  That is a 
variant of the last bullet.  One other variant is for instance 5322 
which is a big ugly document but not as controversial.  I guess the 
question is are we going to get to the point where if bullet number 
four is the hum, do we take these things in order or is there a dependency?

Tony: Actually I think that all three could be done in parallel.

John:  The argument for 5321 is that because 5322 is lower 
controversy, we could find ourselves doing 5322 and learning as 
little as we have learned from 8BITMIME.

Pete: Let's have the hum and then have a discussion about the 
relative controversy about what we should do.

Tony: Time check, we have six minutes.

Dave:  I want to suggest changing the humming process because the 
classic problem of making list of decisions is that it is not quite 
the right one and I know that you are trying on it; it's not a 
criticism, it is the nature of the challenge and I suggest that we 
establish this as a sequence of hums.  The first is disband or 
continue.  The second is keep the charter or revise the charter.  And 
the third is depending on the other one, is what to do if we keep the 
charter or what do do if we change the charter.

Tony: I'm going to push back on that.

Barry: I think that whether it is a one-step or two -step process is 
rather germane whether we recharter or not.

Tony: Okay.  This is a multivote hum. I want to get a sense of the room.

Alexey:  We have so little people in the room, can we raise hands?  I 
don't want hums.

Tony: Okay, who wants to disband?

Tony: Who wants to flat out switch to one-step process whether we do 
a recharter or skip the recharter?  One.

Tony: Who wants to follow Alexey's original suggest of doing a 
comparison step with two documents, one that does a one-step process 
and the following does a two-step process?

Tony: I thought that would get some votes.

Tony: Who wants to continue with the two step process for the next 
couple of documents?

Tony: And all the rest of you are evidently are abstaining.

Tony: Now that we have three minutes left or two minutes, we will not 
really have time to discuss specific changes to templates that came 
up on the list.  Chris posted these suggesting two explicit changes 
and there is a metacomment that should be posted to the group.

Tony: There are three documents that are in the harper now.  that we 
have agreed last time that would be the next set of documents, SMTP, 
Mail Format and Submit.  John sent me a pre-version of the template 
for 5321.  I asked Randy to do one and he said that he would be able 
to get into it in about three weeks.  And I have not heard anything 
yet from Pete yet, so.

Alexey: Does Submit normatively depend on SMTP?

Tony: Yes

Alexey:  This reduces this set to two basically.

Pete: Let's be clear, the bottom of the normative dependency list is 
5322 because 5322 does not have a dependency on 5321.  If we want to 
try uncontroversial first with the IESG then we do 5322.  And we say 
here is a big document but it should not cause you any problems if 
you can't get over 5322, giving them 5321 is absurd.  If we can get 
through 5322, they got through the template and say that we can 
approve the template for some value of constrained that makes us not 
as miserable or we do not use that word or whatever it is then the 
idea of trying 5321 is plausible .  If they are simply not to be able 
to get over the process point, if they are simply not to be able to 
deal with the idea of dealing with a template and giving some sort of 
approval to that template, then we should disband.

Tony: We are officially out of time.

John: The counter argument very  briefly is that we got a template 
for 5321.  We turn that into a template that can be posted in a 
matter of half and hour.  They've asked for 5321.  The experiment 
represented by the difference of opinion between Alexey and I about 
the state of 5321.  It is a very interesting an important one.  The 
template for 5321 recognizes all the promises which the IESG probably 
believes was made to them the last time around.  The very important 
experiment with 5321 isn't the nature of dependencies, it's the 
nature of controversies.  But it is more or less whether the IESG 
specifically asked for some changes when 5321 was approved will 
decide whether that's all the things they have to ask for because 
that's already in the template.  Although they start asking for 
something else, that's really important information for us to 
have.  I don't care.  From my point of view, if we want to sit on 
5321 till 5322 is ready and then submit both templates at the same 
time, I'm fine with that.

Tony: Do we want to have a quick hum?  Whether to reach 5321 first.

Dave: We have voted a path to follow and I want to suggest that we 
have two things in mind, one is that doing anything that relies on a 
particular set of people  being in the IESG such as the current group 
rather than the next group strikes me as fragile and it's not the way 
we have to think.  Even though it might be an experience that might 
work.  But that just adds more risk and we already have a complicated 
situation.  The second is as people think in terms of doing things 
that would constrain the IESG, that the IESG would agree to be 
constrained by.  Please let me know if you know if there has ever 
been any decision by the IESG other than chartering that the

(end of audio)

The Chair asks for a raise of hands on doing 5322 only, 5321 only and 
for both documents.  There was no consensus.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 02 Dec 2009 20:12:52 +0100

S Moonesamy wrote:
> [...]

+1, fwiw. I feel 5321bis as the most exciting target, and that's why I 
subscribed to the yam list.

IMHO, putting forward 8bitmime has been wisely careful, but it 
resulted in a 90%-boilerplate pre-evaluation, which may partially 
justify IESG's reaction. The WG can pursue the 2-step experimental 
process even without full IESG's cooperation --since we don't formally 
need their approval for those drafts-- and eventually present the 
final result as if it were produced by a 1-step process: In any case, 
the 2-step experiment will have been carried out, with visible results.

---

From: SM <[email-masked]>
Date: Sat, 05 Dec 2009 12:11:33 -0800

This amended version of the rough notes posted on December 2 includes 
changes sent by Dave Crocker.

Agenda:

9:00 MIC test

Agenda for bashing

Next slide.

discussed in the WG.  Instead of not mentioning this, it should be 

Alexey:  Dave suggested to postpone all, even clarifying questions, 
until after Dave's presentation.

Next slide.

Next slide.

That's it for me.

Dave Crocker: First of all I believe any description of the facts, 
the details of the facts that I may come up with, that I will come up 
with are exactly the same as Alexey's.  Some of our interpretations 
are the same.  We are likely to have significant differences in the 
implications in recommendations.  Brief review of why I am the one 
standing here right now.  It's partly my laziness and partly an 
accident that led to my being responsible for this document.  I don't 
care about this document, I care about what the group is doing.  The 
tone of the responses we saw from the IESG felt more like complaints 
than efforts to improve things.  It didn't feel like they felt that 
they were participating in a document.  It felt like it was a hassle, 
maybe they were.  It did not feel collaborative.

A very clear statement from IESG members  that they will not be 

it and of course I think that it would be destructive.  I think that 
that we would be entering a state of war with the IESG.

There is a principle that would cause us to do that.  The principle I 

Alexey: I would agree that the IESG as a whole disagreed to be 
constrained.  This is in the tracker.  I think there were at least 
six people saying that they are happy with the pre-evaluation 
document modulo issues  brought up on the IETF Last-Call.

feeling that we would not do thyat work unless we could reach a prior 

Tony: I did, okay.

Tony: Who wants to follow Alexey's original suggestion of doing a 
comparison step with two documents, one that does a one-step process 
and the following does a two-step process?

Tony: Yes

(end of audio)

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Ned Freed <[email-masked]>
Date: Sat, 12 Dec 2009 19:17:10 -0800 (PST)

> subscribed to the yam list.

I will again repeat that 5321bis moving from draft to full is not a time for
lots of changes of the sort that you seem to be after. Indeed, there is
substantive risk with the present course continues 5321 will become ineligable
for processing under the rules for this WG.

> justify IESG's reaction.

Nonsense. Had the IESG objected to the boilerplate nature of the pre-eval, they
could have, you know, actually reviewed the document and found the actual
problems it contained that weren't addressed in the pre-eval. They did nothing
of the sort.

> The WG can pursue the 2-step experimental

I myself am not so optimistic. But there's no need to speculate - we run the
process and see what happens.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 13 Dec 2009 11:02:03 +0100

Ned and all,
Ned Freed wrote:
> I will again repeat that 5321bis moving from draft to full is not a time 
> for lots of changes of the sort that you seem to be after. Indeed, there is
> substantive risk with the present course continues 5321 will become 
> ineligible for processing under the rules for this WG.

I think the community expects a Full Standard that will provide 
consistent and unambiguous reference for the years to come. We are 
all committed to fulfill that expectation. I try and only consider 
changes that improve the clarity of the spec, without altering the 
protocol unless they are already deployed by commonly used 
implementations. That sort of changes are apparently allowed in the 
charter, so where does the risk of ineligibility originate from?

For example, I recently complained about apparently prohibited 
header changes that seem to formally relegate mailing lists with an 
added header signature, and newsletters with personalized 5322.To, 
out of SMTP scope. Either I got it wrong or that snippet needs a 
fix. Moving from draft to full is the last chance for fixing it, in 
case. Therefore, I felt a compelling obligation to bring it to the 
WG's attention. Should I have put that down?

I do my best to be as flexible and conciliatory as possible, 
reasoning that if my opinion differs from that of the WG, it is 
probably because I'm missing some point. Trying to understand that 
point may occasionally make me appear insistent. I apologize for 
that, but please don't mistake that behavior for insolence or denial 
of consensus.