Subject: [NSIS] Initial attempt at NTLP - call for consensus:

From: [email-masked]
Date: Tue, 1 Apr 2003 12:50:03 +0300

Hi,

At IETF 56, I made the following suggestion for starting the NTLP work:

Starting point
 Based on RSVP (RFC2205 + RFC2961)
 Separate service specific stuff out
 Separate flow spec & session id
 Keep semantics of PATH (discovery & transport combined)
 Support Soft state
 Support of RSVP-proxies

Open issues to address (need consensus)
 Logically separate discovery & transport, in practice they could be piggybacked.
 Message fragmentation concerns
 Reliability concerns
 Optionally supporting other transport protocols
 Reduction of multicast complexity
 Support RFC2752 / policy issues
 Routing interaction (handling mid-session path splitting)
 Support for explicitly stating message directionality & hop-by-hop vs. end-to-end.

Please comment on the above, if you feel that you can live with above suggested starting point.

I have asked Henning Schulzrinne & Melinda Shore to put together an initial proposal on the NTLP, for the working group to consider.  My hope is that we have a stable starting point for this work already by IETF 57 in Vienna.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 1 Apr 2003 12:43:16 +0100

john,

it might be helpful for some of us if you were able to categorise the points in the list below according to whether they are agreement/questions about
a) what the NTLP should do, or
b) how the NTLP should do it

some of them are clearly (b), others seem more like partly (a) [which cannot then be answered by thinking about the NTLP in isolation, i would contend]

in particular, what is the actual meaning/content of 'support soft state'?

cheers,

robert h.

ps. are you going to probe consensus on the interim meeting results in the same way? even despite having been there, i didn't recognise some of them when presented in San Francisco.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 01 April 2003 10:50
> To: [email-masked]
> Subject: [NSIS] Initial attempt at NTLP - call for consensus:
> 
> 
> Hi,
> 
> I have asked Henning Schulzrinne & Melinda Shore to put 
> together an initial proposal on the NTLP, for the working 
> group to consider.  My hope is that we have a stable starting 
> point for this work already by IETF 57 in Vienna.
> 
> br,
> John

---

From: [email-masked]
Date: Tue, 1 Apr 2003 16:01:53 +0300

Hi Robert,

> it might be helpful for some of us if you were able to 
> categorise the points in the list below according to whether 
> they are agreement/questions about
> some of them are clearly (b), others seem more like partly 
> (a) [which cannot then be answered by thinking about the NTLP 
> in isolation, i would contend]

The points I made at the meeting are just meant as starting 
points for the work - I think part of the what & how are
left up to the protocol design stage, which, I hope, is
what we are in know.  I don't want to get into mandating 
the protocol design - if you have opinions on the what
& the how, now is a good time air your opinions.

With regards to starting with RSVP (RFC2205 + RFC2961) -
please note, we are not required to be backwards
compatible.
 
> in particular, what is the actual meaning/content of 'support 

In my mind, soft state is state which is not tied to a transport 
layer connection & will eventually expire.  Supporting soft state
means that the state which NTLP transport should be soft state.
Again, the semantics of how soft soft is, I think, should be
part of the protocol design.

> ps. are you going to probe consensus on the interim meeting 
> results in the same way? even despite having been there, i 
> didn't recognise some of them when presented in San Francisco.

As there were no comments on the meeting minutes on the list nor at the 
meeting, there seemed nothing to probe.  I will send my summary to the
list - any anyone with comments, clarification or anything I missed are
encouraged to speak up.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 1 Apr 2003 14:22:19 +0100

john,

a quick first question - are you saying that *what* the NTLP should do
(i.e. what functions it should have) is a protocol *design* question?
 
> part of the protocol design.

my question here would be, in concrete terms, how is the NTLP functionality 
(not internal design) impacted by the fact that the (signalling application) 
state is soft (or indeed that the information is 'state' information in
the first place)?

robert h.

ps. if the consensus is that i am obsessing pointlessly about this question,
i'll be happy to shut up. however, the fact that some people think this
is important protocol functionality, and others think this is not protocol
related at all, seems somehow disconcerting to me.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Tue, 1 Apr 2003 16:33:13 +0300

Hi Robert,

> (i.e. what functions it should have) is a protocol *design* question?

What I mean is that the particular functions it has, with regards
to the layer split is part of the design, yes.  That layer split
should be captured in the framework.
  
> state is soft (or indeed that the information is 'state' information in

The impact is that existence of an NTLP (or lower layer protocol) 'connection' 
should not imply liveliness of state.  Periodic refreshes should be considered
as the way to keep state alive.
 
John