Re: NITS (and beyond) review of draft-ietf-speermint-voip-consolidated-usecases-08

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: speermint-bounces@...
[mailto:speermint-bounces@...] On
> Behalf Of Alexander Mayrhofer
> Sent: Monday, June 16, 2008 11:09 AM
> To: speermint@...
> Subject: [Speermint] NITS (and beyond) review of draft-ietf-speermint-
> voip-consolidated-usecases-08
>
> 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
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint