Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) I would be concerned if outside groups spent time arguing "foo" is bad, or if they advocated other positions to the same issue. But I tend to feel quite uncomfortable with litmus tests based on inactivity of other groups/people. My personal view is that advocates of that line of reasoning place a bigger burden on themselves in providing specific in-depth arguments. Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. i appreciate work that is trivial because its generally simple, easy to accomplish, and leads to fewer interoperability issues. as for ISPs, its fascinating the disparity of how quiet and talkative they are depending on what side of the NDA you are on :-) cheers, -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. could you expand on this observation? -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-carlberg-trip-attribute-rp (TRIP Attribute for Resource Priority) to Proposed Standard
Ted, Howdy, A couple of things about this specification confuse me, and I'd appreciate enlightenment from the authors. The first is that the document spends a fair amount of time setting up the context in which GETS or other services might use resource priority and how this mechanism relates to the SIP resource-priority header. In Section 4.2.3, though, the documents says: An LS MAY add the ResourcePriority attribute when propagating routing objects to an LS in another domain. The inclusion of the ResourcePriority attribute is a matter of local administrative policy. Should the reader assume that this local administrative policy will follow one of the policy approaches discussed in Section 2? If so, should this be stated explicitly? If not, is the text in Section 2 appropriate? Section 2 just provides context and a pointer for additional reading to the casual reader. I wouldn't characterize the systems discussed in Section 2 as "policy approaches", and the word "policy" is also not mentioned in that section. However, the section does point the reader to rfc-3689, which in turn discusses the term of "local policy", thus complimenting its usage further on in this draft. The second is that relatively sparseness of the Security Considerations, which at the moment read: The document defines a new attribute for the TRIP protocol and has no direct security considerations applied to it. However, the security considerations for TRIP and its messages remain the same and are articulated in Section 14 of [rfc3219]. Are there no security considerations for the removal of this header by LSes which fail to honor the requirement that an LS "MUST propagate the ResourcePriority attribute"? I would say no. Taking the text in its entirety If received from a peer LS in another domain, an LS MUST propagate the ResourcePriority attribute to other LSs within its domain. the document conveys the need for consistent information propagated *within* a domain. A broken implementation that fails to propagate the information simply reduces the filter/criteria used to select a gateway. Are there any specific considerations (security or reliability) that apply when the Partial flag has been set by Location Server that does not recognize the attribute? Nothing beyond what is stated in rfc-3219. Keep in mind while this draft defines a new attribute, it shares the same following characteristics of the Communities attribute defined in rfc-3219: Conditional Mandatory: False. Required Flags: Not Well-Known, Independent Transitive. Potential Flags: None. If one determines that an additional consideration (security or reliability) does apply when the Partial flag is set, we'll need to update rfc-3219 as well. cheers, -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
I'll echo Fred's comments, and just add this... I'd have to say that there wasn't really a clear consensus in either direction about much of anything. your original note asked about consensus of closing the group -- that's the focus of the discussion point you brought to our attention on this list. if you're now arbitrarily changing the basis of the discussion point, then its really impossible to point out a weakness in your conclusion or decision. that's frustrating and winds up being pointless for anyone else to engage in a debate -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
I'm speaking here as an individual. I'd like to build consensus for my position both within the IESG and within the community, but I realize that if I fail to build that consensus, I cannot make this objection as a single IESG member. ken> Its now been about 2 weeks since the last comment was sent on ken> this thread. Do you feel you have reached consensus? I sent my IESG comments two weeks ago, and Jon should be following up with the WG chairs. Since I (and most of the IETF list) don't have access to that private correspondence, I don't know if your comments addressed my above question of whether you feel there was consensus reached given your original statement/position. I won't ask you to repeat your private comments, but I would appreciate your feedback on my question given the amount of correspondence on the IETF list concerning this thread. As a side note, I'm a little surprised that your concluding(?) remarks were made in private. When I had sent you a private comment on this thread a couple of weeks ago, you had responded with a desire that I keep my correspondence in public. I guess its just me, but it just feels that your action is a bit inconsistent. regards, -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Sam, Back on Nov 1'st, you started this thread with the following: > I'm speaking here as an individual. I'd like to build consensus > for my position both within the IESG and within the community, > but I realize that if I fail to build that consensus, I cannot > make this objection as a single IESG member. Its now been about 2 weeks since the last comment was sent on this thread. Do you feel you have reached consensus? -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
It's not clear whether going on this way will achieve useful results in a useful amount of time. the first part of the above is a matter of opinion, which I'll respect but disagree with. the second is a red herring. if you wish a more detailed explanation of the timeline of milestones in IEPREP, I'll be happy to take this offline with you and the working group chairs. the timeline reflects poorly on several people (I'll objectively include myself in one instance) and groups and really doesn't need to be brought up here on the ietf list. -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
> Pete Resnick wrote:>>> Questions abound around the mechanisms for sending an email and >> ensuring that it is delivered in a stated time interval on the >> order of minutes or that an indication of failure is returned to >> the sender...>> That, in particular, seems like a relatively easy extension to > RFC 3461 (by adding some sort of additional parameter value to > DELAY). Not exactly rocket science. Not exactly requiring > spinning up a WG.Please keep in mind that this is your (Pete Resnick's) solution to the question/issue that Fred brought up. Your solution may be the best one, it may be part of a larger more encompassing solution, or it may not be applied. But the point is that this part of the discussion (ie, specific solutions), and its merits, should not be here on the IETF list. Instead, we should ask whether issues/questions that motivate the re-charter are valid or at least reasonable to be addressed in IEPREP.and my apologies if I'm taking your last sentence out of context, but the thread involves re-chartering an existing WG, not starting from scratch.Its my view that the proposed re-charter is an evolutionary progression of what currently exists, as opposed to a new group or a new direction that is 180 degrees from what was done in the past. -ken___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
ken> Interestingly enough, the work that you mention below in your ken> original posting... ken> ... rfc-4542, rfc-4411, and draft ken> -ietf-tsvwg-vpn-signal-preemption (along with some other ken> related work) has actually not been done in IEPREP because ken> the group was not allowed to consider solutions. Instead, ken> some of the work has been pushed to TSVWG, to the groans and ken> sometimes confusion of some of the participants of that ken> group, who wondered what the subject of prioritization had to ken> do with TSVWG. Part I think the work you cite belongs in tsvwg. AT least 4542 and vpn-signaling-preemption. I mentioned the above as examples, not as a case-by-case examination of what should or should not be in IEPREP. But along those lines, rfc-4542 (titled "Implementing an Emergency Telecommunications Service"), where ETS was first established in IEPREP and the draft deals with priority and preemption, seems odd to me to be in TSVWG. But if you feel differently, then we agree to disagree. ken> of the revised charter is meant to ken> remove this obstacle. Which work would be permitted under the revised charter that is currently udone elsewhere? I may have more concerns about the revised charter than I thought I did. I am not speaking of any specific work other than what has been discussed in the proposed re-charter. to consider otherwise is to go beyond what I stated. ken> Also, as Scott Brimm has mentioned, there is a proposed ken> liaison from the ITU to work with the IETF, with one of the ken> working groups of interest being IEPREP. It would seem ken> odd to close down the group and punt the subject to them when ken> they are approaching "us" for assistance If IEPREP is ken> closed, does that mean the subject gets pushed over to TSVWG? that rather depends on what question they're asking, now doesn't it? IF they're asking for enhancements to RSVP to deal with some ETS issues, then yes, I'd hope the work would be done in tsvwg. That way, ETS requirements can be balanced against other requirements. If they want to change SIP, I'd hope that it would go through sipping and eventually sip. we will have to wait to see what they request. all I stated was that they were coming to us and that it was odd to close down a group they were interested in working with. Anticipating hypotheticals are not useful because they can put us down a rat hole that may or may not have substance. -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
Sam,One of the objectives of the work produced by IEPREP was to lay down the ground work and put together a baseline set of requirements to start with when considering solutions. Our intention was that the baseline then becomes a starting point where more specific requirements can be put forth. Outside of this, solutions were definitely out of scope.My understanding is that there are others that now wish to present some more specific requirements and potential solutions that do not fall into the scope of other working groups. So the proposed re-charter looks to be a natural extension to what has been done.Interestingly enough, the work that you mention below in your original posting..."I would assume we'd ask people working in this space totake a look at the existing ieprep output, RFC 4542, RFC 4411,draft-ietf-tsvwg-vpn-signal-preemption and other appropriatedocuments."... rfc-4542, rfc-4411, and draft -ietf-tsvwg-vpn-signal-preemption (along with some other related work) has actually not been done in IEPREP because the group was not allowed to consider solutions. Instead, some of the work has been pushed to TSVWG, to the groans and sometimes confusion of some of the participants of that group, who wondered what the subject of prioritization had to do with TSVWG. Part of the revised charter is meant to remove this obstacle.Also, as Scott Brimm has mentioned, there is a proposed liaison from the ITU to work with the IETF, with one of the working groups of interest being IEPREP. It would seem odd to close down the group and punt the subject to them when they are approaching "us" for assistance If IEPREP is closed, does that mean the subject gets pushed over to TSVWG?-ken___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: S stands for Steering [Re: Should the IESG rule or not?]
> From: Brian E Carpenter > > I'm supposed to be on vacation so this will be brief, but I don't > think that your assertion about what "the community" has said is > backed up by postings from a sufficient number of people to be a > community view. Most people in the community haven't posted one way > or the other. I haven't counted, but in the recent discussions about > the hop by hop option, I've seen a number of messages agreeing with > the IESG's decision, contrasted with a large number of critical > postings from just a few people. My view is that your impression of the reaction is incorrect. in taking the position that respondents can be classified as either: a) being satisfied with the IESG *decision*, b) dissatisfied or uncomfortable with the decision, or c) could not be clearly determined by the content of their response, I came up with the following list. Dissatisfied Satisfied Other - - Robert Elz Thomas Narten Barbara Roseman John Leslie Sam HartmanYakov Rekhter Ken Carlberg Bob Hinden Scott Brim Ralph Droms Brian CarpenterSpencer Dawkins Steve Silverman Allison Mankin Thomas Hruska Jefsey MorfinHarald Alvestrand Randy Presuhn John Klensin Keith MooreScott Bradner Nick Staff Bill Sommerfeld Lawrence Roberts Eliot Lear Vint CerfJoel Halpern Dave Crocker Margaret Wasserman Ned FreedJeffrey Hutzelman Grenville Armitage Hans Kruse I listed names so that people could object to my interpretation, and I'm sure I made a mistake or two. But at best, it seems the reaction is split, and not to be viewed as objections coming from simply a few but persistant people. -ken ps, I hope your vacation is going well :) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
> | The proposal includes significant changes to the > | Internet architecture including a new TCP congestion control > | algorithm, new requirements for IPsec security gateways and new > | behavior for routers. > > Whether any of that is a viable proposal or not is for others to > judge (not even the IESG I'd suggest), but it makes no difference > what the answer is to that question for the actual request that > was made. there is precedence regarding concern over new efforts and their relationship to TCP. I can't cite chapter and verse, but I seem to recall that the work on reliable-multicast and BEEP (two different efforts altogether) were informed by the powers-that-be to be "TCP friendly". the degree by which one views the new algorithm as "unfriendly" is something I'll defer to others more qualified than myself. what I do find troubling is the arguement that new requirements for IPsec security gateways and new behavior for routers is an added reason for rejecting the proposal. in a rebuttal comment, Thomas Narten writes: > RFC 2780 says: > >> 5.5 IPv6 Hop-by-Hop and Destination Option Fields >> >> Values for the IPv6 Hop-by-Hop Options and Destination Options fields >> are allocated using an IESG Approval, IETF Consensus or Standards >> Action processes. > >(where those terms are defined in RFC2434.) > >The clear intention of the above is that assignments for HBH code >points be conditioned on IETF review (and approval). That is, a >document that gets published as an Internet Draft, gets reviewed, and >then pops out as an RFC. intention or even tradition has little weight. The key word used above is IESG Approval "or" standards action (ie, RFC). That being the case and agreed to by the IESG allows Dr. Roberts to go straight to the IESG and ask for the extension. Dr. Roberts may have given the IESG a jolt in being very thorough about what could be done with such an extension, but I side with Robert Elz as to the relevence. The system says that someone can make a request for an extension to IPv6. If there are no additional criteria set forth for the field, and the extension doesn't clash, it would seem that request should be satisfied. Dr. Roberts seems to have played within the rules. -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
mailing list archives
Hello, I was wondering if someone (IAB, IESG, wg chairs, whomever) could strongly encourage the folks that maintain archives to provide them as a series (volumes), as opposed to a single clump/file. Some archivists do provide a more structured breakdown based on month/year. However, others have simply a single large file (I just downloaded one that has its first entry dated June of 1987) Thankfully, my ISP connectivity is large enough not to worry about the time to download, but there are significant numbers of people either behind 56/28.8k modems or behind satcom links where large file transfers can be problematic. I deeply appreciate the time & resources used to archive working group mailing lists, but it would be very helpful if these folks could add some structure to the archive. cheers, -ken
