Subject: [NSIS] Some small errors

From: Bo Gao <[email-masked]>
Date: Tue, 14 Mar 2006 04:04:53 -0500

Hello,
In the Internet-Draft of GIST 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-09.txt,
At Page 34,line 5, "it if" should be "if it".
At Page 50, "NTLP" should be modified to "GIST" in the sentence 
"Alternatively, receipt of an upstream Query at the flow source MAY be 
used to trigger setup of NTLP state in the downstream direction" as the 
name has been already changed.
At Page 61, in the rule 2 "if a new MA-SM would be needed for this 
peer, create one in listening state", I think this applies to rule 1 
too. As the confirm can be sent over the new established MA (Not sure).

Also I have a question about the local processing, How could the 
signaling application indicate  it wishes to become a signaling peer 
with the Querying node? I checked the service interface between GIST 
and NSLP, I couldn't figure out if it is a functionality of the 
SendMessage or a functionality of RecvMessage. Is the parameter " 
Transfer-Attribute " in the ReceMessage a in-out parameter?

Sincerely

Bo Gao
E-mail: [email-masked]
Web: http://www.cs.concordia.ca/~gao_b

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 16 Mar 2006 14:18:02 -0000

Hi Bo,

Thanks for the comments. Please see in line:

> -----Original Message-----
> From: Bo Gao [mailto:[email-masked]] 
> Sent: 14 March 2006 09:05
> To: [email-masked]
> Subject: [NSIS] Some small errors
> 
> 
> Hello,

I've added these to the issue tracker at 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue105

basically the answers are
*) yes
*) yes
*) not quite; in fact, the rules about when to create a listening MA
are not really consistently listed (should also be in rules 1 and 5
here and also rule 1 for the node level SM). the point is that listening
MA creation is only loosely correlated with the message processing;
this needs to be clarified in the context of what state needs to be in 
place before a Response is sent.

> Transfer-Attribute " in the ReceMessage a in-out parameter?

this is handled in the RecvMessage primitive: when a Query is received
the NSLP gets a RecvMessage, and its reaction determines whether peering
takes place and the payload in the Response. See the discussion of the
Routing-State-Check argument to RecvMessage in B.2 (and references
therein).

cheers,

r.