[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Iptel] Review of TGREP -01
Hi Vijay,
Thx much for sparing the time to do the review.
Please see my comments inlined (begin with ###dhaval).
At 02:53 PM 4/17/2003 -0500, Vijay K. Gurbani wrote:
Folks:
I volunteered to 'expert' review TGREP at the San Francisco IETF.
Enclosed are my comments. Hope they are helpful.
Thanks,
- vijay
--
Vijay K. Gurbani
vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm
6G-440
Naperville, Illinois 60566 Voice: +1 630 224
0216
------------------------------------------------------------------------------
Comments on
<http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-01.txt>
A philosphical comment first: after reading the I-D, it appears
that
registration is but a pre-requsite for the selection of the
appropriate
gateway, so the thrust is on gateway selection more than gateway
registration. Is TGREP a misonomer? I realize it is too late
to change the
name now, and I am not advocating doing so.
On to some real comments.
* First paragraph of Page 4: too many "etc." in the
paragraph. Suggest
re-wording to take some of them out.
###dhaval: will do.
* Section 3.5.5: The strength
(MUST) in the following statement:
Routes MUST not be
disseminated external to the ITAD, with
TrunkGroup attribute.
should be replaced to a SHOULD (there is also a
gratuitous comma in the
sentence above).
Someone correct me if I am mistaken, but there may be
arrangements between
ITADs to carry emergency (SOS) calls identified by a
trunk group name. I
know that trunk group names are not standardized, but
there is an I-D
tackling that particular problem
(http://www.ietf.org/internet-drafts/draft-
ietf-iptel-trunk-group-00.txt>). In certain
cases, it may be beneficial
for two autonomous ITADs to have peering arrangements
for SOS trunk groups.
I would thus like to leave open the possibility of the
disseminating routes
with TrunkGroup attributes in the
future.
###dhaval: Our intent for the MUST was deliberate since no standardized
trunk group names exist.
If I understand correctly, the draft
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-00.txt
seems to
attempt to define a mechanism to send a trunk group rather standardizing trunk groups.
So, should (no pun intended ;-) we leave the change from MUST to SHOULD
for the future since there's no guarantee that there will be standardized trunk group names?
What do you think? Please don't get me wrong. I am open to either way.
Anyone else have input on this?
* There isn't any Security section. Even if we assume the same security
considerations as TRIP, we should simply point this out.
###dhaval: Will do.
* There isn't any section on IANA considerations. The type codes and
###dhaval: Section 4 covers this but thanks for pointing out since
I noticed a reference error from Section 4 (it should be pointing to sections
3.1, 3.2 etc. versus 4.1, 4.2 etc.)
address families being discussed in the I-D have presumably been
send to IANA and are in the processing queue.
###dhaval: Haven't sent anything to IANA yet. Jonathan, could you guide us on this?
Suggest that you take off the following two sentences from the
first paragraph of Page 4:
The type codes for the new attributes and address families
are yet to be obtained from IANA. An attempt will be made
to assign the codes...
###dhaval: Will remove this in light of Section 4 that covers this already.
and simply include an IANA section with the pertinent template
and information.
* Section 3, second paragraph ends with:
However, there are certain attributes that are not
relevant in TGREP. TGREP also defines certain new attributes
that find a use in a TGREP update.
Suggest you change it to something as follows which provides more
directions to implementors:
However, certain TRIP attributes are not relevant in TGREP; a
TGREP speaker MAY ignore them if they are present in a TGREP
message. In addition, TGREP defines the new attributes
described in this document to be transported in a TGREP
update (UPDATE message?).
Please feel free to paraphrase what I wrote above
###dhaval: Will do.
* Section 3.1; I would suggest flipping the order of the first and second
paragraph. The second paragraph actually defines the TotalCircuitCapacity
attribute.
###dhaval: Will do. (also similarly for 3.2 and 3.3)
* Section 3.2: I think this section makes a strong case for NOT disseminating
the AvailableCircuits attribute (due to its dynamic nature). Furthermore,
in section 3.2.5 you do indicate that "Routes MUST NOT be disseminated
with the AvailableCircuits attribute." However, the first paragraph of
section 3.2 provides an escape clause to the implementor:
"...it MUST NOT be propagated unless the LS is sure that it
is relatively static."
Section 3.2.5 and the openeing paragraph of section 3.2 are in direct
conflict with each other.
Suggest that you take out the "...it MUST NOT be propagated unless the
LS is sure..." sentence and simply state that this attribute MUST NOT
be propagated.
###dhaval: Will do.
* Section 3.3.1, in the sentence: "The first component field represents
the total number of calls terminated normally ...", I would suggest
you replace 'successfully' with 'normally'. More so since we just
defined (in the previous section) what we consider are the criteria
for a successfull call.
###dhaval: Will do.
* Section 3.3.5: There is ambiguity in the sentence:
Routes MUST NOT be disseminated with the CallSuccess
attribute. Its potential to change dynamically does not
make it suitable to disseminate in most cases.
What is the final consensus: routes MUST not be dissemniated with this
attribute? or am I allowed an escape clause since the sentence also
says "...in most cases."
I would suggest that due to the dynamic nature of this attribute, it NOT
be included. To a certain extent, CallSuccess and AvailableCircuitCapacity
work against each other: the better the call success rate at a gateway,
the less the available circuit capacity may be in the near future at that
gateway. Since we are not dissemniating AvailableCircuitCapacity, let's
do the same for CallSuccess.
###dhaval: Will do..
* Section 3.5.1: "The presence of TrunkGroup attribute with the length
field of the attribute as 0 signifies that the TGREP GW can terminate ALL
trunkgroup for the given Reachable route(s)."
Does not the *absence* of TrunkGroup attribute signify the same? I would
suggest that if a TGREP GW can terminate ALL trunkgroups, don't use a
wildcard attribute of 0. This simply requires more processing and special-
casing. My suggestion would be that the absence of a TrunkGroup attribute
amply signifies the GW's capability of handling all trunk groups.
* I would suggest taking Section 3.8 out completely; it does not add any
extra essence to TGREP. Furthermore, since it has only one sub-section
which represents that cost/pricing was not considered as an attribute
for a variety of reasons. If you had considered other attributes as
well and rejected them, it may have been a good idea to have an entire
section devoted to such attributes. But since you have only one such
attribute, I would just as soon leave it out.
###dhaval: Will do.
* Section 3.9 talks about a "lightweight" version of TRIP; does such a beast
exist? Does what you describe next constitute a "lightweight" version of
TRIP? Please clarify.
* In Section 3.10, I am not sure I understand the difference between
'aggregation' and 'consolidation' as you use it. Is not what you describe
at the top of page 22 aggregation?
Furthermore, you state in the same paragraph that there is a possibility
of loosing routes if consolidation was not done. Why would that be the
case? I am not sure I understand why the routes would be lost if
consolidation was not done.
* Section 3.10, I do not understand what the last paragraph is trying to
say. There is a lot of gratuitous commas and I am not sure I understand
the implications of the last statement. If, as you state in the para-
graph above, consolidation is so important that routes may be lost if not
done, why leave it upto individual implementations. I don't see any
guidelines which will help implementors code consolidation in a consistent
manner (again, I am unclear as to where 'aggregation' stops and
'consolidation' begins; maybe that is the root of all my problems with this
section. Needs some work to clarify things...)
Nits and Grammatical/structural comments: please incorporate these if they
make sense to you.
###dhaval: Will do.
Thx,
Dhaval
* Page 3:
The decision about which gateway to use depends on many
factors, including their availability, remaining call
capacity and call success statistics particular POTS
destination.
I am not sure what you mean by the last clause, "...and call success
statistics particular POTS destinatios". Maybe you meant "...and
call success statistics TO particular POTS destinations."?
* First paragraph of Page 4: Suggest replacing the sentence:
The document aims at specifying all the attributes that
can go in on the TGREP session.
with:
This document specifies all the attributes that are useful
for inclusion in a TGREP session.
* Section 3.3, suggest replacing the following two sentences:
For example, a call that reaches the Alerting stage but
does not get connected because of called party being unavailable
is conventionally considered a successful call. Similar is the
case when the called party is busy.
with:
For example, a call that reaches the Alerting stage but
does not get connected due to the unavailability of the called
party, or the called party being busy, is conventionally
considered a successful call.
* Section 3.6.1, second paragraph:
s/It is the same as the E.164/The CountryCode is the same as the E.164/
* Section 3.7: s/for a GW cam advertise/for a GW to advertise/
* Section 3.10: s/into the Location Server for propogation/into the Location
Server./
_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel