Subject: [Speermint] NITS review (plus comments) of draft-speermint-consolidated-presence-im-usecases-01

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 22 May 2007 11:11:37 +0200

Hi,

I've done a NITS review of the consolidated IM/presence use case - i've also
added some general comments about the draft - hope they help!

idnits reports the following issues:

---
idnits 2.04.07

/home/ietf/id/draft-ietf-speermint-consolidated-presence-im-usecases-01.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Too long document name: The document name (without revision number),
     'draft-ietf-speermint-consolidated-presence-im-usecases', is 54
     characters long, but may be at most 50 characters

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of http://www.ietf.org/ID-Checklist.html for how to handle the case
     when there are no actions for IANA.)

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     No issues found here.

     Summary: 2 errors (**), 1 warning (==), 0 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
----

- I'm unsure how to best change the draft name, especially since my initial
idea of "draft-speermint-presence-im-consolidated" does not make clear that
this is a use cases document (might clash with future documents). I'd
suggest the editors should consult with the chairs on this.

- If RFC 2119 terminology is not to be used, please remove section 1 and the
corresponding reference.

- Please add an IANA considerations section, explaining that there are no
such considerations since this document as a use case doc does not propose
any protocols.

- Document title: I think that "Presence & IM Use Cases" is way too generic
in the context of the whole IETF. I'd suggest to a) expand "IM" and b) add
the word "Peering", like "Presence & Instant Messaging Peering Use Cases".

- Abstract: i think (warning - i'm not a native speaker!) that "non-VoIP"
would be the desired term (most often, a lower case "o" is used, so i
suggest sticking to that).

- Introduction: i'd suggest changing "the management of the intercommunity
link.." to "the management of such intercommunity links". Please expand the
acronym "VoIP" here (at least once in the document, best on first use after
the abstract). I also suggest changing "unless otherwise is stated" to
"unless otherwise stated" (again, you might want to have that checked by a
native-speaking reviewer). The last paragraph does not add much information,
i suggest removing it.

- 3.1 Simple Interdomain Subscription: small nit: From other documents i get
the impression that language like "we have" is to be avoided in RFCs. I
suggest rephrasing the first sentence. Generally, we should come to a
conclusion whether all terminology from the terminology draft should be
written like "Peer Network", to distinguish them from generic text. Jason?
David?

- 3.2 List Interdomain Subscription: Please expand URI (and make a
informative reference) on first use. I'd use bullets for the two
"sub-use-cases". I think that "SUBSCRIBE" is a request type, not a
"session", although i know what that is intended to say. A reference to the
respective draft about the SUBSCRIBE mechanisms would be good here.

- 3.3 Authorization Migration: "presentities" is not defined - maybe add a
reference to a definition. Same for "watchers". Also, a new term "peering
network" is introduced - is that some generic term, or is it meant to be a
"Peer Network". The last paragraph talks about "communities" again, and
leaves it unclear whether a "community" translates 1:1 to a "Peer Network".
Also, the last paragraph contains a lot of typos: "sharin", "informaiton",
"associaed", "doucment", "otehr". I also suggest changing "users that should
get it" to "users that should receive it".

- 3.4 Page Mode IM: Please expand "SBE" on first use.

- 3.5: Session Based IM: Please expand "MSRP". No need to refer to the
definition of SBE again.

- 3.6: "More or less fully standardized" is a very nice double oxymoron :) -
I suggest rephrasing that (although i somehow like it). The second sentence
of the last bullet ("Note that document sharing..") looks incomplete to me.
I also think that the last paragraph should be rephrased, probably in a way
that saying the list above is not exhaustive as new developments in the
world of non-VoIP RTC surface.

- 3.7: I'm not sure whether this section describes potential or existing use
cases for peering. Some of the text gives general justification for the use
case of IM peering - if that is the intended meaning of the text, it should
probably be moved to the introduction section (or, even make a "Motivation
for Peering" subscection?)

- 4: Security Considerations: typo "there <-> they are". I think that the
SEC reviewer will not be satisfied with the current text - if there are
security considerations for those use cases (or related considerations, as
privacy) they should at least be mentioned, even the document does not
attempt to propose a solution. First thing that comes to my mind is trust
relation between peers, esp. in the scenario described in section 3.3).

