Re: FYI - Examining Actual State of IPv6 Deployment
I think that's a pretty bizarre way to measure IPv6 deployment. The _last_ applications to support IPv6 will be the widely popular apps that depend on an extensive infrastructure of servers that are currently associated with IPv4. Email and the web both fall into this category. And as long as a site (practically speaking) has to support SMTP over IPv4 in order to accept incoming mail, and HTTP over IPv4 in order to make its web pages readable to most viewers, there's little incentive for that site to advertise an record for either server. Dan York wrote: Since there's been so much discussion here of IPv6 here, I thought I'd mention a recent post on CircleID.com called Examining Actual State of IPv6 Deployment: http://www.circleid.com/posts/81166_actual_state_ipv6_deployment/ The article is by Thomas Kuehne and is a quick-and-dirty study he did of how many web sites were configured with records. Obviously it's not a comprehensive study, but just another data point about the readiness for IPv6 - or not. I've included the intro to the data below. Enjoy, Dan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FYI - Examining Actual State of IPv6 Deployment
Since there's been so much discussion here of IPv6 here, I thought I'd mention a recent post on CircleID.com called Examining Actual State of IPv6 Deployment: http://www.circleid.com/posts/81166_actual_state_ipv6_deployment/ The article is by Thomas Kuehne and is a quick-and-dirty study he did of how many web sites were configured with records. Obviously it's not a comprehensive study, but just another data point about the readiness for IPv6 - or not. I've included the intro to the data below. Enjoy, Dan There have been quite a number of recent articles about various IPv6 issues. Thus the question: how far along is the actual IPv6 deployment? This is a quick-and-dirty survey that focuses mainly on the content provider side. What domains were surveyed? Alexa offers country depended TopSites listings. Domains listed are frequently visited by users from that country, not necessarily hosted there. The data collection is heavily biased towards sites that host files referenced from many different places (e.g. advertisement and social networks). The data collection is chiefly based on optional browser plugins and is as such frequently corrupted (e.g. for Germany mail.ru is listed ahead of rtl.de, msn.de and aol.de). How was IPv6 deployment surveyed? For each domain the domain name server was asked for IPv4(A) and IPv6 () records for the domain, www.domain, it’s mail exchanges and it’s name servers. If an IPv6 record was returned deployment was assumed. There was no check if the advised IPv6 actually provided the service. -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Transition of www.ietf.org Update
This is a reminder that the transition of the main IETF web site began on Wednesday, 16 January. Virtually all changes to static web pages are on hold until testing is completed and the actual cut-over takes place on 31 January 2008. This hold does not affect data driven web pages, web sites hosted and managed by third parties, nor *urgent* requirements. You may continue to submit change requests to [EMAIL PROTECTED] and you will receive a tracker ticket when you submit your request. However, NSS will keep the tickets open and hand them over to AMS after the transition is complete on 31 January. If you have an *urgent* need for a web site change you should make that known in your request. They will be handled on a case-by-case basis. Thanks. Ray Pelletier IETF Administrative Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
On Jan 17, 2008, at 12:04 PM, Brian E Carpenter wrote: Just as a reminder, the idea was to have something *easier and cheaper* than RFCs but more organized than arbitrary web pages. Fred might note that cheaper with his IAOC hat on ;-). I do indeed. That said, I'm paying for the RFC Editor's office anyway, so not asking them to work on a specific document doesn't necessarily save me money - what would save money is not having them work on a large subset of documents. From my perspective, what is costly in RFC development is the amount of time it takes and the hoops one jumps through to do and to respond to review. It doesn't cost money per se, but it costs time, and in my wallet time is more valuable. heresy If you really want to argue that IONs are of value in the sense of not having the RFC editor edit and publish them, the question we want to ask is what the quality of an ION's English grammar (perhaps the RFC Editor's biggest value-add) and how does it compare to that of an RFC? If an RFC is not noticeably better, do we need the RFC Editor's office AT ALL? /heresy Personally, that is a consideration I want to make very carefully; the amount of work the RFC Editor puts into an RFC varies quite a bit (something about the grammar skills of its author), and some documents really benefit from the process. If we were to decide we didn't need the RFC Editor any more, I would expect the IAOC to make consultative editorial services available to working groups so that documents headed to the IESG had already been through that process. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Internet Draft Submission cutoff dates
--On Friday, 18 January, 2008 13:18 -0600 Eric Gray [EMAIL PROTECTED] wrote: John, Your description of the reasons for having the draft sub- mission dead-lines may agree with original thinking that went into setting them, initially. However, there were collateral benefits that the new automated submission process helps to improve - but does not eliminate. For the people who participate in a fair number of working groups in the IETF, requiring early posting allows for a greater likelihood that they will be able to at least skim each new draft sometime before setting up their laptop at the beginning of each meeting in which that draft will be discussed. Eric, To be clear, I was not advocating doing away with the cutoff. I think cutoffs are a good idea, for exactly the reasons you suggest and because they avoid any necessity for per-WG rules about deadlines to prevent a particularly nasty way of gaming the system. I just want to be sure that the intervals we have been using are still appropriate. Moreover, having a week longer grace period for subsequent submissions also makes sense from this same perspective - because it is usually the case that there is less new material to absorb in a -01 or subsequent version than there was in a -00 version. Not always, but usually. One exception is when a draft becomes a working group draft - which means it becomes a -00 version with virtually no change from a previous (often a -03 or -04) version. Just for purposes of discussion (I do not have any strong positions on this other than a desire to have it reviewed), I think it makes a lot of sense to require a long lead time on new drafts in order that people have a way to consider new concepts, whether they want to attend particular WGs, etc. Three weeks does not strike me as unreasonable for that purpose. And the draft-transition exception you mention is already part of the rules. However, in many WGs, we see a lot of work done in the weeks before an IETF meeting, both before and after the current posting deadline. I think it is in our interest to have WGs looking at drafts that are as up-to-date as possible, consistent with everyone in the WG having a reasonable opportunity to read them before the actual meeting. So I'm not sure that two weeks is optimal for revision drafts. Perhaps the tradeoffs would work better at a week before, or perhaps at some other interval. I suspect that setting the revised draft cutoff much shorter than a week before the meeting would mean that some people would not be able to review them before beginning to travel to the meetings and that the Secretariat might not have time to manually process whatever needed to be manually processed, but I don't know. I do not think it is either wise or useful to try to design the details of this on the IETF list (nor do I think you were suggesting that either) and hope my note does not set off a long thread. I believe it is reasonable for us to ask the IESG to think about the issue, make a decision and tell us. I'd prefer to hear about their reasoning, but I can live without even that. I just don't think it is reasonable to continue automatically with the current cutoffs when the reason for setting those particular cutoff values has largely disappeared. And I wanted to mention the question on the IETF list precisely because I hope that this is not an appropriate subject for an RFC3933 experiment. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Finding information
As someone new to the IETF, how should I go about doing the following? I want to find some information about IMAP and its extensions. Let's say I found RFC 1730. How would I know that it had been obsoleted by RFC 2060 and then by RFC 3501? How do I find the extensions? I don't necessarily want to search through a list of 5000 entries to find what I want. That's where I think a naming scheme like IETF-IMAP would be handy. Then I could look at a list of IETF-IMAP and see IETF-IMAP-2003 would be newer than IETF-IMAP-1996. But that's beside the point. As of right now, how do I find this information? Is there a handy tool on tools.ietf.org that I should use? Thanks for your help. Willie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-carpenter-rfc2026-changes-02.txt
On 2008-01-18 23:20, Frank Ellermann wrote: Brian E Carpenter wrote: the question is whether people are interested enough to comment... ...and maybe also how interested the author is to answer comments: http://article.gmane.org/gmane.ietf.general/27581/match=2026 [RFC 3700] You still propose to kill STD 1 claiming that everybody is online today. What with CDs containing all RFCs, or similar collections for offline use ? Well, mosts CDs seem to have index pages of some kind - something like http://www.rfc-editor.org/rfcxx00.html would do it (and that is always up to date, whereas STD1 is normally out of date). [standards action] Removing the right to initiate a standards actions from the community is a bad idea. That's not aligning with reality, I tested it, it works like a charme, the RFC in question meanwhile got its number. I didn't intend that at all. Where do you find that? [Draft Standard] Deployable Standard for DS is nice. [conflicts] Does persons appointed to IETF roles include document editors and expert reviewers ? I think Chairs can act as buffer between angry folks and editors, and so hope it does NOT include editors. We can debate the details I guess - but don't you think there should be an appeal path if an IANA-considerations expert reviewer makes a dubious decision? Document editors aren't appointed by the IESG, so wouldn't be covered by my language. Have you integrated your conflict draft into this draft ? No. There was insignificant community interest in that so I've dropped it. It could be better to keep them apart. While you are at it you could adopt John's proposal to replace two months by six weeks for appeals. That would be a real change rather than an alignment with current practice. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet Draft Submission cutoff dates
On Jan 18, 2008, at 5:17 PM, Brian E Carpenter wrote: A possible approach would be to use the cutoff dates as deadlines for drafts to be placed on the WG agenda - i.e. allow automated posting to continue unabated, but only allow late drafts to be discussed in the meeting if so agreed during agenda-bashing. Some of us do that anyway :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet Draft Submission cutoff dates
On 2008-01-19 09:04, Fred Baker wrote: On Jan 18, 2008, at 11:18 AM, Eric Gray wrote: For the people who participate in a fair number of working groups in the IETF, requiring early posting allows for a greater likelihood that they will be able to at least skim each new draft sometime before setting up their laptop at the beginning of each meeting in which that draft will be discussed. Yes, and dating from my time in office, that was also a consideration. A possible approach would be to use the cutoff dates as deadlines for drafts to be placed on the WG agenda - i.e. allow automated posting to continue unabated, but only allow late drafts to be discussed in the meeting if so agreed during agenda-bashing. I certainly think that having a couple of weeks to read drafts is desirable. One week including intercontinental travel is very short. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet Draft Submission cutoff dates
On Jan 18, 2008, at 11:18 AM, Eric Gray wrote: For the people who participate in a fair number of working groups in the IETF, requiring early posting allows for a greater likelihood that they will be able to at least skim each new draft sometime before setting up their laptop at the beginning of each meeting in which that draft will be discussed. Yes, and dating from my time in office, that was also a consideration. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Internet Draft Submission cutoff dates
John, Your description of the reasons for having the draft sub- mission dead-lines may agree with original thinking that went into setting them, initially. However, there were collateral benefits that the new automated submission process helps to improve - but does not eliminate. For the people who participate in a fair number of working groups in the IETF, requiring early posting allows for a greater likelihood that they will be able to at least skim each new draft sometime before setting up their laptop at the beginning of each meeting in which that draft will be discussed. Moreover, having a week longer grace period for subsequent submissions also makes sense from this same perspective - because it is usually the case that there is less new material to absorb in a -01 or subsequent version than there was in a -00 version. Not always, but usually. One exception is when a draft becomes a working group draft - which means it becomes a -00 version with virtually no change from a previous (often a -03 or -04) version. -- Eric Gray Principal Engineer Ericsson -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 2:06 PM Cc: ietf@ietf.org Subject: Internet Draft Submission cutoff dates Hi. The current cutoff schedule for Internet Drafts dates from my time on the IESG (i.e., is ancient history). It was conditioned on the pre-IETF rush and the observation that the Secretariat, at the time, required a sufficiently long time to get drafts posted in the pre-meeting rush that, unless there was a two-week cutoff, we couldn't reliably have all expected documents in hand prior to the start of the meetings. Splitting the new and revised drafts was a further attempt to compensate when the load built up enough that the choices were between such a split and moving the submission deadline for _all_ I-Ds back even further. The conclusion was that a split was desirable because a three-week cutoff for revisions would seriously interfere with WGs getting work done in the run-up to IETF meetings. With the automated posting tools typically getting I-Ds posted in well under an hour and a tiny fraction of the documents being handled manually, the original reasons for the submission cutoffs no longer apply. It is still reasonable, IMO, to have a cutoff early enough to permit people to receive and read documents before departing for the meetings, but it seems to me that criterion would require a cutoff a week (or even less) prior to the meeting, not two or three weeks. Other models about giving people time to read might suggest leaving the new document cutoff at three weeks before the meeting, but seeing if we could move the revision cutoff considerably closer to the meetings. I don't necessarily object to retaining the current two and three week posting deadlines, but I'd like to know that the IESG has done a careful review of those deadlines and their applicability to the current environment and concluded that they are still appropriate, rather than having the secretariat retain them simply on tradition and autopilot. thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Internet Draft Submission cutoff dates
DÁccord. -- Eric Gray Principal Engineer Ericsson -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 4:47 PM To: Eric Gray Cc: ietf@ietf.org Subject: RE: Internet Draft Submission cutoff dates Importance: High --On Friday, 18 January, 2008 13:18 -0600 Eric Gray [EMAIL PROTECTED] wrote: John, Your description of the reasons for having the draft sub- mission dead-lines may agree with original thinking that went into setting them, initially. However, there were collateral benefits that the new automated submission process helps to improve - but does not eliminate. For the people who participate in a fair number of working groups in the IETF, requiring early posting allows for a greater likelihood that they will be able to at least skim each new draft sometime before setting up their laptop at the beginning of each meeting in which that draft will be discussed. Eric, To be clear, I was not advocating doing away with the cutoff. I think cutoffs are a good idea, for exactly the reasons you suggest and because they avoid any necessity for per-WG rules about deadlines to prevent a particularly nasty way of gaming the system. I just want to be sure that the intervals we have been using are still appropriate. Moreover, having a week longer grace period for subsequent submissions also makes sense from this same perspective - because it is usually the case that there is less new material to absorb in a -01 or subsequent version than there was in a -00 version. Not always, but usually. One exception is when a draft becomes a working group draft - which means it becomes a -00 version with virtually no change from a previous (often a -03 or -04) version. Just for purposes of discussion (I do not have any strong positions on this other than a desire to have it reviewed), I think it makes a lot of sense to require a long lead time on new drafts in order that people have a way to consider new concepts, whether they want to attend particular WGs, etc. Three weeks does not strike me as unreasonable for that purpose. And the draft-transition exception you mention is already part of the rules. However, in many WGs, we see a lot of work done in the weeks before an IETF meeting, both before and after the current posting deadline. I think it is in our interest to have WGs looking at drafts that are as up-to-date as possible, consistent with everyone in the WG having a reasonable opportunity to read them before the actual meeting. So I'm not sure that two weeks is optimal for revision drafts. Perhaps the tradeoffs would work better at a week before, or perhaps at some other interval. I suspect that setting the revised draft cutoff much shorter than a week before the meeting would mean that some people would not be able to review them before beginning to travel to the meetings and that the Secretariat might not have time to manually process whatever needed to be manually processed, but I don't know. I do not think it is either wise or useful to try to design the details of this on the IETF list (nor do I think you were suggesting that either) and hope my note does not set off a long thread. I believe it is reasonable for us to ask the IESG to think about the issue, make a decision and tell us. I'd prefer to hear about their reasoning, but I can live without even that. I just don't think it is reasonable to continue automatically with the current cutoffs when the reason for setting those particular cutoff values has largely disappeared. And I wanted to mention the question on the IETF list precisely because I hope that this is not an appropriate subject for an RFC3933 experiment. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SECDIR review of draft-cridland-imap-context-03
* * Section 4.4, second paragraph (s/may/MAY) * Only a single PARTIAL search return option may be present in a single * command. * Should this be: * Only a single PARTIAL search return option MAY be present in a single * command. * * * Best regards, * Chris can be? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Internet Draft Submission cutoff dates
Hi. The current cutoff schedule for Internet Drafts dates from my time on the IESG (i.e., is ancient history). It was conditioned on the pre-IETF rush and the observation that the Secretariat, at the time, required a sufficiently long time to get drafts posted in the pre-meeting rush that, unless there was a two-week cutoff, we couldn't reliably have all expected documents in hand prior to the start of the meetings. Splitting the new and revised drafts was a further attempt to compensate when the load built up enough that the choices were between such a split and moving the submission deadline for _all_ I-Ds back even further. The conclusion was that a split was desirable because a three-week cutoff for revisions would seriously interfere with WGs getting work done in the run-up to IETF meetings. With the automated posting tools typically getting I-Ds posted in well under an hour and a tiny fraction of the documents being handled manually, the original reasons for the submission cutoffs no longer apply. It is still reasonable, IMO, to have a cutoff early enough to permit people to receive and read documents before departing for the meetings, but it seems to me that criterion would require a cutoff a week (or even less) prior to the meeting, not two or three weeks. Other models about giving people time to read might suggest leaving the new document cutoff at three weeks before the meeting, but seeing if we could move the revision cutoff considerably closer to the meetings. I don't necessarily object to retaining the current two and three week posting deadlines, but I'd like to know that the IESG has done a careful review of those deadlines and their applicability to the current environment and concluded that they are still appropriate, rather than having the secretariat retain them simply on tradition and autopilot. thanks, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: houston.rr.com MX fubar?
At 06:29 17/01/2008, Tony Finch wrote: On Thu, 17 Jan 2008, Mark Andrews wrote: a) when RFC 2821 was written IPv6 existed and RFC 2821 acknowledged its existance. It did DID NOT say synthesize from . RFC 2821 only talks about IPv6 domain literals. The MX resolution algorithm in section 5 is written as if in complete ignorance of IPv6 so it is reasonable to interpret it in the way that RFC 3974 does. If you wanted to rule out MX synthesis from then it should have been written down ten years ago. It's too late now. They have already been upgraded in this way. Even without fallback-to- , they have to be upgraded to handle IPv6 anyway, because the IPv4 MX lookup algorithm breaks as I described in http://www1.ietf.org/mail-archive/web/ietf/current/msg49843.html MX additional section is a optimization. The lack of or A records is NOT a bug. Perhaps you could explain why the problem I described in the URL above isn't actually a problem. In my many years of dealing with DNS protocol definition and implementations I have developed a moral: Optimization is the worst possible solution! Placing A records in the additional section on an answer to MX query is an attempt to optimize (or minimize) the number of queries needed by the MTA. Due to this there are MTA's out there that will/can not ask the follow up query if the desired address record is not in the additional section. The fundamental question is which protocol implementation should change to support the other ? Mail people argue that DNS implementations should change, us DNS people argue that Mail implementations should change/evolve. I do not think we will ever agree. Tony, in your message you talk about MTA doing extra wasted lookups. Guess what, it is only a question of who does the work: the MTA or the recursive DNS resolver. The only difference is that the MTA can scope the queries based on what transport protocols it uses, and curtail the search once it finds an useable answer. The DNS recursive resolver can only stop after it tries all names for all transport addresses. Olafur ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-cridland-imap-context-03
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I found the document to be well written and I endorse it becoming a standards track RFC. I did not find anything that would appear to be a security problem but I would like to see some of the wording changed in the Security Considerations section. Specifically, the first paragraph states: It is believed that this specification introduces no serious new security considerations. However, implementors are advised to refer to [IMAP]. I think it could be better worded as: This document defines additional IMAP4 capabilities. As such it does not change the underlying security considerations of IMAP [IMAP]. The authors and reviewers believe that no new security issues are introduced with these additional IMAP4 capabilities. Below are some other editorial items which you may consider. Section 2, second paragaph (s/will/MUST) If this is missing, the server will return results as specified in [SORT]. should be: If this is missing, the server MUST return results as specified in [SORT]. Section 4.1, fifth paragraph (s/will/MUST) mailbox order - that is, by message number and UID. Therefore, the UID SEARCH, SEARCH, UID SORT, or SORT command used - collectively known as the searching command - will always have an order, the requested order, which will be the mailbox order for UID SEARCH and SEARCH commands. Should be: mailbox order - that is, by message number and UID. Therefore, the UID SEARCH, SEARCH, UID SORT, or SORT command used - collectively known as the searching command - MUST always have an order, the requested order, which will be the mailbox order for UID SEARCH and SEARCH commands. (or perhaps SHOULD?) Section 4.3 The third and fourth paragraphs should be combined as they discuss the same topic. Section 4.3 The seventh and eighth paragraphs should be combined. Section 4.3.1 The first, second and third paragraphs should be combined into one paragraph. Section 4.3.2, second paragraph (missing the) The client MUST process ADDTO and REMOVEFROM return data items in order they appear, including those within a single ESEARCH response. Should be: The client MUST process ADDTO and REMOVEFROM return data items in the order they appear, including those within a single ESEARCH response. Section 4.3.2, last paragraph The 2119 keywords should be used when describing expected behaviour. Section 4.4, second paragraph (s/may/MAY) Only a single PARTIAL search return option may be present in a single command. Should this be: Only a single PARTIAL search return option MAY be present in a single command. Best regards, Chris ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-hoffman-additional-key-words-00.txt
At 12:49 16/01/2008, Paul Hoffman wrote: At 1:43 PM -0500 1/15/08, John C Klensin wrote: A different version of the same thinking would suggest that any document needing these extended keywords is not ready for standardization and should be published as Experimental and left there until the community makes up its collective mind. It seems that you didn't read the whole document; RFC 4307 already uses these terms. My experience with talking to IKEv2 implementers (mostly OEMs at this point) is that they understood exactly what was meant and were able to act accordingly when choosing what to put in their implementations. I think this addition of 2119 words is quite useful. More and more of our work shifts from protocol definition to protocol maintenance these extra keywords give working groups a way to indicate to developers/purchasers/planners/operators/regulators[1] what the requirements for the protocol are going to be in the next few years. More and more of the software we deal with is now released in multi year cycles followed by multi year deployment lag. Further more number of protocols are embedded in hardware devices that are frequently not updated during the device's lifetime, think the router in homes. Question: the use of +/- in the context of ? NOT, is that going to be written as SHOULD+ NOT or SHOULD NOT+ ? I have no feeling on the topic just think it should be documented. I support this document and what it is trying to accomplish. Olafur PS: [1] Even though most of the people in the IETF are implementors or lobbyists the documents get used by a large group that is absent from the IETF and due to their roles would contribute nothing even if they attended. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-manet-packetbb-11.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Since this is now scheduled for next weeks telechat, you should liaise with your AD before making any changes. Document: draft-ietf-manet-packetbb-11.txt Reviewer: Elwyn Davies Review Date: 18 January 2008 IETF LC End Date: 16 January 2008 IESG Telechat date: 24 January 2008 Summary: This document is not ready for the IESG. There are issues that must be addressed: - There are parts of the packet format that are not fully specified (encoding of lengths not specified particularly). - The supposed extensibility is currently chimeric. The relationship between this draft, OLSR [experimental, RFC 3626] and OLSRv2 [aiming for ps, draft-ietf-manet-olsrv2-04.txt] should be made clearer. OLSR packet format has very little to do with the current work whereas OLSRv2 explicitly uses the format specified here. The inconsistency of the polarity of the inclusion/exclusion bits in the various semantics fields is ugly, unnecessary and likely to cause grief for implementers who get mixed up, as well as making the document difficult to read. It would be good to fix this before OLSRv2 progresses further. The layer violation required to obtain the notional address length from the lower level protocols is unpleasant. I would like to see an optional field to carry this value explicitly that (a) avoid the layer violation and (b) make the format usable where the network layer protocol is not a conventional IP protocol (e.g. when the format is used in a DTN environment). Personally I would prefer to see ABNF used to specify the packet grammar. It is common IETF usage and generally more familiar to standards readers than regular expressions. Apart from these major issues, there are a number of more detailed comments below and a few editorial nits. Comments: s1/general: While the use of regular expression formalism to express the packet content grammar is perfectly valid, the IETF normally prefers to use ABNF [RFC2234] to express grammars of this kind. Since the very limited subset of RE that is actually used could be equally expressed in ABNF, consideration should be given to using ABNF. This could be automatically checked and is likely to be more familiar to the general reader. Also a number of items in the terminology could then be removed. s2: The 'Network Address' is confusing and not really fully defined. I presume that it is supposed to be the same as what is usually called an address prefix. The exact interpretation of 'prefix length' needs to be spelt out (presumably that only that number of address bits measured from the left/most significant end of the address are significant). s2: address-length: Although address-length can be imputed from the network address fields of (IP) network layer if that is being used, it would make the format more genrally useful (I am thinking maybe DTNs here) if there as an optional field in the packet header (?) to carry the address-length explicitly. That would also avoid forcing layer violations. s3: I sort of assumed from the statement that the protocol was derived from OLSR (an experimental proto, [RFC3626]) that the header compression ideas came from there and hence that there was a good deal of history that needed to be (or at least could conveniently be) brought over. I believe that in practice there is relatively little propagated and some of the choices on this document are not the result of any history - see particularly comments on 'polarity' of semantics flag bits. OTOH, it appears that OLSRv2 which is still a draft progressing towards PS explicitly uses this format. s3, para 2 and s7: There are security concerns with using IPv4 mapped IPv6 addresses, especially 'on the wire'. Technically this usage is not on the wire, I guess, but I think it would be good to point out and justify that the security concerns do not apply (see [RFC4942] for discussion - also you can go back to http://www.watersprings.org/pub/id/draft-itojun-v6ops-v4mapped-harmful-02.txt to see the original discussion at more length). s3, para 5: I am less convinced about the extensibility of the protocol than the authors seem to be because there is no mechanism for specifying behaviour when a receiver sees either messages or TLVs that it does not recognise. A number of relatively standard techniques exist involving emebedded flags specifying drop/ignore packet/message if unrecognized, forward/drop message if unrecognized, etc s3, last para: I believe the 'may' could be a MAY. s3, last para: AFAICS the example feature is not well chosen as the diffusion mechanism is orthogonal to the packet syntax specified here. If there are things about the packet format that might be
Re: SECDIR review of draft-cridland-imap-context-03
Hi, On Fri, 18 Jan 2008, Bob Braden wrote: * * Section 4.4, second paragraph (s/may/MAY) * Only a single PARTIAL search return option may be present in a single * command. * Should this be: * Only a single PARTIAL search return option MAY be present in a single * command. * * * Best regards, * Chris can be? That's possible - I think that the authors need to clarify it better. It may be May be or may be can be or doo be shoo whop. :-) Have a good weekend, Chris ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
On 2008-01-18 17:13, Joe Abley wrote: On 17-Jan-2008, at 18:50, Brian E Carpenter wrote: Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). For what it's worth, there's a document in the dnsop queue which the wg intends to send up the tree for publication as fyi, once past wg last call. So the series might be dormant today, but there's a reasonable chance it might snort in its sleep and roll over in due course. I've always wondered what the designation for your information adds to an RFC that is already labelled informational. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
On 18-Jan-2008, at 21:48, Brian E Carpenter wrote: I've always wondered what the designation for your information adds to an RFC that is already labelled informational. Me too. I hope to find out :-) Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Transition of www.ietf.org Update
This is a reminder that the transition of the main IETF web site began on Wednesday, 16 January. Virtually all changes to static web pages are on hold until testing is completed and the actual cut-over takes place on 31 January 2008. This hold does not affect data driven web pages, web sites hosted and managed by third parties, nor *urgent* requirements. You may continue to submit change requests to [EMAIL PROTECTED] and you will receive a tracker ticket when you submit your request. However, NSS will keep the tickets open and hand them over to AMS after the transition is complete on 31 January. If you have an *urgent* need for a web site change you should make that known in your request. They will be handled on a case-by-case basis. Thanks. Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
