Subject: [Speermint] review (NITS and general comments) of draft-ietf-speermint-terminology

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 11 Aug 2006 12:51:08 +0200

Hi,

i've done a nits review on the terminology draft (and also included some
"non-NIT" comments, see below):

- "technical" nits: none (the draft passes the idnits checker without any
warnings)

- acronyms: There are a bunch of acronyms that are not expanded on their
first use: ENUM, VoIP, SIP, NAPTR, URI, SRV, SMTP, MX, L5. In
contrary, "DNS" does not need to be expanded, it's on the RFC Editor's "well
known" list.

- References: I'm missing them for a bunch of the mentioned protocols (most
notable "SIP"). The E.164 reference is outdated as Klaus Nieminen recently
pointed out on the ENUM mailing list (there is a 2005 revision).

- I'd put "(SPEERMINT)" after "Session peering for multi.." in the
Introduction, line 7 - just to make the connection (i didn't see it anywhere
else in the draft)

- simple one: Figure 1 includes two double lines, so the "i.e. above the
double line in.." should be corrected to eg. "... above both double lines .."

[I'm proably nit-picking a bit over the next sections, but for terminology
every word is important, by definition, so... ]

- Section 3.1: This not only defines the CRD, but also the terminus "ingress
point". If we need the term "ingress point", we should prabably define it
seperately - there is already use for it in section 3.2. I'm unsure whether
we need to differentiate between "destination" and "ingress point" (a
"destination netfork" is for sure something different than the ingress point)

Additionally, the definition of "ingress" point specifically mentions SRV
record type routing, which could lead to the impression that RFC3263-style
(or federation-rule) routing destinations are _not_ ingress points... also
note that a CRD which already contains is port number would skip SRV lookup
- so the SRV stuff is imho too specific for the definition.

- Seciton 3.2: This section leaves open whether the "destination" is
_always_ a "ingress point" - if yes, wording should be unified.

- Section 3.3: The definition would exclude packet-switched "PSTN-style"
networks, like eg. NGN/UMTS/IMS release5 (?) stuff. However, i don't see any
better method than using the "circuit switched" parameter for the definition..

- Section 3.4: "Overlaying" the term "Network" could be confusing, because
that would mean everytime we talk about any other network (eg. ethernet) in
the context of SPEERMINT we'd need to specifically say that it's eg. an
"Ethernet Network". What about changing that to "Peer Network" or something,
so that we don't "cast" the generic work "Network"? We'd probably end up
with the need to say  "a RFCXXX, 3.4 network" each time we mention the
structure defined here.

Additionally, we're already using the term "peer network" in the draft
itself (4.1, eg.)

- Section 4.1/4.2: Is "peering" taking place between "Networks" or "Service
Providers"? I don't think that "Service providers" can be "interconnected",
only their networks can.

- Section 4.3/4.4: The term "domain" is not defined in the document. That
makes the definition a bit unsharp. should those be "networks" or "service
providers" instead?

- Section 5.1: The term "service provider" ins this section (taken from the
infrastructure enum requirements draft) clashes with the "service provider"
of the speermint terminology draft itself). Maybe we should use something
different here (draft-ietf-enum-validation-arch uses "communication service
provider" for that - another option would be to simply use "entity" here?)

- Section 5.2 (small): There seems to be "over" missing at the end of line 4
in the first paragraph.

- Section 5.3: The first sentence looks incomplete to me: " ... the use of a
seperate branch the e164.arpa tree ...". The second sentence is a bit
unsharp, imho. Is it exchanging "phone numbers to Call Routing data" in
order to find "Ingress Points" or "Peer Networks"?

- Section 6: There are a few acronyms / unreferenced stuff: X.509, GRX, CA

that's all -

Alex

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

---

From: David Meyer <[email-masked]>
Date: Fri, 11 Aug 2006 07:03:00 -0700

Alex, 

	Thanks for the detailed comments. I'll update accordingly
	and build a -03.

	Thnx,

	--dmm

---

From: David Meyer <[email-masked]>
Date: Fri, 11 Aug 2006 11:04:11 -0700

I've updated with your comments (and a few others). -03
	is on  

	http://www.1-4-5.net/~dmm/draft-ietf-speermint-terminology-03.txt

	--dmm