As said above, please add an IANA section.

Hope that helps,

Alex

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 22 May 2007 15:12:10 +0300

Alexander & Jason,

Many thanks for your review, intend to issue 02 in mid June.

Anyone that has comments on the draft please send them asap.

--Avshalom

Alexander Mayrhofer <[email-masked]> 
22/05/2007 12:11

To
speermint <[email-masked]>, Avshalom Houri/Haifa/IBM@IBMIL, Edwin Aoki 
<[email-masked]>, Sriram Parameswar <[email-masked]>, 
speermint <[email-masked]>, "Livingood, Jason" 
<[email-masked]>, David Meyer <[email-masked]>
cc

Subject
[Speermint] NITS review (plus comments) of 
draft-speermint-consolidated-presence-im-usecases-01

Hi,

I've done a NITS review of the consolidated IM/presence use case - i've 
also
added some general comments about the draft - hope they help!

---
idnits 2.04.07

 

     No issues found here.

 

  ** The document seems to lack an IANA Considerations section.  (See 
Section
     2.2 of http://www.ietf.org/ID-Checklist.html for how to handle the 
case
     when there are no actions for IANA.)

  Miscellaneous warnings:

 

     No issues found here.

     Run idnits with the --verbose option for more detailed information 
about
     the items above.
----

- I'm unsure how to best change the draft name, especially since my 
initial
idea of "draft-speermint-presence-im-consolidated" does not make clear 
that
this is a use cases document (might clash with future documents). I'd
suggest the editors should consult with the chairs on this.

- If RFC 2119 terminology is not to be used, please remove section 1 and 
the
corresponding reference.

- Document title: I think that "Presence & IM Use Cases" is way too 
generic
in the context of the whole IETF. I'd suggest to a) expand "IM" and b) add
the word "Peering", like "Presence & Instant Messaging Peering Use Cases".

- Introduction: i'd suggest changing "the management of the intercommunity
link.." to "the management of such intercommunity links". Please expand 
the
acronym "VoIP" here (at least once in the document, best on first use 
after
the abstract). I also suggest changing "unless otherwise is stated" to
"unless otherwise stated" (again, you might want to have that checked by a
native-speaking reviewer). The last paragraph does not add much 
information,
i suggest removing it.

- 3.1 Simple Interdomain Subscription: small nit: From other documents i 
get

"session", although i know what that is intended to say. A reference to 
the

- 3.3 Authorization Migration: "presentities" is not defined - maybe add a
reference to a definition. Same for "watchers". Also, a new term "peering
network" is introduced - is that some generic term, or is it meant to be a
"Peer Network". The last paragraph talks about "communities" again, and
leaves it unclear whether a "community" translates 1:1 to a "Peer 
Network".
Also, the last paragraph contains a lot of typos: "sharin", "informaiton",
"associaed", "doucment", "otehr". I also suggest changing "users that 
should
get it" to "users that should receive it".

- 3.6: "More or less fully standardized" is a very nice double oxymoron :) 
-
I suggest rephrasing that (although i somehow like it). The second 
sentence
of the last bullet ("Note that document sharing..") looks incomplete to 
me.
I also think that the last paragraph should be rephrased, probably in a 
way
that saying the list above is not exhaustive as new developments in the
world of non-VoIP RTC surface.

