Last Call summary on draft-yevstifeyev-tn3270-uri
Hello all,
This message summarizes the Last Call on draft-yevstifeyev-tn3270-uri
(http://tools.ietf.org/id/draft-yevstifeyev-tn3270-uri-13.txt).
Firstly, some statistical information. The Last Call was requested by
Peter Saint-Andre on 4 January, 2011 and was announced on 4 January,
2011. The Last Call ends on 1 February, 2011. The LC announcement has
been sent out to IETF Discussion, uri-review and u...@w3c.org mailing
lists. A number of comments have been received during the Last Call.
The most current version - 13 - I have just uploaded is believed to
resolve them. Moreover, a number of improvements have been made to
improve the document quality.
Secondly, here is the exhaustive list of differences between the 12
version and 13 version.
/Intended status/ - did not change: Informational;
/Title/ - changed. Was *The 'tn3270' Uniform Resource Identifier
Scheme* and now is *The 'tn3270' Uniform Resource Identifier (URI)
Scheme*. I'm asking Peter to change the write0up in accordance to this.
/Abstract/ - did not change;
/Introduction/ - changed. Added the RFC 2119 boilerplate (now used
throughout the document); added the reference to IANA registry;
clarified the purpose of the document; some other minor changes.
/Scheme definition/ - changed. Splitted the designated service into
Telnet 3270 and Telnet 3270 Enchanted, added the reference to IBM
Publication GA23-0059, related to 3270 data stream; added the reference
to RFC 3049, related to TN3270E; clarified the URI syntax, as follows. Was:
The 'tn3270' URI takes the following form (given in ABNF, as
described inRFC 5234 http://tools.ietf.org/html/rfc5234 [RFC5234
http://tools.ietf.org/html/rfc5234]):
tn3270uri = tn3270: // authority [/]
The 'authority' rule is defined inRFC 3986 http://tools.ietf.org/html/rfc3986
[RFC3986 http://tools.ietf.org/html/rfc3986]. The final
character / can be omitted.
Now:
The 'tn3270' URI takes the following form (given in ABNF, as
described inRFC 5234 http://tools.ietf.org/html/rfc5234 [RFC5234
http://tools.ietf.org/html/rfc5234]):
tn3270uri = tn3270: hier-part
hier-part = // authority [/]
;the URI takes the form
;tn3270://user:password@host:port/
;that is formally defined via the 'authority'
The 'authority' rule is specified inRFC 3986
http://tools.ietf.org/html/rfc3986 [RFC3986
http://tools.ietf.org/html/rfc3986]. If 'port'
(in the 'authority' part) is omitted, it SHALL default to 21. The
final character / MAY be omitted.
/Security Considerations/ - changed. Clarified why there are no other
security considerations for 'tn3270' scheme other than the 'telnet' one has.
/IANA Considerations/ - changed. added the reference to RFC 4395;
changed the description of protocol, that uses the scheme in accordance
with Section 2; changed the Contact and author to IESG and IETF,
respectively.
/References/ - RFC 4395 is now Informative; added the references to RFC
3049, IANA registry and IBM Publication GA23-0059.
/Acknowledgments/ - corrected the typographical mistake in the last name
of Alfred Hoenes.
/Author's addresses/ - changed, clarified the address.
Lastly, during the LC the document was reviewed by IANA, GenART and
OPS-DIR Review Team. I'm citing their reviews.
IANA:
IANA understands that, upon approval of this document, there is a single
Action that IANA needs to complete.
In the URI schemes registry located at:
http://www.iana.org/assignments/uri-schemes.html
in the Provisional URI Schemes section, the follow registration will be
added:
URI Scheme: tn3270
Description: TN3270 Telnet Service
Reference: [RFC-to-be]
IANA understands that this is the only action required upon approval of
this document.
GenART:
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-yevstifeyev-tn3270-uri-12
Reviewer: Vijay K. Gurbani
Review Date: Jan-14-2011
IETF LC End Date: Feb-02-2011
IESG Telechat date: Unknown
Summary: This draft is ready as an Informational RFC.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 0
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
OPS-DIR:
-Original Message-
From:ops-dir-boun...@ietf.org [mailto:ops-dir-boun...@ietf.org] On
Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Wednesday, January 12, 2011 1:07 PM
To:ops-...@ietf.org
Cc:draft-yevstifeyev-tn3270-uri-auth...@tools.ietf.org
Subject: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12
I reviewed draft-yevstifeyev-tn3270-uri-12 for its
Review of draft-ymbk-aplusp-08
I reviewed the document draft-ymbk-aplusp-08 in general. Operations directorate and Security directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir/SecDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. - This document is well written, though there may be some nits. Comment #1: In Abstract section this draft proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address. A SOHO CPE (A+P) may provide with website service. When a host in external network accesses this website, what information that DNS servers feedback to host? If it is an IP address, it can't uniquely identify the CPE. If it is IP + port range, how can host recognize this and process? If it is IP + some a Port, how can DNS server know when port changed? Some Operators identify services by five elements include UDP/TCP well-known ports when CPE is an unreliable device. If well-known ports changed, service can't be recognized. Comment #2: Abstract section, In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. - This viewpoint is not always true. During the transition from IPv4 to IPv6, some set of operators do not want the services are affected, which may result some customers lost. A smoothly transition technology is more favorable. Comment #3: Section 1.1 says: Another issue with CGN is the trade-off between session state and network placement. - If there are too many session state to keep, two CGN or more can be placed. A distributed CGN may be a good choice. And single point of failure can be resolved Comment #4: In section 3.3.1, it says: different port-ranges can have different lifetimes, and the CPE is not entitled to use them after they expire what is the appropriate lifetime for a port-rang? When for P2P application, many ports are used. In a short-term period, when for some fixed service (e.g. site), a port may be used for many years. Will the server allocate port according application? Or else there is some security problem or port efficient allocation. For the more, port allocation will make more burdens for server because of large number s of ports and high frequency requisition. Comment #5: SMAP (stateless A+P Mapping) is proposed in section 4.1, IPv4 address and port is embedded in the IPv6 address which would be used to create a tunnel. - In section 5.2, Dynamic Allocation of Port Ranges is proposed. What if the allocated ports do not belong to a single IP address? The SMAP mechanism may not work in this case. - The IPv6 address would follow the format defined in [I-D.ietf-behave-address-format], but port is not included in the address formats defined by that draft. Any plan to define the address format? Here is the format defined in [I-D.ietf-behave-address-format]: +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |PL| 0-32--40--48--56--64--72--80--88--96--104-| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |32| prefix|v4(32) | u | suffix| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |40| prefix|v4(24) | u |(8)| suffix| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |48| prefix|v4(16) | u | (16) | suffix| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |56| prefix|(8)| u | v4(24) | suffix| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |64| prefix| u | v4(32) | suffix| +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |96| prefix|v4(32) | +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Figure 1 Comment #6: In section 5.1.2 A+P for Mobile Providers - If A+P is implemented in a terminal device, e.g. mobile phone and PC, there might be some problems, e.g. ARP problem terminal would not be able to send packets to
Re: Review of draft-ymbk-aplusp-08
Operations directorate and Security directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. and which are you? can't be ops, as you are a vendor. so security? but we already received the security review. but thanks for the review anyway. randy, a bit confused ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
+1 to the proposed rules for reclassifying DS to IS. I think they offer a reasonable balance between expediency and quality. Ned On 1/24/2011 12:37 PM, Russ Housley wrote: draft-housley-two-maturity-levels-03 was just posted. ... Overall I find this spec to be an improvement over the previous version. Here are a few areas where improvements can be made. This phrase in Section 1: In addition, IETF working groups and IESG members providing much more scrutiny than is called for by RFC 2026 [1] prior to publication as Proposed Standard. is not a sentence. Should it be provide? Should it be have been providing? Something else? The sentence in Section 1 One desired outcome is to provide an environment where the IETF community is able to publish Proposed Standards as soon as rough consensus is achieved. and these sentences in Section 2.1: The intention of the two-tier maturity ladder is to restore the requirements for Proposed Standard from RFC 2026. No new requirements are introduced; no existing published requirements are relaxed. together lay out what is required for PS. Disregarding the other arguments over the word restore, these sentences are otherwise fine and dandy. But I think there needs to be further guidance provided to the IESG and Working Groups on how they should change their behavior. What is wrong with how the WGs and IESG are currently interpreting the rules of 2026 for PS? What current behaviors differ or have gone beyond what 2026 requires, and hence need to be changed to restore those requirements? Without such guidance, nothing changes. One major section that has been removed from the previous version of this I-D is what to do with documents currently in the Draft Standard status. I know that there was significant disagreement with the automatic reclassification to Internet Standard proposed before, with good reason. I'm going to letter the the rules in section 2.2 as follows. I'm also going to indicate how these sort of map into the old classifications: a) technical maturity (DS = FS) b) belief in significant benefit to Internet community (DS = FS) c) significant number of implementations with successful operational experience (DS = FS) d) no unresolved errata (PS = DS) e) no unused features that increases implementation complexity (PS = DS) Some people have argued that having a significant number of implementations (c) is sufficient to demonstrate both technical maturity (a) and the belief in benefit (b). The (d) and (e) requirements have already been demonstrated by virtue of those RFCs already being at DS status, although additional errata may have been filed against the DS. So I'm going to suggest that the following be applied to documents that are currently in Draft Standard status: Any protocol or service that is currently in Draft Standard status, without significant unresolved errata, may be reclassified as an Internet Standard as soon as it can be demonstrated to have a significant number of implementations with successful operational experience. This reclassification may be accomplished by filing a request with the IESG, detailing the Implementation and Operational Experience. After review, the IESG will hold an IETF-wide Last Call on the reclassification. If there is consensus for the reclassification, the RFC will be reclassified without being reissued. Protocols and services that have significant unresolved errata will need to be re-issued to resolve the errata before the above criteria can be applied. Of course, there is still an open question what it means to have a significant number, which will remain as subjective as it was before with the 2026 rules. Tony Hansen t...@att.com ___ 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: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
I'm really glad to see this draft in LC at long last and it is a great improvement to the current situation - thank you to all the people that put work into this. I have two significant problems with it that I think should be resolved before being published Big Issues 1: I don't like mandating one port for secure and not secure versions of a protocol I don't think this reflects IETF consensus given the number of protocols that deliberately choses to use two ports. I also don't think that it is a good idea in all cases. I believe the decision should be left to the people designing the protocol if they want one port or two. Let me give some examples Imagine a client server protocol that runs over UDP and uses DTLS for security. The server will simultaneously serve requests over both DTLS and UDP. When the server receives a packet, it needs to be able to demux if it is a UDP packet or a DTLS packet. The obvious demux code point is the port. Yes, one might be able to reinvent a concept of a stream along with a 5 tuple and something like STARTTLS but this has many other problems. It means the client needs to use a different SRC port for each different session to the same server. This uses up NAT ports and complicates NAT traversal. It also adds additional latency to set up a small session. People just aren't going to do it. The other approach is demux based on the first byte inside the UDP packet. The CoAP protocol being developed in the CORE WG has taken that approach. The CORE WG proposed to the TLS chairs that over half the remaining code space for the TLS code point in the first byte be assigned to CoAP. The TLS chai rs, more or less told the CORE guys to get stuffed (politely of course). Two ports is the obvious answer. Lets consider another example. As the draft mentions, firewalls help apply policy, and catch configuration errors. Take an organization (like my house) that has a policy of no email over unencrypted protocols. It's really easy to set up a firewall policy that allows the encrypted ports and blocks the non encrypted ports that are typically used for email and does not require the firewall to do DPI. No doubt my daughter could figure out to circumvent this and sent unencrypted email via an VPN tunneled over DNS or ICMP or something but thats not the point - the point is to catch accidental misconfiguration, like the type that happen during software upgrades. You can agree or disagree about using firewalls this way but the fact remains, lots of people do use firewalls this way. I strongly urge this draft not to take on mandating one port - leave the decision with the designers of the protocol. If draft does mandate one port, you will end up with a port registered for protocol foo and a port for a proprietary protocol with no description called foo-secure. As I mentioned before, I also do not believe there is IETF consensus for one port. Big Issue #2: The draft has close to no review advice for the expert reviewer. I have been involved with several port registrations and they all left me grumpy and irritated and very frustrated at the expert review process. I'm sure the expert reviewer involved felt the same way and I know others have had similar experiences. We need concrete actionable advice for when the review says yes or no. This draft provides no guidance on what the expert review would approve or deny. If all they are doing is checking the requirements of this draft have been satisfied, then I am fine with that but the draft needs to say that something like any denial by an expert review should include which MUST in this draft was not complied with. I would like the draft to say that when IANA sends a response from an expert review to the applicant, the name of the reviewer (and perhaps email address) should be included. Lets take some specific points of never ending confusion about what is good enough to say yes. The reference to the doc describing the protocol. Is this a one line description? Is it a overview of the high level way this works, deals with congestion, security etc? Is it a full protocol specification. I have no idea. I also have no idea on what grounds the expert reviews can say no based on this. What protocols use Anycast. Does STUN? Does ping? what about DNS? Who knows - who cares. I do not believe discussion of if a protocol uses anycast or not has much relevance to deciding to allocate a port. Next lets talk about the whole topic of what is or is not appropriate for dynamic range. Let's take web browsing for example. You start with a URL like www.example.com but the protocol could have required a port like www.example.com:55123 in the URL and only used dynamic ports. Is http a protocol that should be forced into the dynamic range? Clearly the answer is no but if not http, then what protocol should? This draft offers no advice to the expert reviewer on what to do. Next lets
Re: draft-housley-two-maturity-levels
1/ I still do not think this (modified) proposal will have any real impact on the number of Proposed Standard documents that move to a (in this proposal, the) higher level since I do not see how this makes any significant changes to the underlying reasons that documents have not progressed in the past - i.e., I see no reason to think that this proposal would change the world much (would not help, would not hurt) 2/ I think the proposal must specifically deal with the 2026 IPR licence requirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement does not make the issue go away. This requirement was, in theory, a way to keep the IETF/IESG out of the business of evaluating the fairness of licensing terms. I can remember only one time it came up (in an appeal) so getting rid of it may be fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that the conditions for advancement have been met - one of the big implementation issues with 2026 was knowing how to decide that a technology was ready to be advanced (did you need a spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocols as they went forward - maybe this is no longer a desire but, like with the license issue, a specific mention of what has been decided would mean that people would not think that things were not just forgotton. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
+1 on all points, especially the first one. john --On Wednesday, January 26, 2011 22:29 -0500 Scott O. Bradner s...@harvard.edu wrote: 1/ I still do not think this (modified) proposal will have any realimpact on the number of Proposed Standard documents that moveto a (in this proposal, the) higher level since I do not seehow this makes any significant changes to the underlying reasonsthat documents have not progressed in the past - i.e., I see noreason to think that this proposal would change the world much(would not help, would not hurt) 2/ I think the proposal must specifically deal with the 2026 IPR licencerequirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement doesnot make the issue go away. This requirement was, in theory, away to keep the IETF/IESG out of the business of evaluatingthe fairness of licensing terms. I can remember onlyone time it came up (in an appeal) so getting rid of it maybe fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that theconditions for advancement have been met - one of the bigimplementation issues with 2026 was knowing how to decidethat a technology was ready to be advanced (did you needa spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocolsas they went forward - maybe this is no longer a desire but,like with the license issue, a specific mention of what hasbeen decided would mean that people would not think thatthings were not just forgotton. Scott ___ 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: draft-housley-two-maturity-levels
Hi, yes, I also agree the first one is the most important point and has not been addressed so far. If we want a system that works (and is used), it needs to include incentives to move from one level to the next one. I have discussed this issue with quite a few people. Some people claim that those incentives exist in some areas (e.g., public institutions preferring or requiring full standards in their RFQs) but, at least in the RAI area, the incentives are not there in the vast majority of cases. Cheers, Gonzalo On 27/01/2011 9:28 AM, John C Klensin wrote: +1 on all points, especially the first one. john --On Wednesday, January 26, 2011 22:29 -0500 Scott O. Bradner s...@harvard.edu wrote: 1/ I still do not think this (modified) proposal will have any realimpact on the number of Proposed Standard documents that moveto a (in this proposal, the) higher level since I do not seehow this makes any significant changes to the underlying reasonsthat documents have not progressed in the past - i.e., I see noreason to think that this proposal would change the world much(would not help, would not hurt) 2/ I think the proposal must specifically deal with the 2026 IPR licencerequirement in section 4.1.2 If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The requirement can be dealt with by explicitly discarding it or by including it. But not mentioning the requirement doesnot make the issue go away. This requirement was, in theory, away to keep the IETF/IESG out of the business of evaluatingthe fairness of licensing terms. I can remember onlyone time it came up (in an appeal) so getting rid of it maybe fine - but don't make it look like it was just forgotten. 3/ I think you also be quite specific as to how to decide that theconditions for advancement have been met - one of the bigimplementation issues with 2026 was knowing how to decidethat a technology was ready to be advanced (did you needa spreadsheet listing all features and noting with ones had been multiply implemented (as was done at huge effort for HTTP 1.1) or is there someting simplier - clear rules would help avoid this type of issue in the future 4/ as part of #3 - the rules should also specifically deal with the following pp from 2026 The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed. this requirement was included to try to remove cruft from protocolsas they went forward - maybe this is no longer a desire but,like with the license issue, a specific mention of what hasbeen decided would mean that people would not think thatthings were not just forgotton. Scott ___ 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
Document Action: 'Architectural Guidelines for Multipath TCP Development' to Informational RFC (draft-ietf-mptcp-architecture-05.txt)
The IESG has approved the following document: - 'Architectural Guidelines for Multipath TCP Development' (draft-ietf-mptcp-architecture-05.txt) as an Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/ Technical Summary Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput. This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP protocol. This document lists certain high level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. Working Group Summary This is a product of the MPTCP WG. There is a consensus in the WG for publication as an informational RFC. There is a very solid WG consensus behind the document. It captures the key high-level design decisions about the MPTCP protocol, which have been reached after extensive discussion and agreement at the IETF meetings and on the list. Document Quality There is already an implementation of the protocol (draft-ietf- mptcp-multiaddressed) that implements the architecture and high-level design decisions in this document, https://scm.info.ucl.ac.be/trac/mptcp/wiki. There were five detailed reviews of versions of the document. No substantial issues were raised. Expert reviews (MIB doctor etc) were not applicable. Personnel Philip Eardley (philip.eard...@bt.com) is the Document Shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses' to Informational RFC (draft-ietf-mptcp-threat-08.txt)
The IESG has approved the following document: - 'Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses' (draft-ietf-mptcp-threat-08.txt) as an Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-threat/ Technical Summary This document describes the threat analysis for Multi-path TCP which allows an endpoint to use multiple IP addresses to exchange data. The goal of this document is to provide the information of possible threats in Multi-path TCP and recommendable solutions to make MPTCP as secure as the current TCP. The information on this document is important for the basic design of MPTCP protocol. Additional strong secure mechanisms are out-of-scope of this document and will be addressed by other documents. Working Group Summary This draft has been discussed in all IETF meetings since the creation of the WG. There is a strong consensus in the WG for publication as an informational RFC. Document Quality This document was reviewed by various people and has been through WGLC successfully. The MPTCP protocol has been designed based on the recommendations in this document. Personnel Yoshifumi Nishida (nish...@sfc.wide.ad.jp) is the document shepherd. Lars Eggert (lars.egg...@nokia.com) reviewed the document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-rmt-bb-fec-raptorq-04.txt (RaptorQ Forward Error Correction Scheme for Object Delivery) to Proposed Standard
The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'RaptorQ Forward Error Correction Scheme for Object Delivery' draft-ietf-rmt-bb-fec-raptorq-04.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 i...@ietf.org mailing lists by 2011-02-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/ The following IPR Declarations may be related to this I-D: /ipr/615/ /ipr/618/ /ipr/702/ /ipr/734/ /ipr/1292/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'URI Scheme for Java(tm) Message Service 1.0' to Informational RFC (draft-merrick-jms-uri-12.txt)
The IESG has approved the following document: - 'URI Scheme for Java(tm) Message Service 1.0' (draft-merrick-jms-uri-12.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-merrick-jms-uri/ Technical Summary This document defines the format of Uniform Resource Identifiers (URI) as defined in [RFC3986], for designating connections and destination addresses used in the Java Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS destination. The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it. Working Group Summary This is not a WG document. Document Quality The document had 2 reviews from the Apps Review team and most of the comments were addressed, although reviewers have disagreed with authors on some philosophical points. The document was also discussed on the uri-rev...@ietf.org mailing list. Several vendors are planning to implement this specification. Personnel Alexey Melnikov is the Responsible Area Director. RFC Editor Note Please replace the 3rd paragraph of Section 9.2.3 with the following 2 paragraphs: OLD: JMS URI variant registrations cannot be deleted; mechanisms that are no longer believed appropriate for use can be marked as obsolete in the Comment field. NEW: JMS URI variant registrations MUST NOT be deleted; mechanisms that are no longer believed appropriate for use can be marked as obsolete in the Comment field. In exceptional circumstances IESG can reassign responsibility for a JMS URI variant. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
