From nsis-bounces@ietf.org Thu Jun 01 04:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FliGk-00030z-6P; Thu, 01 Jun 2006 04:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fli9y-0006ED-33 for nsis@ietf.org; Thu, 01 Jun 2006 04:04:02 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fli9v-0000TB-5U for nsis@ietf.org; Thu, 01 Jun 2006 04:04:02 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 075241BAC4D for ; Thu, 1 Jun 2006 09:54:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) To: nsis Message-Id: References: <3F2E01E1D7B04F4EBEC92D3FA324D8807DCFB1@rsys004a.roke.co.uk> From: Martin Stiemerling Date: Thu, 1 Jun 2006 10:03:57 +0200 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bc7ad0be57af1caf5c16e3f26b55e70 X-Mailman-Approved-At: Thu, 01 Jun 2006 04:11:00 -0400 Subject: [NSIS] NSLP versioning X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0555777467==" Errors-To: nsis-bounces@ietf.org --===============0555777467== Content-Type: multipart/alternative; boundary=Apple-Mail-1--956854573 --Apple-Mail-1--956854573 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, There is still a not completely solved issue back from the old days (2004) about NSLP versioning. It is about wether an NSLP can have multiple versions or not. The old emails have been mainly exchanged privately amongst the NSLP and NTLP authors. Take a look and give some comments! (there are two emails included in this email) The topic has shown up as well in these recent emails from Robert and Roland: http://www1.ietf.org/mail-archive/web/nsis/current/msg05130.html http://www1.ietf.org/mail-archive/web/nsis/current/msg05140.html The baseline in the old days has been that a new NSLP version would require a new NSLP, thus a new NSLP ID. Martin Henning Schulzrinne wrote: > Martin Stiemerling wrote: > >>> The NTLP doesn't care what format the NSLPs use for their messages >>> (so they can easily do totally different things to one another). >>> The NTLP also has some significant differences from the NSLPs with >>> regard to message content requirements. Even so, it still seems >>> useful to make some attempt at co-ordinating the design, even if it >>> is only to make implementors' lives easier. >>> >> >> Very good idea, indeed we need some coordination between all NSIS >> components . >> > > Having a common way of representing all NSLPs also makes it possible > to have a debugger or protocol analyzer that can show the outline of > the packet even if it does not understand the semantics of each NSLP. > > Thus, I'd argue that there'd have to be a really strong reason *not* > to > do this... > Good. :-) >> I would prefer to have a version number, since allocating a new NSLP >> number for a new NSLP version might not be appropriate. Allocating a >> new NSLP number will include some sort of IANA action, a new version >> number probably not. >> > > Versioning is a tricky topic. This is not just about allocating > version numbers in the protocol field. Indeed, there seem to be few > successful instances of multiple versions of the same protocol. (HTTP > is an example > of a not-very-successful transition, even though it mostly works in > practice. > > I would argue that there are only two interesting cases: > > (1) It's effectively a new protocol, even if it re-uses some parts of > the old one, if an existing implementation can't make use of the > information (not backwards-compatible). In that case, little is gained > by having a version field unless you have a really small NSLP field > (which we should avoid). > > (2) The new 'protocol' just adds a few options, but an old > implementation can understand this (backwards compatible). In that > case, the version doesn't help at all and you might as well just > include the fields as optional. > This was more-or-less the conclusion I came to in thinking about the QoS NSLP. If there is a mechanism to extend the current version with new objects in a backwards compatible way, then you don't need or want to change version numbers for that. Changes that are big enough to cause an increase in version number are likely to be rare enough and significant enough that allocating a new NSLP identifier is reasonable. >> - NSLP protocol version number. >> > > Not a good idea; see above. > > >> >> - number of TLVs in NSLP message >> > > Not a good idea; just means that there is one more field to keep > consistent. > Yes, I agree. It doesn't seem to add anything particularly helpful, just more error cases to check. >> - NSLP message type (NATFW NSLP uses this field to distinguish the >> action to be taken, e.g., create pinholes in firewall >> > > Yes. > Agreed. The current QoS NSLP common header has message type and flags (with the flags currently depending on the message type). Does this sound useful to other people? >>> We've also got the concept of 'objects', which tend to be specified >>> as some sort of TLV (or AVP). Currently GIMPS defines its objects >>> as a type and length. The QoS NSLP has a length and type which is >>> split into 'class' and 'type', in a similar way to RSVP. This is >>> useful where you have a number of objects which are alternatives >>> for one another (e.g. IPv4 src/dst vs IPv4 src/dst/proto/ports vs >>> IPv6 src/dst/flow-label). Otherwise it seems rather a waste of the >>> type-space. The QoS NSLP makes use of the class/type split in two >>> cases at the moment: 'Scoping' and 'QSpec' (where the 'type' with >>> the QSpec class is the QoS model id). The 'alternatives' construct >>> can also be defined using a BNF definition of the messages. >>> Questions: >>> c) which comes first, 'type' or 'length'? >>> d) does 'length' include the length of the 'length' or 'type+length' >>> fields? e) should 'type' be split into class/type or just be a flat >>> number space? >>> >> >> For c): First 'type, second 'length'. >> For d): To make implementer's live easier: 'length' is total length >> of the object (TLV header plus data) >> > > Agreed. > OK for (c). For (d), would have argued it the other way. However, from a brief survey including the header length does seem more common for Internet protocols (TCP, SCTP, RSVP, DIAMETER), whilst ASN.1 BER and XDR don't include the TLV header length. By including the length of the header, you have additional special error cases to deal with (e.g. if the object header is 4 bytes long, lengths of 0, 1, 2, or 3 are special cases which can never be valid). In other ways, I'm not sure it makes much difference to implementors with respect to parsing the data. Not including the header length probably gives you a bit more freedom on how you manage your buffer/ pointers. >> The exact allocation of type, i.e., whether to split into class and >> type could be left to the particular NSLP. For instance, NATFW NSLP >> won't split into class and type. >> > > There are really two parts here, namely (written a bit differently > than > the RSVP case) > > - meaning ("this is the flow label describing the packets") = class > > - format ("this is an IPv4 version") > > Protocols like SMTP separate the two meanings, and I think this is a > good idea. However, the format labeling can be done inside the object, > as a common part of the object. > > Again, this primarily simplifies parsing and protocol analyzers. You > can just pass the object to a routine, which will know whether it can > handle the protocol version. > We've used this sort of thing in the current QoS NSLP draft in two places: the SCOPING object and the QSPEC (where the sub-type is used to indicate the QoS model). Interestingly, Rob suggested a different approach for the Flow-Routing Information in the GIMPS-01 draft. It doesn't seem to be something that is needed particularly often, and, certainly, you can always do it by including the sub-type/format discriminator inside the object itself. >>> The other thing we've talked about in the QoS NSLP work is whether >>> there ought to be some flags to indicate how to process objects >>> with a type number that an implementation might not know about >>> (RSVP and DIAMETER have functionality of this sort). This is used >>> to aid extensibility, and indicates the required behaviour when a >>> node encounters an object it does not know about - should it >>> forward it as is? remove it from the message? abort and send back >>> an error? Question: >>> f) Should we define some standard unknown-object processing >>> indicators (drop/forward/error)? >>> >> >> That's a good issue to further discussion. Can we be put this on >> hold, since (at least) I didn't have thought about this right now. >> > > Yes, a mandatory bit may be needed *instead* of the useless version > identifier. > Yes, that was my thought. Some existing protocols that do this sort of thing are RSVP (two high bits of class-num indicate reject message, ignore+drop object, or ignore+forward object), DIAMETER ('Mandatory' bit), X.509 (critical/non-critical extensions), SCTP (flags indicating behaviour for unknown chunk types), etc. > Another alternative is to use the option labeling mechanism used in > SIP which identifies capabilities instead of protocol elements. > Semantics > are "if you don't understand the label, don't process the message; if > you understand the label, you by definition understand the necessary > message components". This works pretty well and can yield somewhat > better diagnostics in case of failures. > > Imagine that you have capability > foo: requires A, B > bar: requires B, C > zong: requires A, C > > If the node understands foo and zong, but not bar, it will indicate > "sorry, can't do C", but it's harder to figure this out. If you > understand bar and zong, but not foo, you can't return anything. > > This is a bit contrived, but I think labeling semantics instead of > syntax elements is a better idea in general. > That's an interesting idea, which I'll need to think about a bit further. >>> For efficient processing it may be useful to pad all objects to 32 >>> bits in length. Questions: >>> g) Does such a padding rule seem sensible? >>> >> >> Yes, it is a good idea. >> >> >>> h) How do we define the padding (and determine that it is there when >>> processing)? >>> >> >> The simplest way would be to define all options (if possible) to 32 >> bits. I have to check out for the NATFW NSLP if all objects can be >> defined to 32 bits, or if there are some that are dynamic w.r.t. >> size. >> > > This usually works, but there may be strings, for example, that are > not naturally multiples of 32 bits. As long as you label all > variable-length entities, the 'left-over' is padding. > So, the object header gives the length including padding, and then you contain an extra length field inside the object itself to give the actual length of the data without padding? The other alternative is that object lengths give the length without padding, but define that all objects must be 32-bit aligned. The total object length is then the given length rounded up to a 4-byte multiple. This is probably more efficient, but gives greater possibility for implementation error. >>> Something else we might want to think about is whether there is a >>> set of common error codes we want to agree on (e.g. 'unknown >>> message type'). >>> >> >> Could be helpful for debugging. >> > > Again, borrowing ideas from elsewhere, it is useful to have message > classes, as in ftp, stmp, SIP, etc., indicating the severity of the > failure and whether this is a progress report, a temporary failure > ("no resources available") or a permanent failure ("your protocol > message is invalid"). That way, you can add failure indications and > older implementations will still do roughly the right thing (like not > retry > the broken message). > Yes, that sounds sensible. regards, Andrew Anfang der weitergeleiteten E-Mail: > Von: "Hancock, Robert" > Datum: 18. Oktober 2004 14:41:24 MESZ > An: , "Henning Schulzrinne" > , "McDonald, Andrew" > , "Cedric Aoun" > , , "Hannes > Tschofenig" , "Georgios Karagiannis" > , "Miquel Martin" > , "Martin Stiemerling" > > Betreff: NSLP versioning > > dear all, > > back in may (!) when we discussed common message structure > and so on, we decided not to have an NSLP version field since > - either the new version was fully backwards compatible > with the old (==> no need for a new version number > anyway, just add optional fields) > - or there is not backwards compatibility and so you > might as well have a new NSLP number provided the id > space is large enough (which it is, at the moment). > > this is what the GIMPS draft currently assumes about > the common NSLP header. > > the question arises of what to do when you have a node > which supports multiple versions (1 and 2) of the 'same' > NSLP, and has no idea which version(s) the peer supports: > > Q-node R-node > {1,2} -----------> {?} > > What NSLP should the Q-node put in its initial GIMPS query > message? > - if it sets NSLP=1 and R node supports {1,2}, how > do they get to use version 2 (which is presumably what > they would prefer) > - if it sets NSLP=2 and R node only supports NSLP=1, > then it will forward the message transparently to the > next node downstream, since NSLP=2 is 'new' and unrelated > to NSLP=1. > > What one might imagine would be that the Q node really > wants to format the GIMPS query with the semantics "I am > interested in QoS and I support all versions up to N", > to which the response could be "I support version M", > (with the implication that any NSLP data in the message > only got interpreted if M=N). The message is intercepted > by the R node based on the 'type' of NSLP, not version. > > How are the NSLP designers planning to do version > negotiation? Or is there some style of protocol design > which eliminates the problem? > > [My current proposal would be to put an open issue in the > next version of the GIMPS draft that discusses this question. > It basically affects the common header format in section > C.2.] > > robert h > > -- > > Visit our website at www.roke.co.uk > > Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK. > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third party > without > permission. This communication is for information only and shall > not create or > change any contractual relationship. > > ) > A98AB OK Completed --Apple-Mail-1--956854573 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear all,=A0

There is still a not = completely solved issue back from the old days (2004) about NSLP = versioning. It is about wether an NSLP can have multiple versions or = not.=A0
The old emails have been mainly exchanged privately = amongst the NSLP and NTLP authors.=A0

Take a look and give some = comments! (there are two emails included in this email)
The = topic has shown up as well in these recent emails from Robert and = Roland:

= =

The baseline in = the old days has been that a new NSLP version would require a new NSLP, = thus a new NSLP ID.=A0

=A0 Martin

Henning = Schulzrinne wrote:

Martin Stiemerling wrote:

The NTLP = doesn't care what format the NSLPs use for their messages
(so they can easily do totally different things to = one another).
The NTLP also has some = significant differences from the NSLPs with
regard = to message content requirements. Even so, it still seems
useful to make some attempt at co-ordinating the = design, even if it
is only to make = implementors' lives easier.


Very = good idea, indeed we need some coordination between all NSIS
components .


Having a = common way of representing all NSLPs also makes it possible
to have a debugger or protocol analyzer that can = show the outline of
the packet even if it does = not understand the semantics of each NSLP.

Thus, I'd = argue that there'd have to be a really strong reason *not*
to
do = this...


Good. :-)


I would = prefer to have a version number, since allocating a new NSLP
number for a new NSLP version might not be = appropriate.=A0 Allocating a
new NSLP = number will include some sort of IANA action, a new version
number probably not.


version numbers in the protocol = field. Indeed, there seem to be few
successful = instances of multiple versions of the same protocol. (HTTP
is an example
of a = not-very-successful transition, even though it mostly works in
practice.

I would argue that there are = only two interesting cases:

(1) It's effectively a new = protocol, even if it re-uses some parts of
the old = one, if an existing implementation can't make use of the
information (not backwards-compatible). In that = case, little is gained
by having a version field = unless you have a really small NSLP field
(which = we should avoid).

(2) The new 'protocol' just adds a few options, but = an old
implementation can understand = this (backwards compatible). In that
case, the = version doesn't help at all and you might as well just
include the fields as = optional.


This was more-or-less the = conclusion I came to in thinking about the QoS NSLP. If there is a = mechanism to extend the current version with new objects in a backwards = compatible way, then you don't need or want to change version numbers = for that. Changes that are big enough to cause an increase in version = number are likely to be rare enough and significant enough that = allocating a new NSLP identifier is reasonable.


=A0- NSLP = protocol version number.


Not a good = idea; see above.

=A0- number of TLVs in NSLP = message


Not a good idea; just means that = there is one more field to keep

Yes, I agree. It doesn't seem to = add anything particularly helpful, just more error cases to = check.
=A0- NSLP message type (NATFW NSLP uses this field = to distinguish the
=A0=A0 action to be taken, = e.g., create pinholes in firewall



Agreed.

The = current QoS NSLP common header has message type and flags (with the = flags currently depending on the message type). Does this sound useful = to other people?
We've also = got the concept of 'objects', which tend to be specified
as some sort of TLV (or AVP). Currently GIMPS = defines its objects
as a type and length. The = QoS NSLP has a length and type which is
split = into 'class' and 'type', in a similar way to RSVP. This is
useful where you have a number of objects which are = alternatives
for one another (e.g. IPv4 = src/dst vs IPv4 src/dst/proto/ports vs
IPv6 = src/dst/flow-label). Otherwise it seems rather a waste of the
type-space. The QoS NSLP makes use of the class/type = split in two
cases at the moment: 'Scoping' = and 'QSpec' (where the 'type' with
the QSpec = class is the QoS model id). The 'alternatives' construct
can also be defined using a BNF definition of the = messages.
Questions:
c) which comes first, 'type' or 'length'?
d) does 'length' include the length of the 'length' = or 'type+length'
fields? e) should 'type' be = split into class/type or just be a flat
number = space?


For c): First 'type, second = 'length'.
For d): To make implementer's = live easier: 'length' is total length
of the = object (TLV header plus data)



OK for (c).

For (d), = would have argued it the other way. However, from a brief survey = including the header length does seem more common for Internet protocols = (TCP, SCTP, RSVP, DIAMETER), whilst ASN.1 BER and XDR don't include the = TLV header length.
By including the length of the = header, you have additional special error cases to deal with (e.g. if = the object header is 4 bytes long, lengths of 0, 1, 2, or 3 are special = cases which can never be valid). In other ways, I'm not sure it makes = much difference to implementors with respect to parsing the data. Not = including the header length probably gives you a bit more freedom on how = you manage your buffer/pointers.


The exact allocation of type, = i.e., whether to split into class and
type = could be left to the particular NSLP.=A0 For instance, NATFW = NSLP
won't split into class and = type.

There are really two parts here, = namely (written a bit differently
the RSVP case)

- = meaning ("this is the flow label describing the packets") =3D = class

- format ("this is an IPv4 version")

good idea. However, the format labeling can be = done inside the object,
as a common = part of the object.
Again, this primarily simplifies = parsing and protocol analyzers. You
can just pass = the object to a routine, which will know whether it can
handle the protocol = version.


We've used this sort of thing in = the current QoS NSLP draft in two places: the SCOPING object and the = QSPEC (where the sub-type is used to indicate the QoS model). = Interestingly, Rob suggested a different approach for the Flow-Routing = Information in the GIMPS-01 draft.

It doesn't seem to be something = that is needed particularly often, and, certainly, you can always do it = by including the sub-type/format discriminator inside the object = itself.
The other = thing we've talked about in the QoS NSLP work is whether
there ought to be some flags to indicate how to = process objects
with a type number that an = implementation might not know about
(RSVP and = DIAMETER have functionality of this sort). This is used
to aid extensibility, and indicates the required = behaviour when a
node encounters an object it = does not know about - should it
forward it as = is? remove it from the message? abort and send back
an error? Question:
f) = Should we define some standard unknown-object processing
indicators = (drop/forward/error)?


That's a good = issue to further discussion.=A0 Can we be put this on
hold, since (at least) I didn't have thought about = this right now.


Yes, a mandatory bit may be = needed *instead* of the useless version

Yes, that was my thought. Some = existing protocols that do this sort of thing are RSVP (two high bits of = class-num indicate reject message, ignore+drop object, or ignore+forward = object), DIAMETER ('Mandatory' bit), X.509 (critical/non-critical = extensions), SCTP (flags indicating behaviour for unknown chunk types), = etc.
Another = alternative is to use the option labeling mechanism used in
SIP which identifies capabilities instead of = protocol elements.
Semantics
are "if you don't understand the label, don't = process the message; if
you = understand the label, you by definition understand the = necessary
message components". This works = pretty well and can yield somewhat
better = diagnostics in case of failures.

Imagine that you have = capability
foo: requires A, B
bar: requires B, C
zong: = requires A, C

If the node understands foo and zong, but not bar, = it will indicate
"sorry, can't do C", but it's = harder to figure this out. If you
understand = bar and zong, but not foo, you can't return anything.

This is = a bit contrived, but I think labeling semantics instead of
syntax elements is a better idea in = general.


That's an interesting idea, = which I'll need to think about a bit further.


For efficient processing it may be useful to pad all = objects to 32
bits in length. = Questions:
g) Does such a padding rule seem = sensible?


Yes, it is a good = idea.
h) How do we = define the padding (and determine that it is there when
processing)?


The = simplest way would be to define all options (if possible) to = 32
bits. I have to check out for the NATFW NSLP if = all objects can be
defined to 32 bits, or if = there are some that are dynamic w.r.t.

This usually works, but there = may be strings, for example, that are
not = naturally multiples of 32 bits. As long as you label all
variable-length entities, the 'left-over' is = padding.


So, the object header gives the = length including padding, and then you contain an extra length field = inside the object itself to give the actual length of the data without = padding?

The other alternative is that object lengths give = the length without padding, but define that all objects must be 32-bit = aligned. The total object length is then the given length rounded up to = a 4-byte multiple. This is probably more efficient, but gives greater = possibility for implementation error.


