Re: Last Call: draft-korhonen-mip6-service (Service Selection for Mobile IPv6) to Informational RFC
I noticed while reviewing this for the Gen-ART team that this proposal specifically allows for the creation of walled gardens in mobile service provision. That's something an IAB workshop warned about some years ago (RFC 3002 section 4.2). The draft makes it clear that the default service should be generic Internet access, although it adds that "There is no absolute requirement that this default service be allowed to all subscribers, but it is highly RECOMMENDED in order to avoid having normal subscribers employ operator-specific configuration values in order to get basic service." Is there a deeper issue than just the technical merit of this draft? (Gen-ART thread, also covering some detailed comments, started at http://www1.ietf.org/mail-archive/web/gen-art/current/msg02389.html) Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
On 2007-11-06 11:35, Frank Ellermann wrote: The IESG wrote: as a BCP +1, maybe s/to use of the/to use the limited/ I also think this is an appropriate, even if significant, change of policy. I really don't see why we would give away a precious resource such as a protocol number for secret usage. Red herring as far as this draft is concerned: I'd be interested to know why we are still willing to allow non-disclosure for port numbers (see RFC 2780 sections 8 and 9.1). Port numbers are going fast. From -00 to Last Call in less than three hours, is that a "speedy publish" procedure I haven't heard of before ? I-D submission tool plus the sponsoring AD's special buttons in the I-D tracker. Seems like eating our own dogfood to me. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-rfc2780-proto-update (IANA Allocation Guidelines for the Protocol Field) to BCP
The IESG wrote: > as a BCP +1, maybe s/to use of the/to use the limited/ >From -00 to Last Call in less than three hours, is that a "speedy publish" procedure I haven't heard of before ? Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Offer of time on the IPR WG agenda for rechartering
On 2007-11-06 08:22, Spencer Dawkins wrote: FWIW, My understanding of the community consensus in 2003 is what Keith said... Spencer though I'd probably phrase this differently, e.g.: the IETF has decided, as a group, that a blanket patent policy is counterproductive to IETF's goals. Mine too. If I was going to be in Vancouver, I'd ask for a few minutes to talk about draft-carpenter-ipr-patent-frswds-01.txt. That draft doesn't exist yet, but will do, with the new requirement in the -00 version changed to a mere preference. My objective would be to test the level of interest in that approach. However, since it is not a change to RFC 3978, but to the interpretation of RFC 2026 itself, I would argue *against* rechartering the IPR WG for this tweak. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Offer of time on the IPR WG agenda for rechartering
FWIW, My understanding of the community consensus in 2003 is what Keith said... Spencer though I'd probably phrase this differently, e.g.: the IETF has decided, as a group, that a blanket patent policy is counterproductive to IETF's goals. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Offer of time on the IPR WG agenda for rechartering
> I'm no longer an AD; if I were, my attitude would be simple: the IETF > has decided, as a group, that patented technology is acceptable. > There's no point to reopening the question every individual document. > +1 though I'd probably phrase this differently, e.g.: the IETF has decided, as a group, that a blanket patent policy is counterproductive to IETF's goals. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Offer of time on the IPR WG agenda for rechartering
On Mon, 5 Nov 2007 08:44:33 -0800 "Lawrence Rosen" <[EMAIL PROTECTED]> wrote: > Harald Alvestrand wrote: > > The outcomes I see possible of such a discussion are: > > > I can't be in Vancouver for this meeting. Probably few of the others > who have been vocal on these issues on these email lists can be in > Vancouver either. > > I hope no decisions will be arrived at in what will probably be an > unrepresentative arena. In-person meetings are an ineffective and > expensive way to decide things in the Internet age. In any event, > these email lists have elicited more comments than any meeting in > Vancouver could properly address. How do we intend to move toward > consensus? Per 2418, of course the mailing list decision is the one that counts. OTOH -- and as is well-understood -- it's often much harder to assess consensus over the net than in person. (It's also harder to reach consensus, in many cases, since email tends to be a polarizing medium, prone to flames and other forms of intemperate behavior.) If you have any suggestions for how to deal with these problems -- and they are problems -- I think the IETF would be very interested in hearing them. (And because I realize that this statement can be misinterpreted, given the lack of tone of voice and body language on a mailing list, let me stress that I'm being 100% serious, complimentary, etc.) > > The alternative to a re-charter is for this complaint to be brought > up again and again, every time someone has the audacity to recommend > an IETF specification that is encumbered so to prevent FOSS > implementations. Is that preferable? > I'm no longer an AD; if I were, my attitude would be simple: the IETF has decided, as a group, that patented technology is acceptable. There's no point to reopening the question every individual document. Were this a legal matter, I'd cry "stare decisis". I'm not saying you shouldn't keep pushing, but if the IESG were to ignore a consensus to follow the current policy it would be challenged and rightly so. (The substantive issue on the document currently being discussed is not the fact of the patent -- under current policy, that's acceptable -- but rather the timing of the disclosure.) The question to discuss now is whether enough has changed since the last consensus call on this topic, in March-April 2003, that it pays to reopen the rechartering question. I personally don't think so, but I'm willing to be persuaded otherwise. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reminder: Offer of time on the IPR WG agenda for rechartering
Harald Alvestrand wrote: > The outcomes I see possible of such a discussion are: I can't be in Vancouver for this meeting. Probably few of the others who have been vocal on these issues on these email lists can be in Vancouver either. I hope no decisions will be arrived at in what will probably be an unrepresentative arena. In-person meetings are an ineffective and expensive way to decide things in the Internet age. In any event, these email lists have elicited more comments than any meeting in Vancouver could properly address. How do we intend to move toward consensus? FWIW, I support Simon's I-D as far as it goes. It is a fine description about how free software is adversely affected by restricted copyrights and patents when implementing so-called "open standards." But I don't think that I-D will suffice alone, and I still recommend that the IPR-WG be re-chartered to propose formal IETF policies that require open standards for the Internet. We should commit in all IETF working groups to remain aware of the influence of patents and copyrights on our standards, to react in intelligent ways to any patent or copyright encumbrances brought to our attention, and all participants in the specification drafting process should commit formally to produce open standards unencumbered by copyright or patent royalties or licensing conditions that would limit implementation by anyone who wants to do so. The devil is in the details, but Vancouver is not the place to brush those details under the rug. We need to re-charter the IPR-WG to fill in the details on a policy for which we can all vote. The alternative to a re-charter is for this complaint to be brought up again and again, every time someone has the audacity to recommend an IETF specification that is encumbered so to prevent FOSS implementations. Is that preferable? If you like, spend 5-10 minutes amongst yourselves in Vancouver discussing this matter. Let us know what you decide. /Larry Rosen > -Original Message- > From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 04, 2007 9:21 PM > To: ietf@ietf.org; [EMAIL PROTECTED] > Subject: Reminder: Offer of time on the IPR WG agenda for rechartering > > Just a reminder > > I have not yet seen a request for time on the IPR agenda that is backed > with an I-D fulfilling the criteria laid out below. > > Simon's "free software guideline" exists as an I-D, but I have not had a > request to put it on the agenda. > > The deadline for -00 I-Ds is in a week. > > Harald Alvestrand > > Forwarded Message > Date: 25. oktober 2007 14:30 +0200 > From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> > To: ietf@ietf.org, [EMAIL PROTECTED] > Subject: Offer of time on the IPR WG agenda for rechartering > > As it looks now, the IPR WG's meeting in Vancouver will not be extremely > contentious. > > So, while priority MUST be given to finishing the WG's current work > (copyrights), it seems reasonable to offer a time slot to proposals to > recharter the WG to deal with patent issues. > > I think we can offer at least some time for face-to-face discussion of the > issues - but in order to have a more focused discussion than a general > discussion on whether or not anything needs to be done, > > The outcomes I see possible of such a discussion are: > > - No changes are necessary. The IPR WG can shut down. > > - A change is necessary, and a specific proposal is deemed closest to what > the community wants. We can process a recharter request soon after the > IETF > meeting. > > - A change is necessary, but no consensus on what change exists. More > discussion is necessary. > > - No consensus can be reached on whether or not a change is necessary. > > I'd like the people who want time on the agenda to supply a text > (preferably published as an I-D), which summarizes, as clearly as > possible: > > - What they think has changed since the last IPR WG evaluation of patent > policy > > - What changes in overall direction they think the WG should address > > - What the charter for this activity should look like > > If more than one such proposal should appear, I'd suggest giving each > submitter a 5-10 minute slot for making their argument, and leaving at > least half an hour for general discussion. > > Please submit I-Ds with the name pattern of > draft--ipr-patent- - that would make it easy for us > to find them all. > > The timeslot for the WG is Tuesday morning from 0900 to 1130; the > rechartering discussion would be within the time from 1030 to 1130. > > Harald > > > ___ > Ipr-wg mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/ipr-wg > > > -- End Forwarded Message -- > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf __
FW: Last Call: draft-ietf-psamp-sample-tech (Sampling and Filtering Techniques for IP Packet Selection) to Proposed Standard
Please find below my technical and editorial comments: Technical 1. Section 3.1 - Packet Content. The definition includes in the packet header the link layer header. This deserves at least a note, which should draw the attention on the fact that some if the Observation Point is located at the interface of an IP router the link header information may not be available. 2. Taking into account the observation at the previous point, why do filters defined in section 6.1 for property match operations refer only to the IP header and do not cover also the sub-IP header? 3. The Security Consideration section should be explicit about the need for confidentiality of the sampling configuration information and authentication of the entities that configure this information. Even if the methods of configuration are out of the scope of this document, mentioning the basic security expectations for the configuration information will help for selecting the appropriate tools and protocols for this purpose. 4. This being a document that targets Proposed Standard it looks strange that the other PSAMP and IPFIX documents are only mentioned as Informational references. The document reuses terminology and refers to the architecture described in PSAMP-FW and I would expect that at list this be considered essential for the understanding of this document. Editorial 1. It would be useful for the Abstract and/or title to mention that this document is part of the PSAMP family of documents. This helps people searching in the RFC index in the future to identify easier the document and where it belongs. 2. The document is using a capitalization convention where all terms defined or mentioned in Section 3 are being written capitalized. This includes quite common and often used terms like Sampling. In order to avoid comments about this capitalization style I suggest to explain this convention in the terminology section. It may also be useful to make this capitalization consistent with other PSAMP document, for example Flow is capitalized in draft-psamp-proto, but not here 3. In the table in Section 4 - need to explain what x and (x) mean 4. the list of filters for the Selection Process in Section 6.1, page 18-19 what do (iv) and (v) mean? Are these packets that failed Ingress filtering as per RFC2827 (iv) and packets that were detected as out of spec for (v)? Making this clear would help Dan -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:47 PM To: IETF-Announce Cc: [EMAIL PROTECTED] Subject: Last Call: draft-ietf-psamp-sample-tech (Sampling and Filtering Techniques for IP Packet Selection) to Proposed Standard The IESG has received a request from the Packet Sampling WG (psamp) to consider the following document: - 'Sampling and Filtering Techniques for IP Packet Selection ' as a 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 ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FW: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard
Here are my comments. They are quite a few, it may be because it's a good document. Technical: 1. Section 3.2.1 - Packet Content. The definition includes in the packet header the link layer header. This deserves at least a note, which should draw the attention on the fact that some if the Observation Point is located at the interface of an IP router the link header information may not be available. Moreover, all examples later in the document use only IP header IE, it would be useful to change or add one example to show sub-IP header information. 2. Section 8.2 - PSAMP IANA considerations mention the need of a group of experts to advise on new PSAMP selection methods. This seems a little overkill to me, as I do not expect this advise to be required too often in the future. One designated expert to work with IANA would seem to me sufficient, of curse in doing his work he may consult with a team, but this needs not be mentioned here. Editorial 1. The document is using a capitalization convention where all terms defined or mentioned in Section 3 are being written capitalized. This includes quite common and often used terms like Sample or Flow. In order to avoid comments about this capitalization style I suggest to explain this convention in the terminology section. 2. Many of the figures get fragmented at print. Now I know that it's difficult to avoid this in a document with about 20 figures, and doing .np before each figure would be quite a waste, but I suggest that at least figure C which is a key architecture diagram be kept on one page. Dan -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:46 PM To: IETF-Announce Cc: [EMAIL PROTECTED] Subject: Last Call: draft-ietf-psamp-protocol (Packet Sampling (PSAMP) Protocol Specifications) to Proposed Standard The IESG has received a request from the Packet Sampling WG (psamp) to consider the following document: - 'Packet Sampling (PSAMP) Protocol Specifications ' as a 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 ietf@ietf.org mailing lists by 2007-11-05. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 10963&rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Daily Dose version 2 launched
Thanks to everyone who provided input regarding the front page of the tools.ietf.org servers. I've now made the page at http://tools.ietf.org/tools also be the front page, providing a grouped list of the main tools available at the servers (and in some case also on other servers). I expect to tweak this a bit, letting the front page and the tools summary page diverge a bit, maybe by putting some of the intro material about the server at the top of the front page, before the tool summaries. The new daily dose is now available at http://tools.ietf.org/dailydose (with a redirect from http://tools.ietf.org/news) and there's also a new link in the lefthand menubar for the news page. I've done some other changes to the sidebar, in response to other comments made in this thread; in particular, the sidebar now has direct links to some of the most used tools. If you have comments on the choice of 'most used tools' (currently idnits, draft diffs, xml2rfc and the spell checker) I'd be happy to hear them. I hope this addresses most of the concerns raised. Best, Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
