Re: [ANCP] Last Call: draft-ietf-ancp-pon-04.txt (Applicability of Access Node Control Mechanism to PON based Broadband Networks) to Informational RFC
Note that this last call is a second last call, to gather comments on the publication of the document considering the IPR disclosures that were published late in the previous IETF last call. - Ralph On Feb 5, 2013, at 3:57 PM 2/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Access Node Control Protocol WG (ancp) to consider the following document: - 'Applicability of Access Node Control Mechanism to PON based Broadband Networks' draft-ietf-ancp-pon-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.org mailing lists by 2013-02-19. 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 The purpose of this document is to provide applicability of the Access Node Control mechanism to PON-based broadband access. The need for an Access Node Control mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to-device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1734/ ___ ANCP mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/ancp
Re: Comments on draft-eastlake-additional-xmlsec-uris-07.txt
On 2/6/13 11:25 PM, SM wrote: Hi Donald, At 18:48 06-02-2013, Donald Eastlake wrote: I'm not sure exactly what you mean here. The errata does appear in the references as [Errata191] - RFC Errata, Errata ID 191, RFC 4051, http://www.rfc- editor.org I have been told by an Area Director that this it the format that the RFC Editor likes. You can certainly find the Errata starting with that link and by just linking to the main ref-editor.org web page, it does not constrain the other structure of that web site. [Errata191] was a normative reference. Referencing errata in an intended Proposed Standard might be a trivial matter. There are side effects to that. That may only be apparent in the long term. I hope that the RFC Editor does not plan to turn Standard Track RFCs into living standards. The format for the reference is what the RFC Editor suggests, but it hasn't been properly documented yet. There is still open discussion about what the appropriate URL should be which in turn impacts that part of the reference. Having errata as normative references does not seem like a good idea to me, so I'm glad to see it has been shifted to an informative reference. I admit, I am unclear what you mean by turning Standard Track RFCs in to living standards; think the process for updating RFCs as new information is developed by creating new RFCs to update or obsolete the older ones is a perfectly reasonable approach. OK. I will move the Errata to the Informational references. See above. I disagree. I believe acknowledgments are very important and should be at the front. I commonly (but not always) put them there in my drafts. I am also not aware of any IETF rule prescribing where Acknowledgements go in Internet Drafts. It is true that the RFC Editor always move them to the end, but that's the way it goes. I noticed that you are one of the rare authors who has the Acknowledgements at the beginning of their document. It was a practice followed in some of the three-digit RFCs. There isn't any requirement in the RFC Style Guide which prohibits the Acknowledgements from being at the front of the document. Since one of the broadest guidelines we work under states make current RFCs look like the previous ones, we do generally put the Acknowledgements and Contributes towards the end of the document. No, it is not absolutely required but we do think it makes more sense. The guidance on section ordering is something that will be discussed as part of the revised Style Guide. I don't know whether it is relevant but John Klensin mentioned this a few days ago: One might even suggest that one of the reasons early ARPANET/ Internet developments worked better than the IETF process of today is that there was wide recognition that it was necessarily a collaborative effort with many people contributing ideas and no one wanting to seize credit. This has been an area of personal confusion for me as I try to understand IETF culture, but I'll leave discussing it to a bar BoF or something. -Heather Flanagan, RSE Section 5 mentions that This document requires no IANA actions. However, there is another paragraph in the IANA Considerations section which is not even actionable by IANA folks. I am not sure whether the text should go into that section. In Section 1: Note that raising XML Digital Signature to Draft Standard [RFC3275] in the IETF required removal of any algorithms for which there was not demonstrated interoperability from the Proposed Standard document. This required removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest. The URI for Minimal Canonicalization was included in [RFC4051] and is included here. That was the historic rationale for the different levels in the Standards Track. Rumor has it that although the rationale was forgotten, whether intentionally or not, the MUST wars continued. Dave Crocker once raised the question of complexity of a specification. Advancement along the Standards could have been used to make a specification less complex by trimming stuff which has not been implemented (see quoted text above). In Section 2.1.1: The content of the DigestValue element shall be the base64 [RFC2045] encoding of this bit string viewed as a 16-octet octet stream. RFC 4648 could be reference instead of RFC 2045. Regards, -sm
IMPORANT: Comments on draft-eastlake-additional-xmlsec-uris-08
Don I've received feedback from XML Security working group members that propose you change the URIs in the draft RFC for AES Key Wrap with Padding to match what is in XML Encryption 1.1, both because we are going to Recommendation and because there is code that currently uses those values. Can you please make the change, using the xmlenc11 URIs I listed below in item 1? Thanks regards, Frederick Frederick Hirsch Nokia On Feb 7, 2013, at 11:04 AM, wrote: Donald Some additional comments on draft http://tools.ietf.org/pdf/draft-eastlake-additional-xmlsec-uris-08.pdf sorry about the delay getting these comments to you. (1) We have defined different *informative* URIs for AES Key Wrap with Padding in XML Encryption 1.1 [http://www.w3.org/TR/xmlenc-core1/#sec-kw-aes-with-pad] which are different from those in the RFC, namely http://www.w3.org/2009/xmlenc11#kw-aes-128-pad http://www.w3.org/2009/xmlenc11#kw-aes-192-pad http://www.w3.org/2009/xmlenc11#kw-aes-256-pad I suggest we change this informative appendix of XML Encryption 1.1 (and the Security Algorithms Cross-Reference) to match what is in the RFC draft. Thomas, is there any problem with that at this PR stage? Those in the RFC draft are: http://www.w3.org/2007/05/xmldsig-more#kw-aes128-pad http://www.w3.org/2007/05/xmldsig-more#kw-aes192-pad http://www.w3.org/2007/05/xmldsig-more#kw-aes256-pad (2) ConcatKDF fragment needs fixing in 4.1 and change log Appendix A due to a typo 2009/xmlenc11#ConctKDF [XMLENC] should be 2009/xmlenc11#ConcatKDF [XMLENC] #ConctKDF, should be #ConcatKDF, (3) To some degree the fragment index and URI index replicate the published W3C Note, XML Security Algorithm Cross-Reference and could be incorporated there. (4) I suggest an update to the Introduction to mention XML Security 1.1 as follows after All of these standards and recommendations use URIs [RFC3986] to identify algorithms and keying information types. add The W3C has subsequently produced updated XML Signature 1.1 [XMLDSIG11] and XML Encryption 1.1 [XMLENC11} versions as well as a new XML Signature Properties specification [XMLDSIG-PROPERTIES]. (5) Typo in introduction Canoncialization should be Canonicalization (6) References Add references to XML Signature 1.1, XML Encryption 1.1, XML Signature Properties, XML Security Algorithm Cross-Reference (all to be updated upon Recommendation publication) Signature properties has added a namespace: xmlns dsp=http://www.w3.org/2009/xmldsig-properties; [XMLDSIG-CORE1] D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. XML Signature Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL:http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/ [XMLENC-CORE1] J. Reagle; D. Eastlake; F. Hirsch; T. Roessler. XML Encryption Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL:http://www.w3.org/TR/2013/PR-xmlenc-core1-20130124/ [XMLDSIG-PROPERTIES] Frederick Hirsch. XML Signature Properties. 24 January 2013. W3C Proposed Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2013/PR-xmldsig-properties-20130124/ [XMLSEC-ALGS] F Hirsch, T Roessler, K Yiu XML Security Algorithm Cross-Reference, 24 January 2013 W3C Working Group Note http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130124/ regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG
Re: IMPORANT: Comments on draft-eastlake-additional-xmlsec-uris-08
Thanks Donald I missed the fact that the references were combined. Please let me know the RFC # and info I need to update the W3C documents as soon as it is clear. regards, Frederick Frederick Hirsch Nokia On Feb 7, 2013, at 5:27 PM, ext Donald Eastlake wrote: Hi Frederick, On Thu, Feb 7, 2013 at 4:24 PM, frederick.hir...@nokia.com wrote: Don I've received feedback from XML Security working group members that propose you change the URIs in the draft RFC for AES Key Wrap with Padding to match what is in XML Encryption 1.1, both because we are going to Recommendation and because there is code that currently uses those values. Can you please make the change, using the xmlenc11 URIs I listed below in item 1? Sure, I'll do that. Thanks regards, Frederick Frederick Hirsch Nokia On Feb 7, 2013, at 11:04 AM, wrote: Donald Some additional comments on draft http://tools.ietf.org/pdf/draft-eastlake-additional-xmlsec-uris-08.pdf sorry about the delay getting these comments to you. (1) We have defined different *informative* URIs for AES Key Wrap with Padding in XML Encryption 1.1 [http://www.w3.org/TR/xmlenc-core1/#sec-kw-aes-with-pad] which are different from those in the RFC, namely http://www.w3.org/2009/xmlenc11#kw-aes-128-pad http://www.w3.org/2009/xmlenc11#kw-aes-192-pad http://www.w3.org/2009/xmlenc11#kw-aes-256-pad I suggest we change this informative appendix of XML Encryption 1.1 (and the Security Algorithms Cross-Reference) to match what is in the RFC draft. Thomas, is there any problem with that at this PR stage? Those in the RFC draft are: http://www.w3.org/2007/05/xmldsig-more#kw-aes128-pad http://www.w3.org/2007/05/xmldsig-more#kw-aes192-pad http://www.w3.org/2007/05/xmldsig-more#kw-aes256-pad As above, I'll change the draft to use the ...//2009/xmlenc11#... URIs. (2) ConcatKDF fragment needs fixing in 4.1 and change log Appendix A due to a typo 2009/xmlenc11#ConctKDF [XMLENC] should be 2009/xmlenc11#ConcatKDF [XMLENC] #ConctKDF, should be #ConcatKDF, OK. (3) To some degree the fragment index and URI index replicate the published W3C Note, XML Security Algorithm Cross-Reference and could be incorporated there. If you would like to incorporate this information there, that seems fine. But I'd like to leave it in the draft also. (4) I suggest an update to the Introduction to mention XML Security 1.1 as follows after All of these standards and recommendations use URIs [RFC3986] to identify algorithms and keying information types. add The W3C has subsequently produced updated XML Signature 1.1 [XMLDSIG11] and XML Encryption 1.1 [XMLENC11} versions as well as a new XML Signature Properties specification [XMLDSIG-PROPERTIES]. OK. (5) Typo in introduction Canoncialization should be Canonicalization OK. (6) References Add references to XML Signature 1.1, XML Encryption 1.1, XML Signature Properties, XML Security Algorithm Cross-Reference (all to be updated upon Recommendation publication) The current draft does have references to XML Signature 1.1 and XML Encryption 1.1. The RFC Reference format permits multiple document under a single tag and both 1.0 and 1.1 are included under the [XMLDSIG] and [XMLENC] tags. I'll add the other two documents. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Signature properties has added a namespace: xmlns dsp=http://www.w3.org/2009/xmldsig-properties; [XMLDSIG-CORE1] D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. XML Signature Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL:http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/ [XMLENC-CORE1] J. Reagle; D. Eastlake; F. Hirsch; T. Roessler. XML Encryption Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL:http://www.w3.org/TR/2013/PR-xmlenc-core1-20130124/ [XMLDSIG-PROPERTIES] Frederick Hirsch. XML Signature Properties. 24 January 2013. W3C Proposed Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2013/PR-xmldsig-properties-20130124/ [XMLSEC-ALGS] F Hirsch, T Roessler, K Yiu XML Security Algorithm Cross-Reference, 24 January 2013 W3C Working Group Note http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130124/ regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG
Re: [ANCP] Last Call: draft-ietf-ancp-pon-04.txt (Applicability ofAccess Node Control Mechanism to PON based Broadband Networks)to Informational RFC
Ralph, for clarification ... is there more than the one IP disclosure at http://datatracker.ietf.org/ipr/1734/ ? The term disclosures lead me to believe there may be more than one George T. Willingmyre, P.E. President GTW Associates -Original Message- From: Ralph Droms Sent: Friday, February 08, 2013 10:53 AM To: ietf@ietf.org Cc: a...@ietf.org Subject: Re: [ANCP] Last Call: (Applicability ofAccess Node Control Mechanism to PON based Broadband Networks)to Informational RFC Note that this last call is a second last call, to gather comments on the publication of the document considering the IPR disclosures that were published late in the previous IETF last call. - Ralph On Feb 5, 2013, at 3:57 PM 2/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Access Node Control Protocol WG (ancp) to consider the following document: - 'Applicability of Access Node Control Mechanism to PON based Broadband Networks' draft-ietf-ancp-pon-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.org mailing lists by 2013-02-19. 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 The purpose of this document is to provide applicability of the Access Node Control mechanism to PON-based broadband access. The need for an Access Node Control mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to-device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1734/ ___ ANCP mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/ancp
Re: [ANCP] Last Call: draft-ietf-ancp-pon-04.txt (Applicability ofAccess Node Control Mechanism to PON based Broadband Networks)to Informational RFC
On Feb 8, 2013, at 4:07 PM 2/8/13, GTW g...@gtwassociates.com wrote: Ralph, for clarification ... is there more than the one IP disclosure at http://datatracker.ietf.org/ipr/1734/ ? The term disclosures lead me to believe there may be more than one Good catch. Typo on my part. There is just the one disclosure. - Ralph George T. Willingmyre, P.E. President GTW Associates -Original Message- From: Ralph Droms Sent: Friday, February 08, 2013 10:53 AM To: ietf@ietf.org Cc: a...@ietf.org Subject: Re: [ANCP] Last Call: (Applicability ofAccess Node Control Mechanism to PON based Broadband Networks)to Informational RFC Note that this last call is a second last call, to gather comments on the publication of the document considering the IPR disclosures that were published late in the previous IETF last call. - Ralph On Feb 5, 2013, at 3:57 PM 2/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Access Node Control Protocol WG (ancp) to consider the following document: - 'Applicability of Access Node Control Mechanism to PON based Broadband Networks' draft-ietf-ancp-pon-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.org mailing lists by 2013-02-19. 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 The purpose of this document is to provide applicability of the Access Node Control mechanism to PON-based broadband access. The need for an Access Node Control mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to-device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1734/ ___ ANCP mailing list a...@ietf.org https://www.ietf.org/mailman/listinfo/ancp
The RFC Acknowledgement
Hi folks, I am wondering how author/ietf-editor fill in the acknowledgement section in the RFCs or I-Ds. Does it make sense in IETF, or left for author opinion? I am getting requests from IETF WGs, IESG, and IAB for comments. My question is do you *make acknowledgements* in I-Ds or just *take comments* for I-Ds? IMO we get last call request for comments because RFC production is all about getting volunteering comments from Internet community to make I-Ds better, so does all I-Ds acknowledge (ACK) to any input comment before the last call and after or it is only before last call?, and if it gets submitted to IESG/IAB, and we comment does that have no ACK in I-D? I sometimes feel discouraged to participate in any world work if the process does not involve my existance, just used with ignoring ACK of the reviewers. IMO any comment has value to the authors (e.g. some think only experts' comments are important to ACK) and to IETF, otherwise, we may delete valuable ACKs in IETF, which is not right. Best Regards AB A participant that still did not complete a year working for IETF, but trying to continue :)
Re: The RFC Acknowledgement
I try to include in the Acknowledgements section of any Internet Drafts I edit the names of anyone who comments on the draft if (1) the comment results in a change in the draft and (2) the commenter does not request that they be left out. If you comment on some draft and the draft is changed as a result and you want to be acknowledged and you are not added to the acknowledgements list, you should complain to the editor / author. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Feb 8, 2013 at 10:11 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi folks, I am wondering how author/ietf-editor fill in the acknowledgement section in the RFCs or I-Ds. Does it make sense in IETF, or left for author opinion? I am getting requests from IETF WGs, IESG, and IAB for comments. My question is do you *make acknowledgements* in I-Ds or just *take comments* for I-Ds? IMO we get last call request for comments because RFC production is all about getting volunteering comments from Internet community to make I-Ds better, so does all I-Ds acknowledge (ACK) to any input comment before the last call and after or it is only before last call?, and if it gets submitted to IESG/IAB, and we comment does that have no ACK in I-D? I sometimes feel discouraged to participate in any world work if the process does not involve my existance, just used with ignoring ACK of the reviewers. IMO any comment has value to the authors (e.g. some think only experts' comments are important to ACK) and to IETF, otherwise, we may delete valuable ACKs in IETF, which is not right. Best Regards AB A participant that still did not complete a year working for IETF, but trying to continue :)
Re: The RFC Acknowledgement
On 2/8/13 6:36 PM, Donald Eastlake wrote: I try to include in the Acknowledgements section of any Internet Drafts I edit the names of anyone who comments on the draft if (1) the comment results in a change in the draft and (2) the commenter does not request that they be left out. If you comment on some draft and the draft is changed as a result and you want to be acknowledged and you are not added to the acknowledgements list, you should complain to the editor / author. Really? I only expect to be acknowledged when I've got text included or have made some other significant contribution. Melinda
Re: The RFC Acknowledgement
--On Friday, February 08, 2013 18:42 -0900 Melinda Shore melinda.sh...@gmail.com wrote: On 2/8/13 6:36 PM, Donald Eastlake wrote: I try to include in the Acknowledgements section of any Internet Drafts I edit the names of anyone who comments on the draft if (1) the comment results in a change in the draft and (2) the commenter does not request that they be left out. If you comment on some draft and the draft is changed as a result and you want to be acknowledged and you are not added to the acknowledgements list, you should complain to the editor / author. Really? I only expect to be acknowledged when I've got text included or have made some other significant contribution. Remembering that we've managed to get ourselves into a situation in which there is a IPR policy-based requirement for some acknowledgements, do we really need to debate this topic rather than saying author/editor discretion as long as the author or editor is sensitive to requests for inclusion or exclusion and to the IPR policy requirements about substantive Contributions. My personal instincts as an author run somewhat closer to Melinda's criterion than to Don's but my bigger concern is that trying to make specific rules about this will result in an extended rat hole tour that ends up with rules that don't work well for edge cases we don't anticipate. john
I-D affects another or work in ietf groups
Hi folks, Related to one discussion with a participant about I-Ds affecting WGs, I have a question after reading two real incidents. The following two work process examples are to show the I-Ds/RFCs affects from participants point of view; 1) I got an understanding from one expert participant that his I-D is not related to one RFC, even though it does involve similar objectives and use-case, which was strange to me. So I understood from him that his I-D is not affected by that RFC, even though his I-D does not mention to exclude that RFC. IMO, I disagree with such producing I-D by separate review-approach unaffected by other related RFCs (i.e. not mentioned RFCs). 2) While I was discussing within a WG about an I-D which is a second version of one IETF prorocol, some participants thought that the I-D obsolete the old version even if not mentioned in the I-D. It then was requested to update and mention that it does not obsolete the older version. New versions are related and can affect each other, or affect people understanding, which requires more careful presentation for such I-D. I beleive that we have one source of producing RFCs, so all I-Ds and RFCs are related some how, and they affect each other. So when I review an item, I always like to consider all RFCs as much as I can to make Internet better. Is that approach right for review? please advise, AB
Re: The RFC Acknowledgement
Hi Donald, The problem is that most people don't complain or don't like to complain, that is reality, they will leave such society easily. So does the IETF have some kind of self check without the commentor complaining. I suggest the WG chair to maintain the WG I-Ds, and if individual I-D then the AD responsible to maintain that, AB On 2/9/13, Donald Eastlake d3e...@gmail.com wrote: I try to include in the Acknowledgements section of any Internet Drafts I edit the names of anyone who comments on the draft if (1) the comment results in a change in the draft and (2) the commenter does not request that they be left out. If you comment on some draft and the draft is changed as a result and you want to be acknowledged and you are not added to the acknowledgements list, you should complain to the editor / author. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Feb 8, 2013 at 10:11 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi folks, I am wondering how author/ietf-editor fill in the acknowledgement section in the RFCs or I-Ds. Does it make sense in IETF, or left for author opinion? I am getting requests from IETF WGs, IESG, and IAB for comments. My question is do you *make acknowledgements* in I-Ds or just *take comments* for I-Ds? IMO we get last call request for comments because RFC production is all about getting volunteering comments from Internet community to make I-Ds better, so does all I-Ds acknowledge (ACK) to any input comment before the last call and after or it is only before last call?, and if it gets submitted to IESG/IAB, and we comment does that have no ACK in I-D? I sometimes feel discouraged to participate in any world work if the process does not involve my existance, just used with ignoring ACK of the reviewers. IMO any comment has value to the authors (e.g. some think only experts' comments are important to ACK) and to IETF, otherwise, we may delete valuable ACKs in IETF, which is not right. Best Regards AB A participant that still did not complete a year working for IETF, but trying to continue :)
Re: The RFC Acknowledgement
I try to include in the Acknowledgements section of any Internet Drafts I edit the names of anyone who comments on the draft if (1) the comment results in a change in the draft and (2) the commenter does not request that they be left out. If you comment on some draft and the draft is changed as a result and you want to be acknowledged and you are not added to the acknowledgements list, you should complain to the editor / author. That's exactly the policy Nathaniel Borenstein and I agreed to use for MIME. I've used it ever since for all the documents I have edited, and it seems to have worked well. (And apologies to anyone whose name I have omitted under that policy - if I did that it was entirely inadvertent.) The only time I've ever had an acknowledgments section has been when an author or contributor is deceased. This very unfortunate situation is quite delicate and merits handling on a case-by-case basis; IMO no specific policy could possibly be written to accomodate it. Ned
Re: The RFC Acknowledgement
On 2/8/13 6:55 PM, John C Klensin wrote: Remembering that we've managed to get ourselves into a situation in which there is a IPR policy-based requirement for some acknowledgements, do we really need to debate this topic rather than saying author/editor discretion as long as the author or editor is sensitive to requests for inclusion or exclusion and to the IPR policy requirements about substantive Contributions. That's my sense as well, and I think it makes a lot of sense in terms of process/overhead to just leave it up to the discretion of chairs and editors. The notion of acknowledging every single person who stepped up to the mic and made any comment, or who posted to a mailing list, seems a bit over-the-top to me. Melinda
Re: I-D affects another or work in ietf groups
Speaking for myself, I would say that an internet draft is relevant to work in a working group if and only if it is covered by the charter of the working group. Anyone can claim anything to dodge the requirement that they ask relevant groups to review it. That doesn't make the claim true. In the event that you need a ruling, I would suggest discussing it with the relevant chairs and, if necessary, ADs. Generally speaking, they will have no axe to grind and can give you a reasonably objective answer. On Feb 8, 2013, at 7:56 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi folks, Related to one discussion with a participant about I-Ds affecting WGs, I have a question after reading two real incidents. The following two work process examples are to show the I-Ds/RFCs affects from participants point of view; 1) I got an understanding from one expert participant that his I-D is not related to one RFC, even though it does involve similar objectives and use-case, which was strange to me. So I understood from him that his I-D is not affected by that RFC, even though his I-D does not mention to exclude that RFC. IMO, I disagree with such producing I-D by separate review-approach unaffected by other related RFCs (i.e. not mentioned RFCs). 2) While I was discussing within a WG about an I-D which is a second version of one IETF prorocol, some participants thought that the I-D obsolete the old version even if not mentioned in the I-D. It then was requested to update and mention that it does not obsolete the older version. New versions are related and can affect each other, or affect people understanding, which requires more careful presentation for such I-D. I beleive that we have one source of producing RFCs, so all I-Ds and RFCs are related some how, and they affect each other. So when I review an item, I always like to consider all RFCs as much as I can to make Internet better. Is that approach right for review? please advise, AB
Re: The RFC Acknowledgement
On Feb 8, 2013, at 7:55 PM, John C Klensin john-i...@jck.com wrote: My personal instincts as an author run somewhat closer to Melinda's criterion than to Don's but my bigger concern is that trying to make specific rules about this will result in an extended rat hole tour that ends up with rules that don't work well for edge cases we don't anticipate. Yes. I tend to acknowledge comments on a draft, and to separately acknowledge comments that included text or which resulted in large changes - I do both Don and Melinda's algorithms. The important thing is, though, to be liberal in what one includes, and to be conservative in the application of legalistic rules.
Re: The RFC Acknowledgement
On 09/02/2013 03:55, John C Klensin wrote: ... My personal instincts as an author run somewhat closer to Melinda's criterion than to Don's but my bigger concern is that trying to make specific rules about this will result in an extended rat hole tour that ends up with rules that don't work well for edge cases we don't anticipate. In complete violation of the spirit of draft-resnick-on-consensus, I will limit my comment to +1. Can we discuss something technical, please? Brian
Ongoing Call for Comment: 'Privacy Considerations for Internet Protocols'
This is a reminder of an ongoing IETF-wide Call for Comment on 'Privacy Considerations for Internet Protocols'. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: http://tools.ietf.org/html/draft-iab-privacy-considerations The Call for Comment will last until February 18, 2013. Please send comments to iab at iab.org or submit them via TRAC (see below). === Submitting Comments via TRAC 1. To submit an issue in TRAC, you first need to login to the IAB site on the tools server: http://tools.ietf.org/wg/iab/trac/login 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/iab/trac/newticket 4. When opening an issue: a. The Type: field should be set to defect for an issue with the current document text, or enhancement for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically minor or trivial. c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. e. The Version: field should be set to 1.0. f. The Severity: field should be set to based on the status of the document (e.g. In WG Last Call for a document in IAB last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select I have files to attach to this ticket. 6. If you want to preview your Issue, click on the Preview button. When you're ready to submit the issue, click on the Create Ticket button. 7. If you want to update an issue, go to the View Tickets page: http://trac.tools.ietf.org/wg/iab/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required.
Ongoing Call for Comment: 'Issues in Identifier Comparison for Security Purposes'
This is a reminder of an ongoing IETF-wide Call for Comment on 'Issues in Identifier Comparison for Security Purposes'. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: http://tools.ietf.org/html/draft-iab-identifier-comparison The Call for Comment will last until February 10, 2013. Please send comments to iab at iab.org or submit them via TRAC (see below). === Submitting Comments via TRAC 1. To submit an issue in TRAC, you first need to login to the IAB site on the tools server: http://tools.ietf.org/wg/iab/trac/login 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/iab/trac/newticket 4. When opening an issue: a. The Type: field should be set to defect for an issue with the current document text, or enhancement for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically minor or trivial. c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. e. The Version: field should be set to 1.0. f. The Severity: field should be set to based on the status of the document (e.g. In WG Last Call for a document in IAB last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select I have files to attach to this ticket. 6. If you want to preview your Issue, click on the Preview button. When you're ready to submit the issue, click on the Create Ticket button. 7. If you want to update an issue, go to the View Tickets page: http://trac.tools.ietf.org/wg/iab/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required.
Document Action: 'Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties' to Informational RFC (draft-ietf-sidr-usecases-06.txt)
The IESG has approved the following document: - 'Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties' (draft-ietf-sidr-usecases-06.txt) as Informational RFC This document is the product of the Secure Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sidr-usecases/ Technical Summary This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. Working Group Summary One reviewer suggested to expand the usecases to cover ongoing work that is out of the scope of the current document. The draft as is has utility at the present time. Future documents can address additional usecases if and when needed. Nothing else to report, apart from the document taking a bit longer in the WG than expected. Document Quality Several prototype implementations (and even commercial for some parts) exist. Reviewers attention is drawn to the Section 1.2 which describes why RFC1918 prefixes are used rather than the RFC5737 prefixes. This was discussed in the Working Group and was the agreed way forward. Personnel Alexey Melnikov is the document shepherd. Stewart Bryant is the Responsible AD. RFC Editor Note In the acknowledgements please s/Stephen Farrel/Stephen Farrell/
RFC 6864 on Updated Specification of the IPv4 ID Field
A new Request for Comments is now available in online RFC libraries. RFC 6864 Title: Updated Specification of the IPv4 ID Field Author: J. Touch Status: Standards Track Stream: IETF Date: February 2013 Mailbox:to...@isi.edu Pages: 19 Characters: 44418 Updates:RFC791, RFC1122, RFC2003 I-D Tag:draft-ietf-intarea-ipv4-id-update-07.txt URL:http://www.rfc-editor.org/rfc/rfc6864.txt The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK] This document is a product of the Internet 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
RFC 6869 on vCard KIND:device
A new Request for Comments is now available in online RFC libraries. RFC 6869 Title: vCard KIND:device Author: G. Salgueiro, J. Clarke, P. Saint-Andre Status: Standards Track Stream: IETF Date: February 2013 Mailbox:gsalg...@cisco.com, jcla...@cisco.com, psain...@cisco.com Pages: 9 Characters: 14648 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-salgueiro-vcarddav-kind-device-07.txt URL:http://www.rfc-editor.org/rfc/rfc6869.txt This document defines a value of device for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK] 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
