Re: Last Call: draft-ietf-ospf-manet-single-hop-mdr-03.txt (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
I send my request to the editors including questions but no reply from them to me. The thread [1] raised some issues, which is not mentioned in the I-D. The message [2] was ignored not answered (this is last reminder). The message [3] proposes using RFC5444 into this I-D, or raise the question of why not using MANET packet format within MANET domains (I need an answer). [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html The I-D SHOULD not go forward if it still ignores the IETF community questions. Regards AB On 6/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' draft-ietf-ospf-manet-single-hop-mdr-03.txt as Experimental 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-06-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 RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Hugh Daniel has passed away
I am sad to hear about this. I remember Hugh from various IPsec test events. And the lights… I still remember the lights. Jari
Re: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
A couple of minor comments: - For some unfathomable reason IEEE people seem to call mailing lists reflectors - that might be worth a mention. Section 4 otherwise seems repetitive. - 3.3.1.4 says: Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted. That's a pretty bogus setup. I would think that if IEEE do want to share some or all drafts with us they could much more easily create a web page when those drafts are available without access control. Or we could if they didn't mind. (Or I could do it if there's no we that wants to:-) Asking IETF WG chairs to deal with passwords is a bit silly. I'm not objecting to this, but am suggesting someone ask IEEE if they'd like to consider the silliness here and fix it. S. On 06/05/2013 07:50 PM, IAB Chair wrote: This is a call for review of The IEEE 802 / IETF Relationship prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-rfc4441rev/ The Call for Review will last until 20 June 2013. Please send comments to i...@iab.org. On behalf of the IAB, Russ Housley IAB Chair
Re: Hugh Daniel has passed away
Paul Wouters p...@cypherpunks.ca writes: Hugh Daniel passed away on June 3rd after what appears to have been a heart attack. I remember many interesting moments and conversations within the times that I talked with him. He was a very memorable person. But certainly the one that stands out in my mind the most was our first encounter. He wrote me over email as we were arranging a time and place to meet and ended it with I'll be wearing a red shirt; you won't miss me. I thought at the time that was quite a declaration. And indeed I did not miss him that day. I do now, however. -- Wes Hardaker Parsons
RE: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
Asking IETF WG chairs to deal with passwords is a bit silly. Maybe they could be emailed a monthly reminder of their personal subscription password on the first of each month. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: 06 June 2013 14:12 To: IAB Chair Cc: IAB; IETF Subject: Re: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship A couple of minor comments: - For some unfathomable reason IEEE people seem to call mailing lists reflectors - that might be worth a mention. Section 4 otherwise seems repetitive. - 3.3.1.4 says: Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted. That's a pretty bogus setup. I would think that if IEEE do want to share some or all drafts with us they could much more easily create a web page when those drafts are available without access control. Or we could if they didn't mind. (Or I could do it if there's no we that wants to:-) Asking IETF WG chairs to deal with passwords is a bit silly. I'm not objecting to this, but am suggesting someone ask IEEE if they'd like to consider the silliness here and fix it. S. On 06/05/2013 07:50 PM, IAB Chair wrote: This is a call for review of The IEEE 802 / IETF Relationship prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-rfc4441rev/ The Call for Review will last until 20 June 2013. Please send comments to i...@iab.org. On behalf of the IAB, Russ Housley IAB Chair
Re: Hugh Daniel has passed away
Paul Wouters p...@cypherpunks.ca writes: Hugh Daniel passed away on June 3rd after what appears to have been a heart attack. I met Hugh many years ago when we were working on our overlay system, and had problems integrating it with FreeS/WAN's IPsec implementation. And yes, I too remember the LED lights. He correlated wavelength with clue - the shorter the wavelength, the higher you stood in his view, AFAIR. -- He visited my office about 12 years ago - unannounced, as was more typical than not. After talking at length, he invited me to dinner with a group of his friends in a nearby town. I mentioned that I was 'closing' on a house in that same town, and would show him after dinner. He rolled up just under a large tree and parked on the street. I asked him why he picked that location, and he said it was because his friend was three lots up the street, and this was the closest vacant spot. He had parked directly at my new house. Through him I met a very interesting sci-fi writer, Renfair frequenter, and food historian that evening, among others, at a restaurant I walk past nearly every day. His contributions to my six degrees was sincerely appreciated and will be missed. Joe
RE: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. I also believe that the comments he made did not advance the content of the document. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. Normal IETF business is to discuss not seek acknowledgement. I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. The authors have posted a revised I-D handling other IETF last call issues, and I will advance that to IESG evaluation. Thanks, Adrian From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: 03 June 2013 17:10 To: ietf Cc: adr...@olddog.co.uk; i...@ietf.org Subject: Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB On Mon, Jun 3, 2013 at 6:35 AM, Ulrich Herberg ulr...@herberg.name wrote: Hi Adrian, I personally agree that adding an informational ref to draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my co-authors. Thanks Ulrich On Sunday, June 2, 2013, Adrian Farrel wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
RE: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
At 20:01 05-06-2013, l.w...@surrey.ac.uk wrote: RFC2031 documented the takeover. Snuck through on informational... It's part of the poorly documented historical facts which happened after some IETF financial woes. I read draft-iab-rfc4441rev-04 again. Section 1 mentions that: This version of the document responds to comments received during IAB Last Call. I would have expected the IAB to catch issues which are related to the IETF. Section 3.1.4 lists Balance between mailing lists and meetings as a cultural difference. The last sentence in the paragraph: Attendance at meetings is critical to influencing decisions and to maintaining membership voting rights. sums up a major difference. It could be said that a standard setting organization is dominated by interest groups (see RFC 6852) which can afford the air travel if major decisions are made during a plenary or interim meetings. In Section 3.3.1.4: However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting The above does not describe correctly why it is not possible to incorporate the material. It could mention that due to copyright restrictions, incorporating materials into IETF documents or postings is not allowed. In Section 3.3.1.5: IEEE 802 standards, once approved, are published and made available for sale. This could be a cultural difference. RFC 6852 glosses over that (see Standards specifications are made accessible to all for implementation and deployment.) BTW, the draft could be made shorter by incorporating the relevant topics by reference instead of describing them in the draft. RFC 6756 has a better layout in my opinion. RFC 4441 describes the policies and procedures that have developed in order to coordinate between the IETF and IEEE 802. draft-iab-rfc4441rev-04 mentions that it describes the standardization collaboration between the IETF and IEEE 802. The result looks like a Taoesque mix of IETF and IEEE 802 material. Why is it important to explain the IAB responsibilities? Why is it important to explain IESG and IAB member appointments? What does cross-referencing documents have to do with the relationship? I suggest looking at the draft while taking the above (non-exhaustive) list of questions into consideration. The details of the collaboration, e.g. how to get a password, can be documented through a Wiki. The IEEE does a decent job of documenting its standards document lifecycle; it's less convoluted than the IETF. The relevant URL is not mentioned in the draft. The draft lists analogies between the IETF and IEEE 802 whereas the reality is that the two organizations operate differently. The details of that is written as politically appropriate version of reality. Regards, -sm
RE: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
In Section 3.3.1.5: IEEE 802 standards, once approved, are published and made available for sale. This could be a cultural difference. RFC 6852 glosses over that (see Standards specifications are made accessible to all for implementation and deployment.) IEEE 802 standards are made more-or-less freely available (you have to agree to terms of use online) after a period of 6 months from publication. Details are here: http://standards.ieee.org/about/get/. -Peter
Re: Call for Review of draft-iab-rfc4441rev-04.txt, The IEEE 802 / IETF Relationship
On 6/6/2013 8:12 AM, Stephen Farrell wrote: - 3.3.1.4 says: Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted. That's a pretty bogus setup. I would think that if IEEE do want to share some or all drafts with us they could much more easily create a web page when those drafts are available without access control. Or we could if they didn't mind. (Or I could do it if there's no we that wants to:-) Asking IETF WG chairs to deal with passwords is a bit silly. I'm not objecting to this, but am suggesting someone ask IEEE if they'd like to consider the silliness here and fix it. Hi, Stephen, It's probably worth pointing out to the community that both IETF and IEEE 802 leadership have been looking at previous revisions and asking if they do that, should we do the same? The most recent case I can think of was that IETF published a list of its liaison managers, while IEEE 802 did not - but review discussions prompted iEEE 802 to start publishing a list of its liaison managers as well. There have been others. I'd be pleasantly surprised if either organization has run out of bogosity to fix, of course ;-) Spencer
Gen-ART review of draft-eastlake-rfc5342bis-02
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
I am an additional Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-rfc2326bis Reviewer: Elwyn Davies Review Date: 5 June 2013 IETF LC End Date: 5 JUne 2013 IESG Telechat date: (if known) - Summary: Almost ready. Generally this is an excellent and well written document, particularly given its size. There are a few minor issues to sort out mainly at the nit level and some consistency issues to fix up. The two issues that I have brought out below are really at what the IESG would call 'DISCUSS-DISCUSS' level. The issue of URI scheme redefinition may well have already been cleared by the URI expert - the draft does not do itself any favours here by failing to explain what the syntax changes are in s4.2; this raises immediate red flags that only start to fade a couple of hundred pages later. The rudimentary nature of the pipeline mechanism is carried over from RTSP 1.0. I'd like to be sure that this has been properly discussed in the WG as it looks pretty flaky to an outsider. There are several inconsistencies between various lists of headers that need sorting out and there is no definition of Proxy-Authorization in the ABNF. There are also a fairly large number of editorial nits but these are all localized and trivial to fix. Finally I have't had time to review the appendices (maybe there will be a follow up). Robert Sparks is the main gen-art reviewer for the document; he asked for additional eyes on the document given the size and his RAI background. Having (just) seen his review, I think we have both picked up on the URI scheme and pipeline issues. I am not sure that I concur with his view that there is significant normative material in the appendices - AFAICS the main protocol definition *is* in the main body of the document and the bits especiially in Appendices B and C are not the core of the protocol. However this is based on a very cursory glance through something like 75 pages of the document. However, I do concur with Robert's view that it needs a security expert to check the security stories. Major(ish) issues: s4.2: This section (re-)defines the URI schemes rtsp and rtsps. The last sentence of para 1 states that the 'details of the syntax' of the URIs 'have been changed'. Is this a reasonable thing to do? Has this been cleared with the URI expert reviewer? I am not entirely clear what the change involves and the draft doesn't explain exactly how the syntax has been altered and its consequences (if any) in s4.2. Some details are finally given in s22.14. Minor issues: s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0 model of sending requests and worrying about success of prior prior pipelined requests was the right answer. I would have thought that it might have been helpful to provide qualifiers on the Pipelined-Requests header that allowed subsequent requests to be suppressed unless the previous command resulted in one of a given set of status codes with a 'reset' option to 'restart' the pipeline. It strikes me that this would avoid some irritating need to work out how to recover from arbitrary failures in a command chain in a client. Nits/editorial comments: General: s/i.e./i.e.,/; s/e.g./e.g.,/ General: Consistent usage of octet vs. byte (octet preferred). General: Consistent use of '(session) keep alive' vs. '(session) keep-alive' General: Consistent use of Base64 vs BASE64. s1, para 2, last sentence: s/delivered as a time-synchronized streams/delivered as time-synchronized streams/ s1. last para: s/used terms/terms used/ s1, last para: Need to expand SDP acronym. s2, para 1: s/considered use cases/use cases considered/ s2.1, para 1: s/completely out of bands/completely out of band/ s2.1, next to last para: It would be useful to provide a pointer to where the two URI schemes are defined (s4.2?) so it is clear these are internally defined and one needn't go looking for another doc. s2.2, para 5: s/uses client-selected identifier/uses a client-selected identifier/ s2.2, para 5: For consistency there should be a reference for s18.32 with Pipelined-Requests. s2.2, last para: For consistency there should be a reference for s18.29 with Media-Range. s2.3, para 1: Expand SMPTE acronym. s2.3, para 3: Reference s13.5 for PLAY_NOTIFY s2.3, para 5: The server should also regularly send every 5 minutes the current media range in a PLAY_NOTIFY request. Shouldn't this be configurable? s2.3, last para: If the client waits too long before resuming the pause point, the content may no longer be available. In this case the pause point will be adjusted to the end of the available media. I know this is a subjective choice, but I would have thought adjusting to the beginning of the available media would be
Re: Last Call: draft-ietf-ospf-manet-single-hop-mdr-03.txt (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
On 6/6/13 3:15 AM, Abdussalam Baryun wrote: I send my request to the editors including questions but no reply from them to me. The thread [1] raised some issues, which is not mentioned in the I-D. The message [2] was ignored not answered (this is last reminder). The message [3] proposes using RFC5444 into this I-D, or raise the question of why not using MANET packet format within MANET domains (I need an answer). [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html The I-D SHOULD not go forward if it still ignores the IETF community questions. This sounds like an appeal of the working group consensus, not a last call comment. If you have concerns with the WGLC those are raised first with the chairs, then with responsible AD, and then with the IESG as a whole. I would observe that consensus does not require universal agreement. If you're in the rough from the vantage point of others, it's worth considering whether political capital, goodwill and the forebearance of your peers are best expended on this point. Regards AB On 6/5/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' draft-ietf-ospf-manet-single-hop-mdr-03.txt as Experimental 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-06-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 RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Hi, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? Why don't you consider discovering an error as a contribution? Why don't you consider providing new ideas a contribution? What is your definition to contribution? I also believe that the comments he made did not advance the content of the document. So I understand that you need to have advance the content then you acknowledge. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. I am trying to find that condition of *major contribution*, Normal IETF business is to discuss not seek acknowledgement. Ideas, Comments and reviews are included in the discuss for drafts progress. Seeking acknowledgement is not wrong within IETF, but please consider *not acknowledging reviews* within IETF documents is not IETF culture (we are not paid so why you thinking much of the business, the IETF business will only progress with acknowledging the volunteers). I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. IMO, it should have been done in the WG. AB From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: 03 June 2013 17:10 To: ietf Cc: adr...@olddog.co.uk; i...@ietf.org Subject: Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats* Reading the RFC6130 applicability section 3, the I-D does not consider all the use-cases included in the that section 3. AB Does the use-case of NHDP [RFC6130] add any value to the threats, or the I-D assumes only one use case which is OLSRv2 network. The NHDP uses RFC5444 packets and RFC5444 messages, so what are the threats to NHDP use for each? not mentioned in I-D. RFC6130 NHDP Can use relevant link-layer information if it is available. AB is there any threat from that use-case? not mentioned in the I-D. *Information bases threats* RFC6130 Appendix F This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A’s various Information Bases after NHDP has been running for sufficiently long time for the state to converge. AB Why the logically recording of the NHDP for all the examples not mentioned in the I-D and were not threat analysed? If there is similar level of threats related to all exampels in RFC6130, then please mention that. This is my last message, thanks. Regards AB
Liaison Statement From the IESG and IAB to ISO/IEC JTC1/SC6 on TISec
The Liaison statement can be found here: https://datatracker.ietf.org/liaison/1258/ The Internet Society will forward this liaison statement to ISO/IEC JTC1/SC6 on their letterhead. This will carry more weight than a statement just from the IESG and IAB because the Internet Society holds a Class A liaison with SC6 on behalf of the IETF. This liaison is provided to ISO/IEC JTC1/SC6 because they are entertaining adopting the TISec. The IESG and the IAB believe TISec provides the same services as IPsec. The IESG rejected a request for a protocol number assignment for TISec in August of last year for that reason, but the IESG offered an experimental code point while TISec was under review in ISO. A liaison was sent to ISO informing them of this decision in December (see ). The TISec proponents have indicated that they believe that TISec is different than IPsec. This liaison is a response this statement. It points out how IPsec supports the same functionality, and it encourages the TISec proponents to engage in the IETF process to specify the use of their national algorithms in IPsec, as has been done for other national algorithms. On behalf of the IAB, Russ Housley On behalf of the IESG, Jari Arkko
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
AB, while the IETF LC has already ended, I will reply to your comments below: On Thu, Jun 6, 2013 at 1:33 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats* Reading the RFC6130 applicability section 3, the I-D does not consider all the use-cases included in the that section 3. AB Does the use-case of NHDP [RFC6130] add any value to the threats, or the I-D assumes only one use case which is OLSRv2 network. I don't understand the question. The use case is a MANET running NHDP. Section 5 in addition outlines consequences of security threats to NHDP for protocols using the information from NHDP. The NHDP uses RFC5444 packets and RFC5444 messages, so what are the threats to NHDP use for each? not mentioned in I-D. I don't understand the question. There is no danger from a message or packet itself; they may contain information that has either been legitimately tampered with or that is wrong because of misconfiguration. And these are the cases we have described. RFC6130 NHDP Can use relevant link-layer information if it is available. AB is there any threat from that use-case? not mentioned in the I-D. After discussion on the MANET mailing list, this was already added in section 4.8 (even though the link quality itself is not a normative part of RFC6130, the authors agreed to add that section). *Information bases threats* RFC6130 Appendix F This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A’s various Information Bases after NHDP has been running for sufficiently long time for the state to converge. AB Why the logically recording of the NHDP for all the examples not mentioned in the I-D and were not threat analysed? If there is similar level of threats related to all exampels in RFC6130, then please mention that. I don't understand the question. The example in RFC6130 simply illustrates how NHDP would perceive and store several sample topologies. How would that represent a level of threat? The I-D describes several security threats and explains in which situations these could occur (and what effect it would have). That could happen in an infinite amount of different topologies, so it is impossible (and useless) to list all topologies where such attacks could occur. Best regards Ulrich
RE: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I find it somewhat disruptive that this email raises new questions on a draft authored in a working group in which you participate, and that it has arrived after the end of IETF last call. I see a series of questions in this message, but no suggested textual changes. I therefore conclude that you are requesting no changes and none shall be made. Thank you. Adrian Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats*
RE: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Sorry to everyone for the noise this thread is creating. Multiple questions that I have to answer. It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Are you asking whether there was an explicit consensus call within the working group on whether or not you should be acknowledged in this document? There was no such call in the working group or on the IETF list. Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. This opinion does not apply to your comments on this document. You did not discover a wrong technical-idea. Your comments did not lead directly to the addition of any new technical-idea. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? That person is you. Yes, you made a review. Reviewing a document is not something authors acknowledge in the IETF or (AFAIK) in academic journals. No, I don't think you discovered errors of any significance. Caveating my answers below as describing a contribution to a document (not a contribution in the wider IETF sense) Why don't you consider discovering an error as a contribution? I would personally consider discovering a major error as something I would acknowledge it in a document I was editing. I would personally consider discovering multiple minor errors as something I would acknowledge it in a document I was editing. However, there is no requirement for editors to act in that way. Furthermore, you do not fit into these categories for this document. Why don't you consider providing new ideas a contribution? I would consider providing major ideas as something I would acknowledge it in a document I was editing. I would consider providing smaller ideas through text for inclusion in the document as something I would acknowledge it in a document I was editing. You do not fit into these categories for this document. What is your definition to contribution? As above, or written text that was included or modified for inclusion in a document and represents a material or substantial part of the document. I also believe that the comments he made did not advance the content of the document. So I understand that you need to have advance the content then you acknowledge. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. I am trying to find that condition of *major contribution*, I would borrow from 2026 and 5378 to say a material or substantial contribution to the document. And, before you ask, no-one is going to write down a rule that says 139 characters is not substantial, but 140 is. This is one of the places where a principal of reasonableness applies. I would know a major contribution if I saw one. I did not see one from you in this case. Normal IETF business is to discuss not seek acknowledgement. Ideas, Comments and reviews are included in the discuss for drafts progress. Seeking acknowledgement is not wrong within IETF, but please consider *not acknowledging reviews* within IETF documents is not IETF culture (we are not paid so why you thinking much of the business, the IETF business will only progress with acknowledging the volunteers). If you want to change the way that the IETF participants (and document authors/editors in particular) acknowledge reviews of their documents, then please start a separate thread or, better still, write an I-D and see whether you can gain consensus. The last time you brought this topic up on this list, I do not recall seeing support. The only reason I can find for someone being able to demand that they are named in an Acknowledgements Section is for conformance to the IETF's Rights policies. I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. IMO, it should have been done in the WG. Thank you for your opinion. Are you asserting that consensus on the readiness of this document for a publication request was incorrectly called by the working group chairs. This would be a serious allegation against the chairs and I would require evidence that there had been no consensus or that they had made an incorrect assessment of the consensus. Thank you, Adrian
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I received an IESG message asking my comments so I gave it, regard to your comments below, the reply is that I refer to missing information needed in the I-D, so the reveiw suggests that there is something missing. Did not suggested text because I know that it most probably not be considered. The Last call ends by 06.06.2013 so I still am in this date, not sure why you close, AB On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: I find it somewhat disruptive that this email raises new questions on a draft authored in a working group in which you participate, and that it has arrived after the end of IETF last call. I see a series of questions in this message, but no suggested textual changes. I therefore conclude that you are requesting no changes and none shall be made. Thank you. Adrian Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats*
Re: Last Call: draft-ietf-ospf-manet-single-hop-mdr-03.txt (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
AB, As Joel pointed out, your questions should have been raised during the OSPF WG Last Call, which you did not participate in. You (inappropriately) posted questions on the MANET WG list after the OSPF WGLC was complete, and several people responded, most of them stating that RFC 5444 is not required for this document: http://www.ietf.org/mail-archive/web/manet/current/msg15403.html http://www.ietf.org/mail-archive/web/manet/current/msg15406.html http://www.ietf.org/mail-archive/web/manet/current/msg15407.html http://www.ietf.org/mail-archive/web/manet/current/msg15408.html Although I should not be required to respond to your questions at this point, I will provide a few additional reasons why RFC 5444 and DLEP are not relevant for this document. (These reasons also apply to the parallel document draft-ietf-ospf-manet-single-hop-or-02.) 1. This draft does not propose a new interface, it only describes how the interface previously specified in RFC 5614 (and RFC 5820 for the other draft) can be configured in the special case of a single-hop MANET. Therefore, your comments should have been directed to RFC 5614 (and RFC 5820). 2. RFCs 5614 and 5820 describe MANET extensions to OSPF, and one of the goals was to minimize changes to OSPF, so we decided to use OSPF packet formats (with minimal changes), rather than MANET packet formats that were designed without OSPF in mind. (This point is also made in the last message listed above.) On the other hand, these are experimental documents, so your questions about using RFC 5444 and DLEP may be valid for future modifications to the proposed MANET extensions of OSPF (both RFCs 5614 and 5820). But they are not valid for draft-ietf-ospf-manet-single-hop-mdr or draft-ietf-ospf-manet-single-hop-or, not only because these two drafts have already completed WGLC, but also because they only describe how to configure RFCs 5614 and 5820 for the special case of a single-hop network. Richard On 6/6/13 3:15 AM, Abdussalam Baryun wrote: I send my request to the editors including questions but no reply from them to me. The thread [1] raised some issues, which is not mentioned in the I-D. The message [2] was ignored not answered (this is last reminder). The message [3] proposes using RFC5444 into this I-D, or raise the question of why not using MANET packet format within MANET domains (I need an answer). [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html The I-D SHOULD not go forward if it still ignores the IETF community questions. Regards AB On 6/5/13, The IESG iesg-secret...@ietf.orgwrote: The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Use of OSPF-MDR in Single-Hop Broadcast Networks' draft-ietf-ospf-manet-single-hop-mdr-03.txt as Experimental 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.orgmailing lists by 2013-06-19. Exceptionally, comments may be sent to iesg@ietf.orginstead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/ No IPR declarations have been submitted directly on this I-D.
Weekly posting summary for ietf@ietf.org
Total of 146 messages in the last 7 days. script run at: Fri Jun 7 00:53:03 EDT 2013 Messages | Bytes| Who +--++--+ 10.27% | 15 | 9.96% | 125797 | abdussalambar...@gmail.com 4.11% |6 | 6.44% |81389 | adr...@olddog.co.uk 5.48% |8 | 3.76% |47556 | mo...@necom830.hpcl.titech.ac.jp 4.11% |6 | 4.30% |54259 | war...@kumari.net 3.42% |5 | 3.58% |45181 | john-i...@jck.com 3.42% |5 | 3.28% |41450 | l.w...@surrey.ac.uk 3.42% |5 | 3.16% |39894 | d...@dcrocker.net 3.42% |5 | 2.36% |29749 | ra...@psg.com 2.74% |4 | 2.53% |31911 | carlosm3...@gmail.com 2.74% |4 | 2.18% |27483 | arturo.ser...@gmail.com 1.37% |2 | 3.38% |42690 | ron.even@gmail.com 2.74% |4 | 1.86% |23539 | m...@mnot.net 1.37% |2 | 3.15% |39833 | simo.veikkolai...@nokia.com 2.05% |3 | 1.88% |23809 | scott.b...@gmail.com 2.05% |3 | 1.68% |21225 | s...@resistor.net 2.05% |3 | 1.62% |20488 | ted.le...@nominum.com 1.37% |2 | 2.29% |28971 | doug.mtv...@gmail.com 2.05% |3 | 1.54% |19411 | jmamo...@gmail.com 0.68% |1 | 2.80% |35397 | elw...@folly.org.uk 2.05% |3 | 1.37% |17285 | iab-ch...@iab.org 0.68% |1 | 2.66% |33542 | cb.li...@gmail.com 1.37% |2 | 1.73% |21883 | barryle...@computer.org 1.37% |2 | 1.64% |20761 | jcur...@istaff.org 1.37% |2 | 1.50% |18953 | brian.e.carpen...@gmail.com 1.37% |2 | 1.44% |18207 | ulr...@herberg.name 1.37% |2 | 1.37% |17302 | hartmans-i...@mit.edu 1.37% |2 | 1.35% |17078 | aeop...@gmail.com 1.37% |2 | 1.27% |16048 | m...@blackops.org 1.37% |2 | 1.10% |13834 | spencerdawkins.i...@gmail.com 1.37% |2 | 1.09% |13711 | chris.dearl...@baesystems.com 1.37% |2 | 1.06% |13376 | joe...@bogus.com 1.37% |2 | 0.94% |11882 | c...@tzi.org 1.37% |2 | 0.92% |11641 | to...@isi.edu 0.68% |1 | 1.60% |20151 | rjspa...@nostrum.com 1.37% |2 | 0.88% |11081 | jari.ar...@piuha.net 1.37% |2 | 0.87% |10956 | fg...@si6networks.com 0.68% |1 | 0.95% |12013 | ke-oog...@kddi.com 0.68% |1 | 0.88% |11066 | nar...@us.ibm.com 0.68% |1 | 0.73% | 9244 | og...@earthlink.net 0.68% |1 | 0.67% | 8504 | framefri...@gmail.com 0.68% |1 | 0.66% | 8340 | d3e...@gmail.com 0.68% |1 | 0.63% | 7996 | david.bl...@emc.com 0.68% |1 | 0.63% | 7948 | yb...@panix.com 0.68% |1 | 0.62% | 7882 | daedu...@btconnect.com 0.68% |1 | 0.61% | 7654 | i...@cdl.asgaard.org 0.68% |1 | 0.61% | 7651 | yi.ji...@gmail.com 0.68% |1 | 0.60% | 7579 | elw...@dial.pipex.com 0.68% |1 | 0.59% | 7486 | ma...@isc.org 0.68% |1 | 0.55% | 6960 | d...@cridland.net 0.68% |1 | 0.55% | 6886 | aman...@verisign.com 0.68% |1 | 0.53% | 6748 | rwfra...@gmail.com 0.68% |1 | 0.52% | 6615 | bmann...@isi.edu 0.68% |1 | 0.52% | 6609 | j...@mercury.lcs.mit.edu 0.68% |1 | 0.51% | 6418 | stephen.farr...@cs.tcd.ie 0.68% |1 | 0.50% | 6367 | do...@dougbarton.us 0.68% |1 | 0.50% | 6353 | p...@cypherpunks.ca 0.68% |1 | 0.50% | 6328 | f...@cisco.com 0.68% |1 | 0.49% | 6164 | p...@frobbit.se 0.68% |1 | 0.45% | 5654 | y...@checkpoint.com 0.68% |1 | 0.44% | 5502 | nscl...@gmx.de 0.68% |1 | 0.41% | 5235 | c...@a.org 0.68% |1 | 0.41% | 5212 | pe...@akayla.com 0.68% |1 | 0.40% | 5074 | wjh...@hardakers.net +--++--+ 100.00% | 146 |100.00% | 1263211 | Total
RFC 6957 on Duplicate Address Detection Proxy
A new Request for Comments is now available in online RFC libraries. RFC 6957 Title: Duplicate Address Detection Proxy Author: F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li Status: Standards Track Stream: IETF Date: June 2013 Mailbox:fabio.co...@orange.com, jeanmichel.com...@orange.com, xavier.pougn...@orange.com, l...@huawei.com Pages: 16 Characters: 32537 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-6man-dad-proxy-07.txt URL:http://www.rfc-editor.org/rfc/rfc6957.txt The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a split-horizon forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address. This document is a product of the IPv6 Maintenance 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 6960 on X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
A new Request for Comments is now available in online RFC libraries. RFC 6960 Title: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Author: S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams Status: Standards Track Stream: IETF Date: June 2013 Mailbox:s...@aaa-sec.com, mmy...@fastq.com, none, ambar...@gmail.com, slava.galpe...@gmail.com, cad...@eecs.uottawa.ca Pages: 41 Characters: 82037 Obsoletes: RFC 2560, RFC 6277 Updates:RFC 5912 I-D Tag:draft-ietf-pkix-rfc2560bis-20.txt URL:http://www.rfc-editor.org/rfc/rfc6960.txt This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This document is a product of the Public-Key Infrastructure (X.509) 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 6962 on Certificate Transparency
A new Request for Comments is now available in online RFC libraries. RFC 6962 Title: Certificate Transparency Author: B. Laurie, A. Langley, E. Kasper Status: Experimental Stream: IETF Date: June 2013 Mailbox:b...@google.com, a...@google.com, ekas...@google.com Pages: 27 Characters: 55048 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-laurie-pki-sunlight-12.txt URL:http://www.rfc-editor.org/rfc/rfc6962.txt This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
