Re: IETF Plenary Discussions
As a life-long fan of the Gong Show, I think it'd be cool to have a big Gong on the dias, where perhaps after a bunch of loud hums, an AD or IAB member finally satisfies the audience. This could happen sooner or later, depending on whether we're talking about topic (1) NATs, (2) The standards process, or (3) Venue location. But perhaps there's another approach that won't be quite so, well, base. To me, if someone wants more than 2 minutes to make a point, perhaps that person should request a short agenda slot. Here's a little process experiment: why not slot 20 minutes for such time at one of the plenaries, allowing for a 5 minute presentation and 5 minute discussion? NANOG has been doing something like this- the Lightning presos. You could even imagine someone carrying over a topic from this IETF discussion list or the previous meeting. This gives people an opportunity to collect their thoughts, perhaps even post a draft, and then give a quick summary of it. Some would say that the moment may have passed, and that decisions will be taken. But 2 minutes is more than enough time for someone to say -1 or +1, or to make a very brief point as to why someone should be -1 or +1. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
+1 But I also agree with part of Adrian's comments. Our vocabulary for describing these things may be sub-optimal and that may have gotten in our way. Perhaps something more along the lines of approved standard, interoperable standard, and verified standard would serve us better than PS/ DS/ Full. But a different piece of vocabulary might be equally important: perhaps we should be talking about recognizing something at a standard at a particular level and not advancing it. I also believe that part of the problem involves what amounts to a positive feedback loop: because few documents are advanced past PS, the IESG feels obligated to impose requirements on approval at PS that go far beyond what is required by 2026. Once documents are polished to a high luster, at the cost of considerable time, for PS, there is little incentive to advance them and, worse, even more impressive requirements are imposed in practice at DS and Full, possibly to give them some distinction beyond Proposed. If we could get back to treating Proposed much as the IEEE used to treat Draft Standard for Trial Use -- no known technical defects in the protocol and documentation that was not required to be more than adequate to explain the idea -- then we might be able to get things into Proposed more quickly and have incentive for document revision and advancement (sic) for those ideas that actually turned out to get traction in practice. Of course, since Brian found one dead horse to kick, I'm semi-obligated to mention another. The ISD idea was to draw things together in a different way, permitting binding several documents together in ways that would deal with the problems Spencer mentions, replacing the rigid PS/ DS/ Full categories with explanatory prose, and binding errata and clarifications more closely to the documents themselves than the RFC Editor version of the errata permits. But neither that idea nor the earlier one Brian mentioned is worth resurrecting and reexamining unless the IESG wants to play and, so far, I've seen little evidence that they do. john --On Wednesday, November 11, 2009 22:40 -0500 Tony Hansen t...@att.com wrote: Yup, and most of those proposed standards and draft standards should have been declared full standards *long* ago. What we *don't* do well is revising the levels of standards that got published, became fully interoperable and deployed without needing a rev of the document. Why is their status still marked 'proposed' or 'draft'? RFC 2026 does NOT require a rev to the document to move forward if there are no errata. For those specs that everyone has implemented and deployed, but there are a number of errata that everyone agrees are required for the spec to be useful, here's an idea for a revision lite (the diet version of a revision): recycle the spec almost totally *as-is*, with a section added called Verified Errata. Copy in such errata, attach the interoperability and deployment reports, and publish. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Logging the source port?
Phillip Hallam-Baker writes: If people are required to track the source port, it is hardly unrealistic to expect them to abandon a file format that does not meet their legal obligations. A misunderstanding, perhaps. Where I live, what's being talked about is laws that govern residents of this jurisdiction (connecting to servers here, or abroad, or often in the neverland of botnets). You seem to be thinking about laws that govern the relationship between servers located here and users everywhere. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt
John C Klensin wrote: ... Standard etag conflict resolution is not required because it is not desirable for many applications of PATCH. For other applications of PATCH, it is already defined by HTTP and does not need to be reiterated here. We disagree. I believe it does need to be reiterated here, either in-line or by an explicit, normative, pointer to the relevant portion of the HTTP spec. ... http://tools.ietf.org/html/draft-dusseault-http-patch-15#section-2 already says: Collisions from multiple PATCH requests are more dangerous than PUT collisions, because a patch document that is not operating from a known base point may corrupt the resource. Clients wishing to apply a patch document to a known entity can first acquire the strong ETag [RFC2616] of the resource to be modified, and use that Etag in the If-Match header on the PATCH request to verify that the resource is still unchanged. If a strong ETag is not available for a given resource, the client can use If-Unmodified-Since as a less-reliable safeguard. So would replacing the 2nd part by: Clients wishing to apply a patch to a known entity can first acquire an ETag ([RFC2616], Section 3.11) of the entity to be modified, and use that ETag to make the PATCH request conditional, such as by including the If-Match request header field ([RFC2616], Section 14.24). address this concern? Note that this makes some more changes: 1) the client can't control whether the etag will be strong, and weak etags may work just fine in certain instances, so just be silent about the type 2) speak of conditional requests in general, and just mention If-Match as one way to get there; there may be other ways such as using the WebDAV If header 3) Get rid of the text that suggests that a last modified date somehow is better than a weak etag. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt
--On Tuesday, November 17, 2009 15:27 +0100 Julian Reschke julian.resc...@gmx.de wrote: John C Klensin wrote: ... Standard etag conflict resolution is not required because it is not desirable for many applications of PATCH. For other applications of PATCH, it is already defined by HTTP and does not need to be reiterated here. We disagree. I believe it does need to be reiterated here, either in-line or by an explicit, normative, pointer to the relevant portion of the HTTP spec. ... http://tools.ietf.org/html/draft-dusseault-http-patch-15#sect ion-2 already says: Collisions from multiple PATCH requests are more dangerous than PUT collisions, because a patch document that is not operating from a known base point may corrupt the resource. Clients wishing to apply a patch document to a known entity can first acquire the strong ETag [RFC2616] of the resource to be modified, and use that Etag in the If-Match header on the PATCH request to verify that the resource is still unchanged. If a strong ETag is not available for a given resource, the client can use If-Unmodified-Since as a less-reliable safeguard. So would replacing the 2nd part by: Clients wishing to apply a patch to a known entity can first acquire an ETag ([RFC2616], Section 3.11) of the entity to be modified, and use that ETag to make the PATCH request conditional, such as by including the If-Match request header field ([RFC2616], Section 14.24). address this concern? Largely, yes, as long as the other changes you list below are addressed (comments below). Note that this makes some more changes: 1) the client can't control whether the etag will be strong, and weak etags may work just fine in certain instances, so just be silent about the type Silent, no. But saying can't control... certain instances explicitly would be fine. I'd be even happier with an explanation of what such an instance might look like, but don't see that as a requirement. 2) speak of conditional requests in general, and just mention If-Match as one way to get there; there may be other ways such as using the WebDAV If header yes 3) Get rid of the text that suggests that a last modified date somehow is better than a weak etag. Probably a good idea. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt
John C Klensin wrote: ... 1) the client can't control whether the etag will be strong, and weak etags may work just fine in certain instances, so just be silent about the type Silent, no. But saying can't control... certain instances explicitly would be fine. I'd be even happier with an explanation of what such an instance might look like, but don't see that as a requirement. ... It's up to the server to decide whether it provides strong or weak etags. And it's also up to the server to decide whether you can use them in a conditional PATCH request (RFC 2616 disallowed this, but HTTPbis is lifting that restriction, and furthermore WebDAV never had it). I think not stating this explicitly is the simplest approach (as this is true for any HTTP method), but I wouldn't object to have more text either (as long as that text wouldn't have to revised when HTTPbis is done). BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-lha-gssapi-delegate-policy
I reviewed the document draft-lha-gssapi-delegate-policy-04 in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Standards Track Delegating user credentials to an insufficiently trusted party is problematic. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to indicate that a particular service is trusted for delegation. This specificatinon adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). 1. Is the document readable? Yes. 2. Does it contain nits? Yes. Some grammatical nits: Section 2 to allow and administrator - to allow an administrator It would is desirable - It would be desirable Idnits complains of a potential boilerplate error: idnits 2.11.15 tmp/draft-lha-gssapi-delegate-policy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ** The document seems to lack an IETF Trust Provisions (12 Sep 2009) Section 6.b License Notice -- however, there's a paragraph with a matching beginning. Boilerplate error? trust-12-sep-2009 Section 6.b paragraph 3 text: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. ... text found in draft: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. ^ Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: No issues found here. Miscellaneous warnings: == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). trust-12-sep-2009 Section 6.c.iii text: This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Checking references for intended status: Proposed Standard (See RFCs 3967 and 4897 for information about using normative references to
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. Brian On 2009-11-18 05:03, Julian Reschke wrote: John C Klensin wrote: ... 1) the client can't control whether the etag will be strong, and weak etags may work just fine in certain instances, so just be silent about the type Silent, no. But saying can't control... certain instances explicitly would be fine. I'd be even happier with an explanation of what such an instance might look like, but don't see that as a requirement. ... It's up to the server to decide whether it provides strong or weak etags. And it's also up to the server to decide whether you can use them in a conditional PATCH request (RFC 2616 disallowed this, but HTTPbis is lifting that restriction, and furthermore WebDAV never had it). I think not stating this explicitly is the simplest approach (as this is true for any HTTP method), but I wouldn't object to have more text either (as long as that text wouldn't have to revised when HTTPbis is done). BR, Julian ___ Gen-art mailing list gen-...@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
In fact, lightning talks are SOP at most operator group meetings. I think that would be an excellent experiment. Brian On 2009-11-17 22:39, Eliot Lear wrote: As a life-long fan of the Gong Show, I think it'd be cool to have a big Gong on the dias, where perhaps after a bunch of loud hums, an AD or IAB member finally satisfies the audience. This could happen sooner or later, depending on whether we're talking about topic (1) NATs, (2) The standards process, or (3) Venue location. But perhaps there's another approach that won't be quite so, well, base. To me, if someone wants more than 2 minutes to make a point, perhaps that person should request a short agenda slot. Here's a little process experiment: why not slot 20 minutes for such time at one of the plenaries, allowing for a 5 minute presentation and 5 minute discussion? NANOG has been doing something like this- the Lightning presos. You could even imagine someone carrying over a topic from this IETF discussion list or the previous meeting. This gives people an opportunity to collect their thoughts, perhaps even post a draft, and then give a quick summary of it. Some would say that the moment may have passed, and that decisions will be taken. But 2 minutes is more than enough time for someone to say -1 or +1, or to make a very brief point as to why someone should be -1 or +1. Eliot ___ 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: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
(This note seems to offer a useful point of departure, in this thread, so I thought I'd resurrect it, for replying. /d) Jari Arkko wrote: Dave, The first assumption is that there is a real problem to solve here. I think there is a real problem, and that is the need to modernize the headers and boilerplates so that they are more reasonable for each stream. This includes things like getting rid of derogatory IESG notes, which none of us likes. I, too, think that there is a very useful bit of modification to the RFC title page that would resolve concerns about reader confusion. The current draft for headers and boilerplates defines a Source header, to indicate which stream the document came out of. http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08 document source This describes the area where the work originates. Historically, all RFCs were labeled Network Working Group. Network Working Group refers to the original version of today's IETF when people from the original set of ARPANET sites and whomever else was interested -- the meetings were open -- got together to discuss, design and document proposed protocols [RFC0003]. Here, we obsolete the term Network Working Group in order to indicate the originating stream. It currently requires that the reader already know what the possible choice are. Since most readers won't know, it's not clear to me how much utility this will have. So instead of a field that simply lists only the actual source, I suggest a header that defines its full context, by listing all choices and bracketing the one that applies. Hence: Source: [[ IETF ]] IRTF IAB Independent versus, for example: Source: IETF IRTF IAB [[ Independent ]] If a reader misses the meaning of this header, why would anyone think that they will better understand any other text that is inserted? Of course, headers and boilerplates changes need to be accompanied by the corresponding change in 3932. THAT is the reason for the 3932bis draft. Giving the IAB authority to override the RFC Editor's decision is more than clarity of labeling. The trouble is, of course the final 3932bis needs to take the opinions of the community into account (and be acceptable to the Excellent idea. To justify making a change in the independence of the RFC Editor, where is the IETF consensus? Absent that community consensus, of course, the status quo is maintained. Hmmm. Here's an uncomfortable legal question for us to consider: Why is IETF consensus sufficient? Since the RFC Editor has always been independent of the IETF, per se, what gives the IETF the authority to declare changes to the RFC Editor's operation? approving bodies). This is why we have discussed all the changes. I do not see a lot of other options than the compromise position if completing 3932bis and the rest of the system of changes is the goal. In a private exchange that Russ was conducting over the last few weeks, I suggested a mediation model, with the IAB reviewing the RFC Editor's decision, but only authorized to make a recommendation, rather than mandating the change. He reported that others he was talking with insisted on the current arbitration model that mandates change. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
--On Wednesday, November 18, 2009 06:09 +0900 Dave CROCKER d...@dcrocker.net wrote: ... approving bodies). This is why we have discussed all the changes. I do not see a lot of other options than the compromise position if completing 3932bis and the rest of the system of changes is the goal. In a private exchange that Russ was conducting over the last few weeks, I suggested a mediation model, with the IAB reviewing the RFC Editor's decision, but only authorized to make a recommendation, rather than mandating the change. He reported that others he was talking with insisted on the current arbitration model that mandates change. Dave, While I agree with you in principle, I suggest that the current text is reasonable, if only because the IAB always has the right to say to the RFC Editor (either ISE or RSE) do what we tell you or you will be fired. I would expect the IAB to exercise that particular authority only after everything else has failed and it is clear to almost everyone that things are out of control, but that is not a question for 3932bis.As the text now reads, the IAB can be asked to conduct a review, but can decline to do so (consistent with RFC 4846 and nothing new). And, if the IAB conducts such a review, it can instruct the RFC Editor has to how to proceed, but can also decide to not do that and simply provide advice (the latter is, again, consistent with 4846). I wish that that IESG (or some few of its members; I don't know) were not insisting on even that much, but there seem to be nothing that can be done about it without the loss of much more time (remember that Independent Submission publications have been blocked for many months by the side-effects of this situation). But, in its present form, it seems relatively harmless in practice and it would be good to get on with this and unlock the Independent Stream publications. Just my opinion, of course. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Question about draft-housley-iesg-rfc3932bis-12 (was: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt)
Dear colleagues, On Tue, Nov 17, 2009 at 04:47:44PM -0500, John C Klensin wrote: I wish that that IESG (or some few of its members; I don't know) were not insisting on even that much, but there seem to be nothing that can be done about it without the loss of much more time (remember that Independent Submission publications have been blocked for many months by the side-effects of this situation). All of the to-ing and fro-ing about this document has finally made me sit up and read it. I have the impression from the archives that at least some people are concerned about the dispute resolution mechanism; there seems to be a suggestion about that it impinges on the traditional freedoms of the RFC Editor. I haven't made up my mind about that, but I am curious why the section is being included anyway. The first two sentences of Section 4 all but say that this is a problem that has never happened. The only motivation the document supplies is that there could be a dispute, and that it'd be nice to have a way of solving the dispute if it were needed. There's no mechanism at all in RFC 3932, as I read it. My experience of this sort of formalism leads me to believe that, when there is no formal mechanism, everyone is forced to act in good faith to hammer out a compromise; whereas once there's a well-established set of rules in place to handle disagreements, there's very little incentive to avoid cranking up that machinery for even very small disputes. (Social pressure doesn't work, because the retort is always that this is what the mechanism is for.) So I'd find it really useful to know what problem this dispute resolution mechanism is actually supposed to solve. I also wonder whether those in favour of the mechanism have worked through the potential workload that would result from high-frequency application of this mechanism, and whether IESG or IAB (or both) members have the time to invest in such an eventuality. Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about draft-housley-iesg-rfc3932bis-12
On 2009-11-18 11:15, Andrew Sullivan wrote: So I'd find it really useful to know what problem this dispute resolution mechanism is actually supposed to solve. Since we're (presumably) trying to write rules that will work when common sense has failed, it seems prudent to have a clear path for disputes of an unknown nature. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
On Tue, Nov 17, 2009 at 12:15 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: In fact, lightning talks are SOP at most operator group meetings. I think that would be an excellent experiment. Brian I agree, and in fact I've suggested lightning talks too; I think it tilts community discussion towards identifying problems and solutions (or educating) rather than asking the leadership for solutions which they're not always able to provide unilaterally. I think where the IESG got hung up on actually planning lightning talks was on identifying a moderator who is familiar with the format enough to run the talks, plus personable and lively enough to keep things moving. Up 'til now I haven't volunteered to run such talks, but I do so now, still hoping somebody better than me can be found. The format I liked from ApacheCon, with a very similar model used at DjangoCon, was to take names from those who wanted to talk for 5 minutes, up to the start of the talks, then pull those names out of a hat until the hour had been used up. The 5 minutes was very strictly enforced with a giant visible countdown, and there was 30sec allowed for the next speaker to come up (therefore no slides). Lisa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt
This version satisfies all my concerns with previous versions. Thanks! Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
John C Klensin wrote: But I also agree with part of Adrian's comments. Our vocabulary for describing these things may be sub-optimal and that may have gotten in our way. Perhaps something more along the lines of approved standard, interoperable standard, and verified standard would serve us better than PS/ DS/ Full. But a different piece of vocabulary might be equally important: perhaps we should be talking about recognizing something at a standard at a particular level and not advancing it. I also believe that part of the problem involves what amounts to a positive feedback loop: because few documents are advanced past PS, the IESG feels obligated to impose requirements on approval at PS that go far beyond what is required by 2026. Once documents are polished to a high luster, at the cost of considerable time, for PS, there is little incentive to advance them and, worse, even more impressive requirements are imposed in practice at DS and Full, possibly to give them some distinction beyond Proposed. If we could get back to treating Proposed much as the IEEE used to treat Draft Standard for Trial Use -- no known technical defects in the protocol and documentation that was not required to be more than adequate to explain the idea -- then we might be able to get things into Proposed more quickly and have incentive for document revision and advancement (sic) for those ideas that actually turned out to get traction in practice. I think John's hit the nail right on the head here. I would like to go a bit further and say that it's long past time to abandon the name RFC altogether. While I understand and respect the historical underpinnings of the term I agree with those who have commented that for most of the world an RFC is an RFC is an RFC and our fine distinctions like Experimental, Informational etc. are lost. My suggestion would be to name the documents what they are, and to come up with new terms for the documents that reflect the evolution of the process. In the standards track area I think names like the ones John proposed are good, I personally would s/interoperable/deployed/ but that's a detail that can be tweaked later, as can names for some of the other categories of things that are all called RFCs now. Anyone else think that clarifying the naming scheme is a good idea? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote: These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. It would also be wrong, because it is neither a requirement for interoperation nor a potential for causing harm (RFC 2119). Aside from which, it makes the original purpose of PATCH non-compliant with its own specification. The purpose of PATCH is to request that the server apply a set of changes to the current state of the target resource. The assumption that these changes will be dependent on a specific prior representation of that resource is false. The server is fully capable of detecting and reporting conflicts when they occur with the current state, as only truly known by the server. In other words ... If the client wants to prevent the PATCH method from being applied to a resource for which the state has changed since the last state known by the client, then it SHOULD use one or more of the conditional request mechanisms of HTTP (If-Match and If-Unmodified-Since request headers [RFC2616]) or WebDAV (If request header [RFC4918]) with the associated metadata from that prior resource state. However, if the patch media type contains its own mechanism for detecting conflicts, such as embedded context or metadata designed to allow non-overlapping changes to be safely applied, then the conditional request mechanisms SHOULD NOT be used with PATCH because they would interfere with collaborative applications, such as shared editors and whiteboards. FTR, the prior sentence, that PATCH is somehow more likely to result in corrupted state than a PUT, is simply false for any patch format that contains context or post-application integrity checks. The only reason it was in the spec is because earlier versions assumed a patch format that contains nothing but byte-vector manipulations. It should be removed, or at least altered to be factual. Roy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Jabber,... at IETF Plenary Discussions (Re: IETF Plenary Discussions)
We have a hard time getting someone to go the minutes. I'd be pleased to do jabber if there was a volunteer for the typing. Russ At 04:47 AM 11/13/2009, Martin J. Dürst wrote: My understanding is that these days, most WG and BOF meetings have somebody watching jabber and bringing up comments from there to the mic. Also, jabber scribing seems to be quite popular, complementing the audio channel (which this time, as reported elsewhere, was excellent). What about jabber support (both scribing and picking up questions/comments) for the plenary? Was this just never considered, or has it been considered and rejected? Regards,Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt
http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08#section-3.2.3 says: Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/static-path/rfcrfc-no.html Can we please recommend *not* to put a file extension into the URL? BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt
At 6:01 AM +0100 11/18/09, Julian Reschke wrote: http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08#section-3.2.3 says: Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/static-path/rfcrfc-no.html Can we please recommend *not* to put a file extension into the URL? +1. http://www.rfc-editor.org/static-path/rfcrfc-no is just fine, and is what we agreed to before. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback' to Proposed Standard
The IESG has approved the following document: - 'RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback ' draft-ietf-avt-rtcpssm-19.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpssm-19.txt Technical Summary This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Working Group Summary There is interest in this work both with AVT and the MBONED community, and solid consensus to publish the draft. Document Quality The draft fills an important gap and is needed to deployed SSM-based IPTV systems. As a result there is strong interest in seeing it done, and implementations are expected. Personnel Colin Perkins is the proto document shepherd. Cullen Jennings is the responsible area director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BEHAVE interim teleconference call
There will be a BEHAVE teleconference interim meeting on December 16, 2009 at 7am (PST), using WebEx. Agenda and dial-in information will be posted at http://tools.ietf.org/wg/behave/trac/wiki ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