- 3.7: I'm not sure whether this section describes potential or existing 
use
cases for peering. Some of the text gives general justification for the 
use
case of IM peering - if that is the intended meaning of the text, it 
should
probably be moved to the introduction section (or, even make a "Motivation
for Peering" subscection?)

Hope that helps,

Alex

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 22 May 2007 09:16:55 -0400

Great review Alex - thanks!

My suggestion on naming:

filename = draft-ietf-speermint-presence-im-usecases 
title = Presence & Instant Messaging Peering Use Cases

Regards
Jason

> -----Original Message-----
> From: Alexander Mayrhofer [mailto:[email-masked]] 
> Sent: Tuesday, May 22, 2007 5:12 AM
> To: speermint; Avshalom Houri; Edwin Aoki; Sriram Parameswar; 
> speermint; Livingood, Jason; David Meyer
> Subject: NITS review (plus comments) of 
> I've done a NITS review of the consolidated IM/presence use 
> case - i've also added some general comments about the draft 
> - hope they help!
> 
>   Checking nits according to 
> http://www.ietf.org/ietf/1id-guidelines.txt:
>   
> - I'm unsure how to best change the draft name, especially 
> since my initial idea of 
> "draft-speermint-presence-im-consolidated" does not make 
> clear that this is a use cases document (might clash with 
> future documents). I'd suggest the editors should consult 
> with the chairs on this.
> 
> - If RFC 2119 terminology is not to be used, please remove 
> section 1 and the corresponding reference.
> 
> - Please add an IANA considerations section, explaining that 
> there are no such considerations since this document as a use 
> case doc does not propose any protocols.
> 
> - Document title: I think that "Presence & IM Use Cases" is 
> way too generic in the context of the whole IETF. I'd suggest 
> to a) expand "IM" and b) add the word "Peering", like 
> "Presence & Instant Messaging Peering Use Cases".
> 
> would be the desired term (most often, a lower case "o" is 
> used, so i suggest sticking to that).
> 
> - Introduction: i'd suggest changing "the management of the 
> intercommunity link.." to "the management of such 
> intercommunity links". Please expand the acronym "VoIP" here 
> (at least once in the document, best on first use after the 
> abstract). I also suggest changing "unless otherwise is 
> stated" to "unless otherwise stated" (again, you might want 
> to have that checked by a native-speaking reviewer). The last 
> paragraph does not add much information, i suggest removing it.
> 
> - 3.1 Simple Interdomain Subscription: small nit: From other 
> documents i get the impression that language like "we have" 
> is to be avoided in RFCs. I suggest rephrasing the first 
> sentence. Generally, we should come to a conclusion whether 
> all terminology from the terminology draft should be written 
> like "Peer Network", to distinguish them from generic text. Jason?
> David?
> 
> - 3.2 List Interdomain Subscription: Please expand URI (and 
> make a informative reference) on first use. I'd use bullets 
> for the two "sub-use-cases". I think that "SUBSCRIBE" is a 
> request type, not a "session", although i know what that is 
> intended to say. A reference to the respective draft about 
> the SUBSCRIBE mechanisms would be good here.
> 
> - 3.3 Authorization Migration: "presentities" is not defined 
> - maybe add a reference to a definition. Same for "watchers". 
> Also, a new term "peering network" is introduced - is that 
> some generic term, or is it meant to be a "Peer Network". The 
> last paragraph talks about "communities" again, and leaves it 
> unclear whether a "community" translates 1:1 to a "Peer Network".
> Also, the last paragraph contains a lot of typos: "sharin", 
> "informaiton", "associaed", "doucment", "otehr". I also 
> suggest changing "users that should get it" to "users that 
> should receive it".
> 
> - 3.5: Session Based IM: Please expand "MSRP". No need to 
> refer to the definition of SBE again.
> 
> - 3.6: "More or less fully standardized" is a very nice 
> double oxymoron :) - I suggest rephrasing that (although i 
> somehow like it). The second sentence of the last bullet 
> ("Note that document sharing..") looks incomplete to me.
> I also think that the last paragraph should be rephrased, 
> probably in a way that saying the list above is not 
> exhaustive as new developments in the world of non-VoIP RTC surface.
> 
> - 3.7: I'm not sure whether this section describes potential 
> or existing use cases for peering. Some of the text gives 
> general justification for the use case of IM peering - if 
> that is the intended meaning of the text, it should probably 
> be moved to the introduction section (or, even make a 
> "Motivation for Peering" subscection?)
> 
> - 4: Security Considerations: typo "there <-> they are". I 
> think that the SEC reviewer will not be satisfied with the 
> current text - if there are security considerations for those 
> use cases (or related considerations, as
> privacy) they should at least be mentioned, even the document 
> does not attempt to propose a solution. First thing that 
> comes to my mind is trust relation between peers, esp. in the 
> scenario described in section 3.3).
>