Re: team to look at diversity
Jari, this is great news. A design team approach may be able to collect information and generate ideas and actionable points in a way that works much better than ranting on the IETF list. The most important insight is that diversity is not a problem that can be fixed by some set of measures, but a process that needs to be ongoing. Of course, that process can still be supported by specific measures, and you have to have a diverse view to find out what might work. I would like to pick two items here. Both are not going to help for all dimensions of diversity, or fix the diversity problem, but it's the small steps that will make a difference. My items are: -- Reducing situations that are perceived as hostile by members of specific groups. -- Working on incentive structures that are useful for diverse groups. Re hostility: I think most of us like to think they know what this means for gender, ethnicity (but we sure can still get a lot better in acting on that knowledge, and in increasing consciousness). We are not always very good at accommodating people with limited command of the English language (yesterday's Diana Raft thing was great comic relief here) -- keeping the process efficient is one thing, being insensitive clods another. Some groups think they know it all and dismiss input from other groups in an aggressive way (folks: academic is not a pejorative!). I don't even know what other people might perceive as hostile; that would be good input for the design team. Re incentives: Just an example that I happen to know about: academia has a need for authorship recognition -- but that need is regularly dismissed by people that come from different groups (in a way that feels like utter contempt, back to the hostility point). What can we improve with respect to the incentive structures for other groups, say, people from operators or from small businesses? Again, something that people from the various groups could contribute their thoughts about toward the design team. I'm not trying to make the design team the diversity ombudsman, but providing a somewhat sensitive and possibly confidential atmosphere for offering thoughts like these might help. Grüße, Carsten
Re: draft-guo-idoca-with-the-html-file-format-00
Yes，I think this idea very goog too, But how to make various software vendors agree to do so ?Especially in larger companies ,such as google docs, office365,why they to do so ?where they do the interest in this？And finally the implementation of the technology is who is going to achieve? Susie On Tue, Apr 2, 2013 at 1:47 PM, Kun Yang yangkun2...@gmail.com wrote: Dear Mr. Guo, This I-D is a good idea. It is the first time I hear about the idea of IDOCA (Interconnection and Interoperability of Cloud-Office Application) with the html file format. If this idea comes true, it will be beneficial to all cloud-office user. However, the problem of security will arise with the interconnection and the interoperability, but the solution for it is not specific in this I-D. Maybe deeper discusses need to be made. Kun
Re: [OPSEC] Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
Fernando, Rather than repeating myself, I'll suggest a change to the Introduction that would (IMHO) improve the message: OLD: 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. For cases in which the corresponding devices are deployed on networks that are assumed to be IPv4-only, NEW: 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default [RFC6434]. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. As a result, networks will need to plan for and deploy IPv6 and its security mechanisms. Some enterprise networks might, however, choose to delay active use of IPv6. For networks that are assumed to be IPv4-only, It would be nice to refer to draft-ietf-v6ops-enterprise-incremental-ipv6 but I think that is too far from RFC publication to be very useful. Regards Brian On 01/04/2013 14:04, Fernando Gont wrote: Brian, On 03/29/2013 10:38 AM, Brian E Carpenter wrote: My minimal request for this draft is for my name to be removed from the Acknowledgements, as I do not think that my comments have been acted on. That has been my intent, and I sent a note before publishing one of the latest revs to double-check that (not sure if I missed your respond, or you didn't respond). In fact, I think that in its current state, this document is harmful to IPv6 deployment. It in effect encourage sites to fence themselves into an IPv4-only world. Particularly, it explicitly suggests a default/deny approach to IPv6-in-IPv4 tunnels, which would prevent the typical baby steps first approach to IPv6 deployment. Sites that implement any kind of security policy employ a default deny policy (for the simple reason that it's safer to open holes than explicitly close them). The bottom-line is that if your site enforces any kind of security policy, you should make an explicit decision regarding what you do with v6, rather than being unaware that it's there in your network. I would like to see the document convey a positive message, suggesting that an IPv4 site first decides which IPv6 deployment mechanism it will use, and then configures security appropriately (to allow that mechanism and block all others). There's an operational gap here: in many cases, operators have no tools to enforce security policies on such tunneled traffic. Besides, when thinking about v6, enterprise networks and the like should be doing native IPv6 (in which case v6 security controls would be enforced throughout the network), rather than having each node go their own way. A specific aspect of this is that if a site provides one well-managed 6in4 tunnel mechanism, all tunneled IPv6 packets will pass through well-defined points where security mechanisms may be applied. In which case you'd be enforcing IPv6 security controls, which is entirely in-line ith what this document is saying. We shouldn't imply that not having an IPv6 plan and blocking all IPv6 by default is a sound strategy. It's not, and I don't think we're implying that. However, I'd note that some people are in the position of blocking traffic, or not doing anything about it. Check for IPv6 support in different security products, and you might get depressed. Cheers,
Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
Just picking a couple of points for further comment: On 02/04/2013 08:46, Liubing (Leo) wrote: Hi, Robert ... -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] ... The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. Robert is right, though, sending people to a long-expired draft is a bad idea. Of course we have to acknowledge it, but maybe we should pull some of its text into an Appendix. Tim Chown, any opinion? RFC4076 seems to say very similar things to this document. Should it have been referenced? [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which might not be common usage in enterprise. But sure we can consider reference it. Yes, and check if it identifies any gaps that we should mention. Bing: we should also add a reference to RFC 4085 Embedding Globally-Routable Internet Addresses Considered Harmful which I missed for RFC 6866. Section 5.3 punts discussion of static addresses off to RFC 6866. That document was scoped only to Enterprise Networks. The scope of this document is larger. As Bing said, the *intended* scope is enterprise networks. We should add that in the Abstract and Introduction. Indeed, many of the points are more general. Thanks again Robert! Brian
RE: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
Kids! Remember, if we're not bright enough to do physics, we can always do engineering, the slow younger brother of physics! But if engineering is too difficult, there's always computer science, where terms like bandwidth mean what we want them to mean. And if even that's too hard, there's always the arts-and-crafts knitted-my-own-shawl-or-at-least-drew-an-okay-pattern-for-it trade of 'Internet Engineering', and writing RFCs. And we can achieve that RFC goal easily by getting in the back door with an April 1 RFC! Every April 1 there's a reminder and inspiration to us all! Lloyd Wood http://sat-net.com/L.Wood/ Time's arrow is written gt;
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
Resending due to Richards change of address. Stewart On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet-addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them to use Ethernet broadcast addressing which allows the crafts to change h/w without the need for reconfiguration by the NMS. Against that background moving them onto the use of a Ethernet m/c address is a step forward. To require using the GAP to that community would illustrate that the IETF is out of touch with their needs and methods of network operation. Hopefully this additional background, which I believe is well known to the MPLS-TP community to which this draft is directed, satisfies your concern on the latter point. - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
On Apr 2, 2013, at 6:41 AM, l.w...@surrey.ac.uk wrote: Kids! Remember, if we're not bright enough to do physics, we can always do engineering, the slow younger brother of physics! Is your point that if we do an engineering solution, that will slow things down enough that we won't have packet ordering problems?
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
Thanks for following up, and for the re-send. Just to be clear, I do not mean these as blocking points. On the former point, I might just suggest a minor edit to the introduction: OLD: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing under these circumstances. NEW: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing when MPLS-TP is used in a pure Ethernet manner, without any IP forwarding capability. On the latter point, I can understand the desire to make the simple case simple, and the text at the end of Section 2 sends a clear warning. It does seems like GAP would also allow autoconfiguration without further NMS interaction. (Unless the NMS is configuring per-Ethernet-address policies, e.g., forward packets with this label to 00:11:22:33:44:55. Is that the case?) On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant stbry...@cisco.com wrote: Resending due to Richards change of address. Stewart On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet- addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them to use Ethernet broadcast addressing which allows the crafts to change h/w without the need for reconfiguration by the NMS. Against that background moving them onto the use of a Ethernet m/c address is a step forward. To require using the GAP to that community would illustrate that the IETF is out of touch with their needs and methods of network operation. Hopefully this additional background, which I believe is well known to the MPLS-TP community to which this draft is directed, satisfies your concern on the latter point. - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: [nfsv4] Last Call: draft-ietf-nfsv4-rfc3530bis-25.txt (Network File System (NFS) Version 4 Protocol) to Proposed Standard
I have not yet completed a full review of this (320-page) document, and I worry that I may not finish before the deadline, so I am bringing this concern to your attention now. Section 3.2.1.1 of this document (Kerberos V5 as a security triple) seems to indicate that it is mandatory for a conformant NFSv4 implementation to implement the Kerberos V5 GSS-API mechanism and a few security triples (mechanism,quality of protection,service). All of the mandatory-to-implement security triples use the DES-MAC-MD5 algorithm. The draft goes on to indicate that clients should engage in security negotiation (section 3.3) to determine what security to use for bulk operation, and that since kerberos-v5 under RPCSEC_GSS is mandatory, the negotiation will be performed using that security provider. The actual mechanism resulting from the negotiation may be different (or may be the same), but this single-DES mechanism seems to be required to be used to protect the negotiation step. Given that the kerberos working group has published RFC 6649 (Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos) and single-DES is known to be critically vulnerable to brute-force attacks, I have grave concern about the IETF publishing new standards documents that mandate the implementation of single-DES and do not specify strong cryptographic algorithms. I feel that to do so would be misleading implementors into believing that single-DES is sufficient and other mechanisms need not be implemented, when in reality this is not true. Sincerely, Ben Kaduk MIT Kerberos Consortium
Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)
Fine with me. On Apr 1, 2013, at 5:41 PM, Robert Sparks rjspa...@nostrum.com wrote: On 3/28/13 1:17 PM, SM wrote: Hi Eric, At 05:13 28-03-2013, Burger Eric wrote: Rather than guessing all of the bad things that could happen, I would offer it would be better to say what we mean, like: The IMAP interface MUST NOT provide any IMAP facilities that modify the underlying message and message metadata, such as mailbox, flags, marking for deletion, etc. If the client is authenticated and authorized, the IMAP interface MUST provide per-user marking of the underlying message as read or flagged. The IMAP interface is a front-end to the read-only mailboxes (archive). It's easier to do what is mentioned above. I'm taking more or less that approach in my working copy (I'll be posting -06 soon). Something to ponder: I use the IMAP interface once, mark a bunch of things as read, and then decide never to use the IMAP interface ever again. How long does the server need to keep my (per-user) marking metadata? E.g., besides CPU and I/O issues, there is a potentially unbounded storage problem as well. It is unbounded because in IMAP I can assign any kind of label (marking) to a message, even ones I make up. One thought for an approach to a solution: 1. per-user markings expire after X time units (six months?) 2. per-user markings may take up at most X storage units (512KB?) I would go for both. Instead, I propose that we make it possible to notice an abuser and turn off access (this is what -06 will contain). I don't believe we could come to a consensus on an automatic expiry of state - there are use cases I can think of where any short expiration (like 6-months) would be infuriating. If keeping this state for normal use turns out to be too expensive for us, then we will have learned something, and can start talking about future IMAP work in general to help systems mitigate that expense. Per-user metadata can be incredibly useful - I might label things by project, work group, draft, mumble, or foo. I would not want to limit the labels to red or green. However, we need some predictable limit as well. Yes. Regards, -sm
Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. The following is my proposed text for replacing the current first paragraph of section 1.2. Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today¹s wireline and wireless services and applications. QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. Thanks, Luyuan -Original Message- From: Russ Housley hous...@vigilsec.com Date: Saturday, March 23, 2013 3:16 PM To: ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. Thanks, Russ On Jan 28, 2013, at 3:01 PM, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Applicability; Use Cases and Design' draft-ietf-mpls-tp-use-cases-and-design-06.txt as Informational RFC 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 ietf@ietf.org mailing lists by 2013-02-11. 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. Abstract This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/b allot/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls
RE: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
Hi, Robert Thanks a lot for your careful and detailed review. It is very helpful to refine the draft. Please see replies inline. -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] Sent: Tuesday, April 02, 2013 4:47 AM To: 6re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org Cc: gen-...@ietf.org; ietf@ietf.org Subject: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt 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-6renum-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10,2013 IESG Telechat date: Not yet scheduled for a telechat Summary: This document is not ready for publication as an Informational RFC. It may be on the right track, but there issues both in substance and form that need to be addressed. Major issues: The document doesn't provide what its title and abstract claim it will provide. For instance, the abstract claims a gap analysis is presented following a renumbering event procedure summary, but neither appear in the draft. [Bing] In fact the subtitles have the implication of a renumbering event procedure summary. But it is indeed not explicit in the main texts. We'll add some texts to represent it explicitly in the next version. There are a few places in the text that say this is a gap, but usually it's not clear what this means. [Bing] We'll make them more clear in the next version. The stated intent is to identify missing capabilities (gaps) and the work needed to provide them. The document should lay these out very clearly. As the document is currently written, it is difficult to pull out a simple list of identified gaps. [Bing] A good suggestion. We once had a summary subtitle in previous versions, but we deleted it since we thought it might be a little redundancy. Now we can add it back, it could be helpful for the readers. While addressing that, it would help more to provide some sense of the relative importance of addressing each of the gaps identified. [Bing] We used to divide the gaps into solvable and unsolvable. Some important gaps might be unsolvable; while some of the solvable ones might not be so important. We'll consider to reflex the two dimensions in the next version. There are several significant issues with clarity. I will point to the most difficult in a section below. -- Minor issues: The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. RFC4076 seems to say very similar things to this document. Should it have been referenced? [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which might not be common usage in enterprise. But sure we can consider reference it. Section 5.3 punts discussion of static addresses off to RFC 6866. That document was scoped only to Enterprise Networks. The scope of this document is larger. Are there gaps because of that difference in scope that were missed? Would it make sense to summarize any gaps RFC 6866 identified that are relevant to this document here? [Bing] This document scope is also for enterprise (it is the 6renum WG scope). In fact the RFC6866 is a sub-document of this draft. We considered static address problem is an important topic that need a separated document to describe. We can consider add a brief summary there. Should section 8 belong to some other document? It looks like operational renumbering advice/considerations, but doesn't seem to be exploring renumbering gaps, except for the very short section 8.2 which says we need a better mechanism without much explanation. [Bing] The multicast and mobility in section 8 were considered as important standalone topics that need to be addressed. Since multicast is complex, we need more texts to describe the problem than describing the gaps directly. But we can make the gaps more clear. -- Text needing clarity (more than nits): [Bing] We'll also deal with the following clarity and nits comments in the next version. Thanks for the careful review.
Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)
Works for me. -- Sent from my mobile device. Thanks be to lemonade! http://www.standardstrack.com/ietf/lemonade/ -Original message- From: Alexey Melnikov alexey.melni...@isode.com To: Burger Eric ebur...@cs.georgetown.edu Cc: Robert Sparks rjspa...@nostrum.com, ietf@ietf.org Sent: Tue, Apr 2, 2013 09:53:39 GMT+00:00 Subject: Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt) Hi Eric, I am sorry if I sound pedantic below, but I think your suggestion can be misinterpreted and thus needs improving: On 28/03/2013 12:13, Burger Eric wrote: Rather than guessing all of the bad things that could happen, I would offer it would be better to say what we mean, like: The IMAP interface MUST NOT provide any IMAP facilities that modify the underlying message and message metadata, such as mailbox, flags, marking for deletion, etc. If the client is authenticated and authorized, the IMAP interface MUST provide per-user marking of the underlying message as read or flagged. One way to implement this is in an IMAP server is to always fail commands for modifying message metadata. Another way of implementing this is to allow them, but ignore (don't persist) results. Both ways were used in the past and they have different effect on IMAP clients. I hope the requirement is intended to allow for either. Another thing to consider is that for IMAP servers that implement IMAP ACL, the easiest way to meet the intended requirement is by not allowing unauthorized users to access some commands on a mailbox. Again, a possible reading of your suggested text is that that is not allowed. So, my suggestion is to change MUST NOT provide any IMAP facilities ... to MUST disallow any IMAP facilities
RE: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Hi Luyuan, You wrote (in part): ..since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Which is not true and probably not what you meant. A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than traditional circuit-based TDM technologies. To be honest however, I'd cut the traditional and use only TDM (since some 'circuit' based technologies also offer packet multiplexing) so I'd reduce it to: A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than TDM technologies. cheers, pd -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Luyuan Fang (lufang) Sent: Monday, April 01, 2013 9:05 PM To: Russ Housley; ietf@ietf.org Cc: m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. The following is my proposed text for replacing the current first paragraph of section 1.2. Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today¹s wireline and wireless services and applications. QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. Thanks, Luyuan -Original Message- From: Russ Housley hous...@vigilsec.com Date: Saturday, March 23, 2013 3:16 PM To: ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. Thanks, Russ On Jan 28, 2013, at 3:01 PM, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Applicability; Use Cases and Design' draft-ietf-mpls-tp-use-cases-and-design-06.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits
RE: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
Hi, Brian The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. Robert is right, though, sending people to a long-expired draft is a bad idea. Of course we have to acknowledge it, but maybe we should pull some of its text into an Appendix. Tim Chown, any opinion? [Bing] Ok, then we can hear some opinions from Tim. RFC4076 seems to say very similar things to this document. Should it have been referenced? [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which might not be common usage in enterprise. But sure we can consider reference it. Yes, and check if it identifies any gaps that we should mention. Bing: we should also add a reference to RFC 4085 Embedding Globally-Routable Internet Addresses Considered Harmful which I missed for RFC 6866. [Bing] Got it. I'll add it in the next version. Section 5.3 punts discussion of static addresses off to RFC 6866. That document was scoped only to Enterprise Networks. The scope of this document is larger. As Bing said, the *intended* scope is enterprise networks. We should add that in the Abstract and Introduction. Indeed, many of the points are more general. [Bing] OK. Thanks. Thanks again Robert! Brian
Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt
Works for me. Thanks, Paul. Luyuan -Original Message- From: Doolan, Paul (NSN - US/Irving) paul.doo...@nsn.com Date: Tuesday, April 2, 2013 7:58 AM To: Luyuan Fang luf...@cisco.com, Russ Housley hous...@vigilsec.com, ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt Hi Luyuan, You wrote (in part): ..since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Which is not true and probably not what you meant. A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than traditional circuit-based TDM technologies. To be honest however, I'd cut the traditional and use only TDM (since some 'circuit' based technologies also offer packet multiplexing) so I'd reduce it to: A better formulation might be since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than TDM technologies. cheers, pd -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext Luyuan Fang (lufang) Sent: Monday, April 01, 2013 9:05 PM To: Russ Housley; ietf@ietf.org Cc: m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. The following is my proposed text for replacing the current first paragraph of section 1.2. Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today¹s wireline and wireless services and applications. QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. Thanks, Luyuan -Original Message- From: Russ Housley hous...@vigilsec.com Date: Saturday, March 23, 2013 3:16 PM To: ietf@ietf.org ietf@ietf.org Cc: m...@ietf.org m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-use-cases-and-design-06.txt I wonder if the direction of Section 1.2 can be revised to make it more of an engineering document. It currently says: In recent years, the urgency for moving from traditional transport technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies has been rising. This is largely due to the fast growing demand for bandwidth, which has been fueled by the following factors: ... Please consider an approach that describes the the reasons behind the transition from the network operator and network user perspectives: Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these advantages: ... The fact that IP networks are being used for new applications and that the legacy devices are getting old does not motivate the transition to packet technologies. The advantages that packet technologies offer for these new applications is the thing that needs to be highlighted here, even if it is just a list of bullets. It seems like the only sentence that addresses this point in Section 1.2 is: It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. Thanks, Russ
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
AB, On Apr 1, 2013, at 5:45 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: RFC6921It is well known that as we approach the speed of light, time slows down. AB I know that time slows for something when it is in speed of light, but communication is not something moving. If the packet is in speed of light we may reduce the comm-delay but never less than zero. The communication times don't change if at least one communicator is not moving in light speed. My comment is that I think this RFC is not logical, and I don't understand its recommendations. There is no way that a packet can be received before send, packet-time never changes communicators-time while the positions of both Tx and Rx are semi-fixed (change is relative to communicators' times not their signal). I think the communication-times may change when the communicators are at/above speed of light not the signal/packet. Is my physics correct? Only time will tell. Bob
Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
On 4/2/2013 2:58 AM, Brian E Carpenter wrote: Just picking a couple of points for further comment: On 02/04/2013 08:46, Liubing (Leo) wrote: Hi, Robert ... -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] ... The document currently references draft-chown-v6ops-renumber-thinkabout several times. That document is long expired (2006). It would be better to simply restate what is important from that document here and reference it only once in the acknowlegements rather than send the reader off to read it. [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid. draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it. Robert is right, though, sending people to a long-expired draft is a bad idea. Of course we have to acknowledge it, but maybe we should pull some of its text into an Appendix. Tim Chown, any opinion? I still think that old draft is fairly good, and a shame to let it all just die. But there is no chance of getting that out as an RFC I guess? Stig RFC4076 seems to say very similar things to this document. Should it have been referenced? [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which might not be common usage in enterprise. But sure we can consider reference it. Yes, and check if it identifies any gaps that we should mention. Bing: we should also add a reference to RFC 4085 Embedding Globally-Routable Internet Addresses Considered Harmful which I missed for RFC 6866. Section 5.3 punts discussion of static addresses off to RFC 6866. That document was scoped only to Enterprise Networks. The scope of this document is larger. As Bing said, the *intended* scope is enterprise networks. We should add that in the Abstract and Introduction. Indeed, many of the points are more general. Thanks again Robert! Brian
Re: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
On 04/01/2013 06:14 PM, SM wrote: with IPv6 connectivity. However, it's inappropriate to rely on pervasive implementation of Happy Eyeballs as the sole solution to prevent end host impacts, since the end user may not know that IPv6 is actively being disabled on this network, or that their IPv6 implementation is otherwise broken. This is a problem that continues to get worse the more dual-stack content becomes available. I agree with the last sentence. Happy Eyeballs is about the HTTP. There are other applications protocols too. :-) Happy eyeballs is about HTTP. But part of the approach predates Happy Eyeballs -- please see RFC5461. Signaling hosts when packets are being dropped allows for a more informed decision/reaction on the host-side. Removing the records when you're not going to allow such connectivity reduces the potential problem (at the end of the day, this is kind of the whitelisting approach that has been applied to the general case by content providers -- with the caveat that in this case you positively know that such connectivity is not present). Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
On Apr 2, 2013, at 7:30 PM, Fernando Gont fg...@si6networks.com wrote: I agree with the last sentence. Happy Eyeballs is about the HTTP. There are other applications protocols too. :-) Happy eyeballs is about HTTP. But part of the approach predates Happy Eyeballs -- please see RFC5461. It's certainly true that we usually talk about Happy Eyeballs in the context of HTTP, but I use it for ssh as well, and I think it's applicable across a broad range of application protocols. It is not applicable to _every_ protocol, but that's as strong a qualification as I'd put on it—saying it's only applicable to HTTP is not correct.
Re: Last Call: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt (Security Implications of IPv6 on IPv4 Networks) to Informational RFC
Hi Fernando, At 16:30 02-04-2013, Fernando Gont wrote: Happy eyeballs is about HTTP. But part of the approach predates Happy Eyeballs -- please see RFC5461. Ok. Removing the records when you're not going to allow such connectivity reduces the potential problem (at the end of the day, this is kind of the whitelisting approach that has been applied to the general case by content providers -- with the caveat that in this case you positively know that such connectivity is not present). Here's an extract from RFC 4924: 'In particular, the DNSSEC protocol described in Protocol Modifications for the DNS Security Extensions [RFC4035] has been designed to verify that DNS information has not been modified between the moment they have been published on an authoritative server and the moment the validation takes place. Since that verification can take place at the application level, any modification by a recursive forwarder or other intermediary will cause validation failures, disabling the improved security that DNSSEC is intended to provide.' I am ok with resolving the problem of the day. If I am of the opinion that it may cause problems in the long run I'll mention it. I am not inclined to do anything more than that. Regards, -sm
Re: Sufficient email authentication requirements for IPv6
On Mar 30, 2013, at 11:26 PM, Christian Huitema huit...@microsoft.com wrote: IPv6 makes publishing IP address reputations impractical. Since IP address reputation has been a primary method for identifying abusive sources with IPv4, imposing ineffective and flaky replacement strategies has an effect of deterring IPv6 use. In practice, the /64 prefix of the IPv6 address has very much the same administrative properties as the /32 value of the IPv4 address. It should be fairly straightforward to update a reputation system to manage the /64 prefixes of IPv6. This seems somewhat more practical than trying to change the behavior of mail agent if their connectivity happens to use IPv6. Dear Christian, The announced prefix space currently represents more than 4 million times the entire IPv4 address space. This means the /64 prefix space can not be considered comparable to IPv4 address space. Go to http://bgp.potaroo.net/v6/as2.0/ and look for Total address space advertised (/64 equiv). The number of announced prefixes over /64s currently shows 18,206,079,529,779,202. Much of the IPv4 has already had Reverse DNS PTR records traversed scanning for hints about whether any specific address appears to represent dynamically assigned access. This guesswork allows about 1/3 of the IPv4 space to be ignored by blocking them from sending public (port 25) SMTP messages. Reverse DNS PTR records offers a costly means to differentiate residential and non-residential access when done on a realtime basis. A significant benefit of a comprehensive reputation mapping of the entire IPv4 address space is that any reverse naming exceptions are incorporated into the reputation values which also eliminates dependence on reverse DNS performance. In IPv6, there can not be any pre-mapping. This places reverse PTR review at the mercy of the even more broken IPv6 reverse zone provisioning. Any mis-configuration of the reverse name space, which is common for IPv4 from residential systems, greatly increases the resources consumed by the growing proportion of sessions emitted by compromised systems. Few expect reverse PTRs and hostnames to match, but to offer names not hinting at being for a dynamic assignment. Greatly increased delays caused by DNS misconfiguration, along with a need to handle a larger number of sessions, will make testing reverse PTR records highly resource prohibitive and problematic for IPv6. In the end, Reverse PTRs can be assigned any name and thus can not serve as a basis to assess accountability. Once a conclusion is reached that only AUTHENTICATED initiating domains offer a means to fairly establish a basis for acceptance, use of reverse PTR records becomes far far less attractive. The ability to authenticate forward domains initiating messages improves security and is better suited for a future of more mobile and dynamic infrastructure. Many email domains will find themselves obligated to authorize IPv4 outbound servers using SPF. Return-Path mail parameters locating authorization reduces backscatter abuse at the cost of reduced delivery integrity. However this parameter's relationship over mail's entire path is too fragile to serve as a basis for acceptance. Since DKIM allows any message to be relayed by design, it can not offer a means to mitigate abuse when any marginal domain must be accepted, as for domains considered too big to block. In addition, problems related to DKIM header field spoofing permitted when signatures are still considered valid, along with a growing range of dangerous email content that references compromised i-frames, makes responding to new threats a growing problem. IPv6 pushes this problem further over the edge without the introduction of the initiating domains having been authenticated. IPv6 addresses can not serve this function, and there is progress being made in respect to use of DANE and the like. Regards, Douglas Otis
Protocol Action: 'The Optimized Link State Routing Protocol version 2' to Proposed Standard (draft-ietf-manet-olsrv2-19.txt)
The IESG has approved the following document: - 'The Optimized Link State Routing Protocol version 2' (draft-ietf-manet-olsrv2-19.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ Technical Summary This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link-state information. A secondary optimization is that OLSRv2 employs partial link-state information: each node maintains information of all destinations, but only a subset of links. This allows that only select nodes diffuse link-state advertisements (i.e. reduces the number of network-wide broadcasts) and that these advertisements contain only a subset of links (i.e. reduces the size of each network-wide broadcast). The partial link-state information thus obtained allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements to the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. Working Group Summary o OLSRv2 is the routing protocol, which uses as constituent parts (and from which was spun off) the already published by the MANET Working Group RFCs 5148, 5444, 5497, and 6130. The document also uses RFC 5498 - also already published by the MANET Working Group. This document is, therefore, an integral part of the Working Group deliverables, and its publication completes the charter item of a proactive MANET protocol. o OLSRv2 was first submitted as an individual draft in July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a Working Group document in August 2005. o A key difference between RFC3626 and OLSRv2 is the introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus on this matter. Metrics support was, then, folded into OLSRv2. o This version of OLSRv2 was given a one month WGLC, so as to ensure sufficient time to review the document. o The Working Group is actively working on the associated MIB document (draft-ietf-manet-olsrv2-mib) There was an issue concerning the differences between the -14 and -15 revisions of the document, brought up by one WG member. The consensus opinion from the WG is that the document should proceed, without additional edits. Document Quality There is a number of independent implementations of OLSRv2. Those listed below have, explicitly, consented to be nominatively mentioned: o Ecole Polytechnique, France (Contact: Thomas Clausen) o CRC - Communications Research Centre Canada (Contact: Yannick Lacharite) o INRIA, France (Contact: Cedric Adjih) o Hitachi Yokohama Research Lab, Japan (Contact: Hiroki Satoh) o BAE Systems Advanced Technology Centre, UK (Contact Christopher Dearlove) o Fraunhofer FKIE is working on the olsr.org implementation of OLSRv2 (Contact: Henning Rogge) o Niigata University, Japan http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ (Contact: Hiroei Imai) Over the years, several interoperability events have been organized, in France, Canada, Japan, Austria, Personnel The Document Shepherd is Stan Ratliff (sratl...@cisco.com) The Responsible AD is Adrian Farrel (adr...@olddog.co.uk)
RFC 6877 on 464XLAT: Combination of Stateful and Stateless Translation
A new Request for Comments is now available in online RFC libraries. RFC 6877 Title: 464XLAT: Combination of Stateful and Stateless Translation Author: M. Mawatari, M. Kawashima, C. Byrne Status: Informational Stream: IETF Date: April 2013 Mailbox:mawat...@jpix.ad.jp, kawashi...@vx.jp.nec.com, cameron.by...@t-mobile.com Pages: 14 Characters: 31382 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-464xlat-10.txt URL:http://www.rfc-editor.org/rfc/rfc6877.txt This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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
RFC 6902 on JavaScript Object Notation (JSON) Patch
A new Request for Comments is now available in online RFC libraries. RFC 6902 Title: JavaScript Object Notation (JSON) Patch Author: P. Bryan, Ed., M. Nottingham, Ed. Status: Standards Track Stream: IETF Date: April 2013 Mailbox:pbr...@anode.ca, m...@mnot.net Pages: 18 Characters: 26405 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-appsawg-json-patch-10.txt URL:http://www.rfc-editor.org/rfc/rfc6902.txt JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The application/json-patch+json media type is used to identify such patch documents. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. 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
