Re: 6tsch BoF
What did you think of Pete Resnick's draft about hums. i like it a lot and have used it in other fora which are somewhat loose or confused about consensus. randy
Re: procedural question with remote participation
On 8/4/13 4:41 PM, Hadriel Kaplan wrote: On Aug 3, 2013, at 7:25 PM, John C Klensin john-i...@jck.com wrote: First, probably to the when meetings begin part, but noting that someone who gets onto the audio a few minutes late is in exactly the same situation as someone who walks into the meeting room a few minutes late -- announcements at the beginning of the session are ineffective. Jabber appears to have some way of setting a banner/announcement thing that shows up when you first join a jabber session, because I've seen such a thing on occasion. I don't know if it's defined in some standard way in XMPP or a proprietary extension. But assuming it's either standard or defacto and popular, we could put the NOTE WELL in it (or a URL to a NOTE WELL). Likewise for the IETF web pages with the audio links, so that you see the NOTE WELL before clicking the audio link. Or even have an annoying pop-up if you prefer. (ugh) I don't want to promise too much, but in time for Vancouver I'll probably finish some code that sends you all sorts of helpful information when you join the jabber room. There is a standardized room subject message but not all IM clients show you that, so I plan to have it sent as a one-off message when you join the chatroom. Further discussion, if any, on the tools-disc...@ietf.org list. Peter -- Peter Saint-Andre https://stpeter.im/
Re: procedural question with remote participation
On Mon, Aug 5, 2013 at 9:37 AM, Peter Saint-Andre stpe...@stpeter.imwrote: I don't want to promise too much, but in time for Vancouver I'll probably finish some code that sends you all sorts of helpful information when you join the jabber room. There is a standardized room subject message but not all IM clients show you that, so I plan to have it sent as a one-off message when you join the chatroom. Further discussion, if any, on the tools-disc...@ietf.org list. I'd be happy to help, and will meander toward that list. One thing for this August Body to consider - we can (quite) easily have new occupants to the room not be participants - in the XEP-0045 sense of the term. This would mean new occupants would lack voice, and be unable to add to the discussion - until they've jumped through some hoops. One such hoop might be acknowledging the (privately sent) Note Well message (thus equating XEP-0045 Participant with IETF Participant to some degree). Another might be that we tell them to go away if their XEP-0054 vCard doesn't include sufficient detail (like their full name and email address, for example), taking us a step toward remote registration. Dave.
Re: procedural question with remote participation
On 08/05/2013 10:07 AM, Dave Cridland wrote: One such hoop might be acknowledging the (privately sent) Note Well message (thus equating XEP-0045 Participant with IETF Participant to some degree). Another might be that we tell them to go away if their XEP-0054 vCard doesn't include sufficient detail (like their full name and email address, for example), taking us a step toward remote registration. I hope folks who invest effort in tooling try to make it all easier and not harder. Right now we don't have good tools that allow remote folks to easily provide live input (and maybe that's just because its a hard problem). So I'd say we should keep trying to make that better and not worry yet about how to control abuse of what's not currently usable. On 08/04/2013 11:41 PM, Hadriel Kaplan wrote: And have separate rooms that require registering, like [wg-name]@members.ietf.org or whatever, We don't have, nor (I believe) do we want, members. And we do want good technical input regardless of source. About the only reason to try control that via registration is due to patent nonsense. That is (unfortunately) a real reason, and we do have to take it into account, but please let's all bear in mind that 99% of those patents are total crap (regardless of country afaik) and let's not be driven by the stupidity but rather let's put that in its proper place as a regrettable cost of being open. Sorry to go on about that, but I don't think onerous registration schemes are really needed to e.g. do floor control. And since the former (registration stuff) is easy, and the latter (esp. with remote audio input in our environment) is not, we might easily end up doing the easy thing, and making it all worse. Cheers, S.
Re: procedural question with remote participation
At 13:10 04-08-2013, Hadriel Kaplan wrote: OK, I'll bite. Why do you and Michael believe you need to have the slides 1 week in advance? One generation's bad behavior becomes the next generation's best practice. It would be appreciated if those slides could be made available in advance. You have the agenda and drafts 2 weeks in advance. The slides aren't normative. Even I do not have the agenda two weeks in advance. Nowadays, there are if time permits slots in addition to A.O.B. What is the meaning of normative in the above? If you need to have them on the website 7 days in advance, you really need to get a faster Internet connection. ;) Ok. :-) At 14:27 04-08-2013, Hadriel Kaplan wrote: What *would* be good to have 7 days or more in advance are the Technical and OA Plenary slides. They shouldn't be changing, afaict. And that way we can figure out if we can have those nights free for other things, or if it's worth going to the Plenaries instead. But I assume those slides already are made available well in advance. (right?) The Technical and other Plenary slides are not made available well in advance. Someone asked the following question: Does she have a clue that she just asked for feedback from an audience that can't see the link she put on the screen? There was a discussion about beer from the tap after that. Please open a new thread if you would like to discuss about that. :-) At 15:21 04-08-2013, Stephen Farrell wrote: And only something potentially disastrous ought imply even considering a zero-tolerance anything in a volunteer organisation. It is after all a volunteer organisation. I hope that people were not surprised that I did not ask for the Spice Girls session to be cancelled. At 15:41 04-08-2013, Hadriel Kaplan wrote: Do you find this is an actual problem in WG meetings? Are the jabber scribes not able to tell you who is at the mic if you ask them? People have forgotten to state their names Some of the Jabber scribes are not able to tell me who are at the microphone when I ask them. If it was my decision to make (and it is not), the Jabber scribe would be allowed to comment at the microphone even after the microphone line is capped. A person can always argue that it is an arbitrary decision. :-) As an off-topic comment, it's not because the Meetecho people are nice that one should expect them to act as Jabber scribes. At 18:36 04-08-2013, Hadriel Kaplan wrote: But for the general case, the truth is that Fuyou Maio is right - you really do need to be able to parse English quickly to truly participate effectively in an IETF physical meeting. And you need to be reasonably swift in either reading it, or following the speaker's words. It's not nice to say, but it's the truth. Real-time direct human communication is why we have the physical meetings to begin with, instead of only mailing lists and virtual meetings. (and for cross-wg-pollination, and for cookies) Yes. Some sessions are easy to follow. For example, I read some slides posted a few days before and I had an idea of what would be discussed. I looked for the slides for a BoF as it was not clear to me what one of these items on the agenda was about. The slides were not available. I didn't bother asking about them. The correct question would have been about the item on the agenda instead of the slides. Regards, -sm
Re: procedural question with remote participation
Right, but Fuyou was talking about *spoken* English being more challenging than written English (if you can't *read* English fairly quickly, drafts and mailing lists are impenetrable, and you're done in the IETF). I'm told that it's easier for non-native English speakers to read slides than to parse spoken English for anyone who talks faster than I do. Aside: this is yet another reason why a really thorough jabber scribe is useful. swb
Re: procedural question with remote participation
On 05/08/13 10:38, Scott Brim wrote: Right, but Fuyou was talking about *spoken* English being more challenging than written English (if you can't *read* English fairly quickly, drafts and mailing lists are impenetrable, and you're done in the IETF). I'm told that it's easier for non-native English speakers to read slides than to parse spoken English for anyone who talks faster than I do. don't forget there are accents as well which make the parsing challenging even more :) Aaron Aside: this is yet another reason why a really thorough jabber scribe is useful. PS: good ones normally don't have time, and random volunteers may not meet your expectation. sign.. swb
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 3, 2013, at 8:48 AM, Chris Griffiths cgriffi...@gmail.com wrote: IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets From this mail it is not clear what type of feedback you are looking for. I like your direct question from the slide deck better. There you asked: Does the community feel these are reasonable reasons to update the trust agreement? The answer to that question is: yes. It seems reasonable to open up the agreement in order to fulfill its purpose in reasonable, effective, and pragmatic ways. I would expect the trust to come back with a proposal once there seems to be consensus that the the agreement should be opened. My requirement would be that that proposal reflects that the Trust will deal with the assets in a way that is sensible and serves community needs. Best, and thanks, --Olaf PS. As an aside, something that might be helpful for other readers of this thread: The word agreement in Trust Agreement might be confusing to the community, but I think that it is important to point out that the agreement can, since July 1, 2010, be modified unilaterally by the trust (see 10.1 for details and boundary conditions). So except the due diligence that is needed to reflect the communities requirements there is no further negotiation needed with the Settlers. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [87attendees] procedural question with remote participation
On Monday, August 5, 2013, Aaron Yi DING wrote: On 05/08/13 10:38, Scott Brim wrote: Right, but Fuyou was talking about *spoken* English being more challenging than written English (if you can't *read* English fairly quickly, drafts and mailing lists are impenetrable, and you're done in the IETF). I'm told that it's easier for non-native English speakers to read slides than to parse spoken English for anyone who talks faster than I do. don't forget there are accents as well which make the parsing challenging even more challenging. When I have talked to non-native English speakers at the IETF newcomers tutorial, pointing out that many of the speakers they're working to understand are also not not native English speakers often turns out to be encouraging. ...
Re: procedural question with remote participation
On Aug 5, 2013, at 5:28 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: I hope folks who invest effort in tooling try to make it all easier and not harder. Right now we don't have good tools that allow remote folks to easily provide live input (and maybe that's just because its a hard problem). So I'd say we should keep trying to make that better and not worry yet about how to control abuse of what's not currently usable. Yup, afaict we were doing ok until IETF 87... but at least one anonymous jabber participant (named Guest) did remotely speak multiple times at the mic on one of the RAI working group sessions this past week (at RTCWEB if I recall). I was personally ok with it, but it was awkward. If folks feel it's inappropriate, then we need something else. I'd be ok with just having jabber scribes ignore anonymous participants. On 08/04/2013 11:41 PM, Hadriel Kaplan wrote: And have separate rooms that require registering, like [wg-name]@members.ietf.org or whatever, We don't have, nor (I believe) do we want, members. Yeah, members.ietf.org was a poor choice of domain name. I wasn't making a formal proposal - just thinking out loud. I'd be happier if the tools team figures out something simpler and less onerous anyway. I was just noting it's not an impossible task to accomplish, some way or other. And we do want good technical input regardless of source. About the only reason to try control that via registration is due to patent nonsense. That is (unfortunately) a real reason, and we do have to take it into account, but please let's all bear in mind that 99% of those patents are total crap (regardless of country afaik) and let's not be driven by the stupidity but rather let's put that in its proper place as a regrettable cost of being open. Amen to that! -hadriel
Re: procedural question with remote participation
On 08/05/13 07:31, Hadriel Kaplan allegedly wrote: Yup, afaict we were doing ok until IETF 87... but at least one anonymous jabber participant (named Guest) did remotely speak multiple times at the mic on one of the RAI working group sessions this past week (at RTCWEB if I recall). I was personally ok with it, but it was awkward. If folks feel it's inappropriate, then we need something else. I'd be ok with just having jabber scribes ignore anonymous participants. It's inappropriate. Tell them they need to provide at least a name.
Re: procedural question with remote participation
On Aug 5, 2013, at 2:43 PM, Scott Brim scott.b...@gmail.com wrote: On 08/05/13 07:31, Hadriel Kaplan allegedly wrote: Yup, afaict we were doing ok until IETF 87... but at least one anonymous jabber participant (named Guest) did remotely speak multiple times at the mic on one of the RAI working group sessions this past week (at RTCWEB if I recall). I was personally ok with it, but it was awkward. If folks feel it's inappropriate, then we need something else. I'd be ok with just having jabber scribes ignore anonymous participants. It's inappropriate. Tell them they need to provide at least a name. Would it be better if they were called Emma instead of Guest ?
Re: procedural question with remote participation
On 08/05/13 07:51, Yoav Nir allegedly wrote: On Aug 5, 2013, at 2:43 PM, Scott Brim scott.b...@gmail.com wrote: On 08/05/13 07:31, Hadriel Kaplan allegedly wrote: Yup, afaict we were doing ok until IETF 87... but at least one anonymous jabber participant (named Guest) did remotely speak multiple times at the mic on one of the RAI working group sessions this past week (at RTCWEB if I recall). I was personally ok with it, but it was awkward. If folks feel it's inappropriate, then we need something else. I'd be ok with just having jabber scribes ignore anonymous participants. It's inappropriate. Tell them they need to provide at least a name. Would it be better if they were called Emma instead of Guest ? Yes. Ask lawyers.
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
I agree with you John, I also not objecting it but wanted more meaning into the report when I receive it, as I suggested before for clarifications. I don't think majority in IETF think it is meaningless so that is why I want to clarify the meaning and discuss what most may not want to discuss. If this was already discussed could some one point me to a discussion about a weekly post that is done for long and which it may be meaningless by some and understoond the meaning by others. I will add that the report can be misleading, and that I have no intention to write a code for something that is not IETF procedure, but I have intention to clarify such message received each week in IETF that has a lack of information or meaning agreed on. AB On Sun, Aug 4, 2013 at 9:55 PM, John C Klensin john-i...@jck.com wrote: --On Sunday, August 04, 2013 19:53 + John Levine jo...@taugh.com wrote: If there is a serious drive to discontinue the weekly posting summary - I strongly object. As far as I can tell, one person objects, everyone else thinks it's fine. I do not want to be recorded as thinking it is fine. If nothing else, I think was is being reported is meaningless statistically (which doesn't mean people can't find value in it). However, I do not object to its being posted as long as it isn't used to justify personal attacks on individuals for their ranking. It seems to me that isn't quite what you said, rough consensus or not. best, john
Re: procedural question with remote participation
On Aug 5, 2013, at 5:26 AM, SM s...@resistor.net wrote: At 13:10 04-08-2013, Hadriel Kaplan wrote: You have the agenda and drafts 2 weeks in advance. The slides aren't normative. Even I do not have the agenda two weeks in advance. Huh. Sounds like a WG Chair problem. I believe draft agendas are due 2 weeks in advance, and final agendas due 1 week in advance. Or at least that was the excuse I was given when I've been denied requests to add stuff to WG agendas on previous occasions - the Chairs told me I was asking too late. (as they should have) What is the meaning of normative in the above? I was trying to be cute by using the term from our drafts/RFCs, as in normative references vs. informative, or the document's RFC2119-type text is normative while examples are informative. I meant the slides are just helpful guides, like pictorial examples, vs. the draft itself which is the real proposal. I guess the joke flopped. :( Some of the Jabber scribes are not able to tell me who are at the microphone when I ask them. If it was my decision to make (and it is not), the Jabber scribe would be allowed to comment at the microphone even after the microphone line is capped. A person can always argue that it is an arbitrary decision. :-) Again, this sounds like a WG Chair problem. If you find that happening, send a private email to that working group's Chair(s) reminding them of the jabber folks. And if they ignore you, then send a private email to the Area Director(s). WG Chairs and ADs are generally decent human beings, at least in private. ;) As an off-topic comment, it's not because the Meetecho people are nice that one should expect them to act as Jabber scribes. I don't expect Meetecho people to jabber scribe. I expect other folks in the room to volunteer. It's a heck of a lot easier/better than being the minute taker. That's why I volunteer for being a scribe - to avoid being a minute taker. :) -hadriel
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
If one or two people are doing most of the posting to a list, that means something is out of balance. Summary statistics can be used as an indicator that something should be done to encourage diversity, or get people back on topic, etc.
Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10
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-allen-dispatch-imei-urn-as-instanceid-10 Reviewer: Roni Even Review Date:2013-8-5 IETF LC End Date: 2013-8-16 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Major issues: Minor issues: Why is it going to be an Informational RFC, considering that there is a lot of normative language in the document. Nits/editorial comments: According to RFC editor guidelines (http://www.rfc-editor.org/policy.html#policy.abstract) the abstract section should not contain citations unless they are completely defined within the Abstract.
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
On Aug 5, 2013, at 8:03 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: I agree with you John, I also not objecting it but wanted more meaning into the report when I receive it, as I suggested before for clarifications. It's just a weekly posting summary of raw stats - it's not a ranking system, popularity contest, or twitter trending list. It's not important, and doesn't matter. Lots of people have been at the top of that list, and we didn't get a reward or rebuke. Even if the summary script was stopped, people who care can generate their own. What's more important is the content quality of the emails, and no automated script can measure that (except for ones the NSA has I guess). I don't think majority in IETF think it is meaningless so that is why I want to clarify the meaning and discuss what most may not want to discuss. Dude, the majority of the IETF probably thinks this entire mailing list is meaningless. -hadriel
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 5, 2013, at 4:08 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: Does the community feel these are reasonable reasons to update the trust agreement? The answer to that question is: yes. It seems reasonable to open up the agreement in order to fulfill its purpose in reasonable, effective, and pragmatic ways. I would expect the trust to come back with a proposal once there seems to be consensus that the the agreement should be opened. My requirement would be that that proposal reflects that the Trust will deal with the assets in a way that is sensible and serves community needs. +1 --Paul Hoffman
Re: Community Feedback: IETF Trust Agreement Issues
+1 Tobias Gondrom Paul Hoffman paul.hoff...@vpnc.org wrote: On Aug 5, 2013, at 4:08 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: Does the community feel these are reasonable reasons to update the trust agreement? The answer to that question is: yes. It seems reasonable to open up the agreement in order to fulfill its purpose in reasonable, effective, and pragmatic ways. I would expect the trust to come back with a proposal once there seems to be consensus that the the agreement should be opened. My requirement would be that that proposal reflects that the Trust will deal with the assets in a way that is sensible and serves community needs. +1 --Paul Hoffman -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: procedural question with remote participation
Spencer Dawkins spencerdawkins.i...@gmail.com quoted Hadiel really poorly, which confused me as you who said this, but I think it was Hadriel now: OK, I'll bite. Why do you and Michael believe you need to have the slides 1 week in advance? 1) As a WG chair, I'd like to see the slides from a (new) presenter in advance to make sure that the *presentation* is on topic, there aren't too many slides, and that ideally, it is a request for discussion rather than a presentation. That's where the deadline comes from. I don't suggest that 2) As a remote participate, I'd much rather have consolidate slides. That requires a bit of time/effort on the part of the chairs. 3) As an open-standards body, I believe it is hypocritical for us to be posting slides in a vendor proprietary format or one from a standards body that seems to have all of features we dislike (like pay to vote). (I'm okay with the secretariat doing conversion, but they are not instant) (And,open source tools running on open platforms sometimes do not render the slides as intended due to lack of a font or a other thing) Not getting the slides at all is a different matter - but 7 days in advance is counter-productive. They should be as up-to-date as practical, to take into account mailing list discussions. [or at least that's how I justify my same-day, ultra-fresh slides] I distinquish between rev-00 of slides and rev-09. I don't have a problem with updates to the slides, assuming you can find the Export as PDF button. It would be best if you didn't create new slides due to numbering changes. I also understand that ADs running area meeting aren't going to have status updates 7 days in advance, nor do I expect them to. I had not considered Spencer's point about translation, and frankly it is a really really really good point. None of this should be taken as disagreement with proposals to experiment with room shapes, whiteboards, , etc. that I heard last week. +1 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpOMRsk6ml3A.pgp Description: PGP signature
Re: [Trustees] The Trust Agreement
On Aug 5, 2013, at 7:29 AM, John C Klensin john-i...@jck.com wrote: As far as CC is concerned, I'm not persuaded that it meets out need but not persuaded that it would cause great harm for non-standards documents either. At the risk of opening up the paint cabinet inside the bike shed: what do you think meets our need? I ask this specifically about the Tao, the document that was brought up as a good use for the Creative Commons Attribution-ShareAlike (BY-SA) license (see http://creativecommons.org/licenses/). That license seemed to meet the desire (not need) to make the Tao more easily distributed to a wider audience, in multiple languages, and thus open the IETF up to more people. --Paul Hoffman
Re: Community Feedback: IETF Trust Agreement Issues
On Aug 5, 2013, at 7:08 AM, Olaf Kolkman o...@nlnetlabs.nl wrote: On Aug 3, 2013, at 8:48 AM, Chris Griffiths cgriffi...@gmail.com wrote: IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets From this mail it is not clear what type of feedback you are looking for. I like your direct question from the slide deck better. There you asked: Does the community feel these are reasonable reasons to update the trust agreement? This was my intention Olaf, thank you for the feedback. The answer to that question is: yes. It seems reasonable to open up the agreement in order to fulfill its purpose in reasonable, effective, and pragmatic ways. I would expect the trust to come back with a proposal once there seems to be consensus that the the agreement should be opened. My requirement would be that that proposal reflects that the Trust will deal with the assets in a way that is sensible and serves community needs. We will certainly do that once there is consensus on this. Best, and thanks, --Olaf PS. As an aside, something that might be helpful for other readers of this thread: The word agreement in Trust Agreement might be confusing to the community, but I think that it is important to point out that the agreement can, since July 1, 2010, be modified unilaterally by the trust (see 10.1 for details and boundary conditions). So except the due diligence that is needed to reflect the communities requirements there is no further negotiation needed with the Settlers. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Trustees] The Trust Agreement
From: Brian E Carpenter brian.e.carpen...@gmail.com Thanks for the careful explanations. I'll second that; it does seem that some tweaking may be in order. Clearly the Trust shouldn't have blanket permission to abandon or dispose of assets When the time comes to draft actual wording, I would suggest that there be a requirement for a notification to the IETF-Announce list at least one month (or so?) prior to any actual disposal or abandonment, or completion of any agreement to dispose. (Maybe only for IP, and not real property too, such as old servers, etc?) I can't imagine the Trust would be disposing of stuff very often, so I think this would be a reasonable requirement. Noel
Re: Anonymity versus Pseudonymity (was Re: [87attendees] procedural question with remote participation)
--On Sunday, August 04, 2013 19:31 + Ted Lemon ted.le...@nominum.com wrote: If you came to the IETF and were working for company X, registered pseudonymously, and didn't disclose IPR belonging to you or company X, and then later company X sued someone for using their IPR, you and company X would get raked over the coals, jointly and severally; the deliberate attempt to deceive would make things worse for you. And that's the point: to provide you with a strong disincentive to doing such a thing. So whether the rules prevent you from being anonymous, or prevent you from suing, everybody's happy. If company X wanted to collaborate with Yoav in preserving his pseudonym (i.e., not disclosing the binding to his name), they could presumably file a disclosure without identifying the particular employee for whom the disclosure was made. Especially with the ambiguities created by anonymous and pseudonymous remote participation, I assume we would not decline to post an IPR disclosure from an organization on the grounds that we didn't know who was affiliated with it who participated in the IETF. (IANAL, so I'm just explaining my understanding of the situation.) ditto. best, john
Re: Last Call: draft-ietf-weirds-rdap-sec-04.txt (Security Services for the Registration Data Access Protocol) to Proposed Standard
Hi SM, thanks for your comments. I'm shepherding the document, so replies inline: On Wed, Jul 24, 2013 at 12:21 PM, SM s...@resistor.net wrote: According to Section 1, the Registration Data Access Protocol is a Lookup Format, JSON Responses and HTTP usage. This looks like a weird protocol to me. If the said protocol is HTTP + JSON (responses) it would be clearer to the reader to explain that in one specification. Section 1 mentions that: One goal of RDAP is to provide security services that do not exist in the WHOIS I don't see how adding a fourth document helps to achieve that goal. RDAP is far from the first protocol specification to exist across multiple RFCs, so this approach isn't uncommon. That said, I take it you believe the material here should be rolled into one of the other documents? In Section 3.1: 'To that end, RDAP clients and servers MUST implement the authentication framework specified in HTTP Authentication: Basic and Digest Access Authentication [RFC2617].' This draft refers to the above authentication framework as the RDAP authentication framework. The draft then explains how the basic and digest schemes work. This is how-to stuff. The draft sets the following requirement: 'If the basic scheme is used, HTTP Over TLS [RFC2818] MUST be used to protect the client's credentials from disclosure while in transit (see Section 3.4).' If I understood correctly HTTPS is needed for security only if the basic scheme is used. Correct, that's what it says. RDAP SHOULD be capable of supporting future authentication methods defined for use with HTTP. That sounds like a SHOULD CONSIDER. Given how ill-defined the protocol is I doubt that the above is actionable. You said two important things here: 1) Can you please elaborate on why you think this is ill-defined and, if possible, how this could be remedied? 2) Insofar as this draft amounts to a requirements document, I take SHOULD be capable to mean the actual implementation needs to have hooks for the stated capability, or have a very good reason for not providing those hooks (e.g., the same capability is available some other way). In Section 3.1.1: RDAP MAY include a federated authentication mechanism that permits a client to access multiple RDAP servers in the same federation with one credential. Using an upper-case may does not bring much in terms of security. The draft takes the stance that security is an optional feature. More precisely, the draft takes the stance that federated authentication is an option. The working group doesn't feel the need to elevate this to SHOULD or MUST, likely because operators might not be compelled to federate themselves with anyone for whatever local security or privacy reasons apply. Section 3.1.1 looks like an executive summary for federated authentication. Right, and the benefits it provides in the context of RDAP. Is that a criticism or an observation? What do you suggest? In Section 3.3: An RDAP service has to be available to be useful. There are no RDAP- unique requirements to provide availability, but as a general security consideration a service operator needs to be aware of the issues associated with denial of service. The text says that the service must be available to be useful and that there isn't any requirement for the service to be available. The next sentence (which you omitted) provides the context. Operators are advised to be aware of denial-of-service considerations, and there's a document referenced that provides useful information. Depending on the uptake of RDAP and the other services that begin to depend upon it, it might become a DoS target. Hardening against such attacks will be important to begin with, but might become critical later. I think this is not a waste of space. In Section 3.4: Web services such as RDAP commonly use HTTP Over TLS [RFC2818] to provide that protection by encrypting all traffic sent on the connection between client and server. The above describes the protocol as a web service. It is a web service, in as much as it uses web protocols. Is there some improvement you'd like to suggest? When this scheme is used, HTTP Over TLS MUST be used to protect the client's credentials from disclosure while in transit.' The above repeats a MUST mentioned in a previous section. True, this can be fixed by replacing it with a reference to Section 3.1. In Section 5: RDAP might need to be extended to provide this service in the future. This does not look like a security consideration. Non-repudiation (which is the context of the paragraph from which that sentence was taken) is one of the classic properties of security, so I don't agree. It's useful to point out to the reader that non-repudiation is not provided by any of the capabilities discussed here, and its absence might be conspicuous. Code
Re: procedural question with remote participation
Hi. I seem to have missed a lot of traffic since getting a few responses yesterday. I think the reasons why slides should be available well in advance of the meeting have been covered well by others. And, as others have suggested, I'm willing to see updates to those slides if things change in the hours leading up to the meeting, but strongly prefer that those updates come as new alides with update-type numbers or other identification rather than new decks. In other words, if a deck is posted in advance with four slides numbered 1, 2, 3, and 4, and additional information is needed for 3, I'd prefer to see the updated deck consist of slides 1, 2, 3, 3a, 3b, 4 or 1, 2, 3a, 3b, 3c, 4, rather than 1, 2, 3, 4, 5, 6. I also prefer consolidated decks but, if WG chairs find that too difficult, I'm happy to do my own consolidating if everyting is available enough in advance for me to do sol Almost independent of the above, the idea that one should just watch the slides on Meetecho implies that Meetecho is available in every session (it isn't) and that everything works. In addition, they either need the slides in advance or need to be able to broadcast real-time video at a resolution that makes the slides readable. The latter was not the case last week in some of the sessions in which Meetecho was transmitting the slides sometimes due in part to interesting speaker-training issues. The reasons to discourage anonymity aren't just patent nonsense (although that should be sufficient and I rather like the pun). Despite all we say and believe about individual participation, the IETF has a legitimate need to understand the difference between comments on a specification from an audience with diverse perspectives and organized campaigns or a loud minority with a shared perspective. That requires understanding whether speakers are largely independent of each other (versus what have sometimes been referred to as sock puppets for one individual) or whether they are part of an organization mounting a systematic campaign to get a particular position adopted (or not adopted). The latter can also raise some rather nasty antitrust / anti-competitiveness issues. Clear identification of speakers, whether in the room or remote, can be a big help in those regards, even though it can't prevent all problems. And the IETF having a policy that requires clear identification at least establishes that we, organizationally and procedurally, are opposed to nefarious, deceptive, and posslbly illegal behavior. A rule about having slides well in advance helps in another way: slides that are bad news for some reasons but posted several days in advance of the meeting provide opportunities for comments and adjustments (from WG Chairs and others). Ones that are posted five minutes before (or 10 minutes after) a session lose that potential advantage. Again, I don't think we should get rigid about it: if slides are posted in advance and then supplemented or revised after feedback is received, everyone benefits. I want to stress that, while I think registration of remote people who intend to participate is desirable for many reasons, I think trying to condition microphone use (either remote on in-room) with proof of registration and mapping of names would be looking for a lot of trouble with probably no significant benefits. best, john
Re: procedural question with remote participation
At 12:38 PM 8/5/2013, John C Klensin wrote: Hi. I seem to have missed a lot of traffic since getting a few responses yesterday. I think the reasons why slides should be available well in advance of the meeting have been covered well by others. And, as others have suggested, I'm willing to see updates to those slides if things change in the hours leading up to the meeting, but strongly prefer that those updates come as new alides with update-type numbers or other identification rather than new decks. In other words, if a deck is posted in advance with four slides numbered 1, 2, 3, and 4, and additional information is needed for 3, I'd prefer to see the updated deck consist of slides 1, 2, 3, 3a, 3b, 4 or 1, 2, 3a, 3b, 3c, 4, rather than 1, 2, 3, 4, 5, 6. How exactly do you do this in pptx? Numbering slides is a linear operation AFAICT, and it's binary (it's either on or off). Please educate me if I'm wrong; lord knows I don't know don't know how to do everything flag/setting in powerpoint... And, in my 8 years as TSVWG chair, I've rarely had completely new individual slides sprinkled throughout an existing deck. Rather, I've received updated slides - each with part of their content altered. Does this fall into your desire for a 3a, or is that just 3 (because 3a means an entirely new slide from scratch)? BTW - I'm very much *not* in favor of stipulating to my WG that slides must be turned in 7 days in advance of a TSVWG meeting. I personally think no more than a 48 hour advanced window should ever be considered. James I also prefer consolidated decks but, if WG chairs find that too difficult, I'm happy to do my own consolidating if everyting is available enough in advance for me to do sol Almost independent of the above, the idea that one should just watch the slides on Meetecho implies that Meetecho is available in every session (it isn't) and that everything works. In addition, they either need the slides in advance or need to be able to broadcast real-time video at a resolution that makes the slides readable. The latter was not the case last week in some of the sessions in which Meetecho was transmitting the slides sometimes due in part to interesting speaker-training issues. The reasons to discourage anonymity aren't just patent nonsense (although that should be sufficient and I rather like the pun). Despite all we say and believe about individual participation, the IETF has a legitimate need to understand the difference between comments on a specification from an audience with diverse perspectives and organized campaigns or a loud minority with a shared perspective. That requires understanding whether speakers are largely independent of each other (versus what have sometimes been referred to as sock puppets for one individual) or whether they are part of an organization mounting a systematic campaign to get a particular position adopted (or not adopted). The latter can also raise some rather nasty antitrust / anti-competitiveness issues. Clear identification of speakers, whether in the room or remote, can be a big help in those regards, even though it can't prevent all problems. And the IETF having a policy that requires clear identification at least establishes that we, organizationally and procedurally, are opposed to nefarious, deceptive, and posslbly illegal behavior. A rule about having slides well in advance helps in another way: slides that are bad news for some reasons but posted several days in advance of the meeting provide opportunities for comments and adjustments (from WG Chairs and others). Ones that are posted five minutes before (or 10 minutes after) a session lose that potential advantage. Again, I don't think we should get rigid about it: if slides are posted in advance and then supplemented or revised after feedback is received, everyone benefits. I want to stress that, while I think registration of remote people who intend to participate is desirable for many reasons, I think trying to condition microphone use (either remote on in-room) with proof of registration and mapping of names would be looking for a lot of trouble with probably no significant benefits. best, john
Re: [Trustees] The Trust Agreement
On 06/08/2013 03:11, Noel Chiappa wrote: From: Brian E Carpenter brian.e.carpen...@gmail.com Thanks for the careful explanations. I'll second that; it does seem that some tweaking may be in order. Clearly the Trust shouldn't have blanket permission to abandon or dispose of assets When the time comes to draft actual wording, I would suggest that there be a requirement for a notification to the IETF-Announce list at least one month (or so?) prior to any actual disposal or abandonment, or completion of any agreement to dispose. (Maybe only for IP, and not real property too, such as old servers, etc?) I can't imagine the Trust would be disposing of stuff very often, so I think this would be a reasonable requirement. Agreed; that's very much in the spirit of how we set up the Trust to be responsive to the community. It doesn't seem like the sort of detail to be embedded in the Trust Agreement though - more like part of a tiny addendum to BCP 101. (Since I have raised that question, I hereby volunter to draft it if necessary.) Brian
Re: procedural question with remote participation
On 08/05/2013 12:31 PM, Hadriel Kaplan wrote: but at least one anonymous jabber participant (named Guest) did remotely speak multiple times at the mic on one of the RAI working group sessions this past week (at RTCWEB if I recall). I was personally ok with it, but it was awkward. Ah. I wasn't aware of that. Not stylish at all IMO on the part of whoever was Guest. I'd be confident that the chairs and participants will deal with it ok though. We do manage to deal with silliness (e.g. people with bad ideas) all the time, so I don't see why this'd pose an insurmountable problem to a wg. On 08/05/2013 06:38 PM, John C Klensin wrote: The reasons to discourage anonymity aren't just patent nonsense (although that should be sufficient and I rather like the pun). Thanks. The pun was accidental as it happens, but I did leave it in after I spotted it :-) Puns aside, its an important point. Most patents are nonsense (in terms of being really inventive) and we shouldn't base our processes anywhere near primarily on the existence of that nonsense. Despite all we say and believe about individual participation, the IETF has a legitimate need to understand the difference between comments on a specification from an audience with diverse perspectives and organized campaigns or a loud minority with a shared perspective. Good point. We have similar issues with folks who do lots of contract work I guess. But, IMO we should first make sure we can hear the good points that are to be made, and only then modulate our reactions to those in terms of who-pays-whom or whatever. Put another way, regardless of patents or who's paying, if someone (even anonymously) comes up with a really good technical point, then we do have to pay attention. But I think we do do that. In contrast, I think the real challenge remote participants face is being heard. And when/if we solve that problem, I suspect that remote participants with bad ideas will be a far worse problem than those who'd like to submarine a patent or further a subtle corporate agenda. So again that leads me back to trying to encourage folks to just make the tools better for us all and to only then try figure out how we need to manage that. Perhaps Hadriel's anecdote above means that how we use jabber is, after about a decade, now mature enough that we ought think more about how we formalise its use. I'm ok with waiting another longish time before even thinking about how to do the same with successful inbound audio for example. S.
Re: procedural question with remote participation
--On Tuesday, August 06, 2013 02:06 +0100 Stephen Farrell stephen.farr...@cs.tcd.ie wrote: ... On 08/05/2013 06:38 PM, John C Klensin wrote: The reasons to discourage anonymity aren't just patent nonsense (although that should be sufficient and I rather like the pun). Thanks. The pun was accidental as it happens, but I did leave it in after I spotted it :-) Puns aside, its an important point. Most patents are nonsense (in terms of being really inventive) and we shouldn't base our processes anywhere near primarily on the existence of that nonsense. Agreed, modulo observations about how much time we seem to put into fine-tuning IPR policies and devising threats to make to those who don't seem inclined to comply. Despite all we say and believe about individual participation, the IETF has a legitimate need to understand the difference between comments on a specification from an audience with diverse perspectives and organized campaigns or a loud minority with a shared perspective. Good point. We have similar issues with folks who do lots of contract work I guess. But, IMO we should first make sure we can hear the good points that are to be made, and only then modulate our reactions to those in terms of who-pays-whom or whatever. Indeed. Put another way, regardless of patents or who's paying, if someone (even anonymously) comes up with a really good technical point, then we do have to pay attention. But I think we do do that. When, as you indirectly point out, we can hear them. In contrast, I think the real challenge remote participants face is being heard. And when/if we solve that problem, I suspect that remote participants with bad ideas will be a far worse problem than those who'd like to submarine a patent or further a subtle corporate agenda. Of course, that is also true of participants who show up and more f2f meetings. So again that leads me back to trying to encourage folks to just make the tools better for us all and to only then try figure out how we need to manage that. Perhaps Hadriel's anecdote above means that how we use jabber is, after about a decade, now mature enough that we ought think more about how we formalise its use. I'm ok with waiting another longish time before even thinking about how to do the same with successful inbound audio for example. I'm actually not a big fan of inbound audio, at least not yet. It is subject to the same technical and operational issues that make outbound audio fragile, including the difficulties of clear and standard pronunciation plus the same how to raise your hand, get in line, or otherwise ask for the floor issues that Jabber does. But, if we are going to rely on Jabber for input, we need to move toward treating it as a source of input with the same priority as those in the room (and relatively more real time), not something that is a nice-to-have when it happens to work. best, john
Re: procedural question with remote participation
On Aug 4, 2013, at 2:20 PM, John C Klensin john-i...@jck.com wrote: I also note that the 1 week cutoff that Michael suggests would, in most cases, eliminate had no choice without impeding WG progress as an excuse. A week in advance of the meeting, there should be time, if necessary to find someone else to organize the presentation or discussion (and to prepare and post late slides that are still posted before the meeting if needed). If it is necessary to go ahead without the slides, it is time to get a warning to that effect and maybe an outline of the issues to be discussed into the agenda.If the WG's position is that slides 12 or 24 hours before the WG's session are acceptable, then the odds are high that one glitch or another will trigger a well, there are no slides posted but they are available in the room and the discussion is important decision. John - I've participated in many IETFs in person but have been remote for the last two meetings. I agree that the slides are essential in many cases for following the discussion, and furthermore agree that it is a complete pain to have to hunt for the slides when they haven't been posted and are instead just in the room, or on the list, or at some URL being passed around, etc. Noting all that agreement, I don't support a one week slide cutoff; the downside of not having a presentation slot as a result would be a disproportionate impact to working group productivity... delaying presentation of an important topic for 4 months just because the slides showed up late (but still days before the actual session) would be creating a purely administrative and artificial impediment to getting things done. Now, something in ietf tools that emailed the WG Chairs (and AD?) noting that slides aren't up for presentations occurring _tomorrow_ and/or kept track of presenters with chronic problems missing the deadline getting their slide decks in the night before might be very useful, and help quite a bit with improving remote participants ability to follow along. My .02, /John
Last Call: draft-ietf-storm-ipsec-ips-update-03.txt (Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3) to Proposed Standard
The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3' draft-ietf-storm-ipsec-ips-update-03.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-08-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 3723 specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP. This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published. [RFC Editor: The Updates: list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'Problem Statement: Overlays for Network Virtualization' to Informational RFC (draft-ietf-nvo3-overlay-problem-statement-04.txt)
The IESG has approved the following document: - 'Problem Statement: Overlays for Network Virtualization' (draft-ietf-nvo3-overlay-problem-statement-04.txt) as Informational RFC This document is the product of the Network Virtualization Overlays Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-nvo3-overlay-problem-statement/ Technical Summary This document describes issues associated with providing multi- tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. Working Group Summary The document is the result of the combination of text from an original problem statement draft, that was used as a basis for the formation of the NVO3 working group, and the input of others in who felt that the original draft did not consider L3VPN solutions and issues sufficiently. A design team with a new editor was formed to resolve these comments and co-edit the combined draft. This combined draft was adopted by the working group and then followed the normal process through working group last call. Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed on the list since formation of the NVO3 working group. Personnel Matthew Bocci is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note The Editors of the draft feel that listing 4 authors - in addition to the Editors - is necessary for proper accreditation and recognition of the hard work, constant review and participation in discussions and decision made with respect to the draft. We hope that you are able to assist us in this matter.
JOSE WG Virtual Interim Meeting Monday, August 19, 2013
The JOSE wg will hold a one hour virtual interim meeting on: Monday, 19 August 2013 at 2300 UTC (1900 EDT, 1600 PDT) A detailed agenda and webex instructions will follow on the jose mailing list. http://www.ietf.org/mail-archive/web/jose/current/maillist.html
JSON WG Virtual Interim Meeting Wednesday August 21, 2013
The JSON Working Group will hold a virtual interim meeting on Wednesday August 21, 2013, at 1500 UTC. It will last for up to three hours. The agenda will be published soon, but it will basically be how to incorporate the topics that are now active on the list into the main document. (FWIW, 1500 UTC is the same as: 0800 San Francisco 1100 New York 1700 Paris 2400 Tokyo)
