[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[yam] Comments on draft-ietf-yam-rfc1652bis-pre-evaluation-00



draft-ietf-yam-rfc1652bis-pre-evaluation-00 was evaluated again by the IESG today ( https://datatracker.ietf.org/idtracker/ballot/3211/ ). The discussion was about the process to be followed. I am waiting for more details from Alexey Melnikov before posting about that.

There is a comment from Lisa Dusseault about security. Please refer to the text below instead as it reflects the current status:

  '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, rather than omit talking about them in the "pre-evaluation"
   documents.  Otherwise, security considerations are still likely to be
   the cause of late surprises.

   In many cases, as in 1652, the content could be very brief.
   E.g. "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."'

There was a comment from Adrian Farrel that "The universal deployment of this feature is well-known" in the I-D seems like an exaggeration. Based on feedback from John Klensin and Tony Hansen, it is suggested that a sentence similar to the text below be used in other pre-evaluation I-Ds:

  'The extensive deployment of this feature is well-known within the email
   implementation and operational communities.'

The DISCUSS positions and comments are related to the work of the Working Group instead of being questions that Dave Crocker should address. The document itself (draft-ietf-yam-rfc1652bis-pre-evaluation-00) is scheduled to be evaluated by the IESG on October 22.

Please comment on the point raised by Lisa.

Regards,
S. Moonesamy
YAM WG Secretary


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.