RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

[Dimitri.Papadimitriou@alcatel.be]

lyndon - see in-inline

Again, thank you for your detailed response.  I had the following 
thoughts:

-- regarding the format for Long Call ID, if there is to be an AS
on the use of the draft, a reference to G.7713.2 would be good.
A reference in the draft itself might be simpler, though.  References
to other Call ID formats could also be added, if desired.

[dp] - what do you mean by "is to be an AS on the use..."

-- on the issue of the Session Object processing, I see your thinking
as to why an implementation should not zero out the Short Call ID 
subfield, but the draft itself notes that some implementations interpret
RFC 3209 to mean the field is zeroed out due to the labeling of the
field "MUST be zero" in 3209.

Why not use a separate object for the Call ID, along the lines of the
Association
object?  That would separate processing of the Call ID from the Session 
object, and might fit the ASON model better by separating Call
information from LSP information.

[dp] already discussed see

<https://ops.ietf.org/lists/ccamp/ccamp.2006/msg00209.html>

answer:

"association object associates by definition LSPs (using per-sender node 
identifier and address) on the other side a call creates an association 
between end-points by which subsequent LSPs may be made (call ids are 
unique within the context of the pair of addresses that are the call 
source and destination)"

-- on the LINK_CAPABILITY object, I may have missed it in the text, but
I did not see a way for a source node to request the destination node to
send its LINK_CAPABILITY back, that would be useful. 

[dp] it is a local policy decision, in both ways - leaves flexibility
and does not create additional call blocking on informational data from 
the protocol perspective 

Also, shouldn't the object be forwarded if not recognized, and not 
discarded?

[dp] you refer to the class-num, because when the notify message 
travels end-to-end a non-supporting receiver just discard it; keep
in mind that the dest address of the notify message is a routable
egress node address

-- One new question: "Simultaneous call and connection establishment
(sometimes called piggybacking) is not supported" in section 5.1 - does
this mean it may be supported in future, or is not considered possible
or desirable?

[dp] the latter v 

Cheers,

Lyndon