Draft IAOC Administrative Policy
All; The IAOC is considering adopting Administrative Procedures. The Draft policy can be found at: http://iaoc.ietf.org/policyandprocedures.html in doc, pdf and txt formats. Some areas covered include: 1. Number of meetings per year 2. Chair Selection 3. Quorum and Voting The IAOC expects to adopt a policy at its 21 August meeting. Your input in most appreciated. Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Missing Materials
Eric Rescorla wrote: As I have done for previous IETFs I just ran getdrafts (http://tools.ietf.org/tools/getdrafts/) on the entire agenda and what follows is the output. As you can see, a pretty substantial number of WGs are without agendas, about 10% of the drafts listed are wrong, and about half of those appear to be simple version errors. -Ekr draft-ietf-eai-smtpext-11.txt (wg=eai) draft-ietf-eai-utf8headers-09.txt (wg=eai) draft-ietf-eai-downgrade-07.txt - draft-ietf-eai-downgrade-08.txt (wg=eai) draft-ietf-eai-imap-utf8-02.txt - draft-ietf-eai-imap-utf8-03.txt (wg=eai) draft-ietf-eai-pop-03.txt - draft-ietf-eai-pop-04.txt (wg=eai) draft-ietf-ipr-3978-incoming-08.txt - draft-ietf-ipr-3978-incoming-09.txt (wg=ipr) draft-ietf-ipr-outbound-rights-06.txt - draft-ietf-ipr-outbound-rights-07.txt (wg=ipr) all fixed now. Thanks for running the check! Harald, back from holidays ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Draft IAOC Administrative Policy
I hope this is a small point, but is it clear that what you want is legal counsel to the IAOC rather than to IASA? Brian On 2008-07-26 19:52, Ray Pelletier wrote: All; The IAOC is considering adopting Administrative Procedures. The Draft policy can be found at: http://iaoc.ietf.org/policyandprocedures.html in doc, pdf and txt formats. Some areas covered include: 1. Number of meetings per year 2. Chair Selection 3. Quorum and Voting The IAOC expects to adopt a policy at its 21 August meeting. Your input in most appreciated. Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Draft IAOC Administrative Policy
Ray Pelletier wrote: Your input in most appreciated. The draft is nicely simple and straightforward. There seem to be only a small number of holes worth closing: IAOC Administrative Procedures ... 1. The IAOC shall hold at least ten meetings each calendar year, as face to face meetings, as teleconferences at which all participants can speak and hear each other, or as a combination. #3 defines a quorum. Item #1 ought to specify that a qualifying meeting has a quorum present. Absent a quorum, it doesn't count as one of the 10 meetings. (And if this isn't the policy you intend, it's worth making that explicit. However, that means there could be no meetings ever having a quorum...) This is more than a formal nicety. Ensuring a quorum creates some pressure to line up participation ahead of time. 7. The IAOC voting members shall not receive any compensation (apart from reimbursement of expenses) for their services as IAOC members. Most members are likely to have their principal employer subsidize their IAOC participation, on one fashion or another. Given the history of the IETF, I suspect no one will consider this problematic. The current wording would seem to prohibit that. I suspect the intention is that IETF, IAOC, ISOC (or the like, related organizations) won't be compensating participation. 8. The IAOC shall be guided by RFC 4071, as amended and supplemented. Guided by is such an interesting language choice. Possibly quite a good one. But distinctive enough to warrant some clarification, I think. For example, it implies that the IAOC is free to utterly ignore it, after have been guided by it. Perhaps that is both intended and desired? Still, this item pertains to decision-making policy. So, for example, is IAOC free to be whimsical about applying Section 2.3 of 4071? (No, I don't think a real IAOC decision would be so cavalier. But a formal document needs to specify things carefully.) With respect to decision-making, should this document specify any sort of appeals process? That is, should it specify a line of accountability? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF-75: sailing to Stockholm
Hi, IETF-75 takes place in Stockholm, Sweden, from July 26-31, 2009. A bunch of us are planning to sail from Finnland to Stockholm during the week before the IETF, and to sail back from Stockholm to Finnland in the week afterwards. Coordinating this with several boats and a bunch of international folks is tricky, which is why we're starting to plan this now. There is a wiki at http://trac.tools.ietf.org/area/tsv/trac/wiki/StockholmSailing that you can refer to for some initial information. This will be the only email I sent with a wide distribution list. If you're interested in this sailing event (or other events at other IETFs), please subscribe to the ietf-sailors list at https://www.ietf.org/mailman/listinfo/ietf-sailors . Lars PS: Feel free to forward this email. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last call comments for capwap-protocol-specification-11
I read capwap-protocol-specification-11 on my way to Dublin; here are some comments/observations. Substantial topics first: Section 3.5: The text about MTU discovery doesn't look right; Section 3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would provide it with the MTU, and then the WTP would establish the CAPWAP session. But those RFCs don't specify e.g. what packets would be used for probing for the MTU. Section 4.6.29: Using MD5 in a new protocol, and not providing algorithm agility for moving to new algorithms, is probably not such a great idea. The linking of control and data channels, and how DTLS session resumption is used here, seems unnecessarily complicated. Normally session resumption is totally TLS internal optimization, and applications running over TLS don't know (and have no need to know) whether full or abbreviated TLS handshake was used. It seems this document wouldn't really need to say anything about session resumption; if the WTP provides the Session ID in data channel, and AC checks that both DTLS connections were established by the same authenticated client, that seems sufficient. This would seem to remove much implementation complexity; e.g. the requirement in 4.4.3 that The AC DTLS implementation MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down doesn't follow the usual TLS/DTLS module boundaries. Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not? The protocol allows the AC to add and delete static MAC ACL entries, but it seems the AC can't check what the current ACL entries are. This means the WTP and AC could get out-of-sync, right? (The AC can't delete the unneeded static MAC ACL entries if it doesn't know what they are.) Section 3.3: there's a single sentence about DNS-based discovery; probably slightly more details would be useful. Section 2.4.3: handling of cookies that fail to validate is really a DTLS detail, and shouldn't be in this specification. RFC 4347 doesn't say what the DTLS server should do, but I think the right approach is to treat an invalid cookie the same as no cookie (and not discard the whole message, as is suggested here -- I think that could lead to weird failure modes even in the absence of malicious attackers). I'll raise this on the TLS mailing list, so it can be clarified in DTLS 1.2 update. Section 4.3: it seems that allocation of WBIDs (and message element numbers in 4.6) would be better done in the document specifying the binding. Considering that WBID allocations require Standards Action, especially allocating WBIDs for technologies for which not even an Internet-Draft exists yet seems premature. Section 4.5.3: Is CAPWAP control protocol strictly lock-step (once you send a Request, you must wait for Response until you send another Request), or are multiple outstanding requests allowed? Can you give up a Request (stop retransmitting it even though you haven't received a Response), and move to the next Request? What should you do if you receive a Request with a Sequence Number that's too old (less than previous Request you've seend) or too new (greater than previous Request+1)? Replay protection is an optional feature in RFC 4347. Should this document say something about it? (e.g. MUST use?) There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using CAPWAP Local IPv4/6 address message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using WTP IPv4/6 address message elements. Minor clarifications/editorial nits: Section 2, 1st para: should reference RFC4347 instead of RFC4346 Section 2.3: should have a sentence saying what transitions represented by punctuation characters mean. Section 2.4.1: DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period While RFC 4347 doesn't specify how long you should continue retransmitting, the intent certainly was not to continue indefinitely. Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, and both parties (not just the DTLS client) retransmit based on timers (in some situations). Section 2.4.4.1: should reference RFC4346 instead of RFC4279. Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice. Section 4.4.1, The 8 bit Length field looks like 16 bits. Section 4.4.2: is it unambiguous which 802.3 frame fields are included or omitted? (e.g. preamble, SOF delimeter, etc.) Section 4.6, message element 29 is spelled Image Information in the rest of the document, but Image Info here Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was only 1 bit, but it's 8 bits). Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is 64