Something = else we might want to think about is whether there is a
set of common error codes we want to agree on (e.g. = 'unknown
message = type').


Could be helpful for = debugging.


Again, borrowing ideas from = elsewhere, it is useful to have message
classes, = as in ftp, stmp, SIP, etc., indicating the severity of the
failure and whether this is a progress report, a = temporary failure
("no resources available") or a = permanent failure ("your protocol
message is = invalid"). That way, you can add failure indications and
older implementations will still do roughly the = right thing (like not
retry
the broken message).


Yes, = that sounds sensible.
regards,




Anfang der = weitergeleiteten E-Mail:

Von: = "Hancock, Robert" <robert.hancock@roke.co.uk>= ;
Datum: 18. Oktober 2004 14:41:24 = MESZ
Betreff: NSLP versioning

dear = all,

back in may (!) when we discussed common message = structure
and so on, we decided not to = have an NSLP version field since
- either the = new version was fully backwards compatible
=A0 with the old (=3D=3D> no = need for a new version number
=A0 anyway, just add optional = fields)
- or there is not backwards = compatibility and so you=A0
=A0 might as well have a new NSLP = number provided the id
=A0 space is large enough (which = it is, at the moment).
this is what the GIMPS draft = currently assumes about
the common = NSLP header.

the question arises of what to do when you have a = node
which supports multiple versions = (1 and 2) of the 'same'
NSLP, and has = no idea which version(s) the peer supports:

Q-node =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = R-node
{1,2} =A0 -----------> =A0 =A0 {?}

What = NSLP should the Q-node put in its initial GIMPS query=A0
- if it sets NSLP=3D1 and R node = supports {1,2}, how
do they get to use version = 2 (which is presumably what
they would = prefer)
- if it sets NSLP=3D2 and R node = only supports NSLP=3D1,
then it will = forward the message transparently to the
next = node downstream, since NSLP=3D2 is 'new' and unrelated
to NSLP=3D1.

What one might imagine would be = that the Q node really
wants to format the GIMPS = query with the semantics "I am
interested in = QoS and I support all versions up to N",
to which = the response could be "I support version M",
(with the implication that any NSLP data in the = message
only got interpreted if M=3DN). = The message is intercepted
by the R node = based on the 'type' of NSLP, not version.

How are the = NSLP designers planning to do version=A0
which eliminates the problem?

[My = current proposal would be to put an open issue in the
next version of the GIMPS draft that discusses this = question.
It basically affects the common = header format in section=A0

robert h

--=A0

Visit our = website at www.roke.co.uk

Roke = Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, = UK.

The information contained in this e-mail and any = attachments is confidential to
Roke Manor = Research Ltd and must not be passed to any third party without
permission. This communication is for information = only and shall not create or
change any = contractual relationship.

)
A98AB OK = Completed

= --Apple-Mail-1--956854573-- --===============0555777467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0555777467==-- From nsis-bounces@ietf.org Thu Jun 01 10:22:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flo4Z-0002pE-5D; Thu, 01 Jun 2006 10:22:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flo4Y-0002ne-DH for nsis@ietf.org; Thu, 01 Jun 2006 10:22:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flo4X-0007e4-9N for nsis@ietf.org; Thu, 01 Jun 2006 10:22:50 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3AFF4F0002 for ; Thu, 1 Jun 2006 16:22:48 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 16:22:47 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 16:22:48 +0200 Message-ID: <447EF837.7070808@ericsson.com> Date: Thu, 01 Jun 2006 16:22:47 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2006 14:22:48.0376 (UTC) FILETIME=[DBA4CB80:01C68586] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I have finally finished my review of GIST. I do have a number of comments and question with potentially serious implications. So lets start with them. Please remember that I have only read it once plus some checks of it when writing up things. So there might be cases when a simple reference to where things are defined can resolve the issue. I will also be on vacation 3rd-11th of June so do not expect any response from me during this period. Major issues ------------ M1. Congestion Control This affects text not only in 5.3.3 but also 7.1.3 and possibly other places. But I do have a general concern that the congestion control measurements described in the specification is underspecified. First in 5.3.3 I don't see any normative minimal values, or even recommended values for T1 and T2 that will be safe to deploy on the internet. I don't find it acceptable that the developer needs to investigate which values that are safe to use and which are not. There should also be some criteria documented for when it is acceptable to go beyond these values. So my concern here is that the retransmission runs havoc and create way to many packets to be sent. Secondly, there are also no values documented for the rate control. I think it is necessary to document what internet safe values are here so that one does not cause problems. In addition is seems a bit simplistic to use a token bucket with some parameters selected based on the local link as GIST clearly sends messages beyond the local link. Thus one might have to consider being a bit smarter and more adaptive to what is seen for different flows. Third, the implication and congestion issues with local repair seems to have been brushed over. Section 7.1.3 do indicate that you need to take care, but nothing more. Are there some potential for aggregation of the queries to minimize the load and have quicker convergence? M2. Security functions for d-mode When reading the security consideration and the specification on security properties I get a bit frightened that there are no authentication mechanism specified for d-mode. It seems that there should be need for authentication of d-mode queries etc to ensure that the a NSIS node is talking to someone that really has the right to perform the query and association creation. Not having such a mechanism seems to prevent building a system where the domains edge nodes handles the primary security and the internal nodes only accept GIST messages that are authenticated by nodes belonging to the domain. Section 8.6: I also am concerned that if there exist no secured MA between two GIST nodes, a on-path Man in the middle can prevent there from ever existing a secured MA. M3. NAT traversal for GIST. Section 7.2: What plans are there for clearly defining NAT behavior for GIST and the relevant NSLPs? I think one should avoid repeating the mistake with NATs of not specifying the behavior sufficiently for NSIS. Thus I think there is need to specify in great deal what is going to happen at the translation. M4. IANA consideration section I think the IANA consideration section is lacking in several ways. A. Decision criteria for IESG, Expert review or other policies are not written. The WG should provide some guidelines for what is acceptable to be registered and what is not. B. There is no explanation for the large blocks of reserved codes that exist. C. No rules for what is required to be included in an application for assignment in any of these spaces. D. The NSLP ID policy. Is it really envisioned that GIST will only be used for NSLPs for which it is suitable that the IESG make decision on them? Wouldn't a better policy be expert review or something which is having a bit of lower bar. Having all proprietary users of GIST run to the IESG for approval seems strange. Minor Issues ------------ L1. The lack of a collected ABNF makes it hard to verify. Has the present ABNF been run through any of the syntax checkers available at: http://tools.ietf.org/inventory/verif-tools ? L2. Section 3.3, page 12, second paragraph: " In addition, it should be noted that NAT traversal almost certainly requires transformation of the MRI field in GIST messages (see Section 7.2). Although the transformation does not have to be defined as part of the standard, the impact on existing GIST-aware NAT implementations should be considered." It seems that not defining the NAT behavior for GIST can potentially cause interop problems and make it very hard to use. What is the plans for addressing this? Are there already existing GIST-aware NATs? L3. Section 4.1.2: "Reliability: This attribute may be 'true' or 'false'. For the case 'true', messages MUST be delivered to the signaling application in the peer exactly once or not at all; if there is a chance that the message was not delivered, an error MUST be indicated to the local signaling application identifying the routing information for the message in question." How does one evaluate "if there is a chance that the message was not delivered"? I think there is need for some clear definition on when the normative requirement applies. L4. Have anyone considered if one can run draft-ietf-pmtud-method-06 style of MTU discovery with GIST D-mode? L5. Section 5.1, page 33: "It MUST echo the MRI (with inverted direction), SID, and Responder-Cookie if the Response carried one;" I don't think "with inverted direction" is really clear here. What does it mean to invert the direction of the MRI? L6. Section 5.2.1 and A.1: I have some problems with that Section 5.2.1 first declares that these fields are present, while not defining them fully. Like nr of bits etc. Then section A.1 is also not a complete definition of the fields in the message. I think doing an informative reference in 5.2.1 is okay, and then actually have a complete definition in A.1. I would also like to point out that unless you always write out the number of bits a field have, and the fields in the order they appear in the graph you will confuse people reading it with text to speech synthesis, like Sam Hartman. Do consider that these comments applies to also other protocol elements defined in appendix A, such as A.3.3. L7. Section 5.2.2: "If the message is downstream, the IP-TTL MUST be set to the TTL that will be set in the IP header for the message (if this can be determined), or else set to 0." How is a message "downstream" I think you need to specify if this relates being sent in the downstream direction. L8. Section 5.3.2: " GIST may send messages addressed as {flow sender, flow receiver} which could make their way to the flow receiver even if that receiver were GIST-unaware. These should be rejected (with an ICMP message) rather than delivered to the user application (which would be unable to use the source address to identify it as not being part of the normal data flow). Therefore, a "well-known" port is required. " I am having difficulties understanding how the end-peer could make a difference between GIST messages going the whole way to the end-peer per design and those that should be rejected by the end-peer. Please explain what the intention here is. L9. Section 5.4.1: DCCP: The note on DCCP forgets one important factor. DCCP does not provide any reliability. L10. Section 5.7.1: "However, the object contents MUST be retained only for the duration of the Query/Response exchange and any following association setup, and afterwards discarded." Is "afterwards" only to referring to completed or failed association setup? L11. Section 5.7.1: "The responding node MUST verify this to ensure that no bidding-down attack has occurred; see Section 8.6 for further discussion." As section 8.6 states this is not sufficient for detecting a on-path man in the middle attack. So I think the wording the the above sentence is to strong. L12. Section 5.7.2: What address is used in the TCP connection. The port is specified but not the address. L13. Section 5.7.3: Why is TLS 1.0 made mandatory and not TLS 1.1? L14. Section 5.8.1.2: "In this case, it MUST use the signaling source address for the IP source address in order to receive the ICMP error." How can a sender of message sending a query using d-mode with the flow source address determine that it is a to small MTU that causes the messages to be lost, rather than anything else? I think the use of MUST in this sentence is wrong. Is it something more than a informative statement saying: To be able to receive ICMP messages the message sender needs to use his own address. L15. Section 5.8.1.3: Can someone please explain why an upstream request which has traversed a non-GIST aware router can be trusted less than a down stream one? L16. Section 6.4, Rule 4: Rule 4: send MA-Hello message restart NoHello timer why is the timeout of a send Hallo message timer reseting the NoHello timer? Shouldn't the NoHello timer be only based on receiving Hello messages from the other side? Also what is the recommended Hello frequency? It would be good to have some discussion on what reasonable values are. This is also part of the congestion discussion for GIST. Section 7.1.2: GIST probing: One more missing recommendation on values for protocol functionality. L17. Section 7.1.4: Bullet 1: "The signaling application at E1 MAY begin local repair immediately, or MAY propagate a notification upstream to D1 that re-routing has occurred." There seems to be a interaction between GIST and the signalling application about the notification on the change. Are there any recommendations on signalling application implementing the necessary semantics to perform that notification? L18. Section 7.2, page 73, last paragraph: A NAT will intercept datagram mode messages with the normal encapsulation containing such echoed NAT-Traversal objects. It is not obvious that a NAT will do this for d-mode. Isn't a NAT which is not made GIST aware simply going to translate the IP/UDP headers and forward the packet despite the router alert. L19. Section 7.2, page 74: "Note that Confirm messages are not translated." Why isn't them? Also where is that specified? And what is really meant with "not translated"? L20. Section A.2: The "r" bits are not explicitly written to fall under the rules in the last paragraph of that section. L21. Section A.2.1: What is the treatment of the "reserverd" AB=11 for a GIST node? L22. Section A.3.1: The "MRM-ID" field is not having the same name as in the IANA consideration section. L23. Section A.3.1.2: "D - Direction (always 0 for "downstream")" The use of "always" in the above make it unclear what is meant. L24. Section A.3.8: "the number of GIST payloads translated by the NAT" The NAT? There might be several NATs on the path and it is not clear how that is handled. One concern would be if different NATs translate different fields. L25. Section 4.1 The Info Count Field and Info fields. I think the rules regarding ordering of these are to weak. As the order and existence of fields are dependent on the error codes and sub-error code, it is important to clarify that with normative strength. So please state the rules that applies for resolving the additional data fields and for each error code be clearer on the additional data field. Being explicit in stating none for those that have none is a good idea. Nits ---- N1. There is quite a list of abbreviation used in this document without being spelled out at their first usage. Please correct. I have spotted the following ones: - NSLPID - RAO - SCD - N-SM - C-mode - Q-mode N2. Section 3.4, last paragraph: "A consequence of this design is that signaling applications should choose SIDs so that they are cryptographically random, and should not use several SIDs for the same flow unless strictly necessary, to avoid additional load from routing state maintenance." I think there is need for a reference to a document on how to achieve cryptographically random numbers. Is RFC 4086 a useful ref? N3. section 6.1: " Rule 4 (rx_Data): if (node policy will only process Data messages with matching routing state) then send "No Routing State" error message else pass directly to NSLP" It seems to me that the expression within the IF is wrongly defined. I think it should read: if (routing state exist) then pass to NSLP else Send error msg. N4. figure 7: The established to established arrow has "[!confirmRequired]" which is a bit confusing on what it applies to of the above cases. N5. Section 7.1.2: Please include a reference for OSPF. N6. Section 7.2: It uses "public" and "private" when referring to the different sides of a NAT. In BEHAVE WG they are using External and Internal instead. The reason is due to that the external side of a NAT may still be a private address space. N7. Section 11: Ref 6 and 8 needs to be updated N8. Section A.3.5: "MUST not" -> "MUST NOT" N9. Section A.4.4.9: subcode 3: "Invalid Object" -> "Invalid Object Type"? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 01 12:42:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqFM-0004eU-FQ; Thu, 01 Jun 2006 12:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlqFK-0004Hg-H3 for nsis@ietf.org; Thu, 01 Jun 2006 12:42:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlqFH-0006iw-2K for nsis@ietf.org; Thu, 01 Jun 2006 12:42:06 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k51Gfg2M011459; Thu, 1 Jun 2006 17:41:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (minor issues and nits) Date: Thu, 1 Jun 2006 17:41:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (minor issues and nits) Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AAC9xuA From: "Hancock, Robert" To: "Magnus Westerlund" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Magnus, Many thanks for the detailed review. I think I at least understand the bulk of the issues you raise, which is a good omen. This email has some initial comments on the minor issues/nits since a lot of them can be cleared up fairly easily. Anything that=20 generates further discussion I will capture explicitly in our issue tracker as/when it happens. I'll write separate emails on the major issues M1-M4. Cheers, robert h. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 01 June 2006 15:23 > To: nsis@ietf.org > Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >=20 >=20 > Hi, >=20 > I have finally finished my review of GIST. I do have a number of=20 > comments and question with potentially serious implications. So lets=20 > start with them. Please remember that I have only read it=20 > once plus some=20 > checks of it when writing up things. So there might be cases when a=20 > simple reference to where things are defined can resolve the issue. >=20 > I will also be on vacation 3rd-11th of June so do not expect any=20 > response from me during this period. >=20 > Major issues > ------------ >=20 > M1. Congestion Control > M2. Security functions for d-mode=20 > M3. NAT traversal for GIST. > M4. IANA consideration section will be covered in separate mails. >=20 > Minor Issues > ------------ >=20 > L1. The lack of a collected ABNF makes it hard to verify. Has the=20 > present ABNF been run through any of the syntax checkers available at: > http://tools.ietf.org/inventory/verif-tools ? earlier versions were certainly checked. the latest version passes Bill Fenner's checker with the exception that there are two common-headers, the second in the error message format. That will be fixed. >=20 > L2. Section 3.3, page 12, second paragraph: > " In addition, it should be noted that NAT traversal almost certainly > requires transformation of the MRI field in GIST messages (see > Section 7.2). Although the transformation does not have to be > defined as part of the standard, the impact on existing GIST-aware > NAT implementations should be considered." >=20 > It seems that not defining the NAT behavior for GIST can potentially=20 > cause interop problems and make it very hard to use. What is=20 > the plans=20 > for addressing this? Are there already existing GIST-aware NATs? See the (separate) answer on M3 (to come). >=20 > L3. Section 4.1.2: > "Reliability: This attribute may be 'true' or 'false'. For the case > 'true', messages MUST be delivered to the signaling=20 > application in > the peer exactly once or not at all; if there is a=20 > chance that the > message was not delivered, an error MUST be indicated=20 > to the local > signaling application identifying the routing=20 > information for the > message in question." >=20 > How does one evaluate "if there is a chance that the message was not=20 > delivered"? I think there is need for some clear definition=20 > on when the=20 > normative requirement applies. This really depends on the protocol being used. In the current=20 specification, you can only use Forwards-TCP to satisfy the reliable attribute, so I think there should be a reference to 5.7.2 to say how a TCP user can detect that a message might not have been delivered. This then becomes part of the rules for defining a new MA protocol (if you use it for reliability, indicate how failures are detected). >=20 > L4. Have anyone considered if one can run draft-ietf-pmtud-method-06=20 > style of MTU discovery with GIST D-mode? In theory this would be possible, however, the design rationale for splitting C/D modes suggests it's the wrong thing to do. The idea is to make the Query small and ideally robust against PMTU issues (since you have to do a Query for each flow), and amortise the cost of PMTUD=20 over the lifetime of a MA (which can support multiple flows). We are also assuming=20 that solid implementations of PMTUD get re-used by GIST implementations (because they are built into the MA protocols), rather than being built=20 into GIST directly, so advances in PMTUD get incorporated automatically. >=20 > L5. Section 5.1, page 33: > "It MUST echo the > MRI (with inverted direction), SID, and Responder-Cookie if the > Response carried one;" >=20 > I don't think "with inverted direction" is really clear here.=20 > What does=20 > it mean to invert the direction of the MRI? Change D=3D0 ro D=3D1 or vice versa. Will clarify. >=20 > L6. Section 5.2.1 and A.1: >=20 > I have some problems with that Section 5.2.1 first declares=20 > that these=20 > fields are present, while not defining them fully. Like nr of=20 > bits etc.=20 > Then section A.1 is also not a complete definition of the=20 > fields in the=20 > message. I think doing an informative reference in 5.2.1 is okay, and=20 > then actually have a complete definition in A.1. OK >=20 > I would also like to point out that unless you always write out the=20 > number of bits a field have, and the fields in the order they=20 > appear in=20 > the graph you will confuse people reading it with text to speech=20 > synthesis, like Sam Hartman. OK >=20 > Do consider that these comments applies to also other=20 > protocol elements=20 > defined in appendix A, such as A.3.3. OK >=20 > L7. Section 5.2.2: > "If the message is downstream, the IP-TTL MUST be set to the TTL > that will be set in the IP header for the message=20 > (if this can > be determined), or else set to 0." >=20 > How is a message "downstream" I think you need to specify if this=20 > relates being sent in the downstream direction. OK, will clarify. >=20 > L8. Section 5.3.2: >=20 > " GIST may send messages addressed as {flow sender, flow receiver} > which could make their way to the flow receiver even if=20 > that receiver > were GIST-unaware. These should be rejected (with an=20 > ICMP message) > rather than delivered to the user application (which=20 > would be unable > to use the source address to identify it as not being part of the > normal data flow). Therefore, a "well-known" port is required. > " >=20 > I am having difficulties understanding how the end-peer could make a=20 > difference between GIST messages going the whole way to the=20 > end-peer per=20 > design and those that should be rejected by the end-peer.=20 > Please explain=20 > what the intention here is. OK, an example: GIST gets assigned the port number 5682. A pair of endpoints (A, B) set up a media flow A->B. B is GIST unaware, and the application get allocated port 5682 by the node's OS (just by bad luck).=20 As part of GIST signalling initiated by A, an intermediate node C sends a Query which is received by B. This query now has source IP# of A and destination IP# of B and the=20 same destination port as the media flow. So it may well be delivered=20 to the media application (and look like garbage); if B checks the=20 source port the problem will only arise if C happens to chose the same source port for GIST as A did for the media flow. It may be that we don't have to worry about this in real life (i.e. we accept that occasionally bad things happen). Else it should be explained better ;-) >=20 > L9. Section 5.4.1: DCCP: > The note on DCCP forgets one important factor. DCCP does not=20 > provide any=20 > reliability. It was implicit in the comment on fragmentation ... but we can make it explicit. >=20 > L10. Section 5.7.1: > "However, the object > contents MUST be retained only for the duration of the=20 > Query/Response > exchange and any following association setup, and afterwards > discarded." >=20 > Is "afterwards" only to referring to completed or failed=20 > association setup? Both. Probably we should define another default time here (cf. M1). >=20 > L11. Section 5.7.1: > "The responding node MUST verify this to ensure that no bidding-down > attack has occurred; see Section 8.6 for further discussion." >=20 > As section 8.6 states this is not sufficient for detecting a=20 > on-path man=20 > in the middle attack. So I think the wording the the above=20 > sentence is=20 > to strong. I hope not: 8.6 is supposed to say that on-path man-in-the-middle=20 attacks can be reliably detected (modulo the residual threat listed in section 5.7). But maybe the correct phraseology would be along the lines of saying that "*if* a bidding down attack is detected after checking the SCD, then ..." (i.e. we accept that there may be false negatives but that the MUST applies to the result of the verification). >=20 > L12. Section 5.7.2: >=20 > What address is used in the TCP connection. The port is specified but=20 > not the address. Destination address: As returned in the Network-Layer-Information in the Response. Source address: free. >=20 > L13. Section 5.7.3: >=20 > Why is TLS 1.0 made mandatory and not TLS 1.1? Earlier, TLS1.1 was the mandatory one; but there was some expert advice to the contrary; see http://www1.ietf.org/mail-archive/web/nsis/current/msg05682.html. >=20 > L14. Section 5.8.1.2: > "In this case, it MUST use the signaling > source address for the IP source address in order to=20 > receive the ICMP > error." >=20 > How can a sender of message sending a query using d-mode with=20 > the flow=20 > source address determine that it is a to small MTU that causes the=20 > messages to be lost, rather than anything else? I think the=20 > use of MUST=20 > in this sentence is wrong. Is it something more than a informative=20 > statement saying: To be able to receive ICMP messages the=20 > message sender=20 > needs to use his own address. OK; I think there is still a MUST here but the MUST applies to any transmission with DF set (we don't care why a DF was set, but if it was, you MUST use your own SA).=20 >=20 > L15. Section 5.8.1.3: >=20 > Can someone please explain why an upstream request which has=20 > traversed a=20 > non-GIST aware router can be trusted less than a down stream one? Routing asymmetry and the (in)ability to apply ingress filtering. It may be that we don't need to specify this tie-breaker aspect, however. >=20 > L16. Section 6.4, Rule 4: >=20 > Rule 4: >=20 > send MA-Hello message > restart NoHello timer >=20 > why is the timeout of a send Hallo message timer reseting the NoHello=20 > timer? Shouldn't the NoHello timer be only based on receiving Hello=20 > messages from the other side? I suspect you are right here (should be the SendHello timer). >=20 > Also what is the recommended Hello frequency? It would be=20 > good to have=20 > some discussion on what reasonable values are. This is also=20 > part of the=20 > congestion discussion for GIST. Partly true; however, I think the issues here are less critical, since the Hello is only sent over MAs which are themselves congestion controlled. >=20 > Section 7.1.2: GIST probing: >=20 > One more missing recommendation on values for protocol functionality. See separate answer to M1. >=20 > L17. Section 7.1.4: >=20 > Bullet 1: "The signaling > application at E1 MAY begin local repair immediately, or MAY > propagate a notification upstream to D1 that re-routing has > occurred." >=20 > There seems to be a interaction between GIST and the signalling=20 > application about the notification on the change. Are there any=20 > recommendations on signalling application implementing the necessary=20 > semantics to perform that notification? Yes, but only implicitly and in the NSLP specifications. Possibly there should be more explicit generic guidance on NSLP design, but it has not been clear up=20 to now where is the correct place to capture this information. (That is, to a large extent I guess it would be preferable if NSLP designers did not have to understand everything in GIST to be able to design an NSLP properly.) >=20 > L18. Section 7.2, page 73, last paragraph: >=20 > A NAT will intercept datagram mode messages with the normal > encapsulation containing such echoed NAT-Traversal objects. >=20 > It is not obvious that a NAT will do this for d-mode. Isn't a=20 > NAT which=20 > is not made GIST aware simply going to translate the IP/UDP=20 > headers and=20 > forward the packet despite the router alert. Non-GIST aware NATs are out of scope. >=20 > L19. Section 7.2, page 74: >=20 > "Note that Confirm messages are not translated." >=20 > Why isn't them? Also where is that specified? And what is=20 > really meant=20 > with "not translated"? See separate answer to M3. >=20 > L20. Section A.2: > The "r" bits are not explicitly written to fall under the=20 > rules in the=20 > last paragraph of that section. True (!) >=20 > L21. Section A.2.1: >=20 > What is the treatment of the "reserverd" AB=3D11 for a GIST node? Good question; I suspect this should be an error case. >=20 > L22. Section A.3.1: >=20 > The "MRM-ID" field is not having the same name as in the IANA=20 > consideration section. OK. >=20 > L23. Section A.3.1.2: > "D - Direction (always 0 for "downstream")" >=20 > The use of "always" in the above make it unclear what is meant. The case D=3D1 is not allowed by the specification; we can fix with a reference to 5.8.2.2. >=20 > L24. Section A.3.8: > "the number of GIST payloads translated by the NAT" >=20 > The NAT? There might be several NATs on the path and it is=20 > not clear how=20 > that is handled. One concern would be if different NATs translate=20 > different fields. See separate answer to M3. (There is an answer to this point but the spec needs an update to include it.) >=20 > L25. Section 4.1 >=20 > The Info Count Field and Info fields. I think the rules regarding=20 > ordering of these are to weak. As the order and existence of=20 > fields are=20 > dependent on the error codes and sub-error code, it is important to=20 > clarify that with normative strength. So please state the rules that=20 > applies for resolving the additional data fields and for each=20 > error code=20 > be clearer on the additional data field. Being explicit in=20 > stating none=20 > for those that have none is a good idea. The idea is that the "template" for the sections A.4.4.x tells you this pretty strictly by virtue of the "Additional Info: " line given for each error condition. But we can try to make that more formal in some way. >=20 >=20 > Nits > ---- >=20 > N1. There is quite a list of abbreviation used in this=20 > document without=20 > being spelled out at their first usage. Please correct. I=20 > have spotted=20 > the following ones: > - NSLPID > - RAO > - SCD > - N-SM > - C-mode > - Q-mode OK. >=20 > N2. Section 3.4, last paragraph: >=20 > "A consequence of this > design is that signaling applications should choose SIDs=20 > so that they > are cryptographically random, and should not use several=20 > SIDs for the > same flow unless strictly necessary, to avoid additional load from > routing state maintenance." >=20 > I think there is need for a reference to a document on how to achieve=20 > cryptographically random numbers. Is RFC 4086 a useful ref? OK. >=20 > N3. section 6.1: >=20 > " Rule 4 (rx_Data): >=20 > if (node policy will only process Data messages with matching > routing state) then > send "No Routing State" error message > else > pass directly to NSLP" >=20 > It seems to me that the expression within the IF is wrongly=20 > defined. I=20 > think it should read: >=20 > if (routing state exist) then > pass to NSLP > else > Send error msg. Nope; if routing state already existed, this state machine would not be invoked (the message goes straight to 6.2/6.3). Some messages can still be processed even if no routing state exists, which is=20 what this event is supposed to capture. >=20 >=20 > N4. figure 7: The established to established arrow has=20 > "[!confirmRequired]" which is a bit confusing on what it=20 > applies to of=20 > the above cases. OK. >=20 >=20 > N5. Section 7.1.2: > Please include a reference for OSPF. OK. >=20 > N6. Section 7.2: >=20 > It uses "public" and "private" when referring to the=20 > different sides of=20 > a NAT. In BEHAVE WG they are using External and Internal instead. The=20 > reason is due to that the external side of a NAT may still be=20 > a private=20 > address space. OK. >=20 > N7. Section 11: > Ref 6 and 8 needs to be updated yes for 8, but isn't 6 still the authoritative reference for TLS1.0? (So, this depends on the answer to L13). >=20 > N8. Section A.3.5: > "MUST not" -> "MUST NOT" OK >=20 > N9. Section A.4.4.9: subcode 3: >=20 > "Invalid Object" -> "Invalid Object Type"? OK. >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 00:11:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm10l-0004j1-65; Fri, 02 Jun 2006 00:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm0xZ-0000Es-Oa; Fri, 02 Jun 2006 00:08:29 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm0xY-0007nT-9D; Fri, 02 Jun 2006 00:08:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5248Lgw014308; Fri, 2 Jun 2006 07:08:27 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 07:08:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 07:08:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jun 2006 07:08:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Thread-Index: AcaF+WZhH9EgFo7gTBuFVa/fJ/m3RAAAKfCw From: Bcc: X-OriginalArrivalTime: 02 Jun 2006 04:08:26.0633 (UTC) FILETIME=[32BEEF90:01C685FA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Fri, 02 Jun 2006 00:11:45 -0400 Subject: [NSIS] FW: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Here are the Internet cut-off dates for the next IETF. If you have any drafts that you think should be WG drafts (not individual submissions), please notify me, as these need special approval. thanks, John=20 >-----Original Message----- >From: ext ietf-announce-bounces@ietf.org=20 >[mailto:ietf-announce-bounces@ietf.org]=20 >Sent: 02 June, 2006 07:00 >To: ietf-announce@ietf.org >Subject: Internet-Drafts Submission Cutoff Dates for the 66th=20 >IETF Meeting in Montreal, Quebec, Canada=20 > > >There are two (2) Internet-Draft cutoff dates for the 66th=20 >IETF Meeting in Montreal, Quebec, Canada: > >June 19th: Cutoff Date for Initial (i.e., version -00)=20 >Internet-Draft Submissions=20 > >All initial Internet-Drafts (version -00) must be submitted by=20 >Monday, June 19th at 9:00 AM ET. As always, all initial=20 >submissions with a filename beginning with "draft-ietf" must=20 >be approved by the appropriate WG Chair before they can be=20 >processed or announced. The Secretariat would appreciate=20 >receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. > >June 26th: Cutoff Date for Revised (i.e., version -01 and=20 >higher) Internet-Draft Submissions=20 > >All revised Internet-Drafts (version -01 and higher) must be=20 >submitted by Monday, June 26th at 9:00 AM ET. > >Initial and revised Internet-Drafts received after their=20 >respective cutoff dates will not be made available in the=20 >Internet-Drafts directory or announced until on or after=20 >Monday, July 10th at 9:00 AM ET, when Internet-Draft posting=20 >resumes. Please do not wait until the last minute to submit. > >Thank you for your understanding and cooperation. If you have=20 >any questions or concerns, then please send a message to=20 >internet-drafts@ietf.org. > >The IETF Secretariat > >FYI: The Internet-Draft cutoff dates as well as other=20 >significant dates for the 66th IETF Meeting can be found at=20 >http://www.ietf.org/meetings/cutoff_dates_66.html. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 04:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5Ai-0006Kg-6n; Fri, 02 Jun 2006 04:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5Ah-0006Fe-7r for nsis@ietf.org; Fri, 02 Jun 2006 04:38:19 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm5Af-0001yZ-Ot for nsis@ietf.org; Fri, 02 Jun 2006 04:38:19 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k528c8WH024065; Fri, 2 Jun 2006 09:38:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In-Reply-To: <447EF837.7070808@ericsson.com> X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OlkEid: 88A45224A111EB0122A1DE4A9B3BAEFF90908F33 Content-class: urn:content-classes:message Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M4: IANA considerations) Date: Fri, 2 Jun 2006 09:38:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M4: IANA considerations) Thread-Index: AcaGH99L/m+bI5DkStSt9qaXphuaSA== From: "Hancock, Robert" To: "Magnus Westerlund" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all (especially Magnus and John), comments on the IANA aspects: > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 01 June 2006 15:23 > To: nsis@ietf.org > Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 [snip] > M4. IANA consideration section >=20 > I think the IANA consideration section is lacking in several ways. >=20 > A. Decision criteria for IESG, Expert review or other=20 > policies are not=20 > written. The WG should provide some guidelines for what is=20 > acceptable to=20 > be registered and what is not. This is a document roadmap issue; there are several different ways in which NSIS (as a protocol suite) can be extended to meet=20 an engineering goal, sometimes involving GIST, sometimes NSLPs and sometimes both, the idea is to centralise this discussion in one document, currently draft-loughney-nsis-ext (which is reference [36]). Maybe the first paragraph of section 9 should=20 state this more strongly, and maybe [36] should be normative. >=20 > B. There is no explanation for the large blocks of reserved=20 > codes that=20 > exist. The rationale is that "If the current allocation policy turns out to be wrong [e.g. because you suddenly start to run out in a particular class] then the reserved space can be used for a second attempt." I'm sure I had seen this in 2434, but it certainly isn't there any more ;-) We could include that rationale more explicitly, or a different=20 rationale, or change the registry structure. Opinions welcome. >=20 > C. No rules for what is required to be included in an application for=20 > assignment in any of these spaces. I'm not sure I really follow this. For example, for error codes, it's stated that the error class and additional info format must be defined; for object types, it's stated that the AB flags must be defined (maybe one could add that the object format is also needed); for MRMs there is a reference to section 3.3 which describes what information is needed for a new MRM. In some cases (such as new message type) I'm not sure what to say beyond 'specification' since the range of things that could be needed is so large. One aspect of this relates to document structure/section content assumptions. The advice we got was to make section 9 purely aimed at IANA and the mechanics needed to get the registry structure=20 and policies documented correctly, on the assumption that IANA will read nothing else. It therefore intentionally doesn't contain all=20 the information/guidance that is needed to extend the protocol; implicitly one is relying on the expertise of the people called up in the policy (ietf/iesg/expert/whoever) to be familiar enough with the specification as a whole to demand the right sort of additional detail if it isn't already provided. It may be that this is the Wrong Way to do things. More guidance needed ... >=20 > D. The NSLP ID policy. Is it really envisioned that GIST will only be=20 > used for NSLPs for which it is suitable that the IESG make=20 > decision on=20 > them? Wouldn't a better policy be expert review or something which is=20 > having a bit of lower bar. Having all proprietary users of=20 > GIST run to=20 > the IESG for approval seems strange. This is probably an oversight, and we could certainly put in some expert review/specification required space as well as the experimental values. (But see under [A] above for discussion of where guidance is written down, which applies most strongly for this particular registry.) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 05:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5xi-00070V-UI; Fri, 02 Jun 2006 05:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5xh-0006zg-KW for nsis@ietf.org; Fri, 02 Jun 2006 05:28:57 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm5xh-00067w-0a for nsis@ietf.org; Fri, 02 Jun 2006 05:28:57 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k529Sdfl000315; Fri, 2 Jun 2006 10:28:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues) Date: Fri, 2 Jun 2006 10:28:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues) Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AAmOqzQ From: "Hancock, Robert" To: "Magnus Westerlund" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, comments on the congestion control/rate limiting issues (M1 and in fact L16-part as well): > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 01 June 2006 15:23 > To: nsis@ietf.org > Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >=20 > M1. Congestion Control >=20 > This affects text not only in 5.3.3 but also 7.1.3 and possibly other=20 > places. But I do have a general concern that the congestion control=20 > measurements described in the specification is underspecified. >=20 > First in 5.3.3 I don't see any normative minimal values, or even=20 > recommended values for T1 and T2 that will be safe to deploy on the=20 > internet. I don't find it acceptable that the developer needs to=20 > investigate which values that are safe to use and which are=20 > not. There=20 > should also be some criteria documented for when it is=20 > acceptable to go=20 > beyond these values. So my concern here is that the=20 > retransmission runs=20 > havoc and create way to many packets to be sent. This is a fair point. I suppose it is impossible to get away permanently without giving concrete numbers in this case. In terms of what sort of values to use and how to describe the constraints on them, I think a good model to follow is probably the SIP INVITE transaction specification (17.1.1.2 of rfc3261) which says [fortunately the timer names are the same...] " The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions. Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used." and later that T2 should be 64*T1. In our case, 500ms seems a reasonable default also; I think T2<=3D64*T1 since there is a separate bound on the T2 value from the signalling application (see the second paragraph of 5.3.3). I would be tempted to relax the NOT RECOMMENDED clause, since a smaller timeout would be valid and possibly quite useful on a wider range of networks, in particular Internet-connected networks but where it is known that the Query should be answered within the local network. Comments and text suggestions welcome. >=20 > Secondly, there are also no values documented for the rate control. I=20 > think it is necessary to document what internet safe values=20 > are here so=20 > that one does not cause problems. In addition is seems a bit=20 > simplistic=20 > to use a token bucket with some parameters selected based on=20 > the local=20 > link as GIST clearly sends messages beyond the local link. Thus one=20 > might have to consider being a bit smarter and more adaptive=20 > to what is=20 > seen for different flows. Here I am not so sure. The text here was informed by the equivalent discussion for ICMPv6 (reference [26], now RFC4443), which caused an extensive thread on the v6 mailing list (start at http://www1.ietf.org/mail-archive/web/ipv6/current/msg01343.html + another 60 or so messages). GIST is not ICMP but many of the same issues arise: messages are generated in the IP 'control plane' (in so far as this is a meaningful term), partly autonomously but mainly in response to events initiated by end systems, the messages go beyond the local link, rules have to be written so they apply to a host and a core router and everything in between. The end result for ICMP was to=20 write something minimal. (The link bandwidth here is used as an indicator for where a router is in a network - core/access/whatever. It's clearly imperfect but there's nothing else apart from dynamic adaptiveness to make use of, and fixed values seem even worse.) We'd really like to avoid adaptiveness in the D-mode state machine. The main use of D-mode should be for Queries/Responses for which=20 adaptation is not meaningful for initial messages (there is no pre-existing state); if there is a large amount of signalling data to send for a given flow, then GIST should transition to C-mode anyway, and the rate limits chosen to be cautious to encourage that. We aimed for robustness and simplicity rather than performance. It might be possible to use some sort of adaptiveness to select an appropriate rate to apply to refresh queries used for GIST probing (see also your point at the end of L16). The current situation is that you can probe as fast as you like until you hit the rate limit, and that it's up to the implementer to decide how fast is really necessary depending on an assessment of route stability (for which I don't know any good objective estimator). On the assumption that=20 most probes will go to the peer you already know about, one could refine this to apply a separate token bucket limiter for probe=20 messages towards that peer, which was adapted according to knowledge of congestion state with that peer (based on message loss). We need input on whether that complexity is really necessary however, since it doesn't change the situation for the whole of D-mode but just a particular subset of it. >=20 > Third, the implication and congestion issues with local=20 > repair seems to=20 > have been brushed over. Section 7.1.3 do indicate that you=20 > need to take=20 > care, but nothing more. Are there some potential for=20 > aggregation of the=20 > queries to minimize the load and have quicker convergence? There is no mechanism that I can think of. Certainly there is no aggregation possible in general, since every affected flow might be affected differently, especially if next-NSIS-routers are many hops away. We depend on the rate limiting to prevent the generated Queries causing a flood, but that's about it.=20 (There are aggregation techniques for transmitting the notifications, but they take place at the NSLP level.) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 06:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6Rt-0001WP-3N; Fri, 02 Jun 2006 06:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6Rs-0001WK-F3 for nsis@ietf.org; Fri, 02 Jun 2006 06:00:08 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm6Rr-0000Ry-UN for nsis@ietf.org; Fri, 02 Jun 2006 06:00:08 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k529xjCW006403; Fri, 2 Jun 2006 10:59:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) Date: Fri, 2 Jun 2006 10:59:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AAoBqRA From: "Hancock, Robert" To: "Magnus Westerlund" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, comments on the NAT traversal questions (M3, also L2/L19/L24): > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 01 June 2006 15:23 > To: nsis@ietf.org > Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >=20 >=20 > Hi, >=20 > M3. NAT traversal for GIST. > Section 7.2: >=20 > What plans are there for clearly defining NAT behavior for=20 > GIST and the=20 > relevant NSLPs? I think one should avoid repeating the=20 > mistake with NATs=20 > of not specifying the behavior sufficiently for NSIS. Thus I=20 > think there=20 > is need to specify in great deal what is going to happen at=20 > the translation. There is already an individual I-D which describes the required behaviour on a NAT, draft-pashalidis-nsis-gimps-nattraversal-02.txt (see in particular section 6). I believe that this document should become a working group document (of at least some working group - I'm not clear on the relationship with behave here).=20 What we've tried to do so far is distinguish the GIST specification, i.e. what nodes implementing GIST have to do, from the NAT specification, i.e. what NAT nodes have to do with GIST messages. The overall solution is outlined here in the GIST spec, but there is a lot more detail that can be added about what NATs should do (specifically in terms of managing their bindings) which is not really a concern of the GIST implementor so it seems reasonable to keep the two separate. > L2. Section 3.3, page 12, second paragraph: > " In addition, it should be noted that NAT traversal almost certainly > requires transformation of the MRI field in GIST messages (see > Section 7.2). Although the transformation does not have to be > defined as part of the standard, the impact on existing GIST-aware > NAT implementations should be considered." >=20 > It seems that not defining the NAT behavior for GIST can potentially=20 > cause interop problems and make it very hard to use. What is=20 > the plans=20 > for addressing this? Are there already existing GIST-aware NATs? This is probably badly worded. What we are trying to say is that,=20 just as there is a split: a) the GIST spec, and b) how NATs handle GIST messages when you define a new MRM there are two things to do: a') how to modify GIST implementations to handle the MRM b') how to modify NATs to handle the new MRM Section 3.3 is saying that the information provided as part of (a') does not have to define all the details of NAT traversal,=20 but that (b') has to be considered, e.g. if necessary as an=20 extension to the base GIST nat traversal specification. (As an aside, there is conceptually a class of MRMs that will in fact be transparent to NATs. It may be valuable to highlight those in some way so that they can be deployed without having to update NATs where the update only consists of the information "you don't have=20 to do anything".) (Another aside: the GIST NAT traversal functionality has been implemented by at least one team. I don't believe it has made it into any standard distributions. The 'existing' in the spec means 'existing at the time that the new MRM is being proposed'.) > L19. Section 7.2, page 74: >=20 > "Note that Confirm messages are not translated." >=20 > Why isn't them? Also where is that specified? And what is=20 > really meant=20 > with "not translated"? Well, the solution is designed so they don't need to be translated.=20 (If they did, it would be very tricky, since often they are=20 carried in C-mode and are invisible to NATs anyway.) Probably the specification should say more explicitly "only Query messages=20 and messages with a NTO are translated by the NAT". "Not translated" means "the payload of the UDP message is not translated". So that can also be made more explicit. > L24. Section A.3.8: > "the number of GIST payloads translated by the NAT" >=20 > The NAT? There might be several NATs on the path and it is=20 > not clear how=20 > that is handled. One concern would be if different NATs translate=20 > different fields. The idea is that the 'list of translated objects' field contains the objects that have been successfully translated by every NAT. In other words, it is the intersection of the translation capabilities of the set of traversed NATs. The first NAT initialises it, subsequent NATs may have to remove objects which it could not translate. The "Type-Count" field is just the length of this list (to allow the message to be parsed). This needs to be made clearer in the spec. cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 07:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7jp-0004bT-Rd; Fri, 02 Jun 2006 07:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7jp-0004bO-Cv for nsis@ietf.org; Fri, 02 Jun 2006 07:22:45 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm7jn-0001Io-SJ for nsis@ietf.org; Fri, 02 Jun 2006 07:22:45 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k52BMExR021373; Fri, 2 Jun 2006 12:22:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 Date: Fri, 2 Jun 2006 12:22:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AApFY4g From: "Hancock, Robert" To: "Magnus Westerlund" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, the security issues, M2: > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 01 June 2006 15:23 > To: nsis@ietf.org > Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >=20 > M2. Security functions for d-mode >=20 > When reading the security consideration and the specification on=20 > security properties I get a bit frightened that there are no=20 > authentication mechanism specified for d-mode. It seems that there=20 > should be need for authentication of d-mode queries etc to=20 > ensure that=20 > the a NSIS node is talking to someone that really has the right to=20 > perform the query and association creation.=20 This is an important question. Some high level analysis: *) d-mode basically has two functions:=20 - to set up routing state - to set up messaging associations Authentication/authorisation of the 'right' to set up the MAs is actually handled within the MA protocols themselves (if you=20 use TLS or whatever). This can use traditional cryptographic security techniques. So there should be no d-mode security issue here. Authentication/authorisation of the 'right' to set up routing state is a more tricky. The point is that there is no framework=20 within which the correctness of routing state can be secured in the traditional sense. Whether or not a node is on the route of a flow is a dynamic function of the forwarding tables in the network as a whole; two nodes could authenticate with each other all that they want to, but this would tell us nothing about=20 whether the routing state itself was correct, since that can only be done by interaction with the forwarding layer. A further point is that at the start of the d-mode exchange, you can no idea which peer you are going to be communicating with, so at least some unauthenticated discovery phase would be needed anyway. The GIST design is supposed to restrict the scope of d-mode to this initial phase, and move over directly to c-mode as soon as it is meaningful to do so. Section 8.3 is supposed to be about the sort of 'non-cryptographic'=20 authentication which can/must be done in these circumstances. > Not having such a=20 > mechanism=20 > seems to prevent building a system where the domains edge=20 > nodes handles=20 > the primary security and the internal nodes only accept GIST messages=20 > that are authenticated by nodes belonging to the domain. I don't understand the problem here. There is nothing to stop a domain being deployed with the security model you indicate; for example: - a host initiates the GIST handshake with the appropriate edge node, sets up routing state and a messaging association - the edge node authenticates the host as part of the MA setup and decides what the host is allowed to do - the host initiates some signalling application transaction - if the edge node decides the signalling transaction is valid,=20 it continues to execute the transaction on the domain interior nodes (GIST handshake for route discovery followed by a signalling application exchange; typically the necessary MAs would already be in place).=20 is this the sort of model you are thinking about? >=20 > Section 8.6: I also am concerned that if there exist no secured MA=20 > between two GIST nodes, a on-path Man in the middle can prevent there=20 > from ever existing a secured MA. This is not what 8.6 is aiming at. Modulo the residual threat in 8.7, 8.6 is saying that - IF you have a suitable security policy and credentials at each node (and 8.6 explains what 'suitable' means) - THEN the only things that an on-path MitM can do are=20 (a) prevent all communication (b) allow a properly secured MA which it cannot intercept The MitM cannot do (c) allow an insecure MA which it can intercept (a) is not something that any security solution can prevent: an on-path MitM can always just block traffic. (b) is the desired outcome anyway. What is ruled out is (c), which is a consequence of the MitM detection mechanism in the Confirm and the security policy which says what to do if the MitM is detected. (Basically, any attempt to set up an insecure MA is automatically detected as an MitM attack.) cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 08:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Xs-0007T3-Jt; Fri, 02 Jun 2006 08:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Xr-0007Sx-0m for nsis@ietf.org; Fri, 02 Jun 2006 08:14:27 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8Xq-0005J7-4P for nsis@ietf.org; Fri, 02 Jun 2006 08:14:26 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52CENUU021497; Fri, 2 Jun 2006 15:14:25 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:14:24 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:14:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 Date: Fri, 2 Jun 2006 15:14:23 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AApFY4gAASUe0A= From: To: , , X-OriginalArrivalTime: 02 Jun 2006 12:14:23.0942 (UTC) FILETIME=[15DB3660:01C6863E] X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, >> M2. Security functions for d-mode >>=20 >> When reading the security consideration and the specification on=20 >> security properties I get a bit frightened that there are no=20 >> authentication mechanism specified for d-mode. It seems that there=20 >> should be need for authentication of d-mode queries etc to=20 >ensure that=20 >> the a NSIS node is talking to someone that really has the right to=20 >> perform the query and association creation. > >This is an important question. Some high level analysis: >*) d-mode basically has two functions:=20 >- to set up routing state >- to set up messaging associations > >Authentication/authorisation of the 'right' to set up the MAs=20 >is actually handled within the MA protocols themselves (if you=20 >use TLS or whatever). This can use traditional cryptographic=20 >security techniques. So there should be no d-mode security issue here. > >Authentication/authorisation of the 'right' to set up routing=20 >state is a more tricky. The point is that there is no=20 >framework within which the correctness of routing state can be=20 >secured in the traditional sense. Whether or not a node is on=20 >the route of a flow is a dynamic function of the forwarding=20 >tables in the network as a whole; two nodes could authenticate=20 >with each other all that they want to, but this would tell us=20 >nothing about whether the routing state itself was correct,=20 >since that can only be done by interaction with the forwarding=20 >layer. A further point is that at the start of the d-mode=20 >exchange, you can no idea which peer you are going to be=20 >communicating with, so at least some unauthenticated discovery=20 >phase would be needed anyway. >The GIST design is supposed to restrict the scope of d-mode to=20 >this initial phase, and move over directly to c-mode as soon=20 >as it is meaningful to do so. > >Section 8.3 is supposed to be about the sort of 'non-cryptographic'=20 >authentication which can/must be done in these circumstances. I agree with Robert's analysis here. Magnus, do you feel that anything should be added to the Security Considerations (that is not already there) on this issue? >> Not having such a mechanism >> seems to prevent building a system where the domains edge nodes=20 >> handles the primary security and the internal nodes only accept GIST=20 >> messages that are authenticated by nodes belonging to the domain. > >I don't understand the problem here. There is nothing to stop=20 >a domain being deployed with the security model you indicate; for >example: >- a host initiates the GIST handshake with the appropriate=20 >edge node, sets up routing state and a messaging association >- the edge node authenticates the host as part of the MA setup=20 >and decides what the host is allowed to do >- the host initiates some signalling application transaction >- if the edge node decides the signalling transaction is=20 >valid, it continues to execute the transaction on the domain=20 >interior nodes (GIST handshake for route discovery followed by=20 >a signalling application exchange; typically the necessary MAs=20 >would already be in place).=20 > >is this the sort of model you are thinking about? Agreed - this is a sort of a deployment considerations topic, depending upon what kind of network you are looking at. I'm not sure if this would go into a base spec, but maybe a deployment guide, BCP or applicability statement, IMO. >> Section 8.6: I also am concerned that if there exist no secured MA=20 >> between two GIST nodes, a on-path Man in the middle can prevent there >> from ever existing a secured MA. > >This is not what 8.6 is aiming at. Modulo the residual threat=20 >in 8.7, 8.6 is saying that >- IF you have a suitable security policy and credentials at=20 >each node (and 8.6 explains what 'suitable' means) >- THEN the only things that an on-path MitM can do are >(a) prevent all communication >(b) allow a properly secured MA which it cannot intercept The=20 >MitM cannot do >(c) allow an insecure MA which it can intercept Robert, I'm not sure if I can exactly parse (b), though I get your point ... >(a) is not something that any security solution can prevent:=20 >an on-path MitM can always just block traffic. (b) is the=20 >desired outcome anyway. >What is ruled out is (c), which is a consequence of the MitM=20 >detection mechanism in the Confirm and the security policy=20 >which says what to do if the MitM is detected. (Basically, any=20 >attempt to set up an insecure MA is automatically detected as=20 >an MitM attack.) Again, I agree with Robert's analsys here - do we need any additional text? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 08:17:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8ai-0001pu-GR; Fri, 02 Jun 2006 08:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8ag-0001pm-Bj for nsis@ietf.org; Fri, 02 Jun 2006 08:17:22 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8af-0005Xi-QA for nsis@ietf.org; Fri, 02 Jun 2006 08:17:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52CHKw0003325; Fri, 2 Jun 2006 15:17:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:17:19 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:17:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) Date: Fri, 2 Jun 2006 15:17:18 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AAoBqRAAAXB0qA= From: To: , , X-OriginalArrivalTime: 02 Jun 2006 12:17:18.0676 (UTC) FILETIME=[7E018140:01C6863E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, >> M3. NAT traversal for GIST. >> Section 7.2: >>=20 >> What plans are there for clearly defining NAT behavior for GIST and=20 >> the relevant NSLPs? I think one should avoid repeating the mistake=20 >> with NATs of not specifying the behavior sufficiently for NSIS. Thus I=20 >> think there is need to specify in great deal what is going to happen=20 >> at the translation. > >There is already an individual I-D which describes the=20 >required behaviour on a NAT,=20 >draft-pashalidis-nsis-gimps-nattraversal-02.txt >(see in particular section 6). I believe that this document=20 >should become a working group document (of at least some=20 >working group - I'm not clear on the relationship with behave here).=20 I think that the NAT traversal material should belong in a separate document - as we have seen with STUN, for example, the NAT considerations change - so I think it makes sense to have it separate. >What we've tried to do so far is distinguish the GIST=20 >specification, i.e. what nodes implementing GIST have to do,=20 >from the NAT specification, i.e. what NAT nodes have to do=20 >with GIST messages. >The overall solution is outlined here in the GIST spec, but=20 >there is a lot more detail that can be added about what NATs=20 >should do (specifically in terms of managing their bindings)=20 >which is not really a concern of the GIST implementor so it=20 >seems reasonable to keep the two separate. Agreed. >> L2. Section 3.3, page 12, second paragraph: >> " In addition, it should be noted that NAT traversal almost certainly >> requires transformation of the MRI field in GIST messages (see >> Section 7.2). Although the transformation does not have to be >> defined as part of the standard, the impact on existing GIST-aware >> NAT implementations should be considered." >>=20 >> It seems that not defining the NAT behavior for GIST can potentially=20 >> cause interop problems and make it very hard to use. What is the plans=20 >> for addressing this? Are there already existing GIST-aware NATs? > >This is probably badly worded. What we are trying to say is=20 >that, just as there is a split: >a) the GIST spec, and >b) how NATs handle GIST messages > >when you define a new MRM there are two things to do: >a') how to modify GIST implementations to handle the MRM >b') how to modify NATs to handle the new MRM > >Section 3.3 is saying that the information provided as part of >(a') does not have to define all the details of NAT traversal,=20 >but that (b') has to be considered, e.g. if necessary as an=20 >extension to the base GIST nat traversal specification. I think a rewording of the text in 3.3 would be a good idea. >(As an aside, there is conceptually a class of MRMs that will=20 >in fact be transparent to NATs. It may be valuable to=20 >highlight those in some way so that they can be deployed=20 >without having to update NATs where the update only consists=20 >of the information "you don't have to do anything".) > >(Another aside: the GIST NAT traversal functionality has been=20 >implemented by at least one team. I don't believe it has made=20 >it into any standard distributions. The 'existing' in the spec=20 >means 'existing at the time that the new MRM is being proposed'.) > >> L19. Section 7.2, page 74: >>=20 >> "Note that Confirm messages are not translated." >>=20 >> Why isn't them? Also where is that specified? And what is really meant=20 >> with "not translated"? > >Well, the solution is designed so they don't need to be translated.=20 >(If they did, it would be very tricky, since often they are=20 >carried in C-mode and are invisible to NATs anyway.) Probably=20 >the specification should say more explicitly "only Query=20 >messages and messages with a NTO are translated by the NAT". > >"Not translated" means "the payload of the UDP message is not=20 >translated". So that can also be made more explicit. Please do make it more explicit. >> L24. Section A.3.8: >> "the number of GIST payloads translated by the NAT" >>=20 >> The NAT? There might be several NATs on the path and it is not clear=20 >> how that is handled. One concern would be if different NATs translate >> different fields. > >The idea is that the 'list of translated objects' field=20 >contains the objects that have been successfully translated by=20 >every NAT. >In other words, it is the intersection of the translation=20 >capabilities of the set of traversed NATs. The first NAT=20 >initialises it, subsequent NATs may have to remove objects=20 >which it could not translate. >The "Type-Count" field is just the length of this list (to=20 >allow the message to be parsed). This needs to be made clearer=20 >in the spec. If you can add this to your ToDo list for the update, that would be great. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 08:20:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8dH-0002BQ-MJ; Fri, 02 Jun 2006 08:20:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8dF-0002BL-MW for nsis@ietf.org; Fri, 02 Jun 2006 08:20:01 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8dF-0005iM-3D for nsis@ietf.org; Fri, 02 Jun 2006 08:20:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52CJxFn026591; Fri, 2 Jun 2006 15:20:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:19:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:19:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestioncontrol/rate limiting issues) Date: Fri, 2 Jun 2006 15:19:59 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestioncontrol/rate limiting issues) Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AAmOqzQAAepPMA= From: To: , , X-OriginalArrivalTime: 02 Jun 2006 12:19:59.0599 (UTC) FILETIME=[DDEC67F0:01C6863E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, >> M1. Congestion Control >>=20 >> This affects text not only in 5.3.3 but also 7.1.3 and=20 >possibly other=20 >> places. But I do have a general concern that the congestion control=20 >> measurements described in the specification is underspecified. >>=20 >> First in 5.3.3 I don't see any normative minimal values, or even=20 >> recommended values for T1 and T2 that will be safe to deploy on the=20 >> internet. I don't find it acceptable that the developer needs to=20 >> investigate which values that are safe to use and which are not. There=20 >> should also be some criteria documented for when it is acceptable to=20 >> go beyond these values. So my concern here is that the retransmission >> runs havoc and create way to many packets to be sent. > >This is a fair point. I suppose it is impossible to get away=20 >permanently without giving concrete numbers in this case. > >In terms of what sort of values to use and how to describe the=20 >constraints on them, I think a good model to follow is=20 >probably the SIP INVITE transaction specification (17.1.1.2 of=20 >rfc3261) which says [fortunately the timer names are the same...] > >" The default value for T1 is 500 ms. T1 is an estimate of the RTT > between the client and server transactions. Elements MAY (though it > is NOT RECOMMENDED) use smaller values of T1 within closed, private > networks that do not permit general Internet connection. T1 MAY be > chosen larger, and this is RECOMMENDED if it is known in advance > (such as on high latency access links) that the RTT is larger. > Whatever the value of T1, the exponential backoffs on retransmissions > described in this section MUST be used." > >and later that T2 should be 64*T1. In our case, 500ms seems a=20 >reasonable default also; I think T2<=3D64*T1 since there is a=20 >separate bound on the >T2 value from the signalling application (see the second=20 >paragraph of 5.3.3). I would be tempted to relax the NOT=20 >RECOMMENDED clause, since a smaller timeout would be valid and=20 >possibly quite useful on a wider range of networks, in=20 >particular Internet-connected networks but where it is known=20 >that the Query should be answered within the local network.=20 >Comments and text suggestions welcome. What do you think of this, Magnus? >> Secondly, there are also no values documented for the rate control. I >> think it is necessary to document what internet safe values are here=20 >> so that one does not cause problems. In addition is seems a bit=20 >> simplistic to use a token bucket with some parameters selected based=20 >> on the local link as GIST clearly sends messages beyond the local=20 >> link. Thus one might have to consider being a bit smarter and more=20 >> adaptive to what is seen for different flows. > >Here I am not so sure. The text here was informed by the=20 >equivalent discussion for ICMPv6 (reference [26], now=20 >RFC4443), which caused an extensive thread on the v6 mailing=20 >list (start at=20 >http://www1.ietf.org/mail-archive/web/ipv6/current/msg01343.htm >l + another 60 or so messages). > >GIST is not ICMP but many of the same issues arise: messages=20 >are generated in the IP 'control plane' (in so far as this is=20 >a meaningful term), partly autonomously but mainly in response=20 >to events initiated by end systems, the messages go beyond the=20 >local link, rules have to be written so they apply to a host=20 >and a core router and everything in between. The end result=20 >for ICMP was to write something minimal. (The link bandwidth=20 >here is used as an indicator for where a router is in a=20 >network - core/access/whatever. >It's clearly imperfect but there's nothing else apart from=20 >dynamic adaptiveness to make use of, and fixed values seem even worse.) > >We'd really like to avoid adaptiveness in the D-mode state machine. >The main use of D-mode should be for Queries/Responses for=20 >which adaptation is not meaningful for initial messages (there=20 >is no pre-existing state); if there is a large amount of=20 >signalling data to send for a given flow, then GIST should=20 >transition to C-mode anyway, and the rate limits chosen to be=20 >cautious to encourage that. We aimed for robustness and=20 >simplicity rather than performance. > >It might be possible to use some sort of adaptiveness to=20 >select an appropriate rate to apply to refresh queries used=20 >for GIST probing (see also your point at the end of L16). The=20 >current situation is that you can probe as fast as you like=20 >until you hit the rate limit, and that it's up to the=20 >implementer to decide how fast is really necessary depending=20 >on an assessment of route stability (for which I don't know=20 >any good objective estimator). On the assumption that most=20 >probes will go to the peer you already know about, one could=20 >refine this to apply a separate token bucket limiter for probe=20 >messages towards that peer, which was adapted according to=20 >knowledge of congestion state with that peer (based on message=20 >loss). We need input on whether that complexity is really=20 >necessary however, since it doesn't change the situation for=20 >the whole of D-mode but just a particular subset of it. Comments on this? >> Third, the implication and congestion issues with local repair seems=20 >> to have been brushed over. Section 7.1.3 do indicate that you need to >> take care, but nothing more. Are there some potential for aggregation >> of the queries to minimize the load and have quicker convergence? > >There is no mechanism that I can think of. Certainly there is=20 >no aggregation possible in general, since every affected flow=20 >might be affected differently, especially if next-NSIS-routers=20 >are many hops away. We depend on the rate limiting to prevent=20 >the generated Queries causing a flood, but that's about it.=20 >(There are aggregation techniques for transmitting the=20 >notifications, but they take place at the NSLP level.) Comments on this? I'm wondering if we need to specify anything here, or just indicate what one should be aware of. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 08:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8hC-0006KT-0z; Fri, 02 Jun 2006 08:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8hA-0006HY-Qb for nsis@ietf.org; Fri, 02 Jun 2006 08:24:04 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8h9-00061d-5e for nsis@ietf.org; Fri, 02 Jun 2006 08:24:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52CNv98030349; Fri, 2 Jun 2006 15:24:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:24:01 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:23:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M4: IANAconsiderations) Date: Fri, 2 Jun 2006 15:23:57 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M4: IANAconsiderations) Thread-Index: AcaGH99L/m+bI5DkStSt9qaXphuaSAAHw3hw From: To: , , X-OriginalArrivalTime: 02 Jun 2006 12:23:58.0500 (UTC) FILETIME=[6C51CE40:01C6863F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert, >> M4. IANA consideration section >>=20 >> I think the IANA consideration section is lacking in several ways. >>=20 >> A. Decision criteria for IESG, Expert review or other=20 >policies are not=20 >> written. The WG should provide some guidelines for what is=20 >acceptable=20 >> to be registered and what is not. > >This is a document roadmap issue; there are several different=20 >ways in which NSIS (as a protocol suite) can be extended to=20 >meet an engineering goal, sometimes involving GIST, sometimes=20 >NSLPs and sometimes both, the idea is to centralise this=20 >discussion in one document, currently draft-loughney-nsis-ext=20 >(which is reference [36]). Maybe the first paragraph of=20 >section 9 should state this more strongly, and maybe [36]=20 >should be normative. I think so - Magnus, what we want to do is have GIST as a good protocol spec, but address elsewhere the overall extensibility issues, etc. =20 >> B. There is no explanation for the large blocks of reserved codes that=20 >> exist. > >The rationale is that "If the current allocation policy turns=20 >out to be wrong [e.g. because you suddenly start to run out in=20 >a particular class] then the reserved space can be used for a=20 >second attempt." I'm sure I had seen this in 2434, but it=20 >certainly isn't there any more ;-) > >We could include that rationale more explicitly, or a=20 >different rationale, or change the registry structure.=20 >Opinions welcome. I'm more comfortable reserving blocks as unused. If GIST turns out to be wildly successful, then we can revise this at a later date. We don't want to allow a gold-rush mentality, allowing people to extend it in whatever way possible. >> C. No rules for what is required to be included in an application for >> assignment in any of these spaces. > >I'm not sure I really follow this. For example, for error=20 >codes, it's stated that the error class and additional info=20 >format must be defined; for object types, it's stated that the=20 >AB flags must be defined (maybe one could add that the object=20 >format is also needed); for MRMs there is a reference to=20 >section 3.3 which describes what information is needed for a=20 >new MRM. In some cases (such as new message type) I'm not sure=20 >what to say beyond 'specification' since the range of things=20 >that could be needed is so large. > >One aspect of this relates to document structure/section=20 >content assumptions. The advice we got was to make section 9=20 >purely aimed at IANA and the mechanics needed to get the=20 >registry structure and policies documented correctly, on the=20 >assumption that IANA will read nothing else. It therefore=20 >intentionally doesn't contain all the information/guidance=20 >that is needed to extend the protocol; implicitly one is=20 >relying on the expertise of the people called up in the policy=20 >(ietf/iesg/expert/whoever) to be familiar enough with the=20 >specification as a whole to demand the right sort of=20 >additional detail if it isn't already provided. > >It may be that this is the Wrong Way to do things. More=20 >guidance needed ... Yes. The extensibility draft (update coming) should have the application designer's rational for extending things. >> D. The NSLP ID policy. Is it really envisioned that GIST will only be >> used for NSLPs for which it is suitable that the IESG make decision on=20 >> them? Wouldn't a better policy be expert review or something which is >> having a bit of lower bar. Having all proprietary users of GIST run to=20 >> the IESG for approval seems strange. > >This is probably an oversight, and we could certainly put in=20 >some expert review/specification required space as well as the=20 >experimental values. (But see under [A] above for discussion=20 >of where guidance is written down, which applies most strongly=20 >for this particular registry.) Well, our former AD wanted to more tightly control this, but I think something along the lines of Expert Review / Spec Required would be OK to most of us here. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 08:26:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8jS-0001sh-NN; Fri, 02 Jun 2006 08:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8jR-0001sV-Ga for nsis@ietf.org; Fri, 02 Jun 2006 08:26:25 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8jQ-0006AZ-DO for nsis@ietf.org; Fri, 02 Jun 2006 08:26:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52CQKJA002075; Fri, 2 Jun 2006 15:26:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:26:18 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:26:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (minor issues and nits) Date: Fri, 2 Jun 2006 15:26:17 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (minor issues and nits) Thread-Index: AcaFhvvOfYVRj+/yQjqC/8hTUlbv6AAC9xuAACsywjA= From: To: , , X-OriginalArrivalTime: 02 Jun 2006 12:26:18.0215 (UTC) FILETIME=[BF989F70:01C6863F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2df02f1a0db129c5d94869f6959903ec Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Magnus & Robert -=20 I trust that Robert will update the points he agrees to, and Magnus can follow-up to the other responses. Most of this seems relatively straight-forward. thanks, John=20 >-----Original Message----- >From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]=20 >Sent: 01 June, 2006 19:42 >To: Magnus Westerlund; nsis@ietf.org >Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (minor=20 >issues and nits) > >Hi Magnus, > >Many thanks for the detailed review. I think I at least=20 >understand the bulk of the issues you raise, which is a good omen. > >This email has some initial comments on the minor issues/nits=20 >since a lot of them can be cleared up fairly easily. Anything=20 >that generates further discussion I will capture explicitly in=20 >our issue tracker as/when it happens. I'll write separate=20 >emails on the major issues M1-M4. > >Cheers, > >robert h. > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 01 June 2006 15:23 >> To: nsis@ietf.org >> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >>=20 >>=20 >> Hi, >>=20 >> I have finally finished my review of GIST. I do have a number of=20 >> comments and question with potentially serious implications. So lets=20 >> start with them. Please remember that I have only read it once plus=20 >> some checks of it when writing up things. So there might be=20 >cases when=20 >> a simple reference to where things are defined can resolve the issue. >>=20 >> I will also be on vacation 3rd-11th of June so do not expect any=20 >> response from me during this period. >>=20 >> Major issues >> ------------ >>=20 >> M1. Congestion Control >> M2. Security functions for d-mode >> M3. NAT traversal for GIST. >> M4. IANA consideration section > >will be covered in separate mails. > >>=20 >> Minor Issues >> ------------ >>=20 >> L1. The lack of a collected ABNF makes it hard to verify. Has the=20 >> present ABNF been run through any of the syntax checkers=20 >available at: >> http://tools.ietf.org/inventory/verif-tools ? > >earlier versions were certainly checked. the latest version=20 >passes Bill Fenner's checker with the exception that there are=20 >two common-headers, the second in the error message format.=20 >That will be fixed. > >>=20 >> L2. Section 3.3, page 12, second paragraph: >> " In addition, it should be noted that NAT traversal almost=20 >certainly >> requires transformation of the MRI field in GIST messages (see >> Section 7.2). Although the transformation does not have to be >> defined as part of the standard, the impact on existing=20 >GIST-aware >> NAT implementations should be considered." >>=20 >> It seems that not defining the NAT behavior for GIST can potentially=20 >> cause interop problems and make it very hard to use. What is=20 >the plans=20 >> for addressing this? Are there already existing GIST-aware NATs? > >See the (separate) answer on M3 (to come). > >>=20 >> L3. Section 4.1.2: >> "Reliability: This attribute may be 'true' or 'false'. For the case >> 'true', messages MUST be delivered to the signaling=20 >application=20 >> in >> the peer exactly once or not at all; if there is a=20 >chance that=20 >> the >> message was not delivered, an error MUST be indicated to the=20 >> local >> signaling application identifying the routing information for=20 >> the >> message in question." >>=20 >> How does one evaluate "if there is a chance that the message was not=20 >> delivered"? I think there is need for some clear definition on when=20 >> the normative requirement applies. > >This really depends on the protocol being used. In the current=20 >specification, you can only use Forwards-TCP to satisfy the=20 >reliable attribute, so I think there should be a reference to=20 >5.7.2 to say how a TCP user can detect that a message might=20 >not have been delivered. >This then becomes part of the rules for defining a new MA=20 >protocol (if you use it for reliability, indicate how failures=20 >are detected). > >>=20 >> L4. Have anyone considered if one can run draft-ietf-pmtud-method-06=20 >> style of MTU discovery with GIST D-mode? > >In theory this would be possible, however, the design=20 >rationale for splitting C/D modes suggests it's the wrong=20 >thing to do. The idea is to make the Query small and ideally=20 >robust against PMTU issues (since you have to do a Query for=20 >each flow), and amortise the cost of PMTUD over the lifetime=20 >of a MA (which can support multiple flows). We are also=20 >assuming that solid implementations of PMTUD get re-used by=20 >GIST implementations (because they are built into the MA=20 >protocols), rather than being built into GIST directly, so=20 >advances in PMTUD get incorporated automatically. > >>=20 >> L5. Section 5.1, page 33: >> "It MUST echo the >> MRI (with inverted direction), SID, and Responder-Cookie if the >> Response carried one;" >>=20 >> I don't think "with inverted direction" is really clear here.=20 >> What does=20 >> it mean to invert the direction of the MRI? > >Change D=3D0 ro D=3D1 or vice versa. Will clarify. > >>=20 >> L6. Section 5.2.1 and A.1: >>=20 >> I have some problems with that Section 5.2.1 first declares=20 >> that these=20 >> fields are present, while not defining them fully. Like nr of=20 >> bits etc.=20 >> Then section A.1 is also not a complete definition of the=20 >> fields in the=20 >> message. I think doing an informative reference in 5.2.1 is=20 >okay, and=20 >> then actually have a complete definition in A.1. > >OK > >>=20 >> I would also like to point out that unless you always write out the=20 >> number of bits a field have, and the fields in the order they=20 >> appear in=20 >> the graph you will confuse people reading it with text to speech=20 >> synthesis, like Sam Hartman. > >OK > >>=20 >> Do consider that these comments applies to also other=20 >> protocol elements=20 >> defined in appendix A, such as A.3.3. > >OK > >>=20 >> L7. Section 5.2.2: >> "If the message is downstream, the IP-TTL MUST be set to the TTL >> that will be set in the IP header for the message=20 >> (if this can >> be determined), or else set to 0." >>=20 >> How is a message "downstream" I think you need to specify if this=20 >> relates being sent in the downstream direction. > >OK, will clarify. > >>=20 >> L8. Section 5.3.2: >>=20 >> " GIST may send messages addressed as {flow sender, flow receiver} >> which could make their way to the flow receiver even if=20 >> that receiver >> were GIST-unaware. These should be rejected (with an=20 >> ICMP message) >> rather than delivered to the user application (which=20 >> would be unable >> to use the source address to identify it as not being part of the >> normal data flow). Therefore, a "well-known" port is required. >> " >>=20 >> I am having difficulties understanding how the end-peer could make a=20 >> difference between GIST messages going the whole way to the=20 >> end-peer per=20 >> design and those that should be rejected by the end-peer.=20 >> Please explain=20 >> what the intention here is. > >OK, an example: >GIST gets assigned the port number 5682. >A pair of endpoints (A, B) set up a media flow A->B. B is GIST >unaware, and the application get allocated port 5682 by the node's >OS (just by bad luck).=20 >As part of GIST signalling initiated by A, an intermediate node C >sends a Query which is received by B. > >This query now has source IP# of A and destination IP# of B and the=20 >same destination port as the media flow. So it may well be delivered=20 >to the media application (and look like garbage); if B checks the=20 >source port the problem will only arise if C happens to chose the >same source port for GIST as A did for the media flow. > >It may be that we don't have to worry about this in real life (i.e. >we accept that occasionally bad things happen). Else it should be >explained better ;-) > > >>=20 >> L9. Section 5.4.1: DCCP: >> The note on DCCP forgets one important factor. DCCP does not=20 >> provide any=20 >> reliability. > >It was implicit in the comment on fragmentation ... but we can >make it explicit. > >>=20 >> L10. Section 5.7.1: >> "However, the object >> contents MUST be retained only for the duration of the=20 >> Query/Response >> exchange and any following association setup, and afterwards >> discarded." >>=20 >> Is "afterwards" only to referring to completed or failed=20 >> association setup? > >Both. Probably we should define another default time here (cf. M1). > >>=20 >> L11. Section 5.7.1: >> "The responding node MUST verify this to ensure that no bidding-down >> attack has occurred; see Section 8.6 for further discussion." >>=20 >> As section 8.6 states this is not sufficient for detecting a=20 >> on-path man=20 >> in the middle attack. So I think the wording the the above=20 >> sentence is=20 >> to strong. > >I hope not: 8.6 is supposed to say that on-path man-in-the-middle=20 >attacks can be reliably detected (modulo the residual threat listed >in section 5.7). But maybe the correct phraseology would be along >the lines of saying that "*if* a bidding down attack is detected after >checking the SCD, then ..." (i.e. we accept that there may be false >negatives but that the MUST applies to the result of the verification). > >>=20 >> L12. Section 5.7.2: >>=20 >> What address is used in the TCP connection. The port is=20 >specified but=20 >> not the address. > >Destination address: As returned in the=20 >Network-Layer-Information in the >Response. >Source address: free. > >>=20 >> L13. Section 5.7.3: >>=20 >> Why is TLS 1.0 made mandatory and not TLS 1.1? > >Earlier, TLS1.1 was the mandatory one; but there was some expert >advice to the contrary; see >http://www1.ietf.org/mail-archive/web/nsis/current/msg05682.html. > >>=20 >> L14. Section 5.8.1.2: >> "In this case, it MUST use the signaling >> source address for the IP source address in order to=20 >> receive the ICMP >> error." >>=20 >> How can a sender of message sending a query using d-mode with=20 >> the flow=20 >> source address determine that it is a to small MTU that causes the=20 >> messages to be lost, rather than anything else? I think the=20 >> use of MUST=20 >> in this sentence is wrong. Is it something more than a informative=20 >> statement saying: To be able to receive ICMP messages the=20 >> message sender=20 >> needs to use his own address. > >OK; I think there is still a MUST here but the MUST applies to any >transmission with DF set (we don't care why a DF was set, but if it >was, you MUST use your own SA).=20 > >>=20 >> L15. Section 5.8.1.3: >>=20 >> Can someone please explain why an upstream request which has=20 >> traversed a=20 >> non-GIST aware router can be trusted less than a down stream one? > >Routing asymmetry and the (in)ability to apply ingress filtering. >It may be that we don't need to specify this tie-breaker aspect, >however. > >>=20 >> L16. Section 6.4, Rule 4: >>=20 >> Rule 4: >>=20 >> send MA-Hello message >> restart NoHello timer >>=20 >> why is the timeout of a send Hallo message timer reseting=20 >the NoHello=20 >> timer? Shouldn't the NoHello timer be only based on receiving Hello=20 >> messages from the other side? > >I suspect you are right here (should be the SendHello timer). > >>=20 >> Also what is the recommended Hello frequency? It would be=20 >> good to have=20 >> some discussion on what reasonable values are. This is also=20 >> part of the=20 >> congestion discussion for GIST. > >Partly true; however, I think the issues here are less critical, >since the Hello is only sent over MAs which are themselves congestion >controlled. > >>=20 >> Section 7.1.2: GIST probing: >>=20 >> One more missing recommendation on values for protocol functionality. > >See separate answer to M1. > >>=20 >> L17. Section 7.1.4: >>=20 >> Bullet 1: "The signaling >> application at E1 MAY begin local repair immediately, or MAY >> propagate a notification upstream to D1 that re-routing has >> occurred." >>=20 >> There seems to be a interaction between GIST and the signalling=20 >> application about the notification on the change. Are there any=20 >> recommendations on signalling application implementing the necessary=20 >> semantics to perform that notification? > >Yes, but only implicitly and in the NSLP specifications. Possibly there >should be >more explicit generic guidance on NSLP design, but it has not=20 >been clear >up=20 >to now where is the correct place to capture this information. (That >is, to a large extent I guess it would be preferable if NSLP designers >did not have to understand everything in GIST to be able to design an >NSLP properly.) > >>=20 >> L18. Section 7.2, page 73, last paragraph: >>=20 >> A NAT will intercept datagram mode messages with the normal >> encapsulation containing such echoed NAT-Traversal objects. >>=20 >> It is not obvious that a NAT will do this for d-mode. Isn't a=20 >> NAT which=20 >> is not made GIST aware simply going to translate the IP/UDP=20 >> headers and=20 >> forward the packet despite the router alert. > >Non-GIST aware NATs are out of scope. > >>=20 >> L19. Section 7.2, page 74: >>=20 >> "Note that Confirm messages are not translated." >>=20 >> Why isn't them? Also where is that specified? And what is=20 >> really meant=20 >> with "not translated"? > >See separate answer to M3. > >>=20 >> L20. Section A.2: >> The "r" bits are not explicitly written to fall under the=20 >> rules in the=20 >> last paragraph of that section. > >True (!) > >>=20 >> L21. Section A.2.1: >>=20 >> What is the treatment of the "reserverd" AB=3D11 for a GIST node? > >Good question; I suspect this should be an error case. > >>=20 >> L22. Section A.3.1: >>=20 >> The "MRM-ID" field is not having the same name as in the IANA=20 >> consideration section. > >OK. > >>=20 >> L23. Section A.3.1.2: >> "D - Direction (always 0 for "downstream")" >>=20 >> The use of "always" in the above make it unclear what is meant. > >The case D=3D1 is not allowed by the specification; we can fix >with a reference to 5.8.2.2. > >>=20 >> L24. Section A.3.8: >> "the number of GIST payloads translated by the NAT" >>=20 >> The NAT? There might be several NATs on the path and it is=20 >> not clear how=20 >> that is handled. One concern would be if different NATs translate=20 >> different fields. > >See separate answer to M3. (There is an answer to this point >but the spec needs an update to include it.) > >>=20 >> L25. Section 4.1 >>=20 >> The Info Count Field and Info fields. I think the rules regarding=20 >> ordering of these are to weak. As the order and existence of=20 >> fields are=20 >> dependent on the error codes and sub-error code, it is important to=20 >> clarify that with normative strength. So please state the rules that=20 >> applies for resolving the additional data fields and for each=20 >> error code=20 >> be clearer on the additional data field. Being explicit in=20 >> stating none=20 >> for those that have none is a good idea. > >The idea is that the "template" for the sections A.4.4.x tells you >this pretty strictly by virtue of the "Additional Info: " line=20 >given for > >each error condition. But we can try to make that more formal in >some way. > >>=20 >>=20 >> Nits >> ---- >>=20 >> N1. There is quite a list of abbreviation used in this=20 >> document without=20 >> being spelled out at their first usage. Please correct. I=20 >> have spotted=20 >> the following ones: >> - NSLPID >> - RAO >> - SCD >> - N-SM >> - C-mode >> - Q-mode > >OK. > >>=20 >> N2. Section 3.4, last paragraph: >>=20 >> "A consequence of this >> design is that signaling applications should choose SIDs=20 >> so that they >> are cryptographically random, and should not use several=20 >> SIDs for the >> same flow unless strictly necessary, to avoid additional=20 >load from >> routing state maintenance." >>=20 >> I think there is need for a reference to a document on how=20 >to achieve=20 >> cryptographically random numbers. Is RFC 4086 a useful ref? > >OK. > >>=20 >> N3. section 6.1: >>=20 >> " Rule 4 (rx_Data): >>=20 >> if (node policy will only process Data messages with matching >> routing state) then >> send "No Routing State" error message >> else >> pass directly to NSLP" >>=20 >> It seems to me that the expression within the IF is wrongly=20 >> defined. I=20 >> think it should read: >>=20 >> if (routing state exist) then >> pass to NSLP >> else >> Send error msg. > >Nope; if routing state already existed, this state machine would >not be invoked (the message goes straight to 6.2/6.3). Some messages >can still be processed even if no routing state exists, which is=20 >what this event is supposed to capture. > >>=20 >>=20 >> N4. figure 7: The established to established arrow has=20 >> "[!confirmRequired]" which is a bit confusing on what it=20 >> applies to of=20 >> the above cases. > >OK. > >>=20 >>=20 >> N5. Section 7.1.2: >> Please include a reference for OSPF. > >OK. > >>=20 >> N6. Section 7.2: >>=20 >> It uses "public" and "private" when referring to the=20 >> different sides of=20 >> a NAT. In BEHAVE WG they are using External and Internal=20 >instead. The=20 >> reason is due to that the external side of a NAT may still be=20 >> a private=20 >> address space. > >OK. > >>=20 >> N7. Section 11: >> Ref 6 and 8 needs to be updated > >yes for 8, but isn't 6 still the authoritative reference for TLS1.0? >(So, this depends on the answer to L13). > >>=20 >> N8. Section A.3.5: >> "MUST not" -> "MUST NOT" > >OK > >>=20 >> N9. Section A.4.4.9: subcode 3: >>=20 >> "Invalid Object" -> "Invalid Object Type"? > >OK. > >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> Multimedia Technologies, Ericsson Research EAB/TVA/A >>=20 >---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 08:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8lb-00067J-VK; Fri, 02 Jun 2006 08:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8la-00067E-OA for nsis@ietf.org; Fri, 02 Jun 2006 08:28:38 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8lZ-0006Sv-Ah for nsis@ietf.org; Fri, 02 Jun 2006 08:28:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52CSaoY000864; Fri, 2 Jun 2006 15:28:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:28:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 15:28:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 Date: Fri, 2 Jun 2006 15:28:04 +0300 Message-ID: In-Reply-To: <447EF837.7070808@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 Thread-Index: AcaFhxKuzbgWg4PCT82dmGnHWHv5SgAuLsLA From: To: , X-OriginalArrivalTime: 02 Jun 2006 12:28:04.0583 (UTC) FILETIME=[FEFF1770:01C6863F] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Magnus, Thanks for your close reading. I think Robert has replied to most of your comments - if you can do a quick cherry-picking & respond to the major issues, then hopefully Robert could work on updating those issues while you are on vacation. When you come back, we can resolve the rest & hopefully get this draft revised before the draft cut-off date. thanks, John=20 >-----Original Message----- >From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 >Sent: 01 June, 2006 17:23 >To: nsis@ietf.org >Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 > >Hi, > >I have finally finished my review of GIST. I do have a number=20 >of comments and question with potentially serious=20 >implications. So lets start with them. Please remember that I=20 >have only read it once plus some checks of it when writing up=20 >things. So there might be cases when a simple reference to=20 >where things are defined can resolve the issue. > >I will also be on vacation 3rd-11th of June so do not expect=20 >any response from me during this period. [rest mail clipped] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 02 09:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9dy-0002Of-34; Fri, 02 Jun 2006 09:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9dw-0002Oa-NU for nsis@ietf.org; Fri, 02 Jun 2006 09:24:48 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9dt-0005iN-AQ for nsis@ietf.org; Fri, 02 Jun 2006 09:24:48 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Fm9dm-0007cp-3o; Fri, 02 Jun 2006 15:24:44 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id CA27086A3; Fri, 2 Jun 2006 15:24:37 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Fm9dl-0006gp-Fn; Fri, 02 Jun 2006 15:24:37 +0200 Message-ID: <44803C14.3000904@tm.uka.de> Date: Fri, 02 Jun 2006 15:24:36 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] NSLP versioning References: <3F2E01E1D7B04F4EBEC92D3FA324D8807DCFB1@rsys004a.roke.co.uk> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Martin Stiemerling schrieb: > Dear all, > > There is still a not completely solved issue back from the old days > (2004) about NSLP versioning. It is about wether an NSLP can have > multiple versions or not. I would say yes, naturally it can. The question is probably what can be considered as an appropriate demultiplexer. So what is the issue exactly? Whether there should be an NSLP version field in the NSLP protocol itself? The current alternative is to use a different NSLP ID for each version, thus using the NSLP ID in GIST as demultiplexing value. Since the NSLP ID is 16bit I guess that there are no issues here. So as long as we assume GIST as underlying transport (or some other protocol at least carrying session ID, MRM, NSLPID and so on) there is no problem here. There is only trouble if all you have is the NSLP data packet alone. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jun 04 16:14:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmyz6-0002WS-Je; Sun, 04 Jun 2006 16:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmyz4-0002WD-DQ; Sun, 04 Jun 2006 16:14:02 -0400 Received: from natipslore.rzone.de ([81.169.145.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmyz1-0002bg-VK; Sun, 04 Jun 2006 16:14:02 -0400 Received: from [192.168.1.54] (p54B1B653.dip0.t-ipconnect.de [84.177.182.83]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k54KDsvf019442; Sun, 4 Jun 2006 22:13:55 +0200 (MEST) Message-ID: <44833E73.3030404@cs.uni-goettingen.de> Date: Sun, 04 Jun 2006 22:11:31 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org, nsis-imp@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: nsis_imp@cs.uni-goettingen.de, hannes.tschofenig@siemens.com Subject: [NSIS] Release of NSIS implementation (0.4.0) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, we would like to release a new version of the NSIS implementation (0.4.0) available at http://user.informatik.uni-goettingen.de/~nsis In order to permit linking the NSLP-API into non-free NSLPs the licenses of the corresponding files were changed into the Lesser GPL (LGPL). This release also contains a skeleton NSLP which can be used as a template to develop further NSLPs. These files are released under the 3-clause BSD-License. The rest of the project is still licensed under the GPL. Further changes are: * Changed buildsystem to automake and autoconf o Added support for FreeBSD, MacOSX o (As end-hosts, routers sniff but do not intercept RAO messages) o Added support for big-endian o IPv6 and SCTP are no longer required to build the package * Changed license o NSLP-API is now LGPL to allow usage in closed source NSLPs o New "skeleton NSLP" is BSD to allow building closed source NSLPs o The remaining code remains to be licensed under the GPL * Add richer support for SCTP * All modules now use a common configuration file * Improved documentation (introduced man pages) * Diagnostics NSLP added * Alignment to byte format of GIST-09 * Added "skeleton NSLP" for others to start creating own NSLPs. * QoS NSLP changes o IPv6 support added o QSPEC object support added o message processing refined o timer handling refined o QoSLogger support, improved debug levels o new structure of FSM-Code o man pages for nsis-qosd(8) and nsis-qos(1) added * Nat/Firewall NSLP changes o new Nat/Firewall NSLP client API o built-in GIST-independent protocol emulation o DebugLogger support, improved debug levels o rewritten Nat/Firewall NSLP client o more fine-grained command-line options o man pages for nsis-natfwd(8) and nsis-natfw(1) added o message parsing updated to draft-ietf-nsis-nslp-natfw-11 o replaced IP address/port placeholders o lots of minor protocol behavior improvements Xiaoming Fu Bernd Schloer Christian Dickmann Henning Peters University of Goettingen For further information =============================================================== Questions, inquiries, comments, please kindly report to the following mailing list: nsis_imp@cs.uni-goettingen.de To subscribe: send an email to nsis_imp-request@cs.uni-goettingen.de with the text subscribe YOUR-EMAIL-ADDRESS in the message body. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 06 16:38:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniJj-000465-U6; Tue, 06 Jun 2006 16:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FniJi-000460-5Y for nsis@ietf.org; Tue, 06 Jun 2006 16:38:22 -0400 Received: from exchfe1.cs.cornell.edu ([128.84.97.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FniJh-0003aN-Nv for nsis@ietf.org; Tue, 06 Jun 2006 16:38:22 -0400 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.42]) by exchfe1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 16:38:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jun 2006 16:38:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Offpath BoF at Montreal IETF Thread-Index: AcaJqCOtPZAwkJxwQIi1VwoQHoab8gAAPXvA From: "Paul Francis" To: X-OriginalArrivalTime: 06 Jun 2006 20:38:21.0183 (UTC) FILETIME=[264F08F0:01C689A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [NSIS] Offpath BoF at Montreal IETF X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org =20 Gang, The offpath BoF, titled "Path-decoupled Signaling for Data", as been = approved for the next IETF. The proposed topic for the BoF is copied below, and = is also available at http://www.cs.cornell.edu/people/francis/offpath/. This message is being sent (separately) to the nsis, behave, p2psip, e2e-interest, and ietf mailing lists. The purpose of this message is to solicite feedback about the topics and agenda for the BoF. Note that the immediate goal of the BoF is to = create an IRTF research group. Nevertheless, possible alternative goals (i.e. = IETF activity) can be discussed. A BoF mailing list has been created (see below). Thanks, PF --------------------------------------------------------------------- Path-decoupled Signaling for Data (offpath) =20 To be held at the 66th (Montreal) IETF, under the auspices of the = Transport Area (Lars Eggert), and coordinated with the IRTF (Aaron Falk). =20 BoF Chair: TBD =20 BoF Initiators:=20 Paul Francis and Saikat Guha (both of Cornell University) @cs.cornell.edu =20 General Discussion: off-path-bof@ietf.org To Subscribe: off-path-bof-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html This page at: http://www.cs.cornell.edu/people/francis/offpath =20 Purpose of BoF: Gauge interest in creating an IRTF research group on this topic. =20 Synopsis:=20 Path-decoupled (or off-path) signaling, in the form of SIP, has proven = to be a very powerful mechanism for facilitating media connection = establishment between hosts. It provides friendly naming, discovery, user mobility, authentication, transport and application negotiation, and even NAT/FW traversal for UDP and, more recently, TCP. Furthermore, it is network independent, working equally well for IPv4 and IPv6. This set of = features, however, would be attractive to all types of data sessions, not just = media. The purpose of this BoF is to gauge interest in the design of off-path signaling (probably but not necessarily using SIP) for establishing all = kinds of non-public-server data sessions. A positive outcome of this BoF = would be the formation of an IRTF group, though other outcomes will of course be considered. We are particularly interested in models of off-path signaling that = improve security beyond today's address/port/deep-inspection model. The use of path-decoupled signaling gives both the middle and the ends the = opportunity to assert policy and negotiate an acceptable session. We would like to explore cases where the off-path signaling operates alone (i.e. NAT/FW traversal with legacy NAT/FW's), as well as where it operates in = conjunction with subsequent path-coupled signaling (either in-band or out-of-band). Considering that an application can always lie about what it is, we = would also like to explore how to couple the signaling primitives with = emerging OS security features (i.e. trusted computing platforms). Beyond security, = we would like to explore the use of off-path signaling for such features as = user and host mobility, transport negotiation (i.e. TCP versus SCTP), anycast = and multicast, billing, and time-delayed communications messaging).=20 The ultimate goal here is that some or all of these features become part = of the standard sockets API of typical OS's, and that infrastructure = support for the signaling becomes ubiquitous (in the same sense that DNS is = ubiquitous). This would allow application developers, security vendors (middlebox and endhost), users, and network administrators to converge on a unified = method of naming and connection establishment over the Internet. (By contrast, naming and connection establishment through NATs and firewalls today is = ad hoc and usually application specific, variously involving email, IM = services, dynamic DNS services, manual configuration of ports, and so on.)=20 Of the IETF working groups, this BoF is most closely aligned with the = nsis WG in the Transport Area, especially the NAT/FW NSLP. The following gives = an example of how an off-path signaling protocol would work in conjunction = with the NAT/FW NSLP. This is only an example...there are other approaches = and variants on this example.=20 Say an application wishes to establish a TCP connection with a "peer", = where both peers are behind NAT/FW's. The initiating peer off-path signals a connection request. The request contains the application name, user = names, authentication information (Certs or Diameter), and information about = the preferred transport (TCP, SSL, IPSec, etc.). The off-path request is = checked by the initiating endhost's policy, and then flows through policy boxes representing the initiator's and the recipient's networks. This gives = both sides an opportunity to reject the request, or to request different = transport or security characteristics, or to accept and pass on the request as-is. Note that the policy boxes could both be far from either ends' physical network, thus not revealing the IP addresses of either end until the connection is approved. The policy boxes could also be widely = replicated.=20 Assuming the connection request is approved, the endhosts use the NAT/FW = NSLP to obtain address and port mappings from their respective NAT boxes. = These are conveyed through the off-path signaling channel. In addition, the = policy boxes create secure tokens that firewalls can use to allow the approved connection. These tokens are passed to the endhosts through off-path signaling, which then convey them on-path, either in-band or out-of-band (i.e. the NAT/FW NSLP), to traverse the firewall. =20 Supporting material: http://nutss.gforge.cis.cornell.edu/ =20 =20 =20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 08 05:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGYJ-0005UX-V7; Thu, 08 Jun 2006 05:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGYI-0005QS-QY for nsis@ietf.org; Thu, 08 Jun 2006 05:11:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFQv-0008Cz-LG for nsis@ietf.org; Thu, 08 Jun 2006 04:00:01 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoF4L-0000Ux-Le for nsis@ietf.org; Thu, 08 Jun 2006 03:36:44 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4ABBC1BAC4D; Thu, 8 Jun 2006 09:26:23 +0200 (CEST) In-Reply-To: <44803C14.3000904@tm.uka.de> References: <3F2E01E1D7B04F4EBEC92D3FA324D8807DCFB1@rsys004a.roke.co.uk> <44803C14.3000904@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92D2D606-F717-4C03-BB35-D3A49B498E8E@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NSLP versioning Date: Thu, 8 Jun 2006 09:36:38 +0200 To: Roland Bless X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Am 02.06.2006 um 15:24 schrieb Roland Bless: > Martin Stiemerling schrieb: >> Dear all, >> >> There is still a not completely solved issue back from the old days >> (2004) about NSLP versioning. It is about wether an NSLP can have >> multiple versions or not. > > I would say yes, naturally it can. The question is probably > what can be considered as an appropriate demultiplexer. > So what is the issue exactly? Whether there should be an NSLP version > field in the NSLP protocol itself? The current alternative is to > use a different NSLP ID for each version, thus using the NSLP ID > in GIST as demultiplexing value. Since the NSLP ID is 16bit I guess > that there are no issues here. So as long as we assume GIST as > underlying transport (or some other protocol at least carrying session > ID, MRM, NSLPID and so on) there is no problem here. There is > only trouble if all you have is the NSLP data packet alone. The issue here is whether an NSIS initiator should have the ability to ask with a single request message for multiple, different NSLP version. This would require a single general NSLP-ID per NSLP and a version information with the NSLP itself. I do not know if this issue is solvable by now or if it should be handled in the NSLP extensibility draft. Since we have only a single version anyway of each NSLP. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 09 09:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh2j-0008N3-3s; Fri, 09 Jun 2006 09:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh2i-0008MF-6N for nsis@ietf.org; Fri, 09 Jun 2006 09:28:52 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FogwY-00056B-7N for nsis@ietf.org; Fri, 09 Jun 2006 09:22:31 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k59DMT6p029257; Fri, 9 Jun 2006 16:22:29 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 16:22:29 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 16:22:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSLP versioning Date: Fri, 9 Jun 2006 16:22:28 +0300 Message-ID: In-Reply-To: <92D2D606-F717-4C03-BB35-D3A49B498E8E@netlab.nec.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSLP versioning Thread-Index: AcaK37ytF8IFFG2RSNGMcxGtncr0iwA5/Tng From: To: , X-OriginalArrivalTime: 09 Jun 2006 13:22:28.0359 (UTC) FILETIME=[C1400970:01C68BC7] X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org >>> There is still a not completely solved issue back from the old days >>> (2004) about NSLP versioning. It is about wether an NSLP can have=20 >>> multiple versions or not. >> >> I would say yes, naturally it can. The question is probably what can=20 >> be considered as an appropriate demultiplexer. >> So what is the issue exactly? Whether there should be an=20 >NSLP version=20 >> field in the NSLP protocol itself? The current alternative=20 >is to use a=20 >> different NSLP ID for each version, thus using the NSLP ID=20 >in GIST as=20 >> demultiplexing value. Since the NSLP ID is 16bit I guess that there=20 >> are no issues here. So as long as we assume GIST as underlying=20 >> transport (or some other protocol at least carrying session ID, MRM,=20 >> NSLPID and so on) there is no problem here. There is only trouble if=20 >> all you have is the NSLP data packet alone. > >The issue here is whether an NSIS initiator should have the=20 >ability to ask with a single request message for multiple,=20 >different NSLP version. >This would require a single general NSLP-ID per NSLP and a=20 >version information with the NSLP itself. > >I do not know if this issue is solvable by now or if it should=20 >be handled in the NSLP extensibility draft. Since we have only=20 >a single version anyway of each NSLP. Is there anyone requesting this feature, it sounds extremely messy to actually get working. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jun 11 19:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZkS-0006Gf-7B; Sun, 11 Jun 2006 19:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZkR-0006GV-1f for nsis@ietf.org; Sun, 11 Jun 2006 19:53:39 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZkM-0004Qs-C7 for nsis@ietf.org; Sun, 11 Jun 2006 19:53:39 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5BNrJSX015615; Mon, 12 Jun 2006 00:53:23 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 00:53:19 +0100 From: "Robert Hancock" To: , , Subject: RE: [NSIS] NSLP versioning Date: Mon, 12 Jun 2006 00:53:18 +0100 Message-ID: <000601c68db2$36bfc370$f40a7356@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-OriginalArrivalTime: 11 Jun 2006 23:53:19.0192 (UTC) FILETIME=[36EE4D80:01C68DB2] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, the problem here is that if the NSLP version is encoded in the NSLPID, version negotation becomes quite hard and incremental deployment of a new version very hard. example: *) node A supports versions 1 and 2; *) it issues a query for version 1; *) it gets a response from node B which supports version 1 and 2, but: the only version they will ever use is version 1 unless A re-Queries for version 2 (the routing state is tied to the NSLP version). second attempt: *) node A supports versions 1 and 2; *) it issues a query for version 2; *) the Query is seen by node B' which only supports version 1, so it has to bypass the Query to the next node down the path. i think there is a relatively simple class of solutions to this problem, where a single NSLPID defines a family of versions, and NSLP messages include a version number. you signal your highest supported version by replying to messages about an unsupported version with an error. you can even put NSLP data in the query to conduct version negotiation as part of route setup. (of course, there are loads of other solutions on the same general pattern. the principle point is not to use different NSLP IDs for different versions.) r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 09 June 2006 14:22 > To: stiemerling@netlab.nec.de; bless@tm.uka.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] NSLP versioning > > > > >>> There is still a not completely solved issue back from > the old days > >>> (2004) about NSLP versioning. It is about wether an NSLP can have > >>> multiple versions or not. > >> > >> I would say yes, naturally it can. The question is > probably what can > >> be considered as an appropriate demultiplexer. > >> So what is the issue exactly? Whether there should be an > >NSLP version > >> field in the NSLP protocol itself? The current alternative > >is to use a > >> different NSLP ID for each version, thus using the NSLP ID > >in GIST as > >> demultiplexing value. Since the NSLP ID is 16bit I guess > that there > >> are no issues here. So as long as we assume GIST as underlying > >> transport (or some other protocol at least carrying > session ID, MRM, > >> NSLPID and so on) there is no problem here. There is only > trouble if > >> all you have is the NSLP data packet alone. > > > >The issue here is whether an NSIS initiator should have the > >ability to ask with a single request message for multiple, > >different NSLP version. > >This would require a single general NSLP-ID per NSLP and a > >version information with the NSLP itself. > > > >I do not know if this issue is solvable by now or if it should > >be handled in the NSLP extensibility draft. Since we have only > >a single version anyway of each NSLP. > > Is there anyone requesting this feature, it sounds extremely messy to > actually get working. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 12 05:56:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpj9t-00078V-Mi; Mon, 12 Jun 2006 05:56:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpj9s-00078Q-M0 for nsis@ietf.org; Mon, 12 Jun 2006 05:56:32 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpj9o-00042B-BZ for nsis@ietf.org; Mon, 12 Jun 2006 05:56:32 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Fpj9a-0006qJ-Q7; Mon, 12 Jun 2006 11:56:17 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 90AAEB4BB; Mon, 12 Jun 2006 11:56:14 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1Fpj9a-0006JW-0e; Mon, 12 Jun 2006 11:56:14 +0200 Message-ID: <448D3A3D.6010105@tm.uka.de> Date: Mon, 12 Jun 2006 11:56:13 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] NSLP versioning References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.2 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: stiemerling@netlab.nec.de, nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, Martin, Robert, and, all >> The issue here is whether an NSIS initiator should have the >> ability to ask with a single request message for multiple, >> different NSLP version. >> This would require a single general NSLP-ID per NSLP and a >> version information with the NSLP itself. >> >> I do not know if this issue is solvable by now or if it should >> be handled in the NSLP extensibility draft. Since we have only >> a single version anyway of each NSLP. > > Is there anyone requesting this feature, it sounds extremely messy to > actually get working. I'm actually opposed to supporting such a version negotiation feature. There are quite a lot of options and cases one could imagine. I guess it's a good example of applying the e2e argument again: the application itself should decide which version is suitable instead of building a version negotiation feature into GIST. Thus, it would be free to probe versions in any order it likes given the current NSLP-IP -> version one-to-one mapping. Furthermore, we have the limited exensibility for yet unknown objects within each version. I guess that's flexible enough. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 13 07:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq71b-0000Hq-50; Tue, 13 Jun 2006 07:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq71Z-0000Hl-7O for nsis@ietf.org; Tue, 13 Jun 2006 07:25:33 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq71W-0006jI-9r for nsis@ietf.org; Tue, 13 Jun 2006 07:25:33 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5DBOv3f022673 for ; Tue, 13 Jun 2006 12:25:17 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Jun 2006 12:25:09 +0100 From: "Robert Hancock" To: Date: Tue, 13 Jun 2006 14:25:06 +0300 Message-ID: <021101c68edc$0753ce80$f40a7356@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <448D3A3D.6010105@tm.uka.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-OriginalArrivalTime: 13 Jun 2006 11:25:10.0052 (UTC) FILETIME=[07BE9E40:01C68EDC] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [NSIS] partly-decoupled signalling work X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org dear all, many of you will be aware of a draft on an approach to path-decoupled signalling (see the last version at: http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt). there was a presentation on this at the last IETF in Dallas (see http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt followed by a productive discussion at the microphone (summary at http://tools.ietf.org/wg/nsis/minutes?item=minutes65.html). as we approach submission cutoff deadlines, we'd like to solicit comments and discussion additional to that expressed at the meeting. in particular, we'd like to understand if the WG thinks that the document is in a suitable state to be adopted as a working group draft. cheers, robert h. et al. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 13 10:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9We-0004gz-85; Tue, 13 Jun 2006 10:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq9Wc-0004gu-Tl for nsis@ietf.org; Tue, 13 Jun 2006 10:05:46 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fq9Wa-0007C6-Es for nsis@ietf.org; Tue, 13 Jun 2006 10:05:46 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-126.messagelabs.com!1150207431!9045674!21 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 4817 invoked from network); 13 Jun 2006 14:05:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-126.messagelabs.com with SMTP; 13 Jun 2006 14:05:43 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F001CBC8D; Tue, 13 Jun 2006 10:05:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] partly-decoupled signalling work Date: Tue, 13 Jun 2006 09:05:42 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC78CB@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <021101c68edc$0753ce80$f40a7356@comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] partly-decoupled signalling work Thread-Index: AcaO3CMkiNcp1CSeSh6Vvd/cC08r/gAFYLKA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Robert Hancock" , X-Spam-Score: 1.8 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org > many of you will be aware of a draft on an approach to path-decoupled > signalling (see the last version at: > http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt). >=20 > there was a presentation on this at the last IETF in Dallas (see > http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt followed > by a productive discussion at the microphone (summary at > http://tools.ietf.org/wg/nsis/minutes?item=3Dminutes65.html). >=20 > as we approach submission cutoff deadlines, we'd like to solicit > comments and discussion additional to that expressed at the=20 > meeting. in particular, we'd like to understand if the WG thinks=20 > that the document is in a suitable state to be adopted as a working > group draft. This had good support at IETF-65 to become a WG document, and I continue to support that. BTW, a link to the slides is at http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm (link above doesn't seem to work). Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 13 23:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqLxb-00016i-H2; Tue, 13 Jun 2006 23:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqLxZ-00016d-LL for nsis@ietf.org; Tue, 13 Jun 2006 23:22:25 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqLxY-0007kv-6T for nsis@ietf.org; Tue, 13 Jun 2006 23:22:25 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5E3MJAf003015; Wed, 14 Jun 2006 06:22:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 06:22:19 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 06:22:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] partly-decoupled signalling work Date: Wed, 14 Jun 2006 06:22:17 +0300 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC78CB@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] partly-decoupled signalling work Thread-Index: AcaO3CMkiNcp1CSeSh6Vvd/cC08r/gAFYLKAABv7PSA= From: To: , , X-OriginalArrivalTime: 14 Jun 2006 03:22:18.0649 (UTC) FILETIME=[BDDB1890:01C68F61] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org As we have a number of drafts that people have been interested in adding to our charter, I think we need to have some discussion on this draft on the mailing list. I'd like to get some consensus if people feel this is a good way to go forward. Some actual discussion & work on the draft - via mailing list discussions - would be a good thing as well. John=20 >-----Original Message----- >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Sent: 13 June, 2006 17:06 >To: Robert Hancock; nsis@ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: RE: [NSIS] partly-decoupled signalling work > >> many of you will be aware of a draft on an approach to=20 >path-decoupled=20 >> signalling (see the last version at: >> http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt). >>=20 >> there was a presentation on this at the last IETF in Dallas (see=20 >> http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt=20 >followed by a=20 >> productive discussion at the microphone (summary at=20 >> http://tools.ietf.org/wg/nsis/minutes?item=3Dminutes65.html). >>=20 >> as we approach submission cutoff deadlines, we'd like to solicit=20 >> comments and discussion additional to that expressed at the meeting.=20 >> in particular, we'd like to understand if the WG thinks that the=20 >> document is in a suitable state to be adopted as a working group=20 >> draft. > >This had good support at IETF-65 to become a WG document, and=20 >I continue to support that. BTW, a link to the slides is at=20 >http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm=20 >(link above doesn't seem to work). > >Jerry > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 04:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQPm-0005Bv-2g; Wed, 14 Jun 2006 04:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQPl-0005Bq-3z for nsis@ietf.org; Wed, 14 Jun 2006 04:07:49 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqQPj-0005vQ-Lq for nsis@ietf.org; Wed, 14 Jun 2006 04:07:49 -0400 Received: (qmail invoked by alias); 14 Jun 2006 08:07:46 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp032) with SMTP; 14 Jun 2006 10:07:46 +0200 X-Authenticated: #29516787 Message-ID: <448FC3D6.3010707@gmx.net> Date: Wed, 14 Jun 2006 10:07:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] partly-decoupled signalling work References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: gash@att.com, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, the working group expressed a lot of interest at last IETF meeting to move this work forward within the NSIS working group. Is this a call for a hum again? Is the question whether this document is a good starting point for the work on the partly-decoupled signaling work? Is rechartering necessary before a document can be taken as a WG item? Ciao Hannes john.loughney@nokia.com wrote: > As we have a number of drafts that people have been interested > in adding to our charter, I think we need to have some discussion > on this draft on the mailing list. I'd like to get some consensus > if people feel this is a good way to go forward. > > Some actual discussion & work on the draft - via mailing list > discussions - would be a good thing as well. > > John > > >>-----Original Message----- >>From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>Sent: 13 June, 2006 17:06 >>To: Robert Hancock; nsis@ietf.org >>Cc: Ash, Gerald R (Jerry), ALABS >>Subject: RE: [NSIS] partly-decoupled signalling work >> >> >>>many of you will be aware of a draft on an approach to >> >>path-decoupled >> >>>signalling (see the last version at: >>>http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt). >>> >>>there was a presentation on this at the last IETF in Dallas (see >>>http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt >> >>followed by a >> >>>productive discussion at the microphone (summary at >>>http://tools.ietf.org/wg/nsis/minutes?item=minutes65.html). >>> >>>as we approach submission cutoff deadlines, we'd like to solicit >>>comments and discussion additional to that expressed at the meeting. >>>in particular, we'd like to understand if the WG thinks that the >>>document is in a suitable state to be adopted as a working group >>>draft. >> >>This had good support at IETF-65 to become a WG document, and >>I continue to support that. BTW, a link to the slides is at >>http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm >>(link above doesn't seem to work). >> >>Jerry >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 04:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQYx-0000eb-IE; Wed, 14 Jun 2006 04:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQYw-0000eW-Cq for nsis@ietf.org; Wed, 14 Jun 2006 04:17:18 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQYu-0006Et-SU for nsis@ietf.org; Wed, 14 Jun 2006 04:17:18 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5E8HB9g021371; Wed, 14 Jun 2006 11:17:13 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 11:17:12 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 11:17:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] partly-decoupled signalling work Date: Wed, 14 Jun 2006 11:17:11 +0300 Message-ID: In-Reply-To: <448FC3D6.3010707@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] partly-decoupled signalling work Thread-Index: AcaPicuWVBMBZM+IQSSep/vjqisNvAAAPebg From: To: X-OriginalArrivalTime: 14 Jun 2006 08:17:12.0298 (UTC) FILETIME=[F017ACA0:01C68F8A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: gash@att.com, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, No hum needed, but there are a number of items to add to the charter, once GIST, QoS NSLP, NATFW NSLP, etc. get sent to the IESG. I'm hoping for some work to start before the document is added to our charter. A small rechartering may be needed. John >-----Original Message----- >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: 14 June, 2006 11:08 >To: Loughney John (Nokia-NRC/Helsinki) >Cc: gash@att.com; robert.hancock@roke.co.uk; nsis@ietf.org >Subject: Re: [NSIS] partly-decoupled signalling work > >Hi all, > >the working group expressed a lot of interest at last IETF=20 >meeting to move this work forward within the NSIS working group. > >Is this a call for a hum again? >Is the question whether this document is a good starting point=20 >for the work on the partly-decoupled signaling work? >Is rechartering necessary before a document can be taken as a WG item? > >Ciao >Hannes > >john.loughney@nokia.com wrote: >> As we have a number of drafts that people have been interested in=20 >> adding to our charter, I think we need to have some=20 >discussion on this=20 >> draft on the mailing list. I'd like to get some consensus if people=20 >> feel this is a good way to go forward. >>=20 >> Some actual discussion & work on the draft - via mailing list=20 >> discussions - would be a good thing as well. >>=20 >> John >>=20 >>=20 >>>-----Original Message----- >>>From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] >>>Sent: 13 June, 2006 17:06 >>>To: Robert Hancock; nsis@ietf.org >>>Cc: Ash, Gerald R (Jerry), ALABS >>>Subject: RE: [NSIS] partly-decoupled signalling work >>> >>> >>>>many of you will be aware of a draft on an approach to >>> >>>path-decoupled >>> >>>>signalling (see the last version at: >>>>http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem >-03.txt). >>>> >>>>there was a presentation on this at the last IETF in Dallas (see=20 >>>>http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt >>> >>>followed by a >>> >>>>productive discussion at the microphone (summary at=20 >>>>http://tools.ietf.org/wg/nsis/minutes?item=3Dminutes65.html). >>>> >>>>as we approach submission cutoff deadlines, we'd like to solicit=20 >>>>comments and discussion additional to that expressed at the meeting. >>>>in particular, we'd like to understand if the WG thinks that the=20 >>>>document is in a suitable state to be adopted as a working group=20 >>>>draft. >>> >>>This had good support at IETF-65 to become a WG document, and I=20 >>>continue to support that. BTW, a link to the slides is at=20 >>>http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm >>>(link above doesn't seem to work). >>> >>>Jerry >>> >>>_______________________________________________ >>>nsis mailing list >>>nsis@ietf.org >>>https://www1.ietf.org/mailman/listinfo/nsis >>> >>=20 >>=20 >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >>=20 >>=20 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 04:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqR98-00040a-Us; Wed, 14 Jun 2006 04:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqR97-00040V-N5 for nsis@ietf.org; Wed, 14 Jun 2006 04:54:41 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqR96-0007j6-2s for nsis@ietf.org; Wed, 14 Jun 2006 04:54:41 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k5E8saj6017476; Wed, 14 Jun 2006 10:54:36 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k5E8sZhQ029595; Wed, 14 Jun 2006 10:54:36 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 10:54:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] partly-decoupled signalling work Date: Wed, 14 Jun 2006 10:54:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] partly-decoupled signalling work Thread-Index: AcaPicuWVBMBZM+IQSSep/vjqisNvAAAPebgAADAKgA= From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 14 Jun 2006 08:54:35.0545 (UTC) FILETIME=[292C0090:01C68F90] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: gash@att.com, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Thanks John for the quick response.=20 I guess that the path-decoupled work received a number of comments over = the last few years. With that respect we are in a good shape. I will, = however, review the draft after the submission deadlines. Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Gesendet: Mittwoch, 14. Juni 2006 10:17 > An: Hannes.Tschofenig@gmx.net > Cc: gash@att.com; nsis@ietf.org; robert.hancock@roke.co.uk > Betreff: RE: [NSIS] partly-decoupled signalling work >=20 > Hi all, >=20 > No hum needed, but there are a number of items to add to the charter, > once GIST, QoS NSLP, NATFW NSLP, etc. get sent to the IESG. I'm > hoping for some work to start before the document is added to our > charter. >=20 > A small rechartering may be needed. >=20 > John >=20 > >-----Original Message----- > >From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > >Sent: 14 June, 2006 11:08 > >To: Loughney John (Nokia-NRC/Helsinki) > >Cc: gash@att.com; robert.hancock@roke.co.uk; nsis@ietf.org > >Subject: Re: [NSIS] partly-decoupled signalling work > > > >Hi all, > > > >the working group expressed a lot of interest at last IETF=20 > >meeting to move this work forward within the NSIS working group. > > > >Is this a call for a hum again? > >Is the question whether this document is a good starting point=20 > >for the work on the partly-decoupled signaling work? > >Is rechartering necessary before a document can be taken as=20 > a WG item? > > > >Ciao > >Hannes > > > >john.loughney@nokia.com wrote: > >> As we have a number of drafts that people have been interested in=20 > >> adding to our charter, I think we need to have some=20 > >discussion on this=20 > >> draft on the mailing list. I'd like to get some consensus=20 > if people=20 > >> feel this is a good way to go forward. > >>=20 > >> Some actual discussion & work on the draft - via mailing list=20 > >> discussions - would be a good thing as well. > >>=20 > >> John > >>=20 > >>=20 > >>>-----Original Message----- > >>>From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] > >>>Sent: 13 June, 2006 17:06 > >>>To: Robert Hancock; nsis@ietf.org > >>>Cc: Ash, Gerald R (Jerry), ALABS > >>>Subject: RE: [NSIS] partly-decoupled signalling work > >>> > >>> > >>>>many of you will be aware of a draft on an approach to > >>> > >>>path-decoupled > >>> > >>>>signalling (see the last version at: > >>>>http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem > >-03.txt). > >>>> > >>>>there was a presentation on this at the last IETF in Dallas (see=20 > >>>>http://www3.ietf.org/proceedings/06mar/slides/nsis-1.ppt > >>> > >>>followed by a > >>> > >>>>productive discussion at the microphone (summary at=20 > >>>>http://tools.ietf.org/wg/nsis/minutes?item=3Dminutes65.html). > >>>> > >>>>as we approach submission cutoff deadlines, we'd like to solicit=20 > >>>>comments and discussion additional to that expressed at=20 > the meeting. > >>>>in particular, we'd like to understand if the WG thinks that the=20 > >>>>document is in a suitable state to be adopted as a working group=20 > >>>>draft. > >>> > >>>This had good support at IETF-65 to become a WG document, and I=20 > >>>continue to support that. BTW, a link to the slides is at=20 > >>>http://www3.ietf.org/proceedings/06mar/slides/nsis-1/sld1.htm > >>>(link above doesn't seem to work). > >>> > >>>Jerry > >>> > >>>_______________________________________________ > >>>nsis mailing list > >>>nsis@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/nsis > >>> > >>=20 > >>=20 > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >>=20 > >>=20 > > > > >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 05:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqRp6-0008DN-BZ; Wed, 14 Jun 2006 05:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqRp5-0008DA-SY for nsis@ietf.org; Wed, 14 Jun 2006 05:38:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqRp4-0000ux-C0 for nsis@ietf.org; Wed, 14 Jun 2006 05:38:03 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CA7A6560001; Wed, 14 Jun 2006 11:38:01 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 11:38:01 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 11:38:01 +0200 Message-ID: <448FD8F9.8040403@ericsson.com> Date: Wed, 14 Jun 2006 11:38:01 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] partly-decoupled signalling work References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 09:38:01.0225 (UTC) FILETIME=[3A473790:01C68F96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: gash@att.com, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I would like to clarify a few thing. Any off-path or partly-decouple work would need to be chartered. My impression of the Dallas discussion was that people are not yet on the same page on what is needed in the larger scale. I know that there where views that Partly-Decoupled work was ready for adoption. But is this really the right way and how does it fit together with other proposals? So please continue discussing the topic and try to reach some consensus on that. While this is ongoing the NSIS WG still has some tasks to finish. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 06:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqT3z-0003wf-8q; Wed, 14 Jun 2006 06:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqT3x-0003vT-Rw for nsis@ietf.org; Wed, 14 Jun 2006 06:57:29 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqT3w-0005fN-Dw for nsis@ietf.org; Wed, 14 Jun 2006 06:57:29 -0400 Received: (qmail invoked by alias); 14 Jun 2006 10:57:26 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp043) with SMTP; 14 Jun 2006 12:57:26 +0200 X-Authenticated: #29516787 Message-ID: <448FEB99.4050503@gmx.net> Date: Wed, 14 Jun 2006 12:57:29 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [NSIS] partly-decoupled signalling work References: <448FD8F9.8040403@ericsson.com> In-Reply-To: <448FD8F9.8040403@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: john.loughney@nokia.com, gash@att.com, nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Magnus, I got the impression that the work on this subject over the last few years lead to: http://tools.ietf.org/wg/nsis/draft-hancock-nsis-pds-problem-03.txt I don't see a competing proposal. Ciao Hannes Magnus Westerlund wrote: > Hi, > > I would like to clarify a few thing. Any off-path or partly-decouple > work would need to be chartered. My impression of the Dallas discussion > was that people are not yet on the same page on what is needed in the > larger scale. I know that there where views that Partly-Decoupled work > was ready for adoption. But is this really the right way and how does it > fit together with other proposals? So please continue discussing the > topic and try to reach some consensus on that. > > While this is ongoing the NSIS WG still has some tasks to finish. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 07:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTk7-0005LS-4t; Wed, 14 Jun 2006 07:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTk6-0005LN-5e for nsis@ietf.org; Wed, 14 Jun 2006 07:41:02 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTk4-00045y-6k for nsis@ietf.org; Wed, 14 Jun 2006 07:41:02 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5EBeUgh028236; Wed, 14 Jun 2006 12:40:32 +0100 Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 12:40:29 +0100 From: "Robert Hancock" To: "'Magnus Westerlund'" , Subject: RE: [NSIS] partly-decoupled signalling work Date: Wed, 14 Jun 2006 14:40:29 +0300 Message-ID: <000a01c68fa7$57b26fa0$1f99b70a@comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <448FD8F9.8040403@ericsson.com> Importance: Normal X-OriginalArrivalTime: 14 Jun 2006 11:40:30.0230 (UTC) FILETIME=[56A06360:01C68FA7] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi magnus, john, all, it is indeed clear that it's important to be precise about what work we are actually talking about doing, especially where the terms 'off path' and 'signalling' are used together. we could be in problem statement/requirements territory, framework updates, new protocol work or description of the applicability of existing work (our draft comes into this category), or indeed any combination of these. when we (the authors) started down this track, our first effort (based in part on advice from the chair) was quite a broad survey of the problem and the possible pieces of different sorts of complete solution. that work was not done in a vacuum - there was extensive discussion on the NSIS m.l. during 2001-2 and during the NSIS w.g. session at ietf#54, a mini-bof in TSV at ietf#55, and a less mini-bof (pads) at ietf#56. the drafts written around this time include draft-schelen-nsis-opopsig-01.txt, draft-declercq-vsn-arch-00.txt and draft-vandenbosch-nsis-resilience-00.txt anyway, we wrote our first -00 draft about a year ago, and it was discussed at length (albeit informally) after a WG interim; we also got a very detailed review from Bob Braden and some off-list feedback from the CCAMP chair. based on that, we made revised versions (-01/-02) which became much more focussed on a single part of the problem space, and a particular style of solution; we discussed how the -02 ideas fitted into the DCPEL proposal during the vancouver IETF, which was a helpful example use case for us to understand better the sort of deployment considerations that have to be taken into account. and version -03 which was discussed in Dallas parallels part of the work done by the EuQoS project (see draft-cordeiro-nsis-hypath-00). so my impression of the current state of affairs is that a) there has been extensive (very extensive) discussion of off-path signaling in its broadest sense b) there is and probably never will be a single IETF view on how the 'off-path' problem should actually be solved, because of the huge range of different problems that the heading actually covers c) however, there is a view that the approach outlined in the pds-problem draft is a valid solution to a particular technical problem which has applicability in a range of real scenarios. so the issue now in a procedural sense is whether we need to go back to the question in (b) and start again on that discussion. my concern is that this would be likely to turn into the sort of open-ended ocean-boiling architectural discussion which is not the best use of WG time. or should we be asking a more targetted question about whether the approach proposed in pds-problem is a useful enhancement to the applicability of all the protocol work we are already doing (which is the question I tried to ask in my original email). or there may be a third option. cheers, robert h. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 14 June 2006 12:38 > To: john.loughney@nokia.com > Cc: Hannes.Tschofenig@gmx.net; gash@att.com; nsis@ietf.org; > robert.hancock@roke.co.uk > Subject: Re: [NSIS] partly-decoupled signalling work > > > Hi, > > I would like to clarify a few thing. Any off-path or partly-decouple > work would need to be chartered. My impression of the Dallas > discussion > was that people are not yet on the same page on what is needed in the > larger scale. I know that there where views that > Partly-Decoupled work > was ready for adoption. But is this really the right way and > how does it > fit together with other proposals? So please continue discussing the > topic and try to reach some consensus on that. > > While this is ongoing the NSIS WG still has some tasks to finish. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 09:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVIu-0004iy-EW; Wed, 14 Jun 2006 09:21:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVIs-0004hg-Tl for nsis@ietf.org; Wed, 14 Jun 2006 09:21:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVIr-0002T7-G3 for nsis@ietf.org; Wed, 14 Jun 2006 09:21:02 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BBC114F03FD; Wed, 14 Jun 2006 15:21:00 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 15:21:00 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 15:21:00 +0200 Message-ID: <44900D3B.50108@ericsson.com> Date: Wed, 14 Jun 2006 15:20:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Hancock Subject: Re: [NSIS] partly-decoupled signalling work References: <000a01c68fa7$57b26fa0$1f99b70a@comm.ad.roke.co.uk> In-Reply-To: <000a01c68fa7$57b26fa0$1f99b70a@comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 13:21:00.0372 (UTC) FILETIME=[60DF0940:01C68FB5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: john.loughney@nokia.com, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Thanks for the clarifications. I am missing most of the background on what has been done in this area prior. I am doing my best to catch up. It is also a reason I might be a bit defensive about taking on what I might think is new work. I don't want to delay any re-chartering of work that the WG agrees on is the way. But I need to understand this before I bring it forward. Thus it will take some discussion on this topic before I am there. So please consider Robert's question. I do like to see some answers on this. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 14 10:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWEM-0006ha-Dx; Wed, 14 Jun 2006 10:20:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWEL-0006hV-LO for nsis@ietf.org; Wed, 14 Jun 2006 10:20:25 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWEK-0002RF-BH for nsis@ietf.org; Wed, 14 Jun 2006 10:20:25 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com for nsis@ietf.org; Wed, 14 Jun 2006 10:20:08 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006061410200819285 for ; Wed, 14 Jun 2006 10:20:08 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jun 2006 10:20:08 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426230E1C@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: nsis@ietf.org Date: Wed, 14 Jun 2006 10:20:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [NSIS] QOS-over-P2P Overlay Network X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1038650798==" Errors-To: nsis-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1038650798== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68FBD.A0D98632" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C68FBD.A0D98632 Content-Type: text/plain; charset="iso-8859-1" Folks: While off-path QOS discussions are going on in the NSIS WG list, I am trying to draw your attention about the above topic as you know P2P networking schemes are discussed in the following formal and informal IETF WGs: * MANET * P2P-SIP In this connection, I am also providing a URL: http://nms.lcs.mit.edu/papers/overqos-nsdi04.html The above will provide light how QOS can be enhanced further for the P2P applications without fully relying on the IP layer. It might an interesting approach to look a little differently for solving the QOS problems, and NSIS WG, I think, is the right place to have a start on this. The ideas are as follows: * Is it possible to enhance QOS signaling protocols to meet the needs of the applications with a combination of higher layer and/or IP network layer (without overly dependent on the IP layer)? * If so, can NSIS QOS signaling protocols be used to help all areas: Higher Layers (Application, Presentation) and IP Networking layer? Best regards, Radhika R. Roy ------_=_NextPart_001_01C68FBD.A0D98632 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] Re: Updated IETF#65 Meeting Minutes

Folks:

 

While off-path QOS discussions are going on in the = NSIS WG list, I am trying to draw your attention about the above topic as you = know P2P networking schemes are discussed in the following formal and informal = IETF WGs:

 

  • MANET
  • P2P-SIP

 

In this connection, I am also providing a URL: http://nms.lc= s.mit.edu/papers/overqos-nsdi04.html=

 

The above will provide light how QOS can be enhanced = further for the P2P applications without fully relying on the IP layer. It = might an interesting approach to look a little differently for solving the QOS = problems, and NSIS WG, I think, is the right place to have a start on this. =

 

The ideas are as follows: =

 

  • Is it possible to = enhance QOS signaling protocols to meet the needs of the applications with a combination = of higher layer and/or IP network layer (without overly dependent on = the IP layer)?
  • If so, can NSIS QOS = signaling protocols be used to help all areas: Higher Layers (Application, = Presentation) and IP Networking layer?

 

Best regards,

Radhika R. Roy

 

------_=_NextPart_001_01C68FBD.A0D98632-- --===============1038650798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1038650798==-- From nsis-bounces@ietf.org Wed Jun 14 11:23:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXDN-0007wM-5N; Wed, 14 Jun 2006 11:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXDM-0007wG-8x for nsis@ietf.org; Wed, 14 Jun 2006 11:23:28 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXDL-0003FF-Gs for nsis@ietf.org; Wed, 14 Jun 2006 11:23:28 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C79C24F0497; Wed, 14 Jun 2006 17:23:26 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 17:23:26 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 17:23:26 +0200 Message-ID: <449029ED.9050208@ericsson.com> Date: Wed, 14 Jun 2006 17:23:25 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M4: IANAconsiderations) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 15:23:26.0080 (UTC) FILETIME=[7B412000:01C68FC6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org john.loughney@nokia.com wrote: > Robert, > >>> M4. IANA consideration section >>> >>> I think the IANA consideration section is lacking in several ways. >>> >>> A. Decision criteria for IESG, Expert review or other >> policies are not >>> written. The WG should provide some guidelines for what is >> acceptable >>> to be registered and what is not. >> This is a document roadmap issue; there are several different >> ways in which NSIS (as a protocol suite) can be extended to >> meet an engineering goal, sometimes involving GIST, sometimes >> NSLPs and sometimes both, the idea is to centralise this >> discussion in one document, currently draft-loughney-nsis-ext >> (which is reference [36]). Maybe the first paragraph of >> section 9 should state this more strongly, and maybe [36] >> should be normative. > > I think so - Magnus, what we want to do is have GIST as a good > protocol spec, but address elsewhere the overall extensibility > issues, etc. Okay. I think that is totally okay as long as it is clear where this information is available. The proposed fix looks good. > >>> B. There is no explanation for the large blocks of reserved codes > that >>> exist. >> The rationale is that "If the current allocation policy turns >> out to be wrong [e.g. because you suddenly start to run out in >> a particular class] then the reserved space can be used for a >> second attempt." I'm sure I had seen this in 2434, but it >> certainly isn't there any more ;-) >> >> We could include that rationale more explicitly, or a >> different rationale, or change the registry structure. >> Opinions welcome. > > I'm more comfortable reserving blocks as unused. If GIST > turns out to be wildly successful, then we can revise this > at a later date. We don't want to allow a gold-rush mentality, > allowing people to extend it in whatever way possible. Okay. I understand the motivation. > >>> C. No rules for what is required to be included in an application for > >>> assignment in any of these spaces. >> I'm not sure I really follow this. For example, for error >> codes, it's stated that the error class and additional info >> format must be defined; for object types, it's stated that the >> AB flags must be defined (maybe one could add that the object >> format is also needed); for MRMs there is a reference to >> section 3.3 which describes what information is needed for a >> new MRM. In some cases (such as new message type) I'm not sure >> what to say beyond 'specification' since the range of things >> that could be needed is so large. >> >> One aspect of this relates to document structure/section >> content assumptions. The advice we got was to make section 9 >> purely aimed at IANA and the mechanics needed to get the >> registry structure and policies documented correctly, on the >> assumption that IANA will read nothing else. It therefore >> intentionally doesn't contain all the information/guidance >> that is needed to extend the protocol; implicitly one is >> relying on the expertise of the people called up in the policy >> (ietf/iesg/expert/whoever) to be familiar enough with the >> specification as a whole to demand the right sort of >> additional detail if it isn't already provided. >> >> It may be that this is the Wrong Way to do things. More >> guidance needed ... > > Yes. The extensibility draft (update coming) should have the > application designer's rational for extending things. I am used to trying to write out clear enough rules about what the potential extender needs to fulfill so that this is easy. There is also the guidance to the reviewer of a proposed extension. It is clear that the guidance can never be all encompassing and the reviewer will have to make some decision on this. Maybe putting the formal rules in the GIST spec and the guidance in the extensibility document is a good split. > >>> D. The NSLP ID policy. Is it really envisioned that GIST will only be > >>> used for NSLPs for which it is suitable that the IESG make decision > on >>> them? Wouldn't a better policy be expert review or something which is > >>> having a bit of lower bar. Having all proprietary users of GIST run > to >>> the IESG for approval seems strange. >> This is probably an oversight, and we could certainly put in >> some expert review/specification required space as well as the >> experimental values. (But see under [A] above for discussion >> of where guidance is written down, which applies most strongly >> for this particular registry.) > > Well, our former AD wanted to more tightly control this, but I think > something along the lines of Expert Review / Spec Required would be > OK to most of us here. > Okay. But as it has been established a WG consensus on the previous position my proposal would not be to change anything now. If the policy is really screwed up I guess we will need to publish an update on that. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 15 23:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr5S9-0008LN-7K; Thu, 15 Jun 2006 23:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr5S8-0008LI-5Q for nsis@ietf.org; Thu, 15 Jun 2006 23:57:00 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr5S6-0005p9-Iy for nsis@ietf.org; Thu, 15 Jun 2006 23:57:00 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2006 20:56:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5G3uwUR006208; Thu, 15 Jun 2006 20:56:58 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5G3uvke004102; Thu, 15 Jun 2006 20:56:57 -0700 (PDT) From: "Dan Wing" To: , Date: Thu, 15 Jun 2006 20:56:56 -0700 Message-ID: <07ca01c690f8$e9dde380$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZtXpAo4ZqImHbcQjOAYQJ4vNANNQAeuKiwCLYH+KA= In-reply-to: <615BD9B54CB01B41838C323DB9E91AAB40768F@esebe100.NOE.Nokia.com> DKIM-Signature: a=rsa-sha1; q=dns; l=6827; t=1150430218; x=1151294218; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=22Dan=20Wing=22=20 |Subject:review=20of=20the=20=22NAT/Firewall=20NSISSignaling=20Layer=20Protocol=2 0(NSLP)=20=22; X=v=3Dcisco.com=3B=20h=3Dr4jzBmc4oaAvIjoWsYUGk/0HaYQ=3D; b=U82EWSlJoHr1y9dcHTLlvZbARYwyyLxjwjI+rjgQGop825HebGf1uXr9mj/H6Al/HOGq6p/x dFhH5TI3y5Fd6Ef//4NHOpBFd6+0zRxBWh3PPH8PcD68MoWxZP/aKDsW; Authentication-Results: sj-dkim-3.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ietf-behave@list.sipfoundry.org Subject: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol (NSLP) " X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John, I read through parts of draft-ietf-nsis-ntlp-09.txt to understand how NATs are handled in NTLP. In that document's section 7.2, "NAT Traversal", it says: 5. Add a NAT-Traversal payload, listing the objects which have been modified and including the unmodified MRI and any other data needed to interpret the response. (If a NAT-Traversal object is already present, in the case of a sequence of NATs, the list of modified objects may be updated and further opaque data added, but the MRI contained in it is left unchanged.) which sounds like you would be disclosing my 'private' IP address on the public side of an NSIS-aware NAT. I believe I'm misinterpreting that, as in -ietf-nsis-nslp-natfw- I found text that alluded to avoiding such information leakage by having the outer-most NAT or firewall configured to know that it is the outer-most NAT (or firewall) and to terminate REA processing. Section 1.1 mentions STUN and TURN only being able to process two IP addresses; have you looked at ICE and would it be useful. I noticed the reference to TURN should be updated to draft-ietf-behave-turn. On to -nsis-nslp-natfw-11: My first concern with this is Appendix A and section 3.8.2, which outlines the fundamental problem of NAT traversal -- how to "leave" your network, on the correct path, in order to get the NSLP messages to traverse the NATs that are on-path between you and your intended peer. This problem is similar to STUN, am I correct? Section 3.8.2 uses words that almost say it, as well: o It may be necessary to use a signaling destination address (SDA) as the actual target of the REA message (NR+) if the DR is located behind a NAT and the address of the DS is unknown. The SDA is an arbitrary address in the outermost address realm on the other side of the NAT from the DR. Typically this will be a suitable public IP address when the 'outside' realm is the public Internet. This choice of address causes the REA message to be routed through the NATs towards the outermost realm and would force interception of the message by the outermost NAT in the network at the boundary between the private address and the public address realm (the edge-NAT). It may also be intercepted by other NATs and firewalls on the path to the edge-NAT. It seems that applications will need to collect several different routable addresses and exchange those addressees with their intended peers in order to optimize the network path. This is what ICE does, and a generalization of this technique is described in draft-ford-behave-app-02.txt section 2.3. I'm also concerned by configuration information that is necessary, such as this (in 3.8.2): The data receiver is challenged to determine whether it is solely located behind firewalls or NATs, for choosing the right message routing method. This decision can depend on a local configuration parameter, possibly given through DHCP, or it could be discovered through other non-NSLP related testing of the network configuration. and The end host cannot be assumed to know this [[the NAT device]] device - instead the NAT or firewall box itself is assumed to know that it is located at the outer perimeter of the network. For example, I am typing this message from my house, where I have two NATs and a hardware VPN with split tunneling. If both of my NATs were NSIS and NSLP aware, I don't know how they would successfully send the appropriate NSIS messages in this configuration; can you elaborate what my application or my NSIS-aware OS stack would do in this situation? From my experience, my application would need to gather different IP addresses (one from my 'internal' network that I'm IPsec'd into, another from my local interface, and another from my connection to the Internet). Even if this _isn't_ necessary -- and I don't see how you'd have success otherwise, but I'm interested in hearing -- I'm curious what information would be in this as-yet-undefined DHCP option (I didn't notice any NSIS-related DHCP document). On page 7 is this sentence fragment: However, if the data receiver resides in a public addressing realm. Figure 3 and its associated text would be clearer if the middleboxes were numbered and the text referred to each middlebox explicitly. Specifically, the sentences: Note that this IP address is not the private IP address of the responder. Instead a NAT binding (including a public IP address) has to be previously installed on the NAT that subsequently allows packets reaching the NAT to be forwarded to the receiver within the private address realm. have too many "this" and "a NAT binding" and "the NAT" to be clearly understood. The other diagrams in surrounding figures 2 through 6 might also benefit from similar changes. Section 2.8, "Multihomed Network with NAT" promises that section 3.8.2 has an extended discussion of such multihoming, but I didn't find anything in that section related to multihomed NATs. -d > -----Original Message----- > From: ietf-behave-bounces@list.sipfoundry.org > [mailto:ietf-behave-bounces@list.sipfoundry.org] On Behalf Of > john.loughney@nokia.com > Sent: Tuesday, May 02, 2006 4:28 AM > To: ietf-behave@list.sipfoundry.org > Subject: [Ietf-behave] Request for a review of the > "NAT/Firewall NSISSignaling Layer Protocol (NSLP) " > > Hi all, > > Currently, the NSIS working group is finalizing the "NAT/Firewall > NSIS Signaling Layer Protocol (NSLP)" for signaling middleboxes. > The current document can be found here: > > Http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt > > NSIS is working on a path-coupled signaling protocol, to signal > nodes along the data patch. As both NAT and Firewalls are along the > data path, NSIS signaling is developing a protocol for allow end > nodes to signal these boxes. > > As both BEHAVE and MIDCOM have been working on related issues, I'd > like to encourage people to read the document and send comments and > questions to the mailing list - nsis@ietf.org. As long as your > subject lines are clearly marked, I'll enable posting rights so that > you don't have to join the NSIS mailing list. > > Additionally, please try not to cross-post discussion on the other > mailing lists; unless the BEHAVE & MIDCOM chairs feel that > cross-posting would be beneficial. > > thanks, > John > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@list.sipfoundry.org > https://list.sipfoundry.org/mailman/listinfo/ietf-behave > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 16 08:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDCq-0001Fu-7N; Fri, 16 Jun 2006 08:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDCo-0001Fp-Tz for nsis@ietf.org; Fri, 16 Jun 2006 08:13:42 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrDCm-0007uI-6T for nsis@ietf.org; Fri, 16 Jun 2006 08:13:42 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A898D91; Fri, 16 Jun 2006 14:13:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 14:13:36 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 14:13:33 +0200 Message-ID: <4492A06D.9020207@ericsson.com> Date: Fri, 16 Jun 2006 14:13:33 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2 Security Issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 12:13:33.0549 (UTC) FILETIME=[499A59D0:01C6913E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hancock, Robert wrote: > Hi, > > the security issues, M2: > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 01 June 2006 15:23 >> To: nsis@ietf.org >> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >> >> M2. Security functions for d-mode >> >> When reading the security consideration and the specification on >> security properties I get a bit frightened that there are no >> authentication mechanism specified for d-mode. It seems that there >> should be need for authentication of d-mode queries etc to >> ensure that >> the a NSIS node is talking to someone that really has the right to >> perform the query and association creation. > > This is an important question. Some high level analysis: > *) d-mode basically has two functions: > - to set up routing state > - to set up messaging associations > > Authentication/authorisation of the 'right' to set up the MAs > is actually handled within the MA protocols themselves (if you > use TLS or whatever). This can use traditional cryptographic security > techniques. So there should be no d-mode security issue here. Hmmm. I see that being easily done for the MA that are established over connection oriented protocols. What about applications using D-mode for application data? > > Authentication/authorisation of the 'right' to set up routing > state is a more tricky. The point is that there is no framework > within which the correctness of routing state can be secured in > the traditional sense. Whether or not a node is on the route > of a flow is a dynamic function of the forwarding tables in the > network as a whole; two nodes could authenticate with each other > all that they want to, but this would tell us nothing about > whether the routing state itself was correct, since that can only > be done by interaction with the forwarding layer. A further point > is that at the start of the d-mode exchange, you can no idea > which peer you are going to be communicating with, so at least > some unauthenticated discovery phase would be needed anyway. > The GIST design is supposed to restrict the scope of d-mode > to this initial phase, and move over directly to c-mode as soon > as it is meaningful to do so. > > Section 8.3 is supposed to be about the sort of 'non-cryptographic' > authentication which can/must be done in these circumstances. Yes, maybe I am being overly paranoid here. And it seems that if you like to authenticate the D-mode requests you could use IPsec AH mode to accomplish that. However lets assume that this is sufficient for now. I intended to request a security review of this protocol as soon as we are ready to progress GIST to IETF last call. > >> Not having such a >> mechanism >> seems to prevent building a system where the domains edge >> nodes handles >> the primary security and the internal nodes only accept GIST messages >> that are authenticated by nodes belonging to the domain. > > I don't understand the problem here. There is nothing to stop > a domain being deployed with the security model you indicate; for > example: > - a host initiates the GIST handshake with the appropriate edge > node, sets up routing state and a messaging association > - the edge node authenticates the host as part of the MA setup > and decides what the host is allowed to do > - the host initiates some signalling application transaction > - if the edge node decides the signalling transaction is valid, > it continues to execute the transaction on the domain interior > nodes (GIST handshake for route discovery followed by a signalling > application exchange; typically the necessary MAs would already > be in place). > > is this the sort of model you are thinking about? Yes. But with the extra twist that I perceive a threat of spoofing or manage to tunnel attacks into the domain. Thus having a desire to restrict the interior nodes to only accept GIST D-mode messages that are authenticated as coming from a the domain. But I will assume that this can actually be accomplished with IPsec. > >> Section 8.6: I also am concerned that if there exist no secured MA >> between two GIST nodes, a on-path Man in the middle can prevent there >> from ever existing a secured MA. > > This is not what 8.6 is aiming at. Modulo the residual threat > in 8.7, 8.6 is saying that > - IF you have a suitable security policy and credentials at each node > (and 8.6 explains what 'suitable' means) > - THEN the only things that an on-path MitM can do are > (a) prevent all communication > (b) allow a properly secured MA which it cannot intercept > The MitM cannot do > (c) allow an insecure MA which it can intercept > > (a) is not something that any security solution can prevent: an on-path > MitM can always just block traffic. (b) is the desired outcome anyway. > What is ruled out is (c), which is a consequence of the MitM detection > mechanism in the Confirm and the security policy which says what to do > if the MitM is detected. (Basically, any attempt to set up an insecure > MA is automatically detected as an MitM attack.) > I think you are mostly correct. However I think there is a case D that is not sufficiently warned about. The case is the two GIST peers A and B, where A tries to create a MA between them. The attacker C is on-path and can intercept and rewrite the GIST messages. A offers both TCP/TLS and TCP in its query. C change that to only being TCP. Which it can sit in the middle and rewrite anything in. B. gets the modified query and sends a response. The response sent back by C is modified so that A gets the picture that B selected TCP. The TCP connection is established and now C can modify the checks as they are not secured. My issue with this whole thing is that the only way of knowing that a MITM exist is to require the usage of TLS with certs at both end, and use that to verify the query sent unsecured. I think it should be clearer that not having a policy of using TLS equals leaving it open for MITM. Or is the above case based on some misunderstanding? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 16 10:27:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFHr-0003HN-2t; Fri, 16 Jun 2006 10:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFHp-0003HI-T2 for nsis@ietf.org; Fri, 16 Jun 2006 10:27:01 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFHp-0000uP-6A for nsis@ietf.org; Fri, 16 Jun 2006 10:27:01 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 586784F0001; Fri, 16 Jun 2006 16:27:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 16:26:59 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 16:26:59 +0200 Message-ID: <4492BFB3.2000109@ericsson.com> Date: Fri, 16 Jun 2006 16:26:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 14:26:59.0171 (UTC) FILETIME=[ED535330:01C69150] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hancock, Robert wrote: > Hi all, > > comments on the congestion control/rate limiting issues > (M1 and in fact L16-part as well): > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 01 June 2006 15:23 >> To: nsis@ietf.org >> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >> >> M1. Congestion Control >> >> This affects text not only in 5.3.3 but also 7.1.3 and possibly other >> places. But I do have a general concern that the congestion control >> measurements described in the specification is underspecified. >> >> First in 5.3.3 I don't see any normative minimal values, or even >> recommended values for T1 and T2 that will be safe to deploy on the >> internet. I don't find it acceptable that the developer needs to >> investigate which values that are safe to use and which are >> not. There >> should also be some criteria documented for when it is >> acceptable to go >> beyond these values. So my concern here is that the >> retransmission runs >> havoc and create way to many packets to be sent. > > This is a fair point. I suppose it is impossible to get away > permanently without giving concrete numbers in this case. > > In terms of what sort of values to use and how to describe the > constraints on them, I think a good model to follow is probably > the SIP INVITE transaction specification (17.1.1.2 of rfc3261) > which says [fortunately the timer names are the same...] > > " The default value for T1 is 500 ms. T1 is an estimate of the RTT > between the client and server transactions. Elements MAY (though it > is NOT RECOMMENDED) use smaller values of T1 within closed, private > networks that do not permit general Internet connection. T1 MAY be > chosen larger, and this is RECOMMENDED if it is known in advance > (such as on high latency access links) that the RTT is larger. > Whatever the value of T1, the exponential backoffs on retransmissions > described in this section MUST be used." > > and later that T2 should be 64*T1. In our case, 500ms seems a reasonable > default also; I think T2<=64*T1 since there is a separate bound on the > T2 value from the signalling application (see the second paragraph of > 5.3.3). I would be tempted to relax the NOT RECOMMENDED clause, since > a smaller timeout would be valid and possibly quite useful on a wider > range of networks, in particular Internet-connected networks but > where it is known that the Query should be answered within the local > network. Comments and text suggestions welcome. I think this is reasonable start. It seems to be to be a good idea to allow the adaptation of the timers based on feedback from the peer. It seems possible to use the GIST query and the response to measure the current RTT. Allowing modification of the timers to track that value + some processing delay + fudge factors seems one way forward. > >> Secondly, there are also no values documented for the rate control. I >> think it is necessary to document what internet safe values >> are here so >> that one does not cause problems. In addition is seems a bit >> simplistic >> to use a token bucket with some parameters selected based on >> the local >> link as GIST clearly sends messages beyond the local link. Thus one >> might have to consider being a bit smarter and more adaptive >> to what is >> seen for different flows. > > Here I am not so sure. The text here was informed by the equivalent > discussion for ICMPv6 (reference [26], now RFC4443), which caused > an extensive thread on the v6 mailing list (start at > http://www1.ietf.org/mail-archive/web/ipv6/current/msg01343.html + > another 60 or so messages). > > GIST is not ICMP but many of the same issues arise: messages are > generated in the IP 'control plane' (in so far as this is a > meaningful term), partly autonomously but mainly in response to > events initiated by end systems, the messages go beyond the local > link, rules have to be written so they apply to a host and a core > router and everything in between. The end result for ICMP was to > write something minimal. (The link bandwidth here is used as an > indicator for where a router is in a network - core/access/whatever. > It's clearly imperfect but there's nothing else apart from dynamic > adaptiveness to make use of, and fixed values seem even worse.) > > We'd really like to avoid adaptiveness in the D-mode state machine. > The main use of D-mode should be for Queries/Responses for which > adaptation is not meaningful for initial messages (there is no > pre-existing state); if there is a large amount of signalling data > to send for a given flow, then GIST should transition to C-mode > anyway, and the rate limits chosen to be cautious to encourage > that. We aimed for robustness and simplicity rather than performance. > > It might be possible to use some sort of adaptiveness to select > an appropriate rate to apply to refresh queries used for GIST > probing (see also your point at the end of L16). The current situation > is that you can probe as fast as you like until you hit the rate limit, > and that it's up to the implementer to decide how fast is really > necessary depending on an assessment of route stability (for which > I don't know any good objective estimator). On the assumption that > most probes will go to the peer you already know about, one could > refine this to apply a separate token bucket limiter for probe > messages towards that peer, which was adapted according to knowledge > of congestion state with that peer (based on message loss). We need > input on whether that complexity is really necessary however, since > it doesn't change the situation for the whole of D-mode but just a > particular subset of it. I can understand the reluctance to use adaptation. I am also fine with not using adaptation as long as the traffic is not causing any sever problem. The question is if the parameters present in the ICMP RFC are good enough also for GIST. Has someone made any analysis of this? What amount of bit-rate are we talking about. Do we need to provide guidance on when the default parameters present in ICMP is appropriate to use for GIST? > >> Third, the implication and congestion issues with local >> repair seems to >> have been brushed over. Section 7.1.3 do indicate that you >> need to take >> care, but nothing more. Are there some potential for >> aggregation of the >> queries to minimize the load and have quicker convergence? > > There is no mechanism that I can think of. Certainly there is > no aggregation possible in general, since every affected flow > might be affected differently, especially if next-NSIS-routers > are many hops away. We depend on the rate limiting to prevent > the generated Queries causing a flood, but that's about it. > (There are aggregation techniques for transmitting the notifications, > but they take place at the NSLP level.) > Okay, it might not be a real issue. As long as there is no risk for the local repair to cause instabilities due to its caused load preventing other operations from happening due the the repair. But if I understand correctly most keep-alive towards NSLPs are done in C-mode. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 16 10:30:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFL1-0005CW-Qj; Fri, 16 Jun 2006 10:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFL0-0005CM-PT for nsis@ietf.org; Fri, 16 Jun 2006 10:30:18 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFKz-000107-0G for nsis@ietf.org; Fri, 16 Jun 2006 10:30:18 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 284546DE; Fri, 16 Jun 2006 16:30:14 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 16:30:13 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 16:30:13 +0200 Message-ID: <4492C075.4070207@ericsson.com> Date: Fri, 16 Jun 2006 16:30:13 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 14:30:13.0476 (UTC) FILETIME=[6123EA40:01C69151] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: nsis@ietf.org, robert.hancock@roke.co.uk X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I think the proposed solution in these email is fine. I am also fine with maintaining the split. But please be clear about it. Cheers Magnus john.loughney@nokia.com wrote: > Hi all, > >>> M3. NAT traversal for GIST. >>> Section 7.2: >>> >>> What plans are there for clearly defining NAT behavior for GIST and >>> the relevant NSLPs? I think one should avoid repeating the mistake >>> with NATs of not specifying the behavior sufficiently for NSIS. Thus > I >>> think there is need to specify in great deal what is going to happen >>> at the translation. >> There is already an individual I-D which describes the >> required behaviour on a NAT, >> draft-pashalidis-nsis-gimps-nattraversal-02.txt >> (see in particular section 6). I believe that this document >> should become a working group document (of at least some >> working group - I'm not clear on the relationship with behave here). > > I think that the NAT traversal material should belong in a separate > document - as we have seen with STUN, for example, the NAT > considerations > change - so I think it makes sense to have it separate. > >> What we've tried to do so far is distinguish the GIST >> specification, i.e. what nodes implementing GIST have to do, >>from the NAT specification, i.e. what NAT nodes have to do >> with GIST messages. >> The overall solution is outlined here in the GIST spec, but >> there is a lot more detail that can be added about what NATs >> should do (specifically in terms of managing their bindings) >> which is not really a concern of the GIST implementor so it >> seems reasonable to keep the two separate. > > Agreed. > >>> L2. Section 3.3, page 12, second paragraph: >>> " In addition, it should be noted that NAT traversal almost > certainly >>> requires transformation of the MRI field in GIST messages (see >>> Section 7.2). Although the transformation does not have to be >>> defined as part of the standard, the impact on existing > GIST-aware >>> NAT implementations should be considered." >>> >>> It seems that not defining the NAT behavior for GIST can potentially >>> cause interop problems and make it very hard to use. What is the > plans >>> for addressing this? Are there already existing GIST-aware NATs? >> This is probably badly worded. What we are trying to say is >> that, just as there is a split: >> a) the GIST spec, and >> b) how NATs handle GIST messages >> >> when you define a new MRM there are two things to do: >> a') how to modify GIST implementations to handle the MRM >> b') how to modify NATs to handle the new MRM >> >> Section 3.3 is saying that the information provided as part of >> (a') does not have to define all the details of NAT traversal, >> but that (b') has to be considered, e.g. if necessary as an >> extension to the base GIST nat traversal specification. > > I think a rewording of the text in 3.3 would be a good idea. > >> (As an aside, there is conceptually a class of MRMs that will >> in fact be transparent to NATs. It may be valuable to >> highlight those in some way so that they can be deployed >> without having to update NATs where the update only consists >> of the information "you don't have to do anything".) >> >> (Another aside: the GIST NAT traversal functionality has been >> implemented by at least one team. I don't believe it has made >> it into any standard distributions. The 'existing' in the spec >> means 'existing at the time that the new MRM is being proposed'.) >> >>> L19. Section 7.2, page 74: >>> >>> "Note that Confirm messages are not translated." >>> >>> Why isn't them? Also where is that specified? And what is really > meant >>> with "not translated"? >> Well, the solution is designed so they don't need to be translated. >> (If they did, it would be very tricky, since often they are >> carried in C-mode and are invisible to NATs anyway.) Probably >> the specification should say more explicitly "only Query >> messages and messages with a NTO are translated by the NAT". >> >> "Not translated" means "the payload of the UDP message is not >> translated". So that can also be made more explicit. > > Please do make it more explicit. > >>> L24. Section A.3.8: >>> "the number of GIST payloads translated by the NAT" >>> >>> The NAT? There might be several NATs on the path and it is not clear >>> how that is handled. One concern would be if different NATs translate > >>> different fields. >> The idea is that the 'list of translated objects' field >> contains the objects that have been successfully translated by >> every NAT. >> In other words, it is the intersection of the translation >> capabilities of the set of traversed NATs. The first NAT >> initialises it, subsequent NATs may have to remove objects >> which it could not translate. >> The "Type-Count" field is just the length of this list (to >> allow the message to be parsed). This needs to be made clearer >> in the spec. > > If you can add this to your ToDo list for the update, that would be > great. > > thanks, > John > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 19 05:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsG6m-0000Gw-Bz; Mon, 19 Jun 2006 05:31:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsG6l-0000Go-9O for nsis@ietf.org; Mon, 19 Jun 2006 05:31:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFvq-00012r-Au for nsis@ietf.org; Mon, 19 Jun 2006 05:20:30 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsFgW-0004pk-HS for nsis@ietf.org; Mon, 19 Jun 2006 05:04:42 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5J94Yfg012847; Mon, 19 Jun 2006 11:04:34 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5J94YN3032545; Mon, 19 Jun 2006 11:04:34 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 11:04:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol(NSLP) " Date: Mon, 19 Jun 2006 11:04:33 +0200 Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1F858267@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol(NSLP) " Thread-Index: AcZtXpAo4ZqImHbcQjOAYQJ4vNANNQAeuKiwCLYH+KAAszxBQA== From: "Pashalidis, Andreas" To: "Dan Wing" , , X-OriginalArrivalTime: 19 Jun 2006 09:04:34.0043 (UTC) FILETIME=[61F84CB0:01C6937F] X-Spam-Score: -2.6 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf-behave@list.sipfoundry.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, This is to give a short answer to Dan Wing's comment below. -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 To: john.loughney@nokia.com; nsis@ietf.org Cc: ietf-behave@list.sipfoundry.org Subject: [NSIS] review of the "NAT/Firewall NSISSignaling Layer Protocol(NSLP) " > I read through parts of draft-ietf-nsis-ntlp-09.txt to understand=20 > how NATs are handled in NTLP. In that document's section 7.2, > "NAT Traversal", it says: > 5. Add a NAT-Traversal payload, listing the objects which have been > modified and including the unmodified MRI and any other data > needed to interpret the response. (If a NAT-Traversal object is > already present, in the case of a sequence of NATs, the list of > modified objects may be updated and further opaque data added, > but the MRI contained in it is left unchanged.) > which sounds like you would be disclosing my 'private' IP address on the > public side of an NSIS-aware NAT. I believe I'm misinterpreting that, as in > -ietf-nsis-nslp-natfw- I found text that alluded to avoiding such > information leakage by having the outer-most NAT or firewall configured to > know that it is the outer-most NAT (or firewall) and to terminate REA > processing. In the draft http://www.ietf.org/internet-drafts/draft-pashalidis-nsis-gimps-nattrave rsal-02.txt (which discusses NAT traversal for GIST in detail), two different "modes of operation" for GIST-aware NATs are described (see sections 5 and 6 respectively). The mode of operation described in section 5 does not suffer from "private address disclosure" on the public side. Best Regards, Andreas Pashalidis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 19 09:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJi0-0004DQ-S5; Mon, 19 Jun 2006 09:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsJhz-0004DL-KX for nsis@ietf.org; Mon, 19 Jun 2006 09:22:27 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsJhy-0008Rn-6G for nsis@ietf.org; Mon, 19 Jun 2006 09:22:27 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5JDMOsN000996 for ; Mon, 19 Jun 2006 15:22:24 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k5JDMOl6021930 for ; Mon, 19 Jun 2006 15:22:24 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 15:22:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jun 2006 15:22:23 +0200 Message-ID: <69D2C30BFA177E4DB3E6C93A94C87F1F858364@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Legacy NAT traversal for NSIS Thread-Index: AcZtXpAo4ZqImHbcQjOAYQJ4vNANNQAeuKiwCLYH+KAAszxBQAAJBksg From: "Pashalidis, Andreas" To: X-OriginalArrivalTime: 19 Jun 2006 13:22:23.0963 (UTC) FILETIME=[66C2C2B0:01C693A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [NSIS] Legacy NAT traversal for NSIS X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hello NSIS, Is anyone interested to make NSIS work through legacy NATs ?? (i.e. NSIS-unaware NATs) Under the following link a preliminary document (in I-D format) can be found that describes a solution approach. http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legacynats-00. txt In an exremely small nutshell: the idea is to tunnel both signalling and data traffic over a single UDP NAT binding. If enough interest exists we plan to submit the document to the working group. But: is there any interest at all?? Best Regards, Andreas Pashalidis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 20 04:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsbqt-0000og-Lm; Tue, 20 Jun 2006 04:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsbqs-0000oY-Gd for nsis@ietf.org; Tue, 20 Jun 2006 04:44:50 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsbqo-0001mj-QB for nsis@ietf.org; Tue, 20 Jun 2006 04:44:50 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5K8iWO6009813; Tue, 20 Jun 2006 09:44:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) Date: Tue, 20 Jun 2006 09:44:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24) Thread-Index: AcaRUXUz39tvYFmhR7yzr1y/8MafhwC9BBrA From: "Hancock, Robert" To: "Magnus Westerlund" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I think how to handle this set of comments is now pretty clear. I've pasted this discussion thread into the issue tracker at (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue109) and they will be implemented in version -10. cheers, r. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 16 June 2006 15:30 > To: john.loughney@nokia.com > Cc: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT=20 > traversal, M3,also L2/L19/L24) >=20 >=20 > Hi, >=20 > I think the proposed solution in these email is fine. I am also fine=20 > with maintaining the split. But please be clear about it. >=20 > Cheers >=20 > Magnus >=20 > john.loughney@nokia.com wrote: > > Hi all, > >=20 > >>> M3. NAT traversal for GIST. > >>> Section 7.2: > >>> > >>> What plans are there for clearly defining NAT behavior=20 > for GIST and=20 > >>> the relevant NSLPs? I think one should avoid repeating=20 > the mistake=20 > >>> with NATs of not specifying the behavior sufficiently for=20 > NSIS. Thus > > I=20 > >>> think there is need to specify in great deal what is=20 > going to happen=20 > >>> at the translation. > >> There is already an individual I-D which describes the=20 > >> required behaviour on a NAT,=20 > >> draft-pashalidis-nsis-gimps-nattraversal-02.txt > >> (see in particular section 6). I believe that this document=20 > >> should become a working group document (of at least some=20 > >> working group - I'm not clear on the relationship with=20 > behave here).=20 > >=20 > > I think that the NAT traversal material should belong in a separate > > document - as we have seen with STUN, for example, the NAT > > considerations > > change - so I think it makes sense to have it separate. > >=20 > >> What we've tried to do so far is distinguish the GIST=20 > >> specification, i.e. what nodes implementing GIST have to do,=20 > >>from the NAT specification, i.e. what NAT nodes have to do=20 > >> with GIST messages. > >> The overall solution is outlined here in the GIST spec, but=20 > >> there is a lot more detail that can be added about what NATs=20 > >> should do (specifically in terms of managing their bindings)=20 > >> which is not really a concern of the GIST implementor so it=20 > >> seems reasonable to keep the two separate. > >=20 > > Agreed. > >=20 > >>> L2. Section 3.3, page 12, second paragraph: > >>> " In addition, it should be noted that NAT traversal almost > > certainly > >>> requires transformation of the MRI field in GIST messages (see > >>> Section 7.2). Although the transformation does not have to be > >>> defined as part of the standard, the impact on existing > > GIST-aware > >>> NAT implementations should be considered." > >>> > >>> It seems that not defining the NAT behavior for GIST can=20 > potentially=20 > >>> cause interop problems and make it very hard to use. What is the > > plans=20 > >>> for addressing this? Are there already existing GIST-aware NATs? > >> This is probably badly worded. What we are trying to say is=20 > >> that, just as there is a split: > >> a) the GIST spec, and > >> b) how NATs handle GIST messages > >> > >> when you define a new MRM there are two things to do: > >> a') how to modify GIST implementations to handle the MRM > >> b') how to modify NATs to handle the new MRM > >> > >> Section 3.3 is saying that the information provided as part of > >> (a') does not have to define all the details of NAT traversal,=20 > >> but that (b') has to be considered, e.g. if necessary as an=20 > >> extension to the base GIST nat traversal specification. > >=20 > > I think a rewording of the text in 3.3 would be a good idea. > >=20 > >> (As an aside, there is conceptually a class of MRMs that will=20 > >> in fact be transparent to NATs. It may be valuable to=20 > >> highlight those in some way so that they can be deployed=20 > >> without having to update NATs where the update only consists=20 > >> of the information "you don't have to do anything".) > >> > >> (Another aside: the GIST NAT traversal functionality has been=20 > >> implemented by at least one team. I don't believe it has made=20 > >> it into any standard distributions. The 'existing' in the spec=20 > >> means 'existing at the time that the new MRM is being proposed'.) > >> > >>> L19. Section 7.2, page 74: > >>> > >>> "Note that Confirm messages are not translated." > >>> > >>> Why isn't them? Also where is that specified? And what is really > > meant=20 > >>> with "not translated"? > >> Well, the solution is designed so they don't need to be=20 > translated.=20 > >> (If they did, it would be very tricky, since often they are=20 > >> carried in C-mode and are invisible to NATs anyway.) Probably=20 > >> the specification should say more explicitly "only Query=20 > >> messages and messages with a NTO are translated by the NAT". > >> > >> "Not translated" means "the payload of the UDP message is not=20 > >> translated". So that can also be made more explicit. > >=20 > > Please do make it more explicit. > >=20 > >>> L24. Section A.3.8: > >>> "the number of GIST payloads translated by the NAT" > >>> > >>> The NAT? There might be several NATs on the path and it=20 > is not clear=20 > >>> how that is handled. One concern would be if different=20 > NATs translate > >=20 > >>> different fields. > >> The idea is that the 'list of translated objects' field=20 > >> contains the objects that have been successfully translated by=20 > >> every NAT. > >> In other words, it is the intersection of the translation=20 > >> capabilities of the set of traversed NATs. The first NAT=20 > >> initialises it, subsequent NATs may have to remove objects=20 > >> which it could not translate. > >> The "Type-Count" field is just the length of this list (to=20 > >> allow the message to be parsed). This needs to be made clearer=20 > >> in the spec. > >=20 > > If you can add this to your ToDo list for the update, that would be > > great. > >=20 > > thanks, > > John > >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 20 05:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FscdX-0003jr-Il; Tue, 20 Jun 2006 05:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FscdW-0003jj-UC for nsis@ietf.org; Tue, 20 Jun 2006 05:35:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FscdW-0006wg-80 for nsis@ietf.org; Tue, 20 Jun 2006 05:35:06 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5K9RMB0017990; Tue, 20 Jun 2006 10:27:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2 Security Issues Date: Tue, 20 Jun 2006 10:27:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2 Security Issues Thread-Index: AcaRPmME1Y9HRVvATYmQfLvGDhpe7wDCdQcw From: "Hancock, Robert" To: "Magnus Westerlund" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, inline ... > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 16 June 2006 13:14 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2=20 > Security Issues >=20 >=20 > Hancock, Robert wrote: > > Hi, > >=20 > > the security issues, M2: > >=20 > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > >> Sent: 01 June 2006 15:23 > >> To: nsis@ietf.org > >> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 > >> > >> M2. Security functions for d-mode > >> > >> When reading the security consideration and the specification on=20 > >> security properties I get a bit frightened that there are no=20 > >> authentication mechanism specified for d-mode. It seems that there=20 > >> should be need for authentication of d-mode queries etc to=20 > >> ensure that=20 > >> the a NSIS node is talking to someone that really has the right to=20 > >> perform the query and association creation.=20 > >=20 > > This is an important question. Some high level analysis: > > *) d-mode basically has two functions:=20 > > - to set up routing state > > - to set up messaging associations > >=20 > > Authentication/authorisation of the 'right' to set up the MAs > > is actually handled within the MA protocols themselves (if you=20 > > use TLS or whatever). This can use traditional=20 > cryptographic security > > techniques. So there should be no d-mode security issue here. >=20 > Hmmm. I see that being easily done for the MA that are=20 > established over=20 > connection oriented protocols. What about applications using=20 > D-mode for=20 > application data? This is then partly a terminology/concept issue: *) we define D-mode as where there is no per-message state, which effectively rules out many channel security protocols anyway. *) OTOH the C-mode is not restricted to 'fully fledged' connection- oriented protocols like TCP; it's supposed to be used for anything=20 where some [don't know what to call it]-state is set up between two nodes with fixed IP addresses. *) so, for example, DTLS/UDP or DTLS/DCCP or IPsec AH/UDP or whatever=20 would count as additional C-mode configuration possibilities. they aren't allowed in the current version of the spec, because we have not chosen to define an unreliable transport option for C-mode. But if we decided that such a mechanism was useful, then this is how it would be incorporated (rather than by securing D mode itself). *) as an aside: in the layering model, applications do not choose=20 which of C/D mode they use. they express their transfer requirements (reliable or not, secured or not, etc.) and then GIST chooses what=20 to do. A consequence of us not (yet) defining an unreliable transport option is that if an application requests secure transfer, it will get TLS/TCP. >=20 > >=20 > > Authentication/authorisation of the 'right' to set up routing > > state is a more tricky. The point is that there is no framework=20 > > within which the correctness of routing state can be secured in > > the traditional sense. Whether or not a node is on the route > > of a flow is a dynamic function of the forwarding tables in the > > network as a whole; two nodes could authenticate with each other > > all that they want to, but this would tell us nothing about=20 > > whether the routing state itself was correct, since that can only > > be done by interaction with the forwarding layer. A further point > > is that at the start of the d-mode exchange, you can no idea > > which peer you are going to be communicating with, so at least > > some unauthenticated discovery phase would be needed anyway. > > The GIST design is supposed to restrict the scope of d-mode > > to this initial phase, and move over directly to c-mode as soon > > as it is meaningful to do so. > >=20 > > Section 8.3 is supposed to be about the sort of 'non-cryptographic'=20 > > authentication which can/must be done in these circumstances. >=20 > Yes, maybe I am being overly paranoid here. And it seems that if you=20 > like to authenticate the D-mode requests you could use IPsec=20 > AH mode to=20 > accomplish that. indeed (but see also above). > However lets assume that this is sufficient=20 > for now. I=20 > intended to request a security review of this protocol as=20 > soon as we are=20 > ready to progress GIST to IETF last call. That will be good to get. >=20 > >=20 > >> Not having such a=20 > >> mechanism=20 > >> seems to prevent building a system where the domains edge=20 > >> nodes handles=20 > >> the primary security and the internal nodes only accept=20 > GIST messages=20 > >> that are authenticated by nodes belonging to the domain. > >=20 > > I don't understand the problem here. There is nothing to stop > > a domain being deployed with the security model you indicate; for > > example: > > - a host initiates the GIST handshake with the appropriate edge > > node, sets up routing state and a messaging association > > - the edge node authenticates the host as part of the MA setup > > and decides what the host is allowed to do > > - the host initiates some signalling application transaction > > - if the edge node decides the signalling transaction is valid,=20 > > it continues to execute the transaction on the domain interior > > nodes (GIST handshake for route discovery followed by a signalling > > application exchange; typically the necessary MAs would already > > be in place).=20 > >=20 > > is this the sort of model you are thinking about? >=20 > Yes. But with the extra twist that I perceive a threat of spoofing or=20 > manage to tunnel attacks into the domain. Thus having a desire to=20 > restrict the interior nodes to only accept GIST D-mode=20 > messages that are=20 > authenticated as coming from a the domain. But I will assume=20 > that this=20 > can actually be accomplished with IPsec. >=20 > >=20 > >> Section 8.6: I also am concerned that if there exist no secured MA=20 > >> between two GIST nodes, a on-path Man in the middle can=20 > prevent there=20 > >> from ever existing a secured MA. > >=20 > > This is not what 8.6 is aiming at. Modulo the residual threat > > in 8.7, 8.6 is saying that > > - IF you have a suitable security policy and credentials at=20 > each node > > (and 8.6 explains what 'suitable' means) > > - THEN the only things that an on-path MitM can do are=20 > > (a) prevent all communication > > (b) allow a properly secured MA which it cannot intercept > > The MitM cannot do > > (c) allow an insecure MA which it can intercept > >=20 > > (a) is not something that any security solution can=20 > prevent: an on-path > > MitM can always just block traffic. (b) is the desired=20 > outcome anyway. > > What is ruled out is (c), which is a consequence of the=20 > MitM detection > > mechanism in the Confirm and the security policy which says=20 > what to do > > if the MitM is detected. (Basically, any attempt to set up=20 > an insecure > > MA is automatically detected as an MitM attack.) > >=20 >=20 > I think you are mostly correct. However I think there is a=20 > case D that=20 > is not sufficiently warned about. The case is the two GIST=20 > peers A and=20 > B, where A tries to create a MA between them. The attacker C=20 > is on-path=20 > and can intercept and rewrite the GIST messages. A offers=20 > both TCP/TLS=20 > and TCP in its query. C change that to only being TCP. Which=20 > it can sit=20 > in the middle and rewrite anything in. B. gets the modified query and=20 > sends a response. The response sent back by C is modified so=20 > that A gets=20 > the picture that B selected TCP. The TCP connection is=20 > established and=20 > now C can modify the checks as they are not secured. >=20 > My issue with this whole thing is that the only way of knowing that a=20 > MITM exist is to require the usage of TLS with certs at both end, and=20 > use that to verify the query sent unsecured. I think it should be=20 > clearer that not having a policy of using TLS equals leaving=20 > it open for=20 > MITM. Or is the above case based on some misunderstanding? Your analysis is correct. You can find a similar discussion at http://www1.ietf.org/mail-archive/web/nsis/current/msg05743.html. Section 8.6 was written partly in response to that thread, and the last sentence there is supposed to address the point you raise: "Therefore, provided that the Querying node applies a security policy on the messaging association protocols it will create that ensures at least this minimal level of protection is met, it can be assured that the capability discovery process will result in the setup of a messaging association with the correct security properties as appropriate for the two peers involved." It may be that this sentence does not advertise its content very effectively (maybe it should be said the other way round, e.g.=20 'if the querying node does not XXX ...'). Views? cheers, robert h. >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 20 06:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdEk-0006MN-6y; Tue, 20 Jun 2006 06:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsdEi-0006G7-AB for nsis@ietf.org; Tue, 20 Jun 2006 06:13:32 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsdEh-00009w-Df for nsis@ietf.org; Tue, 20 Jun 2006 06:13:32 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5KADNOt025837; Tue, 20 Jun 2006 11:13:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues) Date: Tue, 20 Jun 2006 11:13:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues) Thread-Index: AcaRUP6rD131KkDwT3aNsTR6Z7MpZgC+4aEA From: "Hancock, Robert" To: "Magnus Westerlund" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 16 June 2006 15:27 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1:=20 > congestion control/rate limiting issues) >=20 >=20 > Hancock, Robert wrote: > > Hi all, > >=20 > > comments on the congestion control/rate limiting issues > > (M1 and in fact L16-part as well): > >=20 > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > >> Sent: 01 June 2006 15:23 > >> To: nsis@ietf.org > >> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 > >> > >> M1. Congestion Control > >> > >> This affects text not only in 5.3.3 but also 7.1.3 and=20 > possibly other=20 > >> places. But I do have a general concern that the=20 > congestion control=20 > >> measurements described in the specification is underspecified. > >> > >> First in 5.3.3 I don't see any normative minimal values, or even=20 > >> recommended values for T1 and T2 that will be safe to=20 > deploy on the=20 > >> internet. I don't find it acceptable that the developer needs to=20 > >> investigate which values that are safe to use and which are=20 > >> not. There=20 > >> should also be some criteria documented for when it is=20 > >> acceptable to go=20 > >> beyond these values. So my concern here is that the=20 > >> retransmission runs=20 > >> havoc and create way to many packets to be sent. > >=20 > > This is a fair point. I suppose it is impossible to get away > > permanently without giving concrete numbers in this case. > >=20 > > In terms of what sort of values to use and how to describe the > > constraints on them, I think a good model to follow is probably > > the SIP INVITE transaction specification (17.1.1.2 of rfc3261) > > which says [fortunately the timer names are the same...] > >=20 > > " The default value for T1 is 500 ms. T1 is an estimate of the RTT > > between the client and server transactions. Elements=20 > MAY (though it > > is NOT RECOMMENDED) use smaller values of T1 within=20 > closed, private > > networks that do not permit general Internet connection.=20 > T1 MAY be > > chosen larger, and this is RECOMMENDED if it is known in advance > > (such as on high latency access links) that the RTT is larger. > > Whatever the value of T1, the exponential backoffs on=20 > retransmissions > > described in this section MUST be used." > >=20 > > and later that T2 should be 64*T1. In our case, 500ms seems=20 > a reasonable > > default also; I think T2<=3D64*T1 since there is a separate=20 > bound on the > > T2 value from the signalling application (see the second=20 > paragraph of > > 5.3.3). I would be tempted to relax the NOT RECOMMENDED=20 > clause, since > > a smaller timeout would be valid and possibly quite useful=20 > on a wider > > range of networks, in particular Internet-connected networks but > > where it is known that the Query should be answered within the local > > network. Comments and text suggestions welcome. >=20 > I think this is reasonable start. It seems to be to be a good idea to=20 > allow the adaptation of the timers based on feedback from the=20 > peer. It=20 > seems possible to use the GIST query and the response to measure the=20 > current RTT. Allowing modification of the timers to track=20 > that value +=20 > some processing delay + fudge factors seems one way forward. ok, we can work on including this. >=20 >=20 > >=20 > >> Secondly, there are also no values documented for the rate=20 > control. I=20 > >> think it is necessary to document what internet safe values=20 > >> are here so=20 > >> that one does not cause problems. In addition is seems a bit=20 > >> simplistic=20 > >> to use a token bucket with some parameters selected based on=20 > >> the local=20 > >> link as GIST clearly sends messages beyond the local link.=20 > Thus one=20 > >> might have to consider being a bit smarter and more adaptive=20 > >> to what is=20 > >> seen for different flows. > >=20 > > Here I am not so sure. The text here was informed by the equivalent > > discussion for ICMPv6 (reference [26], now RFC4443), which caused > > an extensive thread on the v6 mailing list (start at > > http://www1.ietf.org/mail-archive/web/ipv6/current/msg01343.html + > > another 60 or so messages). > >=20 > > GIST is not ICMP but many of the same issues arise: messages are > > generated in the IP 'control plane' (in so far as this is a > > meaningful term), partly autonomously but mainly in response to > > events initiated by end systems, the messages go beyond the local > > link, rules have to be written so they apply to a host and a core > > router and everything in between. The end result for ICMP was to=20 > > write something minimal. (The link bandwidth here is used as an > > indicator for where a router is in a network - core/access/whatever. > > It's clearly imperfect but there's nothing else apart from dynamic > > adaptiveness to make use of, and fixed values seem even worse.) > >=20 > > We'd really like to avoid adaptiveness in the D-mode state machine. > > The main use of D-mode should be for Queries/Responses for which=20 > > adaptation is not meaningful for initial messages (there is no > > pre-existing state); if there is a large amount of signalling data > > to send for a given flow, then GIST should transition to C-mode > > anyway, and the rate limits chosen to be cautious to encourage > > that. We aimed for robustness and simplicity rather than=20 > performance. > >=20 > > It might be possible to use some sort of adaptiveness to select > > an appropriate rate to apply to refresh queries used for GIST > > probing (see also your point at the end of L16). The=20 > current situation > > is that you can probe as fast as you like until you hit the=20 > rate limit, > > and that it's up to the implementer to decide how fast is really > > necessary depending on an assessment of route stability (for which > > I don't know any good objective estimator). On the assumption that=20 > > most probes will go to the peer you already know about, one could > > refine this to apply a separate token bucket limiter for probe=20 > > messages towards that peer, which was adapted according to knowledge > > of congestion state with that peer (based on message loss). We need > > input on whether that complexity is really necessary however, since > > it doesn't change the situation for the whole of D-mode but just a > > particular subset of it. >=20 > I can understand the reluctance to use adaptation. I am also=20 > fine with=20 > not using adaptation as long as the traffic is not causing any sever=20 > problem. The question is if the parameters present in the=20 > ICMP RFC are=20 > good enough also for GIST. Has someone made any analysis of=20 > this? What=20 > amount of bit-rate are we talking about. Do we need to=20 > provide guidance=20 > on when the default parameters present in ICMP is appropriate=20 > to use for=20 > GIST? that would be too easy ... ;-) the end result of the ICMP discussion (as I read it) has been that there *are* no default parameters in the ICMP spec. (The relevant section is 2.4(f) of rfc4443.) There is a definition of a set of parameters (bucket rate N and size B), but the closest one gets to parameters is "For example, in a small/mid-size device, the possible=20 defaults could be B=3D10, N=3D10/s." which is about as tentative as it comes. And I would not say that the numbers are that useful; what to reuse would be the text that says - it's configurable - take into account where you are in the network (and implicitly that limiting based purely on inter-packet timers or absolute bandwidth caps are not useful, which was what was removed compared to the previous version of the spec.) There have been analysis documents in the distant past about message rates, but only applying to QoS (based on RSVP experience) and even they have been controversial because they depend so strongly on assumptions about refresh reduction. Now we have a wider range of signalling applications, so the situation is likely to be even less clear. the best advice to implementors I can think of would be to say that=20 *) the bucket size (B) should be related to the number of signalling sessions that the node is expected to support *) the rate should allow the bucket to be discharged in a second (and these would be SHOULD starting points). That still doesn't give an actual number, but it does relate the number to a more 'objective' system sizing parameter that implementors will have to think about anyway. >=20 >=20 > >=20 > >> Third, the implication and congestion issues with local=20 > >> repair seems to=20 > >> have been brushed over. Section 7.1.3 do indicate that you=20 > >> need to take=20 > >> care, but nothing more. Are there some potential for=20 > >> aggregation of the=20 > >> queries to minimize the load and have quicker convergence? > >=20 > > There is no mechanism that I can think of. Certainly there is > > no aggregation possible in general, since every affected flow > > might be affected differently, especially if next-NSIS-routers > > are many hops away. We depend on the rate limiting to prevent > > the generated Queries causing a flood, but that's about it.=20 > > (There are aggregation techniques for transmitting the=20 > notifications, > > but they take place at the NSLP level.) > >=20 >=20 > Okay, it might not be a real issue. As long as there is no=20 > risk for the=20 > local repair to cause instabilities due to its caused load preventing=20 > other operations from happening due the the repair. But if I=20 > understand=20 > correctly most keep-alive towards NSLPs are done in C-mode. certainly, signalling application state refresh (distinct from routing state refresh) can be done this way. cheers, r. >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 20 18:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsp32-00077e-DW; Tue, 20 Jun 2006 18:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsp2r-00076Q-5u; Tue, 20 Jun 2006 18:50:05 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsp2o-0005yw-Of; Tue, 20 Jun 2006 18:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5KMo2WR009169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fsp2n-0001ZB-RP; Tue, 20 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Jun 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-tunnel-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSIS Operation Over IP Tunnels Author(s) : C. Shen, et al. Filename : draft-ietf-nsis-tunnel-00.txt Pages : 33 Date : 2006-6-20 This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-tunnel-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-tunnel-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-20164222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-tunnel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-tunnel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20164222.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Jun 21 05:04:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsydk-0001g3-Ao; Wed, 21 Jun 2006 05:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsydi-0001fy-MG for nsis@ietf.org; Wed, 21 Jun 2006 05:04:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsydh-0002JR-L2 for nsis@ietf.org; Wed, 21 Jun 2006 05:04:46 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D50EA4F0002; Wed, 21 Jun 2006 11:04:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:04:33 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:04:25 +0200 Message-ID: <44990B99.2070008@ericsson.com> Date: Wed, 21 Jun 2006 11:04:25 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: congestion control/rate limiting issues) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 09:04:25.0510 (UTC) FILETIME=[B1B5C460:01C69511] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, See inline. Hancock, Robert wrote: > hi, > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 16 June 2006 15:27 >> To: Hancock, Robert >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (M1: >> congestion control/rate limiting issues) >> >> >> Hancock, Robert wrote: >>> Hi all, >>> >>> comments on the congestion control/rate limiting issues >>> (M1 and in fact L16-part as well): >>> >>>> -----Original Message----- >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>>> Sent: 01 June 2006 15:23 >>>> To: nsis@ietf.org >>>> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09 >>>> >>>> M1. Congestion Control >>>> >>>> This affects text not only in 5.3.3 but also 7.1.3 and >> possibly other >>>> places. But I do have a general concern that the >> congestion control >>>> measurements described in the specification is underspecified. >>>> >>>> First in 5.3.3 I don't see any normative minimal values, or even >>>> recommended values for T1 and T2 that will be safe to >> deploy on the >>>> internet. I don't find it acceptable that the developer needs to >>>> investigate which values that are safe to use and which are >>>> not. There >>>> should also be some criteria documented for when it is >>>> acceptable to go >>>> beyond these values. So my concern here is that the >>>> retransmission runs >>>> havoc and create way to many packets to be sent. >>> This is a fair point. I suppose it is impossible to get away >>> permanently without giving concrete numbers in this case. >>> >>> In terms of what sort of values to use and how to describe the >>> constraints on them, I think a good model to follow is probably >>> the SIP INVITE transaction specification (17.1.1.2 of rfc3261) >>> which says [fortunately the timer names are the same...] >>> >>> " The default value for T1 is 500 ms. T1 is an estimate of the RTT >>> between the client and server transactions. Elements >> MAY (though it >>> is NOT RECOMMENDED) use smaller values of T1 within >> closed, private >>> networks that do not permit general Internet connection. >> T1 MAY be >>> chosen larger, and this is RECOMMENDED if it is known in advance >>> (such as on high latency access links) that the RTT is larger. >>> Whatever the value of T1, the exponential backoffs on >> retransmissions >>> described in this section MUST be used." >>> >>> and later that T2 should be 64*T1. In our case, 500ms seems >> a reasonable >>> default also; I think T2<=64*T1 since there is a separate >> bound on the >>> T2 value from the signalling application (see the second >> paragraph of >>> 5.3.3). I would be tempted to relax the NOT RECOMMENDED >> clause, since >>> a smaller timeout would be valid and possibly quite useful >> on a wider >>> range of networks, in particular Internet-connected networks but >>> where it is known that the Query should be answered within the local >>> network. Comments and text suggestions welcome. >> I think this is reasonable start. It seems to be to be a good idea to >> allow the adaptation of the timers based on feedback from the >> peer. It >> seems possible to use the GIST query and the response to measure the >> current RTT. Allowing modification of the timers to track >> that value + >> some processing delay + fudge factors seems one way forward. > > ok, we can work on including this. > Good, lets see how complex this becomes and if it is worth the effort. So I would suggest that the WG thinks up some strawmen to discuss around. [snip] > > that would be too easy ... ;-) > > the end result of the ICMP discussion (as I read it) has been that > there *are* no default parameters in the ICMP spec. (The relevant > section is 2.4(f) of rfc4443.) There is a definition of a set of > parameters (bucket rate N and size B), but the closest one gets to > parameters is "For example, in a small/mid-size device, the possible > defaults could be B=10, N=10/s." which is about as tentative as it > comes. And I would not say that the numbers are that useful; what to > reuse would be the text that says > - it's configurable > - take into account where you are in the network > (and implicitly that limiting based purely on inter-packet timers > or absolute bandwidth caps are not useful, which was what was removed > compared to the previous version of the spec.) > > There have been analysis documents in the distant past about message > rates, but only applying to QoS (based on RSVP experience) and even > they have been controversial because they depend so strongly on > assumptions > about refresh reduction. Now we have a wider range of signalling > applications, so the situation is likely to be even less clear. > > the best advice to implementors I can think of would be to say that > *) the bucket size (B) should be related to the number of signalling > sessions that the node is expected to support > *) the rate should allow the bucket to be discharged in a second > > (and these would be SHOULD starting points). > > That still doesn't give an actual number, but it does relate the number > to a more 'objective' system sizing parameter that implementors will > have to think about anyway. > Well, could we provide some conservative numbers that are quite certain to no screw up the network completely even in some worst case scenario and provide those as default values with instructions how one may modify them. I am still concerned about the risk of misconfiguration leading to serious issues. An interesting complication that might be shown is that the maximum load from GIST will only show up when there is need for a massive amount of D-mode traffic, like when attempting to do local repair and refresh the routing state. The unfortunate things here is that these are situations when there is a high risk that there anyway is quite a heavy load on the network due to route changes etc. I fear that we can't do much better than some conservative values and recommendations for how to configure this if you think you know what you are doing. The next step seems to be a fully adaptive scheme which will not be simple. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 21 05:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsymm-00082T-6V; Wed, 21 Jun 2006 05:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsymk-00082L-56 for nsis@ietf.org; Wed, 21 Jun 2006 05:14:06 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsymi-0003Cn-Hy for nsis@ietf.org; Wed, 21 Jun 2006 05:14:06 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B0DCF112E; Wed, 21 Jun 2006 11:13:22 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:13:22 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:13:21 +0200 Message-ID: <44990DB1.2060205@ericsson.com> Date: Wed, 21 Jun 2006 11:13:21 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09: M2 Security Issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 09:13:21.0948 (UTC) FILETIME=[F173B5C0:01C69512] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hancock, Robert wrote: > hi, > > inline ... > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: 16 June 2006 13:14 >> >> Hancock, Robert wrote: >>> the security issues, M2: >>> >>>> -----Original Message----- >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] [snip] >> What about applications using D-mode for >> application data? > > This is then partly a terminology/concept issue: > *) we define D-mode as where there is no per-message state, which > effectively rules out many channel security protocols anyway. > *) OTOH the C-mode is not restricted to 'fully fledged' connection- > oriented protocols like TCP; it's supposed to be used for anything > where some [don't know what to call it]-state is set up between two > nodes with fixed IP addresses. > *) so, for example, DTLS/UDP or DTLS/DCCP or IPsec AH/UDP or whatever > would count as additional C-mode configuration possibilities. they > aren't allowed in the current version of the spec, because we have > not chosen to define an unreliable transport option for C-mode. But > if we decided that such a mechanism was useful, then this is how it > would be incorporated (rather than by securing D mode itself). > *) as an aside: in the layering model, applications do not choose > which of C/D mode they use. they express their transfer requirements > (reliable or not, secured or not, etc.) and then GIST chooses what > to do. A consequence of us not (yet) defining an unreliable transport > option is that if an application requests secure transfer, it will > get TLS/TCP. > Thanks for the clarification. So in the end it comes down to what policy the NSLP has for transporting its messages. So if it requires security the GIST will be forced to use a secured C-mode as the D-mode can't be secured in the way the policy would require. It resolves my question. > [SNIP] > Your analysis is correct. You can find a similar discussion at > http://www1.ietf.org/mail-archive/web/nsis/current/msg05743.html. > Section 8.6 was written partly in response to that thread, and the > last sentence there is supposed to address the point you raise: > > "Therefore, provided that the Querying node applies a > security policy on the messaging association protocols it will create > that ensures at least this minimal level of protection is met, it can > be assured that the capability discovery process will result in the > setup of a messaging association with the correct security properties > as appropriate for the two peers involved." > > It may be that this sentence does not advertise its content very > effectively (maybe it should be said the other way round, e.g. > 'if the querying node does not XXX ...'). Views? > I at least would like it to be more explicit and clear about the threat. So turning the sentence around as proposed I think will be much more eye catching to the issue. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 21 09:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2hV-00062m-6H; Wed, 21 Jun 2006 09:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2hU-00062h-DO for nsis@ietf.org; Wed, 21 Jun 2006 09:24:56 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2hS-0002WM-LF for nsis@ietf.org; Wed, 21 Jun 2006 09:24:56 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A510E1BAC4D; Wed, 21 Jun 2006 15:13:02 +0200 (CEST) In-Reply-To: <07ca01c690f8$e9dde380$c5f0200a@amer.cisco.com> References: <07ca01c690f8$e9dde380$c5f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CE8F470-60D1-4933-A1B5-4CC1E4DDAF13@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Wed, 21 Jun 2006 15:24:45 +0200 To: Dan Wing X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: John Loughney , nsis Subject: [NSIS] Re: [Ietf-behave] review of the "NAT/Firewall NSISSignaling Layer Protocol (NSLP) " X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org [posting to the nsis list only] Hi Dan, All, Many thanks to Dan for reviewing the NATFW NSLP! More inline. Am 16.06.2006 um 05:56 schrieb Dan Wing: > John, > > I read through parts of draft-ietf-nsis-ntlp-09.txt to understand > how NATs are handled in NTLP. In that document's section 7.2, > "NAT Traversal", it says: > > 5. Add a NAT-Traversal payload, listing the objects which have > been > modified and including the unmodified MRI and any other data > needed to interpret the response. (If a NAT-Traversal > object is > already present, in the case of a sequence of NATs, the list of > modified objects may be updated and further opaque data added, > but the MRI contained in it is left unchanged.) > > which sounds like you would be disclosing my 'private' IP address > on the > public side of an NSIS-aware NAT. I believe I'm misinterpreting > that, as in > -ietf-nsis-nslp-natfw- I found text that alluded to avoiding such > information leakage by having the outer-most NAT or firewall > configured to > know that it is the outer-most NAT (or firewall) and to terminate REA > processing. There some difference between the NAT behaviour in the NTLP spec and the NATFW NSLP. The NATFW NSLP follows the way of not disclosing any private IP address. The way how the NTLP will do it has been specified to some extend in the draft but is undergoing some additional work and thoughts. I.e., the NTLP is probably disclosing the private IP address to NTLP nodes outside the private IP address realm. (as Andreas mentioned there is another draft discussing the NAT traversal of the NTLP without a NATFW NSLP) > > Section 1.1 mentions STUN and TURN only being able to process two IP > addresses; have you looked at ICE and would it be useful. I > noticed the > reference to TURN should be updated to draft-ietf-behave-turn. I believe this refers to the NTLP draft. > > > > > > On to -nsis-nslp-natfw-11: > > My first concern with this is Appendix A and section 3.8.2, which > outlines > the fundamental problem of NAT traversal -- how to "leave" your > network, on > the correct path, in order to get the NSLP messages to traverse the > NATs > that are on-path between you and your intended peer. This problem is > similar to STUN, am I correct? Section 3.8.2 uses words that > almost say Right, it is similar to STUN and ICE issues. > it, as well: > > o It may be necessary to use a signaling destination address (SDA) > as the actual target of the REA message (NR+) if the DR is > located > behind a NAT and the address of the DS is unknown. The SDA > is an > arbitrary address in the outermost address realm on the other > side > of the NAT from the DR. Typically this will be a suitable > public > IP address when the 'outside' realm is the public Internet. > This > choice of address causes the REA message to be routed through > the > NATs towards the outermost realm and would force interception of > the message by the outermost NAT in the network at the boundary > between the private address and the public address realm (the > edge-NAT). It may also be intercepted by other NATs and > firewalls > on the path to the edge-NAT. > > It seems that applications will need to collect several different > routable > addresses and exchange those addressees with their intended peers > in order > to optimize the network path. This is what ICE does, and a > generalization > of this technique is described in draft-ford-behave-app-02.txt > section 2.3. Yes, indeed, an application can collect multiple addresses if needed. An optimization would need to find out which of the obtained public contact addresses is the best suited. This section in the appendix is one of my open work items for the draft, since it is crucial for operating the NATFW NSLP. Thanks for the pointer to the BEHAVE draft. I will check it and then go back to the section. > > > I'm also concerned by configuration information that is necessary, > such as > this (in 3.8.2): > > The data receiver is > challenged to determine whether it is solely located behind > firewalls > or NATs, for choosing the right message routing method. This > decision can depend on a local configuration parameter, possibly > given through DHCP, or it could be discovered through other non- > NSLP > related testing of the network configuration. > > and > > The end host cannot be assumed to know this [[the NAT device]] > device - > instead the NAT or firewall box itself is assumed to know that > it is > located at the outer perimeter of the network. > > For example, I am typing this message from my house, where I have > two NATs > and a hardware VPN with split tunneling. If both of my NATs were > NSIS and > NSLP aware, I don't know how they would successfully send the > appropriate > NSIS messages in this configuration; can you elaborate what my > application > or my NSIS-aware OS stack would do in this situation? From my > experience, I'm happy to clarify but I have to say I would need some information about the ordering of the NATs and the VPN gateway in the topology. Are those two NATs in sequence or in parallel? (I assume the latter?) > my application would need to gather different IP addresses (one > from my > 'internal' network that I'm IPsec'd into, another from my local > interface, > and another from my connection to the Internet). Even if this _isn't_ > necessary -- and I don't see how you'd have success otherwise, but I'm > interested in hearing -- I'm curious what information would be in this > as-yet-undefined DHCP option (I didn't notice any NSIS-related DHCP > document). > > > > > > > On page 7 is this sentence fragment: > > However, if the data receiver resides in a public > addressing realm. Will be removed, seems to be a left over from some old text. > > > Figure 3 and its associated text would be clearer if the > middleboxes were > numbered and the text referred to each middlebox explicitly. > Specifically, > the sentences: > > Note that this IP address is not the private > IP address of the responder. Instead a NAT binding (including a > public IP address) has to be previously installed on the NAT that > subsequently allows packets reaching the NAT to be forwarded to the > receiver within the private address realm. > > have too many "this" and "a NAT binding" and "the NAT" to be clearly > understood. The other diagrams in surrounding figures 2 through 6 > might > also benefit from similar changes. Ok, thanks! That makes understanding easier. > > > > Section 2.8, "Multihomed Network with NAT" promises that section > 3.8.2 has > an extended discussion of such multihoming, but I didn't find > anything in > that section related to multihomed NATs. Good catch! I need to write some text on this. Many thanks and I will come back to the question on who the NATFW NSLP will work in your home configuration as soon as I have the information about the topology. Martin > > -d > > > > >> -----Original Message----- >> From: ietf-behave-bounces@list.sipfoundry.org >> [mailto:ietf-behave-bounces@list.sipfoundry.org] On Behalf Of >> john.loughney@nokia.com >> Sent: Tuesday, May 02, 2006 4:28 AM >> To: ietf-behave@list.sipfoundry.org >> Subject: [Ietf-behave] Request for a review of the >> "NAT/Firewall NSISSignaling Layer Protocol (NSLP) " >> >> Hi all, >> >> Currently, the NSIS working group is finalizing the "NAT/Firewall >> NSIS Signaling Layer Protocol (NSLP)" for signaling middleboxes. >> The current document can be found here: >> >> Http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt >> >> NSIS is working on a path-coupled signaling protocol, to signal >> nodes along the data patch. As both NAT and Firewalls are along the >> data path, NSIS signaling is developing a protocol for allow end >> nodes to signal these boxes. >> >> As both BEHAVE and MIDCOM have been working on related issues, I'd >> like to encourage people to read the document and send comments and >> questions to the mailing list - nsis@ietf.org. As long as your >> subject lines are clearly marked, I'll enable posting rights so that >> you don't have to join the NSIS mailing list. >> >> Additionally, please try not to cross-post discussion on the other >> mailing lists; unless the BEHAVE & MIDCOM chairs feel that >> cross-posting would be beneficial. >> >> thanks, >> John >> _______________________________________________ >> Ietf-behave mailing list >> Ietf-behave@list.sipfoundry.org >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave >> > _______________________________________________ > Ietf-behave mailing list > Ietf-behave@list.sipfoundry.org > https://list.sipfoundry.org/mailman/listinfo/ietf-behave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 21 15:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iC-0000Ww-3F; Wed, 21 Jun 2006 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iA-0000WT-TP; Wed, 21 Jun 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8i9-0002si-L1; Wed, 21 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5LJo1WR028009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ft8i9-0003lD-DV; Wed, 21 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-sctp-00.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : General Internet Signaling Transport (GIST) over SCTP Author(s) : X. Fu, et al. Filename : draft-ietf-nsis-ntlp-sctp-00.txt Pages : 10 Date : 2006-6-21 The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take the advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for some extensions of SCTP is also discussed, namely its Partial Reliability Extension and the usage of TLS over SCTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-ntlp-sctp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-sctp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-21102442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-sctp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-sctp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21102442.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Jun 23 15:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfP-0002Rn-5b; Fri, 23 Jun 2006 15:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfH-0002L1-3J; Fri, 23 Jun 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrfF-0004uh-RJ; Fri, 23 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo1WR012267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfF-00039o-HS; Fri, 23 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-10.txt Pages : 53 Date : 2006-6-23 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qspec-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qspec-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-23100648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qspec-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qspec-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23100648.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Jun 23 16:16:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts50-0002ef-6Q; Fri, 23 Jun 2006 16:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fts4z-0002dj-9W for nsis@ietf.org; Fri, 23 Jun 2006 16:16:37 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fts4x-0000Sl-Qn for nsis@ietf.org; Fri, 23 Jun 2006 16:16:37 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-126.messagelabs.com!1151093779!10308887!7 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 19964 invoked from network); 23 Jun 2006 20:16:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-126.messagelabs.com with SMTP; 23 Jun 2006 20:16:34 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F00339286 for nsis@ietf.org; Fri, 23 Jun 2006 16:16:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt Date: Fri, 23 Jun 2006 15:16:29 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC79D2@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt Thread-Index: AcaW/kaTNRc1lr6NTHO3fZd0EYaG7gAAYfvg From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, The updated 'QoS-NSLP QSPEC Template' I-D is available at http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt. The updates are in response to comments and discussion since IETF-65: 1. rewrote Section 2 (Introduction) for clarity 2. added clarifications on mandatory parameters in Section 4.2; added discussion of forwarding options when a domain supports a different QOSM than the QNI 3. expanded Section 4.5 on error code handling, including redefined E-Flag and editorial changes to the N-Flag and T-Flag discussions 4. made some editorial clarifications in Section 4.6 on defining new mandatory parameters 5. Section 4.7 added to identify what a QOSM specification document must include 6. clarified the requirements in Section 5 for defining a new QSPEC Version 7. made editorial changes to Section 6 (Procedures), and added procedures for handling preemption 8. removed QOSM ID assignments in Section 9 (IANA Considerations); clarified procedures for defining new mandatory parameters; added registry for QOSM error codes There are no further outstanding changes/comments pending and no open issues currently identified. Thanks, Regards, Jerry=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, June 23, 2006 3:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : QoS NSLP QSPEC Template Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-qspec-10.txt Pages : 53 Date : 2006-6-23 =09 The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC, which contains both the QoS description and QSPEC control information. The QSPEC format is defined, as are a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs. To a certain extent QSPEC parameters ensure interoperability of QOSMs. Optional QSPEC parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jun 25 04:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuPpH-0005hf-Hu; Sun, 25 Jun 2006 04:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuPpG-0005hV-Fs for nsis@ietf.org; Sun, 25 Jun 2006 04:18:38 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FuPpE-000174-1V for nsis@ietf.org; Sun, 25 Jun 2006 04:18:38 -0400 Received: (qmail invoked by alias); 25 Jun 2006 08:18:34 -0000 Received: from p549874EC.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.116.236] by mail.gmx.net (mp003) with SMTP; 25 Jun 2006 10:18:34 +0200 X-Authenticated: #29516787 Message-ID: <449E46D3.7060108@gmx.net> Date: Sun, 25 Jun 2006 10:18:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org, tsvwg@ietf.org, radiusext@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [NSIS] [Fwd: [Dime] Diameter QoS Dinner] X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, NSIS, TSVWG, RADEXT WG members might also be interested in the Diameter Quality of Service dinner. We plan to meet at the registration desk at 19:30 after the Welcome Reception on Sunday. See my previous mail: http://www1.ietf.org/mail-archive/web/dime/current/msg00401.html Please let me know if you plan to show up. Ciao Hannes -------- Original Message -------- Subject: [Dime] Diameter QoS Dinner Date: Mon, 19 Jun 2006 14:14:39 +0200 From: Tschofenig, Hannes To: Hi all, it would be good to meet Diameter QoS interested folks at the next IETF for a discussion about possible next steps before the DIME session. The DIME WG session will be on***** MONDAY, July 10, 2006** * *1740-1840 Afternoon Session III* Room 519B APP _widex_ Widget Description Exchange Service WG Room 520ABC INT _softwire_ Softwires WG Room 519A IRTF NMRG Network Management Research Group Charter *Room 513C-F OPS **_dime_* * Diameter Maintenance and Extensions WG *Room 520DEF RAI rtpsec Securing the Real-time Transport Protocol BOF Room 513B SEC _sasl_ Simple Authentication and Security Layer WG Room 518AB TSV _tsvwg_ Transport Area Working Group WG _https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66_ Hence, there is only time after the Welcome Reception on Sunday. My proposal would be to meet at the registration desk at 19:30. Please send me a mail if you are interested. Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun Jun 25 16:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuay4-0000az-GX; Sun, 25 Jun 2006 16:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuay3-0000au-5m for nsis@ietf.org; Sun, 25 Jun 2006 16:12:27 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuay1-0000g6-ET for nsis@ietf.org; Sun, 25 Jun 2006 16:12:27 -0400 Received: from s4.ifi.informatik.uni-goettingen.de ([134.76.81.226] helo=smtp.ifi.informatik.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1Fuaxv-0007hL-Um; Sun, 25 Jun 2006 22:12:22 +0200 Received: from [192.168.0.10] (p5484C436.dip0.t-ipconnect.de [84.132.196.54]) by smtp.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Sun, 25 Jun 2006 22:12:19 +0200 (CEST) Message-ID: <449EEE1F.6060309@cs.uni-goettingen.de> Date: Sun, 25 Jun 2006 22:12:15 +0200 From: Niklas Steinleitner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthias Friedrich , nsis@ietf.org Subject: Re: [NSIS] NATFW state machine draft X-Spam-Level: / X-Spam-Report: Content analysis: 0.6 points, 6.0 required 0.4 HTML_30_40 BODY: Message is 30% to 40% HTML 0.0 HTML_MESSAGE BODY: HTML included in message 0.2 HTML_TITLE_EMPTY BODY: HTML title contains no text X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.2 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1417230904==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1417230904== Content-Type: multipart/alternative; boundary="------------060605020502080509040705" This is a multi-part message in MIME format. --------------060605020502080509040705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Matthias, sorry for my late response, i before overlook your mail and notice it when preparing an update for the statemachine draft. Thanks for your deep review and helpful comments, please find my comments inline. Matthias Friedrich wrote: >Hi, > >I've got a few questions about version 02 of the NATFW state machine >draft. > > * Section 7 ("State machines for the NAT/FW NF"), state IDLE: > What's the tx_CREATE in the last action good for? > > For "Proxying for a Data Sender", see section 3.8.7.1 in the NAT/FW NSLP draft. > * Section 7 ("State machines for the NAT/FW NF"), state NONEDGE_REA: > Is there a rx_RESPONSE(SUCCESS, REA) condition missing? The response > could be coming from an upstream NF and should be passed on. The > state would stay NONEDGE_REA. > > Right, it's missing. Will be fixed in the newest version. > * Section 7 ("State machines for the NAT/FW NF"), state EDGE_REA: > The first condition looks like a copy and paste mistake. I think > a tx_RESPONSE(SUCCESS, REA) should be sent and the state should > stay EDGE_REA. An edge NF shouldn't send REAs any further. > > Oops, you're right. Thanks. > I also wonder where the tx_RESPONSE(ERROR, REA) in the second > condition could be coming from. The node is on the edge of the > network after all. > > Totally agree! Will be fixed. > * Section 8 ("State machine for the NAT/FW NR"), state SESSION: > The tg_TEARDOWN looks unnecessary to me, the session should be > terminated by a rx_CREATE && CREATE(Lifetime) > 0 condition. > > Looks also like a copy & paste mistake. Fixed. > * What about changing all those rx_CREATE && CREATE(Lifetime) > 0 > style conditions to a more concise syntax, maybe like > rx_CREATE(lifetime > 0)? Or, maybe I should stop drawing with > a pencil. > > Good idea, espacily as the transmission style already follows this syntax. >Since CREATE and REA sessions are different things (as I learned >recently), it would IMHO make sense to split the NF and NR state >machines into CREATE and REA parts. That way they'll be easier to >understand and look nicer on paper (I tested it), especially when more >conditions will be added later. > >The NR would be split into NR and NR-REA (or NI+) parts. The NR would >consist of IDLE and SESSION states, while the NR-REA would consist of >IDLE, WAITRESP (formerly REA_WAITRESP), and REA. > >The NF would consist of IDLE, WAITRESP, and SESSION states, while >NF-REA consists of IDLE, EDGE_REA, and NONEDGE_REA. > > In a former version of the draft, we has split it into two statemachines. But we think it is better to have all in one statemachine. If you have several hours time to draw it, it's looks very nice and is not so hard to understand ;-) You might be interested to take a look to my figures. You can find them at: http://user.informatik.uni-goettingen.de/~nsteinle/nsis/natfw/statemachine/natfw-statemachine-03.pdf Thanks for your helpful comments, Best Regards, Niklas >Thanks, > Matthias, who hopes he didn't overlook something :-) > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > --------------060605020502080509040705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi Matthias,

sorry for my late response, i before overlook your mail and notice it when preparing an update for the statemachine draft.
Thanks for your deep review and helpful comments, please find my comments inline.

Matthias Friedrich wrote:
Hi,

I've got a few questions about version 02 of the NATFW state machine
draft.

 * Section 7 ("State machines for the NAT/FW NF"), state IDLE:
   What's the tx_CREATE in the last action good for?
For "Proxying for a Data Sender", see section 3.8.7.1 in the NAT/FW NSLP draft.
 * Section 7 ("State machines for the NAT/FW NF"), state NONEDGE_REA:
   Is there a rx_RESPONSE(SUCCESS, REA) condition missing? The response
   could be coming from an upstream NF and should be passed on. The
   state would stay NONEDGE_REA.
Right, it's missing. Will be fixed in the newest version.
 * Section 7 ("State machines for the NAT/FW NF"), state EDGE_REA:
   The first condition looks like a copy and paste mistake. I think
   a tx_RESPONSE(SUCCESS, REA) should be sent and the state should
   stay EDGE_REA. An edge NF shouldn't send REAs any further.
Oops, you're right. Thanks.
   I also wonder where the tx_RESPONSE(ERROR, REA) in the second
   condition could be coming from. The node is on the edge of the
   network after all.
Totally agree! Will be fixed.
 * Section 8 ("State machine for the NAT/FW NR"), state SESSION:
   The tg_TEARDOWN looks unnecessary to me, the session should be
   terminated by a rx_CREATE && CREATE(Lifetime) > 0 condition.
Looks also like a copy & paste mistake. Fixed.
 * What about changing all those rx_CREATE && CREATE(Lifetime) > 0
   style conditions to a more concise syntax, maybe like
   rx_CREATE(lifetime > 0)? Or, maybe I should stop drawing with
   a pencil.
Good idea, espacily as the transmission style already follows this syntax. 
Since CREATE and REA sessions are different things (as I learned
recently), it would IMHO make sense to split the NF and NR state
machines into CREATE and REA parts. That way they'll be easier to
understand and look nicer on paper (I tested it), especially when more
conditions will be added later.

The NR would be split into NR and NR-REA (or NI+) parts. The NR would
consist of IDLE and SESSION states, while the NR-REA would consist of
IDLE, WAITRESP (formerly REA_WAITRESP), and REA.

The NF would consist of IDLE, WAITRESP, and SESSION states, while
NF-REA consists of IDLE, EDGE_REA, and NONEDGE_REA.

In a former version of the draft, we has split it into two statemachines. But we think it is better to have all in one statemachine.
If you have several hours time to draw it, it's looks very nice and is not so hard to understand ;-)
You might be interested to take a look to my figures. You can find them at:
http://user.informatik.uni-goettingen.de/~nsteinle/nsis/natfw/statemachine/natfw-statemachine-03.pdf

Thanks for your helpful comments,
Best Regards,
Niklas

Thanks,
	Matthias, who hopes he didn't overlook something :-)

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

--------------060605020502080509040705-- --===============1417230904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1417230904==-- From nsis-bounces@ietf.org Mon Jun 26 03:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulK2-0005df-JP; Mon, 26 Jun 2006 03:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulK1-0005da-V0 for nsis@ietf.org; Mon, 26 Jun 2006 03:15:49 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FulK0-0003w6-Gg for nsis@ietf.org; Mon, 26 Jun 2006 03:15:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5Q7FjIa006154 for ; Mon, 26 Jun 2006 10:15:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:15:34 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:15:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jun 2006 10:15:33 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda requests Thread-Index: AcaY8FB9ACnTBdCCTWOTjNeVNHlWFg== From: To: X-OriginalArrivalTime: 26 Jun 2006 07:15:34.0377 (UTC) FILETIME=[50EAB590:01C698F0] X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [NSIS] Agenda requests X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, If you are interested in having a slot at the NSIS meeting in the IETF, please send the following information: Draft name Presenter's name Time slot needed. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 03:22:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulQ5-00024u-Jp; Mon, 26 Jun 2006 03:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulQ2-00024d-Gc for nsis@ietf.org; Mon, 26 Jun 2006 03:22:02 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FulQ1-0004JE-76 for nsis@ietf.org; Mon, 26 Jun 2006 03:22:02 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 26 Jun 2006 10:22:00 +0300 id 00087EDF.449F8B18.0000258F Date: Mon, 26 Jun 2006 10:22:00 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [NSIS] NSLP authorization work X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Hannes, Martin and myself have pretty much finalized our proposal to add an authorization object to the NSLP layer. We'd like to hear comments on whether this would be as usefull to have as we see it. The draft includes e.g., the structure and use of the authorization object and message processing rules for the QoS and NAT/FW NSLPs. http://www.ietf.org/internet-drafts/draft-manner-nsis-nslp-auth-01.txt Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 04:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumH0-0003XT-Q8; Mon, 26 Jun 2006 04:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumGy-0003XD-Sr for nsis@ietf.org; Mon, 26 Jun 2006 04:16:44 -0400 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumGt-000830-HS for nsis@ietf.org; Mon, 26 Jun 2006 04:16:44 -0400 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id E3B2B25F6D9; Mon, 26 Jun 2006 09:16:37 +0100 (WEST) Received: from zoing (unknown [193.136.207.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id 95D9B25F6D8; Mon, 26 Jun 2006 09:16:37 +0100 (WEST) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Subject: RE: [NSIS] Agenda requests Date: Mon, 26 Jun 2006 09:16:18 +0100 Message-ID: <002901c698f8$d8ff5000$14cf88c1@zoing> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaY8FB9ACnTBdCCTWOTjNeVNHlWFgACDDIA In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, Can I have a five to ten minute slot to present the HyPath updates and future steps? Thanks, Lu=EDs Cordeiro -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: segunda-feira, 26 de Junho de 2006 8:16 To: nsis@ietf.org Subject: [NSIS] Agenda requests Hi all, If you are interested in having a slot at the NSIS meeting in the IETF, please send the following information: Draft name Presenter's name Time slot needed. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 06:28:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuoKp-0002so-8X; Mon, 26 Jun 2006 06:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuoKn-0002rf-RP for nsis@ietf.org; Mon, 26 Jun 2006 06:28:49 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuoKk-0001ee-DP for nsis@ietf.org; Mon, 26 Jun 2006 06:28:49 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QASgIN026975 for ; Mon, 26 Jun 2006 13:28:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 13:28:39 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 13:28:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jun 2006 13:28:39 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on QoS NSLP Thread-Index: AcaZC0k7Ia5k2CijTXilf6HD11NSPw== From: To: X-OriginalArrivalTime: 26 Jun 2006 10:28:39.0348 (UTC) FILETIME=[4A18FF40:01C6990B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [NSIS] WGLC on QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Jukka has submitted the QoS NSLP draft. It should be released today. Until it is announced, you can find a copy of it here: http://www.cs.helsinki.fi/u/jmanner/papers/draft-ietf-nsis-qos-nslp-11.t xt The WGLC will run until July 7th. After that, Jukka can summarize all issues and we will discuss them at the next IETF meeting in Montreal. Jukka, do you have a diff file or a summary of the changes made? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 06:31:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuoN4-0005ge-9O; Mon, 26 Jun 2006 06:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuoN2-0005aJ-To for nsis@ietf.org; Mon, 26 Jun 2006 06:31:08 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuoN1-0001jY-DU for nsis@ietf.org; Mon, 26 Jun 2006 06:31:08 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5QAV1N5006905; Mon, 26 Jun 2006 13:31:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 13:30:35 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 13:30:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jun 2006 13:30:34 +0300 Message-ID: In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC79D2@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on draft-ietf-nsis-qspec-10.txt Thread-Index: AcaW/kaTNRc1lr6NTHO3fZd0EYaG7gAAYfvgAILnqHA= From: To: , X-OriginalArrivalTime: 26 Jun 2006 10:30:35.0052 (UTC) FILETIME=[8F1006C0:01C6990B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [NSIS] WGLC on draft-ietf-nsis-qspec-10.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Jerry has submitted the QoS NSLP QSPEC Template. You can find the announcement & Jerry's comments below. The WGLC will run until July 7th. After that, Jerry can summarize all issues and we will discuss them at the next IETF meeting in Montreal. thanks, John=20 >-----Original Message----- >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Sent: 23 June, 2006 23:16 >To: nsis@ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 > >Hi All, > >The updated 'QoS-NSLP QSPEC Template' I-D is available at=20 >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt. > >The updates are in response to comments and discussion since IETF-65: > >1. rewrote Section 2 (Introduction) for clarity 2. added=20 >clarifications on mandatory parameters in Section 4.2; added=20 >discussion of forwarding options when a domain supports a=20 >different QOSM than the QNI 3. expanded Section 4.5 on error=20 >code handling, including redefined E-Flag and editorial=20 >changes to the N-Flag and T-Flag discussions 4. made some=20 >editorial clarifications in Section 4.6 on defining new=20 >mandatory parameters 5. Section 4.7 added to identify what a=20 >QOSM specification document must include 6. clarified the=20 >requirements in Section 5 for defining a new QSPEC Version 7.=20 >made editorial changes to Section 6 (Procedures), and added=20 >procedures for handling preemption 8. removed QOSM ID=20 >assignments in Section 9 (IANA Considerations); clarified=20 >procedures for defining new mandatory parameters; added=20 >registry for QOSM error codes > >There are no further outstanding changes/comments pending and=20 >no open issues currently identified. > >Thanks, >Regards, >Jerry=20 > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Friday, June 23, 2006 3:50 PM >To: i-d-announce@ietf.org >Cc: nsis@ietf.org >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-10.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Next Steps in Signaling=20 >Working Group of the IETF. > > Title : QoS NSLP QSPEC Template > Author(s) : J. Ash, et al. > Filename : draft-ietf-nsis-qspec-10.txt > Pages : 53 > Date : 2006-6-23 >=09 >The QoS NSLP protocol is used to signal QoS reservations and=20 >is independent of a specific QoS model (QOSM) such as IntServ=20 >or DiffServ. Rather, all information specific to a QOSM is=20 >encapsulated in a separate object, the QSPEC. This document=20 >defines a template for the QSPEC, which contains both the QoS=20 >description and QSPEC control information. The QSPEC format is=20 >defined, as are a number of QSPEC parameters. The QSPEC=20 >parameters provide a common language to be re-used in several=20 >QOSMs. To a certain extent QSPEC parameters ensure=20 >interoperability of QOSMs. Optional QSPEC parameters aim to=20 >ensure the extensibility of QoS NSLP to other QOSMs in the future. >The node initiating the NSIS signaling adds an Initiator QSPEC=20 >that must not be removed, thereby ensuring the intention of=20 >the NSIS initiator is preserved along the signaling path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 06:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuooV-0003BG-8k; Mon, 26 Jun 2006 06:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuooT-0003B8-W4 for nsis@ietf.org; Mon, 26 Jun 2006 06:59:29 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuooS-00056N-IT for nsis@ietf.org; Mon, 26 Jun 2006 06:59:29 -0400 Received: from sbz-30.cs.helsinki.fi (sbz-30.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 26 Jun 2006 13:59:27 +0300 id 00087ED3.449FBE0F.0000131B Date: Mon, 26 Jun 2006 13:59:26 +0300 (EEST) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] WGLC on QoS NSLP In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, The wdiff tool does not like changes in section headings, so below is a page-by-page diff. It's not as nice as what wdiff produces, but shows the main things. There were a lot of editorial fixes and some text was re-arranged, many clarifications, but not that many technical changes. Some of the main technical things were removal of the peer ack-feature, fixes in the error codes, added error source identifier coding, add a new flag to RESERVE, etc. http://www.cs.helsinki.fi/u/jmanner/draft-ietf-nsis-qos-nslp-11-from-0.diff.html Jukka On Mon, 26 Jun 2006 john.loughney@nokia.com wrote: > Hi all, > > Jukka has submitted the QoS NSLP draft. It should be released today. > Until it is announced, you can find a copy of it here: > http://www.cs.helsinki.fi/u/jmanner/papers/draft-ietf-nsis-qos-nslp-11.t > xt > > The WGLC will run until July 7th. After that, Jukka can summarize all > issues and we will discuss them at the next IETF meeting in Montreal. > > Jukka, do you have a diff file or a summary of the changes made? > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 11:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fut51-0006rH-W6; Mon, 26 Jun 2006 11:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fut50-0006rC-Ge for nsis@ietf.org; Mon, 26 Jun 2006 11:32:50 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fut4y-0001cz-3S for nsis@ietf.org; Mon, 26 Jun 2006 11:32:50 -0400 Received: from [84.163.47.141] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Fut4v3ry4-0004EL; Mon, 26 Jun 2006 17:32:47 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 54A1C5E80E2; Mon, 26 Jun 2006 17:32:20 +0200 (CEST) Date: Mon, 26 Jun 2006 17:32:20 +0200 From: Matthias Friedrich To: Niklas Steinleitner Subject: Re: [NSIS] NATFW state machine draft Message-ID: <20060626153220.GA18002@mafr.de> Mail-Followup-To: Niklas Steinleitner , nsis@ietf.org References: <449EEE1F.6060309@cs.uni-goettingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449EEE1F.6060309@cs.uni-goettingen.de> User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, On Sunday, 2006-06-25, Niklas Steinleitner wrote: > Matthias Friedrich wrote: [...] >> * Section 7 ("State machines for the NAT/FW NF"), state IDLE: >> What's the tx_CREATE in the last action good for? > For "Proxying for a Data Sender", see section 3.8.7.1 in the NAT/FW NSLP > draft. >From your definition of tg_CREATE_PROXY, I assumed that a new session is created which would then execute the tx_CREATE message. Anyway, I'd also split the transition to avoid conditions in the action part: Condition Action State ----------------------------+-----------------------------+---------- [...] | | rx_REA && IS_EDGE |tx_RESPONSE(SUCCESS,REA); | EDGE_REA && (!IS_PUBLICSIDE)) | | | | rx_REA(proxy) && IS_EDGE |tx_RESPONSE(SUCCESS,REA); | EDGE_REA && (!IS_PUBLICSIDE)) |tg_CREATE_PROXY; | ----------------------------+-----------------------------+---------- [...] >> The NR would be split into NR and NR-REA (or NI+) parts. The NR would >> consist of IDLE and SESSION states, while the NR-REA would consist of >> IDLE, WAITRESP (formerly REA_WAITRESP), and REA. >> The NF would consist of IDLE, WAITRESP, and SESSION states, while >> NF-REA consists of IDLE, EDGE_REA, and NONEDGE_REA. > In a former version of the draft, we has split it into two > statemachines. But we think it is better to have all in one statemachine. In version 01, the NAT and FW state machines were separate and I agree that it's good to have them united. In my implementation I separated the REA and non-REA parts and found the code a bit easier to handle. Anyway, the state machine draft is still a big help to me. A few more things: * The proxy_mode/proxy_object variables aren't defined. * ReportAsyncEvent() is undefined. If this is a notification for the application, then I think all ReportAsyncEvent() calls in the NF can be removed because there's no application running on top of the NSLP. * In the NF, state IDLE, the rx_CREATE(Lifetime > 0) condition isn't enough. At the moment, I see three cases: rx_CREATE(Lifetime > 0) && IS_PUBLICSIDE && !RESERVATION_EXISTS => tx_RESPONSE(ERROR, CREATE); go to state IDLE rx_CREATE(Lifetime > 0) && IS_PUBLICSIDE && RESERVATION_EXISTS => tx_CREATE(); go to state CREATE_WAITRESP rx_CREATE(Lifetime > 0) && !IS_PUBLICSIDE => tx_CREATE(); go to state CREATE_WAITRESP My implementation isn't finished yet, so I might find more issues to report later. Cheers, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 12:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutYr-0007QL-4A; Mon, 26 Jun 2006 12:03:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutYp-0007QG-Ti for nsis@ietf.org; Mon, 26 Jun 2006 12:03:39 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutYo-0003tv-IG for nsis@ietf.org; Mon, 26 Jun 2006 12:03:39 -0400 Received: from [84.163.47.141] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FutYn2vgl-0005xG; Mon, 26 Jun 2006 18:03:38 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 25F135E80E2; Mon, 26 Jun 2006 18:03:19 +0200 (CEST) Date: Mon, 26 Jun 2006 18:03:19 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060626160319.GB18002@mafr.de> Mail-Followup-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [NSIS] NATFW and the GIST API X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I'm currently implementing the NATFW draft and have a problem with the GIST API version 09. A NATFW implementation needs to know from which network interface a received message came from. This is to check if a message came from the inside or from outside of the local domain or from the public or private side of a NAT. However, this information isn't available in the RecvMessage primitive (see B.2.). I hacked our local GIST implementation to give me the IP address of the network interface that received the message, which is easily available. How did others solve this problem? Did I overlook something or should the GIST API be extended? While I'm at it: The MessageStatus primitive (B.3.) would be far more useful to me if it also gave me the session ID. It would save me from keeping track of message handles which is overkill in my situation. Thanks for reading, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon Jun 26 16:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxL8-0005W3-VY; Mon, 26 Jun 2006 16:05:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxL5-0005TA-O0; Mon, 26 Jun 2006 16:05:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxL5-0001vi-LR; Mon, 26 Jun 2006 16:05:43 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuxL4-0004TF-97; Mon, 26 Jun 2006 16:05:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QJo1jx020719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fux5t-00059n-Dc; Mon, 26 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-rmd-07.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : RMD-QOSM - The Resource Management in Diffserv QOS Model Author(s) : A. Bader, et al. Filename : draft-ietf-nsis-rmd-07.txt Pages : 82 Date : 2006-6-26 This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-rmd-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-rmd-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-26103225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-rmd-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-rmd-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26103225.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Mon Jun 26 21:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv21B-0004So-RT; Mon, 26 Jun 2006 21:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv21A-0004Sj-Ky for nsis@ietf.org; Mon, 26 Jun 2006 21:05:28 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv219-0006Ye-Bl for nsis@ietf.org; Mon, 26 Jun 2006 21:05:28 -0400 Received: from bear.cs.columbia.edu (IDENT:wfdScAuutN7ZgbS/g8KJM895NTORPrzo@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k5R15GSr003135 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 26 Jun 2006 21:05:22 -0400 (EDT) Received: from [128.59.20.222] (hpeters-laptop.cs.columbia.edu [128.59.20.222]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k5R15FYf001466 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Jun 2006 21:05:16 -0400 Message-ID: <44A0844B.1020909@math.uni-goettingen.de> Date: Mon, 26 Jun 2006 21:05:15 -0400 From: Henning Peters User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthias Friedrich Subject: Re: [NSIS] NATFW and the GIST API References: <20060626160319.GB18002@mafr.de> In-Reply-To: <20060626160319.GB18002@mafr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id k5R15GSr003135 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Matthias, your observation is correct. I remember that we discovered this issue=20 last fall similarly while implementing NAT/Firewall NSLP and raised=20 discussion for an API change. While I forgot the final outcome of the API discussion (I hope GIST=20 folks have not?!), I know that our workaround is based on configuration.=20 We simply maintain a mapping between IP addresses and private/public=20 interface (see example conf attached, look for natfw.isPrivateNet option) Extending the API with the network interface (how do you define this?)=20 might not be expressive enough, adding the receiving IP address is not=20 necessary and creates ambiguity. A boolean variable (private/public)=20 would suffice for protocol operation. It should be also noted that for non-hierarchical NAT operation a=20 heuristical approach based on RFC1918 could be used. I would still favor the API change, though, because it cleanly decouples=20 GIST and NAT/Firewall NSLP depedency and minimizes redundancy in a=20 configuration-based approach. Henning example G=F6ttingen GIST + NAT/Firewall NSLP 0.4.0 configuration snippet: %<------ # The first entry is meant as a default route. It is used when # no subsequent entry matches. IPv4[0].addr =3D 10.0.0.1 IPv4[0].net =3D 0.0.0.0 IPv4[0].mask =3D 0 # Use this address as the external address for NatFW NSLP IPv4[0].natfw.useAsExternalAddress =3D yes # Default network is public (i.e. the global internet) IPv4[0].natfw.isPrivateNet =3D no # This entry defines the outgoing local interface card IPv4[1].addr =3D 192.168.0.1 # These entries define the network segment you want to reach # with the previously defined outgoing interface card IPv4[1].net =3D 192.168.0.0 IPv4[1].mask =3D 24 # The network 192.168.0.0/24 is private IPv4[1].natfw.isPrivateNet =3D yes # The second network (192.168.1.0/24) uses the SAME outgoing # interface again. IPv4[2].addr =3D 192.168.0.1 IPv4[2].net =3D 192.168.1.0 IPv4[2].mask =3D 24 # The network 192.168.1.0/24 is private IPv4[2].natfw.isPrivateNet =3D yes ------>% Matthias Friedrich wrote: > Hi, > > I'm currently implementing the NATFW draft and have a problem with the > GIST API version 09. > > A NATFW implementation needs to know from which network interface a > received message came from. This is to check if a message came from > the inside or from outside of the local domain or from the public or > private side of a NAT. However, this information isn't available in th= e > RecvMessage primitive (see B.2.). > > I hacked our local GIST implementation to give me the IP address of th= e > network interface that received the message, which is easily available. > How did others solve this problem? Did I overlook something or should > the GIST API be extended? > > While I'm at it: The MessageStatus primitive (B.3.) would be far more > useful to me if it also gave me the session ID. It would save me from > keeping track of message handles which is overkill in my situation. > > Thanks for reading, > Matthias > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 27 02:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6sp-0004Lm-RA; Tue, 27 Jun 2006 02:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6so-0004Gj-Jg for nsis@ietf.org; Tue, 27 Jun 2006 02:17:10 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6sm-0006xK-7K for nsis@ietf.org; Tue, 27 Jun 2006 02:17:10 -0400 Received: from [84.163.44.83] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Fv6si44XJ-0001Um; Tue, 27 Jun 2006 08:17:05 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 11E725E8224; Tue, 27 Jun 2006 08:16:48 +0200 (CEST) Date: Tue, 27 Jun 2006 08:16:48 +0200 From: Matthias Friedrich To: Henning Peters Subject: Re: [NSIS] NATFW and the GIST API Message-ID: <20060627061648.GA27013@mafr.de> Mail-Followup-To: Henning Peters , nsis@ietf.org References: <20060626160319.GB18002@mafr.de> <44A0844B.1020909@math.uni-goettingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A0844B.1020909@math.uni-goettingen.de> User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, On Monday, 2006-06-26, Henning Peters wrote: > your observation is correct. I remember that we discovered this issue > last fall similarly while implementing NAT/Firewall NSLP and raised > discussion for an API change. Ah, very well, thank you. > While I forgot the final outcome of the API discussion (I hope GIST > folks have not?!), I know that our workaround is based on configuration. > We simply maintain a mapping between IP addresses and private/public > interface (see example conf attached, look for natfw.isPrivateNet option) > Extending the API with the network interface (how do you define this?) > might not be expressive enough, adding the receiving IP address is not > necessary and creates ambiguity. A boolean variable (private/public) > would suffice for protocol operation. The first thing I had in mind was to extend the API to give me the network device identifiers (eth0 is public, eth1 is private, etc.), but they are highly unportable. The IP address of the network interface that received a message is easily accessible using the socket API. A private/public boolean variable would hand the problem off to GIST and would require configuration on GIST level because you can't always be sure that only RFC1918 addresses are used on the private side. Because of this, I like your configuration based address matching better. At the moment, I'm not sure which approach to use, but I don't have to decide it immediately. Regards, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 27 05:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9ol-0000hP-Ka; Tue, 27 Jun 2006 05:25:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9ok-0000hG-0u for nsis@ietf.org; Tue, 27 Jun 2006 05:25:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv9oi-0000Nk-Gy for nsis@ietf.org; Tue, 27 Jun 2006 05:25:10 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CFC04D3E for ; Tue, 27 Jun 2006 11:25:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 11:25:07 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 11:25:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 11:25:07 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFE48@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RMD draft -07 Thread-Index: AcaZy5Qi47c9CTIdRs2RjL3UuoE8vA== From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: X-OriginalArrivalTime: 27 Jun 2006 09:25:07.0354 (UTC) FILETIME=[94629FA0:01C699CB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [NSIS] RMD draft -07 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear All, Please note that the newest version of the RMD draft was = published. We tried to include all the comments. Main changes: Applicability section is added: - applicability for Diffserv classes - possible signaling cases Updates following QSpec and QoS NSLP changes: - Ack flags, RII - error codes, flags fixed Admission, reservation and defending priority is taken into account In severe congestion section - Impl. details moved to the appendix. In the main section we focus on = the signaling. - Use of DSCPs is better described Appendix added (impl. details, examples): - Operation in interior and egress nodes in case of severe congestion - Operation in ingress and egress in case of admission control - Selecting bi-directional flows for termination in case of severe = congestion - Severe congestion for bi-directional when flows congested = simultaneously on forward and reverse path Best regards, Attila _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 27 09:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDX2-0004Xv-CD; Tue, 27 Jun 2006 09:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDX0-0004Xq-I2 for nsis@ietf.org; Tue, 27 Jun 2006 09:23:06 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDWy-0006u6-3K for nsis@ietf.org; Tue, 27 Jun 2006 09:23:06 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RDN09L015836 for ; Tue, 27 Jun 2006 16:23:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:22:57 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:22:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 16:22:56 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC on draft-ietf-nsis-rmd-07.txt Thread-Index: AcaZ7MxWpKljPQkoS76uYiA7az9pFQ== From: To: X-OriginalArrivalTime: 27 Jun 2006 13:22:56.0463 (UTC) FILETIME=[CD6FDDF0:01C699EC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [NSIS] WGLC on draft-ietf-nsis-rmd-07.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, RMD has been reissued, updating the issues raised in WGLC. Please review the current draft, especially for those of you who submitted issues. Send mail to the mailing list with new issues, statements that your issues have been corrected, or that you have read the draft and believe it ready. WGLC will run until close of business on July 7th. http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-07.txt thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 27 09:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDiN-0004Zq-Fq; Tue, 27 Jun 2006 09:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvDiM-0004Zd-B3; Tue, 27 Jun 2006 09:34:50 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvDiI-0007Zj-R1; Tue, 27 Jun 2006 09:34:50 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RDYjLV022634; Tue, 27 Jun 2006 16:34:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:34:26 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:34:25 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 16:34:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Controlled load & Pre-Congestion Notification (PCN) Thread-Index: AcaWD/nnR4/CPbSiQIGXx/JqJbbVGADJ6x7gACXawLAAB4+aYA== From: To: X-OriginalArrivalTime: 27 Jun 2006 13:34:25.0562 (UTC) FILETIME=[682C07A0:01C699EE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tsvwg@ietf.org Subject: [NSIS] NSIS Controlled load & Pre-Congestion Notification (PCN) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, The following draft on signaling Controlled Load with NSIS has been submitted. http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controll edload-04.txt =20 The Controlled Load signalled is the 'classical' CL; not the "Admission Control over=20 DiffServ using Pre-Congestion Notification" solution. I'm trying to gage interest in the classic Controlled Load QoS model in NSIS,=20 as well as using NSIS to signal PCN. There is the following draft which uses RSVP to signal Admission Control over Diffserv using Pre-congestion Notification:=20 http://www.watersprings.org/pub/id/draft-lefaucheur-rsvp-ecn-00.txt=20 So we'd be looking at potentially a signaling model for this. I'm cc:ing TSVWG, but it would be good to have discussions on the NSIS mailing list. The current situation is that we (in NSIS) are starting to clear our charter,=20 and there has been interest in making the Controlled Load QoS Model a WG draft. I would imagine that also working on the PCN at the same time might be desirable. let me know, thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 27 09:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvE3k-0002ot-Sc; Tue, 27 Jun 2006 09:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvE3j-0002ol-0s; Tue, 27 Jun 2006 09:56:55 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvE3h-00009R-JY; Tue, 27 Jun 2006 09:56:54 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1151416505!11053530!30 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27542 invoked from network); 27 Jun 2006 13:56:52 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 27 Jun 2006 13:56:52 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB45200036BA4; Tue, 27 Jun 2006 09:56:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NSIS Controlled load & Pre-Congestion Notification (PCN) Date: Tue, 27 Jun 2006 08:56:51 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC79FE@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NSIS Controlled load & Pre-Congestion Notification (PCN) Thread-Index: AcaWD/nnR4/CPbSiQIGXx/JqJbbVGADJ6x7gACXawLAAB4+aYAAAmucw From: "Ash, Gerald R \(Jerry\), ALABS" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Ash, Gerald R \(Jerry\), ALABS" , tsvwg@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org John, > The following draft on signaling Controlled Load with NSIS has been > submitted. > http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controll edload-04.txt > =20 > The Controlled Load signalled is the 'classical' CL; not the=20 > "Admission Control over DiffServ using Pre-Congestion Notification" > solution. >=20 > I'm trying to gage interest in the classic Controlled Load=20 > QoS model in NSIS, as well as using NSIS to signal PCN. >=20 > There is the following draft which uses RSVP to signal=20 > Admission Control >=20 > over Diffserv using Pre-congestion Notification:=20 >=20 > http://www.watersprings.org/pub/id/draft-lefaucheur-rsvp-ecn-00.txt=20 The current PCN draft is at http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp-ecn-01.txt. =20 > So we'd be looking at potentially a signaling model for this. >=20 > I'm cc:ing TSVWG, but it would be good to have discussions on the NSIS > mailing list. >=20 > The current situation is that we (in NSIS) are starting to clear our > charter, and there has been interest in making the Controlled Load QoS > Model a WG draft. > I would imagine that also working on the PCN at the same time might be > desirable. >=20 > let me know, I support moving ahead with 'classic CL' QOSM as a WG item, as well as moving forward with PCN. Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue Jun 27 10:12:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEIb-0002q3-Ct; Tue, 27 Jun 2006 10:12:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvEIa-0002pq-2t; Tue, 27 Jun 2006 10:12:16 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvEIX-0000he-MA; Tue, 27 Jun 2006 10:12:16 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 27 Jun 2006 16:12:06 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Jun 2006 16:12:06 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E63E5@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Subject: RE: [NSIS] NSIS Controlled load & Pre-Congestion Notification (P CN) Date: Tue, 27 Jun 2006 16:11:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tsvwg@ietf.org, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, as I'm interested in PCN and also following NSIS, I would appreciate some activity to signal CLS/PCN with NSIS. If there's more interest, I'd also help on a draft. PCN doesn't yet have WG status. Would it be a good idea to wait until IETF accepts PCN as a work item before NSIS starts to work on this? Should we discuss this in Montreal (maybe also with Bob Briscoe and Francois Lefaucheur)? Regards, Rudiger |The current situation is that we (in NSIS) are starting to clear our |charter, and there has been interest in making the Controlled Load QoS |Model a WG draft. |I would imagine that also working on the PCN at the same time might be |desirable. | |let me know, |thanks, |John | |_______________________________________________ |nsis mailing list |nsis@ietf.org |https://www1.ietf.org/mailman/listinfo/nsis | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 28 08:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZLI-00074O-3c; Wed, 28 Jun 2006 08:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZLA-0006h9-BM for nsis@ietf.org; Wed, 28 Jun 2006 08:40:20 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZ5z-0001pn-H9 for nsis@ietf.org; Wed, 28 Jun 2006 08:24:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SCOXtE032652; Wed, 28 Jun 2006 15:24:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:24:34 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:24:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Agenda requests Date: Wed, 28 Jun 2006 15:24:35 +0300 Message-ID: In-Reply-To: <002901c698f8$d8ff5000$14cf88c1@zoing> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Agenda requests Thread-Index: AcaY8FB9ACnTBdCCTWOTjNeVNHlWFgACDDIAAG1S0EA= From: To: , X-OriginalArrivalTime: 28 Jun 2006 12:24:35.0078 (UTC) FILETIME=[D0DCAA60:01C69AAD] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org it would have made my life easier for you to have responded as I listed = below ...=20 >-----Original Message----- >From: ext Lu=EDs Cordeiro [mailto:cordeiro@dei.uc.pt]=20 >Sent: 26 June, 2006 11:16 >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] Agenda requests > >Hi John, > >Can I have a five to ten minute slot to present the HyPath=20 >updates and future steps? > >Thanks, >Lu=EDs Cordeiro > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: segunda-feira, 26 de Junho de 2006 8:16 >To: nsis@ietf.org >Subject: [NSIS] Agenda requests > >Hi all, > >If you are interested in having a slot at the NSIS meeting in=20 >the IETF, please send the following information: > >Draft name >Presenter's name >Time slot needed. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 28 08:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZWw-00017X-Fw; Wed, 28 Jun 2006 08:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZWv-00014A-Pc for nsis@ietf.org; Wed, 28 Jun 2006 08:52:29 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZWu-0005JJ-Ci for nsis@ietf.org; Wed, 28 Jun 2006 08:52:29 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k5SCqHeD020346; Wed, 28 Jun 2006 14:52:25 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] Agenda requests Date: Wed, 28 Jun 2006 14:52:17 +0200 Message-ID: <001701c69ab1$b076ea70$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaY8FB9ACnTBdCCTWOTjNeVNHlWFgACDDIAAG1S0EAAAPNb0A== X-Spam-Score: -5.682 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 28 Jun 2006 14:52:26 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John I would like to have a time slot of 10 minutes for: -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: woensdag 28 juni 2006 14:25 To: cordeiro@dei.uc.pt; nsis@ietf.org Subject: RE: [NSIS] Agenda requests it would have made my life easier for you to have responded as I listed below ...=20 >-----Original Message----- >From: ext Lu=EDs Cordeiro [mailto:cordeiro@dei.uc.pt] >Sent: 26 June, 2006 11:16 >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] Agenda requests > >Hi John, > >Can I have a five to ten minute slot to present the HyPath updates and=20 >future steps? > >Thanks, >Lu=EDs Cordeiro > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: segunda-feira, 26 de Junho de 2006 8:16 >To: nsis@ietf.org >Subject: [NSIS] Agenda requests > >Hi all, > >If you are interested in having a slot at the NSIS meeting in the IETF, = >please send the following information: > >Draft name >Presenter's name >Time slot needed. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 28 09:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZj9-0003b1-SO; Wed, 28 Jun 2006 09:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZj8-0003aw-MS for nsis@ietf.org; Wed, 28 Jun 2006 09:05:06 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZj7-0005uD-99 for nsis@ietf.org; Wed, 28 Jun 2006 09:05:06 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k5SD4wjh021594; Wed, 28 Jun 2006 15:05:02 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] Agenda requests Date: Wed, 28 Jun 2006 15:05:00 +0200 Message-ID: <001901c69ab3$767747f0$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001701c69ab1$b076ea70$4c0d5982@dynamic.ewi.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaY8FB9ACnTBdCCTWOTjNeVNHlWFgACDDIAAG1S0EAAAPNb0AAAYnqw X-Spam-Score: -5.682 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Wed, 28 Jun 2006 15:05:03 +0200 (MEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John=20 Sorry about the below too fast reply :-) I would like to have a time slot of 10 minutes for: Draft: InterDomain-QOSM: The NSIS QOS Model for Inter-domain Signaling to Enable End-to-End QoS Provisioning Over Heterogeneous Network Domains =20 Presenter:=20 Georgios Karagiannis Time slot 10 minutes! Best Regards, Georgios -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: woensdag 28 juni 2006 14:52 To: john.loughney@nokia.com; nsis@ietf.org Subject: RE: [NSIS] Agenda requests Hi John I would like to have a time slot of 10 minutes for: -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: woensdag 28 juni 2006 14:25 To: cordeiro@dei.uc.pt; nsis@ietf.org Subject: RE: [NSIS] Agenda requests it would have made my life easier for you to have responded as I listed below ...=20 >-----Original Message----- >From: ext Lu=EDs Cordeiro [mailto:cordeiro@dei.uc.pt] >Sent: 26 June, 2006 11:16 >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] Agenda requests > >Hi John, > >Can I have a five to ten minute slot to present the HyPath updates and=20 >future steps? > >Thanks, >Lu=EDs Cordeiro > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: segunda-feira, 26 de Junho de 2006 8:16 >To: nsis@ietf.org >Subject: [NSIS] Agenda requests > >Hi all, > >If you are interested in having a slot at the NSIS meeting in the IETF, = >please send the following information: > >Draft name >Presenter's name >Time slot needed. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 28 10:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvb2b-0005r9-Eq; Wed, 28 Jun 2006 10:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvb2a-0005r4-U3 for nsis@ietf.org; Wed, 28 Jun 2006 10:29:16 -0400 Received: from mail.uc.pt ([193.137.200.37] helo=mail-1.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvb2Y-0005Z3-I4 for nsis@ietf.org; Wed, 28 Jun 2006 10:29:16 -0400 Received: from mail-1.ci.uc.pt (mail-1.ci.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 0D5E725F6F0; Wed, 28 Jun 2006 15:29:13 +0100 (WEST) Received: from zoing (13.84.103.87.rev.vodafone.pt [87.103.84.13]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-1.ci.uc.pt (Postfix) with ESMTP id F41D825F6EF; Wed, 28 Jun 2006 15:29:10 +0100 (WEST) From: =?iso-8859-1?Q?Lu=EDs_Cordeiro?= To: , Subject: RE: [NSIS] Agenda requests Date: Wed, 28 Jun 2006 15:29:06 +0100 Message-ID: <005a01c69abf$3a4fb0d0$0d546757@zoing> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 thread-index: AcaY8FB9ACnTBdCCTWOTjNeVNHlWFgACDDIAAG1S0EAABEtVoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi John, Sorry for the short reply. Draft name: draft-cordeiro-nsis-hypath-01 Presenter's name: Lu=EDs Cordeiro Time slot needed: 10 minutes BR, Lu=EDs Cordeiro -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: quarta-feira, 28 de Junho de 2006 13:25 To: cordeiro@dei.uc.pt; nsis@ietf.org Subject: RE: [NSIS] Agenda requests it would have made my life easier for you to have responded as I listed below ...=20 >-----Original Message----- >From: ext Lu=EDs Cordeiro [mailto:cordeiro@dei.uc.pt]=20 >Sent: 26 June, 2006 11:16 >To: Loughney John (Nokia-NRC/Helsinki); nsis@ietf.org >Subject: RE: [NSIS] Agenda requests > >Hi John, > >Can I have a five to ten minute slot to present the HyPath=20 >updates and future steps? > >Thanks, >Lu=EDs Cordeiro > >-----Original Message----- >From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >Sent: segunda-feira, 26 de Junho de 2006 8:16 >To: nsis@ietf.org >Subject: [NSIS] Agenda requests > >Hi all, > >If you are interested in having a slot at the NSIS meeting in=20 >the IETF, please send the following information: > >Draft name >Presenter's name >Time slot needed. > >thanks, >John > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed Jun 28 15:50:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvg32-0002sx-9R; Wed, 28 Jun 2006 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvg30-0002sY-Qp; Wed, 28 Jun 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvg30-0004b3-I5; Wed, 28 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5SJo2UA029649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fvg30-00030J-2O; Wed, 28 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-11.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSLP for Quality-of-Service Signaling Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-qos-nslp-11.txt Pages : 75 Date : 2006-6-28 This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-qos-nslp-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-qos-nslp-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28123847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-nslp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-nslp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28123847.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Wed Jun 28 18:53:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvium-00034J-EC; Wed, 28 Jun 2006 18:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvirI-00063y-J3; Wed, 28 Jun 2006 18:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvirI-0000C2-Gu; Wed, 28 Jun 2006 18:50:08 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvirC-0000Fc-6p; Wed, 28 Jun 2006 18:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5SMo11u006576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirB-0004mI-Ks; Wed, 28 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 18:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-applicability-mobility-signaling-05.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Applicability Statement of NSIS Protocols in Mobile Environments Author(s) : S. Lee, et al. Filename : draft-ietf-nsis-applicability-mobility-signaling-05.txt Pages : 73 Date : 2006-6-28 Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suit, and how the protocols operate in different scenarios, with mobility management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-applicability-mobility-signaling-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28154729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-applicability-mobility-signaling-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28154729.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Jun 29 09:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwBg-0005o8-ND; Thu, 29 Jun 2006 09:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwBf-0005jx-8X for nsis@ietf.org; Thu, 29 Jun 2006 09:04:03 -0400 Received: from natreg.rzone.de ([81.169.145.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwBd-00039n-Rg for nsis@ietf.org; Thu, 29 Jun 2006 09:04:03 -0400 Received: from [192.168.178.200] (p5484BC5B.dip0.t-ipconnect.de [84.132.188.91]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k5TD3sxU006426 for ; Thu, 29 Jun 2006 15:03:55 +0200 (MEST) Message-ID: <44A3CF21.8040906@cs.uni-goettingen.de> Date: Thu, 29 Jun 2006 15:01:21 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] draft-qosmodel-controlledload-04 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, the first open issue in the appendix B is about what to do with mandatory QSPEC parameters which are not needed for CLS. Does a QOSM have to understand (and provide information about) all mandatory parameters, even if they are not used? The QSPEC-draft says in section 5 that all parameters listed in the next sections are mandatory. The QSPEC-draft also says in section 4.1 that "a given QOSM defines which of the mandatory and optional parameters it uses, ..." Are there any specific parameters which makes the open issue B.1.1. clearer? Following the QSPEC-draft there doesn't seem to be a conflict, if nothing is done with the unneeded parameters. Thanks, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 29 09:27:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwYM-0000HQ-Q6; Thu, 29 Jun 2006 09:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwYK-0000HL-NG for nsis@ietf.org; Thu, 29 Jun 2006 09:27:28 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwYJ-0004kl-7D for nsis@ietf.org; Thu, 29 Jun 2006 09:27:28 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C7B2A122; Thu, 29 Jun 2006 15:27:25 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19708-02; Thu, 29 Jun 2006 15:27:23 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3283311C; Thu, 29 Jun 2006 15:27:23 +0200 (MST) Message-ID: <44A3D53B.3090803@uni-tuebingen.de> Date: Thu, 29 Jun 2006 15:27:23 +0200 From: Ali Fessi User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Hannes Tschofenig , Georg Carle , Andreas Klenk , Falko Dressler , Cornelia Kappler Subject: [NSIS] Metering NSLP update X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, we submitted an update for the Metering NSLP drafts: "Framework for Metering NSLP" http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-03.txt and "NSLP for Metering Configuration Signaling" http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-04.txt The main changes since last versions are in the protocol document. - The protocol specification is more detailed (message processing and state machine) - A couple of examples are provided in the "Examples of Operations" section to help the reader to understand how the protocol works - a bit-level spezification is provided. Comments are welcome. Best regards, Ali -- Ali Fessi University of Tuebingen _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 29 10:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxMR-0005pN-W7; Thu, 29 Jun 2006 10:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxMQ-0005pI-Pi for nsis@ietf.org; Thu, 29 Jun 2006 10:19:14 -0400 Received: from natklopstock.rzone.de ([81.169.145.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxMP-0001rc-Bl for nsis@ietf.org; Thu, 29 Jun 2006 10:19:14 -0400 Received: from [192.168.178.200] (p5484BC5B.dip0.t-ipconnect.de [84.132.188.91]) (authenticated bits=0) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k5TEHuw0028574; Thu, 29 Jun 2006 16:17:57 +0200 (MEST) Message-ID: <44A3E07A.9060208@cs.uni-goettingen.de> Date: Thu, 29 Jun 2006 16:15:22 +0200 From: Bernd Schloer User-Agent: Opera/8.51 (Windows NT 5.1; U; en) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: fu@cs.uni-goettingen.de, Hannes.Tschofenig@siemens.com Subject: [NSIS] Update draft "QoS NSLP State Machine" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, a new version of the "QoS NSLP State Machine" draft is available. http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine-04.pdf http://www.ietf.org/internet-drafts/draft-fu-nsis-qos-nslp-statemachine-04.txt The important changes are: * reduced state machines of QNI, QNE and QNR to one for all nodes * new variables introduced to have a finer control on the direction of a message * state diagrams simplified Your comments are welcome. Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu Jun 29 10:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxqF-0004uM-Kj; Thu, 29 Jun 2006 10:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxqE-0004tn-8v; Thu, 29 Jun 2006 10:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxqD-000518-UX; Thu, 29 Jun 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5TEo1UA017764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 14:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvxqD-0008Ka-At; Thu, 29 Jun 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-statemachine-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : GIST State Machine Author(s) : H. Tschofenig, et al. Filename : draft-ietf-nsis-ntlp-statemachine-02.txt,.pdf Pages : 24 Date : 2006-6-29 This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-ntlp-statemachine-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29094401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-ntlp-statemachine-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-statemachine-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29094401.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Thu Jun 29 16:00:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2gC-0001F8-5Y; Thu, 29 Jun 2006 16:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2Wd-0004mw-LP; Thu, 29 Jun 2006 15:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2Wd-0001Zj-JH; Thu, 29 Jun 2006 15:50:07 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw2WZ-0001vh-4v; Thu, 29 Jun 2006 15:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo29F012769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WY-0003Ts-BE; Thu, 29 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-nslp-natfw-12.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Author(s) : M. Stiemerling, et al. Filename : draft-ietf-nsis-nslp-natfw-12.txt Pages : 101 Date : 2006-6-29 This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-nslp-natfw-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29112909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-nslp-natfw-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-nslp-natfw-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29112909.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri Jun 30 01:35:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwBen-0002ua-TM; Fri, 30 Jun 2006 01:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwBem-0002rP-2S for nsis@ietf.org; Fri, 30 Jun 2006 01:35:08 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwBek-0007ov-Ix for nsis@ietf.org; Fri, 30 Jun 2006 01:35:08 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5U5Z4TO023546 for ; Fri, 30 Jun 2006 08:35:05 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:34:11 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:34:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jun 2006 08:34:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS Agenda Thread-Index: AcacBs+uNLbdlf7JSQiB+/mjdvkB/w== From: To: X-OriginalArrivalTime: 30 Jun 2006 05:34:11.0387 (UTC) FILETIME=[D0D318B0:01C69C06] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [NSIS] NSIS Agenda X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Here is a rough agenda for our meeting. I am hoping that we can take = care of the currently chartered work on the Wednesday session and get = into the individual / new topics on Thursday.=20 Please comment if your draft is not on the list. John NSIS WG Meeting IETF 66 WEDNESDAY, July 12, 2006 0900-1130 Morning Session I Room 520ABC TSV nsis Next Steps in Signaling WG THURSDAY, July 13, 2006 1510-1610 Afternoon Session II Room 513CDE TSV nsis Next Steps in Signaling WG 0) WG Update & Next Steps=20 John Loughney 25 minutes Discussion of potential rechartering after completion of existing NSLP = work & QoS model work. 1) GIST Update - 45 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp Robert Hancock 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-00.txt Henning will present it. 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp TBA 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-statemachine TBA 5 minutes 2) NAT-FW NSLP Update - 15 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt Hannes or Martin 15 minutes 3) QoS Work update - 45 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp Jukka Manner 20 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt TBA 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-02.txt TBA 5 minutes http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-07.txt=20 Attila Bader=20 10 min. draft-kappler-nsis-qosmodel-controlledload-04.txt =09 TBA 5 minutes 4) Discussion of working on Partly-Decoupled Signalling - 20 minutes http://www.ietf.org/internet-drafts/draft-hancock-nsis-pds-problem-03.txt= Robert Hancock 10 minutes Open mic discussion 10 minutes 5) Individual Drafts - remaining time http://www.ietf.org/internet-drafts/draft-cordeiro-nsis-hypath-01=20 Lu=EDs Cordeiro=20 10 minutes Communication Patterns for NSIS http://www.ietf.org/internet-drafts/draft-stiemerling-nsis-mrm-patterns-0= 0.txt Martin max 5 minutes Authorization for NSIS Signaling Layer Protocols=20 http://www.ietf.org/internet-drafts/draft-manner-nsis-nslp-auth-01.txt Jukka Manner 15 minutes=20 InterDomain-QOSM: The NSIS QOS Model for Inter-domain Signaling to = Enable End-to-End QoS Provisioning Over Heterogeneous Network Domains http://www.ietf.org/internet-drafts/draft-zhang-nsis-interdomain-qosm-02.= txt Georgios Karagiannis 10 minutes Metering NSLP work http://www.ietf.org/internet-drafts/draft-fessi-nsis-m-nslp-framework-03.= txt http://www.ietf.org/internet-drafts/draft-dressler-nsis-metering-nslp-04.= txt Juergen Quittek 10 minutes. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 01:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwBjv-0002Wn-GH; Fri, 30 Jun 2006 01:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwBjt-0002Ha-LW for nsis@ietf.org; Fri, 30 Jun 2006 01:40:25 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwBjs-0000L3-UX for nsis@ietf.org; Fri, 30 Jun 2006 01:40:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5U5eMQS011158 for ; Fri, 30 Jun 2006 08:40:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:40:23 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:40:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jun 2006 08:40:23 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSIS next steps Thread-Index: AcacB63nPd9yC1TPTd6lLx4oCyhV0A== From: To: X-OriginalArrivalTime: 30 Jun 2006 05:40:23.0466 (UTC) FILETIME=[AE99D8A0:01C69C07] X-Spam-Score: 0.3 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Subject: [NSIS] NSIS next steps X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1670720428==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1670720428== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69C07.AEB274E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69C07.AEB274E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Below is a cut & paste (with slight editing) from http://tools.ietf.org/wg/nsis/ showing the individual drafts that are active for NSIS. I believe that we have had interest in at least the Partly De-coupled Signaling, Controlled Load QoS Model & the Meeting NSLP work. These are (at least) the intial set of drafts that we would be considering to add to the charter after we complete our milestones. Some of these may require us to modify our current charter. I'd like the working group to comment on the drafts, indicating what is your priority for completing. If there are items that you feel are not a priority, please let me know. We will talk more about this in Montreal. thanks, John =20 draft-cordeiro-nsis-hypath-00.txt -00 2006-03-01 14:53 =20 draft-dressler-nsis-metering-nslp-04.txt -04 new 2006-06-28 21:21 =20 draft-fessi-nsis-m-nslp-framework-03.txt -03 new 2006-06-28 21:19 =20 draft-fu-nsis-diagnostics-nslp-01.txt -01 2006-03-16 02:07 =20 draft-fu-nsis-qos-nslp-statemachine-04.txt -04 new 2006-06-28 21:00 =20 draft-hancock-nsis-pds-problem-03.txt -03 2006-03-09 02:07 =20 draft-kappler-nsis-qosmodel-controlledload-04.txt -04 new 2006-06-26 20:25 =20 draft-loughney-nsis-ext-02.txt -02 2006-03-16 02:07 =20 draft-manner-nsis-nslp-auth-01.txt -01 2006-06-22 19:55 =20 draft-pashalidis-nsis-gimps-nattraversal-03.txt -03 new 2006-06-26 18:41 =20 draft-stiemerling-nsis-mrm-patterns-00.txt -00 2006-06-20 20:22 =20 draft-thiruvengadam-nsis-mip6-fw-04.txt -04 new 2006-06-29 17:47 =20 draft-tommasi-nsis-semipro-00.txt -00 2006-02-22 17:15 =20 draft-tschofenig-nsis-gist-security-01.txt -01 new 2006-06-28 20:58 =20 draft-werner-nsis-natfw-nslp-statemachine-03.txt -03 new 2006-06-28 19:41 =20 draft-zhang-nsis-interdomain-qosm-02.txt -02 new 2006-06-26 13:56 =20 ------_=_NextPart_001_01C69C07.AEB274E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Below is a cut & paste (with slight = editing) from=20 http://tools.ietf.org/wg/nsis/ showing=20 the individual drafts that are active for NSIS.

I believe that we have had interest in at = least the=20 Partly De-coupled Signaling, Controlled Load QoS Model & the Meeting = NSLP=20 work.  These are (at least) the intial set of drafts that we would = be=20 considering to add to the charter after we complete our = milestones.  Some=20 of these may require us to modify our current charter.

I'd like the working group to = comment on the=20 drafts, indicating what is your priority for completing.  If there = are=20 items that you feel are not a priority, please let me know.

We will talk more about this in = Montreal.

thanks,

John

 

= draft-cordeiro-nsis-hypath-00.txt -00=20 2006-03-01 14:53 

draft-dressler-nsis-metering-nslp-04.txt = -04 new=20 2006-06-28 21:21 

draft-fessi-nsis-m-nslp-framework-03.txt = -03 new=20 2006-06-28 21:19 

draft-fu-nsis-diagnostics-nslp-01.txt -01 = 2006-03-16 02:07 

draft-fu-nsis-qos-nslp-statemachine-04.txt= -04 new=20 2006-06-28 21:00 

draft-hancock-nsis-pds-problem-03.txt -03 = 2006-03-09 02:07 

draft-kappler-nsis-qosmodel-controlledload-04.txt=20 -04 new 2006-06-26 20:25 

= draft-loughney-nsis-ext-02.txt -02=20 2006-03-16 02:07 

draft-manner-nsis-nslp-auth-01.txt -01=20 2006-06-22 19:55 

draft-pashalidis-nsis-gimps-nattraversal-03.txt -03=20 new 2006-06-26 18:41 

draft-stiemerling-nsis-mrm-patterns-00.txt= -00=20 2006-06-20 20:22 

draft-thiruvengadam-nsis-mip6-fw-04.txt = -04 new=20 2006-06-29 17:47 

= draft-tommasi-nsis-semipro-00.txt -00=20 2006-02-22 17:15 

draft-tschofenig-nsis-gist-security-01.txt= -01 new=20 2006-06-28 20:58 

draft-werner-nsis-natfw-nslp-statemachine-03.txt=20 -03 new 2006-06-28 19:41 

draft-zhang-nsis-interdomain-qosm-02.txt = -02 new=20 2006-06-26 13:56 

------_=_NextPart_001_01C69C07.AEB274E7-- --===============1670720428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1670720428==-- From nsis-bounces@ietf.org Fri Jun 30 07:41:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHNH-0007Iv-JZ; Fri, 30 Jun 2006 07:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHNG-0007Iq-9C for nsis@ietf.org; Fri, 30 Jun 2006 07:41:26 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwHNE-00065C-PX for nsis@ietf.org; Fri, 30 Jun 2006 07:41:26 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5UBfKXJ003048; Fri, 30 Jun 2006 14:41:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:41:05 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:41:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Legacy NAT traversal for NSIS Date: Fri, 30 Jun 2006 14:41:04 +0300 Message-ID: In-Reply-To: <69D2C30BFA177E4DB3E6C93A94C87F1F858364@MCHP7IEA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Legacy NAT traversal for NSIS Thread-Index: AcZtXpAo4ZqImHbcQjOAYQJ4vNANNQAeuKiwCLYH+KAAszxBQAAJBksgAiXZayA= From: To: , X-OriginalArrivalTime: 30 Jun 2006 11:41:04.0975 (UTC) FILETIME=[11F20DF0:01C69C3A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Andreas, I think there is interest, but I think it might be good to get some input from the BEHAVE WG as well. John=20 >-----Original Message----- >From: ext Pashalidis, Andreas [mailto:Andreas.Pashalidis@siemens.com]=20 >Sent: 19 June, 2006 16:22 >To: nsis@ietf.org >Subject: [NSIS] Legacy NAT traversal for NSIS > >Hello NSIS, > >Is anyone interested to make NSIS work through legacy NATs ?? (i.e. >NSIS-unaware NATs) > >Under the following link a preliminary document (in I-D=20 >format) can be found that describes a solution approach. >http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legac >ynats-00. >txt > >In an exremely small nutshell: the idea is to tunnel both=20 >signalling and data traffic over a single UDP NAT binding. > >If enough interest exists we plan to submit the document to=20 >the working group. But: is there any interest at all?? > >Best Regards, >Andreas Pashalidis > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 07:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHUh-0001H0-0a; Fri, 30 Jun 2006 07:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHUf-0001Gv-L2 for nsis@ietf.org; Fri, 30 Jun 2006 07:49:05 -0400 Received: from denhaag.ewi.utwente.nl ([130.89.10.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwHUf-0006Hi-2W for nsis@ietf.org; Fri, 30 Jun 2006 07:49:05 -0400 Received: from utip105 (utip105.ewi.utwente.nl [130.89.13.76]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id k5UBmw58028644; Fri, 30 Jun 2006 13:49:01 +0200 (MEST) From: "Georgios Karagiannis" To: , Subject: RE: [NSIS] NSIS next steps Date: Fri, 30 Jun 2006 13:49:06 +0200 Message-ID: <001701c69c3b$310a4d00$4c0d5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcacB63nPd9yC1TPTd6lLx4oCyhV0AAMtwtg X-Spam-Score: -5.63 () ALL_TRUSTED, AWL, BAYES_00, FVGT_u_HAS_2LETTERFLDR, HTML_MESSAGE, HTML_TITLE_EMPTY X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 30 Jun 2006 13:49:03 +0200 (MEST) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878273977==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============0878273977== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C69C4B.F4931D00" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C69C4B.F4931D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi John Please note that the following QoS model draft shows how the Partly De-coupled Signaling can be applied: draft-zhang-nsis-interdomain-qosm-02.txt It will therefore be good to consider to add also the above draft to the charter after we complete our current milestones Best Regards, Georgios _____ From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 30 juni 2006 7:40 To: nsis@ietf.org Subject: [NSIS] NSIS next steps Hi all, Below is a cut & paste (with slight editing) from http://tools.ietf.org/wg/nsis/ showing the individual drafts that are active for NSIS. I believe that we have had interest in at least the Partly De-coupled Signaling, Controlled Load QoS Model & the Meeting NSLP work. These are (at least) the intial set of drafts that we would be considering to add to the charter after we complete our milestones. Some of these may require us to modify our current charter. I'd like the working group to comment on the drafts, indicating what is your priority for completing. If there are items that you feel are not a priority, please let me know. We will talk more about this in Montreal. thanks, John draft-cordeiro-nsis-hypath-00.txt -00 2006-03-01 14:53 draft-dressler-nsis-metering-nslp-04.txt -04 new 2006-06-28 21:21 draft-fessi-nsis-m-nslp-framework-03.txt -03 new 2006-06-28 21:19 draft-fu-nsis-diagnostics-nslp-01.txt -01 2006-03-16 02:07 draft-fu-nsis-qos-nslp-statemachine-04.txt -04 new 2006-06-28 21:00 draft-hancock-nsis-pds-problem-03.txt -03 2006-03-09 02:07 draft-kappler-nsis-qosmodel-controlledload-04.txt -04 new 2006-06-26 20:25 draft-loughney-nsis-ext-02.txt -02 2006-03-16 02:07 draft-manner-nsis-nslp-auth-01.txt -01 2006-06-22 19:55 draft-pashalidis-nsis-gimps-nattraversal-03.txt -03 new 2006-06-26 18:41 draft-stiemerling-nsis-mrm-patterns-00.txt -00 2006-06-20 20:22 draft-thiruvengadam-nsis-mip6-fw-04.txt -04 new 2006-06-29 17:47 draft-tommasi-nsis-semipro-00.txt -00 2006-02-22 17:15 draft-tschofenig-nsis-gist-security-01.txt -01 new 2006-06-28 20:58 draft-werner-nsis-natfw-nslp-statemachine-03.txt -03 new 2006-06-28 19:41 draft-zhang-nsis-interdomain-qosm-02.txt -02 new 2006-06-26 13:56 ------=_NextPart_000_0018_01C69C4B.F4931D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John
 
Please note that the following QoS model draft shows how = the Partly=20 De-coupled Signaling can be applied:
draft-zhang-nsis-interdomain-qosm-02.txt  
 
It will therefore be good to consider to add also the above = draft=20
to the charter after we complete our current=20 milestones
 
Best Regards,
Georgios
 

From: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Sent: vrijdag 30 juni 2006=20 7:40
To: nsis@ietf.org
Subject: [NSIS] NSIS next=20 steps

Hi all,

Below is a cut & paste (with slight = editing) from=20 http://tools.ietf.org/wg/nsis/ showing=20 the individual drafts that are active for NSIS.

I believe that we have had interest in at = least the=20 Partly De-coupled Signaling, Controlled Load QoS Model & the Meeting = NSLP=20 work.  These are (at least) the intial set of drafts that we would = be=20 considering to add to the charter after we complete our = milestones.  Some=20 of these may require us to modify our current charter.

I'd like the working group to = comment on the=20 drafts, indicating what is your priority for completing.  If there = are=20 items that you feel are not a priority, please let me know.

We will talk more about this in = Montreal.

thanks,

John

 

= draft-cordeiro-nsis-hypath-00.txt -00=20 2006-03-01 14:53 

draft-dressler-nsis-metering-nslp-04.txt = -04 new=20 2006-06-28 21:21 

draft-fessi-nsis-m-nslp-framework-03.txt = -03 new=20 2006-06-28 21:19 

draft-fu-nsis-diagnostics-nslp-01.txt -01 = 2006-03-16 02:07 

draft-fu-nsis-qos-nslp-statemachine-04.txt= -04 new=20 2006-06-28 21:00 

draft-hancock-nsis-pds-problem-03.txt -03 = 2006-03-09 02:07 

draft-kappler-nsis-qosmodel-controlledload-04.txt=20 -04 new 2006-06-26 20:25 

= draft-loughney-nsis-ext-02.txt -02=20 2006-03-16 02:07 

draft-manner-nsis-nslp-auth-01.txt -01=20 2006-06-22 19:55 

draft-pashalidis-nsis-gimps-nattraversal-03.txt -03=20 new 2006-06-26 18:41 

draft-stiemerling-nsis-mrm-patterns-00.txt= -00=20 2006-06-20 20:22 

draft-thiruvengadam-nsis-mip6-fw-04.txt = -04 new=20 2006-06-29 17:47 

= draft-tommasi-nsis-semipro-00.txt -00=20 2006-02-22 17:15 

draft-tschofenig-nsis-gist-security-01.txt= -01 new=20 2006-06-28 20:58 

draft-werner-nsis-natfw-nslp-statemachine-03.txt=20 -03 new 2006-06-28 19:41 

draft-zhang-nsis-interdomain-qosm-02.txt = -02 new=20 2006-06-26 13:56 

------=_NextPart_000_0018_01C69C4B.F4931D00-- --===============0878273977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0878273977==-- From nsis-bounces@ietf.org Fri Jun 30 08:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHor-0008Pj-6X; Fri, 30 Jun 2006 08:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHop-0008Pd-IQ for nsis@ietf.org; Fri, 30 Jun 2006 08:09:55 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwHom-0006pK-RR for nsis@ietf.org; Fri, 30 Jun 2006 08:09:55 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 28D60500003; Fri, 30 Jun 2006 14:09:50 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:09:49 +0200 Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 14:09:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Fri, 30 Jun 2006 14:09:48 +0200 Message-ID: <05F34B6959F19F43BBD78FFCD4C15D055DFE57@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcabfIg181WH0pGTSoKu/GJV9jnDWgAwGGkQ From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?= To: "Bernd Schloer" , X-OriginalArrivalTime: 30 Jun 2006 12:09:49.0103 (UTC) FILETIME=[159B1BF0:01C69C3E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, This is the case in RMD as well. In RMD domain resource = reservation is based on one parameter: Bandwidth. If, for example, the = resource request arriving to the Edge is a token bucket, it should be = translated to a single Bandwidth parameter. This may be a peak value, or = an effective value. Best regards, Attila > -----Original Message----- > From: Bernd Schloer [mailto:bschloer@cs.uni-goettingen.de] > Sent: Thursday, June 29, 2006 3:01 PM > To: nsis@ietf.org > Subject: [NSIS] draft-qosmodel-controlledload-04 >=20 >=20 > Hi, >=20 > the first open issue in the appendix B is about what to do=20 > with mandatory QSPEC=20 > parameters which are not needed for CLS. >=20 > Does a QOSM have to understand (and provide information=20 > about) all mandatory > parameters, even if they are not used? The QSPEC-draft says=20 > in section 5 that > all parameters listed in the next sections are mandatory. The=20 > QSPEC-draft also > says in section 4.1 that "a given QOSM defines which of the=20 > mandatory and > optional parameters it uses, ..." >=20 > Are there any specific parameters which makes the open issue=20 > B.1.1. clearer?=20 > Following the QSPEC-draft there doesn't seem to be a=20 > conflict, if nothing is > done with the unneeded parameters. >=20 > Thanks, > Bernd >=20 >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 08:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIKW-0006fP-NX; Fri, 30 Jun 2006 08:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIKV-0006fK-CL for nsis@ietf.org; Fri, 30 Jun 2006 08:42:39 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwIKS-0001VY-V0 for nsis@ietf.org; Fri, 30 Jun 2006 08:42:39 -0400 Received: (qmail invoked by alias); 30 Jun 2006 12:42:35 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp039) with SMTP; 30 Jun 2006 14:42:35 +0200 X-Authenticated: #29516787 Message-ID: <44A51C39.1030804@gmx.net> Date: Fri, 30 Jun 2006 14:42:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernd Schloer Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <44A3CF21.8040906@cs.uni-goettingen.de> In-Reply-To: <44A3CF21.8040906@cs.uni-goettingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Bernd, Bernd Schloer wrote: > Hi, > > the first open issue in the appendix B is about what to do with > mandatory QSPEC parameters which are not needed for CLS. > > Does a QOSM have to understand (and provide information about) all > mandatory > parameters, even if they are not used? I think the question is wrong. What about the following question: " Does a node that implements a particular QOSM has to understand all mandatory parameters listed in the QSPEC template draft (even if the QOSM does not make use of them)? " The answer would be "YES" since the QSPEC template draft says that mandatory parameters have to be understood by every NSIS QoS node. There is only the question what "understands" means. Another possible question would be: " Does a node that implements a particular QOSM has to define mappings from all mandatory parameters listed in the QSPEC template draft to the QOSM draft (even if the QOSM does not make use of them)? " The answer is "I don't know". Ciao Hannes The QSPEC-draft says in section 5 > that > all parameters listed in the next sections are mandatory. The > QSPEC-draft also > says in section 4.1 that "a given QOSM defines which of the mandatory and > optional parameters it uses, ..." > > Are there any specific parameters which makes the open issue B.1.1. > clearer? Following the QSPEC-draft there doesn't seem to be a conflict, > if nothing is > done with the unneeded parameters. > > Thanks, > Bernd > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 08:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIMR-0004OM-51; Fri, 30 Jun 2006 08:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIMP-0004OH-Tm for nsis@ietf.org; Fri, 30 Jun 2006 08:44:37 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwIMO-00020F-FN for nsis@ietf.org; Fri, 30 Jun 2006 08:44:37 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5UCiYKt006020 for ; Fri, 30 Jun 2006 15:44:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 15:44:07 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 15:44:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jun 2006 15:44:07 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised WGLC on RMD & new WGLC on Y1541 Thread-Index: AcacQt/F6eJBvNXpSt+MxfHV+3J+Jw== From: To: X-OriginalArrivalTime: 30 Jun 2006 12:44:07.0231 (UTC) FILETIME=[E05884F0:01C69C42] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [NSIS] Revised WGLC on RMD & new WGLC on Y1541 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, RMD is currently in WGLC, but as it is dependent on the QoS NSLP & QoS Template document, I will need to push back the WGLC on it. The WGLC will runn until July 20th, just in case there are any issues on either the QoS NSLP or QoS Template document. Feel free to review it now, though. http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-07.txt This draft is also ready for WGLC: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt and I will also start WGLC, going until July 20th. Again, send comments early. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 08:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIN7-0005ZV-0c; Fri, 30 Jun 2006 08:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwIN5-0005Su-4U for nsis@ietf.org; Fri, 30 Jun 2006 08:45:19 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwIN3-00021r-Mw for nsis@ietf.org; Fri, 30 Jun 2006 08:45:19 -0400 Received: (qmail invoked by alias); 30 Jun 2006 12:45:17 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp033) with SMTP; 30 Jun 2006 14:45:17 +0200 X-Authenticated: #29516787 Message-ID: <44A51CDB.7040503@gmx.net> Date: Fri, 30 Jun 2006 14:45:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Attila_B=E1der_=28IJ/ETH=29=22?= Subject: Re: [NSIS] draft-qosmodel-controlledload-04 References: <05F34B6959F19F43BBD78FFCD4C15D055DFE57@esealmw116.eemea.ericsson.se> In-Reply-To: <05F34B6959F19F43BBD78FFCD4C15D055DFE57@esealmw116.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.2 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Attila, Attila Báder (IJ/ETH) wrote: > Hi Bernd, This is the case in RMD as well. In RMD domain resource > reservation is based on one parameter: Bandwidth. If, for example, > the resource request arriving to the Edge is a token bucket, it > should be translated to a single Bandwidth parameter. This may be a > peak value, or an effective value. I guess Bernd's question was focusing on a different aspect. What happens if you receive a request that contains the parameter 'Y.1541 QoS Class with the value set for Class 0? Ciao Hannes > > Best regards, Attila > > >> -----Original Message----- From: Bernd Schloer >> [mailto:bschloer@cs.uni-goettingen.de] Sent: Thursday, June 29, >> 2006 3:01 PM To: nsis@ietf.org Subject: [NSIS] >> draft-qosmodel-controlledload-04 >> >> >> Hi, >> >> the first open issue in the appendix B is about what to do with >> mandatory QSPEC parameters which are not needed for CLS. >> >> Does a QOSM have to understand (and provide information about) all >> mandatory parameters, even if they are not used? The QSPEC-draft >> says in section 5 that all parameters listed in the next sections >> are mandatory. The QSPEC-draft also says in section 4.1 that "a >> given QOSM defines which of the mandatory and optional parameters >> it uses, ..." >> >> Are there any specific parameters which makes the open issue B.1.1. >> clearer? Following the QSPEC-draft there doesn't seem to be a >> conflict, if nothing is done with the unneeded parameters. >> >> Thanks, Bernd >> >> >> >> _______________________________________________ nsis mailing list >> nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ nsis mailing list > nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 12:08:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLXj-0007DY-1X; Fri, 30 Jun 2006 12:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLXh-0007DT-Vv for nsis@ietf.org; Fri, 30 Jun 2006 12:08:29 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwLXg-0002Qv-Fc for nsis@ietf.org; Fri, 30 Jun 2006 12:08:29 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1151683119!9902465!51 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6908 invoked from network); 30 Jun 2006 16:01:06 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-120.messagelabs.com with SMTP; 30 Jun 2006 16:01:06 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB452000BB7EE; Fri, 30 Jun 2006 12:01:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] draft-qosmodel-controlledload-04 Date: Fri, 30 Jun 2006 11:01:05 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A53@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <44A51C39.1030804@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] draft-qosmodel-controlledload-04 Thread-Index: AcacQrT9c1dUslpqQ6C9i3SMmpVBFwAFqX8g From: "Ash, Gerald R \(Jerry\), ALABS" To: "Hannes Tschofenig" , "Bernd Schloer" X-Spam-Score: 1.1 (+) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: "Ash, Gerald R \(Jerry\), ALABS" , nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, See below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Friday, June 30, 2006 8:43 AM > To: Bernd Schloer > Cc: nsis@ietf.org > Subject: Re: [NSIS] draft-qosmodel-controlledload-04 >=20 > Hi Bernd, >=20 > Bernd Schloer wrote: > > Hi, > >=20 > > the first open issue in the appendix B is about what to do with=20 > > mandatory QSPEC parameters which are not needed for CLS. > >=20 > > Does a QOSM have to understand (and provide information about) all=20 > > mandatory parameters, even if they are not used? >=20 > I think the question is wrong. What about the following question: > " > Does a node that implements a particular QOSM has to understand all > mandatory parameters listed in the QSPEC template draft (even if the=20 > QOSM does not make use of them)? > " > The answer would be "YES" since the QSPEC template draft says that=20 > mandatory parameters have to be understood by every NSIS QoS node. >=20 > There is only the question what "understands" means. IMO you need to more carefully read the QSPEC I-D document. All mandatory QSPEC parameters that are populated in the QSPEC must be interpreted by every QNE, which is explained in the QSPEC I-D: It says in Section 4.4.1 (Mandatory and Optional QSPEC Parameters) of the QSPEC I-D http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt: " Mandatory QSPEC parameters are treated as follows: o A QNI SHOULD populate mandatory QSPEC parameters if applicable to the underlying QOSM. o QNEs MUST interpret mandatory QSPEC parameters, if signaled." Furthermore, it says in Section 4.2 (QSPEC Processing): " a QNE MUST at least interpret all the mandatory parameters in a QSPEC even if it does not support the corresponding QOSM. Mandatory parameters provide a minimal subset of parameters. A QNE MUST either a) strictly interpret a mandatory parameter, or b) remap the parameter and raise the flag defined in Section 5.1, where the remapping MUST be specified in the QOSM specification. Here the terminology 'strictly interpret' means that the parameter is implemented according to the commonly accepted definition and/or as specified by references given for each QSPEC parameter. This means that in case a), a parameter must be strictly interpreted as a token bucket. However, in case b), a parameter may be remapped, perhaps to a parameter. In the latter case, the remapping of the to must be specified in the QOSM specification document. For example, QOSM X exclusively uses the parameter . It must define a mapping of the mandatory parameter . The mapping consists of interpreting the Token Bucket Rate as the parameter and disregarding the other Token Bucket parameters. Clearly, some information contained in the parameter is lost by this mapping, and the resulting QoS may not be quite what was intended by the QNI. Therefore, QOSM X also specifies that the flag be raised. Thus, a QNE using QOSM X is able to make an informed decision whether to admit a reservation described in terms of , and at the same time (by means of ) signals to the QNI/QNR that the exact intention of the QNI may not be met." I think this text is pretty clear as to what is required regarding interpreting mandatory parameters. If not, please suggest clarifications. > Another possible question would be: > " > Does a node that implements a particular QOSM has to define mappings=20 > from all mandatory parameters listed in the QSPEC template=20 > draft to the QOSM draft (even if the QOSM does not make use of them)? > " > > The answer is "I don't know". A QNE must interpret all mandatory parameters, if populated, as explained in the above text I quoted. If a QOSM re-maps a mandatory QSPEC parameter, that re-mapping must be defined in the QOSM specification. As stated in Section 4.7 (QOSM Specification Requirements): " A QOSM specification MUST define QSPEC parameter behavior for these cases: a) new optional QSPEC parameters the QOSM specification defines, and b) remapping of existing mandatory or optional QSPEC parameters, as described in Section 4.2. Unless otherwise specified in the QOSM specification document, the behaviors to strictly interpret the mandatory and optional QSPEC parameters are defined in this document through the references to RFCs that precisely define the QSPEC parameter behaviors. =20 A QOSM specification MUST define how the mandatory parameters are to be mapped onto the QSPEC parameters used by the QOSM, however the mapping MAY result in slight modification to the intended specification when an exact mapping is not possible. This definition MUST allow a QNE implementing this QOSM to make a decision as to whether a reservation described in terms of mandatory parameters can be admitted. If for a particular mandatory parameter no mapping can be found that guarantees the desired QoS, the QNE is advised to raise the flag. In other words, for all mandatory parameters a mapping must be defined, but it is acknowledged that this mapping may result in slightly bending the original intention of the QNI." I think this text is pretty clear as to what is required. If not, please suggest clarifications. Thanks, Jerry =20 > Ciao > Hannes >=20 > The QSPEC-draft says in section 5 > > that > > all parameters listed in the next sections are mandatory. The=20 > > QSPEC-draft also > > says in section 4.1 that "a given QOSM defines which of the=20 > mandatory and > > optional parameters it uses, ..." > >=20 > > Are there any specific parameters which makes the open issue B.1.1.=20 > > clearer? Following the QSPEC-draft there doesn't seem to be=20 > a conflict,=20 > > if nothing is > > done with the unneeded parameters. > >=20 > > Thanks, > > Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri Jun 30 12:32:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLue-0001Sm-TB; Fri, 30 Jun 2006 12:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLud-0001Sh-KD for nsis@ietf.org; Fri, 30 Jun 2006 12:32:11 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLub-0003O7-Aw for nsis@ietf.org; Fri, 30 Jun 2006 12:32:11 -0400 Received: from sundial.cs.cornell.edu ([128.84.96.115]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 12:32:08 -0400 Received: from himalaya.cs.cornell.edu (himalaya.cs.cornell.edu [128.84.223.110]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k5UGW8v02835; Fri, 30 Jun 2006 12:32:08 -0400 (EDT) Subject: Re: [NSIS] Legacy NAT traversal for NSIS From: Saikat Guha To: "Pashalidis, Andreas" In-Reply-To: <69D2C30BFA177E4DB3E6C93A94C87F1F858364@MCHP7IEA.ww002.siemens.net> References: <69D2C30BFA177E4DB3E6C93A94C87F1F858364@MCHP7IEA.ww002.siemens.net> Date: Fri, 30 Jun 2006 17:32:07 +0100 Message-Id: <1151685127.26969.230.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 30 Jun 2006 16:32:08.0843 (UTC) FILETIME=[BB38D5B0:01C69C62] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1633214363==" Errors-To: nsis-bounces@ietf.org --===============1633214363== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6Ow8mEYJdBxrXoXWx6hH" --=-6Ow8mEYJdBxrXoXWx6hH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Andreas, On Mon, 2006-06-19 at 15:22 +0200, Pashalidis, Andreas wrote: > Is anyone interested to make NSIS work through legacy NATs ?? (i.e. > NSIS-unaware NATs) >=20 > Under the following link a preliminary document (in I-D format) can be > found that describes a solution approach. > http://www.tschofenig.priv.at/TEMP/draft-pashalidis-nsis-gist-legacynats-00. > txt >=20 > In an exremely small nutshell: the idea is to tunnel both signalling and > data traffic over a single UDP NAT binding. I haven't gone through the document throughly, but the underlying transport you propose reminds me of TEREDO (which is over IPv6 over UDP over IPv4, where the UDP over IPv4 is punched through legacy NATs with the help of STUN/TURN/ICE etc.) One could potentially run GIST over TEREDO and keep the signaling and data channel separate in IPv6 land even though they use the same NAT binding in IPv4 land. Alternatively, TURN (public-data-relay protocol for traversing the worst of NATs) now has some lightweight framing capability; the framing in TURN could potentially be extended to carry any in-band signals including GIST.=20 --=20 Saikat --=-6Ow8mEYJdBxrXoXWx6hH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEpVIHnFltqi691/oRAgstAJ9JLYzhyE1rTEPJ7smFHlZBdyEC6ACfcrf6 wNmOuzIz0tvaolZKos1S1hg= =mXk9 -----END PGP SIGNATURE----- --=-6Ow8mEYJdBxrXoXWx6hH-- --===============1633214363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1633214363==--