Subject: [yam] Request for comments: Working Group procedure

From: S Moonesamy <[email-masked]>
Date: Mon, 19 Oct 2009 10:48:29 -0700

This is a follow-up on the message [1] I posted about 
draft-ietf-yam-rfc1652bis-pre-evaluation-00 on October 15th.

All the IESG comments except for Lisa's point (see my previous 
message) have been addressed.  The latter is relevant to the 
procedure followed by the Working Group and future pre-evaluation I-Ds.

Now that I have more information about the procedure to be followed 
by the Working Group, I'll elaborate on it.  A pre-evaluation 
Internet-Draft is submitted and the WG is asked to comment on 
it.  There is a WGLC for the pre-evaluation I-D.  I write a 
deployment report for the document being revised.  If there is WG 
consensus about the pre-evaluation I-D, the WG Chairs request an IESG 
Evaluation of it.  The way the evaluation is handled ("Management 
Item") is an internal IESG matter.  The IESG issues a statement about 
the specification being evaluated.  The WG decides what to do about 
any issues that may arise.  There is another WGLC if there is an 
updated document.  The WG submits the document for an IETF-wide 
Last-Call and the normal process is followed.

Please review what Lisa said [1] about security considerations and 
post your comments to this mailing list.

Regards,
S. Moonesamy
YAM WG Secretary

1. http://www.ietf.org/mail-archive/web/yam/current/msg00130.html

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 13:54:55 -0400

> Please review what Lisa said [1] about security considerations and post your
> comments to this mailing list.

What I think, and what I've said all along, is that it's reasonable
for the IESG to require updates to the old documents to address modern
concerns, and necessary for the WG to do them.  That may, in some
cases, involve nothing more than explaining why the protocol shouldn't
be changed now, but it's still important to call the issues out.

To strain the "low-hanging fruit" metaphor, I don't think anyone
expects us to rent a cherry-picker, but we might sometimes need to use
a step-stool.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Oct 2009 11:18:41 -0700

S Moonesamy wrote:
> Please review what Lisa said [1] about security considerations and post 
> your comments to this mailing list.

    'My point, now that I've figured out how to explain it, is that
    if the WG wants to avoid late surprises, it will cause the IESG
    to think about whether the security considerations need to be
    upgraded,'

Lisa is raising a completely open-ended concern.  Hence, we cannot know what 
will satisfy her.

That said, we probably can and should take a step back, for each specification 
we touch, and ask some basic questions about utility and safety.  Even if 
something is heavily used, it is reasonable to ask whether the usage is 
sufficient, the dangers are sufficiently problematic, and the like.

Going from Draft to Full is not intended to entail a technical review, but it is 
still worth taking that extra moment to consider first principles briefly.  Not 
in detail, but enough to let any glaring issues get stated.

With respect to security, for this extension, I think the citation to text in 
RFC 1652 text, works just fine.

On the usage side, again, I think SM's suggested text works.  The extension is 
heavily used and that use is widely acknowledged.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Oct 2009 11:23:00 -0700

> be changed now, but it's still important to call the issues out.

Even in the constrained terms you put it, you are permitting quite a bit of 
additional work for getting from Draft to Full.

d/

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 14:25:54 -0400

> additional work for getting from Draft to Full.

Yes.  I consider it important.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Oct 2009 11:33:07 -0700

> Yes.  I consider it important.

Folks,

So, I think this defines a significant disparity on a significant issue about 
the basic process of going from Draft to Full.

As such, it ought to get some focussed discussion by the group.

d/
-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Mon, 19 Oct 2009 15:22:54 -0400

Dave, we've always considered the possibility that we may get feedback 
saying that moving a particular RFC to full standard really does need 
more than a minimal amount of work. Isn't this an example of that principal?

And we've always stated that if that happens, at that point the document 
should be removed from YAM's initial charter. Work on it can continue 
"off the charts" as individual work or be postponed until after the 
initial YAM charter is finished, but the YAM WG won't be spending its 
cycles on it during the initial charter time period.

	Tony Hansen

Dave CROCKER wrote:
> 
> 
> Barry Leiba wrote:
>>> Even in the constrained terms you put it, you are permitting
>>> quite a bit of additional work for getting from Draft to Full.
>>
> So, I think this defines a significant disparity on a significant issue 
> about the basic process of going from Draft to Full.
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 15:59:21 -0400

> should be removed from YAM's initial charter. Work on it can continue "off
> the charts" as individual work or be postponed until after the initial YAM
> charter is finished, but the YAM WG won't be spending its cycles on it
> during the initial charter time period.

The difference is that I'm saying that dealing with things like
security considerations should NOT kick the document off the
charter... at least not immediately.

I think it's reasonable that we might get to a point in reviewing and
adding/updating security considerations, where we think it's time to
kick the document off.  But I don't think it should happen just
because we need to contemplate adding a security considerations
section.

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Oct 2009 14:17:52 -0700

Barry Leiba wrote:
> kick the document off. 

I'm going to pursue this for one last iteration, because I'm not sure that the 
underlying principle I'm trying to express is sufficiently clear.

It's entirely possible that I'm being too sensitive.  It's entirely possible 
that the discussion here is too theoretical.  It's entirely possible that the 
dribble of data from the IESG is merely meant as exploration. But I think it's 
worth belaboring the premise of the wg, to make sure that we do not fall into a 
trap of acting like normal wgs seeking Proposed.  That is, I think the crucial 
issue is going to be how /we/ choose to handle the interaction with the IESG.

What troubles me particularly is phrasing like "get to a point in reviewing and 
adding/updating".  This suggests the usual model that working groups have, in 
interacting with the IESG, which is a highly opportunistic and iterative 
exchange, trying to placate AD concerns.  In contrast, interaction based on 
clear principles with consistent application requires a very different style.

My understanding of this wg is that we are trying to establish some principles 
for processing from Draft to Full, and I do not think that goal is served by our 
having a sequence of on-going iterations of details with the IESG.  Just to be 
clear:  It's not that interacting with the IESG is bad; it's iterating during 
each interaction where we are driven by one set of details, then another, then...

When an AD presses for the wg to do more work on one of our drafts, I think we 
have to first be clear on whether the change is appropriate for this stage and 
we have to resist making the change if we believe it is not.

We especially need to avoid iterative negotiation, because it is expensive, slow 
frustrating and, I believe, typically destructive to the real quality of the 
work.  Tolerating such process when going to Proposed seems to be a necessary 
expedient, but I do not understand how it could be appropriate for a 
specification that is sufficiently mature to be worthy of Full.

This is supposed to be a learning and training exercise, and that means some of 
the adaptation needs to be with the IESG.  If ADs can deal with this wg effort 
the same as for ones seeking Proposed, they will not see the inherent difference 
in the work.

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2009 21:25:26 -0400

Ah.  Dave, you misunderestimate my stance.  Thanks for pursuing it to
get to that point.

>> adding/updating security considerations, where we think it's time to

What I meant by this was to address the process BEFORE we take it to the IESG.

What I've been advocating from the beginning is that we should look at
the documents with the current documentation standards in mind.  That
means considering the Security Considerations (and perhaps, though it
seems less likely, IANA Considerations.  If the document has none, or
what it has does not conform to current practice, we add or update it
appropriately, as part of OUR process.

It might be that this review leads us to a point where we think that
the work required to make the Security Considerations acceptable is
more than we want to do, and then we kick the document out.  That
decision may come because we think we can't just say "Go look there,"
and we can't reasonably document security concerns, adding that
current and historical usage demands that this be brought to full
Standard anyway.

I am not suggesting that we should change any protocols to deal with
new security considerations.  And if the IESG comes back to us and
says, "No, we can't go ahead with this because of [X]," we likely WILL
say, "OK, put this one on the other pile," and move on (though I do
think that decision would depend upon what, specifically, the issue
is).  The charter tells us that the default answer would be to set it
aside.

I definitely agree with the consensus when we chartered YAM, that
"battles" with the IESG over each document are not appropriate to what
we want to do.

Now, all that said: consensus when we wrote the charter was NOT to add
or update things like Security Considerations.  I bring it back up now
because we have some early feedback from the IESG, and that's new
information.  It may be that the WG's consensus is still against what
I say above, and that's fine.  I just think we should look at it
again, in light of Lisa's feedback (and I'm sure Lisa is not alone in
what she asks).

Barry

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Oct 2009 02:39:38 -0700

I picked some of the points made during the discussion about security 
considerations.  There is a risk that I mischaracterize your 
comments.  The points I mention are not necessarily the most 
important ones.  The entire message you posted will be taken into 
account if a decision has to be taken.  I'm not providing URLs to the 
messages to keep this short.  If you have any objection or comments 
about I am doing or the way I am doing it, please say so.

Barry: It's reasonable for the IESG to require updates to the old 
documents to address modern concerns, and necessary for the WG to do them.

Dave: Lisa is raising a completely open-ended concern.  Hence, we 
cannot know what will satisfy her.  Even if something is heavily 
used, it is reasonable to ask whether the usage is sufficient, the 
dangers are sufficiently problematic, and the like.  Take the extra 
moment to let any glaring issues get stated.

Tony: We may get feedback saying that moving a particular RFC to full 
standard really does need more than a minimal amount of work.  Work 
can be continued "off the charts".

Barry: Dealing with things like security considerations should NOT 
kick the document off the charter... at least not immediately.

Dave: Make sure that we do not fall into a trap of acting like normal 
wgs seeking Proposed.  I think this defines a significant disparity 
on a significant issue about the basic process of going from Draft to Full.

Barry: "battles" with the IESG over each document are not appropriate 
to what we want to do.  Consensus when we wrote the charter was NOT 
to add or update things like Security Considerations.  I bring it 
back up now because we have some early feedback from the IESG, and 
that's new information.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Oct 2009 13:37:31 +0200

Hi SM,
I don't quite understand the procedure you described:

S Moonesamy wrote:
> Now that I have more information about the procedure to be followed by 
> the Working Group, I'll elaborate on it.  A pre-evaluation 
> Internet-Draft is submitted and the WG is asked to comment on it.  There 
> is a WGLC for the pre-evaluation I-D.  I write a deployment report for 
> the document being revised.  If there is WG consensus about the 
> pre-evaluation I-D, the WG Chairs request an IESG Evaluation of it.  The 
> way the evaluation is handled ("Management Item") is an internal IESG 
> matter.  The IESG issues a statement about the specification being 
> evaluated.  The WG decides what to do about any issues that may arise.  
> There is another WGLC if there is an updated document.  The WG submits 
> the document for an IETF-wide Last-Call and the normal process is followed.

I'm not sure rfc1652bis can serve as a full-featured prototype of what 
we are going to do. In that case, the pre-evaluation I-D only contains 
  added/ removed references. In the general case, the charter 
expressly allows changes that (a) contribute in a substantial and 
substantive way to the quality and comprehensibility of the 
specification, while they (b) don't change the existing protocol. At 
any rate, a second I-D, which will become the final FS, has to be 
actually written. For rfc1652bis it will be straightforward, while in 
general it may require some work. Does that imply a second round of 
WGLC + LC for the second I-D?

> your comments to this mailing list.

I cannot get the point: the text you quoted and the current Section 5, 
Security Considerations, of RFC 1652 seem equivalent to me (up to 
reference changes). However, I think we may treat that the same way as 
boilerplate replacement, can't we?

Text you quoted

  Since this is an extension to SMTP, the main security concerns
  have to do with SMTP itself rather than this document.  The WG feels
  the security considerations of this document will be sufficient for
  Full Standard status.

Section 5 in RFC 1652

  This RFC does not discuss security issues and is not believed to
  raise any security issues not already endemic in electronic mail and
  present in fully conforming implementations of [RFC 821].

I feel particularly dumb today, as I post this stuff. My apologies for 
your time, but I can't reach the cherries :-(

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Oct 2009 08:38:12 -0700

Hi Alessandro,
>I don't quite understand the procedure you described:

[snip]

>I'm not sure rfc1652bis can serve as a full-featured prototype of 
>what we are going to do. In that case, the pre-evaluation I-D only 
>contains  added/ removed references. In the general case, the 
>charter expressly allows changes that (a) contribute in a 
>substantial and substantive way to the quality and comprehensibility 
>of the specification, while they (b) don't change the existing 
>protocol. At any rate, a second I-D, which will become the final FS, 
>has to be actually written. For rfc1652bis it will be 
>straightforward, while in general it may require some work. Does 
>that imply a second round of WGLC + LC for the second I-D?

RFC1652bis is not a full-featured prototype.  The RFC was suggested 
as a "test case" during the YAM Working Group session at IETF 
75.  The matter was discussed on this mailing list after that 
meeting.  The Working Group could have chosen a specification that 
contained changes as allowed by the Charter.  But that requires more 
work and there's no guarantee that the result will be an Internet Standard.

A second I-D will be written for RFC1652bis.  That is the actual 
specification.  There will be a WGLC for it (the second round you 
mentioned). There is a (IETF-wide) Last-Call after that.

>I cannot get the point: the text you quoted and the current Section 
>5, Security Considerations, of RFC 1652 seem equivalent to me (up to 
>reference changes). However, I think we may treat that the same way 
>as boilerplate replacement, can't we?

During the IESG Evaluation, there were some comments from IESG 
members about whether the security considerations in the documents 
this Working Group will be working on are adequate.  Some of these 
RFCs were written before the guidelines for writing a Security 
Considerations section was formalized.  The text I quoted covers what 
the IESG asked.

Lisa used RFC 1652 as an example to explain her point.  The 
draft-ietf-yam-rfc1652bis-pre-evaluation-00 I-D does not contain any 
text about security concerns.  In some cases, we could use some of 
her text as a boilerplate replacement.

>I feel particularly dumb today, as I post this stuff. My apologies 
>for your time, but I can't reach the cherries :-(

If you have any questions, please ask.  I would like the procedure 
(how we are doing the work and not the work must be done this way) to 
be clear to everyone.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 21 Oct 2009 09:02:37 +0200

S Moonesamy wrote:
>> At any rate, a second I-D, which will become the final FS, has to be 

Thanks for the clarification. Then, the pre-evaluation I-D does not 
bear any formal value, outside of the WG: I don't think we can bind 
the IESG to compulsorily approve an I-D, given that they had already 
approved its pre-evaluation and the changes we have carried out were 
just what we had anticipated in it. Of course, they can save us a 
good deal of time and annoyance in case they can anticipate from the 
pre-evaluation that they are not going to approve a specific change. 
However, we don't really need the pre-evaluation I-D to be formally 
approved in order to proceed, do we? As much as we don't, the IESG 
should rather consider the substance of pre-evaluations and not 
bother with their form.

> Some of these RFCs were written 
> before the guidelines for writing a Security Considerations section was 
> formalized.  The text I quoted covers what the IESG asked.

RFCs 3552 and 2223 talk about security considerations sections for 
_RFCs_. If pre-evaluation I-Ds will never become RFCs, they 
shouldn't need such sections. Is it possible that the IESG asked for 
a formal suitability just because they too --like me and possibly 
more-- did not have a clear picture of our procedure?

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 Oct 2009 02:48:37 -0700

Hi Alessandro,
>should rather consider the substance of pre-evaluations and not 

The pre-evaluation I-D is used to communicate with the IESG and to 
avoid "late surprises".  The WG informs the IESG about the changes it 
is considering.  If the IESG approves of them, work continues on the 
document.  It saves us and the IESG time if we are all on the same 
wavelength about what changes should be made.

I'll avoid commenting on whether we can bind the IESG as that's more 
about process.

>more-- did not have a clear picture of our procedure?

The comments from the IESG were about the substance and not about the 
security consideration section for the pre-evaluation I-D.  It is 
about security considerations for RFC 1652bis and the other 
specifications this WG will work on.

The IESG had a discussion about the procedure and the WG Chairs 
received feedback from the AD.  The various parties have a clear 
picture of how they would like things done.  Understanding the 
procedure doesn't necessarily mean that the various parties agree.

If you do not understand Lisa's point, I can ask her to clarify.  ADs 
are busy people and they may not reply immediately.  If you disagree 
with what she said, you have to explain why it is incorrect.  It's 
helpful if you also provide an alternative and explain why it is 
good.  If the WG agrees to that, it then has to decide whether to put 
up a fight if the IESG is unconvinced.

Regards,
S. Moonesamy
YAM WG Secretary