gmane.ietf.general http://blog.gmane.org/gmane.ietf.general hourly 1 1901-01-01T00:00+00:00 Gmane http://gmane.org/img/gmane-25t.png http://gmane.org MalcolmBETTS90013533 is out of the office. http://comments.gmane.org/gmane.ietf.general/52002 <pre> I will be out of the office starting 25/05/2012 and will not return until 04/06/2012. I will not have access to email, I will respond to your message when I return. </pre> Malcolm.BETTS< at >zte.com.cn 2012-05-26T02:01:02 RFP for IETF Meeting Agenda Scheduling Tool http://comments.gmane.org/gmane.ietf.general/52000 <pre>The IETF Administrative Oversight Committee (IAOC), on behalf of the IETF, announces this Request for Proposals for an IETF Meeting Agenda Scheduling Tool. The successful bidder will enter into a contract with the Internet Society. The agenda tool will manage all meeting scheduling and space allocation associated with interim meetings, Large Interim Meetings and regular IETF meetings. This includes working group sessions, leadership meetings, EDU sessions, BoFs, office hours, registration, breaks, and more. The Secretariat will construct the agenda template in the tool by entering venue, date and time information. The community will input the agenda content by submitting session requests. The tool shall include an interface for an automatic schedule creation capability, which may optionally be included in the initial delivery or procured in the future. The schedule creation capability will generate a proposed agenda by finding the most appropriate match of venue (room capacity and availability) and the session request profiles, which includes conflicts to be avoided. The tool will also be flexible enough to allow for ongoing updates and schedule regeneration as the meeting content evolves. Bidders may propose customization of an existing product(s), and/or development of the solution. The RFP can be found at: http://iaoc.ietf.org/rfpsrfis.html Proposals must be received via email at agenda-tool&lt; at &gt;ietf-bids.org no later than July 9, 2012 5:00 P.M. All questions/inquiries must be submitted in writing and must be received no later than midnight, June 18, 2012. Responses to questions and inquiries shall be posted online at: http://iaoc.ietf.org/rfpsrfis.html by June 22, 2012. The point of contact regarding this RFP is the IETF Administrative Director, Ray Pelletier, iad&lt; at &gt;ietf.org. Ray Pelletier </pre> IETF Administrative Director 2012-05-25T22:00:16 Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18 http://comments.gmane.org/gmane.ietf.general/51999 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dnsext-dnssec-bis-updates-18 Reviewer: Richard Barnes Review Date: May-25-2012 IETF LC End Date: Not known IESG Telechat date: Jan-05-2012 Summary: Almost ready, couple of questions MAJOR: 4.1. It's not clear what the threat model is that this section is designed to address. If the zone operator is malicious, then it can simulate the necessary zone cut and still prove the non-existence of records in the child zone. 5.10. I find the recommendation of the "Accept Any Success" policy troubling. It deals very poorly with compromise (and other roll-over scenarios): Suppose there are two trust anchors, one for example.com and one for child.example.com. If the private key corresponding to the TA for child.example.com is compromised, but the validator continues to trust it, this negates the benefit provided by the parent (example.com) facilitating a rollover. Suggest an alternative policy, "Highest Signer": Out of the set of keys configured as TAs, the validator only uses a key as a TA (for purposes of validation) if there does not exist a DNSSEC path from it to any other TA. This policy seems like more work to enforce (because you have to do more backward chaining), but ISTM that the validator should have the necessary DNSSEC records anyway, so it's just a matter a couple of quick checks. </pre> Richard L. Barnes 2012-05-25T21:02:28 Weekly posting summary for ietf< at >ietf.org http://comments.gmane.org/gmane.ietf.general/51997 <pre>Total of 59 messages in the last 7 days. script run at: Fri May 25 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.47% | 5 | 5.54% | 25712 | randy&lt; at &gt;psg.com 6.78% | 4 | 7.16% | 33268 | stpeter&lt; at &gt;stpeter.im 3.39% | 2 | 9.13% | 42391 | ron.even.tlv&lt; at &gt;gmail.com 5.08% | 3 | 6.59% | 30626 | shanna&lt; at &gt;juniper.net 5.08% | 3 | 4.94% | 22928 | marshall.eubanks&lt; at &gt;gmail.com 5.08% | 3 | 4.57% | 21219 | brian.e.carpenter&lt; at &gt;gmail.com 5.08% | 3 | 4.30% | 19950 | rdroms.ietf&lt; at &gt;gmail.com 1.69% | 1 | 6.05% | 28097 | bclaise&lt; at &gt;cisco.com 3.39% | 2 | 3.54% | 16456 | trammell&lt; at &gt;tik.ee.ethz.ch 3.39% | 2 | 3.27% | 15189 | sm&lt; at &gt;resistor.net 3.39% | 2 | 3.15% | 14620 | hsantos&lt; at &gt;isdg.net 3.39% | 2 | 2.53% | 11729 | cabo&lt; at &gt;tzi.org 3.39% | 2 | 2.52% | 11728 | ned+ietf&lt; at &gt;mauve.mrochek.com 1.69% | 1 | 2.94% | 13672 | alexey.melnikov&lt; at &gt;isode.com 1.69% | 1 | 1.80% | 8383 | hartmans-ietf&lt; at &gt;mit.edu 1.69% | 1 | 1.77% | 8218 | narten&lt; at &gt;us.ibm.com 1.69% | 1 | 1.72% | 7972 | mcquilwp&lt; at &gt;pobox.com 1.69% | 1 | 1.69% | 7844 | marka&lt; at &gt;isc.org 1.69% | 1 | 1.65% | 7684 | abdussalambaryun&lt; at &gt;gmail.com 1.69% | 1 | 1.57% | 7270 | weiler+secdir&lt; at &gt;watson.org 1.69% | 1 | 1.56% | 7263 | jhutz&lt; at &gt;cmu.edu 1.69% | 1 | 1.50% | 6980 | john-ietf&lt; at &gt;jck.com 1.69% | 1 | 1.44% | 6703 | petithug&lt; at &gt;acm.org 1.69% | 1 | 1.44% | 6687 | housley&lt; at &gt;vigilsec.com 1.69% | 1 | 1.42% | 6591 | bob.hinden&lt; at &gt;gmail.com 1.69% | 1 | 1.39% | 6464 | erosen&lt; at &gt;cisco.com 1.69% | 1 | 1.34% | 6215 | stephen.farrell&lt; at &gt;cs.tcd.ie 1.69% | 1 | 1.33% | 6161 | ynir&lt; at &gt;checkpoint.com 1.69% | 1 | 1.32% | 6136 | yaakov_s&lt; at &gt;rad.com 1.69% | 1 | 1.27% | 5907 | chair&lt; at &gt;ietf.org 1.69% | 1 | 1.27% | 5894 | pradeepar&lt; at &gt;gmail.com 1.69% | 1 | 1.26% | 5850 | vinayakh&lt; at &gt;gmail.com 1.69% | 1 | 1.22% | 5646 | elwynd&lt; at &gt;folly.org.uk 1.69% | 1 | 1.21% | 5627 | cos&lt; at &gt;aaaaa.org 1.69% | 1 | 1.21% | 5618 | lear&lt; at &gt;cisco.com 1.69% | 1 | 1.18% | 5462 | bortzmeyer&lt; at &gt;nic.fr 1.69% | 1 | 1.11% | 5178 | julian.reschke&lt; at &gt;gmx.de 1.69% | 1 | 1.11% | 5138 | dhc&lt; at &gt;dcrocker.net --------+------+--------+----------+------------------------ 100.00% | 59 |100.00% | 464476 | Total </pre> Thomas Narten 2012-05-25T04:53:03 Inconsistent behavior of IETF meeting registration page http://comments.gmane.org/gmane.ietf.general/51990 <pre>Hi, I was trying to register for IETF 84 and tried the link http://www.ietf.org/meeting/register.html from the main site. Sometimes it takes me to the IETF 80 page (registration over) and sometimes it takes me to the right note well page. Trying to replicate the issue, I am seeing that it works well on IE and Safari on Windows but not on Firefox on Linux/Windows. Further attempts to replicate this problem on Firefox on Windows did not work. Posting this here as I am not sure what is the right place to post such issues. Please point me there. Also hoping that I would get more datapoints of this problem from other people on this list (which probably will help pinpoint the problem). Looks like a cache-expiry or an improper redirection issue. Either ways the workaround is to change the number of the IETF meeting in the link as this (https://www.ietf.org/registration/ietf84/ietfreg.py) works. </pre> Vinayak Hegde 2012-05-24T17:58:13 Question on DHCPv6 / RFC3315 http://comments.gmane.org/gmane.ietf.general/51987 <pre>Hello All Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of Confirm messages When a client changes its configuration from dhcpv6 enabled to static ipv6, is this considered as moving to a new link and is the client required to send out a Confirm message ? Thanks pradeep </pre> pradeep ramachandran 2012-05-23T23:31:02 secdir review of draft-sakane-dhc-dhcpv6-kdc-option http://comments.gmane.org/gmane.ietf.general/51986 <pre>I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This doc specifies several DHCPv6 options for carrying Kerberos config info. There are obvious risks to doing this, but they're discussed reasonably well in this and similar cited docs (e.g. RFC3634, which specifies a much more limited option for DHCPv4). The doc explains by DNS service discovery isn't ideal for some environments. With that said, there are some things that need clarification, and the doc sorely needs an editorial pass. As-is, the doc is not ready for publication. I will be happy to review the doc again once it's been thoroughly edited. Things that need clarification or consideration: For the transport type field, would it be better to use a bitmask? Then one could use a single DHCPv6 option to specify a KDC that's reachable over both TCP and UDP, rather than needing two DHCPv6 options. Section 7 uses the term "TGT" without expansion. In the Kerberos world I can't imagine someone not knowing what this is, but it's not clear to the layman. It probably needs to be expanded. The algorithm in section 4.1 needs work. The obvious thing is to read it linearly. Doing that, one would prefer DHCP over DNS SVR info (per step 2), which is not what step 6 and the graphic say. Saying "no answer from the DNS server" is probably not the desired semantic. In 3.4, the option-len field is ambiguous. It says "24-octet + the length of the realm-name field in octets." But it looks to me like this option is 27 octets + length of realm name. Perhaps it would be better to just count the length of the realm name? And here are some examples of wording that needs work. There are many more -- I quit copying them into this review after the first few: 3.2 "This option informs a DHCPv6 server of which realm the client want to access, ..." 7 "... a rogue KDC that does not know the client access." What is "the client access"? "The incorrect KDC is not be able to proceed any further state of the client." "The considerable situation is that the support of an unconfigured workstation used by multiple users, which obtains its KDC information and default realm via DHCP." </pre> Samuel Weiler 2012-05-23T23:12:17 abnf discussion list? http://comments.gmane.org/gmane.ietf.general/51981 <pre>Folks, g'day. There are periodic questions about ABNF that go beyond the specifics of a specification attempting to use it. While these are not hot topics, they do occur periodically. Also, there is support material (software, documentation) for ABNF that has no single, natural home. I'd like to suggest an abnf-discuss&lt; at &gt;ietf.org mailing list and an abnf.ietf.org web page. Thoughts? d/ </pre> Dave Crocker 2012-05-23T16:56:49 Weekly posting summary for ietf< at >ietf.org http://comments.gmane.org/gmane.ietf.general/51939 <pre>Total of 57 messages in the last 7 days. script run at: Fri May 18 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.53% | 6 | 7.75% | 35365 | dhc&lt; at &gt;dcrocker.net 5.26% | 3 | 11.69% | 53304 | elwynd&lt; at &gt;folly.org.uk 3.51% | 2 | 11.14% | 50783 | jmvalin&lt; at &gt;jmvalin.ca 7.02% | 4 | 4.31% | 19674 | randy&lt; at &gt;psg.com 3.51% | 2 | 6.19% | 28233 | hartmans-ietf&lt; at &gt;mit.edu 5.26% | 3 | 4.02% | 18321 | adrian&lt; at &gt;olddog.co.uk 5.26% | 3 | 3.92% | 17857 | stpeter&lt; at &gt;stpeter.im 3.51% | 2 | 3.11% | 14177 | hsantos&lt; at &gt;isdg.net 3.51% | 2 | 2.80% | 12792 | ole&lt; at &gt;cisco.com 1.75% | 1 | 4.43% | 20226 | fluffy&lt; at &gt;cisco.com 3.51% | 2 | 2.60% | 11865 | dot&lt; at &gt;dotat.at 3.51% | 2 | 2.53% | 11557 | sm&lt; at &gt;resistor.net 3.51% | 2 | 2.40% | 10960 | ned+ietf&lt; at &gt;mauve.mrochek.com 1.75% | 1 | 2.35% | 10703 | mary.ietf.barnes&lt; at &gt;gmail.com 1.75% | 1 | 2.04% | 9307 | narten&lt; at &gt;us.ibm.com 1.75% | 1 | 1.69% | 7686 | barryleiba&lt; at &gt;computer.org 1.75% | 1 | 1.61% | 7348 | daedulus&lt; at &gt;btconnect.com 1.75% | 1 | 1.61% | 7347 | dave&lt; at &gt;cridland.net 1.75% | 1 | 1.49% | 6775 | brian.e.carpenter&lt; at &gt;gmail.com 1.75% | 1 | 1.44% | 6553 | dworley&lt; at &gt;avaya.com 1.75% | 1 | 1.43% | 6527 | fluffy&lt; at &gt;iii.ca 1.75% | 1 | 1.42% | 6464 | ynir&lt; at &gt;checkpoint.com 1.75% | 1 | 1.42% | 6459 | rdroms.ietf&lt; at &gt;gmail.com 1.75% | 1 | 1.40% | 6394 | peter.sylvester&lt; at &gt;edelweb.fr 1.75% | 1 | 1.40% | 6374 | ajs&lt; at &gt;anvilwalrusden.com 1.75% | 1 | 1.38% | 6297 | warren&lt; at &gt;kumari.net 1.75% | 1 | 1.37% | 6252 | ed.lewis&lt; at &gt;neustar.biz 1.75% | 1 | 1.29% | 5906 | lee&lt; at &gt;asgard.org 1.75% | 1 | 1.28% | 5855 | julian.reschke&lt; at &gt;gmx.de 1.75% | 1 | 1.27% | 5772 | john-ietf&lt; at &gt;jck.com 1.75% | 1 | 1.27% | 5770 | jaap&lt; at &gt;nlnetlabs.nl 1.75% | 1 | 1.25% | 5709 | scott&lt; at &gt;kitterman.com 1.75% | 1 | 1.22% | 5571 | ben&lt; at &gt;nostrum.com 1.75% | 1 | 1.19% | 5439 | dougb&lt; at &gt;dougbarton.us 1.75% | 1 | 1.19% | 5420 | vesely&lt; at &gt;tana.it 1.75% | 1 | 1.10% | 5020 | simon.perreault&lt; at &gt;viagenie.ca --------+------+--------+----------+------------------------ 100.00% | 57 |100.00% | 456062 | Total </pre> Thomas Narten 2012-05-18T04:53:03 RFC 2119 terms, ALL CAPS vs lower case http://comments.gmane.org/gmane.ietf.general/51892 <pre>Some snippets from another discussion thread, in a galaxy far, far away: Murray: Ned: Murray:  That In fact, RFC 2119 says that the normative keywords are "often capitalized", but doesn't require that they be. As Murray says, my habit is to use this for 2119 boilerplate: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This passes all nit checks, including those involving the eyes of the IESG, and I think it makes the situation absolutely clear. We could, certainly, as Murray notes, update 2119 to require all caps in order to use the words as 2119 terms. Alternatively, Tony and Dave had submitted this draft, now expired: http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119 It suggests words such as "can" and "ought to" as substitutes, which is what Murray's original review was also suggesting. The trouble with the first approach (using all caps as 2119 terms, and using the same words in lower case as normal English) isn't so much that someone might be confused later, but that during development and review we're not sure whether you meant to put the word in all caps, and just forgot. No amount of documentation can avoid that question, and using "can" or "ought to" gets us away from the issue. The trouble with the "non-normative synonyms" is that it makes document text awkward, by requiring us to artificially substitute less apt words, when "may" and "should", as English words, are exactly what we mean. It's probably worth having a discussion of all of that, and seeing whether there's some possibility of developing a rough community consensus on what we might-could-maybe-oughta-should do. Barry </pre> Barry Leiba 2012-05-16T13:59:08 Gen-ART LC Review of draft-ietf-ccamp-assoc-info-03 http://comments.gmane.org/gmane.ietf.general/51887 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-assoc-info-03 Reviewer: Ben Campbell Review Date: 2012-06-14 IETF LC End Date: 2012-06-14 Summary: This draft is ready for publication as an informational RFC. Major issues: None Minor issues: None Nits/editorial comments: </pre> Ben Campbell 2012-05-14T19:12:10 Gen-art last call review of draft-ietf-codec-opus-12.txt (completed) http://comments.gmane.org/gmane.ietf.general/51886 <pre>I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at &lt;http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&gt;. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-codec-opus-12.txt Reviewer: Elwyn Davies Review Date: 14 May 2012 (completed) IETF LC End Date: 10 May 2012 IESG Telechat date: (if known) - Summary: Before offering some views on the document, let me say that this piece of work seems to be a tour de force on behalf of its developers. It is certainly one of the (if not the) most technically complex pieces of work that has been presented to the IETF, and is far more mathematically complex and rigorous than our usual run of standards. It is also perhaps a vindication of the rough concensus and running code philosophy. So congratulations to the authors and the companies that have supported this work. But back to the review.... I came to this review with a very outdated view of what goes on inside codecs, so it was rather a shock to the system. Taking that into account, I think that some additional high level, up front description of the two parts (SILK and CELT) and the range encoding system would make it easier for future (naive) readers and potential implementers to understand what is going on. For example, after struggling with the description of CELT in the decoder (s4.3) I found that going off and reading the slides on CELT presented at IETF 79 helped considerably. Such additions might also help future dissemination of the technique by giving potential users a quick overview. It would also make it easier to justify the decision to postpone the high level (and highly mathematical/technical) view to section 5 after the detailed description of the decoder. I also found that the descriptions of the SILK and CELT decoders appeared to be written with a different perspective (see detailed comments) doubtless by different authors. This is not ideal and, despite the expected further increase in page count, some additional text in s4.3 seems desirable. By far the most difficult to parse section is 4.3.3 talking about bit allocation in CELT. Despite considerable study, I didn't feel I had really got to grips with how this worked. An example might help. Finally, the most contentious aspect of this document is the requirement to treat the code as normative. There are just over 30,000 physical lines of code and I haven't checked them hardly at all. Slocount reckons this represents 7.14 man years of effort. As with the document, there is a discrepancy between CELT and SILK with the latter code being more heavily commented, especially as regards routine parameters. A proper validation of the claim that the code implements the description would take several weeks of time: I guess that we have to take the document shepherd's assurances on this. One issue is that both code and document are pretty much saturated with what we used to call 'magic numbers'. Although these are explained in the document, it does not appear that this is always the case in the code. I would also be happier if the code contained Doxygen (or similar) dcoumentation statements for all routines (rather than just the API). So overall, the work is something that ought to be standardized but the document needs further work - not quite ready for the IESG. Major issues: Can we accept the code as normative? If not how do we proceed? Minor issues: Contrast between decoder descriptions of LP part and CELT part: The SILK descriptions go into gory detail on the values used in lots of tables, etc., whereas the CELT part has a very limited treatment of the numeric values used (assuming reliance on finding the values in the reference implementation, either explictly or implicitly). There are things to be said for both techniques. I was wondering (while reading the SILK description) if the authors have any means of automatically generating the tables from the code in the SILK part (or vice versa) to avoid double maintenance. On the other hand, there are pieces of the CELT decoder description (especially in s4.3.3 where knowing numbers of bands, etc.) where some actual numbers would help comprehension. s2 (and more generally): The splitting of the signal in the frequency domain into signal (components?) below and above 8kHz in the hybrid case presumably requires that the output of the CELT encoder is windowed so that only one of encoders gnerates output below 8kHZ. I think something is needed in s2 to explain how this is managed (presumably to do with energy bands?). I didn't find anything in s5 about what has to be done for the encoder when running in hybrid mode which surprised me somewhat. s4.1: Despite having found a copy of the range coding paper and tried to read it, I found the description of range coding opaque (there are some more words later in s5 but this is a bit late for understanding the decoder). Given that this is (I think) fairly novel, some additional less opaque description could be very helpful to people trying to understand what is going on. In particular knowledge of how entropy coding works is pretty much a prerequisite. s4.2.5, para 3: How? s4.2.5, para 4: Should this be phrased in RFC 2119 requiremenmts language? The first part sounds like a SHOULD with the second part being the get out , but its not entirely clear what the consequences are other then simplicity. ====================================================================== MINOR ISSUES ABOVE submitted as part 1 of review ====================================================================== general/s11.2: Several references [Hadamard], [Viterbi}, etc., are to Wikipaedia pages. Whilst these are convenient (and only illustrative) they are not guaranteed to be very stable. Better (i.e., more stable) references are desirable. s1, para 2: Is this a MUST? There are instances in the text which might contradict this (e.g., para 1 of s4.2.7.5 which has (capitalized) SHOULDs). s4.3: As a complete newcomer to CELT, I would have appreciated a more high level understanding of what CELT is doing at this point. I tried reading s4.3 without any additional input and found it very hard going. Eventually I gave up and went looking for some additional input. This presentation seems to have a useful view http://www.ietf.org/proceedings/79/slides/codec-2.pdf I think that it would be extremely helpful to have a description similar to this at this point in the document, even though there is some material in section 5.3 which could also be forward referenced. Still the material in s5.3 does not start from the basic principles that CELT is using, and since these are essentially novel, it would be very good to give prospective implementers/users an understanding of what is going on. Incidentally, I found the above IETF presentation more useful than http://www.celt-codec.org/presentations/misc/lca-celt.pdf Note that the SILK part seems rather less opaque. It would also be useful to indicate numerically how many bands are involved and what the number of MDCT bins are in the various bands. s4.3, last para: Can the 'out of range error' occur in the LP decoder? (if not why not?) ====================================================================== Nits/editorial comments: global: bytes -&gt; octets global: The form/terminology Q&lt;n&gt; (e.g., Q13, Q15, Q16) ought to be explained. s1: Expand CELP s1.1.6: Need to define floor(). s2: ? Expand SILK s2: Reference for Vorbis. s2.1.8: Expand AAC (and MP3). s3: References for Ogg, Matroska, maybe RTP. s3: Fig 1, Table 2 and intervening text: Presumably SILK only (Table 2) etc correspond to MODES 1-3 in Figure 1. This needs to be consistent. s3.2.1: Make it clear which of the octets is len[0]/len[1]. To be precise it might be better to say len0/len1 are the values of the two length octets (in whichever order you intend). The form len[0] could be misinterpreted as a function 'length of 0'. s3.2.5: better s/figure below/Figure 5/ s3.2.5: 'This number' is not the compressed length of each frame that is the subject of the first sentence, but the number of remaining octets - this needs rewording. s3.2.5: Surely this is a non sequitur? This might be better phrased as 'The total size of a well formed packet MUST be at least...' s3.3: The example diagrams ought to have figure numbers. s3.4: I am not keen on duplicating normative requirements in this way (double maintenance issue). It would be better to put explicit numbered requirements in the sections above an reference the resulting numbers here. s4.1: How are the 'top seven bits' to be interpreted here? e.g. as the bottom seven bits of a 8 bit integer field? an 8 bit integer with the lowest bit zeroed out? s4.1.1: This is really a global point. This section refers to entdec.c. Presumably (since we haven't reached the code yet) and it is still compressed, there is some file structure. I don't think this has been said above. It would be good to provide a list of the file components (i.e., sectional structure of the code) at the start, maybe even giving line number positions within the decompressed code. s4.1.1.1: This is not well phrased. Better Then it reads the next octet of the payload [packet? payload hasn't really been used before] and combines the left over bit from the previous octet (see Section 4.1 for starting this process) as the high bit (bit 7)| of 'sym' and the top 7 bits of the octet as the other 7 bits of sym, leaving the remaining bit for the next iteration. s4.1.5.2: Should r_Q15 = rng &gt;&gt; (l-16) be r_Q15 = rng &gt;&gt; (lg-16)? There doesn't seem to be an 'l' defined. s4.2.1: Expand LTP earlier. It would also be useful to expand LPC again. s4.2.2: acronym VAD is not expanded until the beginning of s4.2.3. s4.2.7: acronym LSF needs to be expanded on first use. s4.2.7.1: Explain briefly why Table 7 has values for indices 0 to 15 when wi0/1 are in range 0 to 14. s4.2.7.4, para below Table 12: s/gain index/gain_index/ as this variable is used subsequently. s4.2.7.4: The use of log_gain seems slightly confusing when combined with gain_index. One at least is presumably log scaled. Maybe a bit more explanation is needed. ====================================================================== COMMENTS ABOVE submitted as part 1 of review ====================================================================== General: Define L1 and L2 (as in L1-norm, etc). s4.2.7.2, last para: What are the consequences (or what actions need to be taken) if it is not invoked? s4.2.7.5, para 1: 'on the unit circle between 0 and pi' might be clearer as 'on the upper half of the unit circle' or 'on the half of the unit circle in the positive imaginary area of the complex plane'. 'standard decomposition'? Needs a reference. s4.2.7.5, para 1: A reference for the use of LSF in LPC would be useful. s4.2.7.5.x: There is inconsistent use of stage 1/stage 2 vs stage-1/stage-2. Please be consistent. s4.2.7.5, para 1: - Does this contradict the 'must' in s1, para 2? - What are the consequences of ignoring the SHOULD? How bad would they get? Might it become unstable and how would one know? s4.2.7.5.1, para 1: s/This indexes an element in a coarse codebook, selects the PDFs for the second stage of the VQ/This indexes an element in a coarse codebook that selects the PDFs for the second stage of the VQ/ s4.2.7.5.3, last para: A reference that indicates why this requirement is needed would be desirable. (and also for s4.2.5.7.8). s4.2.7.5.4 and Table 25: Are the values in Table 25 NDeltaMin or NDelatMin_Q15? The equations after Table 25 use both NDeltaMin and NDeltaMin_Q15. Is this correct? In particular the first two equations deliver _Q15 values but use raw NDeltaMin. s4.1.1/s4.2.7.1 and other places: The term 'exact integer division' is used in various places. My understanding was that this phrase implied that it was known that the dividend was an exact multiple of the divisor by some out-of-band means. This doesn't seem to be the case generally in Opus (e.g,, where both n/5 and n%5 are needed - clearly this doesn't anticipate n%5 == 0 every time!) So what does 'exact integer division' imply? A definition may be needed. s4.3, last para: s/described in the figure above./described in Table 55 above./ s4.3.1: This statement appears out of the blue apparently. Some more explanation of what the transient flag actually implies and why we should be so sure about its PDF would help. s4.3.2.1: Arguably a reference is needed for the z-transform. s4.3.2.1: Avoid the equation picture splitting across page boundaries. in the current version it is unclear what the denominator is. (use needLines processing direcrive in xml2rfc). Same applies to the equation below Table 57 in s4.3.4.3. 4.3.2.1, after the equations: As a person with limited skills in the srt, I have no idea what desynchronization implies here. 4.3.2.1, ibid: I suspect this sentence belongs before the equation described the z-transform. Where are the values of the parameters for the inter-frame mode defined (the intra-frame ones are in the text)? s4.3.2.3: Paragraph on decoding band boosts: Might be improved by using equations rather than the wordy descriptions used at present. (global)s4.3.2.3, para above table 56: s/iff/if and only if/ s4.3.2.3: LOG2_FRAC_TABLE is missing. s4.3.3: It would be helpful to explain either here, or at the outset of s4.3 overall, how the concept of energy bands and MDCT bins applies to the CELT part of the codec, and just how many bands and bins are used. Some of this is contained in s5.3.2, but the magic number 17 appears later in 4.3.3 which is presumably something to do with the point in the frequency domain that CELT takes over from LP in the hybrid mode. It would make the very complex section 4.3.3 rather easier to understand with this extra information - I have to say I struggled! On reflection, I think an example of what bits are allocated to a band and how thay rae subsequently used would be quite helpful - Without going to delve into the code I am really not clear that I understand just what bits are allocated and what they then encode and I have read the text quite a few times now. s4.3.3: Be consistent between 'tone to noise' and 'tone-to-noise'. s4.3.3: This paragraph contains a number of interesting assertions: Is there a reference where one could see them justified (it may be that this is the result of original research in the Opus team). s4.3.3, paragraphs after the bullet points: The concepts of 'shape' and 'shape encoding' is introcuced here without explicit definition. Are we talking about the shape windowing used in FFT/MDCT here? This should be made clear. s4.3.3, 5th para after bullet points: s/In the reference the maximums/In the reference implementation the maximums/ s4.3.3, 6th para after the bullet points: A table of bands per mode and number of MDCT bins covered would be helpful here in order to get a feeling for the scale of the problem. Also the cache_caps50 table in the code contains the magic number 168. Where does this come from? s4.3.3, 6th para after the bullet points: Where do these frame sizes get specified? And what is the total set of frame sizes? The text says 'e.g.' (which incidentally should be 'e.g.,') implying that this is not the complete set. s4.3.3, 6th para after the bullet points: Need to define 'truncating integer division' to go with 'exact integer division'. s4.3.3, 7th para after the bullet points: How many, at least, and what values? Are these range encoded? I don't see them in the table above or with a PDF specified. s4.3.3, 7th para after the bullet points: Would that be a value of two or two bits? s4.3.3: Paragraph on decoding band boosts: Might be improved by using equations rather than the wordy descriptions used at present. (global)s4.3.3, para above table 56: s/iff/if and only if/ s4.3.3, 2nd para after Table 56: The terms 'intenmsity stereo' and 'dual stereo' don't appear to have been defined. s4.3.3: LOG2_FRAC_TABLE is missing. 4.3.4.3, last para: Should this sentence come before the previous paragraph? There isn't really a 'following process' in this section and I don't think it menas the process in s4.3.4.4? s4.3.4.3, last sentence: I think this needs some more explanation for the uninitiated. s4.3.4.4: What this limit is does not appear to be defined. s4.3.5: The 'collapse' phenomenon is not fully defined, and it would be useful to mention why it happens. Also s/min/minimum/. s4.3.6: s/Just like/Just as/ s4.3.7, last para: I think 'power complementarity' requires further explanation or a reference. s4.5, para 3: s/To avoid or reduces glitches during these/To avoid or reduce glitches during these/ s4.5.1.1, para 1: s/For for SILK-only/For SILK-only/ s4.5.1.4, para 2: s/redundant frame is as-is,/redundant frame as-is,/ s5, figure 16: The Optional High-pass Filter box has two spurious '+' symbols on the vertical sides. s5, last para: A reference for the Auto Regressive Moving Average (ARMA) filter would be useful. s5.2.3.4.2.1, title: s/Burgs method/Burg's Method/ s5.2.3.5, para 2: Expand 'R/D performance' (or probably specify it as abbreviation for rate-distortion in para 1). s5.3.5, para 1 below equation: Is E an abbreviation for 'extra'? s5.3.6: The abbreviation RD for rate-distortion is defined here (see comment on s5.2.3.5). s6.1: This section is perhaps a little 'triumphalist' for the reference implementation (this may of course be justified!. The quality metric is a 'relative quality metric' and presumably if someone does a *really* good job of coding, it is entirely possible that the new algorithms might get better than 100 on the quality score (i.e., provide a better answer than the reference implementation). s6.2: Just wondering, but is non-standard frame size the only option offered by Opus Custom? If not, probably more text is needed here. Are there any major changes to the algorithms implied by the use of Opus Custom? s7. Referencing SECGUIDE (RFC 3552) seems inappropriate since it occurs in such a security considerations section. Just omit it. s11.2: A number of references are to Wikipaedia pages. While these were useful to me in refreshing or initializing my knowledge, they are not usually considered adequately stable for use in RFCs. I fear you may have to provide more stable references. Appendix A: I checked that the code extracted as inicated and was able to be compiled under Ubuntu 10.04 LTS. </pre> Elwyn Davies 2012-05-14T15:06:13 SecDir review of draft-ietf-ccamp-assoc-info-03 http://comments.gmane.org/gmane.ietf.general/51882 <pre>Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document does not define any new procedures or mechanisms, and mentions this fact three times throughout the document. It formalizes an email by Adrian Farrel clarifying the procedures for processing an ASSOCIATION object on a path message. The security considerations section repeats that the document does not define new procedures, and concludes that no security considerations are added. This is not a valid deduction, as clarification often involves prohibiting non-functional or insecure interpretation of the original document text. However, in this case the clarification is not about such insecure configurations, so the document is fine. One textual comment, though: section 2.2 near the bottom of page #5 lists 3 possible values for association ID. The second option is "The LSP ID of the LSP protecting an LSP". This is not clear. I suggest rewording as "The LSP ID of the protecting LSP" without an indefinite "an LSP". Yoav </pre> Yoav Nir 2012-05-13T06:46:39 Weekly posting summary for ietf< at >ietf.org http://comments.gmane.org/gmane.ietf.general/51879 <pre>Total of 137 messages in the last 7 days. script run at: Fri May 11 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.03% | 11 | 7.81% | 75340 | sm&lt; at &gt;resistor.net 5.84% | 8 | 6.11% | 58911 | ynir&lt; at &gt;checkpoint.com 5.84% | 8 | 5.74% | 55379 | john-ietf&lt; at &gt;jck.com 3.65% | 5 | 5.12% | 49405 | hsantos&lt; at &gt;isdg.net 3.65% | 5 | 4.54% | 43771 | brian.e.carpenter&lt; at &gt;gmail.com 3.65% | 5 | 4.40% | 42406 | tobias.gondrom&lt; at &gt;gondrom.org 4.38% | 6 | 3.12% | 30131 | randy&lt; at &gt;psg.com 3.65% | 5 | 3.57% | 34387 | chair&lt; at &gt;ietf.org 3.65% | 5 | 2.87% | 27711 | mrex&lt; at &gt;sap.com 2.92% | 4 | 3.10% | 29856 | msk&lt; at &gt;cloudmark.com 2.92% | 4 | 2.65% | 25521 | dwm&lt; at &gt;xpasc.com 2.19% | 3 | 2.60% | 25080 | sant9442&lt; at &gt;gmail.com 2.19% | 3 | 2.39% | 23047 | marshall.eubanks&lt; at &gt;gmail.com 2.19% | 3 | 2.35% | 22671 | scott&lt; at &gt;kitterman.com 2.19% | 3 | 2.06% | 19886 | hannes.tschofenig&lt; at &gt;nsn.com 2.19% | 3 | 2.04% | 19640 | fred&lt; at &gt;cisco.com 2.19% | 3 | 2.01% | 19427 | ted.ietf&lt; at &gt;gmail.com 2.19% | 3 | 1.78% | 17163 | dhc&lt; at &gt;dcrocker.net 2.19% | 3 | 1.73% | 16638 | dougb&lt; at &gt;dougbarton.us 2.19% | 3 | 1.69% | 16255 | touch&lt; at &gt;isi.edu 1.46% | 2 | 2.28% | 21993 | hallam&lt; at &gt;gmail.com 1.46% | 2 | 1.71% | 16487 | housley&lt; at &gt;vigilsec.com 1.46% | 2 | 1.67% | 16111 | warren&lt; at &gt;kumari.net 1.46% | 2 | 1.49% | 14405 | presnick&lt; at &gt;qualcomm.com 1.46% | 2 | 1.49% | 14367 | dotis&lt; at &gt;mail-abuse.org 1.46% | 2 | 1.30% | 12556 | melinda.shore&lt; at &gt;gmail.com 1.46% | 2 | 1.30% | 12541 | ned+ietf&lt; at &gt;mauve.mrochek.com 1.46% | 2 | 1.27% | 12273 | dworley&lt; at &gt;avaya.com 1.46% | 2 | 1.18% | 11333 | johnl&lt; at &gt;iecc.com 1.46% | 2 | 1.09% | 10517 | paul&lt; at &gt;cypherpunks.ca 0.73% | 1 | 1.34% | 12937 | ondrej.sury&lt; at &gt;nic.cz 0.73% | 1 | 1.16% | 11194 | mary.ietf.barnes&lt; at &gt;gmail.com 0.73% | 1 | 1.08% | 10431 | adrian&lt; at &gt;olddog.co.uk 0.73% | 1 | 1.02% | 9790 | narten&lt; at &gt;us.ibm.com 0.73% | 1 | 0.88% | 8467 | allison.mankin&lt; at &gt;gmail.com 0.73% | 1 | 0.78% | 7499 | eburger-l&lt; at &gt;standardstrack.com 0.73% | 1 | 0.75% | 7190 | john&lt; at &gt;jck.com 0.73% | 1 | 0.73% | 7062 | hsantos&lt; at &gt;santronics.com 0.73% | 1 | 0.72% | 6960 | marka&lt; at &gt;isc.org 0.73% | 1 | 0.68% | 6593 | stephen.farrell&lt; at &gt;cs.tcd.ie 0.73% | 1 | 0.68% | 6523 | nick&lt; at &gt;inex.ie 0.73% | 1 | 0.67% | 6457 | glen&lt; at &gt;amsl.com 0.73% | 1 | 0.67% | 6413 | bob.hinden&lt; at &gt;gmail.com 0.73% | 1 | 0.64% | 6200 | jason_livingood&lt; at &gt;cable.comcast.com 0.73% | 1 | 0.63% | 6049 | mail&lt; at &gt;sabahattin-gucukoglu.com 0.73% | 1 | 0.61% | 5914 | yaakov_s&lt; at &gt;rad.com 0.73% | 1 | 0.60% | 5830 | dcrocker&lt; at &gt;bbiw.net 0.73% | 1 | 0.60% | 5780 | peter.sylvester&lt; at &gt;edelweb.fr 0.73% | 1 | 0.57% | 5470 | markku.savela&lt; at &gt;vtt.fi 0.73% | 1 | 0.57% | 5460 | stpeter&lt; at &gt;stpeter.im 0.73% | 1 | 0.56% | 5404 | jaap&lt; at &gt;nlnetlabs.nl 0.73% | 1 | 0.55% | 5293 | cos&lt; at &gt;aaaaa.org 0.73% | 1 | 0.53% | 5083 | michel&lt; at &gt;arneill-py.sacramento.ca.us 0.73% | 1 | 0.52% | 5037 | ajs&lt; at &gt;anvilwalrusden.com --------+------+--------+----------+------------------------ 100.00% | 137 |100.00% | 964244 | Total </pre> Thomas Narten 2012-05-11T04:53:03 Finally, It's The Year Of Linux^H^H^H^H^HIPv6 http://comments.gmane.org/gmane.ietf.general/51826 <pre>I really shouldn't, so soon after his last inflammatory rant, but here: http://www.theregister.co.uk/2012/05/08/ipv6_coming_next_month/ &lt;Quote&gt; One month from now, World IPv6 Launch Day with be upon us. Numerous online services will be enabling IPv6 and leaving it on. AAAA records will be published, and those of us with IPv6 enabled systems will start to use IPv6 preferentially to IPv4. But what does this all mean? For the short term at least, the truth is "not much". … &lt;/quote&gt; Ignoring the obvious error with the preceding quote, on this occasion, he does at least appear to have one thing right: most people really aren't all that motivated, in the short term. The apathy continues a pace, and most of the industry is obliged to help in turn by doing almost nothing. Whether it will after June 6 is an open question, but I don't imagine he'll be far off there, either. What's important here, I think, is simply that the desire to have IPv6 deployed and running is outpaced by people's ongoing desire to ignore it. "Networking nerds" are happy because IPv6 at long last has a sporting chance. Everyone else just wants less of the hype. *Grumble* Cheers, Sabahattin </pre> Sabahattin Gucukoglu 2012-05-09T03:34:32 a favor from the list about Jon Postel http://comments.gmane.org/gmane.ietf.general/51816 <pre>Hi, all, My apologies for contacting this list with a non-IETF issue, but since this community knew Jon well, I'm asking for its help (among others). --- There is a Facebook page that falsely implies being owned by Jon Postel: https://www.facebook.com/jon.postel Facebook has declined requests from Jon's family to have this page removed. To everyone on this list: PLEASE do not "LIKE" or interact with this page. Jon passed in 1998, as you know, 5 years before Facebook ever existed. He never had a page on this or any other social networking site, and whomever is running this should stop misrepresenting themselves. If anyone here can help, please let me know. Joe touch&lt; at &gt;isi.edu </pre> Joe Touch 2012-05-08T23:19:26 [Fwd: IETF posting delays] http://comments.gmane.org/gmane.ietf.general/51807 <pre> -------- Original Message -------- Subject: [Fwd: Re: [IETF] Re: IETF posting delays] Date: Tue, 08 May 2012 07:31:13 -0400 From: Hector Santos &lt;sant9442&lt; at &gt;gmail.com&gt; To: Warren Kumari &lt;warren&lt; at &gt;kumari.net&gt; CC: SM &lt;sm&lt; at &gt;resistor.net&gt;, John C Klensin &lt;john-ietf&lt; at &gt;jck.com&gt;, ietf-action&lt; at &gt;ietf.org I'm giving up. Now using gmail account. As you can see with the response below to Warren and cc: Mary, John, and the IETF list, was sent last night at May 7, 23:01. My MTA transport logs show it was sent to all four, so I am presuming the direct mail was received and perhaps you can confirm you received it. Yet, not posted on the list, not on the IETF archive, my copy never sent. Thats now two submissions by a subscribed member that are in la la land. So its not working. The IETF wants to improve its image with the minority engineering community? Wants to reduce the noise? Wants to increase IETF meeting attendance? IMO, this policy in place for subscribed member mail holding and filtering when the mail is never posted, needs to be seriously reviewed. The perception amounts to nothing else but deliberate censorship, especially when the mail appears to be discarded. I have current plans and budgeting to attend the next two IETF Meetings. I have second thoughts now, dropping my I-D work and just stay out of the IETF scene. Who needs the stress! </pre> Hector Santos 2012-05-08T11:35:31 IETF posting delays http://comments.gmane.org/gmane.ietf.general/51759 <pre>For IETF mailing lists like this, I would prefer to use my real "professional" email address hsantos&lt; at &gt;santronics.com. However, since it often takes over 24 hours or longer, and in cases over the year "lost" (never posted), I regularly now use my junk gmail.com alias account which is posted on the IETF list "immediately" with a copy sent my santronics.com account hosting server and picked up within minutes of my next mail reader pop3 poll. Have others experience similar delays with their accounts? and had to use other domains, like gmail.com? When I first begin to take notice a while back and last year I decided to ask the list admin. He replied shortly and indicated there was no moderation. I also asked a few IETF veterans, a WG chair and AD, and they all repeated there was no moderation going on. But I believe I read an IETF person in the list explained delays was mostly due to moderation. If so, while I don't see any reason for it, I was never given any notice my email would be moderated and I would like to ask why my email is being moderated? Of course, it doesn't make sense because if there was moderation it would be on the address and not the "person" since I can post via gmail.com. If not the case, trying to provide the benefit of doubt and seeking a logical reason for it, I figured the IETF list/MTA software is using some custom outbound queuing/scheduling logic with a higher preference for email domain volume, i.e. gmail.com at the top and individual domain accounts last in its scheduling logic. Since gmail.com is a popular account used by many in this list, maybe that would explain why the MTA sending this out faster than others. I offered this logical out reason to the list admin and he wasn't sure of the legacy software queuing logic. Anyway, just trying to figure out why the delays since I can stick with my real account and not the gmail.com junk account. Thanks -- HLS </pre> Hector 2012-05-05T22:39:27 Weekly posting summary for ietf< at >ietf.org http://comments.gmane.org/gmane.ietf.general/51742 <pre>Total of 125 messages in the last 7 days. script run at: Fri May 4 00:53:01 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 6.40% | 8 | 9.28% | 93921 | mary.ietf.barnes&lt; at &gt;gmail.com 6.40% | 8 | 5.17% | 52339 | dworley&lt; at &gt;avaya.com 5.60% | 7 | 4.37% | 44283 | melinda.shore&lt; at &gt;gmail.com 4.80% | 6 | 5.10% | 51614 | ynir&lt; at &gt;checkpoint.com 4.80% | 6 | 4.02% | 40699 | sm&lt; at &gt;resistor.net 3.20% | 4 | 4.06% | 41134 | jgunn6&lt; at &gt;csc.com 4.00% | 5 | 3.05% | 30885 | john-ietf&lt; at &gt;jck.com 3.20% | 4 | 3.54% | 35851 | msk&lt; at &gt;cloudmark.com 3.20% | 4 | 3.34% | 33782 | mmorrow&lt; at &gt;cisco.com 0.80% | 1 | 4.59% | 46476 | nurit.sprecher&lt; at &gt;nsn.com 2.40% | 3 | 2.46% | 24903 | sant9442&lt; at &gt;gmail.com 2.40% | 3 | 2.33% | 23568 | narten&lt; at &gt;us.ibm.com 2.40% | 3 | 2.19% | 22127 | hallam&lt; at &gt;gmail.com 2.40% | 3 | 2.11% | 21375 | framefritti&lt; at &gt;gmail.com 2.40% | 3 | 1.88% | 19051 | ned+ietf&lt; at &gt;mauve.mrochek.com 2.40% | 3 | 1.84% | 18652 | rbarnes&lt; at &gt;bbn.com 0.80% | 1 | 2.89% | 29234 | rumbiles&lt; at &gt;gmail.com 1.60% | 2 | 1.94% | 19672 | stewe&lt; at &gt;stewe.org 1.60% | 2 | 1.34% | 13565 | ron&lt; at &gt;debian.org 1.60% | 2 | 1.32% | 13334 | fred&lt; at &gt;cisco.com 1.60% | 2 | 1.22% | 12351 | bortzmeyer&lt; at &gt;nic.fr 1.60% | 2 | 1.21% | 12246 | scott.brim&lt; at &gt;gmail.com 1.60% | 2 | 1.07% | 10838 | dhc&lt; at &gt;dcrocker.net 0.80% | 1 | 1.53% | 15493 | stephen.farrell&lt; at &gt;cs.tcd.ie 0.80% | 1 | 1.44% | 14590 | linda.dunbar&lt; at &gt;huawei.com 0.80% | 1 | 1.33% | 13427 | alan.kavanagh&lt; at &gt;ericsson.com 0.80% | 1 | 1.28% | 12969 | cb.list6&lt; at &gt;gmail.com 0.80% | 1 | 1.20% | 12143 | lars&lt; at &gt;netapp.com 0.80% | 1 | 1.19% | 12029 | hsantos&lt; at &gt;santronics.com 0.80% | 1 | 0.96% | 9742 | marc.blanchet&lt; at &gt;viagenie.ca 0.80% | 1 | 0.83% | 8416 | dave&lt; at &gt;cridland.net 0.80% | 1 | 0.74% | 7532 | stbryant&lt; at &gt;cisco.com 0.80% | 1 | 0.74% | 7489 | glenzorn&lt; at &gt;gmail.com 0.80% | 1 | 0.72% | 7257 | mcr&lt; at &gt;sandelman.ca 0.80% | 1 | 0.71% | 7236 | jmpolk&lt; at &gt;cisco.com 0.80% | 1 | 0.71% | 7201 | warren&lt; at &gt;kumari.net 0.80% | 1 | 0.71% | 7158 | hgs&lt; at &gt;cs.columbia.edu 0.80% | 1 | 0.69% | 6949 | akatlas&lt; at &gt;gmail.com 0.80% | 1 | 0.66% | 6709 | hannes.tschofenig&lt; at &gt;gmx.net 0.80% | 1 | 0.66% | 6680 | avri&lt; at &gt;psg.com 0.80% | 1 | 0.64% | 6477 | daedulus&lt; at &gt;btconnect.com 0.80% | 1 | 0.63% | 6401 | jdrake&lt; at &gt;juniper.net 0.80% | 1 | 0.63% | 6397 | uyeshiro&lt; at &gt;ifa.hawaii.edu 0.80% | 1 | 0.62% | 6288 | mrw&lt; at &gt;lilacglade.org 0.80% | 1 | 0.62% | 6278 | randy_presuhn&lt; at &gt;mindspring.com 0.80% | 1 | 0.61% | 6177 | cabo&lt; at &gt;tzi.org 0.80% | 1 | 0.61% | 6165 | richard&lt; at &gt;shockey.us 0.80% | 1 | 0.61% | 6128 | kpfleming&lt; at &gt;digium.com 0.80% | 1 | 0.58% | 5859 | huubatwork&lt; at &gt;gmail.com 0.80% | 1 | 0.58% | 5858 | ben&lt; at &gt;nostrum.com 0.80% | 1 | 0.56% | 5683 | joelja&lt; at &gt;bogus.com 0.80% | 1 | 0.56% | 5671 | paul.hoffman&lt; at &gt;vpnc.org 0.80% | 1 | 0.56% | 5668 | ted.ietf&lt; at &gt;gmail.com 0.80% | 1 | 0.56% | 5622 | brian.e.carpenter&lt; at &gt;gmail.com 0.80% | 1 | 0.55% | 5614 | yaakov_s&lt; at &gt;rad.com 0.80% | 1 | 0.55% | 5611 | derhoermi&lt; at &gt;gmx.net 0.80% | 1 | 0.54% | 5487 | harald&lt; at &gt;alvestrand.no 0.80% | 1 | 0.54% | 5454 | hartmans-ietf&lt; at &gt;mit.edu 0.80% | 1 | 0.53% | 5343 | mrex&lt; at &gt;sap.com 0.80% | 1 | 0.53% | 5316 | acooper&lt; at &gt;cdt.org 0.80% | 1 | 0.52% | 5277 | john&lt; at &gt;jck.com 0.80% | 1 | 0.50% | 5025 | randy&lt; at &gt;psg.com 0.80% | 1 | 0.50% | 5017 | robert&lt; at &gt;raszuk.net 0.80% | 1 | 0.47% | 4802 | cos&lt; at &gt;aaaaa.org --------+------+--------+----------+------------------------ 100.00% | 125 |100.00% | 1012538 | Total </pre> Thomas Narten 2012-05-04T04:53:01 IETF Trust Minutes since August 2011 http://comments.gmane.org/gmane.ietf.general/51736 <pre>Dear IETF Trust, The IETF Trust reported during the IETF83 meeting that the "Minutes are complete except for the meeting held this morning". I don't see any minutes published since August 2011. Could these minutes be published in a timely manner? It was also mentioned the subpoenas would be published as they come in. Where can I find them? Does the amount of US$600 cover the storage cost of the "blue sheets"? Can the IETF Trust review the second paragraph of the message at http://www.ietf.org/mail-archive/web/ietf/current/msg73049.html and provide feedback to the IETF Community? Regards, -sm </pre> SM 2012-05-03T10:48:35 Mailing list for LGBTQ participants in the IETF http://comments.gmane.org/gmane.ietf.general/51727 <pre>For those not aware of it, there is a long-standing mailing list for LGBTQ participants in the IETF: ietf-motss&lt; at &gt;lists.pensieve.org (with subscription at ietf-motss-request&lt; at &gt;lists.pensive.org). About the IETF-MOTSS List: ----- --- ---------- ----- This list is for use by members of the IETF-MOTSS (Members of the Same Sex, an out of date term for lesbian, gay, bi, transgendered, etc.) community. Topics of discussion include social events held during IETF meetings (traditionally called "anti-socials" if they occur at the same time, but separate from, the main social or "sub-socials" if they occur within the main social), and anything else of interest to the community. regards, Ted </pre> Ted Hardie 2012-05-02T18:16:50 Search Engine Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.general