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

[S Moonesamy <sm+ietf at elandsys.com>]

Hi Alessandro,
At 04:37 20-10-2009, Alessandro Vesely wrote:
> 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