Subject: [Speermint] Review of the Requirements Draft

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Sep 2006 14:23:19 +0200

Hi all,

I went through the requirements draft. Here are a few questions and 
comments:

* My comments regarding the mentioning of the working group name and the 
   description about the process are applicable here as well.

* Please also remove process related descriptions from the draft.
I would also suggest to remove the editor's notes. If you want to track 
open issues and the current discussion status then you might just want 
to use an issue tracker instead. Since the document does not get 
published too regularly these comments and notes are pointless.

The open question section should be deleted as well (unless it points to 
the issue tracker).

* I strongly suggest to change the style of the document. You might want 
to reuse the Requirement/Motivation style we have in the requirements 
document in ECRIT.

Every requirement must use RFC 2119 language.
The RFC 2119 boilerplate is missing.

* Section 3.2, 3.3, 3.4 are not requirements in the classical sense. It 
should rather be content of a BCP document.

Hence, you need to decide about the type of document you are writing. Is 
this a document that describes requirements for a later protocol or 
targeted at the usage of a protocol (BCP)?

* Section 6 is not helpful. You might either want to tackle the subject 
by referring to the protocol that the working group wants to develop (if 
the working group actually wants it) or you want to refer to another 
document.

* There are far too many references in the normative reference section. 
Typically, you only have one reference in there : RFC 2119.
Here you might also want to include the terminology document.

This document basically needs a major rewrite. I suggest to start soon 
since you block the protocol work.

Ciao
Hannes

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 5 Sep 2006 09:51:26 -0400

Thanks for all the detailed comments - we should have the editors
consider each of these closely.

Jason

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 8:23 AM
> To: [email-masked]
> Subject: [Speermint] Review of the Requirements Draft
> 
> Hi all,
> 
> I would also suggest to remove the editor's notes. If you 
> want to track open issues and the current discussion status 
> then you might just want to use an issue tracker instead. 
> Since the document does not get published too regularly these 
> comments and notes are pointless.
> 
> The open question section should be deleted as well (unless 
> it points to the issue tracker).
> 
> * I strongly suggest to change the style of the document. You 
> might want to reuse the Requirement/Motivation style we have 
> in the requirements document in ECRIT.
> 
> * Section 3.2, 3.3, 3.4 are not requirements in the classical 
> sense. It should rather be content of a BCP document.
> 
> Hence, you need to decide about the type of document you are 
> writing. Is this a document that describes requirements for a 
> later protocol or targeted at the usage of a protocol (BCP)?
> 
> * Section 6 is not helpful. You might either want to tackle 
> the subject by referring to the protocol that the working 
> group wants to develop (if the working group actually wants 
> it) or you want to refer to another document.
> 
> This document basically needs a major rewrite. I suggest to 
> start soon since you block the protocol work.
> 
> Ciao
> Hannes
>

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 14 Sep 2006 15:28:32 -0600

Hi Hannes,

   Thank you for your review and comments.
   See inline.

Jean-Francois.

> Sent: Tuesday, September 05, 2006 6:23 AM
> To: [email-masked]
I agree but view this as a question of document maturity. Kids start by
using generic sounds or words to mean something they can't name
precisely but as they grow, it's amazing, the words and language nuances
come out clear and loud.
I will clear the requirements draft from the abuse of SPEERMINT.

> The open question section should be deleted as well (unless it points
Noted.
 
> to reuse the Requirement/Motivation style we have in the requirements
Yes, will probably not get done in draft-01.

> Every requirement must use RFC 2119 language.
I noted this in the editor notes for draft-00 as something to clean up.
Section 3 is aligned with this approach and the rest of the doc will be.

> The RFC 2119 boilerplate is missing.
Agreed, fixed. 

> should rather be content of a BCP document.
I do not understand your point here given the scope of this doc: minimum
set of requirements for VoIP interconnect and the wg charter suggests it
be a BCP. 
Look at BCP 40, it's got quite a few requirements verbs. I must be
missing your point.

> Hence, you need to decide about the type of document you are writing.
A BCP with requirements (MUST/SHOULD on protocols) that must/should be
implemented and/or used to achieve the intended goals stated in the
title of the doc.

> Is
If you were doing the review of an ID in WGLC, I would totally agree.
This was draft-00 throwing a couple of ideas for wg debate and the
document was clearly requesting more input on what should be in-scope of
these requirements (per the editor's notes). 

> Typically, you only have one reference in there : RFC 2119.
It depends.
I beg to differ in this case: if you have a MUST statement on another
IETF RFC, then that it has to be in the normative reference section,
i.e., to comply with this document, you have to comply with the others,
hence they make the normative section.
In some cases, for e.g. when drafting requirements for new protocols
(like parts of in the ecrit req draft), MUST/SHOULD are on the
functionality of the protocols, then yes, the result is no other
normative ref than 2119.
Check BCP 111.

> Here you might also want to include the terminology document.
Yes.

> since you block the protocol work.

And what protocol would that be?