Re: Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02
Ben, Apologies for missing your additional questions. Please see below for a response. Best regards, Matthew From: Ben Campbell b...@nostrum.com To: Bocci, Matthew (Matthew) matthew.bo...@alcatel-lucent.com Reply-to: b...@nostrum.com Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-tp-uni-nni-02 X-RSN: 1/0/933/9723/54927 Thanks for the quick response. Also see below. I elided sections that I think have been addressed. On Dec 22, 2010, at 5:44 AM, Bocci, Matthew (Matthew) wrote: Ben, Thank you for your comments. Please see below. Best regards Matthew On 21/12/2010 22:13, Ben Campbell b...@nostrum.com wrote: [...] -- Section 1.1, 1st paragraph: More conventional in what context? Useful for what purpose? It is the convention to represent a UNI or NNI as a specific reference point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or ATM UNI (ITU-T I.413), rather than to represent these as a span as in the original diagrams in RFC5921. I propose to rephrase this sentence to: However, it is convention to illustrate these interfaces as reference points. With regard to your second question, I propose to rephrase the sentence as follows: Furthermore, in the case of a UNI, it is useful to illustrate the distribution of UNI functions between the Customer Edge (CE) side and the Provider Edge (PE) side of the UNI (the UNI-C and UNI-N) in order to show their relationship to one another. WFM -- Figures 1 and 2: Is the meaning of the various line types described elsewhere? If so, a statement to that effect with a reference would be helpful. We have used the same convention as RFC5921. However, there is no key there. I am not sure that a complete key would clarify the diagram as the same line type is used to represent multiple entities due to the limited umber of characters that are useful for ASCII drawing. Ah, I agree it probably would be too much to add a complete key, and on re-reading, I see most of the lines are sufficiently labeled. But I am still confused by a few of them. For example, in under the UNI column, I see both a single and double dashed (equal signs) line under the label of Client Traffic Flows. Should I assume those to just be two arbitrary flows where the line type just helps me follow a particular flow, or are they somehow different classes of flows? MB They are just flows belonging to arbitrary transport service instances, and helps the reader to follow the path of the flow. On the right side of the same diagram, I see 3 Transport Paths with an outer set of arrows, and the lower two having another arrow between. Should the outer arrows be interpreted as a channel over which client traffic flows? MB The outer arrows are supposed to look like two sides of a tunnel (the transport path) other which the transport service instance (TSI) is transported. -- Figure 2: I suggest expanding CP somewhere. CP is expanded in the terminology section. So it is, right there at the top. (I could have sworn I did a text search for that--looks like the search option in the iPad tool I use for reviewing drafts is not reliable :-|) On 22/12/2010 11:44, Bocci, Matthew (Matthew) matthew.bo...@alcatel-lucent.com wrote: Ben, Thank you for your comments. Please see below. Best regards Matthew On 21/12/2010 22:13, Ben Campbell b...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-tp-uni-nni-02 Reviewer: Ben Campbell Review Date: 2010-12-21 IETF LC End Date: 2010-12-23 IESG Telechat date: (if known) Summary: This draft is ready for publication as in informational RFC. I have a small number of editorial comments that I think could further improve the draft if there is another round of editing. Major issues: None Minor issues: None Nits/editorial comments: -- Section 1, 1st paragraph: I suggest moving the expansion of MPLS-TP TP the first mention in the body of the draft. OK. I have moved this to the first use of the acronym in that section. -- Section 1.1, 1st paragraph: More conventional in what context? Useful for what purpose? It is the convention to represent a UNI or NNI as a specific reference point between functional groups e.g. MEF E-NNI (Figure 2 of MEF26) or ATM UNI (ITU-T I.413), rather than to represent these as a span as in the original diagrams in RFC5921. I propose to rephrase this sentence to: However, it is convention to illustrate these interfaces as reference points. With regard to your second question, I propose to rephrase the sentence as follows: Furthermore, in the case of a UNI, it is useful to illustrate the distribution of UNI functions between the Customer Edge (CE) side and the Provider
Re: Change control
At 14:58 19-01-11, Donald Eastlake wrote: It depends. That's why there are different versions of the boilerplate depending on what rights the submitter is granting to the IETF. I'll reproduce the notice for completeness: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. I gather that an IETF Submission with the above notice allows the IETF to have change control on the work. Generally, yes. There's nothing wrong is such discussion if there appears to be a WG consensus to do so. You refer to this hypothetical submission as a work, which is a technically correct copyright term, but I believe you are thinking of it as a standards specification or a part of or an amendment to such a specification. But it can just be that the submitter wanted to use the draft format as a convenient way to make a statement to the WG, presumably a statement relevant to what the WG is doing. In such a case, the whole point would be consideration and, if appropriate, discussion of that statement in the WG. I was thinking of it in terms of work, BCP 78 and BCP 79. Thanks for providing a better perspective. It depends. That's why there are different versions of the boilerplate. If the submitter has denied the IETF permission to produce derivative works, then it seems improper to attempt to adopt that draft as a WG draft. That's because being a WG draft implies WG change control. However, the ideas in the draft could be used in a WG draft. At 15:46 19-01-11, Phillip Hallam-Baker wrote: I generally reserve change control over non WG IDs because I have experienced people hijacking a draft, changing the principles entirely and adding their name. Since there is an explicit allowance for that in the IPR regime, I don't see why this would be an issue. Some people post drafts with the notice quoted above. They have not given any thought to the explicit allowance and end up being unhappy when they are asked to give up control. The first case (see my previous message) wasn't a pleasant situation. At 18:43 19-01-11, Martin Rex wrote: That's how I understand the second paragraph here: http://tools.ietf.org/html/bcp78#page-7 Yes. For what it's worth, there was a case where changes to the SDO specification, which was not an IETF Submission, are only accepted from members of the SDO. There is a parallel with the IETF here as Contributions require acceptance of the Note Well, i.e. changes are only accepted from IETF participants. While the inclusion of the respective Copyright boilerplate by the author in the the submission is technically sufficient, I would consider it a courtesy to ask the original author for consent anyway, especially if it is about a new I-D (rather than an older RFC). Agreed. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
At 07:56 14-01-11, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'about' URI scheme' draft-holsten-about-uri-scheme-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the There is a IANA registration in Section 8. The arguments at http://www.ietf.org/mail-archive/web/ietf/current/msg65163.html are also applicable to draft-holsten-about-uri-scheme-06. In Section 5.2: Applications MAY resolve any unreserved about URI to any resource, either internal or external, or redirect to an alternative URI. What happens when the unreserved about URI becomes a reserved about URI in future? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Change control
To be honest, I'm not even clear on what the issue is. If an organization creates a BCP in its own context based on the experiences of its constituents, and then the IETF uses that material to inform its own BCP on the same subject, and reasonable permission and attribution are given, what constitutes change control? The IETF controls its version, and the other organization controls its own. For example, OpenBSD was forked from NetBSD. Who now has change control? Does that even mean anything? Apart from copyright matters, I think the only problem arises when there's debate over whose version is the official one. But that's a matter of the perception that exists outside of the two organizations. Otherwise, aren't they merely two perspectives on the same subject matter, and that's that? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Change control
That is why I really want to see a specific example of harm (which I note SM has refused to do). This is the sort of case where it is very easy to make the wrong decision if people are allowed to waffle on about what they imagine to be high principle when the rules were made the way they are to support important real world requirements. If we are to discuss this further, I want to see an example. eom On Thu, Jan 20, 2011 at 3:53 PM, Murray S. Kucherawy m...@cloudmark.comwrote: To be honest, I'm not even clear on what the issue is. If an organization creates a BCP in its own context based on the experiences of its constituents, and then the IETF uses that material to inform its own BCP on the same subject, and reasonable permission and attribution are given, what constitutes change control? The IETF controls its version, and the other organization controls its own. For example, OpenBSD was forked from NetBSD. Who now has change control? Does that even mean anything? Apart from copyright matters, I think the only problem arises when there's debate over whose version is the official one. But that's a matter of the perception that exists outside of the two organizations. Otherwise, aren't they merely two perspectives on the same subject matter, and that's that? -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Change control
The only thing I can dream up (without an example) is that the submitting organization's version of something and the IETF's version end up diverging, and the submitting organization doesn't like that. To wit, the submitting organization wanted the added credibility of the RFC label without any substantive changes to the material. But that strikes me as a failure of due diligence more than anything. Caveat emptor. From: Phillip Hallam-Baker [mailto:hal...@gmail.com] Sent: Thursday, January 20, 2011 1:16 PM To: Murray S. Kucherawy Cc: ietf@ietf.org Subject: Re: Change control That is why I really want to see a specific example of harm (which I note SM has refused to do). This is the sort of case where it is very easy to make the wrong decision if people are allowed to waffle on about what they imagine to be high principle when the rules were made the way they are to support important real world requirements. If we are to discuss this further, I want to see an example. eom On Thu, Jan 20, 2011 at 3:53 PM, Murray S. Kucherawy m...@cloudmark.commailto:m...@cloudmark.com wrote: To be honest, I'm not even clear on what the issue is. If an organization creates a BCP in its own context based on the experiences of its constituents, and then the IETF uses that material to inform its own BCP on the same subject, and reasonable permission and attribution are given, what constitutes change control? The IETF controls its version, and the other organization controls its own. For example, OpenBSD was forked from NetBSD. Who now has change control? Does that even mean anything? Apart from copyright matters, I think the only problem arises when there's debate over whose version is the official one. But that's a matter of the perception that exists outside of the two organizations. Otherwise, aren't they merely two perspectives on the same subject matter, and that's that? -MSK ___ Ietf mailing list Ietf@ietf.orgmailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
I agree with SM's concern that the mechanism by which this is extended is underspecified. The draft contains one reserved token, blank, and a set of examples which make clear that there is an unwritten set of known and unknown tokens which populate the segment portion of the given ABNF. Providing a registry for those tokens, possibly with simple reserved status if no specification exists, might help. Standardizing a method for querying what about: tokens are available in a specific context might as well (about:about, for example, or about:?about). But the reality is that the behavior resulting from these URIs is totally non-deterministic and varies from context to context. In most contexts outside of a browser location bar, they are meaningless. Inside that context, the browser's definition seems to be definitive. If the aim is only to get about:blank fully specified, I'd suggest saying so outright, and noting clearly that all other uses are context-dependent, with returning about:blank recommended practice for those unknown. As a thought experiment, would the W3C counsel against the presence of an about URI in an XML namespace? Additionally, naming a change controller should generally be a bit more precise than an organization name. The W3C director or TAG seems more appropriate than just W3C. regards, Ted Hardie On Thu, Jan 20, 2011 at 11:18 AM, SM s...@resistor.net wrote: At 07:56 14-01-11, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'about' URI scheme' draft-holsten-about-uri-scheme-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the There is a IANA registration in Section 8. The arguments at http://www.ietf.org/mail-archive/web/ietf/current/msg65163.html are also applicable to draft-holsten-about-uri-scheme-06. In Section 5.2: Applications MAY resolve any unreserved about URI to any resource, either internal or external, or redirect to an alternative URI. What happens when the unreserved about URI becomes a reserved about URI in future? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 83 Venue
At 03:31 PM 1/19/2011, IETF Administrative Director wrote: The IAOC is pleased to announce Paris as the site for IETF 83 from 25 - 30 March 2012. The IETF last met in the city in 2005 at IETF 63. Paris was the number one choice for a European venue in a venue preference survey conducted after IETF 78. I don't know about this... after all, the last time we had an IETF there is when EKR blew a gasket at the lack of (real) cookies during the breaks. This cannot be overlooked as an isolated incident, or hand-waved away. I wouldn't want to be around him if this were to occur again. ;-) James 2012 IETF 83 Paris 25 - 30 MarchHost: your name here ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 73 messages in the last 7 days. script run at: Fri Jan 21 00:53:02 EST 2011 Messages | Bytes| Who +--++--+ 13.70% | 10 | 16.89% | 108644 | hal...@gmail.com 8.22% |6 | 11.13% |71600 | lars.egg...@nokia.com 2.74% |2 | 12.02% |77333 | j...@cisco.com 5.48% |4 | 3.00% |19280 | julian.resc...@gmx.de 4.11% |3 | 2.93% |18861 | s...@resistor.net 4.11% |3 | 2.86% |18371 | daedu...@btconnect.com 4.11% |3 | 2.69% |17312 | m...@sap.com 4.11% |3 | 2.31% |14854 | dwor...@avaya.com 1.37% |1 | 4.66% |29945 | ron.even@gmail.com 2.74% |2 | 3.12% |20038 | m...@cloudmark.com 2.74% |2 | 2.69% |17290 | o...@nlnetlabs.nl 2.74% |2 | 1.58% |10179 | d...@ewellic.org 2.74% |2 | 1.52% | 9808 | ves...@tana.it 1.37% |1 | 2.36% |15165 | krishnabi...@gmail.com 1.37% |1 | 2.21% |14246 | jma...@gmail.com 1.37% |1 | 2.11% |13568 | li...@cs.ucla.edu 1.37% |1 | 1.97% |12698 | spen...@wonderhamster.org 1.37% |1 | 1.57% |10074 | matthew.bo...@alcatel-lucent.com 1.37% |1 | 1.37% | 8834 | l...@cisco.com 1.37% |1 | 1.32% | 8505 | t...@americafree.tv 1.37% |1 | 1.22% | 7834 | nar...@us.ibm.com 1.37% |1 | 1.19% | 7658 | chris.dearl...@baesystems.com 1.37% |1 | 1.09% | 6994 | ted.i...@gmail.com 1.37% |1 | 1.02% | 6569 | xavier.mar...@gmail.com 1.37% |1 | 0.99% | 6362 | d3e...@gmail.com 1.37% |1 | 0.95% | 6105 | evniki...@gmail.com 1.37% |1 | 0.93% | 5991 | jh...@cmu.edu 1.37% |1 | 0.90% | 5786 | d...@dcrocker.net 1.37% |1 | 0.84% | 5407 | ned+i...@mauve.mrochek.com 1.37% |1 | 0.84% | 5384 | e...@abenaki.wabanaki.net 1.37% |1 | 0.83% | 5316 | p...@xelerance.com 1.37% |1 | 0.82% | 5301 | marc.blanc...@viagenie.ca 1.37% |1 | 0.82% | 5246 | ch...@ietf.org 1.37% |1 | 0.81% | 5241 | paul.hoff...@vpnc.org 1.37% |1 | 0.81% | 5217 | mic...@krsek.cz 1.37% |1 | 0.77% | 4924 | alexey.melni...@isode.com 1.37% |1 | 0.76% | 4874 | bmann...@isi.edu 1.37% |1 | 0.74% | 4773 | ero...@cisco.com 1.37% |1 | 0.70% | 4510 | jab...@hopcount.ca 1.37% |1 | 0.70% | 4506 | jmp...@cisco.com 1.37% |1 | 0.69% | 4452 | iljit...@muada.com 1.37% |1 | 0.69% | 4423 | d...@dotat.at 1.37% |1 | 0.59% | 3769 | i...@ietf.org +--++--+ 100.00% | 73 |100.00% | 643247 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
2011/1/21, Ted Hardie ted.i...@gmail.com: I agree with SM's concern that the mechanism by which this is extended is underspecified. The draft contains one reserved token, blank, and a set of examples which make clear that there is an unwritten set of known and unknown tokens which populate the segment portion of the given ABNF. Providing a registry for those tokens, possibly with simple reserved status if no specification exists, might help. Standardizing a method for querying what about: tokens are available in a specific context might as well (about:about, for example, or about:?about). Hello all, I'd like to agree with the proposition to create the regsitry for 'about' URI tokens That will allow to track what tokens become 'reserved', 'unreserved', etc. simplier. Mykyta Yevstifeyev But the reality is that the behavior resulting from these URIs is totally non-deterministic and varies from context to context. In most contexts outside of a browser location bar, they are meaningless. Inside that context, the browser's definition seems to be definitive. If the aim is only to get about:blank fully specified, I'd suggest saying so outright, and noting clearly that all other uses are context-dependent, with returning about:blank recommended practice for those unknown. As a thought experiment, would the W3C counsel against the presence of an about URI in an XML namespace? Additionally, naming a change controller should generally be a bit more precise than an organization name. The W3C director or TAG seems more appropriate than just W3C. regards, Ted Hardie On Thu, Jan 20, 2011 at 11:18 AM, SM s...@resistor.net wrote: At 07:56 14-01-11, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The 'about' URI scheme' draft-holsten-about-uri-scheme-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the There is a IANA registration in Section 8. The arguments at http://www.ietf.org/mail-archive/web/ietf/current/msg65163.html are also applicable to draft-holsten-about-uri-scheme-06. In Section 5.2: Applications MAY resolve any unreserved about URI to any resource, either internal or external, or redirect to an alternative URI. What happens when the unreserved about URI becomes a reserved about URI in future? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6076 on Basic Telephony SIP End-to-End Performance Metrics
A new Request for Comments is now available in online RFC libraries. RFC 6076 Title: Basic Telephony SIP End-to-End Performance Metrics Author: D. Malas, A. Morton Status: Standards Track Stream: IETF Date: January 2011 Mailbox:d.ma...@cablelabs.com, acmor...@att.com Pages: 27 Characters: 61559 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pmol-sip-perf-metrics-07.txt URL:http://www.rfc-editor.org/rfc/rfc6076.txt This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK] This document is a product of the Performance Metrics for Other Layers Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6083 on Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
A new Request for Comments is now available in online RFC libraries. RFC 6083 Title: Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) Author: M. Tuexen, R. Seggelmann, E. Rescorla Status: Standards Track Stream: IETF Date: January 2011 Mailbox:tue...@fh-muenster.de, seggelm...@fh-muenster.de, e...@networkresonance.com Pages: 9 Characters: 16674 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tsvwg-dtls-for-sctp-06.txt URL:http://www.rfc-editor.org/rfc/rfc6083.txt This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK] This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6084 on General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)
A new Request for Comments is now available in online RFC libraries. RFC 6084 Title: General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) Author: X. Fu, C. Dickmann, J. Crowcroft Status: Experimental Stream: IETF Date: January 2011 Mailbox:f...@cs.uni-goettingen.de, m...@christian-dickmann.de, jon.crowcr...@cl.cam.ac.uk Pages: 12 Characters: 27040 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-nsis-ntlp-sctp-15.txt URL:http://www.rfc-editor.org/rfc/rfc6084.txt The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). This document defines an Experimental Protocol for the Internet community. This document is a product of the Next Steps in Signaling Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
