I am the assigned Gen-ART reviewer for
draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other Last Call comments
you may receive.
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Comments:
Substantial:
============
* General comment about backward compatibility
I think legacy transit nodes resetting the Call ID to zero on
transmission is a major issue that needs to be addressed more visibly in
the draft.
* Section 6.1
The following sentence needs to be tightened.
The text
"Note that a Call MAY NOT be imposed ..."
needs to be changed to
"Note that a Call MUST NOT be imposed ..."
since it is a prohibition to do so.
Semi-substantial:
=================
* Section 5.1
I did not understand what this sentence means. Does it mean the
notify message does not have to follow the path of LSPs or it must not
follow the path of LSPs? Adding some clarifying text on why it is so,
may be a good idea.
"The Notify message is a targeted message and does
not follow the path of LSPs through the network."
* Section 6.5 Call Collision
For the Call ID Contention error case, I do not see why we need to check
the remote source address, instead of always returning an error.
* Section 6.6.5
"If a teardown request Notify message is received
for an unknown Call ID, it is, nevertheless, responded to in the
affirmative."
Why not return a Call Management/Unknown Call ID error instead?
* IANA considerations
If there are existing implementations it would be nice to suggest
values for the RSVP objects and error codes to the IANA
Minor:
======
* The following text is repeated in both the abstract and the
introduction. One of them can be removed.
"A Call does not provide the actual connectivity for transmitting user
traffic, but only builds a relationship by which subsequent
Connections may be made. In GMPLS such Connections are known as Label
Switched Paths (LSPs)."
* Section 4.3.1
Suggest replacing
"In this case the ingress..."
with
"In the case where the ingress..."
since "this case" has not been defined.
Editorial:
==========
There is a reference to RFC2747 in the references section but it is not
referenced anywhere in the draft. I would suggest removing the reference
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
