RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Lorenzo Answers below David De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Lorenzo Colitti Envoyé : mercredi 4 septembre 2013 10:04 À : BOUCADAIR Mohamed IMT/OLN Cc : v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Wed, Sep 4, 2013 at 3:31 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: it is about ** a ** profile for mobile devices. But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network. This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document. [[david]] Do you mean that the current status regarding IPv6 support in devices is fine and that there is no need for other features in mobile devices ? Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus. [[david]] OK Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 3:31 PM, mohamed.boucad...@orange.com wrote: it is about ** a ** profile for mobile devices. But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network. This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document. I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus. Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 5:29 PM, david.bi...@orange.com wrote: ** But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment? Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document?
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Wed, Sep 4, 2013 at 6:07 PM, mohamed.boucad...@orange.com wrote: Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? ** *[Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time.* Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That’s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. *[Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear.* True. The document does define cellular device as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than device here? It's confusing, because device usually refers to any engineered object. Maybe use the word sharing or tethering in the name? *[Med] There is running code for several features listed in this document. Because we don’t have “decent” implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!* But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works.
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi Lorenzo, We already answered to several of the points in previous discussions (during the call for adoption and also during the WGLC). We also made some changes in the last version to make the language clear (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05): it is about ** a ** profile for mobile devices. The scope covers mobile hosts, hosts with wan sharing capabilities (e.g., mobile CPE) and the also those with wi-fi interfaces. The motivations for this effort and scope are explained in the introduction. Cheers, Med De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Lorenzo Colitti Envoyé : mardi 20 août 2013 11:39 À : IETF Discussion Cc : v6...@ietf.org WG Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.orgmailto:iesg-secret...@ietf.org wrote: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. Regards, Lorenzo
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, See inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mercredi 4 septembre 2013 10:51 À : BINET David IMT/OLN Cc : BOUCADAIR Mohamed IMT/OLN; v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Wed, Sep 4, 2013 at 5:29 PM, david.bi...@orange.commailto:david.bi...@orange.com wrote: But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by other ones. Maybe you have some other proposition for mobile profile but as operators, this list of requirements fits our needs. Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). [[david]] Did you mention that not all requirements are mandatory ? It gives flexibility to operators to define what they are expecting from vendors. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. [Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That's not fair at all. Some devices have been connected to IP networks for tens of years now and it does not mean we should not add new features to these devices to enable new services. We are considering, as operators, that current IPv6 features in mobile devices do not satisfy all our needs as mentioned in the document. And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment? [Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear. There are plenty deployments relying on the mobile networks to provide broadband services. Device vendors people involved in discussion with operators in this field are quite aware of this model. You can check for instance: http://www.orange.tn/fixe-et-internet/pid382-la-flybox-orange.html Oh, and I know it's a bit out of fashion, but: what happened to running code? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind of document may be useful to get some. Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document? [Med] There is running code for several features listed in this document. Because we don't have decent implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!!
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lore...@google.com] Envoyé : mercredi 4 septembre 2013 11:25 À : BOUCADAIR Mohamed IMT/OLN Cc : BINET David IMT/OLN; v6...@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC On Wed, Sep 4, 2013 at 6:07 PM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this. [Med] What statement you would like to see added? Thanks. Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. [Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That's not fair at all. I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. [Med] This is not for all mobile hosts but for those acting as mobile CPEs. The text is clear. True. The document does define cellular device as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than device here? It's confusing, because device usually refers to any engineered object. Maybe use the word sharing or tethering in the name? [Med] The use of cellular device is governed by the definition included in the document: o 3GPP cellular host (or cellular host for short) denotes a 3GPP device which can be connected to 3GPP mobile networks or IEEE 802.11 networks. o 3GPP cellular device (or cellular device for short) refers to a cellular host which supports the capability to share its WAN (Wide Area Network) connectivity. and ... This section focuses on cellular devices (e.g., CPE, smartphones or dongles with tethering features) which provide IP connectivity to other devices connected to them. In such case, all connected devices are sharing the same 2G, 3G or LTE connection. In addition to the generic requirements listed in Section 2http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#section-2, these cellular devices have to meet the requirements listed below. Because I'm naively assuming the reader interprets this term according to the definition provided in the document, I don't see what is confusing in such wording. [Med] There is running code for several features listed in this document. Because we don't have decent implementations which meet the minimal set of requirements from operators, a group of these operators decided to carry on this effort to define a common profile. Saying that, it seems to me you want to impose specific rules only for this document!! But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code. That's not the way it works. [Med] This document is not a standard. This is explicitly mentioned in the document.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That?s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Dear Abdussalam, Many thanks for your review and suggestions. The changes you proposed have been integrated in -05 (see http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-05). As for your question about IP mobility, this is not relevant in the context of this document. Mobility is managed following 3GGP specific procedures. Cheers, Med De : v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] De la part de Abdussalam Baryun Envoyé : mardi 27 août 2013 13:05 À : ietf Cc : v6...@ietf.org; i...@ietf.org Objet : Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Reviewer: Abdussalam Baryun Date: 26.08.2013 As per the IESG request for review dated 19.08.2013 I support the draft, thanks, below are my comments, Overall The draft is about 3GPP Mobile Devices but the draft has no normative reference to such device. The title of the draft SHOULD mention that it is general profile or a proposal, where the abstract says *specifies an IPv6 profile* which means not general, so the title SHOULD say *An IPv6 profile*. Also the draft does not consider Mobile IP issues nor RFC5213 into requirements. From the doc the reviewer is not sure does the draft consider MANET issues or not needed for such devices or such connections? Abstract This document specifies an IPv6 profile for 3GPP mobile devices. AB suggest this document defines an IPv6 profile The document is missing an applicability statement section, which may be found in one paragraph in section 1.1, but the reviewer would like more details because the document is some how saying it is general requirements. AB On Mon, Aug 19, 2013 at 11:52 PM, The IESG iesg-secret...@ietf.orgmailto:iesg-secret...@ietf.org wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' draft-ietf-v6ops-mobile-device-profile-04.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.orgmailto:ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to i...@ietf.orgmailto:i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: PS Characterization Clarified
The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? This is painting us into the room where PS is mature and robust. If we like being in that room, that's fine. But it removes the IESG can put fuzzy stuff out as PS if it thinks that's the right thing to do option. Wouldn't such spec come with an applicability statement of sorts? (today, in practice?) That's a good point; probably yes. So if the text here can say something that allows a PS spec to *say* that it's less mature, and that that's being done on purpose, my concern is satisfied. It says that IETF PS specs are at least as mature as final standards from other SDOs. Mostly, that's true. But it doesn't have to be. After this, it would have to be, always, for every PS spec. Are we *sure* that's what we want? This draft is mostly targeted to document what we do, not what we want. Although I can see how you want to keep the door open. As a specific current example, I have the sense that the documents coming out of the repute working group are specifying a protocol that's somewhat less mature than what we usually do -- more comparable to the 2026 version of PS than to this one. Yet I absolutely think they should be PS, *not* Experimental. Barry
Re: PS Characterization Clarified
OK, somebody has to say it. Maybe we should have another state, something like draft standard. [ sob alluded to a private message from me which said ] while i really like the idea of pushing well-tested interoperable documents to full standards, i think tested interop is key here. hence i liked the old interop tests for ds and am not all that happy to see it go (yes, i whined privately to russ). our protocols are rarely based on any testable formalism, computer science, mathematics, ... we live on a pile of crap hacks. interop is about all that keeps us from entropic degeneration. randy
Re: PS Characterization Clarified
On 9/4/2013 11:14 AM, Scott Brim wrote: On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba barryle...@computer.org wrote: The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? This is painting us into the room where PS is mature and robust. If we like being in that room, that's fine. But it removes the IESG can put fuzzy stuff out as PS if it thinks that's the right thing to do option. Wouldn't such spec come with an applicability statement of sorts? (today, in practice?) That's a good point; probably yes. So if the text here can say something that allows a PS spec to *say* that it's less mature, and that that's being done on purpose, my concern is satisfied. Not the spec itself but an associated statement about it? There was a proposal to provide an alternative way of publishing applicability statements, in http://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04 (now expired). As a specific current example, I have the sense that the documents coming out of the repute working group are specifying a protocol that's somewhat less mature than what we usually do -- more comparable to the 2026 version of PS than to this one. Yet I absolutely think they should be PS, *not* Experimental. OK, somebody has to say it. Maybe we should have another state, something like draft standard. There were a couple of proposals to provide a way of saying the working group thinks they're finished, but lets hold off on PS until they see how the protocol works. The one I co-authored was at http://tools.ietf.org/html/draft-dawkins-newtrk-wgs-00, Scott Bradner's was at http://tools.ietf.org/html/draft-bradner-ietf-stds-trk-00, in Section 5. Both are now expired. Perhaps those drafts would be helpful background for folks thinking about this? (especially for folks who were too busy doing protocol work to follow NEWTRK? :-) Spencer
Re: PS Characterization Clarified
On Wed, Sep 4, 2013 at 10:34 AM, Barry Leiba barryle...@computer.org wrote: The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? This is painting us into the room where PS is mature and robust. If we like being in that room, that's fine. But it removes the IESG can put fuzzy stuff out as PS if it thinks that's the right thing to do option. Wouldn't such spec come with an applicability statement of sorts? (today, in practice?) That's a good point; probably yes. So if the text here can say something that allows a PS spec to *say* that it's less mature, and that that's being done on purpose, my concern is satisfied. Not the spec itself but an associated statement about it? As a specific current example, I have the sense that the documents coming out of the repute working group are specifying a protocol that's somewhat less mature than what we usually do -- more comparable to the 2026 version of PS than to this one. Yet I absolutely think they should be PS, *not* Experimental. OK, somebody has to say it. Maybe we should have another state, something like draft standard.
Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt
All I've been out on leave since just after Berlin (which I had to cancel at the last minute, so I wasn't able to attend in realtime, or present the INSIPID reqs and solutions drafts - which I normally do at each IETF). Somewhere along the way, it was decided that draft-kaplan-insipid-session-id should be informational and not historic. I backed this draft becoming historic, and wouldn't have backed this draft becoming an informational RFC, for some very specific reasons that Dan's Gen-Art review successfully tease out. I'm glad to see that Robert and Gonzalo Salgueiro (INSIPID WG chair) each generally agree to (Robert's agreement is below, Gonzalo's note of agreement is the next message on this thread on the INSIPID list). Basically, as the author of more than 50% of the requirements doc text and approximately 70% of the solution doc text (from a 2 draft WG) I'm intimately familiar with the topic. We, as a WG, have 2 existing legacy drafts that were never intended to reach RFC because they could never get any WG to reach consensus on either; I'm referring to draft-kaplan-insipid-session-id-00 and draft-kaplan-insipid-session-id-03 (neither is compatible the other). But, that didn't stop 3GPP from referencing one of the (the -03 version of the kaplan draft) - and only a few months ago it was decided in INSIPID that we would rather have kaplan-03 as a separate historic RFC than an appendix within the existing solution doc currently progressing in INSIPID. But alas, now with this magical change, the kaplan-03 _IS_ going to become an I-RFC, and it's going to be AD-sponsored, so the authors really don't have to abide by the INSIPID WG - and I have a problem with that on many levels. #1 - this bait-and-switch will produce a non-historic RFC, where there was NOT any specific call for consensus to do that reassignment on the INSIPID list. I deem that a process violation. #2 - with IETF LC about or actually over, one could interpret any failure of the INSIPID WG to produce a standards-track RFC with this kaplan-03 document as an informational RFC as INSIPID's meeting some measure of success within the WG, and that is not acceptable. Attempting to get WG consensus to point #1 would have addressed or at least fleshed this out. #3 - I firmly want what Dan refers to with his Major issue #1 below, in that, as a condition of the INSIPID WG successfully documenting a standards-track solution, this kaplan-03 draft can then be published - perhaps even consecutive RFCs - as an I-RFC that way the INSIPID solution RFC(to-be) does all the IANA registration because it has the lower RFC number. #4 - I am firmly opposed to the kaplan-03 draft IANA registering any part of the new Session-ID header. I would like to point out that if Dan's #1 major issue is worked out, his major issue #2 will also likely be worked out as a result of making the changes necessary for major issue #1. The kaplan-03 draft should be written with INSIPID's express plan to produce their own solution, with the intention of the kaplan-03 document being approved *after* the INSIPID solution is RFC'd. James Date: Thu, 22 Aug 2013 12:08:26 -0500 From: Robert Sparks rjspa...@nostrum.com To: Romascanu, Dan (Dan) droma...@avaya.com CC: gen-...@ietf.org gen-...@ietf.org, draft-kaplan-insipid-session-id@tools.ietf.org draft-kaplan-insipid-session-id@tools.ietf.org, insi...@ietf.org insi...@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt Adding the working group. Dan - thanks for this review. I've been working towards trying to express a concern, and this really helped clarify what was bothering me. This document, AFAIK, _is not_ actually trying to register the Session-ID header with IANA, even though there is a section that looks like it does. Rather, that registration is in http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ That is a very good example of how just adding the explanatory paragraph at the beginning of the document isn't enough to turn this into something that documents an earlier path considered and implementation that exists current deployments - the text needs to be touched in several places to make it clear that's what the document is doing. In the IANA considerations case, one possible adjustment is to change the text to here's what known implementations have used for syntax. See [draft-ietf-insipid-session-id] for the intended registered syntax, and not issue instructions to IANA. It's more work for Hadriel, but I think it's necessary. RjS On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document:
RE: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
At 02:43 04-09-2013, mohamed.boucad...@orange.com wrote: [Med] The document followed the IETF procedures and was benefited from the inputs and review of IETF participants; and as such it is an IETF document. We included text to precise this is not a standard but an informational document. FWIW, we formally asked for guidance from the wg in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time. There aren't any minutes for that WG session. Is there a formal request for guidance from the working group and is it possible to verify that there wasn't any comment at that time? I took a quick look at the draft. I note that, for the telechat, Spencer Dawkins and Pete Resnick are paid by the document. :-) It would be interesting to have an approximate page count of the number of pages to review. In the Introduction Section: One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices. I read the above sentence several times. My understanding is that having non-broken IPv6 implementations is a hurdle. The way to fix that would be for mobile operators to have broken IPv6 implementations. :-) In Section 1.2: It uses the normative keywords only for precision. My reading of the word precision is that it is the ability of a measurement to be consistently reproduced. I don't see how special language fits that. My guess is that the intent of that sentence got lost in translation ( http://www.youtube.com/watch?v=pCB7cxv-Ey8 ). In Section 2: REQ#3: The cellular host MUST comply with the behavior defined in [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-Context type. Is the above in accordance with RFC Editor guidelines? REQ#6: The device MUST support the Neighbor Discovery Protocol ([RFC4861] and [RFC5942]). In which RFCs are the Neighbor Discovery Protocol defined? I am asking this question as the above does not match the information provided by the RFC Editor. REQ#12: The cellular host SHOULD support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to learn PREFIX64 SHOULD be supported by the cellular host. How would the capitalized should be read in the above? The guidance in RFC 2119 does not look applicable here. In Section 5: REQ#34: Applications using URIs MUST follow [RFC3986]. For example, SIP applications MUST follow the correction defined in [RFC5954]. The above says that applications must follow RFC 3986 and then provides an example with a capitalized must for RFC 5954. The Security Considerations Section references draft-ietf-v6ops-rfc3316bis-04. That draft contains exhaustive security considerations. This draft doesn't say much about security considerations. Regards, -sm
Re: REVISED Last Call: draft-ietf-pwe3-vccv-impl-survey-results-02.txt (The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results) to Informational RFC
The Reviewer: Abdussalam Baryun Date: 05.09.2013 I-D name: draft-ietf-pwe3-vccv-impl-survey-results Received your Request dated 04.09.2013 ++ The reviewer supports the draft subject to amendments. Overall the survey is not easy to be used as source of information related to such technology users, but easier as source of information related to respondings of companies. AB I prefer the title to start as: A Survey of .. Abstract This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. AB How did the survey determine implementations related to users (are they general known or uknown or chosen by authors...etc). What kind of results? AB the abstract starts interesting but ends making the results not clear what it was (good, reasonable, expected, positive, had conclusions..etc)? AB The draft states that it has no conclusion, because it is not intended for that but to help in knowing results to help in other future drafts. However, the abstract mentions that the survey conducted to determine (not understood how to determine without conclusions or analysis). Introduction In order to assess the best approach to address the observed interoperability issues, the PWE3 working group decided to solicit feedback from the PW and VCCV user community regarding implementation. This document presents the survey and the information returned by the user community who participated. AB the introduction needs to show the importance of the survey, or what makes such decision from the WG (i.e. seems like the WG has not cover all types of community, not sure)? AB Why did the WG decide the survey by using questionnair? AB suggest amending the document presents the questionnair form questions and information returned .. Sections 1.1 1.2 and 1.3 ..questions based on direction of the WG chairs.. There were seventeen responses to the survey that met the validity requirements in Section 3. The responding companies are listed below in Section 2.1. AB Why were thoes methodologies and why that way of quetions chosen for this survey? The answer to this is important for the document (informational) and future drafts. AB The reason of the survey's methodology should be mentioned in clear section, as the athors' opinion. Section 1.2 Form Why the form did not make security consideration related to implementations in the form questions? which then may be used in security section. Results section 2 AB are difficult to read or find related to section 1.2. AB Usually the section mixes between what was returned and what was given. It is prefered to have two separate sections as 1 (what was given including the form), and what was returned as results. Regards AB On 9/4/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results' draft-ietf-pwe3-vccv-impl-survey-results-02.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-09-23. 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 Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) to carry information essential to the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and to discriminate Operations, Administration, and Maintenance (OAM) from Pseudowire (PW) packets. However, some encapsulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/ VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/ballot/ No IPR declarations have been submitted directly on this I-D.
REVISED Last Call: draft-ietf-pwe3-vccv-impl-survey-results-02.txt (The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results) to Informational RFC
The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'The Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results' draft-ietf-pwe3-vccv-impl-survey-results-02.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 i...@ietf.org mailing lists by 2013-09-23. 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 Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) to carry information essential to the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and to discriminate Operations, Administration, and Maintenance (OAM) from Pseudowire (PW) packets. However, some encapsulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/ VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/ballot/ No IPR declarations have been submitted directly on this I-D.
New Mailing List: Internet governance and IETF technical work
As requested by the community, the IAB has decided to open a mailing list to discuss topics regarding the intersection of Internet governance and IETF technical work. In particular, this list will focus on issues relating to Internet governance and regulation, including the 2014 ITU Plenipotentiary Conference, and their potential to impact the future of the Internet architecture. In that regard, the community is invited to participate in this mailing list with an eye toward both receiving more information about these events and advising the IAB by identifying key issues for which the board may wish to provide technical clarifications on how certain policy outcomes could impact the Internet architecture. Examples could include IPv6 deployment, spam, cybersecurity, and obstacles or challenges to Internet adoption. This will be an IAB maintained list, and will be subject to normal IETF process (such as the NOTE WELL statement). This new email list is: internetgovt...@iab.org . To join, please visit the web page: https://www.iab.org/mailman/listinfo/internetgovtech The list is specifically not a general discussion list for all issues relating to the ITU or even Internet Governance. ISOC will be posting information about ISOC mailing lists for more general policy discussions. Because Internet governance is often a sensitive topic and passions often run high, while anyone from the IETF community is welcome, those who join the list will be expected to stay within the parameters above (e.g., receiving information and providing constructive advice to the IAB) and to comport themselves in a respectful way toward all. To encourage inclusion, we are asking that individuals avoid repetitive or excessive posting. The IAB's ITU-T Coordination Program Leads (currently Ross Callon and Joel Halpern) may, at their sole discretion, remove or moderate individuals whose posting is not of assistance to the IAB or, in the opinion of the Program Leads, of benefit to the IETF community. On behalf of the IAB, Russ Housley IAB Chair
Resend: RFC 6986 on GOST R 34.11-2012: Hash Function
Resending the announcement. RFC 6986 has been available since it originally announced. On Wed, Aug 28, 2013 at 05:06:49PM -0700, RFC Editor wrote: A new Request for Comments is now available in online RFC libraries. RFC 6986 Title: GOST R 34.11-2012: Hash Function Author: V. Dolmatov, Ed., A. Degtyarev Status: Informational Stream: Independent Date: August 2013 Mailbox:d...@cryptocom.ru, ale...@renatasystems.org Pages: 40 Characters: 78975 Updates:RFC 5831 I-D Tag:draft-dolmatov-gost34112012-01.txt URL:http://www.rfc-editor.org/rfc/rfc6986.txt This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831. 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/search/rfc_search.php 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
Re: RFC 7008 on A Description of the KCipher-2 Encryption Algorithm
Resending the announcement. RFC 7008 has been available since it was originally announced. On Wed, Aug 28, 2013 at 05:07:22PM -0700, RFC Editor wrote: A new Request for Comments is now available in online RFC libraries. RFC 7008 Title: A Description of the KCipher-2 Encryption Algorithm Author: S. Kiyomoto, W. Shin Status: Informational Stream: Independent Date: August 2013 Mailbox:kiyom...@kddilabs.jp, ohp...@hanmail.net Pages: 37 Characters: 71051 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-kiyomoto-kcipher2-09.txt URL:http://www.rfc-editor.org/rfc/rfc7008.txt This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan. 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/search/rfc_search.php 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 7002 on RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting
A new Request for Comments is now available in online RFC libraries. RFC 7002 Title: RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting Author: A. Clark, G. Zorn, Q. Wu Status: Standards Track Stream: IETF Date: September 2013 Mailbox:alan.d.cl...@telchemy.com, glenz...@gmail.com, sunse...@huawei.com Pages: 12 Characters: 22523 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-xrblock-rtcp-xr-discard-15.txt URL:http://www.rfc-editor.org/rfc/rfc7002.txt This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications. This document is a product of the Metric Blocks for use with RTCPs Extended Report Framework 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/search/rfc_search.php 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 7003 on RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting
A new Request for Comments is now available in online RFC libraries. RFC 7003 Title: RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting Author: A. Clark, R. Huang, Q. Wu, Ed. Status: Standards Track Stream: IETF Date: September 2013 Mailbox:alan.d.cl...@telchemy.com, rac...@huawei.com, sunse...@huawei.com Pages: 14 Characters: 25970 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14.txt URL:http://www.rfc-editor.org/rfc/rfc7003.txt This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications. This document is a product of the Metric Blocks for use with RTCPs Extended Report Framework 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/search/rfc_search.php 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 7004 on RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting
A new Request for Comments is now available in online RFC libraries. RFC 7004 Title: RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting Author: G. Zorn, R. Schott, Q. Wu, Ed., R. Huang Status: Standards Track Stream: IETF Date: September 2013 Mailbox:glenz...@gmail.com, roland.sch...@telekom.de, sunse...@huawei.com, rac...@huawei.com Pages: 21 Characters: 41795 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-xrblock-rtcp-xr-summary-stat-11.txt URL:http://www.rfc-editor.org/rfc/rfc7004.txt This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications. This document is a product of the Metric Blocks for use with RTCPs Extended Report Framework 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/search/rfc_search.php 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 7005 on RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting
A new Request for Comments is now available in online RFC libraries. RFC 7005 Title: RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting Author: A. Clark, V. Singh, Q. Wu Status: Standards Track Stream: IETF Date: September 2013 Mailbox:alan.d.cl...@telchemy.com, va...@comnet.tkk.fi, sunse...@huawei.com Pages: 14 Characters: 27050 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-xrblock-rtcp-xr-jb-14.txt URL:http://www.rfc-editor.org/rfc/rfc7005.txt This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications. This document is a product of the Metric Blocks for use with RTCPs Extended Report Framework 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/search/rfc_search.php 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 7018 on Auto-Discovery VPN Problem Statement and Requirements
A new Request for Comments is now available in online RFC libraries. RFC 7018 Title: Auto-Discovery VPN Problem Statement and Requirements Author: V. Manral, S. Hanna Status: Informational Stream: IETF Date: September 2013 Mailbox:vishwas.man...@hp.com, sha...@juniper.net Pages: 12 Characters: 27284 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-ad-vpn-problem-09.txt URL:http://www.rfc-editor.org/rfc/rfc7018.txt This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements. This document is a product of the IP Security Maintenance and Extensions 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/search/rfc_search.php 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
