From nsis-bounces@ietf.org Tue May 01 18:12:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj0aY-00072d-2s; Tue, 01 May 2007 18:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj0aW-00072Y-2x for nsis@ietf.org; Tue, 01 May 2007 18:12:48 -0400 Received: from rsys001x.roke.co.uk ([193.118.201.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj0aT-0005sP-4p for nsis@ietf.org; Tue, 01 May 2007 18:12:48 -0400 Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys001x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l41MCfbl026929 for ; Tue, 1 May 2007 23:12:41 +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 Date: Tue, 1 May 2007 23:12:41 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D6802FE4F7B@rsys005a.comm.ad.roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GIST (NTLP) WGLC Comments Thread-Index: AceMPdWznIpgw61xQBSuK0FX6scaGA== From: "Ford, Alan" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: alan.ford@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Subject: [NSIS] GIST (NTLP) WGLC Comments 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, Below, please find my initial WGLC comments for the GIST draft. I have studied in detail sections 1-6, and loosely read the rest. I would like to finish the rest, as well as provide some suggested text for some of my comments. However, my progress was delayed by some interop preparations. I shall provide further comments later. It's possible that some of these comments are inconsistant due to reading this in multiple sessions, however I hope they are broadly coherant. The vast majority of these comments are requests for clarification. Anything else is (hopefully) tagged appropriately. Section 1: * [My understanding? - Not really a text change] Why does it exclude end-to-end higher layer signalling? If all nodes were both GIST and application aware, would it work...? What extensions would be needed? * (Penultimate paragraph) - "Parts of the GIST design depend on the use of packets with IP options"- not "depend", something less strong. * (and elsewhere) - Normative reference [14] to long expired draft! Section 2: * I don't feel that "Session" is defined well. I think the distinction between "flow" and "session" needs to be better explained. * "Session Identifier": "opaque" is not clear - opaque to what? (GIST, I know, but it should say this) * In "sender", "aggregate" is mentioned. Adding "(subnet)" would make the implementation clearer. * A definition of "routing state", e.g. "knowledge of adjacent peers for sessions" would be useful. Section 3: * 3.2, Connection Mode: "fast state setup" ??? What state is being setup fast here? Or is the point the second bit - reliability? * 3.2, UDP as "NAT-friendly" is not really explained. Is the intention something along the lines of, "a well-known protocol that can be handled by aware NATs"? * 3.3, No mention is made of "loose end" being in the spec. * 3.4, first paragraph, "In addition...": a) "these messages" - not all; b) this whole sentance is effectively repeated later on in the next paragraph, could just remove it. * 3.4, Data could be "sent in the same was as the Query", this implies Q-Mode, is this correct? * 3.6, No mention is made of RAO. While this is fine, it leaves the reader with some questions later on. Its existance should be introduced here? * 3.9, a random SID isn't down to GIST it's down to the NSLP surely... * 3.9, GIST should provide... "the authenticated identities used to the signalling application". I don't see how this is done in the API, is this correct? * 3.10 2: Last sentance, "node-level policy interactions...". What is this? Is this something else? Is this not just the transfer attributes, as already mentioned? * 3.10 4: Commentary on RAO implies requirement, needs to be updated. Section 4: * 4.1.1, "how the message should be routed" add "(the flow information)" or similar * 4.1.1, discarding unreliably delivered messages and telling the sender. Is this any more than letting the TCP stack realise it hasn't got an ACK? * 4.1.2, "If there is a chance that the message was not delivered..." we should tell the NSLP. It does not explain how, and also, how could this actually happen? A reliable transport mechanism, by definition, should not allow this, surely? * 4.1.2, about Security, a small comment on Integrity/Confidentiality, as mentioned in Appendix A, would be good. * 4.1.2, I'm really confused about "Local Processing" attributes. It sounds like they are local only, but still I find the purpose unclear.=20 * 4.1.2, a general comment on Transfer Attributes (also relevant in other sections). Does "false" mean, "I do not NEED this feature", or does it mean "I do not WANT this feature"? It is simpler to implement the former, e.g. provide security even if it's not asked for. But is that the right way to do it? This should be addressed. Especially because this could lead to an NSLP not being able to ask for a non-secure MA. Sure, why would they want this? But forbidding this makes me feel uneasy. * 4.2, last paragraph. Add "e.g. TCP port numbers" or similar * 4.3, "router alert" is mentioned explitictly in the diagram * 4.3, [Error?] are "Receive" and "Transmit" the right way around? Because if they are, I'm confused. * 4.3.1 should also mention the later Q-Mode stuff about being able to negotiate with peers if you know you don't use RAO, or at least reference the section * 4.3.1, last paragraph (GIST Hop Count): * Decrement before being passed to NSLP? Say this explicitly. * You should say you do not decrement if you are just forwarding it on (I presume you don't, since you're not supposed to look beyond the NSLPID in that situation). * 4.3.2, what if it's the last hop, so GIST "MUST" peer, but the NSLP says not? GIST can't "MUST propogate". * 4.3.2, how do I "flag to the receiving NSLP that the routing state was not validated"? * 4.3.2, it took me a little while to realise the difference between 2 and 3 here (MA vs non-MA), maybe could be clearer? * 4.3.3, "forwarded within the GIST" - I presume this means just unknown NSLPIDs. If this means anything more, please clarify! * 4.3.3, "signalling application has requested " insert: 'security attributes that require' "channel-secured delivery", because it's not explicitly requested as such, right? * 4.3.3, [Typo] "(Section 5.3.2)" is in brackets * 4.3.4 #1, useful to reference 3.6 * 4.3.4 #5, why is a special mention made to not intepreting MRI/SID from original message? This is the default for error behaviour surely? * 4.3.4, the text after the numbered list, beginning "In cases (2) and (3)...", I feel should be included into the list itself. It is confusing being separate. In addition, what should happen with the GIST Hop Count here? * 4.3.4, #1, "The message is so large...". This sounds like a MA should be set up on an error?! Is this right? Doesn't really match into state machines etc... Could be excused as a special case, but this should be made clearer here if true. * 4.4.1, "...with additional payloads." Payloads makes me think of data. Is "fields" more appropriate? * 4.4.1 says The peer address should be derived from the NLI "if this was decoded successfully". If it wasn't, surely this would be a bigger problem and the message wouldbe errored? * 4.4.2, this whole text is quite tricky to follow. I realise it's trying to be generic, but some references to TLS X509 might be useful, and especially the concept of certificates signing keys. Will try to look again. * 4.4.5. [Issue] I would like to see a way of rejecting unreasonably long or short MA-Hold-Times and Routing State validity times. Else we are left with a potential DoS route. Some kind of error? * 4.4.6, last bit, note on responding node deletes all state if it gets a Confirm or Data with no Routing State. Is it possible for a race condition to occur when one turns up with incorrect routing state and kills the valid state that exists? This probably could not happen, I've probably misunderstood, just checking... Section 5: * 5.1, first paragraph, should reference Appendix A. * 5.1, re recent discussions on list. Is it worth rewording so that data "MUST" be carried last, and all other fields "MUST" be carried in order. Thus allowing intermediate extensions if required. * 5.1, there's a MUST NOT, should the error be explcitly mentioned here or is it implied? * 5.2.2, NLI stuff - some clarification needed on upstream, previously mentioned. * 5.3.1 (and Appendix A): [Issue] "Missing Magic Number" error is infeasible, as per earlier discussions; please remove. * 5.3.2, IP options "(unless negotiated otherwise)" * 5.3.2.2. [Issue] NAT in IPv6? That does not exist, at least in v4-style. If the comment about "legacy NAT detection" is being made in another context, that should be clearer, else it should be removed. * 5.3.2.2, [Issue] why are we forbidding any extra extension headers? Surely this is a bit restrictive? * 5.3.2.3, [Typo] third paragraph, typo "networ". Also some repetition. * 5.3.2.4, [Issue] says IP options are passed to NSLP, however no provision in Appendix B is made for this. I thought IP options were assitance only, and only relevant to GIST (indeed conflicts with earlier). * 5.6: Error messages. It implies it must be sent over D-Mode, this is not the case though? Plus, why not include the NSLPID if available? Would be feasible and maybe helpful. * 5.7.1, "The latter approach can be used to..." insert "can be, for example, used to..." * 5.7.1, [Issue]. Relating to ealier, if TCP/TLS is a valid MA to use for "Reliable=3Dtrue; Security=3Dfalse", then the principle of "MUST = NOT have weaker security properties..." means that only TLS could ever be reused if it existed, and TCP could never be reused. This can't be the intention? * 5.7.3, it should be clearer which transfer attributes this profile provides solutions for. * 5.7.3.1, APD should be defined again. * 5.7.3.1, discussion of wildcarding doesn't seem to be quite right, "*.example.com matches... *.example.com" ? * 5.8.1.2, S=3D1 is the encapsulation for first hop, and this should = be made clearer earlier in this text, both in the bullet point list, and further on in the text, it's only right at the end that this is mentioned, should be earlier. * 5.8.1.2, [Issue] later it mentions "IP version mismatch" referring to the interface. The definition in Appendix A has evolved to be that the MRI's IP version MUST be the same as the flow, this does not appear to be the case in this text. * 5.8.1.3, Paragraph "It is possible...", what happens if the upstream query is the first query, does the routing state get overridden by the downstream? I'm guessing yes but this should be clearer. * 5.8.1.3, "The DiffServ... flow label MAY" - surely this should be "SHOULD" as per earlier for downstream. Also, RAO should be clarified more here. Section 6: * There is a general question of error message processing, and whether any mentions of this should be made in this section. * Why is tg_NSLPData and tg_RawData separate, is it just the different state machines, [QR] vs MA? * 6.1, [Typo] "Rle" vs "Rule" * 6.2, mentions of Data in Queries. This relates to the wider issue being discussed on the list at the moment. * 6.2, Refresh_QNode - should reference the section with the 1/2 - 3/4 principle * 6.2, No_Response - default time suggestion/reference? * 6.2, if Rule 3 is also the Initialisation rule, then it should be "(re)start No_Response timer", and should be more clearly marked as such ("Rule 3/Initialisation:" or similar) * 6.3, No_Confirm - similar to above, what's a default time suggestion/reference? * 6.3, and what is the Number of Responses threshold? Mention it's local policy, and a suggested value... * 6.4 - In general, the difference between GIST "Messages" and "Hellos" is a bit fuzzy at times. The second paragraph should be split in two, and a mention made of the tg_MAIdle timer. Plus, clarify that this activity could be based on the MA Hold Time, else there is no mention of this made here. * 6.4, NoHello/SendHello are based BOTH on the Query/Response/Confirm sequence, because the Confirm's MAHT overrides the Query's. Indeed, since Confirm is always required for MAs, it should just be Response/Query. * 6.4, Rule 2. Message should be passed to QSM or RSM, not NSM. Or, fix NSM to pass it on correctly. * 6.4, Rule 2. Should this also have "(re)start SendHello"? Since this also works for moving Idle to Connected. Unintended consequences have not been explored yet, however, and maybe it's handled by tg_RawData/rx_MA-Hello? =20 Secton 7: * 7.4. Dual Stack: "SHOULD" use the same IP version for other queries. This is now a MUST, based on the Error definition in Appendix A? * 7.4, Tunnelling. It is not guaranteed you can know an address is Anycast, so you can't "MUST NOT" it. Also, why the reference to 6to4? Surely GIST shouldn't care where the routing is coming from, unless it is rerouted? Appendix A: * A.3.1.1: "Invalid Flag-Field Combination" error. How can this be detected? I don't see it possible to know when this situation occurs. Or rather, the only case I can think of is when the packet is NOT long enough to contain the ports when the port flags are set. If this is the only case it can occur in, the spec should say this. * A.3.4, there should be a supporting diagram for a Stack-Proposal Profile. * A.4.1, "Q=3D1", is this check valid, based on the "be liberal in = what you accept" principle? * A.4.1, is there a maximum length for the Comment? * A.4.4.1, Error 5 cannot work, as mentioned earlier. * A.4.4.11: In my experience of Linux implementation, the IP TTL is not decremented until being forwarded. Should we intercept it, it remains at 255. I don't know if this is standard or not, however. Regards, Alan _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 01 18:33:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj0uN-0007Ze-RB; Tue, 01 May 2007 18:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj0uM-0007ZZ-8I for nsis@ietf.org; Tue, 01 May 2007 18:33:18 -0400 Received: from amailer.gwdg.de ([134.76.10.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj0uL-0008Bq-NY for nsis@ietf.org; Tue, 01 May 2007 18:33:18 -0400 Received: from p5b03b9e2.dip0.t-ipconnect.de ([91.3.185.226] helo=[192.168.0.188]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1Hj0uH-0004Mg-3k for nsis@ietf.org; Wed, 02 May 2007 00:33:13 +0200 Message-ID: <4637C026.5090204@cs.uni-goettingen.de> Date: Wed, 02 May 2007 00:33:10 +0200 From: Xiaoming Fu Organization: University of Goettingen, Germany User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nsis Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 read thru the GIST_v13 doc, and agree that the spec is well written (indeed!). Besides protocol operations it contains solid rationales to explain the design options including their pros and cons. Here are some comments/suggestions, primarily text/editorial ones: In page 4 "This specification concentrates mainly on path-coupled signalling _controlling resources on network elements_" --> In the sense of of signaling described earlier in this doc ("monitoring of state which is managed by other mechanisms"), it is not "controlling" but "monitoring". In Page 7, GIST Node: Any node along the data path supporting GIST, regardless of what signalling applications it supports. --> I think GIST Node should be independent on whether it is an on-path node or not, thus, "along the data path" could be removed. In page 8, ... "unless otherwise _qualified_" --> "unless otherwise _particularly specified_"? In page 11, "Extensions to the security or transport capabilities of D-mode can be provided equivalently by selecting a different protocol stack under the GIST messaging layer, which would then become another option within the overall C-mode framework. " --> I am confused by "equivalently" here, Do you mean C-mode in this case would be preferred. Also, "overall _C-mode framework_" has not been introduced yet. (BTW- This sentence contains too much different info to me as a non-native English speaker to follow). "Note that downgrade attacks on such approach would need to be prevented by policy at the destination node, similar to the situation discussed in Section 8.6." --> I may read it wrong... _downgrade_ attacks seem to be already mitigrating some attacks (good thing), why need "prevented". "Indeed, it would be impossible for intermediate routers to carry out any processing on the messages without terminating the transport and security protocols used." --> I suppose this is talking about TLS/cryptographically protected case, as normal TCP channels maybe still processed by e.g., certain routers acting as PEPs. In page 12: " Predictive Routing: Here, the intent is to signal along a path that the data flow may follow in the future. Possible cases are pre- installation of state on the backup path that would be used in the event of a link failure, and predictive installation of state on the path that will be used after a mobile node handover." --> This scenario seems not to be discussed in elsewhere in this doc In page 14: "However, if there are no security or transport requirements and no need for persistent reverse routing state, it can also be sent in the same way as the Query." --> does this mean, that a DATA message has to include MRM in this case? In page 15: "An _exisiting_ peering relationship" --> An existing peering relationship Page 24: Return routability checking: when is this feature (as well as other security features) included? Current Transfer-Attribute concerning "Security" is given rather at a high level. In page 37: "(e.g. for which flow)" --> maybe more accurately: "(e.g. for which session") ? In page 55: "Current MRMs define the use of a Router Alert Option [3] to assist the peer in intercepting the message depending on the NSLPID. If the MRM defines the use of RAO, the sender MUST include it by default." and in page 109: ... " multiple NSLPIDs MAY be associated with the same value. " --> How many RAO values are suggested for GIST/NSIS? Supposedly 1, -- or "the same value" here means the value of "MRM"? In page 56: ... "within the _networ_" --> "within the network" In page 88: I maybe lost in the load splitting/sharing: is it so essential to be supported at GIST level? Cheers, Xiaoming Martin Stiemerling wrote: > Hi all, > > Thanks for all getting their reviews done and/or discuss open items. > > The WGLC is extended for one week, as discussions have started late and > to give further opportunities for reviews. > > Thus, the WGLC runs now until **May 2nd**! > > Thanks, > > Martin > > Anfang der weitergeleiteten E-Mail: > >> *Von: * Martin Stiemerling > > >> *Datum: * 18. April 2007 11:37:22 MESZ >> *An: * nsis > >> *Betreff: * *[NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt * >> >> Dear all, >> >> This is a friendly reminder for the currently running WGLC for GIST. >> >> Apparently, there have not been much reviews and/or comments on GIST. >> I interpret this as *nobody* has read the document. Consider also >> Magnus' email response to the original WGLC! >> >> In any case, I would like to encourage all WG memmbers and especially >> *all* implementers and NSLP authors to review GIST and to send their >> comments to the list. >> >> It is even good to send something along the lines "yes, I have read >> the document and it is fine with me." >> >> Thanks and looking forward to your reviews, >> >> Martin >> >> Am 04.04.2007 um 00:31 schrieb Martin Stiemerling: >> >>> Dear all, >>> >>> We are starting an extended WGLC for GIST. The WGLC starts on April >>> 4th and will run for *three* weeks. >>> >>> Everybody of the NSIS WG should review GIST once again, especially >>> all **implementers** and **NSLP authors**. >>> >>> Thank you and looking forward to your reviews and comments >>> >>> Martin >>> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 02 03:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj9EL-0003mQ-2d; Wed, 02 May 2007 03:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj9EK-0003mK-2o for nsis@ietf.org; Wed, 02 May 2007 03:26:28 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj9EH-0000hu-DP for nsis@ietf.org; Wed, 02 May 2007 03:26:28 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l427QKSf015774; Wed, 2 May 2007 16:26:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l427QL315012; Wed, 2 May 2007 16:26:21 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id l427QMx11882; Wed, 2 May 2007 16:26:22 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Date: Wed, 2 May 2007 15:25:08 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD01BE0488@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Thread-Index: AceDVoX/IXmIfI7VS1m3j+E71pRiMAJJ/7aQ From: "Cheng Hong" To: "nsis" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: john.loughney@nokia.com, Martin Stiemerling 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 draft -13 is well written and provides some explanation of the important design points. Below are some of my comments on the draft (mainly for clarifications): - Sec "4.3.2 Local Processing and Validation", page 29, point 2 "The Application MAY provide an updated NSLP payload for the same NSLPID, which will be used in the Query forwarded by GIST. ..., any GIST node forwarding a Query MUST NOT modify it except in the NSLP payload; in particular, it MUST NOT modify any GIST payloads or their order" What does this part mean? A NSLP node is allowed to modified the NSLP payload without being recorded as part of the signaling path. Is there any information allow the receiver of this message to decide where the NSLP payload is actually from? - Sec "4.4.2 GIST Peer Authorisation", Page 38 - 40.=20 This part helps in understanding how the authorisation is carried out on a GIST node. However, it is part of the implementation issue, and belongs to the Security Considerations. Suggest move it after the "8.2 Peer Node Authentication" as "8.3 Peer Node Authorisation". - Sec "5.3.3 Retransmission and Rate Control", Page 58 last paragraph. It is suggested that "A suitable approach is to restrict the token bucket parameters so that the mean output rate is a small fraction , such as 5%, of the nodes' lowest-speed interface."=20 Shouldn't it be "5% of the node's lowest-speed interface participated in the signaling"? What if the node has a extremly low speed interface (e.g. dialup) that is used for other purpose?=20 - Sec "5.8.1.3 Upstream Q-mode Encapsulation" Page 69, third bullet "The DiffServ codepoint and (for IPv6) flow label MAY be set to match the values from the MRI as in the downstream case, and the UDP port selection is also the same." Does this matter? Or, it is just assuming/hoping that the network is doing symmetric routing? - Annex A, "A.2 General Object Format" & "A.3.1.1 Path-Coupled MRM". Both formats have the A/B flags, for different purpose. Would be better if a different name is used, say "C/D", for one of them. - Annex A, "A.3.1.1 Path-Coupled MRM", page 122, "Source/Destination Port" field. It is said that "If the flag is set and port=3D0x0000, the MRI will apply to a specific port, whose value is not yet know."=20 It sounds like a quite useful feature to enable predictive signaling. However, when the port number is know, the signaling states has to be updated, such that it could refer to the current flow. In this case, would receiving a message of different MRI (the port number is different) cause any problem in GIST state management? At least it has impact on the routing state table (Figure 9) on the GIST node. Also, at this state, with port set to 0x0000, the MRI may not be useful at the NSLP layer, e.g. no filter could be derived. A sentence like "In this case, signaling applications decide the use of MRI according to their message processing rule, e.g. mark the state as pending" would be helpful. - Annex A, "A.3.9 NAT Traversal", page 129 first paragraph "The list is initialised by the first NAT on the path; subsequent NATs may delete elements in the list."=20 The subsequent NATs can only delete elements from the list? Is there a reason why they could not add elements (i.e. make further changes to the objects)? Cheers Cheng Hong =20 =20 > -----Original Message----- > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: Friday, April 20, 2007 10:17 PM > To: nsis > Subject: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt=20 >=20 > Hi all, >=20 > Thanks for all getting their reviews done and/or discuss open items.=20 >=20 > The WGLC is extended for one week, as discussions have=20 > started late and to give further opportunities for reviews.=20 >=20 > Thus, the WGLC runs now until **May 2nd**! >=20 > Thanks, >=20 > Martin >=20 >=20 > Anfang der weitergeleiteten E-Mail: >=20 >=20 > Von: Martin Stiemerling > Datum: 18. April 2007 11:37:22 MESZ > An: nsis > Betreff: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt=20 >=20 > Dear all, >=20 > This is a friendly reminder for the currently running=20 > WGLC for GIST. >=20 > Apparently, there have not been much reviews and/or=20 > comments on GIST. I interpret this as *nobody* has read the=20 > document. Consider also Magnus' email response to the original WGLC! >=20 > In any case, I would like to encourage all WG memmbers=20 > and especially *all* implementers and NSLP authors to review=20 > GIST and to send their comments to the list. >=20 > It is even good to send something along the lines "yes,=20 > I have read the document and it is fine with me." >=20 > Thanks and looking forward to your reviews, >=20 > Martin >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 02 04:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj9p5-0005J3-Sj; Wed, 02 May 2007 04:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj9p3-0005FI-K5 for nsis@ietf.org; Wed, 02 May 2007 04:04:25 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj9p1-0001BH-14 for nsis@ietf.org; Wed, 02 May 2007 04:04:25 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9F79513CF82 for ; Wed, 2 May 2007 10:04:19 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <987892BF-91A6-4FBE-90DF-0DA38BB4B312@netlab.nec.de> Message-Id: <5A4C82D1-D8FB-4602-A08F-9DAC2635D684@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt Date: Wed, 2 May 2007 10:04:18 +0200 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f3de74e534ea82d41273d2b8504db1c 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="===============0059831279==" Errors-To: nsis-bounces@ietf.org --===============0059831279== Content-Type: multipart/alternative; boundary=Apple-Mail-9-69879165 --Apple-Mail-9-69879165 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed [I'm writing as NATFW NSLP author.] Hi all, I have read the GIST draft and I'm fine with the draft. The draft contains an excellent written protocol specification and explains the overall protocol also in an excellent way. There are some nits in the draft but those have been already covered by all the other people that did a review. Good job! :) Martin Am 20.04.2007 um 16:17 schrieb Martin Stiemerling: > Hi all, > > Thanks for all getting their reviews done and/or discuss open items. > > The WGLC is extended for one week, as discussions have started late > and to give further opportunities for reviews. > > Thus, the WGLC runs now until **May 2nd**! > > Thanks, > > Martin > > Anfang der weitergeleiteten E-Mail: > >> Von: Martin Stiemerling >> Datum: 18. April 2007 11:37:22 MESZ >> An: nsis >> Betreff: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt >> >> Dear all, >> >> This is a friendly reminder for the currently running WGLC for GIST. >> >> Apparently, there have not been much reviews and/or comments on >> GIST. I interpret this as *nobody* has read the document. Consider >> also Magnus' email response to the original WGLC! >> >> In any case, I would like to encourage all WG memmbers and >> especially *all* implementers and NSLP authors to review GIST and >> to send their comments to the list. >> >> It is even good to send something along the lines "yes, I have >> read the document and it is fine with me." >> >> Thanks and looking forward to your reviews, >> >> Martin >> >> Am 04.04.2007 um 00:31 schrieb Martin Stiemerling: >> >>> Dear all, >>> >>> We are starting an extended WGLC for GIST. The WGLC starts on >>> April 4th and will run for *three* weeks. >>> >>> Everybody of the NSIS WG should review GIST once again, >>> especially all **implementers** and **NSLP authors**. >>> >>> Thank you and looking forward to your reviews and comments >>> >>> Martin >>> >>> Anfang der weitergeleiteten E-Mail: >>> >>>> Von: >>>> Datum: 3. April 2007 21:50:02 MESZ >>>> An: >>>> Kopie: >>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt >>>> >>>> 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: General Internet Signalling Transport >>>> Author(s) : H. Schulzrinne, R. Hancock >>>> Filename : draft-ietf-nsis-ntlp-13.txt >>>> Pages : 177 >>>> Date : 2007-4-3 >>>> >>>> This document specifies protocol stacks for the routing and >>>> transport >>>> of per-flow signalling messages along the path taken by that >>>> flow >>>> through the network. The design uses existing transport and >>>> security >>>> protocols under a common messaging layer, the General Internet >>>> Signalling Transport (GIST), which provides a common service for >>>> diverse signalling applications. GIST does not handle >>>> signalling >>>> application state itself, but manages its own internal state >>>> and the >>>> configuration of the underlying transport and security >>>> protocols to >>>> enable the transfer of messages in both directions along the >>>> flow >>>> path. The combination of GIST and the lower layer transport and >>>> security protocols provides a solution for the base protocol >>>> component of the "Next Steps in Signalling" framework. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-13.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-13.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. >>>> >>>> >>>> >>> >>> >>> >>> stiemerling@netlab.nec.de >>> NEC Europe Limited | >>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >>> Registered in England 2832014 >>> >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 >> >> >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-9-69879165 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 [I'm writing as NATFW NSLP = author.]

Hi = all,

I have = read the GIST draft and I'm fine with the draft. The draft contains an = excellent written protocol=A0specification and explains the overall = protocol also in an excellent way.

There are some nits in the = draft but those have been already covered by all the other people that = did a review.

Good job! :)

=A0 = Martin

Am 20.04.2007 um 16:17 schrieb Martin = Stiemerling:

Hi all,

Thanks for all getting = their reviews done and/or discuss open items.=A0

The WGLC is extended for = one week, as discussions have started late and to give further = opportunities for reviews.=A0

Thus, the WGLC runs now = until **May 2nd**!

Thanks,

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: = Martin Stiemerling <stiemerling@netlab.nec.de>= ;
Datum: 18. April 2007 11:37:22 = MESZ
An: nsis <nsis@ietf.org>
Betreff: = [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt=A0

Dear = all,

This is a friendly reminder for the currently = running WGLC for GIST.
Apparently, there have not been = much reviews and/or comments on GIST. I interpret this as *nobody* has = read the document. Consider also Magnus' email response to the original = WGLC!

In any case, I would like to encourage all WG = memmbers and especially *all* implementers and NSLP authors to review = GIST and to send their comments to the list.

It is = even good to send something along the lines "yes, I have read the = document and it is fine with me."

Thanks and looking forward to = your reviews,

=A0 = Martin

Am 04.04.2007 um 00:31 schrieb Martin = Stiemerling:

=
Dear all,

We are = starting an extended WGLC for GIST. The WGLC starts on April 4th and = will run for *three* weeks.

Everybody of the NSIS WG should = review GIST once again, especially all **implementers** and **NSLP = authors**.

Thank you and looking forward to your reviews and = comments

=A0 = Martin

Anfang der weitergeleiteten E-Mail:

Von: <Internet-Drafts@ietf.org><= /DIV>
Datum: 3. April 2007 21:50:02 MESZ
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Kopie: <nsis@ietf.org>
Betreff: [NSIS] I-D = ACTION:draft-ietf-nsis-ntlp-13.txt

A New Internet-Draft is = available from the on-line Internet-Drafts
This draft is a work item of the = Next Steps in Signaling Working Group of the IETF.

= Title = = : GIST: General Internet Signalling Transport
Author(s) : H. = Schulzrinne, R. Hancock
= Filename = : draft-ietf-nsis-ntlp-13.txt
= Pages = = : 177
Date : 2007-4-3

This document = specifies protocol stacks for the routing and transport
=A0=A0 = of per-flow signalling messages along the path taken by that = flow
=A0=A0 through the network.=A0 The design uses existing = transport and security
=A0=A0 protocols under a common = messaging layer, the General Internet
=A0=A0 Signalling Transport = (GIST), which provides a common service for
=A0=A0 diverse signalling = applications.=A0 GIST does = not handle signalling
=A0=A0 application state itself, = but manages its own internal state and the
=A0=A0 configuration of the = underlying transport and security protocols to
=A0=A0 = enable the transfer of messages in both directions along the = flow
=A0=A0 path.=A0 The combination of GIST and = the lower layer transport and
=A0=A0 security protocols = provides a solution for the base protocol
=A0=A0 component of the "Next = Steps in Signalling" framework.

A URL for this Internet-Draft = is:

To = remove yourself from the I-D Announcement list, send a message = to
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of
the message.
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-13.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-nsis-ntlp-13.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
<ATT966628.TXT>
<ATT966629.txt>



stiemerling@netlab.nec.de
NEC Europe Limited |
Registered in England 2832014



nsis mailing list



stiemerling@netlab.nec.de
NEC Europe Limited |
Registered in England 2832014




nsis mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

nsis mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-9-69879165-- --===============0059831279== 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 --===============0059831279==-- From nsis-bounces@ietf.org Wed May 02 19:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjOFy-0001ME-Kj; Wed, 02 May 2007 19:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjOFx-0001M8-Ed for nsis@ietf.org; Wed, 02 May 2007 19:29:09 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjOFu-0006Jz-MB for nsis@ietf.org; Wed, 02 May 2007 19:29:09 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HjOFs-0002s7-G2 for ; Thu, 03 May 2007 01:29:06 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1HjOFs-0007LY-7U; Thu, 03 May 2007 01:29:04 +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 CC9BC2FC013 for ; Thu, 3 May 2007 01:29:03 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HjOFr-0002tL-Cx for nsis@ietf.org; Thu, 03 May 2007 01:29:03 +0200 Message-ID: <46391EBE.8060801@tm.uka.de> Date: Thu, 03 May 2007 01:29:02 +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: "nsis@ietf.org" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [NSIS] GIST WGLC comments 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, First of all: this is a very complete and well written protocol specification. It provides a lot of background on protocol design choices. Well done! Despite its relatively large page volume, it's straightforward implementable (speaking as an implementer). I still have some remarks/comments (and maybe more to come after the interop): - 5.3.2.1: Option to disable MUST be disabled by default...might be confusing...in the following paragraph: Implementations MAY provide an option to disable the setting of RAO on Q-mode packets on a per-destination prefix basis; however, the option MUST be disabled by default and MUST only be enabled when it has been separately verified that the the next GIST node along the path to the destination is capable of intercepting packets without RAO. - Why is the magic number at all necessary? I don't see the case that non-GIST data packets carry the same RAO and get accidently caught. Likewise, if RAO is not used in special cases, it could be ensured that normal data flows will not use destination port 4, too? - Error for Wrong/Missing Magic number: I would recommend to send back an "Incorrect Encapsulation" error (maybe also with additional corresponding subcode) since the magic number is not really part of the common header. Furthermore: since we will not parse the message with the wrong magic number, I don't know what to fill into the common-error-header, esp. protocol version is also unknown. - Why is the Hello-ID object not optional? This was observed by Max Laier while implementing the current proposal. If the Hello-ID is only required when r=1, we could omit it if r=0 and no response is required. So instead of setting Hello-ID=0 we simply could omit it. This would also reduce number or error cases: we do not have to deal with a forbidden hello-ID==0. - Using the SII handle to get back to the same next hop is probably not so easy. What if there is no existing MA that could be reused. Should a new MA be set up? How could this be done along the "old path". More guidance on this topic would be nice... Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 03 03:47:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjW2N-0003nt-99; Thu, 03 May 2007 03:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjW2K-0003nO-6q for nsis@ietf.org; Thu, 03 May 2007 03:47:36 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjW2G-0001SI-RL for nsis@ietf.org; Thu, 03 May 2007 03:47:36 -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 l437lQWW032102 for ; Thu, 3 May 2007 08:47:26 +0100 Received: from [193.118.197.222] ([193.118.197.222]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 08:47:26 +0100 Message-ID: <4639938E.2040702@roke.co.uk> Date: Thu, 03 May 2007 08:47:26 +0100 From: Andrew McDonald User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2007 07:47:26.0720 (UTC) FILETIME=[4B3B5800:01C78D57] X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f864d073635f9dbbfb1a859082fbfac Subject: [NSIS] GIST WGLC comments 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, My review comments are below. Generally the document is readable, and provides a reasonable balance between background and detailed specification. My comments are mainly editorial or on minor issues of clarity. I don't believe there are any serious technical problems with the draft. Andrew > 1. Introduction > (GIST). GIST does not handle signalling application state itself; in > that crucial respect, it differs from application signalling > protocols such as SIP, RTSP, and the control component of FTP. > Instead, GIST manages its own internal state and the configuration of > the underlying transport and security protocols to ensure the > transfer of signalling messages on behalf of signalling applications > in both directions along the flow path. I found the comparison/differentiation from application signalling slightly confusing. I'm ot sure if it could be clarified. It is probably the juxtaposition of the terms "signalling application" and "application signalling" that are the problem. > operation is captured in the form of state machine language in possible reword: state machine language -> state machines > packets with IP options to probe the network, which leads to > migration issues in networks with non-GIST nodes, especially in the > case of IPv4, and these are discussed in Appendix C. "networks with non-GIST nodes" is basically every existing deployed networks. That sounds like a total roadblock to deployment. I don't think the situation is really that bad! > document, Section 9 gives the formal IANA considerations for the > registries already defined by the GIST specification. suggested reword: registries already defined -> registries defined > 2. Requirements Notation and Terminology > GIST Node: Any node along the data path supporting GIST, regardless > of what signalling applications it supports. Does this definition include GIST-aware NATs? > Messaging Association (MA): A single connection between two > explicitly identified GIST adjacent peers, i.e. between a given > signalling source and destination address. A messaging > association may use a specific transport protocol and known ports. > If security protection is required, it may use a specific network > layer security association, or use a transport layer security > association internally. A messaging association is bidirectional: > signalling messages can be sent over it in either direction, > referring to flows of either direction. The phrase "may use a specific transport protocol and known ports" seems a little odd? It made we wonder whether there was some possibility of using "unknown ports" that was being deliberately excluded. Use of the word 'specific' also seemed superfluous (on both occasions). > 3.1. Overall Design Approach > To meet the routing requirement, one possibility is for the node to > use local routing state information to determine the identity of the > GIST peer explicitly. GIST defines a three-way handshake which > probes the network to set up the necessary routing state between > adjacent peers, during which signalling applications can also > exchange data. The term 'routing state' is GIST-specific jargon which hasn't really been introduced at this stage. Could it be reworded? > (NTLP). The strategy of splitting the transport problem leads to a > layered structure for the NTLP, of a specialised GIST messaging layer possible edit: of a -> with a [snip] > ========|===================|===== <-- GIST API > | | > ^^ +------------------------------------------------+ > || |+-----------------------+ +--------------+ | > || || GIST | | GIST State | | > || || Encapsulation |<<<>>>| Maintenance | | > || |+-----------------------+ +--------------+ | > || | GIST: Messaging Layer | > || +------------------------------------------------+ [snip] > Figure 2: Protocol Stack Architecture for Signalling Transport The term "GIST Encapsulation" seemed unclear to me. I suspect it is meant to be deliberately vague. Could it be made differently vague? > 3.2. Modes and Messaging Associations > Connection mode (C-mode): used for larger messages or where fast > state setup in the face of packet loss is desirable, or where > channel security is required. Setup of what state? Signalling Application state? > D-mode uses UDP, as a suitable NAT-friendly encapsulation which does suggested edit: remove ',' > not require per-message shared state to be maintained between the > peers. Long-term evolution of GIST is assumed to preserve the > simplicity of the current D-mode design. Extensions to the security > or transport capabilities of D-mode can be provided equivalently by > selecting a different protocol stack under the GIST messaging layer, > which would then become another option within the overall C-mode > framework. This includes both the case of using existing protocols I got slightly confused by the sentence "Extensions ... framework.". Could it be reworded? Replacing 'equivalently' with 'alternatively' or 'instead' would probably have been enough for me. (I think part of the point is that 'if you want to do this, do it with C-mode, not D-mode'). > 3.3. Message Routing Methods > Most of the details of GIST operation are independent of which is > being used. Therefore, the GIST design encapsulates the routing- > dependent details as a message routing method (MRM), and allows Which of what alternatives? My first read of this was that it was a choice between 'predictive routing' and 'nat address resverations'. Maybe change 'which is' to 'the message routing'. > The content of a MRM definition is as follows, using the path-coupled > MRM as an example: suggested edit: a MRM -> an MRM > o A specification of the IP-level encapsulation of the messages > which probe the network to discover the adjacent peers. A > downstream encapsulation must be defined; an upstream > encapsulation is optional. Random thought: is it impossible to envisage an MRM that can only do upstream routing? Or, is there some other reason for the constraint? > The Query, Response and Confirm messages implement the handshake that > GIST uses to set up routing state and messaging associations. The > handshake is initiated from the Querying node towards the Responding > node. The first message is the Query, which is encapsulated in a > special way depending on the message routing method, in order to > probe the network infrastructure so that the correct peer will > intercept it and become the Responding node. A Query always triggers 'probe the network' and 'intercept it' are true for current MRMs. Are they true for all beyond-current-GIST MRMs? > a Response in the reverse direction as the second message of the > handshake. As part of the defence against denial of service attacks, > the Responding node can delay state installation until a return > routability check, and require the Querying node to complete the suggested reword: "a return routability check" -> "a return routability check has been performed" > 3.5. GIST Peering Relationships > > Peering is the process whereby two GIST nodes create message routing > state which point to each other. Something seemed a bit odd about this sentence. Does 'state' need to be 'states'? (i.e. they each create some state; they don't jointly create one piece of state) > change. As well as network level rerouting, changes could include > modifications in NSIS signalling functions deployed at a node, or suggested reword: "modifications in" -> "modifications to" > 4.2.1. Message Routing State > o The node is using other techniques to send the message. For > example, it can send it in Q-mode and rely on the peer to > intercept it. Possible reword: "other techniques to send the message" -> "other techniques to route the message" or "other techniques to address the message" or something of that sort It's only the 'how to get this to the next hop' question. The text could (maybe) be read as broader than that. > > In addition, if the node is a flow endpoint, GIST will refuse to > create routing state for the direction beyond the end of the flow > (see Section 4.3.3). This isn't really 'in addition' since it overlaps with the 2nd bullet above. Maybe "In particular," instead. And, maybe, "refuse to attempt to create" rather than just "refuse to create". > 4.3. Basic GIST Message Processing > > This section describes how signalling application messages are > processed in the case where any necessary messaging associations and > routing state are already in place. The description is divided into > several parts. Firstly, message reception, local processing and > message transmission are described for the case where the node hosts > the NSLPID identified in the message. Secondly, the case where the > message is handled directly in the IP or GIST layer (because there is > no matching signalling application on the node) is given. An > overview is given in Figure 3. This section concentrates on the GIST > level processing, with full details of IP and transport layer > encapsulation in Section 5.3 and Section 5.4. "Firstly" and "Secondly" are slightly confusing, since the 'firstly' actually covers sections 4.3.1 to 4.3.3, while 'secondly' is just 4.34. Maybe reword to: "Firstly (in sections 4.3.1 to 4.3.3)" and "Secondly (in section 4.3.4)" > +---------------------------------------------------------+ > | >> Signalling Application Processing >> | > | | > +--------^---------------------------------------V--------+ > ^ V > ^ NSLP Payloads V > ^ V > +--------^---------------------------------------V--------+ > | >> GIST >> | > | ^ ^ ^ Processing V V V | > +--x-----------N--Q---------------------Q--N-----------x--+ It's not clear what the 'NSLP Payloads' in this diagram is. Having made a guess about what it is trying to say, I'd suggest either changing it to: +---------------------------------------------------------+ | >> Signalling Application Processing >> | | | +--------^---------------------------------------V--------+ ^ NSLP NSLP V ^ Payloads Payloads V ^ V +--------^---------------------------------------V--------+ | >> GIST >> | Or get rid of the 'NSLP Payloads' text altogether. > 4.3.1. Message Reception > Normal encapsulation: Normal messages arrive UDP-encapsulated and > addressed directly to the receiving signalling node, at an address > and port learned previously. Each datagram contains a single "port learned previously" sounds like some special discovery mechanism has been used. Actually it is just "GIST well known port" or "the UDP port we got a message from". Could it be reworded? > message which is passed to the GIST layer for further processing, > just as in the C-mode case. > > Q-mode encapsulation: Where GIST is sending messages to be > intercepted by the appropriate peer rather than directly addressed > to it (in particular, Query messages), these are UDP encapsulated, > and MAY include an IP router alert option (RAO) if required by the > MRM. I think this should be a 'may' rather than a 'MAY'. The RFC2119 language would be in the relevant MRM description. > 4.3.3. Message Transmission > > Signalling applications can generate their messages for transmission, > either asynchronously, or in reply to an input message, and GIST can I assume 'input message' means a message received by the signalling app from GIST, rather than an 'input message' received through some other API on the signalling app. Is it worth making clearer? > If a messaging association is not required, the message is sent in > D-mode. The processing in this case depends on the message type and > whether routing state exists or not. Is 'not required' the best wording? It suggests that there are some circumstances where it is required, but the default fall-back position is to use D-mode. Would 'not appropriate' be better? > 4.3.4. Nodes not Hosting the NSLP > 1. A message contains an RAO value which is relevant to NSIS, but it > does not exactly match the Q-mode encapsulation rules of > Section 5.3.2. The message MUST be transparently forwarded at > the IP layer. This says 'at the IP layer', but the Q-mode checks require GIST involvement. So, is it 'at the IP layer'? Should there be mention in this (otherwise fairly comprehensive) list of what to do with an RAO value which is not relevant? > 2. A Q-mode encapsulated message contains an RAO value which is > relevant to NSIS but not to the specific node, but the IP layer > is unable to recognise whether it needs to be passed to GIST for > further processing or whether the packet should be forwarded just > like a normal IP datagram. > > 3. A Q-mode encapsulated message contains an RAO value which is > relevant to the node, but the specific signalling application for > the NSLPID in the message is not processed there. I found these two points a little unclear. There seemed to be some overlap between the two points. Actually, on reading (2) again, I'm not sure what it really is saying. It feels like it overlaps with (3), but I'm no longer sure. > In cases (2) and (3), the role of GIST is to forward the message > essentially as though it were a normal IP datagram, and it will not > become a peer to the node sending the message. Forwarding with > modified NSLP payloads is covered above in Section 4.3.2. However, a > GIST implementation MUST ensure that the IP-layer TTL field and GIST > hop count are managed correctly to prevent message looping, and this > should be done consistently independently of whether the processing > takes place on the fast path or in GIST-specific code. The rules are > that in cases (2) and (3), the IP-layer TTL MUST be decremented just > as if the message was a normal IP forwarded packet; in case (3) the > GIST hop count MUST be decremented as in the case of normal input > processing, which also applies to cases (4) and (5). I'm unclear on why there is a difference between handling (2) and (3). I suspect my confusion over (2) and (3) itself probably doesn't `help. In fact, (2) doesn't identify messages that need to be forwarded - it just says "GIST needs to look at it harder and decide". So, I'm not sure why GISTs role is to forward these messages regardless. Is any further guidance needed on preserving the original IP headers, e.g. with respect to DSCPs or ECN marking? > In the first two cases, only the common header of the GIST message is > examined; in the third case, the MRI is also examined. The rest of > the message MUST NOT be inspected in any case. Similar to the case > of Section 4.3.2, the GIST payloads MUST NOT be modified or re- > ordered; an implementation MAY choose to achieve this by retaining > the original message, rather than reconstructing it from some parsed > internal representation. Although this last point is a 'MAY', I think that's the only way to do it if you are going to fully obey the 'MUST NOT', since the 'MUST NOT' means that you have to forward errored data that you would be unable to parse. > 4.4. Routing State and Messaging Association Maintenance > The initial message in any routing state maintenance operation is a > Query, sent from the querying node and intercepted at the responding suggested reword: "intercepted at the" -> "intercepted by the node that will become the" since it you know that it is going to be the responding node at the time of interception > 4.4.2. GIST Peer Authorisation > This specification models the decision as verification by the > authorising node of the peer's identity against a local list of > peers, the authorised peer database (APD). The APD is a abstract "a abstract" -> "an abstract" > 4.4.3. Messaging Association Multiplexing > For routers, the Router-ID [2], which is one of the router's IP > addresses, MAY be used as one possible value for the Peer- > Identity. In scenarios with nested NATs, the Router-ID alone may > not satisfy the uniqueness requirements, in which case it MAY be > extended with additional tokens, either chosen randomly or > administratively coordinated. I don't believe the RFC1812 (i.e. ref [2]) Router-ID is appropriate. It only appears to be defined for unnumbered links. More importantly: "Routers with multiple unnumbered interfaces MAY have multiple router-id's.". This doesn't meet the interface independence requirement. > 4.4.4. Routing State Maintenance > > Each item of routing state expires after a lifetime which is > negotiated during the Query/Response/Confirm handshake. The Network > Layer Info (NLI) object in the Query contains a proposal for the > lifetime value, and the NLI in the Response contains the value the > Responding node requires. What routing state lifetime value is carried in the Confirm? > 4.4.5. Messaging Association Maintenance > Because the Responding node can choose not to create state until a > Confirm, an abbreviated Stack-Configuration-Data object containing > just this information MUST be repeated by the Querying node in the > first Confirm sent on a new MA. If the object is missing in the > Confirm, an "Object Type Error" message (Appendix A.4.4.9) with > subcode 2 ("Missing Object") MUST be returned. Should it be made clearer that this is the SCD from the Query that is repeated (i.e. not the one from the Response being reflected back). > 5.1. GIST Messages > GIST-Message: The primary messages are either one of the stages in suggested reword: "one of the stages in" -> "part of" > indicate if a reply of some sort is requested. The objects following > the common header MUST be carried in a fixed order, depending on > message type. Messages with missing, duplicate or invalid objects > for the message type MUST be rejected with an "Object Type Error" > message with the appropriate subcode (Appendix A.4.4.9). Since the ordering of objects is a MUST, a compliant implement does not need to cope with receiving messages with objects in a different order (though Postel's Law suggests it would be good if it did). However, if it doesn't like it, what should it do? What error message should it send? Possibly an Object Type Error with subcode 3 (Invalid Object Type) would be reasonable. > Network-Layer-Information. If the message exchange relates to setup > of a new messaging association, which MUST be carried out in D-mode, This phrase is possibly ambiguous. In particular, the Confirm must be carried over the MA, which isn't D-mode. It probably ought to be made clearer that it is the Response that must be sent in D-mode in this scenario. > MA-Hello: This message MUST be sent only in C-mode. It contains the > common header, with a NSLPID of zero, and a message identifier, the > Hello-ID. It always indicates that a node wishes to keep a messaging > association open, and if sent with R=0 and null Hello-ID this is its suggested reword: "null Hello-ID" -> "a Hello-ID of zero" or "zero Hello-ID" > only function. A node MAY also invoke a diagnostic request/reply > exchange by setting R=1 and providing a non-zero Hello-ID; if this > case, the peer MUST send another MA-Hello back along the messaging > association echoing the same Hello-ID and with R=0. Use of this > diagnostic is entirely at the discretion of the initiating node. By "initiating node" do you mean the node sending the MA-Hello that requests a response? > 5.2.1. The Common Header > Note that in D-mode Section 5.3, there is a 32-bit magic number suggested comma: "D-mode Section 5.3," -> "D-mode, Section 5.3," > 5.2.2. TLV Objects > > All data following the common header is encoded as a sequence of > type-length-value objects. Currently, each object can occur at most Why "Currently"? Is there a particular extensibility issue being hinted at here? (Should it be made more explicit?) > The interface-address must be routable, i.e. it MUST be usable as > a destination IP address for packets to be sent back to the node > generating the signalling message, whether in D-mode or C-mode. > If this object is carried in a message with the source addressing > mode flag S=1, the interface-address MUST match the source address > used in the IP encapsulation, to assist in legacy NAT detection > (Section 7.2.1). If this object is carried in a Query or Confirm, > the interface-address MUST specifically be set to an address bound > to the interface associated with the MRI, to allow its use in suggest: "to the interface" -> "to an interface" The subsequent text suggests how to pick a suitable interface - which means there is (likely to be) more than one to choose from. > GIST-Error-Data: This contains all the information to report the > cause and context of an error. "all the information": _all_ sounds a bit strong to me > 5.3.2.3. Upper Layer Encapsulation and Overall Interception > Requirements > packets intercepted within the networ which does not match both the "networ" -> "network" > 5.3.2.4. IP Option Processing > > For both IPv4 and IPv6, for Q-mode packets with IP options allowed by > the above requirements, IP options processing is intended to be > carried out independently of GIST processing. Note that for the > options allowed by the above rules, the options semantics are > independent of the payload: UDP payload modifications are not > prevented by the options and do not affect the options content, and > conversely the presence of the options does not affect the UDP > payload. Some of the "options" should be possesive "options'" > On packets originated by GIST, IP options MAY be added according to > node-local policies on outgoing IP data. On packets forwarded by > GIST without NSLP processing, IP options MUST be processed as for a > normally forwarded IP packet. On packets locally delivered to the > NSLP, the IP options MAY be passed to the NSLP and equivalent options > used on subsequently generated outgoing Q-mode packets. In this > case, routing related options on SHOULD be processed identically as > they would be for a normally forwarded IP packet. The last sentence doesn't make sense (i.e. not English). > 5.5. Message Type/Encapsulation Relationships > specification. If a message arrives with an invalid encapsulation > (e.g. a Query arrives over a messaging association), this MUST be > rejected with an "Incorrect Encapsulation" error message > (Appendix A.4.4.3). This probably needs to be made clearer, particularly with the reduction in differences between Q/D-modes. This relates in part to issue 183, which notes that a receiver might not be able to tell whether something was Q or D mode encapsulated. In particular, if a receiver receives a Query and believes it is D-mode, not Q-mode, that probably shouldn't be an error, particularly with the 5.3.2.1 and Appendix C discussion on leaving off RAOs. > 5.7.1. Overview > A Query requesting association setup always contains a Stack-Proposal suggested reword: "requesting association" -> "requesting messaging association" > and Stack-Configuration-Data object. The Stack-Proposal MUST only > include protocol configurations that are suitable for the transfer > attributes of the messages that the Querying node wishes use the suggested reword: "wishes use" -> "wishes to use" > o The re-used messaging association MUST have equivalent or better > transport and security characteristics as at least one of the > protocol configurations that was offered in the Query. I found it difficult to understand these bullets. In the first one, changing "all of the options" to "any of the options" would probably work for me. For the second, is it really just saying "you MUST pick one of the options from the Query"? > 5.7.3. Protocol Definition: Transport Layer Security > GIST nodes MAY negotiate other TLS ciphersuites. In some cases, the > negotiation of alternative ciphersuites is used to trigger > alternative authentication procedures, such as the use of pre-shared > keys [33]. The use of other authentication procedures may require > additional specification work to define how they can be used as part > of TLS within the GIST framework, and may or may not require the > definition of additional MA-Protocol-IDs. Following on from the previous paragraph, I read this as saying that PSK was not covered in this document. However, 5.7.3.1 does discuss use of identities in PSK. > 5.8.1.3. Upstream Q-mode Encapsulation > This section defines an upstream Q-mode encapsulation and validation > checks for when it can be used. The functionality to generate > upstream Queries is OPTIONAL, but if received they MUST be processed > in the normal way. No special functionality is needed for this. Although it says "in the normal way", there are some additional checks (TTL) on upstream Queries. > o The DiffServ codepoint and (for IPv6) flow label MAY be set to > match the values from the MRI as in the downstream case, and the > UDP port selection is also the same. Why "MAY"? It is "SHOULD" in the downstream direction. > 5.8.2.2. Downstream Q-mode Encapsulation > o By default, the IP source address is the source address, again > from the MRI (S=0). However, the use of the signalling source > address (S=1) is allowed as in the case of the path-coupled MRM. suggested reword: remove ", again" > 6. Formal Protocol Specification > 4. Messaging associations have their own lifecycle, represented by > MA-SM, from when they are first created (in an incomplete state, "by MA-SIM" -> "by an MA-SM" > 6.1. Node Processing > cause the creation of other state machines. The only events that are > processed by this state machine are incoming GIST messages (Query/ > Response/Confirm/Data) and API requests to send data; no other events > are possible. There are also some er_ events from receiving Error messages. > Rle 5 (tg_NSLPData): "Rle 5" -> "Rule 5" > 6.2. Query Node Processing > state, in which timeout-based retransmissions are handled. Data > messages (rx_Data events) should not occur in this state; if they do, > this may indicate a lost Response and a node MAY also retransmit a > Query for this reason. suggested reword: "MAY also retransmit" -> "MAY retransmit" > 6.3. Responder Node Processing > Rule 10: > // can happen e.g. a retransmitted Response causes a duplicate Confirm > silently ignore Comment should be indented by one character. > 6.4. Messaging Association Processing > Rule 2: > pass message to Node-SM > if the NoHello timer was running, stop it In some cases, shouldn't the message be passed to a R-SM (e.g. a Confirm) or a Q-SM (e.g. a Response when reusing an MA) instead? > 7.1.2. Route Change Detection Mechanisms > GIST Probing: According to the specification, each GIST node MUST > periodically repeat the discovery (Query/Response) operation. > Values for the probe frequency are discussed in Section 4.4.4. > The querying node will discover the route change by a modification > in the Network-Layer-Information in the Response. The period can > be negotiated independently for each GIST hop, so nodes that have > access to the other techniques listed above MAY use long periods > for the probing operation. suggested reword: "for the probing operation." -> "between probes." > 7.1.3. GIST Behaviour Supporting Re-Routing > routing state is considered Bad until the machine first enters the suggested reword: "the machine" -> "the state machine" > 7.1.4. Load Splitting and Route Flapping > statement that an SII handle no longer lies on the path. Both can be "SII handle" -> "SII-Handle" (to follow standard form elsewhere) > 7.2.2. GIST-aware NAT Traversal > the contents of the MRI. This makes the assumption that NATs only > rewrite the header fields included in this payload, and not other suggested reword: "this payload" -> "the MRI" > 7.2.3. Message Processing Rules > A NAT will intercept D-mode messages with the normal encapsulation > containing such echoed NAT-Traversal objects. The NAT processing is > a subset of the processing for the Q-mode encapsulated case: I assume this applies to (most commonly) Responses, and also Data messages. Could this be made clearer in some way? > 7.4. IPv4-IPv6 Transition and Interworking > mismatching versions MUST be rejected with a "MRI Validation > Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP 'a "MRI Validation' -> 'an "MRI Validation' > 8.6. Security Protocol Selection Policy > 1. The Response does not depend on the Stack-Proposal in the Query > (see Section 5.7.1). Therefore, tampering with the Query has no > effect on the resulting messaging association configuration. Is this still true when the responding node picks to reuse an existing MA? > 9. IANA Considerations > NSLP Identifiers: Each signalling application requires the > assignment of one of more NSLPIDs. The following NSLPID is "of one of more" -> "of one or more" > of GIST operation. If the new MA-Protocol-ID can be used in > conjunction with existing ones (for example, a new transport > protocol option which could be used with Transport Layer removing the word "option" would have made this clearer for me > A.1. The GIST Common Header > The rules governing the use of the R-flag depend on the GIST message > type. It MUST always be set (R=1) in Query messages, since these > always elicit a Response, and never in Confirm, Data or Error > messages. It MAY be set in an MA-Hello; if set, another MA-Hello > MUST be sent in reply. Does the MA-Hello in reply have to have R=0? > A.2.1. Object Extensibility > The combination AB=11 is reserved. If a message is received > containing an object with AB=11, it MUST be rejected with an "Object > Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid > Extensibility Flags"). > > These extensibility rules define only the processing within the GIST > layer. There is no requirement on GIST implementations to support an > extensible service interface to signalling applications, so > unrecognised objects with AB=01 or AB=10 do not need to be indicated > to NSLPs. If a new GIST object is defined which requires such an > interaction, it should be specified with AB=11. I don't understand the last sentence (given the previous paragraph). > A.3.1.1. Path-Coupled MRM > T flag: T=1 means that DiffServ field (DS-field) is significant. "that DiffServ" -> "that the DiffServ" > A.4.4.1. Common Header Parse Error > 0: Unknown Version: The GIST version is unknown. The (highest) > supported version supported by the node can be inferred from the > Common Header of the Error message itself. I believe this error code relies on some assumptions about possible 'upgrades' of GIST. In particular, in order to avoid error storms (from sending errors in response to errors) either: - common header needs to remain mostly unchanged (in particular the message type field) - implementations of GIST version N, need to understand the common header of GIST version N-1 > A.4.4.10. Object Value Error Should there be a diagnostic error subcode for the situation where the stack proposal in the confirm doesn't match that in the response? > B.4. NetworkNotification > NSLPID: An identifier indicating which NSLP this is message is for. "this is message" -> "this message" > Appendix C. Deployment Issues with Router Alert Options > function. It is always possible for middleboxes to block specific > traffic types; by using a normal encapsulation for Q-mode traffic at What does "normal" mean? > The IPv4 RAO is defined by [3], which defines the RAO format with a > 2-byte value field; however, only one value (zero) is defined and > there is no IANA registry for further allocations. It states that > unknown values should be ignored (i.e. the packets forwarded as > normal IP traffic); however, it has also been reported that some > existing implementations simply ignore the RAO value completely (i.e. > process any packet with an RAO as though the option value was zero). Linux has a similar but slightly different problem when using the "router alert" sockopt. In the IPv4 case it doesn't allow an application to express 'interest' in a particular RAO value. However, it is also hard-coded to only intercept packets with an RAO value of zero. > Appendix D. Example Routing State Table and Handshake > -------------------------- Query ----------------------------> > IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST) > Q-mode magic number (0x4e04 bda5) > GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0) In this (and the rest of this example), is it intended to replace "Dst=GIST" with the actual port number once allocated? Also, should the state of the "E" flag in the common header be shown? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 03 05:08:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjXIT-0001j1-Ix; Thu, 03 May 2007 05:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjXIS-0001it-9p for nsis@ietf.org; Thu, 03 May 2007 05:08:20 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjXIR-0002z5-0b for nsis@ietf.org; Thu, 03 May 2007 05:08:20 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HjXIO-0005f8-Sg; Thu, 03 May 2007 11:08:18 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1HjXIO-0002EA-CA; Thu, 03 May 2007 11:08:16 +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 B631B2FC21C; Thu, 3 May 2007 11:08:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HjXIN-0003po-Ea; Thu, 03 May 2007 11:08:15 +0200 Message-ID: <4639A67E.1060903@tm.uka.de> Date: Thu, 03 May 2007 11:08:14 +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: "Hancock, Robert" , "nsis@ietf.org" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [NSIS] GIST NLI matching 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 Robert, I guess there is some guidance missing in section 4.4.3. The text says the NLI object includes peer-identity and interface-address which is correct. But the _complete_ NLI object contains also IP-TTL and RS-Validity Time. In the following text it should be made clear what "matching" an NLI means. I guess that it's intended to use only peer-identity and interface-address to find MAs. Section 5.2.2 mentions this: "The peer-identity and interface-address are used for matching existing associations, as discussed in Section 4.4.3" I propose to mention this explicitly in section 4.4.3, too. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 04 02:29:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjrIO-0006zt-Sp; Fri, 04 May 2007 02:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjrIN-0006zl-52 for nsis@ietf.org; Fri, 04 May 2007 02:29:35 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjrIL-0000wZ-Qf for nsis@ietf.org; Fri, 04 May 2007 02:29:35 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 61AEF13CF81 for ; Fri, 4 May 2007 08:29:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) To: nsis Message-Id: <12588BAE-5DCD-40BF-958E-2825E572758E@netlab.nec.de> From: Martin Stiemerling Date: Fri, 4 May 2007 08:29:30 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [NSIS] WGLC for GIST ended May 2nd 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="===============1892180034==" Errors-To: nsis-bounces@ietf.org --===============1892180034== Content-Type: multipart/alternative; boundary=Apple-Mail-37-236991540 --Apple-Mail-37-236991540 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi all, The WGLC for GIST (draft-ietf-nsis-ntlp-13.txt) has ended on May 2nd. There have been multiple WG members sending their comments and mainly editorial issues have been identified. The general consensus was that draft-ietf-nsis-ntlp-13.txt is ready for the IESG review. Robert and Henning will prepare an updated version after the NSIS interop (taking place in the next week in Karlsruhe, Germany), as far as I know. This version will address the comments received and comments from the implementers, if found at the interop. Thanks to all for their work Martin stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-37-236991540 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

The WGLC for GIST = (draft-ietf-nsis-ntlp-13.txt) has ended on May 2nd.=A0

There have been multiple WG = members sending their comments and mainly editorial issues have been = identified. The general consensus was that=A0draft-ietf-nsis-ntlp-13.txt = is ready for the IESG review.=A0

Robert and Henning will = prepare an updated version after the NSIS interop (taking place in the = next week in Karlsruhe, Germany), as far as I know. This version will = address the comments received and comments from the implementers, if = found at the interop.

Thanks to all for their = work

=A0 = Martin

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-37-236991540-- --===============1892180034== 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 --===============1892180034==-- From nsis-bounces@ietf.org Mon May 07 03:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxSr-0001oX-9j; Mon, 07 May 2007 03:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkxSp-0001oJ-Gl; Mon, 07 May 2007 03:16:55 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkxSo-0006Hw-8L; Mon, 07 May 2007 03:16:55 -0400 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HkxSl-0004VC-U8; Mon, 07 May 2007 09:16:53 +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 98FD02FC097; Mon, 7 May 2007 09:16:51 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HkxSl-0007Bf-AX; Mon, 07 May 2007 09:16:51 +0200 Message-ID: <463ED262.30105@tm.uka.de> Date: Mon, 07 May 2007 09:16:50 +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: "nsis@ietf.org" , nsis-imp@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [NSIS] NSIS Interop Remote participation 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, if you're interested in participating the NSIS interop, but could not manage to get here, you may consider to participate remotely. If you are interested to do so, please mail me. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 14 03:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnV5Y-0002tp-7W; Mon, 14 May 2007 03:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnV5X-0002tk-BC for nsis@ietf.org; Mon, 14 May 2007 03:35:23 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnV5U-0001iL-UJ for nsis@ietf.org; Mon, 14 May 2007 03:35:23 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1HnV5S-00059s-9T for ; Mon, 14 May 2007 09:35:20 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1HnV5R-00005Y-VK; Mon, 14 May 2007 09:35: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 235922FC097 for ; Mon, 14 May 2007 09:35:17 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1HnV5Q-0007IV-SD for nsis@ietf.org; Mon, 14 May 2007 09:35:16 +0200 Message-ID: <46481134.5030509@tm.uka.de> Date: Mon, 14 May 2007 09:35:16 +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: "nsis@ietf.org" X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [NSIS] NSIS Interop in Karlsruhe - Feedback 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, just as a short feedback: we had a very successful interop in Karlsruhe. We mainly concentrated on GIST and thanks to Christian we had many good test cases we could automatically run. He did a terrific job in defining test cases and in providing automated tools to let the tests run. This saved a considerable amount of time. Thanks also to Roke for the latest dissector code! All in all I would say that we had three independent interoperable implementations and that the GIST main functions worked quite well. We will come back with a more detailed report about that. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 24 05:59:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrA66-0002q4-N5; Thu, 24 May 2007 05:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrA65-0002ou-MO for nsis@ietf.org; Thu, 24 May 2007 05:59:05 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrA64-0004I9-1x for nsis@ietf.org; Thu, 24 May 2007 05:59:05 -0400 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 88D1D13CF81; Thu, 24 May 2007 11:59:00 +0200 (CEST) In-Reply-To: <46481134.5030509@tm.uka.de> References: <46481134.5030509@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <60D62E28-4766-4B86-8AD3-2F6CDEDDAEB4@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] NSIS Interop in Karlsruhe - Feedback Date: Thu, 24 May 2007 11:58:58 +0200 To: nsis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Roland Bless 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="===============1267443480==" Errors-To: nsis-bounces@ietf.org --===============1267443480== Content-Type: multipart/alternative; boundary=Apple-Mail-34--169924671 --Apple-Mail-34--169924671 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear implementers, Once again thanks of lot for doing the NSIS interop test! Especially thanks to Roland for hosting the meeting in Karlsruhe! It would be good to get the interop results in a written form rather soon, so that we have record of what has been tested and how the result are. Do you have any idea when the report is ready? Thanks Martin Am 14.05.2007 um 09:35 schrieb Roland Bless: > Hi all, > > just as a short feedback: > we had a very successful interop in Karlsruhe. > We mainly concentrated on GIST and thanks to Christian > we had many good test cases we could automatically > run. He did a terrific job in defining test cases and > in providing automated tools to let the tests run. > This saved a considerable amount of time. Thanks also > to Roke for the latest dissector code! > All in all I would say that we had three independent > interoperable implementations and that the GIST main > functions worked quite well. We will come back with a > more detailed report about that. > > Regards, > Roland > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-34--169924671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear implementers,

Once again thanks of lot = for doing the NSIS interop test! Especially thanks to Roland for hosting = the meeting in Karlsruhe!

It would be good to get the = interop results in a written form rather soon, so that we have record of = what has been tested and how the result are. Do you have any idea when = the report is ready?

Thanks

=A0 = Martin

Am 14.05.2007 um 09:35 schrieb Roland = Bless:

Hi all,

just as = a short feedback:
we had a very successful interop = in Karlsruhe.
We mainly concentrated on GIST = and thanks to Christian
we had many = good test cases we could automatically
run. He = did a terrific job in defining test cases and
in providing automated tools to let the tests = run.
This saved a considerable amount = of time. Thanks also
to Roke for the latest = dissector code!
All in all I would say that we = had three independent
interoperable = implementations and that the GIST main
more detailed report about that.

=A0Roland

nsis mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-34--169924671-- --===============1267443480== 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 --===============1267443480==-- From nsis-bounces@ietf.org Tue May 29 11:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3Xd-00083f-Cf; Tue, 29 May 2007 11:23:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3Xc-00083a-BP for nsis@ietf.org; Tue, 29 May 2007 11:23:20 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht3XZ-0003B5-C4 for nsis@ietf.org; Tue, 29 May 2007 11:23:20 -0400 Received: by wa-out-1112.google.com with SMTP id m16so879178waf for ; Tue, 29 May 2007 08:23:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=F/B+ndRU9lDqTUhC+8DZwmSJ7ROFxgMT9nRNEKBUjK0H+dCAY7FQAYSPEVIYDAsHMjgdBCwZcE2fde6qYGp2epOKWOwWeCCFz2O2S0MvJEZXv6aJBtrPGScNsgeVZwd79gKAVr7P38wPhlp8662HblY2+SbgM1xpsW+sg6fo7IU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YTC21kNL06t7mVyaq6vc/vtwhBL0XUmNp/dZ8N4cUsmpIeGBc1viFw11YJC7cTInPM6MA1876lOBkb+z0JUMm0gdorjC4D6iny/zxuq03X6QQpONfbKBOZGdRfblm6cjz/WpiwPxe2vqY6huSUejplZdpZeZc05Mto0b4anOyvs= Received: by 10.114.168.1 with SMTP id q1mr3469276wae.1180452196334; Tue, 29 May 2007 08:23:16 -0700 (PDT) Received: by 10.114.195.13 with HTTP; Tue, 29 May 2007 08:23:16 -0700 (PDT) Message-ID: Date: Tue, 29 May 2007 11:23:16 -0400 From: "Ajay Kumar Todimala" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [NSIS] kom-rsvp on MAC OS X 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="===============0909825513==" Errors-To: nsis-bounces@ietf.org --===============0909825513== Content-Type: multipart/alternative; boundary="----=_Part_214836_4181000.1180452196280" ------=_Part_214836_4181000.1180452196280 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks, I am trying to build kom-rsvp, an implementation of RSVP protocol. I built it on a Linux box. I was wondering if any of you folks has tried to build it on MAC OS X. Does the current version of kom-rsvp has support to build it on MAC? Your help/comments will be greatly appreciated. Thanks, Ajay. ------=_Part_214836_4181000.1180452196280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Folks,

I am trying to build kom-rsvp, an implementation of RSVP protocol.
I built it on a Linux box. I was wondering if any of you folks has tried to build it on
MAC OS X. Does the current version of kom-rsvp has support to build it on MAC?

Your help/comments will be greatly appreciated.

Thanks,
Ajay.
------=_Part_214836_4181000.1180452196280-- --===============0909825513== 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 --===============0909825513==-- From nsis-bounces@ietf.org Tue May 29 11:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3bq-00028Q-Ey; Tue, 29 May 2007 11:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3bo-00028H-J1 for nsis@ietf.org; Tue, 29 May 2007 11:27:40 -0400 Received: from services110.cs.uwaterloo.ca ([129.97.152.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht3bn-0003q8-9f for nsis@ietf.org; Tue, 29 May 2007 11:27:40 -0400 Received: from [129.97.34.33] (kalli.uwaterloo.ca [129.97.34.33]) (authenticated bits=0) by services110.cs.uwaterloo.ca (8.13.8/8.13.8) with ESMTP id l4TFRYE4019075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2007 11:27:35 -0400 (EDT) Message-ID: <465C4666.6020102@cs.uwaterloo.ca> Date: Tue, 29 May 2007 11:27:34 -0400 From: Martin Karsten User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Ajay Kumar Todimala Subject: Re: [NSIS] kom-rsvp on MAC OS X References: In-Reply-To: X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at mailchk-m04 with ID 465C4666.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on localhost X-Virus-Status: Clean X-UUID: 2d1ad486-699f-4382-b982-bc5859ab9e68 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 I don't think that nsis folks appreciate rsvp-impl traffic on this list... ;-) Anyway, last time I checked (many years ago though), it built on MAC without problems, except that the signal interface was slightly different. Search for __APPLE__ in the source code. However, C++ compilers have evolved and catch a lot more questionable C++ statements in the code now, so that may also lead to compilation problems. The software is just getting old... Good luck, Martin Ajay Kumar Todimala wrote: > Hello Folks, > > I am trying to build kom-rsvp, an implementation of RSVP protocol. > I built it on a Linux box. I was wondering if any of you folks has tried > to build it on > MAC OS X. Does the current version of kom-rsvp has support to build it > on MAC? > > Your help/comments will be greatly appreciated. > > Thanks, > Ajay. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 May 29 17:31:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9IF-0005SS-Ty; Tue, 29 May 2007 17:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9IF-0005SI-6O for nsis@ietf.org; Tue, 29 May 2007 17:31:51 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht9IB-0006Aq-Si for nsis@ietf.org; Tue, 29 May 2007 17:31:51 -0400 Received: from s4.ifi.informatik.uni-goettingen.de ([134.76.81.226] helo=smtp.stud.informatik.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.66) (envelope-from ) id 1Ht9IA-00018g-8E for nsis@ietf.org; Tue, 29 May 2007 23:31:46 +0200 Received: from [192.168.0.21] (p5484afa0.dip0.t-ipconnect.de [84.132.175.160]) by smtp.stud.informatik.uni-goettingen.de (Postfix) with ESMTP for ; Tue, 29 May 2007 23:31:43 +0200 (CEST) Message-ID: <465C9BAE.1050505@cs.uni-goettingen.de> Date: Tue, 29 May 2007 23:31:26 +0200 From: Bernd Schloer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 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-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] smallest path MTU - Maximum Packet Size [M] 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, in version 13 of the QSPEC-draft the Maximum Packet Size [M] was removed from the TMOD parameter (former Traffic parameter). RFC2211 mentions, that links are not permitted to fragment packets which receive the controlled-load service and packets larger than the MTU of the link are treated as non-conformant to the TSPEC. What was the reason to omit this parameter? Best regards, Bernd _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 30 05:54:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKst-000431-C3; Wed, 30 May 2007 05:54:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKss-00042w-7L for nsis@ietf.org; Wed, 30 May 2007 05:54:26 -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 1HtKsq-000094-U2 for nsis@ietf.org; Wed, 30 May 2007 05:54:26 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 30 May 2007 12:54:23 +0300 id 0008009A.465D49CF.00005E37 Date: Wed, 30 May 2007 12:54:23 +0300 (EEST) From: Jukka MJ Manner To: NSIS Working Group 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: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [NSIS] QoS NSLP final fixes for v.14 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, Here are the changes I have done to QoS NSLP spec. If I have missed some comment, please forgive me, and send it again. There is still the question of the abstract API. The current version is (very) complex, and one proposal was to divide it into a simple API, and a more powerful API (mainly for those inter-intra domain cases). The changes: 1. Added Protocol Error: 0x0f - Incompatible QSPEC (From Jerry & Andrew, Mar 14) 2. Moved Break-flag from message-specific flags to Generic Flags in the Common Header. (Suggested by Roland, Mar 21) 3. To support pre-emption mechanisms in QOSMs, we have added: * RESERVE and QUERY should be able to carry an INFO_SPEC object * BOUND_SESSION_ID that indicates the session that caused the pre-emption. Note that the value of this BOUND_SESSION_ID will have a new Binding Code value, which will have to be specified in the QOS-NSLP. and the section below: 4.2.12. Pre-emption The QoS NSLP provides building blocks to implement pre-emption. This specification does not define how pre-emption should work, but only provides signaling mechanisms that can be used by QoS Models. For example, an INFO_SPEC object can be added to messages to indicate that the signaled session was pre-empted. A BOUND_SESSION_ID object can carry the Session ID of the flow that caused the pre-emption to happen for the signaled session. How these are used by QoS Models is out of scope of the QoS NSLP specification. When do we start WGLC? Regards, Jukka ps. By far the biggest change was to move from good-old nroff to xml... took a while. ;) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 31 06:03:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HthVb-0006RQ-90; Thu, 31 May 2007 06:03:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HthVa-0006RL-D4 for nsis@ietf.org; Thu, 31 May 2007 06:03:54 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HthVZ-0001ds-Lj for nsis@ietf.org; Thu, 31 May 2007 06:03:54 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1BAD313CF82; Thu, 31 May 2007 12:03:53 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <57034164-6352-4A8B-892D-2F64BFF7F80D@netlab.nec.de> From: Martin Stiemerling Subject: Re: [NSIS] QoS NSLP final fixes for v.14 Date: Thu, 31 May 2007 12:03:53 +0200 To: Jukka MJ Manner X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: NSIS Working Group 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="===============1111471693==" Errors-To: nsis-bounces@ietf.org --===============1111471693== Content-Type: multipart/alternative; boundary=Apple-Mail-22-435170764 --Apple-Mail-22-435170764 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Jukka, Can you post an updated draft soon? We can run the WGLC with the new draft. Any thoughts from the WG about the API? Thanks, Martin Am 30.05.2007 um 11:54 schrieb Jukka MJ Manner: > > Dear all, > > Here are the changes I have done to QoS NSLP spec. If I have missed > some > comment, please forgive me, and send it again. > > There is still the question of the abstract API. The current > version is > (very) complex, and one proposal was to divide it into a simple > API, and a > more powerful API (mainly for those inter-intra domain cases). > > The changes: > > 1. > > Added Protocol Error: > > 0x0f - Incompatible QSPEC > (From Jerry & Andrew, Mar 14) > > 2. > > Moved Break-flag from message-specific flags to Generic Flags in the > Common Header. > (Suggested by Roland, Mar 21) > > 3. > > To support pre-emption mechanisms in QOSMs, we have added: > > * RESERVE and QUERY should be able to carry an INFO_SPEC object > > * BOUND_SESSION_ID that indicates the session that caused the > pre-emption. Note that the value of this BOUND_SESSION_ID will have a > new Binding Code value, which will have to be specified in the QOS- > NSLP. > > and the section below: > > 4.2.12. Pre-emption > > The QoS NSLP provides building blocks to implement pre-emption. > This > specification does not define how pre-emption should work, but only > provides signaling mechanisms that can be used by QoS Models. For > example, an INFO_SPEC object can be added to messages to indicate > that the signaled session was pre-empted. A BOUND_SESSION_ID > object > can carry the Session ID of the flow that caused the pre-emption to > happen for the signaled session. How these are used by QoS > Models is > out of scope of the QoS NSLP specification. > > > > When do we start WGLC? > > > Regards, > Jukka > > ps. By far the biggest change was to move from good-old nroff to > xml... > took a while. ;) > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-22-435170764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Jukka,

Can you post an updated = draft soon? We can run the WGLC with the new draft.=A0

Any thoughts from the WG = about the API?

Thanks,
=A0
=A0Martin

Am 30.05.2007 um 11:54 schrieb = Jukka MJ Manner:


Dear all,

Here are the changes I have done = to QoS NSLP spec. If I have missed some=A0
comment, = please forgive me, and send it again.

There is = still the question of the abstract API. The current version is=A0
(very) = complex, and one proposal was to divide it into a simple API, and a=A0
more = powerful API (mainly for those inter-intra domain cases).

The = changes:

1.
Added Protocol Error:

0x0f - = Incompatible QSPEC
(=46rom Jerry & Andrew, = Mar 14)

2.=A0

Moved = Break-flag from message-specific flags to Generic Flags in the
Common Header.
(Suggested by = Roland, Mar 21)

3.=A0

To support = pre-emption mechanisms in QOSMs, we have added:

* = RESERVE and QUERY should be able to carry an INFO_SPEC object

* = BOUND_SESSION_ID that indicates the session that caused the
pre-emption. Note that the value of this = BOUND_SESSION_ID will have a
new Binding = Code value, which will have to be specified in the QOS-NSLP.

and the = section below:

4.2.12.=A0 = Pre-emption
=A0=A0 The QoS NSLP provides = building blocks to implement pre-emption.=A0 This
=A0=A0 = specification does not define how pre-emption should work, but = only
=A0=A0 provides signaling = mechanisms that can be used by QoS Models.=A0 For
=A0=A0 = example, an INFO_SPEC object can be added to messages to = indicate
=A0=A0 that the signaled session = was pre-empted.=A0 A = BOUND_SESSION_ID object
=A0=A0 can carry the Session ID = of the flow that caused the pre-emption to
=A0=A0 happen for the signaled = session.=A0 How these are = used by QoS Models is
=A0=A0 out of scope of the QoS = NSLP specification.


When do = we start WGLC?


Jukka

ps. By = far the biggest change was to move from good-old nroff to xml...=A0
took a = while. ;)

nsis mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-22-435170764-- --===============1111471693== 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 --===============1111471693==-- From nsis-bounces@ietf.org Thu May 31 06:21:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HthmL-0008SB-V4; Thu, 31 May 2007 06:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HthmK-0008Rr-Co for nsis@ietf.org; Thu, 31 May 2007 06:21:12 -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 1HthmI-00083Q-P8 for nsis@ietf.org; Thu, 31 May 2007 06:21:12 -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; Thu, 31 May 2007 13:21:09 +0300 id 0008013A.465EA195.000062A4 Date: Thu, 31 May 2007 13:21:09 +0300 (EEST) From: Jukka MJ Manner To: Martin Stiemerling Subject: Re: [NSIS] QoS NSLP final fixes for v.14 In-Reply-To: <57034164-6352-4A8B-892D-2F64BFF7F80D@netlab.nec.de> Message-ID: References: <57034164-6352-4A8B-892D-2F64BFF7F80D@netlab.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: NSIS Working Group 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 can post the draft at any time. As said, it still lacks a new API. Jukka On Thu, 31 May 2007, Martin Stiemerling wrote: > Hi Jukka, > > Can you post an updated draft soon? We can run the WGLC with the new draft. > > Any thoughts from the WG about the API? > > Thanks, > > Martin > > Am 30.05.2007 um 11:54 schrieb Jukka MJ Manner: > > > > >Dear all, > > > >Here are the changes I have done to QoS NSLP spec. If I have missed some > >comment, please forgive me, and send it again. > > > >There is still the question of the abstract API. The current version is > >(very) complex, and one proposal was to divide it into a simple API, and a > >more powerful API (mainly for those inter-intra domain cases). > > > >The changes: > > > >1. > > > >Added Protocol Error: > > > >0x0f - Incompatible QSPEC > >(From Jerry & Andrew, Mar 14) > > > >2. > > > >Moved Break-flag from message-specific flags to Generic Flags in the > >Common Header. > >(Suggested by Roland, Mar 21) > > > >3. > > > >To support pre-emption mechanisms in QOSMs, we have added: > > > >* RESERVE and QUERY should be able to carry an INFO_SPEC object > > > >* BOUND_SESSION_ID that indicates the session that caused the > >pre-emption. Note that the value of this BOUND_SESSION_ID will have a > >new Binding Code value, which will have to be specified in the QOS-NSLP. > > > >and the section below: > > > >4.2.12. Pre-emption > > > > The QoS NSLP provides building blocks to implement pre-emption. This > > specification does not define how pre-emption should work, but only > > provides signaling mechanisms that can be used by QoS Models. For > > example, an INFO_SPEC object can be added to messages to indicate > > that the signaled session was pre-empted. A BOUND_SESSION_ID object > > can carry the Session ID of the flow that caused the pre-emption to > > happen for the signaled session. How these are used by QoS Models is > > out of scope of the QoS NSLP specification. > > > > > > > >When do we start WGLC? > > > > > >Regards, > >Jukka > > > >ps. By far the biggest change was to move from good-old nroff to xml... > >took a while. ;) > > > >_______________________________________________ > >nsis mailing list > >nsis@ietf.org > >https://www1.ietf.org/mailman/listinfo/nsis > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 > 6BL | Registered in England 2832014 > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 31 15:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqSi-0005ou-Gp; Thu, 31 May 2007 15:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqSh-0005oo-Dh for nsis@ietf.org; Thu, 31 May 2007 15:37:31 -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 1HtqSg-0001Ps-4v for nsis@ietf.org; Thu, 31 May 2007 15:37:31 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 31 May 2007 22:37:29 +0300 id 0008C947.465F23F9.000017CD Date: Thu, 31 May 2007 22:37:29 +0300 (EEST) From: Jukka MJ Manner To: NSIS Working Group 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] QoS NSLP Abstract API: feedback wanted 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, The last thing before a WGLC is to specify the abstract API for the QoS NSLP. The current spec has our initial proposal, which after a fresh re-read looks quite ok to me. Maybe some examples on the usage would help clarify the operation but in general the API looks quite good. What do people feel? Is the abstract and informational API good enough at this stage to go for WGLC? Or do we want to change it in some way? Regards, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis