Subject: Re: [Speermint] Review of architecture-09

From: Daryl Malas <[email-masked]>
Date: Mon, 8 Mar 2010 17:48:42 -0700

Hi Alex,

I believe I addressed most, if not all, of your comments in the -10 revision of the draft.  Please review and confirm.

Regards,

Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, January 20, 2010 8:36 AM
To: [email-masked]
Subject: [Speermint] Review of architecture-09

In the light of the LC, i have reviewed
draft-ietf-speermint-architecture-09. Here are my comments:

Generally, i think that some of the issues i have listed below require an additional revision before we progress the draft. I've found content as well as editorial issues, and i suggest solving those before we proceed the draft.

More details:

- The draft has a number of idnits - those should be solved:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-speermint-architecture-09.txt

Most obvious are the over-long lines, and the outdated references.

- nit: 3.1 is the only sub-secion of 3. - this is sometimes considered misuse of sections...

- Acronyms are not expanded on first use - i've spotted "UA", "ENUM", "SIP", "URI", "NAPTR", "SRV", "EvRC" (??)

- "Figure 2" is referenced a few times, eg. on page 4, even though there's just "figure 1".

- Content: Page 5, first line: "intra-SSP" should probably be clarified as "resource within the originating SSP"

- Typo: Page 5, bullet 4: "tec" is probably supposed to be "text"?

- Content: Page 5, "In case the target SSP changes..." What does that mean? I thought the that "target SSP" would be the ultimate destination, and hence the "target SSP" cannot "change" (except in cases like
porting...) If this is about a "transit" case, then we have a terminology problem - that would then be the "next hop SSP"? The only exception might be when a session gets redirected to a different SSP - is that case meant here? Also, the reference to "figure 2" is pointing nowhere..

- Typo: Page 5: "communicator" -> "communicate" in section 3.1

- Content: Section 3.1: there seems to be a confusion between "network elements" and "functions". If i understand it correctly, then "elements"
implement "functions", hence "elements" can only communicate with other "elements", but not with "functions", because the "functions" are something abstract?

- Content: Section 4.4.1: The definition of "LUF" in RFC 5486 is different from what is stated here. RFC 5486 says the LUF returns the "target domain", and not the address of the SF or the target SSP...
Again, a terminology problem around the famous "no-man's land" between LUF and LRF..

The draft itself says in 4.1.2 that the *LR* discovers the "next hop SF"
(page 6, bottom)

An option would be to state in 4.1.1 that "the LUF identifies the target  SSP for a given request"?

- Content: Section 4.1.1.1 "performs a Lookup Function (LUF) to determing the target address" should probably also be "... to determine the target SSP"?

- Nit: page 7, line 3 "may be used" should read "need to be used"?

- Nit: "originating SSP" and other terminology should be written as "Originating SSP", so that those terms are easier distinguished from other "non-terminology" text. (for example, first line of 4.1.2.1 - in 4.1.2.2, "Originating SSP" is already capitalized)

- Content: 4.1.2.1 - What is an "receiving SSP"? Is that the "Target SSP", or some intermediate SSP?

- Content: 4.1.2.1 says "when communicating with another SSP" might be redundant, because intra-SSP communication is out of scope anyway?

- Nit: 4.1.2.3: "communicationS" -> "communication"

- Content: Page 8, first line: "a SF may perform"... I think that should be "a SBE may perform", or "a SF of an SBE" (like a few lines down) - not sure if this is intentional, though.

- Content: 4.1.3.1.1 - The sentence is a) completely broken and b) contradicts the recommendation (?) to select TLS in 4.1.2.1

- Content: Section 5 "Peering must occur in a common IP address space" - what is meant by this? The whole internet is a "common IP address space"
(or, actually two spaces, if you consider v4 and v6). I *think* i understand what is meant here ("a broadcast domain"?), but the definition is extremely vague...

- Content: Section 4.2.1.1, last sentence: My local SIP guru here says that checking the "From" header against the client TLS certificate might be dangerous in transit scenarios, because it might contain the domain of the originating SSP, while the client certificate would be from the intermediate SSP. Also, he notes that verifying both the Identity headers *and* the From header might be too much of verification...

- Content: Section 6, Security Considerations are weak: An "optional requirement" is somehow a contradiction, and not really convincing, particularly in the field of Security.. Maybe change that to "cryptography should be required unless physical security..." Also, i don't see the work requested in the second paragraph happening anywhere...

- Nit: RFC2119 is referenced, but i don't see a single RFC2119-style MAY, MUST etc. in the draft. It might be safe to remove the reference to RFC2119.

tia,

Alex

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