Subject: [Speermint] NITS (and beyond) review of draft-ietf-speermint-voip-consolidated-usecases-08

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 16 Jun 2008 17:08:44 +0200

Hi,

i did a review of the consolidated usecases draft, comments as follows:

- Generally, i'd appreciate if more eyes could check the draft. I think 
the language could be clearer, and there are also several (mostly small) 
technical issues. More reviewers would definitely help here (i suggest 
nominating at least one other formal reviewer for the document before we 
proceed)

Detailed comments follow:

- The automated idnits report doesn't yield any serious problems 
(complains about the spacing in some examples).

- Abstract: I think it should read "... many common VoIP use caseS .."

- ToC: Parts of the structure are inconsistent. For example, 5. "Use 
Cases" should probably be merged with 5.1 "Static Peering Use Cases", so 
that we have 5. "Static Peering Use Cases" and 6. "On-demand Peering Use 
Cases". Also, if "On-demand direct" is the only "on-demand" use case, a 
seperate section below that seems superflous (should have at least two 
sections at the same level, ihmo). Same for section 7 and 7.1

- There are numerous abbreviations that never get expanded in the draft. 
I do know that a lot of them are from the terminology draft, but that 
draft is not even referenced in the "Terminology" section. The 
abbreviations that are never expanded (i might have missed some, though) 
include: VoIP, (most of the SPEERMINT-Terms), ENUM, VLAN, SSPs, QoS, 
DSCP, URI, UAC, UAS, TN, R-URI, NAPTR, B2BUA, SBC/SBE, RTP, L5, BGP, 
TRIP, SPIT, DUNDi, TLS.

- RFC2119 Terminology is mentioned in the Terminology section, but the 
terms are never used. I strongly suggest referring to the SPEERMINT 
terminology here, though.

- Figure 1: "the elements defined are optional" should probably read 
"some elements..."

- In some of the figures, there is not just a "O-DBE" (oh-dbe), but also 
a "0-DBE" (zero-DBE). I guess it's a typo (if not, i'm curious about the 
purpose of this "element phishing" :)

- page 4, last sentence "sub-divided in .." should probably mean 
"sub-divided into.. " (warning - i'm not a native speaker).

- page 5 mentions a "step four", although the steps are not numbered. 
Maybe change the list into a numbered list.

- Section 5: "User cases" should probably read "Use cases". See more 
comments about the section structure above.

- The phone numbers used in the various SIP requests / ENUM records seem 
not to be from the IETF "good example number" list. Please use the drama 
numbers for the draft (+1 <area code> 555 <0100-0199>), see 
http://www.ietf.org/ID-Checklist.html

- "ENUM" is defined to use e164.arpa. So, any example using a different 
suffix is technically not "ENUM", but "ENUM-like technology". I know 
that might make it hard in some places of the document, but that's how 
it is defined...

- Most of the ENUM records are broken. For example, page 8 has a 
(broken?) backreference "\1", while the regular expression does not 
yield any data for the backreference - no parentheses around the ".*". 
I've a hard time with the term "inputted" below that example, too. Maybe 
"provisioned"? The ENUM records also miss the "replacement" element, 
which in most cases is empty, and therefore a "." at the end of the 
record. They also don't have the "IN" class, while other DNS record 
examples have.

- Typo in bullet 4 on this page - "exapmle.com". There should be a 
reference to the S-NAPTR logic somewhere.

- Bullet 5 - use "TCP as transport" is maybe better than "TCP for 
transport"? (might be a taste issue, though)

- Trailing dot after DNS examples? Most of them are missing that, could 
be a problem if someone decides to enter the records "as they are" into 
a zone.

- 5.1.1.1 "where exists" should probably read "where there is". Maybe 
change "sign a peer agreement which clearly states the peering 
policies... " to "sign a peering agreement which clearly states the 
policies..."

- last paragrahp of 5.1.1.2: "decide to deploy SBE." should probably be 
"decide to deply SBEs".

- last paragraph of 5.1.2: The case where media passes through the DBEs 
is not specific to the static-direct-assisted case - it could also 
happen in the static direct - maybe mention this in the draft..

- 5.1.3 maybe "lies within..." instead of "lies with..."?

- Figure 4 contains one of those "zero-DBE"s :)

- bullet 2 - the ENUM record is broken, there is neither content for the 
backreference, and additionally the regex will never match because there 
is a space after ".*". Missing the replacement component, too.

- Bullet 4: I think it would be good to specify which kind of "DNS 
Lookup", in that case a lookup for S-NAPTRs... same in bullet 6, where a 
DNS query for "A records" (What about AAAA?) is performed. It would also 
be good to reference to the SRV and S-NAPTR documentation somewhere.

- page 17: shouldn't there be "example.ORG" in the Via: header?

- paragraph below: "Note that if I-SSP" instead of "Note that I-SSP"..

- bullet 9: broken ENUM record.

- I'm missing information on when and when not S-NAPTR and SRV queries 
are performed. For example, between step 9. and 10. there is no SRV 
lookup. It is unclear in what cases those lookups are performed, and 
when they are not performed. Maybe they are optional in some scenarios.

- 5.1.3.1: It says that "once O-SSP queries the SED, LUF/LRF provider is 
out of the picture." - that was confusing to me because i don't see how 
the _SED_ itself can be queried ("queries _for_ the SED" instead?). 
Later in the paragraph, "before peering happened", should probably be 
changed to "before peering happens".

- 5.1.3.2: Refers to figure 5, shouldn't that be figure 4? Also, if 
there are no SBE/DBE employed here, wouldn't that make it an Static 
Direct Assisted use case, meaning that the very existance of SBE/DBE is 
the difference, and without them the use case would not be different 
from the other one?

- Figure 5 has the dreaded "zero-DBE" again :)

- 5.1.4.2 "common code" should probably mean "common codec". also, "list 
of codecs" instead of "list of codec".

- 6.1 "there is NOT" -> "there is no" ? I'm missing a reference to the 
Rohan's direct peering draft here...

- 6.1.2 - personally, i don't really like the biased statement about 
SPAM in open peering models. Even in closed models, users of Service 
providers can submit any amount of spam to any peer.

- 7: "concrete" -> "actual"?

- 7.1.1. What is an "LS"? SBCs are SBE's, or?

That's what i found - as i said, i'd definitely recommend that at least 
one other reviewer checks the draft before we proceed.

cheers

Alex

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

---

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 16 Jun 2008 11:57:17 -0400

Alex - Thank you very much for providing the detail below.  Yiu and I (the editors) will be addressing your comments below in short order, but we will be holding off on submitting a new draft until such time that we have a formal reviewer assigned to the document and get feedback from that person - provided the Chairs want to go down that path.

Adam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexander Mayrhofer
> Sent: Monday, June 16, 2008 11:09 AM
> To: [email-masked]
> Subject: [Speermint] NITS (and beyond) review of draft-ietf-speermint-
> voip-consolidated-usecases-08
>
> Hi,
>