Subject: [Gen-art] Gen-ART Review of draft-ietf-opes-smtp-use-cases-03

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 13 Sep 2005 07:59:24 -0500

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

Summary: This document is almost ready for publication as an Informational 
RFC.

I found a few nits, probably AUTH-48, but just to write them down now:

- In the last paragraph of the Introduction, there were just a few too many 
pronouns for me to easily parse

   This work focuses on SMTP based services that want to modify command
   values and those that want to block commands by defining an error
   response that the MTA should send in response to the response it
   received.

I wasn't sure what "those" and "it" were actually pointing to (I could 
guess, but I'd be guessing).

- OCP isn't expanded on first use.

- The text under Figure 3 refers to "the MTA (the OPES processor)", but 
there are three MTAs in Figure 3, all with OCP callout servers. Should this 
have been plural, or was the reference to one of the three MTAs (and, if so, 
which one)?

- In Section 4.1, one of the actions is "The attachment is removed by an 
error message" - should this be "replaced by an error message"? "removed, 
and an error message generated"? Or did I misunderstand?

- In Section 5, I think what you're saying is "this document does not 
describe any new protocol functionality, it only shows use cases for OPES 
with SMTP, so does not introduce any new security considerations beyond 
current considerations for SMTP and OPES" - sorry, but we see enough "no new 
security considerations" that we get suspicious quickly!

Thanks,

Spencer 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Sep 2005 10:00:01 -0400

Spencer,

thanks much for the detailed comments, very helpful. Appreciate your 
time and effort!

Wrt to the last comment - any suggestion on how to address this? It's 
obvious that this document just describes uses cases. We cannot simply 
make up some "security considerations" just for the seak of having some...

Ted - I assume we wait to hear feedback from the IESG review until 
incorporating all the comments into a new version?

Thanks,
   Markus

Spencer Dawkins wrote:
> Summary: This document is almost ready for publication as an 
> Informational RFC.
> 
> - In the last paragraph of the Introduction, there were just a few too 
> many pronouns for me to easily parse
> 
> there are three MTAs in Figure 3, all with OCP callout servers. Should 
> this have been plural, or was the reference to one of the three MTAs 
> (and, if so, which one)?
> 
> error message" - should this be "replaced by an error message"? 
> "removed, and an error message generated"? Or did I misunderstand?
> 
> describe any new protocol functionality, it only shows use cases for 
> OPES with SMTP, so does not introduce any new security considerations 
> beyond current considerations for SMTP and OPES" - sorry, but we see 
> enough "no new security considerations" that we get suspicious quickly!
> 
> Thanks,
> 
> Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Sep 2005 09:41:25 -0500

Hi, Markus,

> Spencer,
>
> thanks much for the detailed comments, very helpful. Appreciate your time 
> and effort!
>

Totally agree - I think the Security Considerations should simply say "this 
document contains only use cases and defines no protocol operations. 
Security considerations for protocols that appear in these use cases are 
documented in the corresponding protocol specifications".

Brian (and Ted), does this seem right to you?

Thanks for the quick feedback.

Spencer

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 Sep 2005 10:44:59 -0400

Hi Spencer,

> Totally agree - I think the Security Considerations should simply say 
> "this document contains only use cases and defines no protocol 
> operations. Security considerations for protocols that appear in these 
> use cases are documented in the corresponding protocol specifications".

That would sound good to me, thanks for the specific suggestion. Let's 
see what comments Brian/Ted might have and what additional feedback we 
get from the IESG review. We'll then incorporate the comments appropriately.

Thanks again for your constructive feedback!

Thanks,
   Markus

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Sep 2005 10:11:49 +0200

Sounds reasonable. I didn't see this as a reason to block the
document, but it would be an improvement.

     Brian